uboot 2016.09-1 whats new

[moonman]

$this->bbcode_second_pass_quote('hfrjkse', 'S')o obviously uBoot knows where (using either label/uuid or partuuid) he found the rootfs. Can uBoot pass this information to the kernel then? Again - just a thought...

[hfrjkse]

Right, but you have to first read partuuid, then edit uEnv.txt. Then when your flashdrive fails and you restore your backup image to another flashdrive, you have to do it again. Of course it's simple enough for most users, but it could be even simpler. uBoot is looking for existence of uEnv.txt in boot folder, then if it finds it, passes this information to the kernel without looking for "root=...." sentence. If uEnv.txt is there - this is your rootfs flashdrive - go ahead with booting. Another idea -an option like "root=me" - something universal, something that would work when you restore backup image on any new flashdrive without need to undertake any extra actions.

Don't get me wrong - current version of your uBoot is a milestone in Pogo history anyway. This is only an idea to improve it further - if it is possible of course.

[summers]

@hfrjkse

What happens is that there are two levels, uboot, and kernel. Now each of those independently needs to know where the boot files, and root file system, is.

Now if you check the enviroment variables set up in typical modern uboot, you see it is set up to effcency scan all partitions it can find (typicaly on usb, sd*, and on these embedded board flash memory). Uboot then loads the uEnv.txt file, kernel, initramfs, device tree - all from where it finds a viable file system.

Uboot then tries to boot linux, it passes a command line to linux, that sets up thing like the console output, and where the root file system is. Now problem with the root file system, is two fold. 1) root may not be where the boot files are, and historically on linux these where often sepearte partitions (when lilo could only access the start of HDD). 2) the kernel has many an varied ways of identifying the root file system, labels, UUID, PARTUUID, device.

So as these two are so different, uboot boot directory, and kernel root fs, is why they get set up separately.

As to can PARTUUID (and UUID) change - we'll not easlly - thats the idea. So when you have a file system on a device, you have a unique way of identifying the file system. Now this doesn't say its impossible, I think if you do a byte my byte copy of the entire disk then you would copy the PARTUUID and UUID. (e.g. think "dd if=/dev/sda of=/dev/sdb" - and commands like that, obviously changing sda and sdb to be approriate drives).

So how modern uboot is set up, by reading uEnv.txt from the boot directory, gives a chance to set up each file system you boot from, so it defines its own root.

So say you set up a rescue USB memory stick, with the right file structure on it. Now having created this on a 3rd computer, you can then idenifty the PARTUUID of the nominal root filesystem, then add that information to uEnv.txt. Now the beauty of the system, when you unplug to USB, and move it to the target machine, the PARTUUID don't change.

Then that the target system uboot, scans filesystems, means it can find the USB, read the uEnv.txt, and know where that boot partition wants its root fs to be.

So actually the current system, is actually very flexable.

Guess if I have a hassle with the current system, is using the PARTUUID to identify the root. Problem is that PARTUUID isn't really used elsewhere, and not all commands work everywhere (e.g. blkid) - so it looses out by not being well known.

[summers]

$this->bbcode_second_pass_quote('', 'I')nteresting thought that the kirkwood.dtsi says that the mac address should be set in bootloader - as is done in uboot, so maybe the ultimate source of mac address is in the uboot env variables. (however no "fdt boardsetup" in uboot env - and I though this was needed to populate the device tree with objects at uboot time).

[hfrjkse]

After a few days break, I get back to my work with my pink devil today and found it is not booting properly.

- when there is no extra FAT32 flashdrive in front socket (only flash drive with arch at the bottom back USB) it boots ok
- when there is an extra flash drive in front socket and you use "reboot" command it boots ok
- when there is an extra flash drive in front socket and you plug/unplug power plug - it does not boot, no green light on front panel

I tried to change uEnv from label to PARTUUID - same story.

Any advice? I'll solder back serial adapter to the pcb to investigate further, but only if necessary.

[summers]

Do several of the usb sticks have file systems with a /boot on them?

If so could be uboot is accessing different ones depending on what is plugged in where, and then reading uEnv.txt from that partition ....

[hfrjkse]

Of course not - there is no even boot folder on this front one, not mention about uEnv.txt file. When unplugged - booting as expected. Only this one flashdrive except the system one is plugged in.

[summers]

Sounds to me like uboot going wrong then, can you access the uboot env variables, and see how it scans the network?

[moonman]

Fire up netconsole instead of opening up the device and see why it doesn't boot

[hfrjkse]

I would set it up, but your post is not precise enough for not advanced linux user like me. Should I use direct RJ45 cable to PC or through the router? If through the router, then I'd have to change all local IP settings I suppose? Using direct connection I'm only getting eth0:0: ERROR while getting interface flags: no such device