2017.07- 2024.10 U-Boot Kirkwood

bodhi,

Is there anyway to remove the ethaddr setting from uboot.2014.07-tld-2.environment.bodhi? The reason I ask, last night I flashed an E02 to the latest uboot and after I rebooted it had the ethaddr from the environment file and not my true MAC ID. I tried fw_setenv ethaddr 'xx:xx:xx:xx:xx'' (acutal values not shown) and it gave me an error something "configuration cannot be changed". Also, I booted with uEnv.txt in boot which worked but u-boot also ignored my setting of ethhaddr=xx:xx:xx:xx:xx:xx in uEnv.txt at least that is how it appears when I did an ifconfig. I didn't want to crack open the plug for serial connection but is that my only alternative at this point to reset the ethaddr?



Edited 1 time(s). Last edit at 03/10/2015 07:16PM by LeggoMyEggo.

You should be able to change it. If not, it's either mtd0 is not defined, or it is loaded as readonly by the kernel. Which u-boot and kernel?

Btw, The default is set to a randomly generated local MAC address which is perfectly ok to use if it cannot be changed. But the problem should be fixed regardless.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> You should be able to change it. If not, it's
> either mtd0 is not defined, or it is loaded as
> readonly by the kernel. Which u-boot and kernel?
>
> Btw, The default is set to a randomly generated
> local MAC address which is perfectly ok to use if
> it cannot be changed. But the problem should be
> fixed regardless.


uboot.2014.07-tld-2.pogo_e02.bodhi and linux-3.18.5-kirkwood-tld-1-bodhi.tar (over existing 3.17 rootfs).

I am not sure if mtd0 is defined or not. I'll have to check.

I prefer to keep the stock MAC ID as I have a couple black PP - 1 E02 and 1 Pro. - and the stock MAC ID helps keep them straight as I have my MAC ID's mapped to my router and those ID's have corresponding static IP addresses and hostnames.

If I can't do this from the OS level, is it guaranteed to be changeable at the serial console? I have to admit, I was kinda hoping that I would have at least one PP that I didn't have to crack open as that would indicate a little bit of acquired skill and Linux mastery :)



Edited 2 time(s). Last edit at 03/10/2015 08:24PM by LeggoMyEggo.

LeggoMyEggo,

>
> If I can't do this from the OS level, is it
> guaranteed to be changeable at the serial console?
> I have to admit, I was kinda hoping that I would
> have at least one PP that I didn't have to crack
> open as that would indicate a little bit of
> acquired skill and Linux mastery :)

You can also change it in netconsole since you're running the latest u-boot, no need to connect serial console :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi

So i tried to load it by tftp methode by this way :

tftp 0x800000 uboot.kwb (i rename the file)
then
go 0x800200

and nothing happens.

I found on the net a uboot ( version 2011.12 on this web site http://lacie-nas.org/doku.php?id=uboot in the ftp link) its a binary runable file and not the kwb file (both existe but i tested the bin one)

tftp 0x80000 uboot.bin
go 0x80000

and its works.

Val532 Wrote:
-------------------------------------------------------
> @bodhi
>
> So i tried to load it by tftp methode by this way
> :
>
> tftp 0x800000 uboot.kwb (i rename the file)
> then
> go 0x800200
>
> and nothing happens.
>
> I found on the net a uboot ( version 2011.12 on
> this web site
> http://lacie-nas.org/doku.php?id=uboot in the ftp
> link) its a binary runable file and not the kwb
> file (both existe but i tested the bin one)
>
> tftp 0x80000 uboot.bin
> go 0x80000
>
> and its works.

Ah. Perhaps this is what need to be configured ( info on that site)::

PATH=/usr/local/x-tools/arm-2010q1/bin/:$PATH CROSS_COMPILE=arm-none-eabi- make netspace_v2_config

I'll take a look at the build again.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Sorry but it's not the netspace_v2 but the D2 network v2.
And in this web site i have not found d2-network_v2_config or something else.

Val532 Wrote:
-------------------------------------------------------
> Sorry but it's not the netspace_v2 but the D2
> network v2.
> And in this web site i have not found
> d2-network_v2_config or something else.

So you do indeed have the D2 Net V2, not the Nespace V2. That's what I did built the image for previously. This D2Net_V2 variant has arcNumber 2203.

OK. Let me rebuild a bin file and let you try.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@Val532,

Try this attached bin:

tftp 0x80000 uboot.2014.07-tld-3.d2net_v2.bin
go 0x80000

I'm not sure that it's going to work chainloading from a much older u-boot to this version. But it's worth a try :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 03/11/2015 05:01AM by bodhi.

bodhi Wrote:
-------------------------------------------------------
> @Val532,
>
> Try this attached bin:
>
>

> tftp 0x80000 uboot.2014.07-tld-3.d2net_v2.bin
> go 0x80000
>

>
> I'm not sure that it's going to work chainloading
> from a much older u-boot to this version. But it's
> worth a try :)

Ok thanks I'll test is tonight.

@bodhi

So I tried to load your bin and it does not work.
But I can confirm that the bin file that I retrieve from the previous site works.

But probably a good news for me the result of md ff00003c is :

ff00003c: 00000121 e3a00000 e59f222c e5921000    !.......,"......
ff00004c: e2013008 e3530000 1a000002 e3811008    .0....S.........

Val532,

Try UART bootng with this attached kwb file, the bin binary won't work with UART.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 03/11/2015 04:43PM by bodhi.

bodhi Wrote:
-------------------------------------------------------
> bodhi Wrote:
> --------------------------------------------------
> -----
> > Zyxel Nsa325 & 320 users,
> >
> > Here are the latest NSA325 and NSA320
> > U-Boot-2014.07 for testing before release.
> These
> > u-boot images incorporated all of the latest
> > features as in other Kirkwood u-boots in the
> first
> > post.
>
> Anybody have run this on NSA320? I'd like to have
> feedbacks before pushing out to GitHub. I've
> tested the NSA325 version, but I don't have the
> NSA320.

Works fine for me on NSA320. Just booted from USB stick 3.18.5-kirkwood-tld-1 kernel and rootfs.

AA666,

> Works fine for me on NSA320. Just booted from USB
> stick 3.18.5-kirkwood-tld-1 kernel and rootfs.

Thanks for confirming.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi

Hi, i test your file, but on my system it does not work.

root@debian:/media/usb# ./kwboot -t -B 115200 /dev/ttyACM0 -b uboot.2014.07-tld-                                                                                        3.d2net_v2.kwb
Sending boot message. Please reboot the target.../
Sending boot image...
  0 % [+xmodem: Protocol error
root@debian:/media/usb#

I think my cable is not good.

Val532,

Try the same method that we use for Pogo V4: When you see that "xmodem Protocol error", up arrow to recall the kwboot command and execute it again. Repeat this as many times as you can until the handshake is completed successfully.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Val532,

I've just noticed that you did not use the option -p in your kwboot. It should be used because it is a NAND version. Sorry, I should have mentioned that.

root@debian:/media/usb# ./kwboot -t -B 115200 /dev/ttyACM0 -b uboot.2014.07-tld-3.d2net_v2.kwb -p

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> Val532,
>
> I've just noticed that you did not use the option
> -p in your kwboot. It should be used because it is
> a NAND version. Sorry, I should have mentioned
> that.
>
>

> root@debian:/media/usb# ./kwboot -t -B 115200
> /dev/ttyACM0 -b uboot.2014.07-tld-3.d2net_v2.kwb
> -p
>

Ah ok, i will test that in few day.

I’ve updated the instruction in the 1st post to include the NSA325 and NSA320 u-boot-2014.07-tld-3 images.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I had a free afternoon, so thought I would play with installing Jesse
and the latest bodhi uboot (2014.07-tld-2) on one of my test PogoPlug
E02 boxes. Currently, my Pogoplugs are all running Wheezy with the
standard 3.2 kernel and a 2011.12 version of uboot, and although I have
no immediate plans to upgrade, I can see that Wheezy will realistically
have to be upgraded to Jesse in the next year or so. On the whole,
today's upgrade on my test machine was fairly straightforward and
uneventful, thanks to bodhi's excellent instructions. However, the
process did generate a couple questions and a couple comments:

After the install of the new uboot and bodhi's environment, I was unable
to boot to the original NAND-based OS. This was not unexpected, nor do
I deem it particularly detrimental. I figure that I have several USB
thumb or disk drives that are bootable on the box and can think of very
few scenarios where the ability to boot to the original OS would be
necessary. But just curious: Is there any way to boot to this OS without
reinstalling an older uboot should I ever need to do so?

I was dismayed to see I seem to have lost all control of the front LED
with the new uboot. I was expecting fuller control, but instead of the
LED lighting up yellow and being somewhat controllable (for instance,
solid-on vs. flashing worked) via manipulating the contents of
/sys/class/leds/plug:green:health/trigger from Wheezy/2011.12, on Jesse/
2014.07 it now lights up solid green but attempts to control it via
/sys/class/leds/status:green:health/trigger, have no effect. Further,
there are a lot more "status:white:left*" (and right*) entries in
/sys/class/leds that I don't understand. I can post a more complete set
of uboot environment info if it would be helpful, but before I do so can
anyone suggest what may be wrong? Perhaps I simply don't understand how
to control this led.

I wanted to be able to boot to either the new Jesse load (arcNumber 3542,
machid dd6) or Wheezy (vanilla 3.2 kernel) (arcNumber 2097, machid 0x831)
without having to reconfigure the uboot env. The way I accomplished this
was to create a /boot/uEnv.txt file on each pluggable device, with the
applicable machid in it. (arcNumber doesn't seem to matter -- I leave it
as 3542 -- as long as machid is explicitly set.) But with uEnv.txt, I
can boot seamlessly into either Wheezy or Jesse.

Another question: I notice that the instructions call for dumping mtd0
to a file via the command "nanddump -nf mtd0 /dev/mtd0", but what can
one do with this file? Wouldn't a better option be:

nanddump --noecc --omitoob -l 0x80000 -f mtd0.uboot.kwb /dev/mtd0
and
nanddump --noecc --omitoob -s 786432 -f orig_envs.img /dev/mtd0

That way you can easily reinstall them using nandwrite (right?). And you
could even do the following to verify the new uboot installed correctly:

nanddump --noecc --omitoob -l 0x80000 -f /tmp/mtd0.uboot /dev/mtd0
cmp /tmp/mtd0.uboot uboot.2014.07-tld-2.pogo_e02.mtd0.kwb

Finally, I'm seeing errors (Unknown command 'mmc' and 'ide') during the
boot process. I realize bodhi says these are normal, but are these
subsystems even available on the E02? Can I just remove the "mmc rescan"
and "ide reset" from the uenv_load string? I've already removed
"run bootcmd_sata" from the boot sequence. Should I remove
"run bootcmd_mmc" as well?

This is more than enough for now. I have some more questions about FDT
kernels, but I'll save that for another time.

Hi restamp,

> After the install of the new uboot and bodhi's
> environment, I was unable
> to boot to the original NAND-based OS. This was
> not unexpected, nor do
> I deem it particularly detrimental. I figure that
> I have several USB
> thumb or disk drives that are bootable on the box
> and can think of very
> few scenarios where the ability to boot to the
> original OS would be
> necessary. But just curious: Is there any way to
> boot to this OS without
> reinstalling an older uboot should I ever need to
> do so?

It might or might not work chainloading the original dockstar u-boot image from Pogo E02 u-boot 2014.07 . On older Pogo E02s it should work. We know that this works with the Pogo V4 (graymanforhire did that). So if you really want to try, then use the nanddump backup for mtd0 to chainload. Please post if you want to do so.

> I was dismayed to see I seem to have lost all
> control of the front LED
> with the new uboot. I was expecting fuller
> control, but instead of the
> LED lighting up yellow and being somewhat
> controllable (for instance,
> solid-on vs. flashing worked) via manipulating the
> contents of
> /sys/class/leds/plug:green:health/trigger from
> Wheezy/2011.12, on Jesse/
> 2014.07 it now lights up solid green but attempts
> to control it via
> /sys/class/leds/status:green:health/trigger, have
> no effect. Further,
> there are a lot more "status:white:left*" (and
> right*) entries in
> /sys/class/leds that I don't understand. I can
> post a more complete set
> of uboot environment info if it would be helpful,
> but before I do so can
> anyone suggest what may be wrong? Perhaps I
> simply don't understand how
> to control this led.

It is all depending on which arcNumber you use for the box. The Pogo E02 can be run with:

- arcNumber 2097 is the reference board, so it is
/sys/class/leds/plug:green:health/trigger

- arcNumber 3542 which is the E02 board, so it is
/sys/class/leds/status:green:health/trigger

If you see "there are a lot more "status:white:left*" then it is not set up correctly. Those are the GoFlex Net LEDs triggers (arcNumber 3089). So either arcNumber is wrong, or the DTB in the FDT rootfs was wrong. If your rootfs is from the mainline wheezy, check to see which do you use, non-FDT or FDT, and most likely that has the wrong machine.

> I wanted to be able to boot to either the new
> Jesse load (arcNumber 3542,
> machid dd6) or Wheezy (vanilla 3.2 kernel)
> (arcNumber 2097, machid 0x831)
> without having to reconfigure the uboot env. The
> way I accomplished this
> was to create a /boot/uEnv.txt file on each
> pluggable device, with the
> applicable machid in it. (arcNumber doesn't seem
> to matter -- I leave it
> as 3542 -- as long as machid is explicitly set.)
> But with uEnv.txt, I
> can boot seamlessly into either Wheezy or Jesse.
>

Excellent use of uEnv.txt! that was the whole intent.

> Another question: I notice that the instructions
> call for dumping mtd0
> to a file via the command "nanddump -nf mtd0
> /dev/mtd0", but what can
> one do with this file? Wouldn't a better option
> be:
>
> nanddump --noecc --omitoob -l 0x80000 -f
> mtd0.uboot.kwb /dev/mtd0
> and
> nanddump --noecc --omitoob -s 786432 -f
> orig_envs.img /dev/mtd0
>
> That way you can easily reinstall them using
> nandwrite (right?). And you
> could even do the following to verify the new
> uboot installed correctly:
>
> nanddump --noecc --omitoob -l 0x80000 -f
> /tmp/mtd0.uboot /dev/mtd0
> cmp /tmp/mtd0.uboot
> uboot.2014.07-tld-2.pogo_e02.mtd0.kwb
>

Yes, absolutely. The nanddump and nandwrite commands were written as backup for one's own box only. But for reuse on different box, it most definitely better to do it the way you stated above. I've thought about updating the instruction (based on JohnW's feedbacks about different nand utils versions on this forum), and you did it for me right there (I knew when you got around to update u-boot, you would have good comments :).

> Finally, I'm seeing errors (Unknown command 'mmc'
> and 'ide') during the
> boot process. I realize bodhi says these are
> normal, but are these
> subsystems even available on the E02? Can I just
> remove the "mmc rescan"
> and "ide reset" from the uenv_load string?

You can set the u-boot env

devices=usb

and the other devices won't be scanned, so it will be less noisy. I left the default envs with all devices so it will work on all boxes.

> I've
> already removed
> "run bootcmd_sata" from the boot sequence. Should
> I remove
> "run bootcmd_mmc" as well?

Yes. The default settings is to cover all Kirkwood boxes.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Thanks for the help, bodhi. You hit the nail squarely on the head with respect to my LED issue: Not paying close enough attention resulted in my blindly using the wrong DTB. But, without you pointing me in this direction, it would have taken me quite a while to figure that one out. BTW, are there any disadvantages to appending the DTB so that it is a part of the uImage and booting it the conventional way if you don't intend to move the filesystem to another architecture?

I'm not particularly interested in (chain-)booting the original OS; was more curious than anything else. But, as long as we're on the subject, any idea why the /dev/mtdblock devices are missing in the Jesse load with the 3.18.5 kernel? Also, I'm curious as to how, and under what circumstances, you issue updates for this kernel.

Another uboot question: Has anyone used the SNTP functionality of the latest uboot, which allows the uboot itself to set the date of the RTC before dispatching control to the Linux kernel? The Jesse load seems to have little trouble handling this function during its boot sequence, but it would be slicker if this function could be preformed by the uboot rather than the kernel. If so, anything to look out for, and which Network Time Server do you use?

Thanks again!

restamp,

> BTW, are
> there any disadvantages to appending the DTB so
> that it is a part of the uImage and booting it the
> conventional way if you don't intend to move the
> filesystem to another architecture?

There is no disadvantage that I know of. Even though it states in the kernel config menu that's it's experimental, it works pretty well. I think they just want people to move on to FDT and did not want to define this compatibility feature as stable.

> why the /dev/mtdblock devices are missing in
> the Jesse load with the 3.18.5 kernel?

No they are not missing. I think if you check your kernel bootargs for mtdparts again, if it is there, it should show up in the kernel under /dev. Does the mtdparts in the cmdline show something like this?

cat /proc/cmdline

....... mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data) ....

> Also, I'm
> curious as to how, and under what circumstances,
> you issue updates for this kernel.

I only update kernel when either:

- There is new major release, i.e. 3.16, 3,17, 3.18, 4.0... And the minor version just depends on when I have free time. So the kernel build jump from 3.17.0 to 3.18.5, for example. I've skipped 3.19 because I did not see anything that would be better for these Kirkwood and Oxnas plugs.

- If there are significant bug fixes in a minor version that relate to these plugs.

> Another uboot question: Has anyone used the SNTP
> functionality of the latest uboot, which allows
> the uboot itself to set the date of the RTC before
> dispatching control to the Linux kernel? The
> Jesse load seems to have little trouble handling
> this function during its boot sequence, but it
> would be slicker if this function could be
> preformed by the uboot rather than the kernel. If
> so, anything to look out for, and which Network
> Time Server do you use?

Here is an example. In this,

dnsip and gatewayip : my local network router IP
montpelier.caltech.edu : ntp server IP (could be any ntp server that is near you)
dns montpelier.caltech.edu : retrieves and stores the IP of that server to ntpserver
sntp $ntpserver : run the sntp command

fw_setenv set_rtc 'setenv dnsip 192.168.0.1; setenv gatewayip 192.168.0.1; setenv netmask 255.255.255.0; dns montpelier.caltech.edu ntpserver; sntp $ntpserver'

and to set rtc at boot, just add "run set_rtc" to the bootcmd (whatever your bootcmd is, below is only an example)

fw_setenv bootcmd 'run set_rtc; usb start; run usb_bootcmd; usb stop; reset'

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

> > why the /dev/mtdblock devices are missing in
> > the Jesse load with the 3.18.5 kernel?
>
> No they are not missing. I think if you check your
> kernel bootargs for mtdparts again, if it is
> there, it should show up in the kernel under /dev.
> Does the mtdparts in the cmdline show something
> like this?
>

> cat /proc/cmdline
> 
> .......
> mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(root
> fs),-(data) ....
>

Interesting. I have:

# cat /proc/cmdline
console=ttyS0,115200 root=/dev/sda1 rootdelay=10 rootfstype= mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
# ls -l /dev/mtd*
crw------- 1 root root 90, 0 Dec 31  1969 /dev/mtd0
crw------- 1 root root 90, 1 Dec 31  1969 /dev/mtd0ro
crw------- 1 root root 90, 2 Dec 31  1969 /dev/mtd1
crw------- 1 root root 90, 3 Dec 31  1969 /dev/mtd1ro
crw------- 1 root root 90, 4 Dec 31  1969 /dev/mtd2
crw------- 1 root root 90, 5 Dec 31  1969 /dev/mtd2ro
crw------- 1 root root 90, 6 Dec 31  1969 /dev/mtd3
crw------- 1 root root 90, 7 Dec 31  1969 /dev/mtd3ro
# grep mtd /proc/devices
 90 mtd
#

Yet, on wheezy:

$ cat /proc/cmdline
console=ttyS0,115200 root=/dev/sda1 rootdelay=10 rootfstype= mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
$ ls -l /dev/mtd*
crw------- 1 root root 90, 0 Dec 31  1969 /dev/mtd0
crw------- 1 root root 90, 1 Dec 31  1969 /dev/mtd0ro
crw------- 1 root root 90, 2 Dec 31  1969 /dev/mtd1
crw------- 1 root root 90, 3 Dec 31  1969 /dev/mtd1ro
crw------- 1 root root 90, 4 Dec 31  1969 /dev/mtd2
crw------- 1 root root 90, 5 Dec 31  1969 /dev/mtd2ro
crw------- 1 root root 90, 6 Dec 31  1969 /dev/mtd3
crw------- 1 root root 90, 7 Dec 31  1969 /dev/mtd3ro
brw-rw---T 1 root disk 31, 0 Dec 31  1969 /dev/mtdblock0
brw-rw---T 1 root disk 31, 1 Dec 31  1969 /dev/mtdblock1
brw-rw---T 1 root disk 31, 2 Dec 31  1969 /dev/mtdblock2
brw-rw---T 1 root disk 31, 3 Dec 31  1969 /dev/mtdblock3
$   grep mtd /proc/devices
 90 mtd
 31 mtdblock
$

Perhaps I'm missing a module?

restamp,

> Perhaps I'm missing a module?

Ah! I remember it now. The fdisk command always erroneously tried to list mtd partitions, so it spitted out errors in dmesg about "mtd partitions don't have valid partition table". Those were scary looking messages! and misleading to say the least. So I've moved mtdblock to module, instead of compiled it in kernel. This way casual users would not see the messages when they try to fdisk -l.

To use mtdblock in the current kernel, either:

1. modprobe it in /etc/rc.local

modprobe mtdblock

or
2. add it to the /etc/initrams-tools/modules, and regenerate initramfs image, and regenerate /boot/uInitrd

After you loaded it, try "fdisk -l" to see if the errors are still there. If they don't show up in dmesg, I will add it back to the kernel in the future, no problem.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Yep, that resolved the problem. I did go looking around for a module, but couldn't find one in the wheezy kernel ("lsmod | grep mtd") either, and gave up. FWIW, the only time I use these mtd block devices is when I'm mounting the NAND root file system, which is rare. So, as long as I know what module name I need to modprobe beforehand to make it work, it's not a problem. So my advice is to leave it as it is. You are correct that the kernel gets vocal when a command that does not understand NAND tries to read the mtd block devices. In fact, it gets ugly:

t# fdisk -l

Disk /dev/sda: 15.2 GiB, 16358768640 bytes, 31950720 sectors
Units: sectors of [ 4584.969410] __nand_correct_data: uncorrectable ECC error
1 * 512 = 512 by[ 4584.975701] blk_update_request: I/O error, dev mtdblock1, sector 0
tes
Sector size[ 4584.983865] __nand_correct_data: uncorrectable ECC error
 (logical/physic[ 4584.990010] blk_update_request: I/O error, dev mtdblock1, sector 0
[ 4584.997589] Buffer I/O error on dev mtdblock1, logical block 0, async page read
al): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc3072e18

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1          16384 10502143 10485760    5G 83 Linux
/dev/sda2       10502144 12075007  1572864  768M 82 Linux swap / Solaris
/dev/sda3       12075008 31950719 19875712  9.5G 83 Linux

Disk /dev/mtdblock0: 1 MiB, 1048576 bytes, 2048 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mtdblock2: 32 MiB, 33554432 bytes, 65536 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mtdblock3: 91 MiB, 95420416 bytes, 186368 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
#

I remember encountering somewhat the same problem when I was trying to mount the rootfs using UUIDs: The kernel would go pound on every block device it could find, looking for the root partition, and although I knew it wasn't harmful, it was still quite distracting to see all those errors fly by in the boot sequence.

Thanks again, bodhi.

A couple days ago, bodhi and I exchanged some brief comments on how to boot to the PogoPlug E02 internal NAND OS from the 2014.07 version of uBoot. I could not see any reason to ever need to do this, but out of curiosity I experimented with it this afternoon. The original uBoot (version 1.1.4 from 2009) was on the NAND filesystem under the name uboot-original-mtd0.kwb. I believe it was put there by the initial Doozan uBoot install script.

First, I tried pulling the original uBoot into memory via fsload, but I could not get the fsload command to work under 2014.07. Maybe I need to set some variables first, but whatever I tried produced an infinite stream of: "get_fl_mem: unknown device type, using raw offset!" No worry: There's more than one way to skin a cat! So, I extricated uboot-original-mtd0.kwb from the NAND partition and copied it to the /boot directory under Jesse. I then rebooted, interrupted the boot sequence in the 2014.07 uBoot, and did the following:

PogoE02> run usb_init
	(Re)start USB...
	USB0:   USB EHCI 1.00
	scanning bus 0 for devices... 3 USB Device(s) found
		scanning usb for storage devices... 1 Storage Device(s) found
PogoE02> ext2load usb 0:1 0x800000 /boot/uboot-original-mtd0.kwb
	524288 bytes read in 331 ms (1.5 MiB/s)
PogoE02> go 0x800200
	## Starting application at 0x00800200 ...
	U-Boot 1.1.4 (Sep 28 2009 - 11:55:23) Cloud Engines v2.0 (3.4.16)
	...

and, voila, after some boot verbiage on the console, I was dumped into a root shell on the original PogoPlug OS. I suppose I could create an environment variable to do this more easily, or even automatically, but it seems unlikely I'll ever need to boot this OS in the future. This was mostly just a learning exercise.

In any event, a couple questions:

1. Has anyone gotten fsload to work under 2014.07 (and if so, what's the secret)?

2. Does anyone know of a good reference document or website for our version of uBoot? I've Googled this any number of times, but never found a satisfactory source. Well, perhaps the source code itself is the ultimate source, but a listing of the commands, what they do, and what other variables they depend on would be quite useful.

restamp,

> PogoE02> run usb_init
> (Re)start USB...
> USB0: USB EHCI 1.00
> scanning bus 0 for devices... 3 USB Device(s)
> found
> scanning usb for storage devices... 1 Storage
> Device(s) found
> PogoE02> ext2load usb 0:1 0x800000
> /boot/uboot-original-mtd0.kwb
> 524288 bytes read in 331 ms (1.5 MiB/s)
> PogoE02> go 0x800200
> ## Starting application at 0x00800200 ...
> U-Boot 1.1.4 (Sep 28 2009 - 11:55:23) Cloud
> Engines v2.0 (3.4.16)
> ...
> and, voila, after some boot verbiage on the
> console, I was dumped into a root shell on the
> original PogoPlug OS.

Nice! this is great. So now we've confirmed that the chainload works going from 2014.07 to the stock Pogo E02 u-boot.

> 1. Has anyone gotten fsload to work under
> 2014.07 (and if so, what's the secret)?

fsload does work. graymanforhire reported that it works in the Pogoplug V4 chainloading the stock u-boot from NAND rootfs. I believe it did for me, but I would have to retry to know for sure (my boxes have never failed to boot because of bad rootfs, I have to purposely cause it). The error you saw perhaps has something to do with that specific NAND partition. Have you tried to mount it in Debian?

> 2. Does anyone know of a good reference document
> or website for our version of uBoot? I've
> Googled this any number of times, but never found
> a satisfactory source. Well, perhaps the source
> code itself is the ultimate source, but a listing
> of the commands, what they do, and what other
> variables they depend on would be quite useful.

The official documentation that one can find is: Denx: http://www.denx.de/wiki/view/DULG/UBoot . However, this is not always up to date. To get the full picture of what the current version does, we would have combine:

- Denx documentation
- Help output in u-boot console
- Look at my README.u-boot-kirkwood commit summary description for additional features/patches specific to my mods.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

> Have you tried to mount it in Debian?

Yes, it is mountable:

root@debian:~#  modprobe mtdblock
root@debian:~#  mount /dev/mtdblock2 /mnt -t jffs2 -r
[  284.354435] jffs2: Empty flash at 0x009ac208 ends at 0x009ac800
[  284.769108] jffs2: notice: (1466) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
root@debian:~#  mount
...
/dev/mtdblock2 on /mnt type jffs2 (ro,relatime)
root@debian:~#  df
Filesystem     1K-blocks   Used Available Use% Mounted on
...
/dev/mtdblock2     32768  12352     20416  38% /mnt
root@debian:~#

> The official documentation that one can find is: Denx: http://www.denx.de/wiki/view/DULG/UBoot ...

Thanks.

restamp,

> 1. Has anyone gotten fsload to work under
> 2014.07 (and if so, what's the secret)?

I can confirm that fsload works on my Dockstar with the original Jeff's setup:

pogo_bootcmd=if fsload uboot-original-mtd0.kwb; then go 0x800200; fi

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)