uboot 2016.09-1 whats new

[summers]

Yes - turns out the default mdt partitions are in the device tree, take a look in:

$this->bbcode_second_pass_code('', '/proc/device-tree/mbus\@f1000000/nand\@012f/')

And looks like that location is common for all kirkwood devices:

http://lxr.free-electrons.com/source/arch/arm/boot/dts/kirkwood.dtsi

And set up for the NSA325 in:

http://lxr.free-electrons.com/source/arch/arm/boot/dts/kirkwood-nsa3x0-common.dtsi

So general for NSA3xx devices

Also wonder - would it be more reliable to get the ethernet mac from the device tree:

$this->bbcode_second_pass_code('', 'od -t x1 /proc/device-tree/ocp@f1000000/ethernet-controller\@72000/ethernet0-port\@0/local-mac-address')

Interesting 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).

Guess question for install, is does stock NSA3xx set the linux eth mac from the uboot ethadr env variable, as stock uboot doesn't do device tree IIRC. Can't say I tempted to flash back to the original uboot to find out.

[znark]

For what it’s worth, just confirming that I could upgrade my NSA325 from an older Arch U-Boot (from last year) to U-Boot 2016.05-1 simply by installing the "uboot-nsa325" package using pacman (had previously flashed it manually). It seems to work fine.

Also, the upgrade from an older "linux-kirkwood" (4.1.0-1) kernel to the latest "linux-kirkwood-dt" (4.7.0-1) device tree kernel went through flawlessly.

I'm booting from a bare ext4 boot partition into a two-disk RAID0/LVM2/ext4 root.

[summers]

Hi znark,

Yes, my problem is/was that it rewrites how linux looks form the mtd nand partitions. The new uboot seems to assume you want to set up a rescue partition. Me, I wanted to keep stock firmware, in case I ever want to boot back to stock. Hence I prefer to keep the original mtd partitions.

Out of interest though, how did you update from the install image of arch, to the new arch uboot? looks to me like that has difficulties, as the install of arch to stock hardware, keeps the original stock mtd partitions - and you can't update without a reboot ...

David.

[hfrjkse]

I've installed fresh Arch on Pogo E02 and then I decided to upgrade also uBoot and as you may guess - something went wrong. After connecting to the serial port I'm getting:

[ 15.508858] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 15.524832] sd 0:0:0:0: [sda] Write Protect is off
[ 15.542105] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 15.577412] sda: sda1 sda2
[ 15.592302] sd 0:0:0:0: [sda] Attached SCSI removable disk
ERROR: device '0cd00ea9-8374-44ff-8b5f-053260dfb796' not found. Skipping fsck.
ERROR: Unable to find root device '0cd00ea9-8374-44ff-8b5f-053260dfb796'.
You are being dropped to a recovery shell
Type 'exit' to try and continue booting
sh: can't access tty; job control turned off
[rootfs ]# blkid
/dev/sda1: UUID="0cd00ea9-8374-44ff-8b5f-053260dfb796" TYPE="ext3"

Can someone help me with this? I know that it may something to do with partuuid, but I spent a few hours trying to fix it and I still can't...

EDIT:
Just changed uEnv.txt to root=LABEL=myLabel
Now it's ok

[moonman]

Is the rootfs ob the same partition as the kernel? That looks like a partuuid for a guid partition table, are you usyng hybrid mbr by any chance?
Your solution is valid though, there shouldn't be any problems unless you name another partition the same.

[hfrjkse]

Well, this is only fresh install made step by step using archlinuxarm manual: https://archlinuxarm.org/platforms/armv ... 2-pinkgray
and then your u-boot was flashed. I didn't make any changes apart from uEnv.txt included into the boot folder.

I'm confused with uuid and partuuid stuff so eventually decided to use label instead. Changing label is simple and quick enough, so I can use various flashdrives and one backup fille for all of them - no need to edit uEnv.txt to match uuid of the current flashdrive.

[summers]

As I recall the problem was that the kernel without modules doesn't understand UUID (and I thought LABEL) so as these were passed to the kernel, it tried to mount root before it was able to access the UUID numbers.

Hence why it suggested that you use PARTUUID, which kernel knows at boot time.

This said though you sould be able to use

root=/dev/sda1

Which was the old way of doing it, and not as robust - but should get you into a working arch ...

Hope that helps.

P.S. Ah just read you post more closly. So LABEL does work in the kernel before modules ....

P.P.S. And you should be able to get PARTUUID using:

$this->bbcode_second_pass_code('', 'ls -l /dev/disk/by-partuuid/')

[hfrjkse]

@summers
Yes, label way works well and I think that I'll be using label rather than uuid or partuuid for the reasons I mentioned above.
Thanks for quoting the command ls -l /dev/disk/by-partuuid/ though. Is there a way to change the partuuid on existing flashdrive? If not, then label wins again, because I can label any flashdrive and then restore backed up image if necressary without worring about changing uEnv.txt to match new flashdrive partuuid.

Just an thought - wouldn't be enough for bootloader to kick on and load image if it sees uEnv.txt in boot folder or even just only "boot" folder on flashdrive or HDD?

[moonman]

You've got the sequence wrong. Uboot finds kernel and loads it - all is fine there. But uboot has to tell the kernel what partition the rootfs is on So the problem here if you /dev/sdXY approach, the kernel may initialize the drives in a different order compared to the uboot.

[hfrjkse]

So 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...