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

QuoteA. 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.

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:

QuoteBodhi
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.

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?

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.

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?

> 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).

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.

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).

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.

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!

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!!

QuoteBodhi
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).

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.

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.

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!

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!!

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!

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

Yes it seems so.

QuoteI 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.

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).

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......

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?

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.