LinuxQuestions.org - Updating U-Boot for Orange Pi H3

- Slackware - ARM (https://www.linuxquestions.org/questions/slackware-arm-108/)

- - Updating U-Boot for Orange Pi H3 (https://www.linuxquestions.org/questions/slackware-arm-108/updating-u-boot-for-orange-pi-h3-4175648375/)

Updating U-Boot for Orange Pi H3

Moved discussion from this thread

Quote:

Originally Posted by SCerovec (Post 5962403)

do i smell a Mac user here? ;)

Not really sure what you mean there. You're proposing having the U-Boot files on a FAT partition. It's also what's documented here.

[snip]

Quote:

What does the Build your own latest kernel documentation say? ;)
(there is a saying: "If the documentation is right the software has to be obsolete." :study:)

Not heard that one. I like it!

Quote:

Maybe an big fat warning about "We're here to get You rolling only!" is in order?
And a link of where to start hacking on...

One person's rolling in to what it is they need that will take them where they want to go, is already another person's end state. The documentation states what it covers, and for anything else, discussions such as this ensue.

Quote:

Someone might get the impression ("supported devices") that Slackware is endorsing heavy loads for the vanilla install?

Slackware is a multi purpose OS, and the ARM port has always sought to be in line with that goal - which it is. It's not aimed at being used for embedded purposes or anything like that.

Quote:

we seem to have come to following boot edits:
1. offline (FAT is a benefit there)
2. off boot (save env has to work)
3. online (from the running system)
the more we make to work - the merrier, and less likely some ex_soviet_state hacker comes and rubs our noses :o about a single conf line we might have missed?

Yes it's probably a config option, looking at this:
https://patchwork.ozlabs.org/patch/214468/

However, the issue seems pretty clear now. With the new SD card images, writing U-Boot to the image is overwriting the FAT partition, as I can see by mounting the SD card.

Code:

root@kitt:~# mount /dev/sdd1 /mnt/floppy/

NTFS signature is missing.

Failed to mount '/dev/sdd1': Invalid argument

The device '/dev/sdd1' doesn't seem to have a valid NTFS.

Maybe the wrong device is used? Or the whole disk instead of a

partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

I uploaded the new U-Boot stuff here

I need to spend some more time hacking on that to get it working, but it's probably almost there.

so, in effect, the env was threading on the partition?

And the save to file didn't work yet?

Quote:

Originally Posted by SCerovec (Post 5962491)

so, in effect, the env was threading on the partition?

And the save to file didn't work yet?

The 'dd' of u-boot to the image is screwing up the FAT partition table; so the new script needs a bit of work.

I'm guessing that once that's fixed, saveenv will work.

Quote:

Originally Posted by drmozes (Post 5962512)

The 'dd' of u-boot to the image is screwing up the FAT partition table; so the new script needs a bit of work.

I'm guessing that once that's fixed, saveenv will work.

can't you just dd it and then partition and format afterward?

AFAIK the partitioning data and the dd overlap only in the "master boot record" and that is a simple thing or re-dd if needed?

Making progress!

I've made an image with a FAT partition, and the latest u-boot.
It seems that if there's MMC (not SD card) even if there are no partitions, U-Boot restricts itself to looking on that device rather than the SD card.

So, I have put the SD card image on to the MMC and it works fine.

The next step is to figure out either why it doesn't check the SD card (it finds it using the u-boot mmc commands, and can load a file from the file system - so it all works), or to figure out how to hard code the device number of the SD card; although that's far from ideal either.

I'll probably upload this stuff next week.

Code:

U-Boot SPL 2019.04-rc1-dirty (Feb 16 2019 - 16:15:14 +0000)

DRAM: 2048 MiB

Trying to boot from MMC2





U-Boot 2019.04-rc1-dirty (Feb 16 2019 - 16:15:14 +0000) Allwinner Technology



CPU:  Allwinner H3 (SUN8I 1680)

Model: Xunlong Orange Pi Plus 2E

DRAM:  2 GiB

MMC:  Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c10000'

mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1

Loading Environment from FAT... OK

In:    serial

Out:  serial

Err:  serial

Net:  phy interface7

eth0: ethernet@1c30000

starting USB...

USB0:  USB EHCI 1.00

USB1:  USB OHCI 1.0

USB2:  USB EHCI 1.00

USB3:  USB OHCI 1.0

USB4:  USB EHCI 1.00

USB5:  USB OHCI 1.0

USB6:  USB EHCI 1.00

USB7:  USB OHCI 1.0

scanning bus 0 for devices... 1 USB Device(s) found

scanning bus 1 for devices... 1 USB Device(s) found

scanning bus 2 for devices... 2 USB Device(s) found

scanning bus 3 for devices... 1 USB Device(s) found

scanning bus 4 for devices... 1 USB Device(s) found

scanning bus 5 for devices... 1 USB Device(s) found

scanning bus 6 for devices... 1 USB Device(s) found

scanning bus 7 for devices... 1 USB Device(s) found

      scanning usb for storage devices... 1 Storage Device(s) found

Hit any key to stop autoboot:  0

=>

=> saveenv

Saving Environment to FAT... OK

My MMC you mean MTD? (in the sense of board soldered on flash storage)

Only otheer option would be actual MMC card vs SD card?

If so, isn't the env code responsible for preference?

Or, eventually is there in the u-boot a hard coded order of preference?

Quote:

Originally Posted by SCerovec (Post 5963349)

eMMC is embedded MMC, and MMC are for removables such as an SD Card.

I think I've cracked it now. It's hard coded to look at device 1 (eMMC), so I've patched it to be 0.
I'm not yet sure if device 1 becomes 0 if there's no SD card though, but it'll suffice for the need I'm addressing.

Maybe note upstream (to make it configurable)?

Quote:

Originally Posted by SCerovec (Post 5963662)

Maybe note upstream (to make it configurable)?

It was just me misunderstanding what was going on.

It's sorted now! I've uploaded v2019.04-rc2 and have tested it with my Orange Pi Plus 2E. I've now got HDMI console working and am using X11.

I tried adding those U-Boot configurations you'd asked for, but they needed some more work.
The new SD card images have a single FAT partition - having more than 1 partition is a pain, and is likely to get broken if people faff around with the partition table anyway.
The only thing I'd like to get working is to be able to dump this SD card image to the eMMC, and have the possibility to live without the SD card (you'd still need it to boot the latest U-Boot, but once you'd installed the OS you could overwrite U-Boot on the eMMC).
To make it work, I had to configure U-Boot to look for its environment on 0:0 which means it doesn't work if there's no SD card.
The other option is to switch it back to saving the environment on to the MMC (meaning not writing it to a FAT file system: I believe the previous version of U-Boot wrote it to the eMMC directly), which should allow us to do that. I'm not in the mood for more U-Boot work now though!

Good work! Glad you've pushed it thru!

OTOH, ideally the u-boot would be aware what it booted from and store the environment to that media:
if eMMC is present -> eMMC
if booted from SD -> SD
if setup booted from SD -> to eMMC if present otherwise to SD if that makes any sense?
if setup booted from USB -> to eMMC, or SD card or USB in that order of preference

kind of (or the like)

Quote:

Originally Posted by SCerovec (Post 5964157)

Sounds like a feature request for U-Boot!
I doubt U-Boot is able to know where it was originally loaded _from_ unless the ROM code passes that info to the SPL and into U-Boot proper.

So far only the system can discern that - and act upon the fact:scratch:

right?