Accessing u-boot variables from linux

Discuss development on Bubba
MouettE
Site admin
Posts: 271
Joined: 06 Oct 2011, 19:45

Re: Accessing u-boot variables from linux

Post by MouettE » 19 Dec 2012, 11:03

pompopom wrote:Are you the one that wrote the Wiki "Install_Bubba_on_RAID-1_volumes"?

First of all: great job you've done, really helpfull and clear from start to bottom!
That's me indeed ! thanks a lot, it's always nice to know your work is useful to others ;-)

As for the u-boot stuff, I suggest you dump the content of your mtd devices (cat /dev/mtdx > mtdx.bin) and open it into your favorite hex editor. That's how I found the two environment zones of u-boot, and consequently the offsets and the sizes (the values are stored in plain ASCII, search for 'baudrate' for example) ; there are two zones (typical U-Boot, but I can find the page I read about that subject), filled with zeros between the last variable and the end of the data size. The rest of the sector is filled with FF. I suppose the flash sector size should be equal to the erasesize attribute of the /proc/mtd content.

Hope this will help, and remember that without a serial console, you may have difficulties if the system doesn't boot anymore. I had plans to try make a rescue USB disk with access to the u-boot environment, but after a couple of hours, I gave up somewhere between device-tree-compiler and buildroot ...

pompopom
Posts: 50
Joined: 13 Dec 2012, 16:45

Re: Accessing u-boot variables from linux

Post by pompopom » 29 Mar 2013, 03:50

Hi Mouette and others reading this,

First of all sorry for not coming back to this subject earlier. It have been some busy months (work, at home, hospital, *skip-details-mode*) Anyway 2 days ago I restarted searching for a solution to this subject. As a warm-up I installed owncloud v5 on the B3 and it seems to work pretty well, but while doing the config I felt more and more the need of first putting everything into RAID :-)

So I got to the point where I left off few months ago.

And guess what? We're really getting to something here! whii :-) Let me summarize my steps:
First I did the export to bin files you proposed in previous post, but honestly it wasn't really getting me any further at first glance, I was more ore less able to find what you where explaining about the sectors and the FF's and 0's but that's about it.
So I digged down into the stack of papers on my desk to find my notes from few months ago and found i had been writing something I read on the net (http://labs.isee.biz/index.php/How_to_m ... _userspace)
That's when I tried the following:

Code: Select all

root@b3:~# cat /etc/fw_env.config
# MTD definition for B3
# MTD device name       Device offset   Env. size       Flash sector size
/dev/mtd1               0x000000        0x010000        0x010000
So instead of entering the mtd0 with an offset I go straight to mtd1. Plain and simply because:

Code: Select all

root@b3:/mnt/b3# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 000c0000 00010000 "u-boot"
mtd1: 00020000 00010000 "env"
mtd2: 00120000 00010000 "data"
should mean that the device "knows" where my mtd1, containing the environment, is located. That is if I understand the docs I have been reading correctly.
Since then fw_printenv outputs the following:

Code: Select all

root@b3:~# fw_printenv
bootdelay=1
baudrate=115200
preboot=
loadaddr=0x800000
console=ttyS0
bootfile=uImage
flashfile=u-boot.kwb
installfile=install.itb
setdiskargs=setenv bootargs root=$diskdev console=$console,$baudrate 
serial=${serial#} key=$key button=$button
setbootargs=setenv bootargs root=$rootdev rw console=$console,$baudrate 
$othbootargs
usbbootroot=/dev/sda1
usbbootdev=usb 0:1
usbboot=usb start; setenv diskdev $usbbootroot; run setdiskargs; 
ext2load $usbbootdev $loadaddr /boot/$bootfile; bootm
usbflashdev=usb 0:1
usbflash=fatload $usbflashdev $loadaddr /install/$flashfile && sf probe 
0:0 && sf erase 0 80000; sf write $loadaddr 0 $filesize
satadev=sata 0:1
sataroot=/dev/sda1
sataboot=setenv diskdev $sataroot; run setdiskargs; ext2load $satadev 
$loadaddr /boot/$bootfile; bootm
usbinstallroot=/dev/ram0
usbinstalldev=usb 0:1
usbinstall=usb start; setenv diskdev $usbinstallroot; run setdiskargs; 
fatload $usbinstalldev $loadaddr /install/$installfile; bootm
bootalt1=run sataboot || reset
bootalt2=run usbinstall || run usbflash || run sataboot || reset
stdin=serial
stdout=serial
stderr=serial
button=0
bootcmd=run sataboot || reset
ethact=egiga0
ethaddr=00:22:02:00:1f:02
eth1addr=00:22:02:00:1f:03
serial#=5067
key=RwvQ3pqpmUdIO/yssGQMeP8DulA=
That is what should be expected. Correct? If I understand your Wiki correctly the next step is to simply tell the environment to boot from /dev/md1 which is the "bubba root" raid-volume created earlier.

Now, if I understand what fw_printenv is telling me, I need to change "sataroot" and not "diskdev" just like you did.

Code: Select all

sataroot=/dev/sda1
sataboot=setenv diskdev $sataroot; run setdiskargs; ext2load $satadev

But I'm not sure about that. Where does my doubt come from: In the output I don't have a variable declaration for "diskdev" but the variable is nevertheless used in:

Code: Select all

setdiskargs=setenv bootargs root=$diskdev console=$console,$baudrate 
:?
Or is diskdev a "new" variable that you have added instead of modifying for the sake of making this RAID-1 setup work?

Or maybe there is still something wrong with my environment size in the fw_env.config which makes fw_printenv not "printing" all the variables? Sidenote: I played a bit with the environment size, for as far as I was able to determine size from the .bin files earlier, but it never gave me any decent output... I'll continue my investigation this evening. If by that time you have any ideas or extra info, please feel free to share them :-)

Thx for your time & effort!

Regards,
Koen

EDIT:
I re-analyzed the output from fw_printenv and my conclusion is that I definitely need to set sataroot. From what I understand about it:
On normal boot "sataboot" is called

Code: Select all

bootalt1=run sataboot || reset
which is:

Code: Select all

sataboot=setenv diskdev $sataroot; run setdiskargs; ext2load $satadev $loadaddr /boot/$bootfile; bootm
First thing that's done in here is setting the diskdev with variable:

Code: Select all

sataroot=/dev/md1
then it runs "setdiskargs". diskdev has just been set in previous routine,

Code: Select all

setdiskargs=setenv bootargs root=$diskdev console=$console,$baudrate serial=${serial#} key=$key button=$button
the other variables are fixed in memory

Code: Select all

console=ttyS0
baudrate=115200
serial#=5067
key=RwvQ3pqpmUdIO/yssGQMeP8DulA=
after that it continues with ext2load with pre-defined variables:

Code: Select all

satadev=sata 0:1
loadaddr=0x800000
bootfile=uImage
As a sidenote to this: In your wiki you say that the usb rescue disk no longer works. What if we also set the usbbootroot variable to /dev/md1 instead of /dev/sda1 ?

*searching for my TX10 screwdriver*

EDIT2: Found my TX10 :-)
So I swapped the disks, crossed my fingers, and powered on my B3. After a few minutes a steady blue led... I was kind off disappointed as the wiki mentioned a fast blinking led due to degraded raid array. Opened up firefox, and browsed to the home page.
I was happy to see the webinterface work as usual, so I did my basic config and returned to shell.
With cat /proc/mdstat I was able to see that everything was working as expected (besides the non-blinking LED) So I continued the wiki and plugged my external disk, re-partioned and added it to the raid-array.

Code: Select all

root@b3:~# cat /proc/mdstat
Personalities : [raid0] [raid1] 
md1 : active raid1 sdb2[2] sda2[0]
      10490368 blocks [2/1] [U_]
      [==>..................]  recovery = 11.1% (1167744/10490368) finish=2.9min speed=53079K/sec
      
md2 : active raid1 sdb3[2] sda3[0]
      1052160 blocks [2/1] [U_]
      	resync=DELAYED
      
md3 : active raid1 sdb4[2] sda4[0]
      1941913024 blocks [2/1] [U_]
      	resync=DELAYED
      
md0 : active raid1 sdb1[1] sda1[0]
      56128 blocks [2/2] [UU]
      
unused devices: <none>
And voila a B3 fully on raid :-)

So there are some differences between B2 and B3 but not that many.

Thx again Mouette for the effort you have put in your pioneering ;-)
If you like you can update your wiki page with this knowledge

MouettE
Site admin
Posts: 271
Joined: 06 Oct 2011, 19:45

Re: Accessing u-boot variables from linux

Post by MouettE » 13 Jun 2013, 04:46

I just ordered my B3 (and a serial adapter ;-) ), so I will be able to update my howto for the B3 with your elements. Stay tuned ...

pompopom
Posts: 50
Joined: 13 Dec 2012, 16:45

Re: Accessing u-boot variables from linux

Post by pompopom » 19 Jun 2013, 08:08

Hi Mouette,

well everything still seems to be working fine since I made the changes.

Just one strange thing happened: after first reboot, when I had the B3 in full-raid, I checked the Raid status with cat /proc/mdstat and found the Raid broken. So I rebuild the raid and rebooted to see if this was happening again. But it didn't... ?

Just wanted to mention before you sit back in your chair thinking everything is in RAID but in fact it isn't :-)

Too bad the LED doesn't blink when the RAID is broken, just as you mention that for B2. But I guess that can be fixed (when I get more time at hands)

regards.

Ubi
Posts: 1547
Joined: 17 Jul 2007, 09:01

Re: Accessing u-boot variables from linux

Post by Ubi » 19 Jun 2013, 14:53

Yes, sometimes software RAID over eSATA gets degraded. But the rebuild kicks in automagically and takes only a few hours. In the mean time both disks are accessible and all but the most recent changes are identical on both disks. In other words: a software raid1 thats out of sync is a non-issue for normal people. If your files are too delicate to cope with this you should not be running RAID1 over rsync anyway :D

pompopom
Posts: 50
Joined: 13 Dec 2012, 16:45

Re: Accessing u-boot variables from linux

Post by pompopom » 20 Jun 2013, 08:47

Ubi wrote:Yes, sometimes software RAID over eSATA gets degraded. But the rebuild kicks in automagically and takes only a few hours. In the mean time both disks are accessible and all but the most recent changes are identical on both disks. In other words: a software raid1 thats out of sync is a non-issue for normal people. If your files are too delicate to cope with this you should not be running RAID1 over rsync anyway :D
Where does rsync come into play in the RAID1 story?

Ubi
Posts: 1547
Joined: 17 Jul 2007, 09:01

Re: Accessing u-boot variables from linux

Post by Ubi » 20 Jun 2013, 10:53

Ah yes. Sorry, mental knot. I meant eSATA. My mind was still working on another thread that involved rsync.

Post Reply