Hello - I have a Pogo E02 that I used for a while with Arch linux from USB(or at least that is what I thought). I couldn't find the USB used with that, but was able to login using ssh. I would like to install debian on this and connect a few drives.

I tried to follow instructions to install uboot, but found that I was getting various errors - like wget invalid or an older version that doesn't seem to support https. I was running ./install_uboot_mtd0.sh script to get uboot installed. I am guessing I have a really old version of the pogoplug stock FW as it doesn't seem to have fw_printenv

If you agree, type 'ok' and press ENTER to continue: ok
# checking for /usr/sbin/nandwrite...

# Installing /usr/sbin/nandwrite...
Connecting to download.doozan.com (45.77.104.33:80)
wget: not an http or ftp url: https://download.doozan.com/uboot/nandwrite.md5
Connecting to download.doozan.com (45.77.104.33:80)
wget: not an http or ftp url: https://download.doozan.com/uboot/nandwrite.md5
## Could not install /usr/sbin/nandwrite from http://download.doozan.com/uboot/nandwrite, exiting.

Is there anyway I can get this updated to install the latest uboot? I was trying to see if this is the easiest option or something like openwrt (which seems to need serial flash)

Thanks

When I login I see command prompt "-bash-3.2#"

I went thrugh instructions for 2017 version of uboot install. Couldn't make much progress as my system seem to fail at commands like "flash_erase" as those are not found on my system. System does have "nandwrite". I was curious if I should just do a "nandwrite" using kwb file and then copy the environment from the following as I can't execute most of the commands mentioned in the following thread

https://forum.doozan.com/read.php?3,12381

when I do "cat /proc/mtd", I see the following (I also ran a few commands with output below on the current state of the system)

-bash-3.2# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 02000000 00020000 "root"
mtd3: 05b00000 00020000 "data"
-bash-3.2# cat /proc/cpuinfo
Processor       : ARM926EJ-S rev 1 (v5l)
BogoMIPS        : 1192.75
Features        : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1
Cache type      : write-back
Cache clean     : cp15 c7 ops
Cache lockdown  : format C
Cache format    : Harvard
I size          : 16384
I assoc         : 4
I line length   : 32
I sets          : 128
D size          : 16384
D assoc         : 4
D line length   : 32
D sets          : 128

Hardware        : Feroceon-KW
Revision        : 0000
Serial          : 0000000000000000
-bash-3.2# printenv
TERM=xterm
SHELL=/bin/bash
SSH_TTY=/dev/pts/0
USER=root
PATH=/usr/bin:/bin
PWD=/tmp
SHLVL=1
HOME=/root
LOGNAME=root
SSH_CONNECTION=xxx.xx.xx.xx xxxx xxx.xx.xx.yy
_=/bin/printenv
OLDPWD=/bin
-bash-3.2# free
              total         used         free       shared      buffers
  Mem:       256008        23892       232116            0            0
 Swap:            0            0            0
Total:       256008        23892       232116
-bash-3.2# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/mtdblock2           32.0M     15.8M     16.2M  49% /
none                    125.0M      1.8M    123.2M   1% /tmp

mtd3 seems different from what was mentioned in that thread, but otherwise it looks the same.

mark,

Quote

I went thrugh instructions for 2017 version of uboot install. Couldn't make much progress as my system seem to fail at commands like "flash_erase" as those are not found on my system. System does have "nandwrite". I was curious if I should just do a "nandwrite" using kwb file and then copy the environment from the following as I can't execute most of the commands mentioned in the following thread

Installing from stock OS, you would need to do this preparation as described in the u-boot installation:

Quote

A. Flashing Instruction:

Installation is the same for each u-Boot image, the instruction below is written to include all boxes. So choose the platform name that you are installing for, and copy/paste the appropriate commands.

If you are running kernel that do not provide mtd-utils and uboot-tools (fw_setenv, fw_printenv, flash_erase, nandwrite), you can download the NAND and U-Boot tools binaries here in this thread.

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

Thanks Bodhi

I copied the binaries over. Now I get the following with printenv. Just wanted to make sure that is okay

./fw_printenv
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
-bash-3.2# ./fw_printenv ethaddr
Warning: Bad CRC, using default environment
## Error: "ethaddr" not defined

Look like there are some badblocks based on dmesg

[    1.050000] Scanning device for bad blocks
[    1.050000] Bad eraseblock 3 at 0x00060000
[    1.090000] Bad eraseblock 654 at 0x051c0000

Should I stop flashing or try the method outlined in the following thread? - i.e. erase 8 blocks instead of 4 and make sure that flash went correctly using diff?

https://forum.doozan.com/read.php?3,17442,17578

mark,

> Look like there are some badblocks based on dmesg
>
>

> [    1.050000] Scanning device for bad blocks
> [    1.050000] Bad eraseblock 3 at 0x00060000
> [    1.090000] Bad eraseblock 654 at 0x051c0000
>

>
> Should I stop flashing or try the method outlined
> in the following thread? - i.e. erase 8 blocks
> instead of 4 and make sure that flash went
> correctly using diff?
>
> https://forum.doozan.com/read.php?3,17442,17578

First, erase 5 blocks, flash u-boot, and see what the results is when you do diff.

Basically, you've found the the right thread that we discussed what to do when a bad block is in the first 8 blocks.

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

I erased 5 blocks and did nandwrite, that seems to have gone okay, but diff produces differences

-bash-3.2# ./flash_erase /dev/mtd0 0 5
Erasing 128 Kibyte @ 40000 -- 40 % complete flash_erase: Skipping bad block at 0                                                                                                                                                             0060000
Erasing 128 Kibyte @ 80000 -- 100 % complete
-bash-3.2# ls /tmp/pogo/uboot.2017.07-tld-1.pogo_e02.mtd0.kwb
/tmp/pogo/uboot.2017.07-tld-1.pogo_e02.mtd0.kwb
-bash-3.2# ls -l /tmp/pogo/uboot.2017.07-tld-1.pogo_e02.mtd0.kwb
-rw-r--r--    1 root     root       524288 Jan  1 00:21 /tmp/pogo/uboot.2017.07-                                                                                                                                                             tld-1.pogo_e02.mtd0.kwb
</mtd0 /tmp/pogo/uboot.2017.07-tld-1.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
Bad block at 60000, 1 block(s) from 60000 will be skipped
Writing data to block 4 at offset 0x80000
-bash-3.2# cd /tmp
-bash-3.2# ./pogo/tools/nanddump -nof /tmp/uBoot1.dump -l 0x60000 /dev/mtd0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00060000...
<ddump -nof /tmp/uBoot2.dump -l 0x20000 -s 0x80000 /dev/mtd0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00080000 and ending at 0x000a0000...
-bash-3.2# cat uBoot1.dump uBoot2.dump > uBoot.dump
-bash-3.2# ls
hbplug.log   resolv.conf  uBoot1.dump  var
pogo         uBoot.dump   uBoot2.dump
-bash-3.2# ls -l
-rw-r--r--    1 root     root          430 Jan  1 00:12 hbplug.log
drwxr-xr-x    3 root     root          220 Jan  1 00:21 pogo
-rw-r--r--    1 root     root           29 Jan  1 00:00 resolv.conf
-rw-r--r--    1 root     root       540672 Jan  1 00:35 uBoot.dump
-rw-r--r--    1 root     root       405504 Jan  1 00:34 uBoot1.dump
-rw-r--r--    1 root     root       135168 Jan  1 00:35 uBoot2.dump
drwxr-xr-x    2 root     root           60 Jan  1 00:00 var
-bash-3.2# diff -s /tmp/pogo/uboot.2017.07-tld-1.pogo_e02.mtd0.kwb uBoot.dump
Binary files /tmp/pogo/uboot.2017.07-tld-1.pogo_e02.mtd0.kwb and uBoot.dump diff                                                                                                                                                             er

Should I try erasing 8 blocks? Unlike the other thread, for me, it seems to have written out the kwb file correctly. So I am confused why the results are different

@bodhi - I also noticed the led at the front keeps blinking. Not sure if that indicates the unit is bricked.

Since wget wasn't working on this machine, I did the prep work - downloaded and extracted the files - on another pi server running debian and then copied the entire result under a single directory using scp back to /tmp. Did the same to prep the debian rootfs as well on the same server.

Based on all the messages, flash looks successful though. I am assuming I can flash back from mtd0 backup if required (as long as I don't reboot). Also looking at the messages after nandwrite, it looks like flash was successful by skipping the bad block at 3 as expected, but when the blocks are combined for checking, each block seems to have extra 4k - 132k instead of 128k. Even when I look at the nanddump messages at the end for comparison, size seems to be the same as the one from earlier thread ("Block size 131072, page size 2048, OOB size 64 Dumping data starting at 0x00000000 and ending at 0x00060000...")

Should I go ahead and apply the environment variables now and proceed with the rest of the flashing?

I already created rootfs on a usb stick using the 5.13.16 version as mentioned earlier (even did the step for uimage though I am planning to use the new uboot assuming it is successfl). I didn't update the kernel, wasn't sure if I can just download the latest and apply it over this rootfs.

Mark,

Your log was all messed up. Very hard to read. See if I can reformat it and read it the same time.

-bash-3.2# ./flash_erase /dev/mtd0 0 5
Erasing 128 Kibyte @ 40000 -- 40 % complete flash_erase: Skipping bad block at 0                                                                                                                                                             0060000
Erasing 128 Kibyte @ 80000 -- 100 % complete

-bash-3.2# ls -l /tmp/pogo/uboot.2017.07-tld-1.pogo_e02.mtd0.kwb
-rw-r--r--    1 root     root       524288 Jan  1 00:21 /tmp/pogo/uboot.2017.07-tld-1.pogo_e02.mtd0.kwb

Looks like nandwrite is here but it got cut off in front:

</mtd0 /tmp/pogo/uboot.2017.07-tld-1.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
Bad block at 60000, 1 block(s) from 60000 will be skipped
Writing data to block 4 at offset 0x80000

-bash-3.2# ./pogo/tools/nanddump -nof /tmp/uBoot1.dump -l 0x60000 /dev/mtd0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00060000...

<ddump -nof /tmp/uBoot2.dump -l 0x20000 -s 0x80000 /dev/mtd0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00080000 and ending at 0x000a0000...

The 2 nanddump above was with wrong options. We want to obmit OOB and no ECC. That's why the combined blocks is not 512K.

-rw-r--r--    1 root     root       540672 Jan  1 00:35 uBoot.dump

And of course they are different.

-bash-3.2# diff -s /tmp/pogo/uboot.2017.07-tld-1.pogo_e02.mtd0.kwb uBoot.dump
Binary files /tmp/pogo/uboot.2017.07-tld-1.pogo_e02.mtd0.kwb and uBoot.dump diff                                                                                                                                                             er

Some nanddump versions have slightly different syntax for options. The toolspack I uploaded was quite a long time ago. Do the help to see exactly what options

./pogo/tools/nanddump --help

And then adjust the -nof to specify that you want to "obmit OOB" and no ECC. See this in the u-boot installation instruction:

Quote

3. Be sure to save your current uBoot image in mtd0, or have a backup image saved somewhere as precaution. And save your current u-boot envs with fw_printenv, or just copy/paste the listing into a text file. Note the nanddump command below allows future restoration to the same box you're backing up, and also can be used to restore a differrent box's mtd0 if needed.

Dumping NAND mtd0:
nanddump --noecc --omitoob -l 0x80000 -f mtd0 /dev/mtd0

By the way, since you already created the USB rootfs, you can also use nanddump and flash_erase in the rootfs too (/usr/sbin/nanddump and /usr/sbin/flash_erase)

Quote

Should I go ahead and apply the environment variables now and proceed with the rest of the flashing?

The nandwrite looks quite OK:

Quote

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
Bad block at 60000, 1 block(s) from 60000 will be skipped
Writing data to block 4 at offset 0x80000

But why not go ahead and finish the exercise above, compare the stitched NAND blocks u-boot image to uboot.2017.07-tld-1.pogo_e02.mtd0.kwb. If they are the same then proceed with the flashing of envs image and setting envs.

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

Looks like you found the issue. it was de to OOB/nanddump options. Thank you. Since I noticed LEDs flashing I wasn't sure if something else could be wrong.

I think I copied the instructions to naddump/concatenate from the earlier thread. May be there was some change to nanddump as you mentioned since then. Looks like "-no" won't omit OOB, -n may be sufficient based on the help.

-bash-3.2# ./pogo/tools/nanddump --noecc --omitoob -l 0x60000 -f /tmp/uBoot1.dump /dev/mtd0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00060000...

-bash-3.2# ./pogo/tools/nanddump --noecc --omitoob -l 0x20000 -s 0x80000 -f /tmp/uBoot2.dump /dev/mtd0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00080000 and ending at 0x000a0000...

-bash-3.2# cat uBoot1.dump uBoot2.dump > uBoot.dump

-bash-3.2# diff -s uboot.2017.07-tld-1.pogo_e02.mtd0.kwb uBoot.dump
Files uboot.2017.07-tld-1.pogo_e02.mtd0.kwb and uBoot.dump are identical

Since I noticed that the nandwrite went without any errors, I went ahead and flashed the environment variables and made the changes including the ones for netconsole. However, I have a few questions.

From the earlier thread, I assigned the following, wanted to confirm if that is accurate - at least the highlighted ones that was mentioned in earlier pogo E02 troubleshooting thread. I redacted ipaddress and macaddress, but pulled macaddress from the label on E02.

Please let me know if these configs look okay.

arcNumber=3542
ethaddr=xx:xx:xx:xx:xx:xx
uenv_init_devices=echo Initializing devices...; setenv init_usb "usb start";  setenv init_ide "ide reset";  setenv init_mmc "mmc rescan"; for devtype in $devices; do run init_$devtype; done
uenv_read=echo Loading envs from $device_type $disk_number...; if load $device_type  $disk_number:1 $uenv_addr /boot/uEnv.txt; then setenv uenv_loaded 1; echo ... envs loaded; fi
uenv_load=run uenv_init_devices; setenv uenv_loaded 0; for devtype in $devices; do for disknum in $disks; do if test $uenv_loaded -eq 0; then setenv device_type $devtype; setenv disk_number $disknum; run uenv_read; fi; done; done;
machid=dd6
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=xxx.xxx.xx.xx
serverip=xxx.xxx.xx.yy
dtb_file=/boot/dts/kirkwood-pogo_e02.dtb

Also, I couldn't find anything for mtdparts from the current env file I saved prior to flashing. So I left it as is from your environment flashing.

The instruction stated

Then for all boxes, restore these 2 envs using the saved envs text in step c (replace xxx with the real saved values

fw_setenv mtdparts 'xxxxxxxxx'
fw_setenv ethaddr 'xx:xx:xx:xx:xx:xx'

Following is what I see for mtdparts from printenv|grep mtdparts

-bash-3.2# ./pogo/tools/fw_printenv|grep -i 'mtdparts'
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
set_bootargs=setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts $custom_params

Is it okay to flash rootfs with the september 2021 version(bullseye) as a starting point for now? Can that be upgraded later from pogo itself? (ie. latest version of kernel)? I skipped the uimage part while building this since I won't be using stock uboot. So I have updated the "dtb_file" accordingly. - i.e. all I did was extract the tarball to usb drive for rootfs for now.

Assuming everything is good, when I reboot with the usb, I am assuming it will load debian. Will I be logging in with root/root as the initial uid/pw or should this be the original ssh password I set for the pogo? I set the ipaddress to be same as the current ip address. I am assuming I will have to replace the rsa keys.

PS:- Sorry about the bad formatting earlier, I just copied over from terminal and wasn't using full screen for terminal, so it looks messy.

Mark,

Quote

> -bash-3.2# diff -s
> uboot.2017.07-tld-1.pogo_e02.mtd0.kwb uBoot.dump
> Files uboot.2017.07-tld-1.pogo_e02.mtd0.kwb and
> uBoot.dump are identical

Cool!

> arcNumber=3542
> ethaddr=xx:xx:xx:xx:xx:xx
> uenv_init_devices=echo Initializing devices...;
> setenv init_usb "usb start";  setenv init_ide "ide
> reset";  setenv init_mmc "mmc rescan"; for devtype
> in $devices; do run init_$devtype; done
> uenv_read=echo Loading envs from $device_type
> $disk_number...; if load $device_type 
> $disk_number:1 $uenv_addr /boot/uEnv.txt; then
> setenv uenv_loaded 1; echo ... envs loaded; fi
> uenv_load=run uenv_init_devices; setenv
> uenv_loaded 0; for devtype in $devices; do for
> disknum in $disks; do if test $uenv_loaded -eq 0;
> then setenv device_type $devtype; setenv
> disk_number $disknum; run uenv_read; fi; done;
> done;
> machid=dd6
> 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=xxx.xxx.xx.xx
> serverip=xxx.xxx.xx.yy
> dtb_file=/boot/dts/kirkwood-pogo_e02.dtb

arcNumber and machid are no longer needed (but it does not hurt to have them). Only the DTB name is needed, which you have it correct from the default. (Pogo E02 is a common denominator, i.e. it will boot just about any Kirkwood board, thus I set it as default in case users forget).

> Also, I couldn't find anything for mtdparts from
> the current env file I saved prior to flashing. So
> I left it as is from your environment flashing.

The default envs mtdparts is correct for Pogo E02.

>

> -bash-3.2# ./pogo/tools/fw_printenv|grep -i
> 'mtdparts'

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

>

Looks good!

> Is it okay to flash rootfs with the september 2021
> version(bullseye) as a starting point for now? Can
> that be upgraded later from pogo itself? (ie.
> latest version of kernel)?

Use Debian-5.13.6-kirkwood-tld-1-rootfs-bodhi.tar.bz2 as starting point, which you already have the USB. Later after you have booted the system, you can upgrade kernel to the latest released one (currently linux-6.0.7-kirkwood-tld-1-bodhi.tar.bz2).

> . So I have updated the "dtb_file"
> accordingly. - i.e. all I did was extract the
> tarball to usb drive for rootfs for now.

So far so good.

> Assuming everything is good, when I reboot with
> the usb, I am assuming it will load debian. Will I
> be logging in with root/root as the initial uid/pw
> or should this be the original ssh password I set
> for the pogo?

The default credential is root/root. Your own SSH keys are automatically generated at 1st boot (Installation Note 2)

> I set the ipaddress to be same as
> the current ip address. I am assuming I will have
> to replace the rsa keys.

No need to worry on the Pogo E02. Only on the SSH terminal side you will see the different key and then adjust your terminal .ssh/known_hosts. I usually delete the entry and let SSH ask me to accept the new key.

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

I attached USB drive and rebooted the pogo. I am unable to connect at the specified IP address nor can I see the device on my router by IP or macaddress.

However, while booting up, i can see the lights blinking and usb drive being accessed. After a while lights become solid orange/green, but doesn't allow access from putty or ping command. I tried netconsole command, but I can't see anything in the netconsole. I do see some other devices on the network sending commands to netconsole.

Looks like I need some help. Not sure which step was incorrect since we verified everything.

I tried booting without USB and that doesn't seem to make any difference either except the LED keeps blinking - i.e. it never becomes solid green.

On the ethernet port, right led is off, and the left one is green/blinking. So I am assuming that means no link activity which may explain why netconsole is not working



Edited 1 time(s). Last edit at 12/26/2022 08:14PM by mark66.

I was able to capture netconsole. It complains about /boot/uEnv.txt. Did I miss a step?

I tried booting from every one of the 4 USB ports and didn't seem to make a difference. At least it looks like it is finding the images, but seems to be stuck at starting the kernel. I am using a 4GB usb stick, does it need more space?

Initializing devices...
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 3 USB Device(s) found
       scanning usb for storage devices...
Use USB retry period from the environment: 15 second(s)
1 Storage Device(s) found
Unknown command 'ide' - try 'help'
Unknown command 'mmc' - try 'help'
Loading envs from usb 0...
** File not found /boot/uEnv.txt **
Loading envs from usb 1...
** Bad device usb 1 **
Loading envs from usb 2...
** Bad device usb 2 **
Loading envs from usb 3...
** Bad device usb 3 **
Loading envs from ide 0...
** Bad device ide 0 **
Loading envs from ide 1...
** Bad device ide 1 **
Loading envs from ide 2...
** Bad device ide 2 **
Loading envs from ide 3...
** Bad device ide 3 **
Loading envs from mmc 0...
** Bad device mmc 0 **
Loading envs from mmc 1...
** Bad device mmc 1 **
Loading envs from mmc 2...
** Bad device mmc 2 **
Loading envs from mmc 3...
** Bad device mmc 3 **
running scan_disk ...
Scan device usb
device usb 0:1
1 bytes read in 722 ms (0 Bytes/s)
Found bootable drive on usb 0
loading uImage ...
5435888 bytes read in 1381 ms (3.8 MiB/s)
loading uInitrd ...
9671091 bytes read in 1617 ms (5.7 MiB/s)
loading DTB /boot/dts/kirkwood-pogo_e02.dtb ...
10114 bytes read in 3752 ms (2 KiB/s)
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-5.13.6-kirkwood-tld-1
   Created:      2021-09-24   0:22:58 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5435824 Bytes = 5.2 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   initramfs-5.13.6-kirkwood-tld-1
   Created:      2021-09-24   1:06:32 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    9671027 Bytes = 9.2 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01c00000
   Booting using the fdt blob at 0x1c00000


Starting kernel ...

Edited 1 time(s). Last edit at 12/26/2022 08:35PM by mark66.

Mark,

Congrats! u-boot was installed successfully.

But you missed this instruction:

Quote

10. Set up netconsole. It's important to set up neconsole if you don't already have serial console connected. If you have serial console, don't set up netconsole at this moment, because it will interfere with serial console.

So now when you boot, the input and output go to serial console, and then stop, and then netconsole, and stop, and serial console again.

Open 2 terminals, one runs serial console and one run netconsole. You will see that the u-boot countdown appear in netconsole. That's where you can interrupt u-boot count down.

And let it boot

boot

Switch back to serial console terminal and wait, eventually you will see boot log progress.

Log into Debian and remove netconsole

fw_printenv

See the u-boot envs listing, if it looks normal, remove netconsole

fw_setenv preboot

Now when you reboot, everything will appear on serial console.

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



Edited 1 time(s). Last edit at 12/26/2022 09:00PM by bodhi.

Not sure if I followed this completely. I recall adding netconsole parameters from your instruction for that step. I did run these commands and see the following in the printenv output from earlier. I was able to capture that output from my rasberry pi running by running the nc command that was mentioned.

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=xxx.xx.xx.xx
serverip=xxx.xx.xx.yy

I am not sure how to run the serial console with pogo since the device is not on the network. Is it something from putty? I thought usually those need a serial cable using a usb connected to computer and pins to hook back to the board (at least when I flashed dd-wrt)

Mark,

> I am not sure how to run the serial console with
> pogo since the device is not on the network. Is it
> something from putty? I thought usually those need
> a serial cable using a usb connected to computer
> and pins to hook back to the board (at least when
> I flashed dd-wrt)

I see. I mistakenly assumed that you have serial console. So forget about removing netconsole. Just run it as you are right now and connect netconsole to observe boot progress.

When you see

Quote

Starting kernel ...

It is normal for netconsole. It is and actually booting. But you cannot see anything after that.

Look for a new IP address in your router, or use Linux nmap or IOS app like Fing to find the new dynamic IP address that this Pogo was assigned to. And you can also ping the rootfs host:

ping debian.local

Now after you can log in, see this post for further netconsole setup so that you can see more boot log.

https://forum.doozan.com/read.php?2,9522

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

Following is the output I see when I put netconsole in the background. I tried opening another console with the assigned ipaddress, but I don't see anything more after "Starting Kernel". I let it sit for 30 minutes and didn't see the expected macaddress or ipaddress for this pogo in my router.

I do see the counter now. Do I need to interrupt this? How long does the typical boot take for the first time? I was curious if there was something wrong with rootfs that prevents the device from booted all the way...

~#  nc -l -u -p 6666 &
[3] 3025
[2]   Killed                  nc -l -u -p 6666
~#
U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:13:18 -0700)
Pogo E02
gcc (Debian 6.3.0-18) 6.3.0 20170516
GNU ld (GNU Binutils for Debian) 2.28
Hit any key to stop autoboot:  0
Initializing devices...
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 3 USB Device(s) found
       scanning usb for storage devices...
Use USB retry period from the environment: 15 second(s)

I installed nmap and checked using the router LAN IP list. This ip assigned in the uboot nor macaddress don't seem to show up anywhere so far. Since the pogo light turns solid green, does it mean boot is successful as I don't see the lights flashing in the usb stick any longer after that.

Quote

Now after you can log in, see this post for further netconsole setup so that you can see more boot log.

https://forum.doozan.com/read.php?2,9522

I am curious - should I rebuild rootfs and then incorporate the above steps to get better visibility? Or is this only possible after the boot is successful to the new debian OS on pogo?



Edited 2 time(s). Last edit at 12/26/2022 11:36PM by mark66.

Quote

I am curious - should I rebuild rootfs and then incorporate the above steps to get better visibility? Or is this only possible after the boot is successful to the new debian OS on pogo?

No. Eventhough it is possible with chroot, you won't see everything that a serial console will give. And a big part of that is rootfs mounting.

So, I would recommend retracing yourr USB rootfs creartion steps. If you have a log of that session, please post here and I will review to see if any step is missing. The rootfs creation instruction must be followed verbatim. IOW, If you have substituted any step with what you think will work, then that's not good.

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

It turned out to be a problem with how the usb flash drive was formatted. I formatted the drives initially on my desktop and then took it to raspberry pi to copy the rootfs. It turns out the ones formatted on my desktop were actually showing up as ext2 on my pi though I had specified the option as "ext3" in the partitioning tool on the desktop. So I did the partitiong/labeling in the pi itself and then everything loaded fine. It looks like there were some extra partitions on some of the drives that I couldn't get rid of from windows machine, Luckily I had one which only had one partition.

Now everything is up and running. Thanks for all your help in getting this through. It looks like most of the issues were because of me not paying attention to your instructions or checking the valid format for the drive.Anyway, it was a good learning experience.

I also upgraded the drive and updated ramdisk as mentioned in your instructions. I also updated the kernel to 6.0.7 and installed a few utils like samba, ntfs-3g etc.

1. Net console fix to monitor kernel boot progress

2. Swap space - are there any instructions on how to do this? The current USB that I am using is only 3.7GB. I may need help with relocating this to another bigger flashdrive as I am assuming swap along with additional utilities/tools that I may install could go over that limit.


One interesting thing I noticed - it looks like some of the smart bulbs in my home were interfering with my netconsole when I initially brought it up(as those devices are always on). I had to turn them off for netconsole to get consistent output from pogo. Not sure why that happened.



Edited 2 time(s). Last edit at 12/27/2022 12:59PM by mark66.

> 2. Swap space - are there any instructions on how
> to do this? The current USB that I am using is
> only 3.7GB. I may need help with relocating this
> to another bigger flashdrive as I am assuming swap
> along with additional utilities/tools that I may
> install could go over that limit.

I meant to add this swapfile instruction, but forgot all about it. Will do that shortly.

>
>
> One interesting thing I noticed - it looks like
> some of the smart bulbs in my home were
> interfering with my netconsole when I initially
> brought it up(as those devices are always on). I
> had to turn them off for netconsole to get
> consistent output from pogo. Not sure why that
> happened.

Do the smart bulbs connect to your network by Wifi? if that's the case, perhaps they are sending/listening to port 6666.

By the way my nc command is (try this to see if you can avoid smart bulbs interference):

192.168.0.x is the Pogo IP address

nc.traditional  -lup 6666 192.168.0.x 6666

(The latest Debian nc is different from one we are used to use for years. So I installed nc.traditional to get it back).

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

Mark,

Here is the instruction for swapfile

https://forum.doozan.com/read.php?2,133753

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

Yes, those smart bulbs were on the same wifi network. I should probably remove them to a different subnet for isolation.

I will wait for your instructions on swap file. Thanks for all the help. I definitely learned a few things.

> I will wait for your instructions on swap file.
> Thanks for all the help. I definitely learned a
> few things.

See above post.

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

Thanks Bodhi. I missed that one. I modified the code for netconsole and added the swap file. I was also able to mount and share drives with samba. I may transfer a few utilities like pihole running on my pi to this as well.

https://forum.doozan.com/read.php?4,42279

I noticed the above thread had instructions on dual boot between openwrt running on NAND and debian from usb stick. Any benefits with openwrt implementation over debian? Will adding packages through that configuration require optware running on a usb stick?

Mark,

> I noticed the above thread had instructions on
> dual boot between openwrt running on NAND and
> debian from usb stick. Any benefits with openwrt
> implementation over debian?

Debian is good for NAS. OpenWrt is good for router. So really there is no advantage/disadvantage comparing the two.

Using NAS, you'd want to update kernel and Debian packages regularly. So Debian is better for security.

Using router, you rarely upgrade the system, and it's OK since its purpose is an appliance. OpenWrt releases new version once in a while, and taking care of security patches for you.

> Will adding packages
> through that configuration require optware running
> on a usb stick?

OpenWrt runs entirely on NAND flash for this box. Adding packages or updgrade system meaning updating the kernel and/or rootfs on flash.

So the bottom line is, generally speaking you should not run OpenWrt as a NAS.

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



Edited 1 time(s). Last edit at 12/28/2022 05:52PM by bodhi.

Thanks. I have used openwrt with an old router in the past, couldn't figure out why that would be loaded on a storage solution like E02.

I forgot to set up the systemd, but was able to figure that part from your instruction using uEnv.txt. With "pstree" command, I can see that now systemd is the init. I am not sure if I need to do anything for services installed prior to installing systemd - like enabling services so that I can use systemctl command to start/stop services. I am looking for a single command/script to shutdown all services when needed - example to make backup.

Also, if I need to switch the rootfs to another usb stick, what is the process? Is it just a matter of running a "dd" command to copy the rootfs to the new device? Do I need to copy everything including label and UUID, so that I can switch to the new flash drive seamlessly?



Edited 1 time(s). Last edit at 12/29/2022 12:13PM by mark66.

Quote

Also, if I need to switch the rootfs to another usb stick, what is the process? Is it just a matter of running a "dd" command to copy the rootfs to the new device? Do I need to copy everything including label and UUID, so that I can switch to the new flash drive seamlessly?

Don't use dd. Use this opportunity to create a backup tarball and restore it to the new USB drive. And you need to be root (sudo won't work). And yes, the partition label needs to be rootfs so that it will be a drop-in replacement (nothing else needs to be done).

See Wiki thread for examples (the last 2 in quote below).

https://forum.doozan.com/read.php?2,23630

Quote

How to clone a rootfs from one Kirkwood box to another: Step 1 and Step 2
How to clone SATA rootfs to USB rootfs
How to clone USB rootfs to SATA rootfs

Note that cloning the rootfs to run on another Kirkwood box has some additional steps (the 1st post in quote above).

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

Quote

Use this opportunity to create a backup tarball and restore it to the new USB drive. And you need to be root (sudo won't work). And yes, the partition label needs to be rootfs so that it will be a drop-in replacement (nothing else needs to be done).

Thanks bodhi, I will give this a try. Also, I just noticed that my current usb flash drive is formatted with block size 4k. I am assuming I should probably use 512 as block size (that may be one reason why it ended up quickly filling up the usb drive).

Any experience with running data sync utilities like syncthing with pogo? Do they run well on this platform since this seem to have a gigabit ethernet connection to router (vs wifi/100mbps connection for my pi)?

Mark,

> Any experience with running data sync utilities
> like syncthing with pogo? Do they run well on this
> platform since this seem to have a gigabit
> ethernet connection to router (vs wifi/100mbps
> connection for my pi)?

This Pogoplug E02 is very fast as far as network is concerned. We could get over 900Mbs running iperf test between the 2 Kirkwood boxes such as this pogo. So data sync over network is quite good. The only limting factor is it has only USB, no SATA. So it will max out at a typical USB bus rate for read/write.

I use rsync scripts only to backup and sync data, so not sure what the performance of syncthing would be like. I would very much like to hear about that after you've tried.

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