Gentoo Forums

Some time ago I got an old BananaPI board with some ancient linux on an SD card.
Replacing userland sort of works. I haven't figured out all the tricks with cross-compiling, but the minimal userland I stuffed in there does work.

Now I want to replace the kernel 3.4-sunxi with 4.5-gentoo (it comes with a default config for sunxi so it should work, right?). Or anything I can actually configure. U-boot appears to be the only bootloader for ARM out there, yet I can't really find any useful information on it.

When I build kernel with cross "make uimage", I get something u-boot recognizes and attempts to boot, but the output to UART drops afterwards ( I replaced uImage on the FAT boot partition)
When I attempt to create either kernel or initramfs manually with mkimage, u-boot complains it's in wrong format and falls back to builtin defaults.
Finally, it seems that there are 2 ways to boot: legacy one using script.bin, and a new one (for newer kernels) using dtb. I found examples of both ways for banana on sunxi's wiki, but neither works for me.
dtb example goes like this (of course replaced board.dtb with an actual filename): So... Any ideas? How do you prepare and run your custom kernels on arm boards?
Also, how do numbers known to mkimage relate to numbers in uEnv.txt (or, do they)? Below is a working, legacy config running the provided kernel. And one more... The uImage generated with make uimage is very similar in size to zImage. The generated Image file is roughly twice as big. Why does mkimage recognize this uImage as "uncompressed"?

I also tried compiling u-boot from a main git repo and snapshot. One was damaged, the other failed to build. Finally u-boot-sunxi succeeded and I burned it into SD card with dd, but I don't see any difference at all compared to the earlier one.

Generic answer: Please configure your bootloader.

*NIX run on most anything. And configuring is most of the time the same regardless the implementation.

The generated Image file is roughly twice as big.

Check what you have enabled and what you really need.
Check if you have choosen a proper compression for your kernel image.

Check and utilize if needed, the build in kernel command line and build in initramfs

GEneric answer: use a proper compression, set the needed parameters in the build in kernel command line, add any needed file in the build in kernel initramfs.


[/code]

Finally u-boot-sunxi succeeded and I burned it into SD card with dd

Nope and nope

You neeed to crosscompile software for your "target architecture"

We do not burn stuff to a SD card. it is flashed based. it is electronically earaseable. Burn is afaik used for worm media / optical media.

dd is just a special way to write to the SD card. And a very dangerous one. This can lead to data corruption when not done properly, with less knowledge / bad guide ...

http://linux-sunxi.org/U-Boot

Well i understand your pain because It seems to be some hardware hacks involved. And I doubt an ordinary user knows where to align those data sectors

setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait panic=10 ${extra}
ext2load mmc 0 0x43000000 script.bin
ext2load mmc 0 0x48000000 uImage
bootm 0x48000000

I nearly ruined a 400 dollars smartphone because of such insane nuts tutorials which could not explain / guide why those sectors are needed and such.

The guide for example lacks on how big the SD-Card in question should be and such.

--

U-Boot 2015.07+ won't start

If you're using a recent (device model based) U-Boot, and the SPL just hangs after initializing the DRAM (CPU: 912000000Hz, AXI/AHB/APB: 3/2/2 or something similar), chances are that your main U-Boot binary may be missing DTB information / a proper device tree. Depending on the (possibly outdated) instructions you followed: double-check that you're not incorrectly using u-boot.bin instead of u-boot-dtb.bin, or u-boot.img instead of u-boot-dtb.img.

--

Personal opinion:

Hardware hacks, lacks of proper explanation how and such. I had already my share of such stuff, If I were you I would stay away from such stuff.

It clearly visible that this hardware needs some machine readable section generated by the admin which later loads a payload which in your case is a bootloader, which payload later is the linux kernel ... and such.
--