martinayotte

If you do a "i2cdetect -l", you will probably see that i2c-0 is dedicated to "sun4i_hdmi_i2c adapter", which maybe wasn't present before ...
 

Are the old module and the new RTL8723BS are pin compatible ?

So, I must be masochist since ALL by boards using old fashion /etc/network/interfaces ...

happens when you take a nap during your statistic courses.. seeing A, thinking about B and conclude C.. Unfortunately, it's not only he who should be blamed for it.. Quite a long time we tried to fit every storm, hot weather period, *random climatic phenomena* into this 'climate change thing'.. Not as surprisingly people don't believe it anymore.. The worst thing you can do to a field of science is to steal its trustworthiness.. And at least for a (growing) fraction of the population we must conclude that we achieved this since a few years now.. Well done...

He means that you can fork this github https://github.com/armbian/build , do a "git clone" to your local PC, do the appropriate change to the kernel config, commit it into your fork, and then send a PullRequest to Armbian github.

http://wiki.banana-pi.org/Getting_Started_with_R64

Doesn't seems to work on Pinebook with Armbian 4.20.y.
I will probably check with an Ayufan image later ...

Probably ...
To confirm, check it by doing "grep APPARMOR /boot/config-*" .

It has not been intentionally removed ...
When a new kernel branch appears, there is a new defconfig for it. If we don't meticulously doing diff between old and new defconfig, it is easy to forget some drivers, and if no one report the missing, it can stay like that for months ...
Now that we know, I will add this one the NEXT and DEV defconfig for future builds !
 
EDIT : Done ! https://github.com/armbian/build/commit/d1f8564edb614c655d818b860320706ce6fca258
EDIT2 : The above commit is for sunxi ! For meson64, here it is : https://github.com/armbian/build/commit/93207705504400ae8fa4c28e4bfccd99803cbbfa

Me neither
Fortunately, it doesn't ask Social Security Number ...

Me neither
Fortunately, it doesn't ask Social Security Number ...

With fresh image, Armbian is asking for "1234" password twice, then ask to enter new password twice, followed by new user creation ...

To see more verbosity, edit /boot/armbianEnv.txt, make sure that "verbosity=7" and "console=serial" instead of "console=both".
This way, you will be able to see what is happening during this 44 seconds ...

The OPi-H6 boards are WIP (aka "Work in Progress"), this means you need to build the images yourself.
It is pretty straight forward : https://docs.armbian.com/Developer-Guide_Build-Preparation/

Unfortunately "getting information" != "answering the same questions and requesting even the basic info again and again and again".
 
For example, threads like this one would have 1 reply with a simple answer - eMMC CSD checks for revision 8 were fixed more than a year ago. It took 5 posts to confirm that this is the culprit and it is still impossible to tell which kernel version (I mean kernel compilation date) is used due to missing dmesg from "armbianmonitor -u".
 
Funny thing is that this thread was created after the addition of the new information collection form, so we may as well make providing armbianmonitor -u output mandatory with 2 exceptions in dedicated subforums - devices without network connection and devices that failed to boot completely.
 
Applying your knowledge and experience while at the same time learning something new is fun, and it can happen when you are talking with a person who at least tries to understand what he is doing and who respects your time by trying to provide requested (and even more than requested) information.
Reading 90% of threads in the "Allwinner H2/H3" section made by people who expect performance and software quality of at least a $200 PC like a J5005 based NUC7 from a $20 board like Orange Pi PC is definitely not fun for me. YMMV.
Unfortunately supporting low end (by price) boards attracts their target audience aka people for whom even the Raspberry Pi is too expensive.

I don't know, but this leave me in big doubts, since this 0x03000030 doesn't point to any kind of registers in the Allwinner datasheets or specs
 
EDIT : It seems that only "compatible" change is required, although this is pretty much a hack, since it doesn't use H6 compatible that @Icenowy delivered ...

I've received my OrangePi-RK3399 recently ...
Just for trials, before doing any real development, I gave a try with a NanoPC-T4 4.19.y image compiled a month ago, and it worked "as is", even eMMC and WiFi is running fine.
That it is a good starting point !
 
Of course, to be able to boot from SDCard, we need to short the eMMC clock using the test point TP50265 :
 

I've just built and tested a new image for OPiOne with 4.20.2 and v2018.11, and it works perfectly ...
 
So, maybe your image was corrupted, or your SDCard flaky, did you use Etcher to burn it ?

If you purchase one, they are so cheap, it will help a lot ...

We, Armbian Devs, didn't found a way to fix that issue yet, so you will need another way to get ethernet, such as USB adaptor ...

Another thing I can share :
I had to temporarily disable this patch https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/general-aufs4.19-20181029.patch , I didn't investigated how to make it 4.20.y compliant ...

And this:
https://github.com/armbian/build/commit/e6d90536d114d57020857a22b1f031fc8c19d0bf
 

Yes, I've just added NEXT to them : https://github.com/armbian/build/commit/c6e7f4fa4539d4aa1a9c9dc4b66a44a5619f4926
 

I can share the fact that I've not resolved the H6 issue freezing at "starting kernel", I've even tried them with 5.0.0-rc1, still the same.
If someone can help narrow the issue, I will be glad ...

so today we're talking a little bit about the buildscript (likely that those posts will be splitted out into it's own thread to build up a miniseries of tutorials)... I just talk about basics of it. To be honest, I don't know every part of it fully but for detailed questions there are people here which can answer specific parts. For the simplicity we assume that the SoC on the board is a supported one (rk3399 is). A basic overview with tree -L 2 to get a overview:
 
cache: to avoid downloading the sources again and again every time you build an image and saving you time to build images, armbians build-script caches sources (e.g. rootfs, kernel sources, u-boot sources, atf, compilers - out of tree sources can't always be compiled with the newest compiler versions so we also have some older ones) config: basic configuration files for your board, the kernel and sources we use. config --> board: an armbian specific boardconfig file, for the RockPi 4b it looks like the follwowing: # RK3399 hexa core 2G/4GB SoC GBe eMMC USB3 WiFi BOARD_NAME="RockPi-4B" BOARDFAMILY="rockchip64" BOOTCONFIG="rockpi4b-rk3399_defconfig" # MODULES="" MODULES_NEXT="" # KERNEL_TARGET="default,dev" CLI_TARGET="stretch,bionic:default" DESKTOP_TARGET="stretch,bionic:default" CLI_BETA_TARGET="" DESKTOP_BETA_TARGET="" BOARDFAMILY tells you which sources it uses (later more on that).
BOOTCONFIG telly you which xxx_defconfig file in u-boot will be used (maybe something for an u-boot plumber tutorial follow up) Modules is only needed if you've to install special modules to enhance functionality (something for a more detailed tutorial).
KERNEL_TARGET (will be explained in sources), CLI_TARGET (which flavors of Armbian you can build (here we provide only ubuntu bionic and debian stretch for some older kernels we've to provide xenial as well cause they're not able to work properly with stretch or bionic).
DESKTOP_TARGET - same as CLI but with a DESKTOP (e.g. we don't provide DESKTOP images for boards without HDMI etc.). CLI_BETA_TARGET not of interest yet.
 
config --> kernel (the .config file you normally get with make ARCH=arm xxx_defconfig if you compile kernels on your own - our configs differ often from defconfigs provided by kernels often to enhance functionality) config --> sources as you can see, the RockPi4b is part of the rockchip64 family therefore (https://github.com/armbian/build/blob/master/config/sources/rockchip64.conf):   for a beginner, most of this configs here can be ignored cause it needs some knowledge to deal with but a few interesting parts will be explained. It basically describes you which sources we use for ArmTrustedFirmware (part of  all(most?) ARM64 boards during boot. U-boot (before the kernel fires up) and which kernel sources will be used for default (often a BSP Kernel), next (mostly a vanilla kernel) and dev (mostly a kernel close to mainline - for rockchip64 for example this is a kernel based on 4.20). some tweaks needed to build an image (e.g. different SoCs expect the u-boot binary on a clear defined place inside the SD-Card for example here: dd if=$1/uboot.img of=$2 seek=16384 conv=notrunc status=none >/dev/null 2>&1 ) tweaks which are needed to boot up the board (e.g. rockchip needs a few binaries and it depends on which rockchip SoC, (sometimes also ramspecific) you use to boot up a board - rockchip64 is for rk3328 and rk3399 and they use different binaries) some family_tweaks here to enable debug console etc. (boardspecific tweaks are also here with some if statements to keep those changes separated from the others). To do changes here or to create such a file from plain (for a new boardfamily) you might need some more experience but it's worth to have a look at it (especially to check which sources we use). The rest of config is currently not that important.
config-default.conf (shows up after you build an image for the first time): this file will be important but since this post here gets anyways too long I try to explain it in the next days (it deserves to have it's own day)
lib: the build-script is not only one big bash-script it's splittened into different ones. In the beginnings you (hopefully) don't need to change something in them but cause the script isn't everywhere 100% clean (we've to be pragmatic here + different people have different opinions how stuff should be solved) it's worth to try to understand how random part of the script work (needs knowledge in bash and definitively not learned within a few hours - you need some background this grows over time)
output: that's where your kernel config (if you decide for Show a kernel configuration menu before compilation - would also need it's own post), debs (debian packages built during compilation, e.g. needed for sending kernelupgrades via apt upgrade), debug (also something for a further tutorial - you'll have a lot of fun with this folder during development ) images (the finally compiled images if nothing fails) patch (will be explained in the follow up, but that's most of the work devs do here.. - e.g. if we fix something inside a kernel or u-boot etc. a patch is automatically generated this is then moved to the appropriate patch folder and part of the buildscript)
packages:  blobs we've to deliver (e.g. to boot up a board), bsp (board support package - I also call non vanilla kernels bsp kernels, it has similarities but it's not the same - some boards need special configurations, e.g the bananapi r2 which has 5x GbE has here some configuration files to bring up all it's interfaces), tools (never worked with, ask someone else ) extras-buildpkgs for packages we deliver to get the enhanced functionality ( also not needed to understand fully in the beginnings - wouldn't call myself an expert on this part.. )
patch: if you generate a patch for kernel or u-boot and you want that others can use it as well place it here in the right folder, create a pull request to armbian and we'll get it. The structure is 'relatively' simple splitted into kernel, u-boot and atf (you won't patch atf soon.. ) for the kernel then splitted into boardfamily-branch (default,  next & dev - for the rockpi this means rockchip64-default and rockchip64-dev is of interest). For u-boot it's mostly u-boot-boardfamily (sometimes we have two branches for u-boot, e.g. the time we switch from a out of tree u-boot to upstream or we need different u-boot sources. not that often here u-boot-rockchip64-dev is of interest for the RockPi)
userpatch: the same than patches but for stuff you don't submit back to our tree (e.g. you can place your patch there if for whatever reasons it's not accepted by armbian - e.g. if it breaks other boards)
now you got an brief overview how much you'll have to learn until you understand it fully and in the next days I might partly explain how to use it.. If you can't wait reading more.. there you go:
https://forum.armbian.com/topic/6-how-to-build-my-own-image-or-kernel/?page=6&tab=comments#comment-65998
https://forum.armbian.com/topic/7296-bananapi-r2-csc-mt7623-as-new-boardfamily/
 
have fun.