uboot 2016.09-1 whats new

[summers]

Hi,

Whats new in the latest (2016.05-1) uboot? E.g. its a hassle updating this on my NSA325, so what changes do you get with the update. Has any of the default enviroment variables changed?

Thanks,

David.

[cmsigler]

Hi,

I chased down the git repository from the commit in the package repository:

ALARM packages. Search for "nsa325." Click on "Source Files" at right on uboot-nsa325 page.

Package log. Click on latest commit message.

Repository pulled from here. Click on latest commit message at top of file/directory listing.

"Bring configs up to date with 2016.05." I think this lists all the changes you're looking for. HTH.

Clemmitt

[summers]

Ta. So as far as I can see, enabling dhcp and usb access from uboot.

Guess I may use those, so I'll unpack and install by hand.

[summers]

And for others interested, they havn't changed the enviroement variables since the last version of uboot. So you only have to flash the uboot image, and not the env variables. So you don't need to worry about setting the ethernet mac address again.

[summers]

Oh yes, is there a reason to get the eth mac address using:

$this->bbcode_second_pass_code('', 'mac=$(fw_printenv | grep ethaddr | cut -d= -f2)')

rather than using:

$this->bbcode_second_pass_code('', 'mac=$(ip a show dev eth0 | sed -ne 's/ *link\/ether \([0-9a-f:]*\) .*/\U\1/p')')

E.g. as far as I can see, linux gets the mac address directly from the device, and so the value in ip a should be correct, what is in the uboot env variables is just what was set there ...

[moonman]

There really isn't any changes. I just brought the package up to date with upstream. USB was already enabled before, but certain config options had to be moved from *.h to Kconfig files. Environment is exactly the same.
EDIT: I should probably be more clear: there aren't any changes to the environment or new features but multiple bug fixes from upstream.

[summers]

Thanks moonman - yes that makes sense. Thanks for the update.

Looking at the install script and why it causes me so much hassle, I wonder if it can be simplified. Now it looks like its a general script used on many of these devices where the uboot lives in flash. Would my mind if I had a go of simplify and improving logic in the script?

E.g. the mac adddress above can be simiplified to a single external command, that I think will work on all devices, to:

$this->bbcode_second_pass_code('', 'mac=$(tr 'a-z' 'A-Z' < /sys/class/net/e*/address)')

Should be able to get a correct mtdparts variable from /proc/mtd, etc.

Anyway I'll drop code in this thread as its written.

Note added later: The code above will fail when there is more than one ethernet card so suggests somenthing like this first:
$this->bbcode_second_pass_code('', 'ls /sys/class/net/ | head -1') - but the first listed card isn't necessarily the prime, on my desk top : enp0s18f2u3i1 - oops that a beagle bone black with etherner under usb gadget, the primary ethernet is enp4s0 - so bit more thought needed.

[moonman]

Mtdparts can be put in uEnv.txt for any specific usecase so you don't have to deal with it every uboot update. As far as taking the max address from ip command I can see one problem with that. As far as retrieving mac address from ip I don't wan to overcomplicate things to add more points of failure to things like uboot. It seems reasonable though, I will test your suggestion to see if i can find any problems with it.

[summers]

AH yes- good thought on mtdparts in uEnv.txt - I'l impliment that now.

This gets close to generating mtdparts env varible, on the current running kernel:

$this->bbcode_second_pass_code('', 'sed -ne 's/mtd.*: \([0-9a-f]*\) [0-9a-f]* \"\(.*\)\"/0x\1\(\2\)/p;' < /proc/mtd')

Sould be similar code to find which partition 0xc0000 is in, and if its at least 0x20000 long past 0xc0000. In which case that is where the env varibles should be written.

[summers]

OK try this code on as many kirkwood devices as possible, it just prints out what to set things to

$this->bbcode_second_pass_code('', '
#!/bin/bash

mac=$(tr 'a-z' 'A-Z' < /sys/class/net/eth0/address)
lastendoffset=0
mtdparts="mtdparts=orion_nand:"
for mtd in /sys/class/mtd/mtd*;
do
if [ "${mtd: -2:2}" != "ro" ]; then
read offset < ${mtd}/offset
printf -v offsethex "0x%X" ${offset}
read size < ${mtd}/size
printf -v sizehex "0x%X" ${size}
read name < ${mtd}/name
read flags < ${mtd}/flags
endoffset=$((${offset}+${size}))
# echo $mtd $offset $size $endoffset $name
if [ ${lastendoffset} -gt 0 ]; then
mtdparts="${mtdparts},"
fi
if [ $offset -eq $lastendoffset ]; then
mtdparts="${mtdparts}${sizehex}(${name})"
else
mtdparts="${mtdparts}${sizehex}@${offset}(${name})"
fi
# partion starts right place, big enough, and writeable
if [ $offset -eq 0 -a $endoffset -ge 524288 -a $(( ${flags} & 0x400 )) -ne 0 ]; then
# this assumes that the /dev name is the same as /sys
# its would be better to work from major minor numbers
ubootpart=/dev/${mtd#/sys/class/mtd/}
read ubooterase < ${mtd}/erasesize
fi
# partition starts before where we want, finishes after, and is writeable
if [ $offset -le 786432 -a $endoffset -ge 917504 -a $(( ${flags} & 0x400)) -ne 0 ]; then
ubootenvpart=/dev/${mtd#/sys/class/mtd/}
ubootenvoffset=$((786432-${offset}))
printf -v ubootenvoffsethex "0x%X" ${ubootenvoffset}
read ubootenverase < ${mtd}/erasesize
printf -v ubootenverasehex "0x%X" ${ubootenverase}
fi
lastendoffset=${endoffset}
fi
done

echo mtdparts=${mtdparts}
echo uboot ${ubootpart}
echo fw_env.config ${ubootenvpart} ${ubootenvoffsethex} 0x20000 ${ubootenverasehex}
echo ethernet mac ${mac}
if [ $ubooterase -eq 131072 ] ; then
echo clear uboot flash_erase ${ubootpart} 0 4
echo write uboot nandwrite ${ubootpart} /boot/uboot-nsa325.kwb
fi
if [ $ubootenverase -eq 131072 ] ; then
echo clear uboot env flash_erase ${ubootenvpart} ${ubootenvoffsethex} 1
echo write uboot env nandwrite -s ${ubootenvoffsethex} ${ubootenvpart} /boot/uboot-nsa325.env
fi
')

Granted it far more verbose than the current install.

It takes parameters from /sys

Tries to keep the mtd partitions the same as currently, and sets up fw_env.config for the current partitions.

Its reasonably robust (but some minor things like the mtd name been the same in /dev and /sys/class/mtd - really should check major and minor numbers). Also assumes that the ethernet card is eth0 - so systemd isn't doing any renaming ....

Interesting tried to see what it would do with the standard install:

http://de3.mirror.archlinuxarm.org/os/n ... arm.tar.gz

where usb_key_func.sh.2 still uses mtdparts=nand_mtd:

Now that mtdparts is totally ignored when kernel boots, it uses another version, that is reasonable for the nsa325. Can't work out where it comes from, but suspect its in the flattened device tree.

Anyway conisder code above RFC - what do others think?

On my NSA325 it gives:

$this->bbcode_second_pass_code('', '
mtdparts=mtdparts=orion_nand:0xC0000(uboot),0x40000(uboot_env),0x80000(old_uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2)
uboot /dev/mtd0
fw_env.config /dev/mtd1 0x0 0x20000 0x20000
ethernet mac XX:XX:XX:XX:XX:XX
clear uboot flash_erase /dev/mtd0 0 4
write uboot nandwrite /dev/mtd0 /boot/uboot-nsa325.kwb
clear uboot env flash_erase /dev/mtd1 0x0 1
write uboot env nandwrite -s 0x0 /dev/mtd1 /boot/uboot-nsa325.env
')