Welcome! Log In Create A New Profile

Advanced

Debian on NSA325 V1/V2

Posted by Buttzy10169 
Re: NSA 325 V2 Debian Is Possible!
October 23, 2018 04:37AM
Hi Mike,

> (1) is '--noecc' critical? (Is it ecc memory?)

Yes, it is important to specify noecc (meaning no ecc info needed to be dumped).


> (2) should the '--omitoob' option be '--omitbad'
> or is it really referring to 'out of band' memory
> (oob)? And, again, is the lack of the option a
> showstopper?

Yes, obmitoob (out of band) option ignores oob, so the dump can be reused on any NS325 box.

If the nanddump version you run does not have those options, you should make sure to download the binaries tarball I uploaded in the u-boot release post

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.

With that said, the mtd back up with nadndump is just a precaution. You can get stock NSA325 nanddump mtds from this forum should you ever need them. Those steps were illustration of how to hack these boxes safely, i.e. you have your own backup, you're are in control when and if you can restore them to stock.


> The next issue refers to bad blocks. I have two -
> at 0x0000048c0000 #582 and 0x0000050a0000 #645.
>

582 and 645 are far away from mtd0, i.e u-boot region, so it is safe to ignore these bad blocks.


> (3) how do I work out which block and which mtd
> number these are present in? Is there an easy
> formula?

NAND block is 128KB. So mtd0 is 8 blocks, 0-7. You can derive the other mtd block numbers by this formula.

So NSA325 mtdparts env defines these mtds:
mtdparts=mtdparts=orion_nand:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2)

mtd0 (u-boot) size is 0x100000 = 1MB, and its location is at 0x0. You can keep going to the next and so on.

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



Edited 3 time(s). Last edit at 10/23/2018 06:00PM by bodhi.
mikeinnc
Re: NSA 325 V2 Debian Is Possible!
October 23, 2018 09:10AM
Thanks again, Bodhi! I'd overlooked the newer version of the programs (binaries) contained in that tarball. My mistake! However, I've downloaded them and extracted them as suggested. There is one small point - in the U-Boot Flashing Utilities thread, you say:

Quote
Bodhi
copy them to /usr/loclal/bin or /usr/sbin in stock OS for later emergency use.

Well, in a NSA325 box, you can't as both those directories are read-only. However you can - and I have - copied them to /bin which is a writeable directory, and where the originals (ie older versions) are located. Is it worth a note to that effect in that thread?

I'm a bit confused by your comments about the mtd blocks, though. As I understand it, the total NAND (flash) memory in the NSA325 is 128MB. As you say, the u-boot area is 1MB in size - I can easily see that from the size value (0x10000 = 2^20 = 1.048,576 or '1MB'). So, if mtd0 contains 8 'blocks' - block 0 through 7 - then each 'block' is 128KB (2^(20-3) = 2^17 = 131,072) since 8*128K = 1MB (actually, 8*131,072 = 1,048,576 QED!!)

So, yes, I can now see how the blocks add-up - and how blocks 582 and 645 are a l-o-n-g way from mtd0 :-)

You said "NAND block is 128MB.". I think you may have meant a NAND block is 128KB - and the entire (total) NAND memory is 128MB. And, of course, that implies there are 1024 blocks of 128KB each - easily encompassing my block numbers.

And then it all makes sense!

Thanks again for your great help!

Mike
mikeinnc
Re: NSA 325 V2 Debian Is Possible!
October 23, 2018 09:30AM
Soory, Bodhi - me again! I see in the information about flashing U-Boot - in step 6 - it says:

flash-erase /dev/mtd0 0 4

The first figure is the block offset - that's fine - and second is <block count>. So, are we only erasing 4 of the 8 blocks in mtd0? And if so, why - why not all 8? Is this a mistake - or is there a deep and meaningful reason for only erasing half of mtd0?

Thanks for your help - again!!

Mike
Re: NSA 325 V2 Debian Is Possible!
October 23, 2018 06:04PM
Mike,

Yes, 128MB was a typo! I should have said "NAND block is 128KB".

And about
flash_erase /dev/mtd0 0 4

The above command erases the 1st 512KB on mtd0, since we only need that much to store u-boot image. I've tried to keep all Kirkwood u-boot images under 512KB to keep the remaining flash untouched for other things.

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



Edited 2 time(s). Last edit at 10/23/2018 06:05PM by bodhi.
mikeinnc
Re: NSA 325 V2 Debian Is Possible!
October 23, 2018 08:42PM
Thanks again, Bodhi. I can see exactly what you mean - and why. So, the good news is that I continued to follow the uboot update instructions to the letter, and also built a USB stick with the 4.12.1 system on it as recommended for first boot. And it worked! Fantastic!

But - there's always a but......

During the first boot, I noticed it said that it couldn't find a 'uEnv.txt' file in the /boot directory. I guess this means it expects to see a set of environment variables for this specific box? Anyway, I'd actually saved the updated environment variables to a text file during the uboot update, and so I copied that file (renamed as required) to the /boot directory, and rebooted the box. Well, OK, it now 'finds' that file and the warning has gone - but the environment variables I see if I use the fw_printenv command bear NO resemblance to the ones I'd expect to see. Amongst other things, the boot process appears to load a dbt file for a 'Cloudengines Pogoplug', and the mtdparts variable is NOTHING like the one seen before! So, what's going on? The system is running - but I'm reluctant to do anything else yet until I see what is happening here? Where are the envs I saved to the flash? Why are the - apparent - envs now so screwed up? And - how does the box boot successfully if all the environment variables appear to be wrong, and even the incorrect dtb file is used?

Really looking forward to any help here!! Thanks so much.......
Re: NSA 325 V2 Debian Is Possible!
October 23, 2018 08:58PM
Mike,

> During the first boot, I noticed it said that it
> couldn't find a 'uEnv.txt' file in the /boot
> directory. I guess this means it expects to see a
> set of environment variables for this specific
> box?

That's optional. You have set up all the specifics during installation. So you should remove uEnv.txt to avoid interferrence with normal u-boot booting. This file meant to serve as a way to tweak u-boot envs during boot. That's why you see u-boot looking for and could not find it (which is only a warning, nothing is wrong).

It is useful when you made a mistake in setting some envs and cannot boot (you would correct those envs temporarily, and then set it permanently later in Debian). Or when you want to test some setup and don't want to commit your changes to u-boot envs (remove it and things go back to the way it was).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Mikeinnc
Re: NSA 325 V2 Debian Is Possible!
October 23, 2018 09:13PM
Thanks for the really speedy reply, Bodhi. As usual, what you say makes perfect sense, and I've removed the file

But - why are my environment variables so apparently wrong?

Here's the result of the fw_printenv command:

arcNumber=2097
bootcmd_exec=run load_uimage; if run load_initrd; then if run load_dtb; then bootm $load_uimage_addr $load_initrd_addr $load_dtb_addr; else bootm $load_uimage_addr $load_initrd_addr; fi; else if run load_dtb; then bootm $load_uimage_addr - $load_dtb_addr; else bootm $load_uimage_addr; fi; fi
bootcmd=run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec
bootcmd_uenv=run uenv_load; if test $uenv_loaded -eq 1; then run uenv_import; fi
bootdelay=10
bootdev=usb
device=0:1
devices=usb ide mmc
disks=0 1 2 3
ethact=egiga0
ethaddr=52:3b:20:9c:11:51
if_netconsole=ping $serverip
ipaddr=192.168.0.231
led_error=orange blinking
led_exit=green off
led_init=green blinking
dtb_file=/boot/dts/kirkwood-pogo_e02.dtb
load_dtb_addr=0x1c00000
load_initrd_addr=0x1100000
load_uimage_addr=0x800000
load_dtb=echo loading DTB $dtb_file ...; load $bootdev $device $load_dtb_addr $dtb_file
load_initrd=echo loading uInitrd ...; load $bootdev $device $load_initrd_addr /boot/uInitrd
load_uimage=echo loading uImage ...; load $bootdev $device $load_uimage_addr /boot/uImage
machid=0x831
mainlineLinux=yes
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
partition=nand0,2
preboot_nc=run if_netconsole start_netconsole
scan_disk=echo running scan_disk ...; scan_done=0; setenv scan_usb "usb start";  setenv scan_ide "ide reset";  setenv scan_mmc "mmc rescan"; for dev in $devices; do if test $scan_done -eq 0; then echo Scan device $dev; run scan_$dev; for disknum in $disks; do if test $scan_done -eq 0; then echo device $dev $disknum:1; if load $dev $disknum:1 $load_uimage_addr /boot/uImage 1; then scan_done=1; echo Found bootable drive on $dev $disknum; setenv device $disknum:1; setenv bootdev $dev; fi; fi; done; fi; done
serverip=192.168.0.220
set_bootargs=setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts $custom_params
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
stderr=serial
stdin=serial
stdout=serial
uenv_addr=0x810000
uenv_import=echo importing envs ...; env import -t $uenv_addr $filesize
uenv_init_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_load=run uenv_init_devices; setenv uenv_loaded 0; for devtype in $devices;  do for disknum in 0; do run uenv_read_disk; done; done;
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
uenv_read=echo loading envs from $devtype $disknum ...; if load $devtype $disknum:1 $uenv_addr /boot/uEnv.txt; then setenv uenv_loaded 1; fi
usb_ready_retry=15

You'll see, for example, that the arcnumber is wrong; the dtb file is /boot/dts/kirkwood-pogo_e02.dtb; the mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data) is wrong.......

What has happened? Why are these variables here? They certainly aren't what I set! I'll really appreciate if you could explain.

Thanks so much

Mike
Re: NSA 325 V2 Debian Is Possible!
October 23, 2018 09:39PM
Mike,

> But - why are my environment variables so
> apparently wrong?

Because you've missed step 8 during installation (or missed parts of step 8).


Quote

8. Flashing default u-boot envs image (if you are upgrading from 2016.05-tld-1 u-boot, you can skip this step 8).

As described in step 1, u-boot envs must be defined in /etc/fw_env.config as

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

This default envs image supports booting with multiple disk drives (and hubs) attached. The disk drives could be any type (usb, sata, sd card). The scanning logic and default envs were set to automatically boot the box with the following required configuration:

For whatever reason, if you can't set up your configuration to satisfy the following 4 requirements, then don't flash this defaut envs image. It might not boot properly. In this case, section C below can be used to tailor the envs to your specific configuration.

r1. There must be only one partition among all partitions from all drives that contains the kernel files. The 2 kernel files are /boot/uImage and /boot/uInitrd.
r2. The partition that contains the 2 kernel files must be partition 1 in a disk drive
r3. The partition that contains the rootfs must be labeled 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).

So the bottom line is if you have only one rootfs in a single Ext3 partition, which is labeled as rootfs, then you're all set.

a. Download the default u-boot envs at Dropbox:

uboot.2016.05-tld-1.environment.bodhi.tar
md5:
3823eef10011b864859d31a76470e0e3
sha256:
c8db95a4225e8d78bdaaaa372bd5a87e4b98f3448dd9c62fc96c72b2df1a997c

This tarball includes 3 files:

uboot.2016.05-tld-1.environment.img (the default envs image to be flashed)
uboot.2016.05-tld-1.environment (the content of the default envs in text format)
uboot.2016.05-tld-1.environment.64K.img (small envs image to be flashed on HP T5325 only).

b. Extract the archive to /tmp
cd /tmp
tar -xf uboot.2016.05-tld-1.environment.bodhi.tar

c. Save current envs with fw_printenv, or just copy/paste the listing into a text file.
fw_printenv > current_envs.txt

d. Flash u-boot envs to NAND location 0xC0000.

Be extra careful with the next 2 commands, you should see output that look like below. If there is error, then do not reboot, post your problem here so we can help.

/usr/sbin/flash_erase /dev/mtd0 0xc0000 1
Expected output:
Erase Total 1 Units
Performing Flash Erase of length 131072 at offset 0xc0000 done

/usr/sbin/nandwrite -s 786432 /dev/mtd0 uboot.2016.05-tld-1.environment.img
Expected output:
Writing data to block 6 at offset 0xc0000

e. Modify the following u-boot variables using fw_setenv:

Note that arcNumber and machid are not necessary if you are booting with FDT kernel 3.17+ in the latest kernel and rootfs thread. But it does not hurt to set them anyway.

archNumber and machid are required for non-FDT kernel (3.16.x or earlier)

Also note that only some boxes need machid, some don't (so the command fw_setenv machid below clears them).

for Pogo V4/Mobile:
fw_setenv arcNumber 3960
fw_setenv machid f78

for iConnect:
fw_setenv arcNumber 2870
fw_setenv machid

for Stora:
fw_setenv arcNumber 2743
fw_setenv machid

for Dockstar:
fw_setenv arcNumber 2998
fw_setenv machid

for Pogo E02:
fw_setenv arcNumber 3542
fw_setenv machid dd6

for GoFlex Home:
fw_setenv arcNumber 3338
fw_setenv machid


for GoFlex Net:
fw_setenv arcNumber 3089
fw_setenv machid

for Sheevaplug:
fw_setenv arcNumber 2097
fw_setenv machid

for NSA325:
fw_setenv arcNumber 4495
fw_setenv machid


for NSA320:
fw_setenv arcNumber 3956
fw_setenv machid

for NSA310S/320S:
fw_setenv arcNumber 4931
fw_setenv machid

for NSA310:
fw_setenv arcNumber 4022
fw_setenv machid


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'


Note: for boxes that boot with SATA as rootfs. Please make this adjustment if your boot drive is SATA:
fw_setenv bootcmd_uenv 'run uenv_load; if test $uenv_loaded -eq 1; then run uenv_import; fi; sleep 3'
(This will help the "ide reset" to work properly. There seems to be a bug in u-boot that if you do "ide reset" too quickly in succession, the SATA drive might have problem spinning up).

f. Adjust the DTB name to boot with a rootfs that has FDT kernel 3.17+ (this is the normal case):

Find your box DTB file in the rootfs /boot/dts directory and adjust the env to it. For example, if the box is the Dockstar
fw_setenv dtb_file '/boot/dts/kirkwood-dockstar.dtb'

In the special case when you are booting with a non-FDT kernel 3.16 or earlier, or if you have appended the DTB to uImage. Remove the DTB file env. If not sure please post question before continuing.
fw_setenv dtb_file

h. For sanity check, list you envs again
fw_printenv

If there is error in listing u-boot envs, stop here and post your problem so we can help.

Remember to save away your old envs text file created in step c for future reference in case more need to be restored.

i. Done step 8.


The red lines were the one you did not do.

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



Edited 1 time(s). Last edit at 10/23/2018 09:41PM by bodhi.
Mikeinnc
Re: NSA 325 V2 Debian Is Possible!
October 23, 2018 11:25PM
Sorry, Bodhi but that';s exactly what I did do! That's why I am so suprised that the environment variables aren't set. Here is the contents of the file that I created after performing step 8 - and before I rebooted with the new uboot (in fact, as a result of sending the fw_printenv output from step 8h to a file). You can clearly see the variables that you have put in red were set.

bootargs=console=ttyS0,115200 mtdparts=nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2) root=/dev/nfs rw init=/init
bootcmd=nand read.e 0x2000000 $(kernel_addr) 0xA00000; bootm 0x2000000
bootdelay=2
baudrate=115200
loads_echo=0
ipaddr=10.4.52.165
serverip=10.4.52.7
rootpath=/srv/ubuntu
netmask=255.255.255.0
nandEcc=1bit
kernel_addr=C80000
MODEL_ID=AA03
PRODUCT_NAME=NSA-325
FEATURE_BIT=00
CONTRY_TYPE=FF
VENDOR_NAME=MitraStar Technology Corp.
run_diag=yes
arcNumber=4495
ethaddr=c8:6c:87:6f:5a:eb
mtdparts=nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2)


Hence my question - since I performed those steps exactly as you wrote them (and, indeed, was most careful to do them carefully and methodically), why am I seeing a set of variables that seem to be completely different? It just isn't making sense!

And, as always, thanks for your valuable advice.

Mike
Mikeinnc
Re: NSA 325 V2 Debian Is Possible!
October 23, 2018 11:40PM
A bit more information. I thought I'd reboot; stop the boot process and set a few of the environment variables using 'setenv' at the NSA325> prompt.

When I tried to set the MAC address (etheraddress), I got this error message:

NSA325> setenv ethaddr 'c8:6c:87:6f:5a:eb'

Warning: egiga0 MAC addresses don't match:
Address in SROM is         c8:6c:87:6f:5a:eb
Address in environment is  52:3b:20:9c:11:51

This seems to indicate that my flash memory variables are set, since that MAC address was the one I previously wrote (it is the actual box one). So, why the difference? Any clues to this?

Thanks

Mike
Mikeinnc
Re: NSA 325 V2 Debian Is Possible!
October 24, 2018 12:07AM
OK, maybe there's an error in the instructions for saving those environment variables. Certainly, when I used the command

nandwrite -s 786432 /dev/mtd0 uboot.2016.05-tld-1.environment.img


as per step 8d, I did not get the same output as shown (yes, and although I noted that, I didn't keep a note of what it was!) But, as the fw_printenv showed all to be OK, I assumed it was.......

So, now, having manually set and saved the environment variables (again!) at the NSA325> prompt, I get this output:

mtdparts=nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2)
arcNumber=4495
bootcmd=run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec
bootcmd_exec=run load_uimage; if run load_initrd; then if run load_dtb; then bootm $load_uimage_addr $load_initrd_addr $load_dtb_addr; else bootm $load_uimage_addr $load_initrd_addr; fi; else if run load_dtb; then bootm $load_uimage_addr - $load_dtb_addr; else bootm $load_uimage_addr; fi; fi
bootcmd_uenv=run uenv_load; if test $uenv_loaded -eq 1; then run uenv_import; fi
bootdelay=10
bootdev=usb
device=0:1
devices=usb ide mmc
disks=0 1 2 3
dtb_file=/boot/dts/kirkwood-nsa325.dtb
ethact=egiga0
ethaddr=c8:6c:87:6f:5a:eb
if_netconsole=ping $serverip
ipaddr=192.168.100.190
led_error=orange blinking
led_exit=green off
led_init=green blinking
load_dtb=echo loading DTB $dtb_file ...; load $bootdev $device $load_dtb_addr $dtb_file
load_dtb_addr=0x1c00000
load_initrd=echo loading uInitrd ...; load $bootdev $device $load_initrd_addr /boot/uInitrd
load_initrd_addr=0x1100000
load_uimage=echo loading uImage ...; load $bootdev $device $load_uimage_addr /boot/uImage
load_uimage_addr=0x800000
mainlineLinux=yes
mtdids=nand0=orion_nand
mtdparts=nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2)
partition=nand0,2
preboot_nc=run if_netconsole start_netconsole
scan_disk=echo running scan_disk ...; scan_done=0; setenv scan_usb "usb start";  setenv scan_ide "ide reset";  setenv scan_mmc "mmc rescan"; for dev in $devices; do if test $scan_done -eq 0; then echo Scan device $dev; run scan_$dev; for disknum in $disks; do if test $scan_done -eq 0; then echo device $dev $disknum:1; if load $dev $disknum:1 $load_uimage_addr /boot/uImage 1; then scan_done=1; echo Found bootable drive on $dev $disknum; setenv device $disknum:1; setenv bootdev $dev; fi; fi; done; fi; done
serverip=192.168.0.220
set_bootargs=setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts $custom_params
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
stderr=serial
stdin=serial
stdout=serial
uenv_addr=0x810000
uenv_import=echo importing envs ...; env import -t $uenv_addr $filesize
uenv_init_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_load=run uenv_init_devices; setenv uenv_loaded 0; for devtype in $devices;  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 $uenv_addr /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
usb_ready_retry=15

which I think we will both agree looks more like I'd expect!

It still doesn't explain why that 'step 8' process didn't work, but it appears to have fixed it. Comments really welcome!

Thanks Bodhi

Mike
Re: NSA 325 V2 Debian Is Possible!
October 24, 2018 12:58AM
This env should be adjusted:

mtdparts=nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2)

should be

mtdparts=orion_nand:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
mikeinnc
Re: NSA 325 V2 Debian Is Possible!
October 24, 2018 10:21AM
Thanks Bodhi. I'm still not sure why the environment variables I set as per step 8 didn't 'stick', but clearly I had loaded the image file as suggested. Looking at that file again, I can see that all those variables I mentioned as not being correct came from there. Oh well, a task for another day....

However, one problem you may know how to solve. If you look back at the envs in my last post, you will see that the mtdparts variable actually exists twice. Once at the top and then just after half-way down. Following your instructions, I modified it with fw_setenv to comply with your recommendation (orion_nand etc). When I then did a fw_printenv, I still had two entries - one had been corrected but the first was as before (nand_mtd). And try as I may, I just cannot get rid of both entries. If I try, only the second one (lower in the list) is deleted. The first (top) entry is still there. If I then edit and save the variable again - well, I get two again. The top one (nand_mtd) is never touched in any way! So how the **** can I get rid of it? I've tried from the NSA325> prompt as well as after a full boot - nothing works! I'm thinking I may have to repeat step 8 that deletes and resets all variables. Do you agree? Any comments gratefully received!!

Regards

Mike
Re: NSA 325 V2 Debian Is Possible!
October 24, 2018 02:28PM
Mike,

Let me take a close ook later today.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Re: NSA 325 V2 Debian Is Possible!
October 25, 2018 12:42AM
Mike,

Looks like you should go through step 8 again. This time will be easier.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
mikeinnc
Re: NSA 325 V2 Debian Is Possible!
October 25, 2018 03:04AM
Quote
Bodhi
Looks like you should go through step 8 again. This time will be easier.

Yes, you were right. It was easier the second time around - and the correct environment variables 'stuck' this time. In addition, it got rid of that anomaly of two mtdparts in the previous environment. Thank goodness for that!

A couple of minor points, if you want to edit the process. In Step 8d, the message is
Erasing 128Kibyte @ C0000 -- 100% complete

rather than the message in the docs. In addition, if it isn't obvious to the user, you could edit the last para in step 8f to read:

"In the special case when you are booting with a non-FDT kernel 3.16 or earlier, or if you have appended the DTB to uImage, remove the DTB file env by just typing the env name with no value. If not sure, please post question before continuing." (edit in italics).

I'd worked that one out, but it might be good to confirm it..... :-)

So, onward and upward - thanks for all your help so far!

Mike
Re: NSA 325 V2 Debian Is Possible!
October 25, 2018 04:48AM
Mike,

Hacking advice: Always ask a question first when you see different behavior than what it stated in the instruction. Don't make assumption because assumption is often wrong :) and causes you to waste time chasing non problem.

I'm glad you got it working well as it should. Have fun hacking!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
mikeinnc
Re: NSA 325 V2 Debian Is Possible!
October 30, 2018 07:02PM
Hello Bohdi - Me again! All has been going swimmingly over the last few days and I've got a Debian based NSA325 humming along nicely - thanks in no small part to your very generous assistance. I've been swapping data from the original disk (which, unfortunately, appeared to have a strange 'Linux RAID partition, and so had to be done externally as the NSA box wouldn't read it. My Mint Linux laptop did, however).

So this meant using a couple of portable USB drives to swap the info and I have noticed something strange that I wonder if you might be able to comment on.

I have both a USB3 drive and a USB2 drive. The USB3 drive will work in either of the two (rear) USB-2 ports, but is not seen and consequently won't work if plugged into the (front) USB-3 port. However, the USB2 drive will work in any of the three USB ports - front (USB-3) or back (USB-2). So clearly the front USB-3 port is operational but will not recognise a native USB3 drive! I believe I may have seen some comments on this issue before but unfortunately can't seem to find them. It's not a show-stopper - after all, I can mount; read and write both of the drives in either of the back ports, but I guess it would be nice to have the extra speed a native USB3 drive could achieve in a native USB-3 port.

As always, any hints,; advice or comments gratefully received.

Many thanks

Mike
Re: NSA 325 V2 Debian Is Possible!
October 30, 2018 07:16PM
Mike,

USB 3.0 drive works with front port. I use a 256GB Sandisk USB to do on-demand backup of the NSA325 rootfs weekly (My daily backup is to a NFS directory).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Re: NSA 325 V2 Debian Is Possible!
October 30, 2018 07:19PM
So it would be good if you list more info.

-when the USB3drive is inserted:

dmesg
fdisk -l

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
mikeinnc
Re: NSA 325 V2 Debian Is Possible!
October 30, 2018 09:14PM
Yes, really interesting. So I took your advice, and plugged the USB3 drive (which is a Toshiba 1GB HDD) in and saved the dmesg output and the fdisk list output. Neither show any indication of the drive. Now, if I plug another - non USB3 - drive in the USB3 (front) port, I immediately get a whole lot of output on the console terminal giving me information about the drive. If I plug the Toshiba USB3 drive in a back port, I get the same sort of information. So, as I said, the port is obviously working as a 'normal' USB port, and the Toshiba drive is obviously working as a 'normal' USB drive. It's just that combination of USB3 drive > USB3 (front) port that the box doesn't like!

Here's the fdisk output (I've cut out the mtdn blocks):

Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x22db667d

Device     Boot Start        End    Sectors  Size Id Type
/dev/sda1        2048 3907028991 3907026944  1.8T 83 Linux


Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x2dee735f

Device     Boot Start        End    Sectors  Size Id Type
/dev/sdb1        2048 3907028991 3907026944  1.8T 83 Linux

No /dev/sdc which is what I'd expect. Plug the drive in a back port and it appears in the fdisk listing as /dev/sdc

Reading through the dmesg output, there doesn't appear to be any reference to the Toshiba drive (which I suppose I'd expect. It's a very long file - can I send you the text output?)

As I say, not a show-stopper - more an irritation. Like an itch you have to scratch! But it would be interesting to know if it is a specific (drive? interface?) problem, or a more general issue.

And, as always, thanks so much for your help!

Mike
Re: NSA 325 V2 Debian Is Possible!
October 31, 2018 12:00AM
Mike,

> a Toshiba 1GB

Is it a 2.5" HDD? what model number?

> Reading through the dmesg output, there doesn't
> appear to be any reference to the Toshiba drive
> (which I suppose I'd expect.

If you record the dmesg time when you insert the drive then it will be apparent if there was a detection or not.

> It's a very long file
> - can I send you the text output?)

If it is too long and you don't want to post here, pastebin it (don't attach it to post).
https://pastebin.com

> But it would be
> interesting to know if it is a specific (drive?
> interface?) problem, or a more general issue.

It is most likely a specific brand/model problem.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
mikeinnc
Re: NSA 325 V2 Debian Is Possible!
October 31, 2018 08:24AM
It is a 2.5 inch HDD - model "Toshiba Canvio V63700-C 1TB 2.5" USB 3.0 Hard Disk Drive". There is certainly NO detection when plugged in front (USB3) port - but, as I've said previously, it is immediately recognised when plugged in a back (USB2) port. Unfortunately, its the only USB3 drive (of any type - 'rotating' or memory stick) that I have, so I can't check with another model. It certainly does look like it is a specific brand/model problem.

We know the port is - fundamentally - OK, and we know the drive is OK - as long as it is in another port! It's interesting, as I do have a desktop (Windows) machine with a USB3 port, and the drive is recognised as such when plugged in there (and it is definitely faster). Recall, though, I did have a problem with a Verbatim USB 'stick' so brand / model / "specification" issues may not be that uncommon!!

Mike
Re: NSA 325 V2 Debian Is Possible!
November 01, 2018 02:32AM
> There
> is certainly NO detection when plugged in front
> (USB3) port - but, as I've said previously, it is
> immediately recognised when plugged in a back
> (USB2) port.

That is very strange. You should try a different USB 3.0 thumb drive. See what will happen in dmesg when you do that.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
mikeinnc
Re: NSA 325 V2 Debian Is Possible!
November 01, 2018 06:52AM
Hi Bodhi - Before I'd seen your reply, I'd already gone down that path! So, I have been and purchased a 32GB USB3 flash drive, and here (below) is what I found - annotated output from the console terminal:

**** CONSOLE OUTPUT ****

*** plugged (new) USB3-32GB flash drive into (front) USB3 port

root@debian:~# [98175.769971] usb 3-1: new SuperSpeed USB device number 2 using xhci_hcd
[98175.804802] usb 3-1: New USB device found, idVendor=0781, idProduct=5581
[98175.811563] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[98175.818731] usb 3-1: Product: Ultra
[98175.822566] usb 3-1: Manufacturer: SanDisk
[98175.826685] usb 3-1: SerialNumber: 4C530001290901104143
[98175.833857] usb-storage 3-1:1.0: USB Mass Storage device detected
[98175.840498] scsi host2: usb-storage 3-1:1.0
[98175.999002] usbcore: registered new interface driver uas
[98176.901078] scsi 2:0:0:0: Direct-Access     SanDisk  Ultra 1.00 PQ: 0 ANSI: 6
[98176.914467] sd 2:0:0:0: Attached scsi generic sg2 type 0
[98176.922005] sd 2:0:0:0: [sdc] 60063744 512-byte logical blocks: (30.8 GB/28.6 GiB)
[98176.938325] sd 2:0:0:0: [sdc] Write Protect is off
[98176.948142] sd 2:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[98176.973730]  sdc: sdc1
[98176.978625] sd 2:0:0:0: [sdc] Attached SCSI removable disk

**** Check transfer speed of USB3 flash drive

root@debian:~# hdparm -t /dev/sdc1

/dev/sdc1:
 Timing buffered disk reads: 190 MB in  3.02 seconds =  63.01 MB/sec

**** Check transfer speeds of both (2TB) SATA HDD for reference

/dev/sdb1:
 Timing buffered disk reads: 450 MB in  3.01 seconds = 149.34 MB/sec

/dev/sda1:
 Timing buffered disk reads: 504 MB in  3.01 seconds = 167.45 MB/sec

*** Plugged Toshiba USB3-HDD into front USB3 port.

root@debian:~# [99878.888209] xhci_hcd 0000:01:00.0: Cannot set link state.
[99878.893653] usb usb3-port1: cannot disable (err = -32)
[99878.899483] usb 3-1: USB disconnect, device number 2

*** Verbatim flash drive (USB2) plugged into USB3 port

root@debian:~# [100016.948772] usb 2-1: new high-speed USB device number 5 using xhci_hcd
[100017.126706] usb 2-1: New USB device found, idVendor=18a5, idProduct=0302
[100017.133548] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[100017.141076] usb 2-1: Product: STORE N GO
[100017.145102] usb 2-1: Manufacturer: Verbatim
[100017.149629] usb 2-1: SerialNumber: 070B86C16E159425
[100017.159953] usb-storage 2-1:1.0: USB Mass Storage device detected
[100017.167643] scsi host2: usb-storage 2-1:1.0
[100019.534066] scsi 2:0:0:0: Direct-Access     Verbatim STORE N GO       PMAP PQ: 0 ANSI: 4
[100019.547410] sd 2:0:0:0: Attached scsi generic sg2 type 0
[100019.553337] sd 2:0:0:0: [sdc] 60506112 512-byte logical blocks: (31.0 GB/28.9 GiB)
[100019.568221] sd 2:0:0:0: [sdc] Write Protect is off
[100019.577351] sd 2:0:0:0: [sdc] No Caching mode page found
[100019.588887] sd 2:0:0:0: [sdc] Assuming drive cache: write through
[100019.608548]  sdc: sdc1
[100019.616559] sd 2:0:0:0: [sdc] Attached SCSI removable disk


**** Check transfer speed of USB2 flash drive plugged into USB3 port - cf. with USB3 flash (above)

/dev/sdc1:
 Timing buffered disk reads:  64 MB in  3.02 seconds =  21.16 MB/sec

*** Toshiba USB3-HDD plugged in to back USB2 port

[100141.509378] usb 1-1.3: new high-speed USB device number 3 using orion-ehci
[100141.660695] usb 1-1.3: New USB device found, idVendor=0480, idProduct=a006
[100141.667700] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[100141.675412] usb 1-1.3: Product: External USB 3.0
[100141.680301] usb 1-1.3: Manufacturer: Toshiba
[100141.684673] usb 1-1.3: SerialNumber: 2011122050148
[100141.696298] usb-storage 1-1.3:1.0: USB Mass Storage device detected
[100141.703863] scsi host2: usb-storage 1-1.3:1.0
[100146.542658] scsi 2:0:0:0: Direct-Access     TOSHIBA  External USB 3.0 0001 PQ: 0 ANSI: 6
[100146.556279] sd 2:0:0:0: Attached scsi generic sg2 type 0
[100146.562162] sd 2:0:0:0: [sdc] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[100146.576124] sd 2:0:0:0: [sdc] Write Protect is off
[100146.589486] sd 2:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[100146.637210]  sdc: sdc1
[100146.644491] sd 2:0:0:0: [sdc] Attached SCSI disk

**** Check transfer speed of Toshiba USB3-HDD plugged into rear USB2 port - cf. with USB2 flas drive (above)

/dev/sdc1:
 Timing buffered disk reads:  86 MB in  3.03 seconds =  28.43 MB/sec

So, as you can see, it appears more likely that it is a specific problem with that Toshiba drive. I suppose there is a possibility that it is a 'disk-type' problem i.e. rotating HDD vs Flash, but I'd like to think not! The fact that the new USB3 flash drive worked exactly as we would expect indicates there's nothing fundamentally wrong with the USB3 port. The three lines of output that start at [99878.888209] seem to show that the port really doesn't 'like' that Toshiba drive for some reason. Can you make anything from those three lines?

I feel that we might be chasing dreams here. As I've said before, the fact that the Toshiba drive works perfectly - if a little more slowly - in a rear USB2 port means that there's really not much to complain about. Interesting? Yes, of course - and, if nothing else, maybe a salutary lesson for others who hit the same or a similar problem. Thanks again for all your invaluable help and advice!

Regards - Mike
Re: NSA 325 V2 Debian Is Possible!
November 01, 2018 04:30PM
Is the Toshiba Canvio USB 3.0 hard drive powered via USB 3 or does it have it's own power supply? If it is USB bus powered the USB port may not be supplying sufficient power.

Ray
Re: NSA 325 V2 Debian Is Possible!
November 01, 2018 05:04PM
@Mike,

Quote

So, as you can see, it appears more likely that it is a specific problem with that Toshiba drive.

Yes it seems so.

Quote

I feel that we might be chasing dreams here. As I've said before, the fact that the Toshiba drive works perfectly - if a little more slowly - in a rear USB2 port means that there's really not much to complain about. Interesting? Yes, of course - and, if nothing else, maybe a salutary lesson for others who hit the same or a similar problem.

Quote

*** Plugged Toshiba USB3-HDD into front USB3 port.

root@debian:~# [99878.888209] xhci_hcd 0000:01:00.0: Cannot set link state.
[99878.893653] usb usb3-port1: cannot disable (err = -32)
[99878.899483] usb 3-1: USB disconnect, device number 2

That's what I've asked to see a few times :)

@Ray and Mike,

My bet is the problem is with the USB 3.0 controller on the Toshiba enclosure. The fact that it is working on the USB 2.0 port, tell us that there is enough power for USB 2.0. For testing purpose, if you take the internal disk out and use another USB 3.0 adapter to connect, I think it will work (I've seen USB 3.0 controller on toaster-type docks failed to be recognized in Linux).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
mikeinnc
Re: NSA 325 V2 Debian Is Possible!
November 01, 2018 08:02PM
Thanks everyone. Yes, Ray, I agree with Bodhi about power, I agree it can be a problem, but I have tried a USB2 HD drive in that USB3 port and it works perfectly - so I'm pretty confident that's not the problem this time. I like your proposal re: replacing the controller, Bodhi - but I think I'll call it quits for now! As I say, the drive - fundamentally - works, even if only in a USB2 port, and I hadn't planned on using it with the NSA box on a regular basis (I found the problem when I was using it to extract data from the original NSA325 disk that had an unusual 'raid' partition on it). Like most things electronic where software is involved, we just have to accept that not every scenario works. I'll mark it up as part of life's rich experience......

Thanks, again, for all your advice and help - Mike
Re: NSA 325 V2 Debian Is Possible!
March 21, 2019 04:48PM
First of all, big thank you for all who contributed to this project. It's awesome to have Debian running on this old hardware.

I have one question (or problem) though. I have the latest uBoot installed, should it boot the factory software if no rootfs partition is found? I was careless and managed to use flash_erase_all instead of flash_erase on mtd0, and of cours misplaced the memory stick where I saved the backup. Could this be why the original Zyxel system is not starting?
Re: NSA 325 V2 Debian Is Possible!
March 21, 2019 06:15PM
Hey, the variables for the new uboot are not configured to boot stock from Flash. If there's no rootfs partition on any device your box will not boot.
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: