Armbian Buster and Bionic with 5.7.y

[khumarahn]

Well, I still cannot compile a working u-boot myself; the one of armbian does not count because it is hard to follow what is going on.

I mean, sunxi' branch of u-boot with atf-allwinner (whether I compile if myself or copy is from debian) does not really see the eMMC at all.

The magic number error is strange. Maybe it is something simple like one u-boot supporting compression and the other not.

I think now it is not related to the magic number... The u-boot does not even see the boot.scr, so probably things get wrong somewhere in the very beginning.

[khumarahn]

OK, I know how to build a working u-boot:

Code Select Expand

set -e # exit if any command fails

git clone https://salsa.debian.org/debian/atf-allwinner.git --depth=1
cd atf-allwinner
make PLAT=sun50iw1p1 DEBUG=1 -j4 bl31
cp build/sun50iw1p1/debug/bl31.bin ../
cd ..

wget https://github.com/Icenowy/u-boot/commit/960ae7.diff
git clone --single-branch --branch pinebook-wip-20181109 --depth=1 https://github.com/anarsoul/u-boot-pine64.git
cd u-boot-pine64
git apply ../960ae7.diff
BL31=../bl31.bin make teres_i_defconfig
BL31=../bl31.bin make -j4
cp u-boot-sunxi-with-spl.bin ../
cd ..

Now: how to build the mainline u-boot for teres?

[lambda]

I think now it is not related to the magic number... The u-boot does not even see the boot.scr, so probably things get wrong somewhere in the very beginning.

Hm, then I must have misunderstood something in your previous message. Never mind.

Now: how to build the mainline u-boot for teres?

Probably not yet. Your results indicate that not everything needed for eMMC is merged yet. (And since anarsoul seems to be actively working on upstreaming his patches, there probably isn't much you can do to speed this up.)

OTOH the teres enable patch seems to work fine and it appears icenowy has stopped working on teres. So bringing this patch to shape and submitting it would help a lot. (And it's no real "building from mainline" so long as this patch is missing.) Also once teres support is in u-boot, people will keep it updated when changing related bits of u-boot, that might break it.

[khumarahn]

I have a working installation on the eMMC with the u-boot built as above and config that avoids the volatile /dev/mmcblk{1,2} devices:

Code Select Expand

$ cat /boot/boot.cmd
setenv bootargs rootwait root=PARTUUID=3807bc36-02 rootfstype=f2fs debug=on console=tty0 console=ttyS0,115200n8 no_console_suspend
load mmc 1 0x44000000 dtb
load mmc 1 0x41000000 Image
booti 0x41000000 - 0x44000000
My fstab also uses UUID. It would be good to figure out how to make /dev/mmcblk{1,2} predictable, but it is not a pressing issue.

I'd be happy to cleanup Icenowy's patch. Though I still understand little about what needs to be done. It looks rather clean already, no?

[lambda]

What's the trick to avoid volatile devices? From to code snippet I don't understand what your solution is.

Patch cleanup:
Step 1: Sync the DT in the patch with what we have in the linux kernel now. (Ie use DT from linux kernel, but readd all the nodes, that are in patch but not in linux. - I guess this is mostly the eDP bridge, but check yourself to be sure nothing gets lost.) Have a look at the DT for pinebook to see how it is done. (Also a git log on the pinebook DT might clear up things.)

Step 2: The defconfig probably contains symbols randomly enabled until "it works". Try to disable anything that might be unnecessary. Cross checking with pinebook defconfig will help a lot, but some things are different. (You will now about them once you compare DTs). Also cross check with common sense - maybe there is something that would improve things when enabled. (USB stuff (working keyboard in u-boot anybody?) comes to mind, but I have no idea really).

Step 3: Test. It should work realiably on external sd card. Don't worry if it doesn't work on eMMC, though if you can make it work there (maybe some more patches merged by anarsould in time) even better.

Step 4: Submit it to the right mailinglist/people. I guess scripts/get_mainter.pl is your friend, but I don't know u-boot customs.

TIA,
Harald

[khumarahn]

Thanks!

What's the trick to avoid volatile devices? From to code snippet I don't understand what your solution is.

That is `root=PARTUUID=3807bc36-02` in kernel command line, in place of `root=/dev/mmcblk1p1`. Apparently, we cannot use UUID there, but PARTUUID works OK. Perhaps, could use partition labels.

[lambda]

That is `root=PARTUUID=3807bc36-02` in kernel command line, in place of `root=/dev/mmcblk1p1`. Apparently, we cannot use UUID there, but PARTUUID works OK. Perhaps, could use partition labels.

Hm, that should help the kernel find the rootfs. But how does this help u-boot find the right device to load the kernel from?

[khumarahn]

Loading kernel works from mmc 1, regardless whether kernel identifies eMMC as /dev/mmcblk1 or /dev/mmcblk2.

[lambda]

Ah, then I completely misunderstood what the issue was. Yes device numbering is not reliable in the kernel. (Hasn't been since 2.6.0 or something.) UUIDs is the way to go. (Also we now use libgpiod instead of /sys/class/gpio for the same reason, etc.)

[igorpec]

Update.

Debian Buster and Ubuntu Bionic (preview) with Kernel 5.1.7
https://www.armbian.com/olimex-teres-a64/#kernels-archive

[d3f]

Update.

Debian Buster and Ubuntu Bionic (preview) with Kernel 5.1.7
https://www.armbian.com/olimex-teres-a64/#kernels-archive

Thanks Igor,

I have tried that and it looks very stable. I am having some problems with the audio but I think I can manage it.

Is there any video acceleration included on the kernel configuration?

Also I tried to build the image on my own but I don't see the 5.1y option on the ./compile.sh script.

Regards,
Lazar

[igorpec]

Thanks Igor,

I have tried that and it looks very stable. I am having some problems with the audio but I think I can manage it.

Is there any video acceleration included on the kernel configuration?

No. Coming with 5.2.y, probably also with faster closed source MALI support.

Also I tried to build the image on my own but I don't see the 5.1y option on the ./compile.sh script.

Regards,
Lazar

DEV configuration are hidden by default since we don't want users to build (and ask questions which we are unable to process) those, sometimes very unstable, targets.

Add EXPERT="yes" for unlock.

[binutzu]

I tested these days Ubuntu_bionic_dev_desktop.7z 2019-07-07 and experienced crashes.
If it weren't for the crashes i really considered putting it on internal eMMC. Works really nice.

So one thing i did after 1st flash on SD card was to check sound in browser (youtube) so i tried various options for pulseaudio output till it worked. After a reboot it crashed, if i remember well, after gui login.
I flashed again anew and i could use the laptop 2-3 times (no audio tweaking).
This  evening i used it again, just reading some news (again the browser) and it crashed in such a way that it actually powered off instantly with a click in the speakers.

Did anybody else experience this? Restarts happened some months ago also when i tried the Armbian image (was maybe the May release?).

Actually i decided to write this post because i found it interesting that this crash caused an immediate poweroff. Writing the post from the "stock" xenial 

[JohnS]

Possibly a lack of enough good power.

John

[igorpec]

Bump. Updated to 5.4.20

(mine seems to have some troubles with a keyboard, so I could not test, but we got reports its working)