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

As per the instructions at "https://wiki.openwrt.org/toh/cloudengines/pogoplug"; I flashed the OpenWRT 2nd stage u-boot onto my Pogoplug-E02 to be chainloaded by the stock Cloud Engines u-boot.

After flashing and doing the "reset" the Pogoplug did indeed chainload the OpenWRT u-boot but it then hangs at the following point:

USB 0: host mode                                                                
PEX 0: interface detected no Link.                                              
Net:   egiga0 [PRIME], egiga1                                                   
Hit any key to stop autoboot:  0                                                
                                                                                
NAND read: device 0 offset 0x100000, size 0x200000                              
                                                                                
Reading data from 0x2ff800 -- 100% complete.                                    
 2097152 bytes read: OK                                                         
## Booting image at 00800000 ...                                                
   Image Name:   OpenWrt Das U-Boot uImage                                      
   Created:      2016-01-02   1:38:50 UTC                                       
   Image Type:   ARM Linux Kernel Image (uncompressed)                          
   Data Size:    454856 Bytes = 444.2 kB                                        
   Load Address: 00600000                                                       
   Entry Point:  00600000                                                       
   Verifying Checksum ... OK

I've posted a question about this on the OpenWRT formus but thought I'd also post here as well. I'm wondering if there's an issue with the current environment variable settings.

The OpenWRT u-boot version appears to be 2014.10 (based on doing a "strings" on the binary.

Here's the output of my flashing the 2nd stage OpenWRT u-boot from the stock u-boot (including a list of environment variables) and then output after rebooting. Note: I have obscured IPs and MAC address in this output:

CE>> setenv ipaddr 100.2.3.3
CE>> setenv serverip 100.2.3.5
CE>> setenv netmask 255.255.255.0
CE>> printenv                                                                   
baudrate=115200                                               
loads_echo=0                                                                    
rootpath=/mnt/ARM_FS/                                                           
run_diag=yes                                                                    
console=console=ttyS0,115200                                                    
CASset=min                                                                      
MALLOC_len=1                                                                    
ethprime=egiga0                                                                 
bootargs_root=root=/dev/mtdblock2 ro                                            
ethmtu=1500                                                                     
usb0Mode=host                                                                   
nandEcc=1bit                                                                    
ethact=egiga0                                                                   
bootargs=console=ttyS0,115200 root=/dev/mtdblock2 ro
ethaddr=00:01:02:03:04:05
cesvcid=ABCDEFGHIJKLMNOPQRS
ceboardver=PPV2                                                                 
bootcmd=nand read.e 0x800000 0x100000 0x200000; setenv bootargs $(console) $(bo0
stdin=serial                                                                    
stdout=serial                                                                   
stderr=serial                                                                   
mainlineLinux=no                                                                
enaMonExt=no                                                                    
enaCpuStream=no                                                                 
enaWrAllo=no                                                                    
pexMode=RC                                                                      
disL2Cache=no                                                                   
setL2CacheWT=yes                                                                
disL2Prefetch=yes                                                               
enaICPref=yes                                                                   
enaDCPref=yes                                                                   
sata_dma_mode=yes                                                               
netbsd_en=no                                                                    
vxworks_en=no                                                                   
bootdelay=3
disaMvPnp=no                                                                    
serverip=100.2.3.5                           
netmask=255.255.255.0                                                           
ipaddr=100.2.3.3

Environment size: 799/131068 bytes                                              
CE>> mw 0x800000 0xffff 0x80000                                                 
CE>> tftpboot 0x800000 openwrt-kirkwood-pogo_e02_second_stage-u-boot.img        
Using egiga0 device                                                             
TFTP from server 100.2.3.5; our IP address is 100.2.3.3
Filename 'openwrt-kirkwood-pogo_e02_second_stage-u-boot.img'.                   
Load address: 0x800000                                                          
Loading: #################################################################      
         ########################                                               
done                                                                            
Bytes transferred = 454920 (6f108 hex)                                          
CE>> nand erase 0x100000 0x80000                                                
                                                                                
NAND erase: device 0 offset 0x100000, size 0x80000                              
Erasing at 0x160000 -- 100% complete.                                           
OK                                                                              
CE>> nand write.e 0x800000 0x100000 0x80000                                     
                                                                                
NAND write: device 0 offset 0x100000, size 0x80000                              
                                                                                
Writing data at 0x17f800 -- 100% complete.                                      
 524288 bytes written: OK                                                       
                                                                                
Environment size: 830/131068 bytes                                              
CE>> reset                                                                      
                                                                                
                                                                                
U-Boot 1.1.4 (Sep 28 2009 - 11:55:23) Cloud Engines v2.0 (3.4.16)               
                                                                                
U-Boot code: 00600000 -> 0067FFF0  BSS: -> 00690D60                             
                                                                                
Soc: 88F6281 A0 (DDR2)                                                          
CPU running @ 1200Mhz L2 running @ 400Mhz                                       
SysClock = 400Mhz , TClock = 200Mhz                                             
                                                                                
DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6                                   
DRAM CS[0] base 0x00000000   size 256MB                                         
DRAM Total size 256MB  16bit width                                              
Flash:  0 kB                                                                    
Addresses 8M - 0M are saved for the U-Boot usage.                               
Mem malloc Initialization (8M - 7M): Done                                       
NAND:128 MB

CPU : Marvell Feroceon (Rev 1)                                                  
CLOUD ENGINES BOARD: PPV2                                                       
                                                                                
Streaming disabled                                                              
Write allocate disabled                                                         
                                                                                
                                                                                
USB 0: host mode                                                                
PEX 0: interface detected no Link.                                              
Net:   egiga0 [PRIME], egiga1                                                   
Hit any key to stop autoboot:  0                                                
                                                                                
NAND read: device 0 offset 0x100000, size 0x200000                              
                                                                                
Reading data from 0x2ff800 -- 100% complete.                                    
 2097152 bytes read: OK                                                         
## Booting image at 00800000 ...                                                
   Image Name:   OpenWrt Das U-Boot uImage                                      
   Created:      2016-01-02   1:38:50 UTC                                       
   Image Type:   ARM Linux Kernel Image (uncompressed)                          
   Data Size:    454856 Bytes = 444.2 kB                                        
   Load Address: 00600000
   Entry Point:  00600000                                                       
   Verifying Checksum ... OK

Any help would be most welcome.

Chainloading from older u-boot (1.1.4) to a modern u-boot such as 2014 or newer is not going to work. You might as well install new u-boot on mtd0 and not having to worry about it at all:
http://forum.doozan.com/read.php?3,12381

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

However, looks like the chainloading was not set up correctly also. No where in your envs that I can find a "go" command, Is there?

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

Quote
bodhi
Chainloading from older u-boot (1.1.4) to a modern u-boot such as 2014 or newer is not going to work. You might as well install new u-boot on mtd0 and not having to worry about it at all:
http://forum.doozan.com/read.php?3,12381

You think I should use your 2016.05 u-boot in preference to the 2014.10 1st stage OpenWRT u-boot then?

One thing to point out is that the documented OpenWRT installation expects the flash to be repartitioned to shrink some of the partitions in order to make mtd3 larger.

Quote
bodhi
However, looks like the chainloading was not set up correctly also. No where in your envs that I can find a "go" command, Is there?

Nope, no sign of a "go" command and none was mentioned in the OpenWRT Pogo-E02 docs. The Cloud Engine u-boot envs are just the way they were after I reinstated the stock u-boot (removed your 2010 u-boot I used to have) I only tweaked the ipaddr, netmask, and serverip variables to get the TFTP working, nothing else.

I did notice that the "bootcmd" in the stock u-boot envs was truncated in my original posting, its correct value is:

bootcmd=nand read.e 0x800000 0x100000 0x200000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000

So is it a case that the chainloaded OpenWRT u-boot is missing its own set of env variables?

armless,

>

> bootcmd=nand read.e 0x800000 0x100000 0x200000;
> setenv bootargs $(console) $(bootargs_root); bootm
> 0x800000
>

>

This the actual bootcmd which loads the kernel.

> So is it a case that the chainloaded OpenWRT
> u-boot is missing its own set of env variables?

Yes.

However, as I mentioned, don't set up chainloading. Just boot the OpenWrt in NAND with the new u-boot,

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

bodhi Wrote:
-------------------------------------------------------
> However, as I mentioned, don't set up
> chainloading. Just boot the OpenWrt in NAND with
> the new u-boot,

Ok, and do you recommend I use your u-boot rather than the OpenWRT (1st stage) u-boot one?

armless,

> Ok, and do you recommend I use your u-boot rather
> than the OpenWRT (1st stage) u-boot one?

You could stay with that u-boot since it is relatively new. However, iirc, it is missing a lot of new features comparing to my u-boot images, so you might as well flash the newer u-boot. The only bad thing with installing any u-boot in Pogo E02 is that it does not have a recovery means such as UART booting, so you have to be extremely careful (i.e. don't reboot if seeing any error).

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

bodhi Wrote:
-------------------------------------------------------
> You could stay with that u-boot since it is
> relatively new. However, iirc, it is missing a lot
> of new features comparing to my u-boot images, so
> you might as well flash the newer u-boot. The only
> bad thing with installing any u-boot in Pogo E02
> is that it does not have a recovery means such as
> UART booting, so you have to be extremely careful
> (i.e. don't reboot if seeing any error).

So I want to replace the existing Cloud Engines u-boot with your current u-boot - but I've got a problem: when I previously installed the OpenWRT 2nd stage u-boot I followed their instructions (at "https://wiki.openwrt.org/toh/cloudengines/pogoplug?s[]=pogoplug&s[]=e02") and so did the following to flash the 2nd stage:

mw 0x800000 0xffff 0x80000
tftpboot 0x800000 openwrt-kirkwood-pogo_e02_second_stage-u-boot.img
nand erase 0x100000 0x80000
nand write.e 0x800000 0x100000 0x80000

and this placed the 2nd u-boot at 0x100000, which is where the stock Pogoplug flash layout previously had mtd1 with the uImage. The documented OpenWRT instructions for a 2-stage u-boot are to re-layout the flash as follows:

mtd#          mtd0      mtd1        mtd2                 mtd3
start         0x000000  0x0e0000    0x100000             0x0200000
size          0x0e0000  0x100000    0x100000             0x7e00000
in Bytes      896 KiB   128 KiB     1 MiB                126 MiB
name          u-boot    u-boot env  second_stage_u-boot  rootfs
file system   none      none        none                 ubifs

So it seems that I currently don't have a working system - I can boot the machine and it chainloads from Cloud Engine u-boot into 2nd stage OpenWRT u-boot and then hangs, or I interrupt the stock u-boot and then can't boot the old Cloud Engine linux as its kernel (uimage) has been overwritten by the 2nd stage u-boot.

I assume that I can't flash your u-boot in place of the stock Cloud Engine's one from within that u-boot so I guess I need to get some sort of Linux dist running temporarily so that I can then from there flash tyour u-boot in place of the stock u-boot, tidy up the environment variables if needed, and then from your u-boot tftp load and flash the OpenWRT ubi image (i.e. with no 2nd stage loader at all).

Actually seems like I'm wrong - the OpenWRT documented instructions for replacing the stock u-boot appear to show their own u-boot being flashed (as the only u-boot) from within the existing u-boot:

dd bs=128k conv=sync if=openwrt-kirkwood-pogo_e02-u-boot.kwb of=openwrt-kirkwood-pogo_e02-u-boot.aligned.kwb
mw 0x800000 0xffff 0x80000
tftpboot 0x800000 openwrt-kirkwood-pogo_e02-u-boot.aligned.kwb
nand erase 0x0 0xa4fff
nand write.e 0x800000 0x0 0x80000

So I guess I could risk the above instructions either as is, or using your u-boot in the place of theirs, and hope I don't brick my Pogoplug...

Your best approach:

1. Create Debian 4.4 rootfs on USB from:
http://forum.doozan.com/read.php?2,12096

You need to append the pogo e02 DTB to uImage.

2. Boot, interrupt serial console and copy the list of current envs, adjust envs (but dont save) to boot with USB rootfs. Boot into Debian. Verify this can be repeated a couple times.

3. In Debian, flash new uboot and default envs image. Adjust ethaddr, ipaddr, serverip, and remove the dtb_file env (you have dtb embbed uImage). Reboot if there is no error.

4. Once booting Debian is ok. Reboot, interrupt serial console and adjust envs to boot Openwrt rootfs in mtd3.

Since you are an exprienced user, you already knew the risk :)

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

bodhi Wrote:
-------------------------------------------------------
> Your best approach:
>
> 1. Create Debian 4.4 rootfs on USB from:
> http://forum.doozan.com/read.php?2,12096
>
> You need to append the pogo e02 DTB to uImage.

Done.

> 2. Boot, interrupt serial console and copy the
> list of current envs, adjust envs (but dont save)
> to boot with USB rootfs. Boot into Debian. Verify
> this can be repeated a couple times.

Does the stock Cloudengines u-boot support USB booting? It doesn't seem to, commands like "usb reset" give the error "Unknown command 'usb' - type 'help'".

As OpenWRT support for the Pogo-E02 seems to not be well documented I've decided to go back to using it with Debian instead, so now that I've got the USB filesystem as per Step 1 I just need to get USB booting working and also update U-boot from stock to your 2016.05 U-boot.

As I don't currently have a working OS I can't flash the newer u-boot from there, though I could use TFTP from the stock u-boot to flash it?

Once I get Debian working I guess I should look at a rescue system to put onto the NAND.

> Since you are an exprienced user, you already knew the risk :)

Not so experienced with u-boot as you can tell :-)



Edited 1 time(s). Last edit at 07/17/2016 08:32PM by armless.

armless,

I don't recommend flashing u-boot in serial console, especially for Pogo E02. Because the risk of bricking is high.

Quote

So it seems that I currently don't have a working system - I can boot the machine and it chainloads from Cloud Engine u-boot into 2nd stage OpenWRT u-boot and then hangs, or I interrupt the stock u-boot and then can't boot the old Cloud Engine linux as its kernel (uimage) has been overwritten by the 2nd stage u-boot.

OpenWrt u-boot should allow booting from USB. Interrupt this u-boot, and

usb start

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

bodhi Wrote:
-------------------------------------------------------
>
> OpenWrt u-boot should allow booting from USB.
> Interrupt this u-boot, and
>

> usb start
>

Ah, but as mentioned earlier in this thread the OpenWRT 2nd stage u-boot (chainloaded from stock CloudEngine u-boot) does not work - it stops at are this part:

Verifying Checksum ... OK

and never gets to the part where I can interrupt it.

So all I've got is a working CloudEngine u-boot.

armless Wrote:
-------------------------------------------------------
> bodhi Wrote:
> --------------------------------------------------
> -----
> >
> > OpenWrt u-boot should allow booting from USB.
> > Interrupt this u-boot, and
> >

> > usb start
> >

>
> Ah, but as mentioned earlier in this thread the
> OpenWRT 2nd stage u-boot (chainloaded from stock
> CloudEngine u-boot) does not work - it stops at
> are this part:
>
> Verifying Checksum ... OK
>
> and never gets to the part where I can interrupt
> it.
>
> So all I've got is a working CloudEngine u-boot.

So with stock u-boot,

usb start

did not work?

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

Quote

As I don't currently have a working OS I can't flash the newer u-boot from there, though I could use TFTP from the stock u-boot to flash it?

Yes. You can boot the new rootfs with tftp.

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

bodhi Wrote:
-------------------------------------------------------
> So with stock u-boot,
>

> usb start
>

> did not work?

Nope, gives "Unknown command 'usb' - type 'help'"

bodhi Wrote:
-------------------------------------------------------
>

Quote

As I don't currently have a working OS I
> can't flash the newer u-boot from there, though I
> could use TFTP from the stock u-boot to flash
> it?

>
> Yes. You can boot the new rootfs with tftp.

I'm assuming something like this:

setenv ipaddr 1.2.3.4
setenv serverip 1.2.3.5
setenv rootdev /dev/ram
tftpboot someaddress uImage
tftpboot someotheraddress rootfs.img
bootm someaddress someotheraddress

However what values would I use to load the kernel and rootfs into? (I'm assuming for the rootfs I can just use the Debian image file)



Edited 1 time(s). Last edit at 07/21/2016 02:51PM by armless.

This example shows how to boot the new Debian rootfs with stock u-boot, where USB is not supported. The tftp command in stock u-boot is used to load the kernel files (uImage and uInitrd) form the the tftproot. And then when the kernel has started, it will mount the Debian rootfs on USB.

Credits: thanks armless for being a good sport, testing all the instruction you've found in this post.

1. Create the Debian rootfs on USB following the instruction:

Quote

Updated 20 Feb 2016:

This Debian-4.4.0-kirkwood-tld-1-rootfs-bodhi.tar.bz2 is to keep in sync with kernel Linux-4.4.0-kirkwood-tld-1.

Note step 4: The pogo E02 DTB must be appended to uImage:

Quote

4. Create uImage with embedded DTB for booting with older u-boots (2012 or earlier). Skip this step if you have installed the latest U-Boot for Kirkwood (or are installing this u-boot at the same time).

Please replace kirkwood-goflexnet.dtb below with the correct DTB name for your box (see the folder /media/sdb1/boot/dts).

Generate the uImage with DTB embedded inside:
cd /media/sdb1/boot
cp -a zImage-4.4.0-kirkwood-tld-1 zImage.fdt
cat dts/kirkwood-pogo_e02.dtb >> zImage.fdt
mv uImage uImage.orig
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-4.4.0-kirkwood-tld-1 -d zImage.fdt uImage
sync

2. Copy the kernel files to the tftp root where the serverip x.x.x.y is (assuming you're logged in to the serverip x.x.x.y, and the rootfs is mounted at /media/sdb1)

mkdir /tftproot
cp -a /media/sdb1/boot/uImage /tftproot
cp -a /media/sdb1/boot/uInitrd /tftproot

3. in stock u-boot

Set the root device in bootargs to point to the rootfs with root=LABEL=rootfs in bootargs. For example,

setenv bootargs 'console=ttyS0,115200 root=LABEL=rootfs rootdelay=10'

For the Pogo E02, Dockstar, GoFlex Net/Home, also set mtdparts variable (instead of a generic bootargs as above):

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

For other boxes, look for the mtdparts env in u-boot envs listing and set it accordingly (post the question if you're not sure how).

4. in stock u-boot

setenv ipaddr x.x.x.x
setenv serverip x.x.x.y 
tftp 0x800000 uImage
tftp 0x1100000 uInitrd

5. Boot

bootm 0x800000 0x1100000

DONE.

--------

Please see the serial console log posted by armless below for a running example.

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



Edited 9 time(s). Last edit at 08/23/2016 03:09AM by bodhi.

I ran into the same problem hanging while attempting to chainload, so found your posts and decided to bite the bullet on 1st stage, and it works, as in the device is not bricked, but booting into openwrt 15.05 was a no go. I need to figure out where to copy the zImage and dtb file. This could be the vague instructions at the end of the openwrt wiki

NOTE: Remember to note down the mac address before flashing 1st stage

Here is a transcript of the steps (connected via serial port) - I did the aligned image on another pogoplug which I used as tftp server (ip's and mac addresses are obscured)

U-Boot 2011.12 (Feb 20 2012 - 21:21:59)
Pogoplug E02

SoC:   Kirkwood 88F6281_A0
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  128 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Using egiga0 device
host 1.2.3.5 is alive


U-Boot 1.1.4 (Sep 28 2009 - 11:55:23) Cloud Engines v2.0 (3.4.16)

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 00690D60

Soc: 88F6281 A0 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB
DRAM Total size 256MB  16bit width
Flash:  0 kB
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:128 MB

CPU : Marvell Feroceon (Rev 1)
CLOUD ENGINES BOARD: PPV2

Streaming disabled
Write allocate disabled


USB 0: host mode
PEX 0: interface detected no Link.
Net:   egiga0 [PRIME], egiga1
Hit any key to stop autoboot:  0
CE>> mw 0x800000 0xffff 0x80000
CE>> tftpboot 0x800000 openwrt-kirkwood-pogo_e02-u-boot.al.kwb
Using egiga0 device
TFTP from server 1.2.3.5; our IP address is 1.2.3.4
Filename 'openwrt-kirkwood-pogo_e02-u-boot.al.kwb'.
Load address: 0x800000
Loading: #################################################################
         ######################################
done
Bytes transferred = 524288 (80000 hex)
CE>> nand erase 0x0 0xa4fff

NAND erase: device 0 offset 0x0, size 0xa4fff
Erasing at 0xa0000 -- 116% complete.
OK
CE>> nand write.e 0x800000 0x0 0x80000

NAND write: device 0 offset 0x0, size 0x80000

Writing data at 0x7f800 -- 100% complete.
 524288 bytes written: OK
CE>> reset


U-Boot 2014.10 (Jul 24 2015 - 20:11:30)
Pogo E02

SoC:   Kirkwood 88F6281_A0
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  128 MiB
NAND read from offset e0000 failed -74
*** Warning - readenv() failed, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   egiga0
Error: egiga0 address not set.

Hit any key to stop autoboot:  0
PogoE02> 
PogoE02> nand erase 0x200000 0x7e00000

NAND erase: device 0 offset 0x200000, size 0x7e00000
Erasing at 0x7fe0000 -- 100% complete.
OK
PogoE02> ubi part root ; ubi remove rootfs ; ubi create rootfs
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: empty MTD device detected
UBI: attached mtd1 (name "mtd=3", size 126 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
UBI: VID header offset: 512 (aligned 512), data offset: 2048
UBI: good PEBs: 1008, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 0, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 0
UBI: available PEBs: 984, total reserved PEBs: 24, PEBs reserved for bad PEB handling: 20
Volume rootfs not found!
No size specified -> Using max size (126959616)
Creating dynamic volume rootfs of size 126959616
PogoE02> tftpboot 0x800000 openwrt-15.05-kirkwood-pogoe02-rootfs.ubifs
*** ERROR: `ethaddr' not set
PogoE02>

PogoE02> setenv ethaddr 00:11:22:33:44:55
...
PogoE02> tftpboot 0x800000 openwrt-15.05-kirkwood-pogoe02-rootfs.ubifs
Using egiga0 device
TFTP from server 1.2.3.5; our IP address is 1.2.3.4
Filename 'openwrt-15.05-kirkwood-pogoe02-rootfs.ubifs'.
Load address: 0x800000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         ################################################
         5.4 MiB/s
done
Bytes transferred = 4515840 (44e800 hex)
PogoE02> ubi write 0x800000 rootfs ${filesize}
4515840 bytes written to volume rootfs
PogoE02> reset
resetting ...


U-Boot 2014.10 (Jul 24 2015 - 20:11:30)
Pogo E02

SoC:   Kirkwood 88F6281_A0
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  128 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
Hit any key to stop autoboot:  0
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: attached mtd1 (name "mtd=3", size 126 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
UBI: VID header offset: 512 (aligned 512), data offset: 2048
UBI: good PEBs: 1008, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 0
UBI: available PEBs: 0, total reserved PEBs: 1008, PEBs reserved for bad PEB handling: 20
** File not found /boot/zImage **
** File not found /boot/pogo_e02.dtb **
Unmounting UBIFS volume rootfs!
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
No FDT memory address configured. Please configure
the FDT address via "fdt addr <address>" command.
Aborting!
No FDT memory address configured. Please configure
the FDT address via "fdt addr <address>" command.
Aborting!
Bad Linux ARM zImage magic!
PogoE02>

bodhi Wrote:
-------------------------------------------------------
> Please post the entire serial console log here,
> whether it was successful or not. I'd like to make
> this a "Howto boot with tftp" tutorial.

Serial console output is attached.

It worked fine. Next step I guess is to grab "flash_erase" and "nandwrite" binaries to put onto the Debian USB so that I can then flash your (Bodhi's) U-Boot and default environment variables and fix them up with right MAC address, etc.

BTW during the Debian boot I noticed the following:

(1) the Debian USB stick is ext3 but there's such module in the initrd and the ext3 fsck failed, but it managed to mount the rootfs using ext4's backward compatibility, and to fsck it then:

modprobe: module ext3 not found in modules.dep
Begin: Checking root file system ... fsck from util-linux 2.25.2
fsck: error 2 (No such file or directory) while executing fsck.ext3 for /dev/sda1
fsck exited with status code 8
done.
Warning: File system check failed but did not detect errors
[   11.704264] EXT4-fs (sda1): mounting ext3 file system using the ext4 subsystem

(2) some kernel error about the Kirkwood hardware crypto:

[   13.563600] marvell-cesa: probe of f1030000.crypto failed with error -524

(3) after booting Debian the /etc/fw_env.config file didn't seem to have any real data, just a comment line:

root@debian:~# cat /etc/fw_env.config 
# MTD device name       Device offset   Env. size       Flash sector size       Num
root@debian:~#

armless,

> (1) the Debian USB stick is ext3 but there's such
> module in the initrd and the ext3 fsck failed, but
> it managed to mount the rootfs using ext4's
> backward compatibility, and to fsck it then:

This is normal. Ext3 has been deprecated. Ext4 module is always used whether the rootfs is Ext3 or Ext4.

> (2) some kernel error about the Kirkwood hardware
> crypto:
>
> [ 13.563600] marvell-cesa: probe of
> f1030000.crypto failed with error -524

This is known issue in 4.4. It was fixed in later version (e.g. 4.6)

>
> (3) after booting Debian the /etc/fw_env.config
> file didn't seem to have any real data, just a
> comment line:
>
> root@debian:~# cat /etc/fw_env.config
> # MTD device name Device offset Env. size
> Flash sector size Num

This should contain the env location. Something went wrong in your installation. To use it with the latest u-boot for Pogo E02, it should be:

# MTD device name	Device offset	Env. size	Flash sector size	Number of sectors
/dev/mtd0 0xc0000 0x20000 0x20000

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

bodhi Wrote:
-------------------------------------------------------
> This should contain the env location. Something
> went wrong in your installation. To use it with
> the latest u-boot for Pogo E02, it should be:
>
>

> # MTD device name	Device offset	Env. size	Flash
> sector size	Number of sectors
> /dev/mtd0 0xc0000 0x20000 0x20000
>

Actually it did have that line in the file, seems my console capture file was somehow truncated.

Have some free time now to finally sort this out once and for all. Now that TFTP booting is working I'm ready to go ahead with updating u-boot and also the default environment image.

Based on the "2016.05 U-Boot Kirkwood" forum thread I've scribbled down a simplified set of steps to perform. Before I hit the big button and start the whole procedure in action I've just a couple of minor clarifications:

(1) when (tftp) booted into Debian I noticed it sees only a single partition:

root@debian:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 08000000 00020000 "orion_nand"
root@debian:~#

rather than the typical 4 partitions and the mtd0 size is not 0x100000 (1M) but rather 0x8000000 (128M?). This seems to be some weird side-effect of my earlier attempt to get the OpenWRT 2nd-stage u-boot going. I did notice during this tftp boot that the output of "printenv" (from stock u-boot) and "fw_printenv" from Debian are quite different, Debian sees a lot more variables that don't exist at all in the u-boot printenv output.

However fw_env.conf does have the expected contents:

root@debian:~# cat /etc/fw_env.config 
# MTD device name	Device offset	Env. size	Flash sector size	Number of sectors
/dev/mtd0 0xc0000 0x20000 0x20000
root@debian:~#

But the u-boot environment, as seen by Debian, does have mtdparts indicating 4 partitions:

root@debian:~# fw_printenv | grep mtd
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
mtdids=nand0=orion_nand

This is at odds with U-Boot earlier in the boot where "printenv" did not show any mtdparts or mtdids variables.

Is these problematic issues or can I ignore them? I'm going to be writing the default u-boot environment image to NAND as well as flashing u-boot.

(2) The forum article about flashing the default environment variables recommends ext3 for rootfs:

r4. The rootfs partition is recommended to be type Ext3 (this is not a hard requirement, ext4 should boot OK, but Ext3 will ensure no problem).

As discussed in earlier postings in this thread, mine is ext4 and I assume there's no reason to change this.

(3) After flashing the default environment what do I set mtdparts to?

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

or

fw_setenv mtdparts 'mtdparts=orion_nand:128M(u-boot)'

based on the size (0x8000000) reported in /proc/mtd?

(4) The current kernel on the USB rootfs has DTB file merged into uImage so that stock u-boot can boot. In order to switch back to a "normal" seperate DTB file base dbooting then I assume after flashing the default environment I simple do this:

fw_setenv dtb_file '/boot/dts/kirkwood-pogo_e02.dtb'
mv /boot/uImage /boot/uImage.non-dtb
mv /boot/uImage.orig /boot/uImage

armless,

root@debian:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 08000000 00020000 "orion_nand"
root@debian:~#

This is because you've booted with a different u-boot, and u-boot envs. And the envs settign in that u-boot needs correction.

> But the u-boot environment, as seen by Debian,
> does have mtdparts indicating 4 partitions:
>
>

> root@debian:~# fw_printenv | grep mtd
> mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage)
> ,32M(rootfs),-(data)
> mtdids=nand0=orion_nand
>

>
> This is at odds with U-Boot earlier in the boot
> where "printenv" did not show any mtdparts or
> mtdids variables.
>
> Is these problematic issues or can I ignore them?
> I'm going to be writing the default u-boot
> environment image to NAND as well as flashing
> u-boot.

No you can not ignore them. You have to set the mtdparts correctly before flashing.

> As discussed in earlier postings in this thread,
> mine is ext4 and I assume there's no reason to
> change this.
>

Ext4 would work fine with the new default uboot envs.


> (4) The current kernel on the USB rootfs has DTB
> file merged into uImage so that stock u-boot can
> boot. In order to switch back to a "normal"
> seperate DTB file base dbooting then I assume
> after flashing the default environment I simple do
> this:
>
> fw_setenv dtb_file
> '/boot/dts/kirkwood-pogo_e02.dtb'
> mv /boot/uImage /boot/uImage.non-dtb
> mv /boot/uImage.orig /boot/uImage

Correct.

-----------

To set mtdparts correctly before flashing, post the output of

Interrupt serial console

printenv

tftp and boot like you did before and

dmesg
cat /proc/mtd

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

Output is attached (IPs, MAC obscured).

armless,

I've modified step 3 above to include mtdparts in bootargs:

http://forum.doozan.com/read.php?3,28772,29034#msg-29034

After booting into Debian, try

fw_printenv
cat /proc/mtd
cat /proc/cmdline

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



Edited 1 time(s). Last edit at 08/11/2016 03:24PM by bodhi.

CE>> setenv bootargs "$(console) root=LABEL=rootfs rootdelay=10 mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data) ro"
CE>> printenv bootargs
bootargs="console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data) ro"

root@debian:~# fw_printenv 
ethact=egiga0
bootdelay=3
baudrate=115200
mainlineLinux=yes
console=ttyS0,115200
led_init=green blinking
led_exit=green off
led_error=orange blinking
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
mtdids=nand0=orion_nand
partition=nand0,2
stdin=serial
stdout=serial
stderr=serial
rescue_installed=0
rescue_set_bootargs=setenv bootargs console=$console ubi.mtd=2 root=ubi0:rootfs ro rootfstype=ubifs $mtdparts $rescue_custom_params
rescue_bootcmd=if test $rescue_installed -eq 1; then run rescue_set_bootargs; nand read.e 0x800000 0x100000 0x400000; bootm 0x800000; else run pogo_bootcmd; fi
pogo_bootcmd=if fsload uboot-original-mtd0.kwb; then go 0x800200; fi
force_rescue=0
force_rescue_bootcmd=if test $force_rescue -eq 1 || ext2load usb 0:1 0x1700000 /rescueme.txt 1; then run rescue_bootcmd; fi
ubifs_mtd=3
ubifs_set_bootargs=setenv bootargs console=$console ubi.mtd=$ubifs_mtd root=ubi0:rootfs rootfstype=ubifs $mtdparts $ubifs_custom_params
ubifs_bootcmd=run ubifs_set_bootargs; if ubi part data && ubifsmount rootfs && ubifsload 0x800000 /boot/uImage && ubifsload 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; fi
usb_scan=usb_scan_done=0;for scan in $usb_scan_list; do run usb_scan_$scan; if test $usb_scan_done -eq 0 && ext2load usb $usb 0x800000 /boot/uImage 1; then usb_scan_done=1; echo "Found bootable drive on usb $usb"; setenv usb_device $usb; setenv usb_root /dev/$dev; fi; done
usb_scan_list=1 2 3 4
usb_scan_1=usb=0:1 dev=sda1
usb_scan_2=usb=1:1 dev=sdb1
usb_scan_3=usb=2:1 dev=sdc1
usb_scan_4=usb=3:1 dev=sdd1
usb_init=run usb_scan
usb_device=0:1
usb_root=/dev/sda1
usb_rootfstype=ext2
usb_rootdelay=10
usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params
usb_bootcmd=run usb_init; run usb_set_bootargs; run usb_boot
usb_boot=mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage; if ext2load usb $usb_device 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd;usb stop; run rescue_bootcmd; run pogo_bootcmd; reset
ethaddr=aa:bb:cc:dd:ee:ff
arcNumber=2097
preboot_nc=setenv nc_ready 0; for pingstat in 1 2 3 4 5; do; sleep 1; if run if_netconsole; then setenv nc_ready 1; fi; done; if test $nc_ready -eq 1; then run start_netconsole; fi
preboot=run preboot_nc
ipaddr=192.168.0.1
netmask=255.255.255.0
if_netconsole=ping $serverip
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
serverip=192.168.0.2

root@debian:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 08000000 00020000 "orion_nand"

root@debian:~# cat /proc/cmdline
"console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data) ro"

To refresh your memory, this machine started with the CloudEngines u-boot (as is normal).

A few years ago I put Doozan U-boot 2010.09 on it to boot Debian from USB with fallback (fsload) to the CloudEngines u-boot.

Recently I set up the OpenWRT 2nd stage U-boot as below (as per their Wiki):

mw 0x800000 0xffff 0x80000
tftpboot 0x800000 openwrt-kirkwood-pogo_e02_second_stage-u-boot.img
nand erase 0x100000 0x80000
nand write.e 0x800000 0x100000 0x80000

and this put their 2nd stage into 0x100000 which is normally mtd1. Rebooting loaded Doozan U-boot which then chainloaded the OpenWRT U-boot but this hung during startup (I think I forgot to "fw_saveenv" when I was installing & setting up the OpenWRT 2nd stage U-boot!).

You then helped me go back to the stock CloudEngines U-boot as follows:

flash_erase /dev/mtd0 0 4
nandwrite /dev/mtd0 uboot-original-mtd0.kwb

And that's how I got to where I am now (TFTPing uImage & uInitrd, then mounting Debian USB rootfs in order to try and now flash your U-Boot onto mtd0). Doh!

armless,

> root@debian:~# cat /proc/mtd
> dev: size erasesize name
> mtd0: 08000000 00020000 "orion_nand"
> [/code]
>
> root@debian:~# cat /proc/cmdline
> "console=ttyS0,115200 root=LABEL=rootfs
> rootdelay=10
> mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(root
> fs),-(data) ro"
>

This is really odd!

It meant that the mtparts in the bootargs was not applied. The mtdparts should show to be allocated during kernel booting. If it does not, then it would explain why there is only one mtd partition.

Please post output of dmesg.

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

bodhi Wrote:
-------------------------------------------------------
> Please post output of dmesg.

Attached.

armless,


I've attached a new DTB here.

1. Boot into Debian, and replace the current DTB with this one

/boot/dts/kirkwood-pogo_e02.dtb

2. Recreate uImage as you did before: append this new DTB to the original uImage

3. Reboot and this time remove mtdparts definition from bootargs

setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=10"

Basically, we are using the mtdparts from the DTB in this run. It should show 4 partitions when you do

cat/proc/mtd

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

bodhi Wrote:
-------------------------------------------------------
> Basically, we are using the mtdparts from the DTB
> in this run. It should show 4 partitions when you
> do
>

> cat/proc/mtd
>

No different in behaviour, /proc/mtd still just has a mtd0 line.

I double-checked the size of uImage to be 100% I'd updated it properly - its 22 bytes smaller than the previous uImage as the DTB you gave me was also 22 bytes smaller than the original one.