idea to circumvent the u-boot dtb issue

[umiddelb]

Hi,

thank you for doing all the bootstrapping work for the pine64.

I have an idea to circumvent the u-boot dtb issue. On ARMv7 it is possible to append the device tree binary to the kernel image directly via:

CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER is not set
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y

and just invoke

boot[m,z] $loadaddr

after loading the kernel image.

[apritzel]

But this is really ARMv7 only. It got introduced to make the switchover the DT less painful, because a lot of the legacy bootloaders didn't support DT. On ARM64 there was the deliberate decision to not go there and mandate bootloaders to supply the proper DT. So there will never be such an option for arm64 (confirmed by the maintainers). Actually the Allwinner U-Boot isn't so bad - it uses DT all over the place - just that it's the wrong one ;-)

In the middle or long run we need to have a proper arm64 upstream U-Boot, but I want to focus on the Linux upstreaming first and thus came up with this hack. Actually I guess one could append the DT to the Android image - it looks like this "--second_offset" could be used for that. I may use this solution for the initial development phase, but actually I think the DT should be with the device, not the kernel.

[umiddelb]

Where can I find additional information about the Android related partitions (offsets, contents, relationship /dependencies to the boot process, etc.) and about the allwinner u-boot?

[apritzel]

Welcome to the Allwinner world ;-) There is a BSP tarball linked in the linux-sunxi A64 wiki page. It contains some version of the code, but most likely not the versions supplied in the Android image. And it doesn't compile anyway. I added some information in the linux-sunxi Pine64 wiki page about it's shortcomings and how to live with them (more to follow).

[apritzel]

Also look at the new Booting.md, which explains the booting process. This doesn't cover the whole partitions thing too deeply yet , though.

[apritzel]

I pushed a tool to generate the partition tables from the command line. Does that answer your questions on the partitions? Frankly I wouldn't waste too much time on this dodgy Allwinner firmware, as a sane U-Boot is already around the corner: https://gist.github.com/ssvb/67ebb38e8f8f2b9b5ee6

[DieterReuter]

@apritzel I would really prefer to wait until the new U-Boot is finished by @ssvb, because this will simplify things dramatically. Don't wast time and resources with the old and crappy Allwinner blobs and use it to create the new stuff in a better way. ;-) But thanks anyway for publishing the too, just in case anyone could have the need to dig deeper.

[apritzel]

@DieterReuter: that's what I said, isn't it? ;-) But still I need to publish the stuff I have, also people may want to rebuild an Android image for some reasons. Ideally our U-Boot will support booting their Android some day as well, the RemixOS thing for instance seems to be a worthwhile thing to support.

[DieterReuter]

@apritzel you see, I'm able to learn. :smirk: I already tried to open and modify your image with fdisk, kpartx and guestfish, to automatically include my rootfs. All tools reported problems with the partition table and I wasn't able to see /dev/sdX10, so I gave up in the end and will move to a better solution with a new A64 compatible U-Boot.

[umiddelb]

@apritzel Thank you, I only wanted to know where I can find the right offsets for accessing the u-boot environment the kernel image and the device tree binary.

[apritzel]

@umiddelb: ha, that's a nice one and another thing completely broken in their U-Boot: the environment is hard coded in the binary and though there is an environment partition in the partition table, I couldn't get it to be loaded automatically. That's why you have "run load_env" to do this for you, also I overwrote the built-in environment to launch this command after the timeout. So you can create a (binary) u-boot environment image and put this into /dev/sdx5. The .dtb is at 21MB in the SD (so not a proper DOS partition), the alternative .dtb is at 22 MB. The device tree section in README.md tells you how to use this. You can put the kernel image in any of the /dev/sdx[6-9] partitions, again the README.md has the details.

[umiddelb]

@apritzel OK, the last line in gen_part.c contains the information I was looking for. Interestingly I could find the start of an u-boot environment at 280576s but I was unable to find the corresponding CRC32 checksum within 280576s+1M, (the environment size of 1M also deviates from 128k which seems to be the u-boot default for sunxi). This could explain why u-boot refuses to use the stored environment and falls back to the built-in default (env default -a).

Anyway, what do you think about chainloading a 64bit u-boot.img instead of a 64bit Linux kernel?

[apritzel]

"chainloading a 64bit u-boot.img": if you have one? But why would you like to chainload it?

u-boot env: IIRC I tried it with and without a checksum and as a uImage: I think this u-boot doesn't even try to load an environment. If I am not mistaken even on the original image the variables in there were ignored.

[umiddelb]

"chainloading a 64bit u-boot.img": if you have one? But why would you like to chainload it?

I thought this could help to overcome the 32 bit -> 64 bit gap. Since there is a (weird) u-boot able to boot a 64 bit kernel in 64 bit mode, what about replacing the kernel image by a (well-formed) mainline 64 bit capable u-boot (which cannot be started natively by boot0, since boot runs in 32 bit mode), which is able to access MMC, USB, ethernet, ... ?

u-boot env: You're right, I don't know where this u-boot loads its working environment. Even if I have written the current environment to MMC via 'saveenv', it still complains about the missing CRC. Do you have an idea, which of the u-boot sources have been taken for compilation?

[apritzel]

Well, the point is that there is no 64-bit U-Boot port readily available. If we would do a port that is supposed to be started from boot0, we could simply write a small trampoline that does the RMR to AArch64 and declare this is some kind of SPL to U-Boot. So boot0 calls into the trampoline and U-Boot gets entered in AArch64.

But it seems to be saner to use the existing U-Boot sunxi SPL approach, where the SPL replaces boot0 and include the RMR jump there.

But since ssvb already has a working 32-bit upstream U-Boot (including a boot0 replacing SPL), I don't see much incentive to do a 64-bit port. Technically there should be no need for an A64 based board to have a true 64-bit U-Boot, as the whole SoC could be perfectly accessed in AArch32. So I'd rather focus on:

• freeing libdram to be able to distribute an image
• add some RMR trampoline code to ssvb's 32-bit U-Boot just before loading the kernel, similar to what Allwinner does. We could provide both bootz to load 32-bit kernels and booti for 64-bit kernels.

Re: U-Boot sources: I briefly looked at the U-Boot source in the BSP and it didn't compile for me. Some part were obviously broken (syntax error in Makefile), so this particular source drop is definitely not the source used for that binary. Quickly fixing the most blatant issues just revealed more issues, so I don't waste any time on this.