OpenWRT 2nd stage u-boot problems on Pogoplug-E02

OK. This time we're going to force it. It looks like the mtd partitions were not set in stock u-boot.

In serial console, at step 3 in the procedure above:

setenv mtdids 'nand0=orion_nand'
setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)"

Please bear with me :) I'd like you to help making the stock tftp booting instruction above works for others looking for it later. I could have shown you a quicker way, but then we won't have this tftp instruction.

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

bodhi Wrote:
-------------------------------------------------------
> OK. This time we're going to force it. It looks
> like the mtd partitions were not set in stock
> u-boot.

I realised that when I had updated the uImage for the changed DTB file that I'd actually forgotten to copy it over from the USB rootfs onto the TFTP server. So did that and tried again - still no difference.

> In serial console, at step 3 in
> [url=http://forum.doozan.com/read.php?3,28772,2903
> 4#msg-29034]the procedure above[/url]:
>
> [code]
> setenv mtdids 'nand0=orion_nand'
> setenv bootargs "console=ttyS0,115200
> root=LABEL=rootfs rootdelay=10
> mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(root
> fs),-(data)"
> [/code]

Ok, tried this and again same behaviour, only mtd0 showing in /proc/mtd.

> Please bear with me :) I'd like you to help making
> the stock tftp booting instruction above works
> for others looking for it later. I could have
> shown you a quicker way, but then we won't have
> this tftp instruction.

No problem - happy to help.

Ok quite a bit missing from the OpenWrt u-boot flashing. How about doing 2 tests (with the new DTB)

In serial console

ver
setenv mtdids 'nand0=orion_nand'
setenv partition 'nand0,2'
setenv bootargs 'console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 earlyprintk=serial'
printenv
boot

setenv mtdids 'nand0=orion_nand'
setenv partition 'nand0,2'
setenv bootargs 'console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 earlyprintk=serial mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)'
printenv
boot

Also pls capture and post the entire bootlog. The kernel output might also have more info as why the mtds are not allocated with the new DTB.

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

bodhi Wrote:
-------------------------------------------------------
> In serial console
>

ver
setenv mtdids 'nand0=orion_nand'
setenv partition 'nand0,2'
setenv bootargs 'console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 earlyprintk=serial'
printenv
boot

No change in behaviour, output inc bootlog attached as file test1.txt

setenv mtdids 'nand0=orion_nand'
setenv partition 'nand0,2'
setenv bootargs 'console=ttyS0,115200
root=LABEL=rootfs rootdelay=10 earlyprintk=serial
mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)'
printenv
boot

We have a winner! cat /proc/mtd now shows 4 partitions (and mtd0 is different size than before):

root@debian:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 02000000 00020000 "rootfs"
mtd3: 05b00000 00020000 "data"

Output attached as file test2.txt.

armless,

setenv mtdids 'nand0=orion_nand'
setenv partition 'nand0,2'
setenv bootargs 'console=ttyS0,115200
root=LABEL=rootfs rootdelay=10 earlyprintk=serial
mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)'
printenv
boot

> We have a winner! cat /proc/mtd now shows 4
> partitions (and mtd0 is different size than
> before):
>
>

> root@debian:~# cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 00100000 00020000 "u-boot"
> mtd1: 00400000 00020000 "uImage"
> mtd2: 02000000 00020000 "rootfs"
> mtd3: 05b00000 00020000 "data"
>

>
> Output attached as file test2.txt.

Cool, so it was because the mtd partitions definition in u-boot was removed before.

You can proceed to flash new u-boot and the default envs to mtd0.

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

bodhi Wrote:
-------------------------------------------------------
> Cool, so it was because the mtd partitions
> definition in u-boot was removed before.

Found why /proc/mtd" was only showing mtd0 previously and then all 4 partitions the latest time:

setenv bootargs "console=$(console) root=LABEL=rootfs rootdelay=10 earlyprintk=serial mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)"

whereas I did this the last time:

setenv bootargs 'console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 earlyprintk=serial mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)'

The difference in behaviour is the use of double quotes (/proc/mtd isn't right afterwards) versus using single quotes (/proc/mtd is correct).

>
> You can proceed to flash new u-boot and the
> default envs to mtd0.

I'm in the process of doing that now. One thing I've noticed is a difference in output from your U-Boot upgrade doc "http://forum.doozan.com/read.php?3,12381";, section "6. Erase mtd0", when running:

flash_erase /dev/mtd0 0 4

you indicate the expected output is:

Erase Total 4 Units 
Performing Flash Erase of length 131072 at offset 0x60000 done

whereas I see:

Erasing 128 Kibyte @ 60000 -- 100 % complete

As the figures match up (131072 == 128 Kibyte) and 0x60000 in both cases I'm assuming this has worked correctly and the difference in output is due to 2 different versions of flash_erase having differing output messages. So I continued onwards with the nandwrite of your u-boot and I'm now doing the default environment variables...

*UPDATE* differing output for flash_erase also while doing the default environment. Your notes, section "B. Flashing default u-boot envs image", "d. Flash u-boot envs to NAND location 0xC0000." for command:

/usr/sbin/flash_erase /dev/mtd0 0xc0000 1

has expected output:

Erase Total 1 Units
Performing Flash Erase of length 131072 at offset 0xc0000 done

whereas I see:

Erasing 128 Kibyte @ c0000 -- 100 % complete

I'm confused why this command seems to erase 128 Kibyte when (in your example output) its for 1 unit, whereas the previous flash_erase for the U-Boot itself was for 4 units but also apparently erased 128 Kibyte (rather than 4 times that).

I'm pausing any activities at this stage until I get some feedback from you ;-)



Edited 1 time(s). Last edit at 08/19/2016 11:50PM by armless.

armless,

>

> flash_erase /dev/mtd0 0 4
>

>
> you indicate the expected output is:
>
>

> Erase Total 4 Units 
> Performing Flash Erase of length 131072 at offset
> 0x60000 done
>

>
> whereas I see:
>
>

> Erasing 128 Kibyte @ 60000 -- 100 % complete
>

>

The above is wrong.

>
>

> /usr/sbin/flash_erase /dev/mtd0 0xc0000 1
>

>
> has expected output:
>
>

> Erase Total 1 Units
> Performing Flash Erase of length 131072 at offset
> 0xc0000 done
>

>
> whereas I see:
>
>

> Erasing 128 Kibyte @ c0000 -- 100 % complete
>

>

The above is correct.

Remember, this is the Pogo E02, so we need to be extra careful. If only the 1 sector was erased, there is some chance that u-boot image is not flashed correctly. So don't reboot. Try erase it again, and btw which version is this

flash_erase --version

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

bodhi Wrote:
-------------------------------------------------------
> Remember, this is the Pogo E02, so we need to be
> extra careful. If only the 1 sector was erased,
> there is some chance that u-boot image is not
> flashed correctly. So don't reboot. Try erase it
> again, and btw which version is this

Ok, tried again, same behaviour:

root@debian:/tmp# flash_erase --version
flash_erase version 1.5.1

Copyright (C) 2000 Arcom Control Systems Ltd

flash_erase comes with NO WARRANTY
to the extent permitted by law.

You may redistribute copies of flash_erase
under the terms of the GNU General Public Licence.
See the file `COPYING' for more information.

root@debian:/tmp# flash_erase /dev/mtd0 0 4
Erasing 128 Kibyte @ 60000 -- 100 % complete

Actually why is it erasing @60000? It should be @0x0.

armless,

I think that this version of flash_erase output is misleading. Go ahead repeat the flashing (step 7, 8).

And do fw_printenv afterward for sanity check. And cross your fingers and reboot :)

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

bodhi Wrote:
-------------------------------------------------------
> And do fw_printenv afterward for sanity check. And
> cross your fingers and reboot :)

Flashed u-boot again and default environment.

Now doing environment variable "fixup".

fw_setenv arcNumber 3542
fw_setenv machid dd6

Should machid be "dd6" or "0xdd6"?

Also "restoring" mtdparts, should it really be the folowing (which is which my pre-flashing env variable was set to):

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

or remove the extra "mtdparts=" bit?

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

Edited 1 time(s). Last edit at 08/20/2016 05:48PM by armless.

armless Wrote:
-------------------------------------------------------
> bodhi Wrote:
> --------------------------------------------------
> -----
> > And do fw_printenv afterward for sanity check.
> And
> > cross your fingers and reboot :)
>
> Flashed u-boot again and default environment.
>
> Now doing environment variable "fixup".
>
>

> fw_setenv arcNumber 3542
> fw_setenv machid dd6
>

>
> Should machid be "dd6" or "0xdd6"?

dd6 is correct.

> Also "restoring" mtdparts, should it really be the
> folowing (which is which my pre-flashing env
> variable was set to):
>
>

> fw_setenv mtdparts
> 'mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(roo
> tfs),-(data)'
>

>
> or remove the extra "mtdparts=" bit?

Don't remove that. It is the name of the kernel bootarg for mtparts.

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

bodhi Wrote:
-------------------------------------------------------
> I think that this version of flash_erase output is
> misleading. Go ahead repeat the flashing (step 7,
> 8).
>
> And do fw_printenv afterward for sanity check. And
> cross your fingers and reboot :)

Aaannnnnnnddddd its rebooted, new U-Boot, finds the USB stick, loads uImage, uInitrd, and DTB (as I'd swapped the uImage with DTB builtin back for the original non-DTB merged uImage), and bingo, Debian running fine it seems.

There is a kernel message about missing MAC address during boot:

[    0.160952] [Firmware Info]: /ocp@f1000000/ethernet-controller@72000/ethernet0-port@0: local-mac-address is not set
[    0.165857] No ATAGs?

but then sets it fine:

[    1.804158] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[    2.883951] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address aa:bb:cc:dd:ee:ff

and "ip link" confirms MAC set fine.

Now to upgrade the kernel to 4.6!

Any point in me creating a blank (for now) /boot/uEnv.txt file? For later use and to get rid of the "file not found" message during boot.

Regarding your 4.6 Kernel update notes:

cd /boot
apt-get remove flash-kernel 
dpkg -i linux-image-4.6.0-kirkwood-tld-1_1.0_armel.deb

The package flash-kernel was not installed so no need to remove it.

Also installing the 4.6 kernel DEB file gave a couple of (minor) warnings:

root@debian:/boot# dpkg -i linux-image-4.6.0-kirkwood-tld-1_1.0_armel.deb 
Selecting previously unselected package linux-image-4.6.0-kirkwood-tld-1.
(Reading database ... 12733 files and directories currently installed.)
Preparing to unpack linux-image-4.6.0-kirkwood-tld-1_1.0_armel.deb ...
Examining /etc/kernel/preinst.d/
Done.
Unpacking linux-image-4.6.0-kirkwood-tld-1 (1.0) ...
Setting up linux-image-4.6.0-kirkwood-tld-1 (1.0) ...

 Hmm. There is a symbolic link /lib/modules/4.6.0-kirkwood-tld-1/build
 However, I can not read it: No such file or directory
 Therefore, I am deleting /lib/modules/4.6.0-kirkwood-tld-1/build


 Hmm. The package shipped with a symbolic link /lib/modules/4.6.0-kirkwood-tld-1/source
 However, I can not read the target: No such file or directory
 Therefore, I am deleting /lib/modules/4.6.0-kirkwood-tld-1/source

Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.6.0-kirkwood-tld-1 /boot/vmlinuz-4.6.0-kirkwood-tld-1
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.6.0-kirkwood-tld-1 /boot/vmlinuz-4.6.0-kirkwood-tld-1
update-initramfs: Generating /boot/initrd.img-4.6.0-kirkwood-tld-1
run-parts: executing /etc/kernel/postinst.d/zz-flash-kernel 4.6.0-kirkwood-tld-1 /boot/vmlinuz-4.6.0-kirkwood-tld-1
root@debian:/boot#

Also in your notes, section 4a:

fw_setenv usb_boot 'run load_dtb; run load_uimage; if run load_initrd; then bootm 0x800000 0x1100000 0x1c00000; else bootm 0x800000 - 0x1c00000; fi'

There is no usb_boot that I can see that is used by any of the "new" environment variables so I guess this is old information that you can now remove from your notes?

Kernel updated, reboot and...............woohoo, now running 4.6.

A quick check (dmesg comparison between 4.6 & 4.4) shows hardware encryption is now apparently working:

<  marvell-cesa f1030000.crypto: CESA device successfully registered
---
>  marvell-cesa: probe of f1030000.crypto failed with error -524

So finally it seems I've got a usable Pogoplug again!!!

Thanks *very* much Bodhi for all your help. I did take "script" output of all the U-boot flashing, default environment flashing, and kernel update if you're interested.

I do have another old Pogoplug E02 here as well still on the Doozan u-boot and therefore once I get around to trying to reflash it (its running "important" stuff so this newly fixed Pogoplug has to take over its duties first) I fully expect things to go a lot easier/quicker as it will avoid the whole OpenWRT "trainwreck" issues I had with this current Pogoplug.

armless Wrote:
-------------------------------------------------------
> bodhi Wrote:
> --------------------------------------------------
> -----
> > I think that this version of flash_erase output
> is
> > misleading. Go ahead repeat the flashing (step
> 7,
> > 8).
> >
> > And do fw_printenv afterward for sanity check.
> And
> > cross your fingers and reboot :)
>
> Aaannnnnnnddddd its rebooted, new U-Boot, finds
> the USB stick, loads uImage, uInitrd, and DTB (as
> I'd swapped the uImage with DTB builtin back for
> the original non-DTB merged uImage), and bingo,
> Debian running fine it seems.
>
> There is a kernel message about missing MAC
> address during boot:
>
>

> [    0.160952] [Firmware Info]:
> /ocp@f1000000/ethernet-controller@72000/ethernet0-
> port@0: local-mac-address is not set
> [    0.165857] No ATAGs?
>

>

This is OK. Since we boot with DTB, ATAG is deprecated.


> but then sets it fine:
>
>

> [    1.804158] mv643xx_eth: MV-643xx 10/100/1000
> ethernet driver version 1.4
> [    2.883951] mv643xx_eth_port mv643xx_eth_port.0
> eth0: port 0 with MAC address aa:bb:cc:dd:ee:ff
>

>
> and "ip link" confirms MAC set fine.
>
> Now to upgrade the kernel to 4.6!
>
> Any point in me creating a blank (for now)
> /boot/uEnv.txt file? For later use and to get rid
> of the "file not found" message during boot.

Don't worry about it. If you want to get rid of the message then, yes create one with one env like this so it can be read properly, and this is useful.

custom_params=earlyprintk

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

armless Wrote:
-------------------------------------------------------
> Regarding your 4.6 Kernel update notes:
>
>

> cd /boot
> apt-get remove flash-kernel 
> dpkg -i
> linux-image-4.6.0-kirkwood-tld-1_1.0_armel.deb
>

>
> The package flash-kernel was not installed so no
> need to remove it.
>
> Also installing the 4.6 kernel DEB file gave a
> couple of (minor) warnings:
>
>

> root@debian:/boot# dpkg -i
> linux-image-4.6.0-kirkwood-tld-1_1.0_armel.deb 
> Selecting previously unselected package
> linux-image-4.6.0-kirkwood-tld-1.
> (Reading database ... 12733 files and directories
> currently installed.)
> Preparing to unpack
> linux-image-4.6.0-kirkwood-tld-1_1.0_armel.deb
> ...
> Examining /etc/kernel/preinst.d/
> Done.
> Unpacking linux-image-4.6.0-kirkwood-tld-1 (1.0)
> ...
> Setting up linux-image-4.6.0-kirkwood-tld-1 (1.0)
> ...
> 
>  Hmm. There is a symbolic link
> /lib/modules/4.6.0-kirkwood-tld-1/build
>  However, I can not read it: No such file or
> directory
>  Therefore, I am deleting
> /lib/modules/4.6.0-kirkwood-tld-1/build
> 
> 
>  Hmm. The package shipped with a symbolic link
> /lib/modules/4.6.0-kirkwood-tld-1/source
>  However, I can not read the target: No such file
> or directory
>  Therefore, I am deleting
> /lib/modules/4.6.0-kirkwood-tld-1/source
> 
> Running depmod.
> Examining /etc/kernel/postinst.d.
> run-parts: executing
> /etc/kernel/postinst.d/apt-auto-removal
> 4.6.0-kirkwood-tld-1
> /boot/vmlinuz-4.6.0-kirkwood-tld-1
> run-parts: executing
> /etc/kernel/postinst.d/initramfs-tools
> 4.6.0-kirkwood-tld-1
> /boot/vmlinuz-4.6.0-kirkwood-tld-1
> update-initramfs: Generating
> /boot/initrd.img-4.6.0-kirkwood-tld-1
> run-parts: executing
> /etc/kernel/postinst.d/zz-flash-kernel
> 4.6.0-kirkwood-tld-1
> /boot/vmlinuz-4.6.0-kirkwood-tld-1
> root@debian:/boot# 
>

>

This is normal. Just an artifact of the kernel build process that you can ignore.

> Also in your notes, section 4a:
>
>

> fw_setenv usb_boot 'run load_dtb; run load_uimage;
> if run load_initrd; then bootm 0x800000 0x1100000
> 0x1c00000; else bootm 0x800000 - 0x1c00000; fi'
>

>
> There is no usb_boot that I can see that is used
> by any of the "new" environment variables so I
> guess this is old information that you can now
> remove from your notes?
>

Let me see. Thanks for pointing this out, it is probably not clear that you don't need to do this if you flashed the default envs image.


> Kernel updated, reboot and...............woohoo,
> now running 4.6.
>
> A quick check (dmesg comparison between 4.6 & 4.4)
> shows hardware encryption is now apparently
> working:
>
>

> <  marvell-cesa f1030000.crypto: CESA device
> successfully registered
> ---
> >  marvell-cesa: probe of f1030000.crypto failed
> with error -524
>

>
> So finally it seems I've got a usable Pogoplug
> again!!!
>

Cool!

> Thanks *very* much Bodhi for all your help. I did
> take "script" output of all the U-boot flashing,
> default environment flashing, and kernel update if
> you're interested.
>

You could post a cleanup version of this (pitfalls and stuff) so that it will benefit others who wants to transition from an installed OpenWrt u-boot.

> I do have another old Pogoplug E02 here as well
> still on the Doozan u-boot and therefore once I
> get around to trying to reflash it (its running
> "important" stuff so this newly fixed Pogoplug has
> to take over its duties first) I fully expect
> things to go a lot easier/quicker as it will avoid

> the whole OpenWRT "trainwreck" issues I had with
> this current Pogoplug.

Glad it works out fine for you :)

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



Edited 1 time(s). Last edit at 08/21/2016 04:16AM by bodhi.

very good!!!!!!!!!!!!!