Debian on NSA325 V1/V2
Posted by Buttzy10169
|
Re: NSA 325 V2 Debian Is Possible! October 23, 2018 04:37AM |
Admin Registered: 13 years ago Posts: 18,543 |
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
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:
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.
> (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:
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
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:
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
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 |
Admin Registered: 13 years ago Posts: 18,543 |
Mike,
Yes, 128MB was a typo! I should have said "NAND block is 128KB".
And about
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.
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.......
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 |
Admin Registered: 13 years ago Posts: 18,543 |
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)
> 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:
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
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 |
Admin Registered: 13 years ago Posts: 18,543 |
Mike,
> But - why are my environment variables so
> apparently wrong?
Because you've missed step 8 during installation (or missed parts of 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.
> 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.
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
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:
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
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
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:
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
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 |
Admin Registered: 13 years ago Posts: 18,543 |
This env should be adjusted:
should be
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
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
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 |
Admin Registered: 13 years ago Posts: 18,543 |
Mike,
Let me take a close ook later today.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
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 |
Admin Registered: 13 years ago Posts: 18,543 |
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)
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 |
Admin Registered: 13 years ago Posts: 18,543 |
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)
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
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 |
Admin Registered: 13 years ago Posts: 18,543 |
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)
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 |
Admin Registered: 13 years ago Posts: 18,543 |
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)
-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):
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
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 |
Admin Registered: 13 years ago Posts: 18,543 |
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)
> 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
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 |
Admin Registered: 13 years ago Posts: 18,543 |
> 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)
> 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:
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
**** 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 |
Registered: 9 years ago Posts: 442 |
|
Re: NSA 325 V2 Debian Is Possible! November 01, 2018 05:04PM |
Admin Registered: 13 years ago Posts: 18,543 |
@Mike,
Yes it seems so.
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)
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
Thanks, again, for all your advice and help - Mike
|
Re: NSA 325 V2 Debian Is Possible! March 21, 2019 04:48PM |
Registered: 5 years ago Posts: 6 |
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?
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 |
Registered: 5 years ago Posts: 125 |
