Welcome! Log In Create A New Profile

Advanced

Pogoplug v2 doesn't show up on LAN after Archlinux install

Posted by Waynosan 
For the record, this is what the http://archlinuxarm.org/os/armv5te/boot/pogo_e02/pogo_e02.sh U-Boot installer did (from within Stock, not preserving the original U-Boot but showing the layout at that point):
msg "saving MAC address"
mac=$(/tmp/blparam | grep ethaddr | cut -d= -f2)
if [[ $mac == '' ]]; then echo " [FAILED]"; exit 1; fi
echo " [$mac]"

msg "erasing U-Boot NAND"
try /tmp/flash_erase /dev/mtd0 0 4 > /dev/null
echo " [OK]"

msg "erasing environment"
try /tmp/flash_erase /dev/mtd0 0xc0000 1 > /dev/null
echo " [OK]"

msg "writing U-Boot"
try /tmp/nandwrite /dev/mtd0 uboot-pogo_e02.kwb > /dev/null
echo " [OK]"

msg "writing environment"
try /tmp/nandwrite -s 0xc0000 /dev/mtd0 uboot-pogo_e02.env > /dev/null
echo " [OK]"

echo ""
echo "Validating.."
/tmp/nanddump -nol 0x80000 -f /tmp/uboot-pogo_e02.kwb /dev/mtd0
/tmp/nanddump -nol 0x20000 -s 0xc0000 -f /tmp/uboot-pogo_e02.env /dev/mtd0

echo ""
msg "checking U-Boot"
try md5sum -cs uboot-pogo_e02.kwb.md5
echo " [OK]"

msg "checking environment"
try md5sum -cs uboot-pogo_e02.env.md5
echo " [OK]"

msg "setting MAC"
ln -s fw_printenv fw_setenv
mount -o remount,rw /
try echo "/dev/mtd0 0xc0000 0x20000 0x20000" > /etc/fw_env.config
mount -o remount,ro /
/tmp/fw_setenv ethaddr ${mac}
echo " [OK]"

echo ""
echo "U-Boot has been installed successfully."
Re: Pogoplug v2 doesn't show up on LAN after Archlinux install
March 18, 2015 01:31AM
TEN,

Yes, it is safe to flash 2014.07-tld-2 u-boot. I did look at this script before. It only erases and writes to mtd0. And the mtd definition left the rest of NAND intact, so chance is that stock Pogo OS will work out of NAND.

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 03/18/2015 01:55AM by bodhi.
bodhi Wrote:
-------------------------------------------------------
> Yes, it is safe to flash 2014.07-tld-2 u-boot. I
> did look at this script before. It only erases and
> writes to mtd0. And the mtd definition left the
> rest of NAND intact, so chance is that stock Pogo
> OS will work out of NAND.

Before:
[root@alarm tmp]# echo "/dev/mtd0 0xc0000 0x20000 0x20000" >> /etc/fw_env.config 
[root@alarm tmp]# fw_printenv
baudrate=115200
bootcmd=usb start; setenv letter 9;for type in usb; do for disk in 0 1 2 3; do if ${type} part ${disk};then setexpr letter $letter + 1;run load;fi;done;done;
bootdelay=3
bootm=echo Booting from ${disk} ...; run setargs; bootm ${loadaddr};
bootz=echo Booting from ${disk} ...; run setargs; bootz ${loadaddr} - ${fdt_addr};
console=ttyS0
fdt_addr=0x800000
fdt_file=/boot/dtbs/kirkwood-pogo_e02.dtb
importbootenv=echo Importing environment (uEnv.txt)...; env import -t $loadaddr $filesize
load=echo Attempting to boot from ${type} ${disk}:1...;if run loadbootenv; then run importbootenv;fi;echo Checking if uenvcmd is set ...;if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;echo Running default loadzimage ...;if run loadzimage; then run loadfdt;run bootz;fi;echo Running default loaduimage ...;if run loaduimage; then run bootm;fi;
loadaddr=0x810000
loadbootenv=load ${type} ${disk}:1 ${loadaddr} /boot/uEnv.txt
loadfdt=load ${type} ${disk}:1 ${fdt_addr} ${fdt_file}
loaduimage=load ${type} ${disk}:1 ${loadaddr} ${uimage}
loadzimage=load ${type} ${disk}:1 ${loadaddr} ${zimage}
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),-(rootfs)
setargs=setenv bootargs console=${console},${baudrate} ${optargs} root=/dev/sd${letter}1 rw rootwait ${mtdparts}
uimage=/boot/uImage
zimage=/boot/zImage
ethaddr=00:25:31:02:2C:CE
[root@alarm tmp]# nanddump -nf mtd0 /dev/mtd0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00100000...
Doing the dastardly deed:
[root@alarm tmp]# flash_erase /dev/mtd0 0 4
Erasing 128 Kibyte @ 60000 -- 100 % complete 
[root@alarm tmp]# nandwrite /dev/mtd0 uboot.2014.07-tld-2.pogo_e02.mtd0.kwb 
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
[root@alarm tmp]# fw_printenv
baudrate=115200
bootcmd=usb start; setenv letter 9;for type in usb; do for disk in 0 1 2 3; do if ${type} part ${disk};then setexpr letter $letter + 1;run load;fi;done;done;
bootdelay=3
bootm=echo Booting from ${disk} ...; run setargs; bootm ${loadaddr};
bootz=echo Booting from ${disk} ...; run setargs; bootz ${loadaddr} - ${fdt_addr};
console=ttyS0
fdt_addr=0x800000
fdt_file=/boot/dtbs/kirkwood-pogo_e02.dtb
importbootenv=echo Importing environment (uEnv.txt)...; env import -t $loadaddr $filesize
load=echo Attempting to boot from ${type} ${disk}:1...;if run loadbootenv; then run importbootenv;fi;echo Checking if uenvcmd is set ...;if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;echo Running default loadzimage ...;if run loadzimage; then run loadfdt;run bootz;fi;echo Running default loaduimage ...;if run loaduimage; then run bootm;fi;
loadaddr=0x810000
loadbootenv=load ${type} ${disk}:1 ${loadaddr} /boot/uEnv.txt
loadfdt=load ${type} ${disk}:1 ${fdt_addr} ${fdt_file}
loaduimage=load ${type} ${disk}:1 ${loadaddr} ${uimage}
loadzimage=load ${type} ${disk}:1 ${loadaddr} ${zimage}
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),-(rootfs)
setargs=setenv bootargs console=${console},${baudrate} ${optargs} root=/dev/sd${letter}1 rw rootwait ${mtdparts}
uimage=/boot/uImage
zimage=/boot/zImage
ethaddr=00:25:31:02:2C:CE
[root@alarm tmp]# fw_setenv preboot 'run preboot_nc'
[root@alarm tmp]# fw_setenv ipaddr    '192.168.2.94'
[root@alarm tmp]# fw_setenv serverip '192.168.2.101'
Looking good (then again that's what they kept saying on Apollo 13 ;)) ?
Jeff in http://forum.doozan.com/read.php?3,14 has two more lines - not needed?
fw_setenv if_netconsole 'ping $serverip'
fw_setenv start_netconsole 'setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;'
Now I guess before reboot the (mostly Arch) fw_env should receive some tweaking to ensure your U-Boot will also boot Debian and be able to fall back to Stock as well?
BTW, just for my understanding,
seeing the (unused?) addresses in between, is there anything in 0x80000-0xbffff and 0xe0000-0xfffff,
and why are the end addresses often rounded up (e.g. by the kernel dmesg itself) to show the MTD partitions as if they were overlapping by one byte (e.g. 0x000000100000 as both start and end) ?
Re: Pogoplug v2 doesn't show up on LAN after Archlinux install
March 18, 2015 03:19AM
TEN,

> Jeff in http://forum.doozan.com/read.php?3,14 has
> two more lines - not needed?

1. You do need all of these 5 lines for net console. Caution: the variable preboot_nc only exists afer you've flashed the default env image uboot.2014.07-tld-2.environment.img (see number 2 below)
[root@alarm tmp]# fw_setenv preboot 'run preboot_nc'
[root@alarm tmp]# fw_setenv ipaddr    '192.168.2.94'
[root@alarm tmp]# fw_setenv serverip '192.168.2.101'
fw_setenv if_netconsole 'ping $serverip'
fw_setenv start_netconsole 'setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;'

> Now I guess before reboot the (mostly Arch) fw_env
> should receive some tweaking to ensure your U-Boot
> will also boot Debian and be able to fall back to
> Stock as well?

2. There is a default envs image (uboot.2014.07-tld-2.environment.img) that you should flash (step 8 which refers to section B) because your current envs are for Arch u-boot. In effect, flashing from Arch is just like flashing from stock u-boot (even the envs location looks the same, the common convention for all of these versions). While I've made sure that this u-boot is a drop in replacement for Jeff ot davygravy u-boot, however, Arch u-boot was released recently so I would not count on it, and would flash the default envs and adjust the envs.

Note: I think I need to revise the instruction regarding this to make this point clear (it was written before Arch u-boot release).

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 03/18/2015 04:10AM by bodhi.
Re: Pogoplug v2 doesn't show up on LAN after Archlinux install
March 18, 2015 04:08AM
TEN,

And you also need to adjust the location of the DTB file:
fdt_file=/boot/dtbs/kirkwood-pogo_e02.dtb

It is getting anoying :) to see how difference from one distribution to another. This could cause someone to brick their box if not careful.

Please post your envs listing before you reboot.

-bodhi
===========================
Forum Wiki
bodhi's corner
bodhi Wrote:
-------------------------------------------------------
> > Jeff in http://forum.doozan.com/read.php?3,14
> has two more lines - not needed?
>
> 1. You do need all of these 5 lines for net
> console. Caution: the
> variable preboot_nc only exists afer you've
> flashed the default env image
> uboot.2014.07-tld-2.environment.img

I see, many thanks, will do when I get back to the Pogo hopefully still up and running.
Section A only had these 3.
Section B was referred to for devices other than E02 (i.e. those having a non-standard fw_env address) but then mentions E02 down there.

> default envs image (uboot.2014.07-tld-2.environment.img) that you
> should flash (step 8 which refers to section B)
> because your current envs are for Arch u-boot. In
> effect, flashing from Arch is just like flashing
> from Jeff/davygravy u-boot (the envs location is
> the common convention for all of these versions)...
> Arch u-boot was released recently so I would not
> count on it, and would flash the default envs and
> adjust the envs.

Still wondering what the 2 eraseblocks before and 1 after 0xc0000-effff are (reserved) for:
If both U-Boot and fw_envs need to be replaced, would there be anything wrong with flash_erase /dev/mtd0 0 8 ?
I recall the end-byte overlap (only just erroneously?) shown by kernel between adjacent MTD partitions already struck me as implausible when flashing other devices many years ago.

Additionally, which copy of the original U-Boot (if any) do I need to download and place where for the Stock fallback?
The above has to read "1 after 0xc0000-0xdffff" for the 7th (fw_env) eraseblock of course. About time I get myself an account to edit typos in posts even from the phone when discussing only the tricky bricky stuff... ;)

Quote
bodhi
It is getting anoying :) to see how difference from one distribution to another. This could cause someone to brick their box if not careful.
Hence the idea to deploy yours as "the One Ring (erm, U-Boot) to boot them all" (fallbacks included) in an installer that leaves fewer pitfalls and saves all the important data.

BTW why wrap an uncompressed tarball around the kwb images that only adds to their size (and needs to be removed so as not to "overflash" with a larger, unusable structure) at all?
So here we go for the fw_env to match your uBoot rather than Arch's:
[root@alarm tmp]# tar -xf uboot.2014.07-tld-2.environment.bodhi.tar
[root@alarm tmp]# flash_erase /dev/mtd0 0xc0000 1
Erasing 128 Kibyte @ c0000 -- 100 % complete 
[root@alarm tmp]# nandwrite -s 786432 /dev/mtd0 uboot.2014.07-tld-2.environment.img
Writing data to block 6 at offset 0xc0000
[root@alarm tmp]# fw_setenv arcNumber 3542
[root@alarm tmp]# fw_setenv machid dd6
[root@alarm tmp]# fw_setenv ethaddr 00:25:31:02:2C:CE
[root@alarm tmp]# fw_setenv ipaddr    '192.168.2.94'
[root@alarm tmp]# fw_setenv serverip '192.168.2.101'
[root@alarm tmp]# fw_setenv preboot 'run preboot_nc'
[root@alarm tmp]# fw_printenv
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
baudrate=115200
bootcmd=run bootcmd_uenv; run bootcmd_usb; run bootcmd_mmc; run bootcmd_sata; reset
bootcmd_mmc=run mmc_init; run set_bootargs_mmc; run mmc_boot
bootcmd_sata=run sata_init; run set_bootargs_sata; run sata_boot;
bootcmd_usb=run usb_init; run set_bootargs_usb; run usb_boot;
bootdelay=10
console=ttyS0,115200
device=0:1
ethact=egiga0
if_netconsole=ping $serverip
led_error=orange blinking
led_exit=green off
led_init=green blinking
mainlineLinux=yes
mmc_boot=mw 0x800000 0 1; run mmc_load_uimage; if run mmc_load_uinitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
mmc_init=mmc rescan
mmc_load_uimage=ext2load mmc $device 0x800000 /boot/uImage
mmc_load_uinitrd=ext2load mmc $device 0x1100000 /boot/uInitrd
mmc_root=/dev/mmcblk0p1
mtdids=nand0=orion_nand
partition=nand0,2
preboot_nc=run if_netconsole start_netconsole
rootdelay=10
rootfstype=ext3
sata_boot=mw 0x800000 0 1; run sata_load_uimage; if run sata_load_uinitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
sata_init=ide reset
sata_load_uimage=ext2load ide $device 0x800000 /boot/uImage
sata_load_uinitrd=ext2load ide $device 0x1100000 /boot/uInitrd
sata_root=/dev/sda1
set_bootargs_mmc=setenv bootargs console=$console root=$mmc_root rootdelay=$rootdelay rootfstype=$rootfstype $mtdparts
set_bootargs_sata=setenv bootargs console=$console root=$sata_root rootdelay=$rootdelay rootfstype=$rootfstype $mtdparts
set_bootargs_usb=setenv bootargs console=$console root=$usb_root rootdelay=$rootdelay rootfstype=$rootfstype $mtdparts
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
stderr=serial
stdin=serial
stdout=serial
usb_boot=mw 0x800000 0 1; run usb_load_uimage; if run usb_load_uinitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
usb_init=usb start
usb_load_uimage=ext2load usb $device 0x800000 /boot/uImage
usb_load_uinitrd=ext2load usb $device 0x1100000 /boot/uInitrd
usb_root=/dev/sda1
bootcmd_uenv=run uenv_load; if test $uenv_loaded -eq 1; then run uenv_import; fi
uenv_import=echo importing envs ...; env import -t 0x810000
uenv_load=usb start; mmc rescan; ide reset; setenv uenv_loaded 0; for devtype in usb mmc ide; do for disknum in 0; do run uenv_read_disk; done; done
uenv_read=echo loading envs from $devtype $disknum ...; if load $devtype $disknum:1 0x810000 /boot/uEnv.txt; then setenv uenv_loaded 1; fi
uenv_read_disk=if test $devtype -eq mmc; then if $devtype part; then run uenv_read;  fi; else if $devtype part $disknum; then run uenv_read; fi;  fi
arcNumber=3542
machid=dd6
ethaddr=00:25:31:02:2C:CE
ipaddr=192.168.2.94
serverip=192.168.2.101
preboot=run preboot_nc
What's missing I guess:
  • fw_setenv mtdparts 'xxxxxxxxx' where Arch's mismatched the actual NAND layout - are your uBoot fw_env's as above (starting with mtdparts=mtdparts=...) alright for Pogo E02?
  • fdt_file=/boot/dtbs/kirkwood-pogo_e02.dtb (in /boot/uEnv.txt, or as: fw_setenv fdt_file '/boot/dtbs/kirkwood-pogo_e02.dtb' ?) in order to enable Arch boot, or Debian?
  • Stock uBoot if yours needs to chainload for the Stock Pogo OS?
  • Settings from http://forum.doozan.com/read.php?3,12381 section "D.1 Modify u-boot envs"
So should I do all 4 of these before reboot too, or is it safe already and ought to launch Arch (as well as drop into internal Stock without USB) ?
"D.2 Add uEnv.txt to /boot directory" goes to the respective USB stick for both your Debian jessie FDT or Arch?
BTW the running Arch AFAICS only has /boot/uImage, i.e. no separate dtb either.
Its fw_env contained:
fdt_addr=0x800000
fdt_file=/boot/dtbs/kirkwood-pogo_e02.dtb
Re: Pogoplug v2 doesn't show up on LAN after Archlinux install
March 18, 2015 02:54PM
TEN,

1. mtdparts looks fine now in the envs. It is defined as the original layout, and it's in the bootargs.

2. DTB file /boot/dtbs/kirkwood-pogo_e02.dtb

You need to find this file in Arch rootfs to make sure. If it's not in the rootfs, then it probably is embedded inside uImage (if there is one).

3. Right now, your envs are all set to boot either a non-FDT kernel, or an FDT kernel with uImage that has embedded DTB.

So see if you can find out which type of Arch rootfs that you have. If there is no uImage in the rootfs, then it must be FDT with zImage, according to these envs:
bootm=echo Booting from ${disk} ...; run setargs; bootm ${loadaddr};
bootz=echo Booting from ${disk} ...; run setargs; bootz ${loadaddr} - ${fdt_addr};
load=echo Attempting to boot from ${type} ${disk}:1...;if run loadbootenv; then run importbootenv;fi;echo Checking if uenvcmd is set ...;if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;echo Running default loadzimage ...;if run loadzimage; then run loadfdt;run bootz;fi;echo Running default loaduimage ...;if run loaduimage; then run bootm;fi;

4. Modify u-boot envs

So at this point, it's all depending on the rootfs that you either need to do 4a or 4b as described in my kernel thread Kernel 3.18.5-kirkwood-tld-1 (Updated 07 Feb 2015)

5. As of right now, you can already boot with the non-FDT rootfs Debian-3.16.0-kirkwood-tld-2 (Updated 02 Sept 2014). And you can boot with an older Arch rootfs that is non-FDT.

6. To find out what the next step should be:

uname -a
ls -l /boot
ls -l /boot/dtbs
cat /proc/cpuinfo

-bodhi
===========================
Forum Wiki
bodhi's corner
bodhi wrote:

> 2. DTB file /boot/dtbs/kirkwood-pogo_e02.dtb
>
> You need to find this file in Arch rootfs to make sure.
> If it's not in the rootfs, then it probably is embedded inside uImage (if there is one).

/boot/uImage is actually all there is in current Arch.

> 3. Right now, your envs are all set to boot either
> a non-FDT kernel, or an FDT kernel with uImage
> that has embedded DTB.

> So see if you can find out which type of Arch
> rootfs that you have. If there is no uImage in the
> rootfs, then it must be FDT with zImage, according
> to these envs:
> bootm=echo Booting from ${disk} ...; run setargs;
> bootm ${loadaddr};
> bootz=echo Booting from ${disk} ...; run setargs;
> bootz ${loadaddr} - ${fdt_addr};
> load=echo Attempting to boot from ${type}
> ${disk}:1...;if run loadbootenv; then run
> importbootenv;fi;echo Checking if uenvcmd is set
> ...;if test -n $uenvcmd; then echo Running uenvcmd
> ...;run uenvcmd;fi;echo Running default loadzimage
> ...;if run loadzimage; then run loadfdt;run
> bootz;fi;echo Running default loaduimage ...;if
> run loaduimage; then run bootm;fi;
So these are what Arch had set, but all I'll need to do for both Arch & Debian is the following?
fw_setenv load_dtb 'ext2load usb 0:1 0x1c00000 /boot/dts/kirkwood-goflexnet.dtb'    
fw_setenv load_initrd 'ext2load usb 0:1 0x1100000 /boot/uInitrd'
fw_setenv load_uimage 'ext2load usb 0:1 0x800000 /boot/uImage'
fw_setenv usb_boot 'run load_dtb; run load_uimage; if run load_initrd; then bootm 0x800000 0x1100000 0x1c00000; else bootm 0x800000 - 0x1c00000; fi'
Once that's done, should I just reboot and see the netconsole come to life (or does it need a fw_setenv netmask even for 255.255.255.0) ?
I.e. "D.1 Modify u-boot envs" incl. setenv devices in addition to device is not required,
and without further changes the above setup will boot uImage whether the DTB is separate or embedded?

"4b. Boot with DTB file embedded in the kernel image (no U-Boot envs change needed)" is not available for FDT?
So I should take the 4a route but will need to make sure I place /boot/dts/kirkwood-goflexnet.dtb (or /boot/dtbs/kirkwood-goflexnet.dtb ?) on all USB media (or does it autodetect embedded DTBs, even in Arch) ?

> 6. To find out what the next step should be:
[root@alarm ~]# uname -a
Linux alarm 3.19.1-2-ARCH #1 PREEMPT Mon Mar 16 05:48:43 MDT 2015 armv5tel GNU/Linux
[root@alarm ~]# ls -l /boot
total 3964
-rw-r--r-- 1 root root 4054992 Mar 16 11:51 uImage
[root@alarm ~]# ls -l /boot/dtbs
ls: cannot access /boot/dtbs: No such file or directory
[root@alarm ~]# cat /proc/cpuinfo
processor	: 0
model name	: Feroceon 88FR131 rev 1 (v5l)
BogoMIPS	: 1191.11
Features	: swp half thumb fastmult edsp 
CPU implementer	: 0x56
CPU architecture: 5TE
CPU variant	: 0x2
CPU part	: 0x131
CPU revision	: 1

Hardware	: Pogoplug E02
Revision	: 0000
Serial		: 0000000000000000
Just in case anything goes wrong about USB, how do I define a fallback into stock Pogo OS already?
Always kirkwood-pogo_e02.dtb for my machine of course, from Debian-3.18.5-kirkwood-tld-1-rootfs-bodhi.tar.bz2, rather than the example's kirkwood-goflexnet.dtb
Re: Pogoplug v2 doesn't show up on LAN after Archlinux install
March 18, 2015 05:35PM
TEN,

The lack of DTB file kirkwood-pogo_e02.dtb and cpuinfo do seem to indicate your rootfs is non-FDT:

[root@alarm ~]# cat /proc/cpuinfo
processor	: 0
model name	: Feroceon 88FR131 rev 1 (v5l)
BogoMIPS	: 1191.11
Features	: swp half thumb fastmult edsp 
CPU implementer	: 0x56
CPU architecture: 5TE
CPU variant	: 0x2
CPU part	: 0x131
CPU revision	: 1

Hardware	: Pogoplug E02
Revision	: 0000
Serial		: 0000000000000000

To confirm it
ls -l /proc/device-tree/

PS.

This does not make sense:
[root@alarm ~]# ls -l /boot
total 3964
-rw-r--r-- 1 root root 4054992 Mar 16 11:51 uImage
Is this the only file in /boot?

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 03/18/2015 05:37PM by bodhi.
bodhi Wrote:
-------------------------------------------------------
> The lack of DTB file kirkwood-pogo_e02.dtb and
> cpuinfo do seem to indicate your rootfs is non-FDT

I.e. I could now reboot into that without further changes (as would be required for FDT) ?

> To confirm it
[root@alarm ~]#  ls -l /proc/device-tree/
ls: cannot access /proc/device-tree/: No such file or directory
[root@alarm ~]# ls -al /boot
total 3972
drwxr-xr-x  2 root root    4096 Mar 17 18:16 .
drwxr-xr-x 17 root root    4096 Mar 17 00:25 ..
-rw-r--r--  1 root root 4054992 Mar 16 11:51 uImage
> This does not make sense:
> Is this the only file in /boot?
In the booted Arch on a USB stick made from http://archlinuxarm.org/os/ArchLinuxARM-kirkwood-latest.tar.gz, yes.

I understand from the very old http://www.dslreports.com/forum/r24833189-Other-Seagate-DockStar-U-Boot-NAND-flash-considerations#24834699 the fallback had been accomplished like this - so where does the uboot-original-mtd0.kwb have to go?
bootcmd=run bootcmd_usb; run bootcmd_ubi; run bootcmd_pogo; reset

bootcmd_ubi=run set_bootargs_ubi; ubi part data; ubifsmount rootfs; ubifsload 0x800000 /boot/uImage; ubifsload 0x1100000 /boot/uInitrd; bootm 0x800000 0x1100000

bootcmd_pogo=fsload uboot-original-mtd0.kwb; go 0x800200

bootcmd_usb=run usb_init; run usb_load_uimage; run set_bootargs_usb; run usb_boot;
Re: Pogoplug v2 doesn't show up on LAN after Archlinux install
March 18, 2015 06:26PM
TEN,

> I.e. I could now reboot into that without further
> changes (as would be required for FDT) ?

> [root@alarm ~]# ls -l /proc/device-tree/
> ls: cannot access /proc/device-tree/: No such file
> or directory

OK. So it is non-FDT. You can reboot. But before doing that, I would confirm the connection by doing a few pings

- On the Pogo, ping the netconsole server 192.168.2.101
- On netconsole server, ping the Pogo 192.168.2.94
- Start netconsole server
- Reboot

On the question about booting Pogo OS, I've mentioned previously above that you should follow graymanforhire's instruction for it. It's somewhere in the forum that he provided a link to his blog.

I've never been interested in using the Pogo OS so I don't want to give advice because I might miss some details. One of my boxes is actually falling back that way (with Pogo processes killed permanently), since it was installed with Jeff's script a few years ago. Another box uses Jeff's rescue system. The rest of my plugs farm don't have any rescue mechanism other than netconsole or or serial console. FWIW, I think Pogoplug service is pretty lousy and unsecure so I never use it.

PS.

About your other questions, how about getting the Pogo boot first and we'll cover them. I've lost track with many questions in different topics :)

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 3 time(s). Last edit at 03/18/2015 07:47PM by bodhi.
bodhi wrote:
> > I.e. I could now reboot into that without further
> > changes (as would be required for FDT) ?
> > ls: cannot access /proc/device-tree/: No such file or directory
> OK. So it is non-FDT. You can reboot.
Many thanks for your help&code! The good news is:
$ nc -ul 6666

U-Boot 2014.07-tld-2 (Sep 20 2014 - 00:52:18)
Pogo E02
gcc (Debian 4.6.3-14) 4.6.3
GNU ld (GNU Binutils for Debian) 2.22
Hit any key to stop autoboot:  0 
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 4 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Unknown command 'mmc' - try 'help'
Unknown command 'ide' - try 'help'

Partition Map for USB device 0  --   Partition Type: DOS

Part	Start Sector	Num Sectors	UUID		Type
  1	2968      	15254632  	d22025c5-01	0b
loading envs from usb 0 ...
** File not found /boot/uEnv.txt **
Unknown command 'mmc' - try 'help'
Unknown command 'ide' - try 'help'
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 4 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
4054992 bytes read in 406 ms (9.5 MiB/s)
** File not found /boot/uInitrd **
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-3.19.1-2-ARCH
   Created:      2015-03-16  11:48:59 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4054928 Bytes = 3.9 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK


Starting kernel ...
socat udp-recv:6666 -
seems to work too from Ubuntu 14.04 LTS,
but just like nc mostly intermittently,
and I've yet to get uBoot to become interactive on a keystroke over netconsole.

> About your other questions, how about getting the
> Pogo boot first and we'll cover them. I've lost
> track with many questions in different topics :)
Re: Pogoplug v2 doesn't show up on LAN after Archlinux install
March 18, 2015 08:06PM
Cool!

On Ubuntu you might need netcat traditional. And:

nc -lup 6666 <pogoipaddr> 6666

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: Pogoplug v2 doesn't show up on LAN after Archlinux install
March 19, 2015 03:09PM
@TEN,

Here is my recommendation: you should install Jeff/davygravy rescue system if you don't care for Pogoplug service. These systems are much more robust with newer kernel and installed utilities.

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 03/19/2015 03:13PM by bodhi.
Re: Pogoplug v2 doesn't show up on LAN after Archlinux install
March 19, 2015 03:19PM
Quote

Still wondering what the 2 eraseblocks before and 1 after 0xc0000 are (reserved) for:
If both U-Boot and fw_envs need to be replaced, would there be anything wrong with flash_erase /dev/mtd0 0 8 ?

Must only erase first 4 blocks to install u-boot. The stock envs and the new envs are in the second 4 blocks in mtd0. They don't occupy the entire area, but the free blocks in between should be reserved for future growth (in case u-boot got too big).

-bodhi
===========================
Forum Wiki
bodhi's corner
Quote
bodhi
On Ubuntu you might need netcat traditional. And:
nc -lup 6666 <pogoipaddr> 6666
Had been using that, though without the -l as its manpage says that must not be alongside -p.

Hammering Enter a few times during the countdown did the trick, while socat would often exit on keystrokes.

Arch boots just fine.

Will try your Debians next - should be much easier now having netconsole available. :)

Placed uboot-original-mtd0.kwb with md5sum b2d9681ef044e9ab6b058ef442b30b6e (not sure if that's the best one for E02, or rather http://download.doozan.com/uboot/files/uboot/uboot.mtd0.pinkpogo.original.kwb which I also put next to the other) into the root of
mkdir /mnt/nand;modprobe mtdblock;mount -t jffs2 /dev/mtdblock2 /mnt/nand
but no luck falling back into stock just yet (asked grayman4hire how he did it on V2, as I could only find his threads for V4 & installing Pogo services into Debian or Arch, but he recommends Jeff's uBoot instead - though how would that work for recent FDTs at all?):
fsload uboot-original-mtd0.kwb
get_fl_mem: unknown device type, using raw offset!
...keeps repeating, sometimes never returning...
get_fl_mem: unknown device type, using raw offset!
 done.
find_inode failed for name=uboot-original-mtd0.kwb
load: Failed to find inode
### JFFS2 LOAD ERROR<0> for uboot-original-mtd0.kwb!
Similar messages have also been seen in http://forum.doozan.com/read.php?3,12381,17526#msg-17526 et seq.

The way Arch following its uBoot mistreated the 2nd through 4th MTD partition, these might indeed need to be reflashed, but I wouldn't want to proceed with this before ruling out other causes, as http://archlinuxarm.org/forum/viewtopic.php?f=58&t=7558 seems inconclusive either, http://forum.doozan.com/read.php?3,998,1460 doesn't make clear which architecture it refers to, and both of the above kwb images go no further than this:
PogoE02> $usb_init
 $ u s b _ i n i t 
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 4 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
PogoE02> ext2load usb $device 0x800000 /uboot-original-mtd0.kwb
 e x t 2 l o a d   u s b   $ d e v i c e   0 x 8 0 0 0 0 0   / u b o o t - o r i g i n a l - m t d 0 . k w b 
524288 bytes read in 200 ms (2.5 MiB/s)
PogoE02> go 0x800200
 g o   0 x 8 0 0 2 0 0 
## Starting application at 0x00800200 ...
Of course I've made it plain in http://archlinuxarm.org/forum/viewtopic.php?f=30&t=8383#p46012 how Arch's approach wasn't exactly helpful.

As I could not find any recovery images for E02 mtds1-3 or the entire NAND, I wonder if all but mtd0 are identical bit for bit across V2s, since I happen to have access to more of these black "pink Pogos" in other places.
Re: Pogoplug v2 doesn't show up on LAN after Archlinux install
March 19, 2015 05:17PM
bodhi Wrote:
-------------------------------------------------------
> @TEN,
>
> Here is my recommendation: you should install
> Jeff/davygravy rescue system if you don't care for
> Pogoplug service. These systems are much more
> robust with newer kernel and installed utilities.

Agreed. Or moonman's arch version.
Re: Pogoplug v2 doesn't show up on LAN after Archlinux install
March 19, 2015 06:14PM
TEN Wrote:
-------------------------------------------------------
>
Quote
bodhi
On Ubuntu you might need netcat
> traditional. And:
>
nc -lup 6666 <pogoipaddr>
> 6666
> Had been using that, though without the -l as its
> manpage says that must not be alongside -p.
>
> Hammering Enter a few times during the countdown
> did the trick, while socat would often exit on
> keystrokes.
>
> Arch boots just fine.
>
> Will try your Debians next - should be much easier
> now having netconsole available. :)
>
> Placed uboot-original-mtd0.kwb with md5sum
> b2d9681ef044e9ab6b058ef442b30b6e (not sure if
> that's the best one for E02, or rather
> http://download.doozan.com/uboot/files/uboot/uboot
> .mtd0.pinkpogo.original.kwb which I also put next
> to the other) into the root of
>
mkdir /mnt/nand;modprobe mtdblock;mount -t
> jffs2 /dev/mtdblock2 /mnt/nand
> but no luck falling back into stock just yet
> (asked grayman4hire how he did it on V2, as I
> could only find his threads for V4 & installing
> Pogo services into Debian or Arch, but he
> recommends Jeff's uBoot instead - though how would
> that work for recent FDTs at all?):
>
fsload uboot-original-mtd0.kwb
> get_fl_mem: unknown device type, using raw
> offset!
> ...keeps repeating, sometimes never returning...
> get_fl_mem: unknown device type, using raw
> offset!
>  done.
> find_inode failed for
> name=uboot-original-mtd0.kwb
> load: Failed to find inode
> ### JFFS2 LOAD ERROR<0> for
> uboot-original-mtd0.kwb!
Similar messages
> have also been seen in
> http://forum.doozan.com/read.php?3,12381,17526#msg
> -17526 et seq.
>
> The way Arch following its uBoot mistreated the
> 2nd through 4th MTD partition, these might indeed
> need to be reflashed, but I wouldn't want to
> proceed with this before ruling out other causes,
> as
> http://archlinuxarm.org/forum/viewtopic.php?f=58&t
> =7558 seems inconclusive either,
> http://forum.doozan.com/read.php?3,998,1460
> doesn't make clear which architecture it refers
> to, and both of the above kwb images go no further
> than this:
>
PogoE02> $usb_init
>  $ u s b _ i n i t 
> (Re)start USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... 4 USB Device(s)
> found
>        scanning usb for storage devices... 1
> Storage Device(s) found
> PogoE02> ext2load usb $device 0x800000
> /uboot-original-mtd0.kwb
>  e x t 2 l o a d   u s b   $ d e v i c e   0 x 8 0
> 0 0 0 0   / u b o o t - o r i g i n a l - m t d 0
> . k w b 
> 524288 bytes read in 200 ms (2.5 MiB/s)
> PogoE02> go 0x800200
>  g o   0 x 8 0 0 2 0 0 
> ## Starting application at 0x00800200 ...
> Of course I've made it plain in
> http://archlinuxarm.org/forum/viewtopic.php?f=30&t
> =8383#p46012 how Arch's approach wasn't exactly
> helpful.
>
> As I could not find any recovery images for E02
> mtds1-3 or the entire NAND, I wonder if all but
> mtd0 are identical bit for bit across V2s, since I
> happen to have access to more of these black "pink
> Pogos" in other places.

Yes, you could dump mtd0 on the other Pogo and restore it. But then doing that will introduce the risk of bricking it. So chainload the dockstar orginal u-boot is the best course. Or just forget about stock, use rescue system on this box.

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: Pogoplug v2 doesn't show up on LAN after Archlinux install
March 19, 2015 11:00PM
grayman4hire,

> Agreed. Or moonman's arch version.

Yes. I like what moonman did very much. Having latest kernel for a rescue system? fantastic!!!. I would go for that just in case I need to use it.

But TEN needs to go back to 2 MTD partitions for that. Which is not a bad thing any mean, as I said I would do it for my personal boxes.

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 03/19/2015 11:05PM by bodhi.
Quote
bodhi
Quote
TEN
Arch's approach wasn't exactly helpful [not backing up NAND partitions but booting with divergent layout].

As I could not find any recovery images for E02 mtds1-3 or the entire NAND, I wonder if all but mtd0 are identical bit for bit across V2s, since I happen to have access to more of these black "pink Pogos" in other places.
Yes, you could dump mtd0 on the other Pogo and restore it. But then doing that will introduce the risk of bricking it.
Actually I'm fine with your uBoot (that would also let me set Arch's partitioning). mtd0 is probably the one different between units due to ethaddr etc. in the fw_env?

Quote

So chainload the dockstar orginal u-boot is the best course.
Couldn't get that to work yet through either fsload from nand0,2 or ext2load from usb - which is why I was rather thinking about whether mtd1, mtd2 &mtd3 could be carried over 1:1 from a similar Pogoplug (i.e. keeping mtd0 as it is, or is it in another partition where Cloud Engines differentiates individual V2 machines?).

Quote

Quote

Or just forget about stock, use rescue system on this box.
I like what moonman did very much. Having latest kernel for a rescue system? fantastic!!!. I would go for that just in case I need to use it.

But TEN needs to go back to 2 MTD partitions for that. Which is not a bad thing any mean, as I said I would do it for my personal boxes.
Of course it'll be useful e.g. for supporting everything up to ext4 (that Arch likes to use) and plenty of USB hardware.

I might actually try this or another rescue system (just to have some fallback I can ssh into) in the instant case if stock is damaged from Arch indeed and remains unbootable even from your uBoot.

What I liked less was the attitude at Arch of ignoring that NAND might hold something useful in many cases, just appropriating it "come what may"
(while other uBoots like yours and distros are criticized in the Arch threads for being more considerate)
without so much as a hint at backing it up (non-trivial as certain versions of nanddump/nandwrite around seem to differ in their handling of OOB bytes)
though Arch and its uBoot affect more than just mtd0,
then just telling users that serial cables are cheap
when they might not have an identical Pogo as "donor" for the old NAND contents
(let alone the urge to pry open and wire up boxes rather than back up what will be discarded at flash),
or a V2 that would even require JTAG if anything goes very wrong.
Re: Pogoplug v2 doesn't show up on LAN after Archlinux install
March 20, 2015 02:35AM
TEN,

> As I could not find any recovery images for E02
> mtds1-3 or the entire NAND, I wonder if all but
> mtd0 are identical bit for bit across V2s, since I
> happen to have access to more of these black "pink
> Pogos" in other places.

Yes. They are identical.

> with your uBoot (that would also let me set Arch's
> partitioning). mtd0 is probably the one different
> between units due to ethaddr etc. in the fw_env?

Yes (also Pogo ID is different too, in envs). Everything about u-boot is in mtd0. So you can use same mtd1,2,3 for all.

> or is it in another
> partition where Cloud Engines differentiates
> individual V2 machines?).

Only mtd0.

> (non-trivial as certain versions of
> nanddump/nandwrite around seem to differ in their
> handling of OOB bytes)

Good point.

> or a V2 that would even require JTAG if anything
> goes very wrong.

This is quite important a warning. The GF Home/Net, PogoV4/Mobile, NSA32x and some Netgear have UART booting. Dockstar, iConnect, and Pogo E02 don't seem to have a way to do that (never say never of course). So my disclaimer always states that UART should be tried.

-bodhi
===========================
Forum Wiki
bodhi's corner
bodhi Wrote:
> > As I could not find any recovery images for E02
> > mtds1-3 or the entire NAND, I wonder if all but
> > mtd0 are identical bit for bit across V2s
> Yes. They are identical.

Whoever has (a working URL for) V2 Pogo E02 MTDs 0-3 (or their md5sums) already, please let me know as I'll gladly save myself the hassle of extracting from boxes offline hundreds of miles away...

> > with your uBoot (that would also let me set
> Arch's
> > partitioning). mtd0 is probably the one
> different
> > between units due to ethaddr etc. in the
> fw_env?
>
> Yes (also Pogo ID is different too, in envs).
> Everything about u-boot is in mtd0. So you can use
> same mtd1,2,3 for all.

> > partition where Cloud Engines differentiates
> > individual V2 machines?
> Only mtd0.

I.e. I'll keep your uBoot for the time being.

On your uBoot's netconsole, entering things such as
nand0,1
setenv mtdparts ...
setenv devices ...
will be passed on to the system booted from there but NOT persist through a reboot in the environment unless I do an explicit saveenv (i.e. Debian, Arch or Stock won't invoke that on their own at shutdown?) - so can be tried without a risk of bricking (as nothing gets written to 0xC0000 from there)?

BTW does http://forum.doozan.com/read.php?3,14,18202#msg-18202 mean I actually ought to run a second instance (with same ports or which else?) of
nc -up 6666 192.168.2.94 6666
that might let me see something beyond the following?
>  g o   0 x 8 0 0 2 0 0 
> ## Starting application at 0x00800200 ...

> > (non-trivial as certain versions of
> > nanddump/nandwrite around seem to differ in
> their
> > handling of OOB bytes)
>
> Good point.

Is there an indication in any of their outputs that can be seen without affecting the NAND to tell the 2 flavours apart?
Or is it safe to assume that all of those currently in use by both Jeff's and Arch's installer, as well as both Debian and Arch themselves (including the respective rescue systems) exhibit identical behaviour?

> > or a V2 that would even require JTAG if anything
> > goes very wrong.
>
> This is quite important a warning.

Wish Arch had said more about what they were about to do or omit - could have spared many of us weeks of headaches, judging from the threads (in particular with respect to NAND layout & backup).
Re: Pogoplug v2 doesn't show up on LAN after Archlinux install
March 20, 2015 10:17AM
TEN Wrote:
-------------------------------------------------------
>
Quote
TEN
>
> What I liked less was the attitude at Arch of
> ignoring that NAND might hold something useful in
> many cases, just appropriating it "come what may"
> (while other uBoots like yours and distros are
> criticized in the Arch threads for being more
> considerate)
> without so much as a hint at backing it up
> (non-trivial as certain versions of
> nanddump/nandwrite around seem to differ in their
> handling of OOB bytes)
> though Arch and its uBoot affect more than just
> mtd0,
> then just telling users that serial cables are
> cheap
> when they might not have an identical Pogo as
> "donor" for the old NAND contents
> (let alone the urge to pry open and wire up boxes
> rather than back up what will be discarded at
> flash),
> or a V2 that would even require JTAG if anything
> goes very wrong.

You can not blame the archlinuxarm team really. Their uBoot is for ALARM and it works fine for that. Yes, I agree, it should support Debian by default, but maybe they want people using ALARM and not Debian :)

Regarding how the archlinuxarm uboot handles the NAND partition, I'm not sure if you're aware, but all the original data is left intact. It's not like they formatted the NAND or anything so there is no need for "backing it up". If you want the original mtdparts layout, then it's just one simple setenv command. The original Pogoplug OS will be intact (and bootable if you can figure out the uboot commands)..
Quote
grayman4hire
Quote
TEN
What I liked less was the attitude at Arch of ignoring that NAND might hold something useful in many cases, just appropriating it "come what may" (while other uBoots like yours and distros are criticized in the Arch threads for being more considerate) without so much as a hint at backing it up (non-trivial as certain versions of nanddump/nandwrite around seem to differ in their handling of OOB bytes) though Arch and its uBoot affect more than just mtd0 ...
You can not blame the archlinuxarm team really.
I don't, really, as a grateful user of their software 24/7 for years, I've just voiced some benevolent criticism on how some of this got communicated (in both tone and content), given that there are threads all over the place, including this forum and theirs, indicating Arch's approach turned into a trap for many people.

Quote

Their uBoot is for ALARM and it works fine for that.
Yes, I agree, it should support Debian by default, but maybe they want people using ALARM and not Debian :)

Regarding how the archlinuxarm uboot handles the NAND partition, I'm not sure if you're aware, but all the original data is left intact. It's not like they formatted the NAND or anything so there is no need for "backing it up".
Well, there's mtd0 for starters, without which on file (quite literally) the rest of the NAND couldn't be booted even if Arch's uBoot had fsload. I never claimed the other MTDs get hurt purposefully, but see below for when things do go wrong.

Quote

If you want the original mtdparts layout, then it's just one simple setenv command. The original Pogoplug OS will be intact (and bootable if you can figure out the uboot commands).
Unfortunately only if it hasn't been mounted - arguably this exact danger could not be envisaged and is complicated by a bug that gets the ro option ignored as documented on http://archlinuxarm.org/forum/viewtopic.php?f=18&t=3490&start=10#p20032 actually: The "JFFS2 partition" out of mtd1+2+3 combined gets mounted rw, and broken in the process (flooding the syslog with purported NAND errors that actually aren't, as a side effect).
I could track it down to that and find out this much from deep within existing threads, but a little advance warning on where Arch breaks long-standing conventions might have prevented unnecessary hardship for me and all those who started these threads in the first place.
Arguably if there weren't multi-year intervals between my opportunities to reflash ARMs, I might have been more observant of potential complications, but then again most users will only (have to) do this once, to their one and only machine, and without e.g. (genuine where Windows is involved) Prolific & BusPirate at hand.
Quote
grayman4hire
Regarding how the archlinuxarm uboot handles the NAND partition, I'm not sure if you're aware, but all the original data is left intact. It's not like they formatted the NAND or anything so there is no need for "backing it up".
BTW 2 of the partitions look like this, quite unusual for
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data):
[root@alarm ~]# uname -a;hexdump -C /dev/mtd1ro;hexdump -C /dev/mtd3ro
Linux alarm 3.19.1-2-ARCH #1 PREEMPT Mon Mar 16 05:48:43 MDT 2015 armv5tel GNU/Linux
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00400000
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
05b00000
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00400000
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
05b00000
Guess there's more to making them "bootable if I can figure out the uboot commands" (as you had put it).

This being the "uBoot Forum" BTW if the headline is any guide, ;-) help in "figuring things out" continues to be much appreciated.
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: