Jump to content

Building mainline U-Boot for Orange Pi Zero Plus 2


BreadLee

Recommended Posts

Dear Community, 

 

I am actively using an Orange Pi Zero Plus 2 board and I want to build U-Boot mainline by myself.  I donwloaded mainline version from Denx's git, but when I'm doing configuration for Orange Pi Zero Plus 2. it uses H5 chip, but my board works with H3. 

During building Armbian Images, build system downloads latest U-Boot version and build it for H3 chip.  I'm new to u-boot and maybe someome will help to find propper configs.

 

Kind regards

Link to comment
Share on other sites

Although pins compatible, H3 and H5 are completely different beast ... An H3 build won't run on H5 ... Maybe you get u-boot prompt, but no SPL, no 64 bits loading ...

Why not using Armbian build process ? You will get a complete image for OPiZeroPlus2, although maybe some missing functionnalities ...

 

Link to comment
Share on other sites

10 minutes ago, martinayotte said:

Why not using Armbian build process ?

I'm trying to create device with two partitions, which situated on eMMC. First one will be main for system and user, but in cases, when main boot will be broken I want boot from second one and then rewrite broken partiton. So currently I don't know how to do that. That is why I started with U-Boot and it's functionality. Maybe I'm chosen to go wrong way.

Link to comment
Share on other sites

3 minutes ago, martinayotte said:

Starting your own build process from scratch could become tedious.

You are absolutely right....

 

3 minutes ago, martinayotte said:

Better use Armbian and tweak your partition scheme manually ...

But I don't know how to start and where I can find information about that. May you advise me something? 

Link to comment
Share on other sites

The partition stuff is located in the lib/debootstrap-ng.sh script, but doesn't handle the scheme you wish. You are in your own to tweak that...

But why do you wish to have RootFS in second partition instead of the first ? Adding a second partition as data would be easy.

If you wish to have dual-boot capabilities, then it is a completely different issue, current u-boot doesn't support that, it requires custom u-boot ...

 

EDIT : maybe an interesting reading : https://github.com/u-boot/u-boot/blob/master/doc/README.bootmenu

 

Link to comment
Share on other sites

25 minutes ago, martinayotte said:

But why do you wish to have RootFS in second partition instead of the first ? Adding a second partition as data would be easy

My idea looks like this: I want to create system, which will can be restored by itself. I've got two separate partitions: first one which works everytime, in other words main partition. Another one will be used in emergency cases only (restore partition). For example: something goes wrong, it is not possible to boot from the main partition. I want to boot from restore partition, then I want rewrite main partition from restore partition. Then reboot and work in normal mode, until new emergecy case will occur. 

Link to comment
Share on other sites

Such implementation will be hard to achieve with proofed automation, because if a kernel crash, how u-boot will be aware of that since it is already given control to kernel !

There will be the need of human intervention anyway using u-boot bootmenu ...

Link to comment
Share on other sites

28 minutes ago, martinayotte said:

There will be the need of human intervention anyway using u-boot bootmenu ...

Sure, I understand that. Currently it will be great for me, to make such system with a human intervention. I don't know how to store two systems and one u-boot and select only that system, which one I want to boot...

Link to comment
Share on other sites

I think this depends on the grade of manual interaction you're willing to do in case it goes wrong... :) E.g. when you're willing to hook up a serial console it 'should be an easy task' just set up a second partition with its own kernel and rootfs on the SD-Card, interrupt the bootprocess and load manually the second kernel, DT (in case you go for mainline) and uInitrd e.g. with something like:

ext4load mmc 1:2 ${loadaddr} ${path}
...

But then the question which comes to my mind: Which failings do you expect? Just mess up stuff in kernel and/or rootfs? Cause if it's more a failing of the SD-Card which worries you, you might think of a backup strategy on different storage. A repeal and replace approach works often better for me.. :P Means write scripts which set-up all the programs I need on top of 'stock armbian' and think about which data needs to be backuped in case the board fails. When my board now fails for whatever reason, I don't waste much time with searching for errors I just set up a new card with a new image. Obviously those scripts needs to be tested before it fails (also if the backup data is sufficient to get it 'working as before'). 

 

A 'quick and dirty approach' might be using customize-image.sh where you set up a second partition to duplicate the first one (with kernel & rootfs) but you might test how well this works with the firstrun scripts (e.g. resizefs). 

Link to comment
Share on other sites

@chwe  Thank you for you reply! Yes, currently I want to create second partition with its own kernel and other files, but I don't know how to do that? For me it looks so mysterious :), cause I'm noobie in U-Boot and Linux Kernel. I'm trying to dive in this suff using google, but it doesn't work such way. 

 

To this moment, I compiled U-Boot and Linux kernel (uImage) and DTS file...  I tried to mix this files on SD card, but without any great results  Maybe you will advise me something?

Link to comment
Share on other sites

there isn't much which you've to change in u-boot. U-boot loads whatever you tell u-boot to load, either this is on the first, the second or whatever partition on your storage. Armbians default is to have everything on one partion (so you'll find in /boot): 

/boot
├── armbianEnv.txt
├── armbianEnv.txt.out
├── armbian_first_run.txt.template
├── boot.bmp
├── boot.cmd
├── boot-desktop.png
├── boot.scr
├── config-4.14.37-sunxi
├── dtb -> dtb-4.14.37-sunxi
├── dtb-4.14.37-sunxi
├── dtb.old -> dtb-4.14.30-sunxi
├── initrd.img-4.14.37-sunxi
├── overlay-user
├── System.map-4.14.37-sunxi
├── uInitrd -> uInitrd-4.14.37-sunxi
├── uInitrd-4.14.37-sunxi
├── vmlinuz-4.14.37-sunxi
└── zImage -> vmlinuz-4.14.37-sunxi

your kernel, boot.scr, armbianEnv.txt, dtb and uInitrd (actually the stuff you 'need' to boot armbian without manual interaction with u-boot).  U-boot loads boot.scr, boot.scr replaces some variables with the content from armbianEnv.txt, the kernel, uInitrd and the right dtb are loaded with proper bootargs and the board boots. But all this stuff sits at the moment on the first partition. U-Boots default bootorder is SD-Card > eMMC > SPI flash. 

You may get some inspiration from @tkaisers work for the OMV-Images (https://github.com/armbian/build/blob/cf40fda60aa8a0d9bbc61bd6484313af9b453911/config/templates/customize-image.sh.template#L144-L159) where he adjust rootfs_resize to 7.3GB, so something like this will be needed for you too. Then you generate a partition with a second kernel and maybe a second rootfs. From there, you can either manually interrupt u-boot to boot your second kernel/rootfs or you may patch your u-boot to have some 'logic' (e.g. read pinstate of a GPIO low-->boot from first partition, high --> boot from second partition).

4 hours ago, BreadLee said:

Maybe you will advise me something?

Hmm not really.. :P I only deal with u-boot to the point to get things working as expected. :P  Means, I try to patch older u-boot versions to let them behave as they should for default armbian as I've done it here:

 

Doing 'fancy stuff' is neither my field of experience nor interest... :P Since armbian uses mainline u-boot for H3, things should be easier.  At least all needed functions for such a project can be found in u-boots documentation whereas documentation for a BSB u-boot is often a bit 'questionable'. Things you've to consider:

  • Your userbuilt Image will not behave like a default Armbian. You may need to freeze kernel/uboot from updates otherwise this may break your system.
  • Is it worth the effort? You gain a multiboot system to the price that you'll have to update kernel/u-boot on your own. But does it save you from the errors you expect? If your system fails you may get it booting from the second partition, you may repair the first one from there but probably this can also be done by just mounting the SD-Card on your PC? Or you boot an image from the SD-Card, mount the eMMC and try to repair things you messed up.
  • It's not really a backup. I would rather think about a proper backup solution than a dual boot system on a single memory.
For sure it's a nice learning experience. IMO you learn much more from 'not out of the shelf'-projects (no matter if they make sense at all or not) but I would see it more as a learning experience than a productive system. :) This stuff needs testing, testing and more testing. Does it behave as I expect? Does it do what I want? Is what I think I want also the thing I need? :P As soon as things 'work' people think the job is done.. They only realize that the job wasn't done when things start to fail and they realize that their concept doesn't behave as they thought it would. But try it! Even if it doesn't work fully, you'll learn something which might help you later for another project. 
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines