plugout.net

Hey

Is there any change that you can get gpt working on a network space 2 classic.
I've bought a 3TB WD Green hdd with the stupid thought that my nwsp2 would support it.
But apparently i do have the classic nwsp2, so i can't get it working.

Any chance that this can be fixed, or did i thew away a lot of money for an upgrade that isn't possible?

Cheers,
Minibike12

The kernel we use supports GPT, the problem is the boot loader (U-boot) of the nwsp2 classic, that doesn't support it. That means a new adapted boot loader must be put in flash memory. Besides the problem of adapting the source code to get a working U-boot there is another risk. If flashing fails you will have a brick instead of a NAS and require special tools to bring it back to life. The boot loader is a tiny program that loads Linux and the rest of the firmware.

In the summer of this year I looked in detail in this and the goal is to be able to modify the flash when the nwsp2 is running using Linux. The goal is to set the boot loader to look at partition 4 for a kernel instead of 7. If that succeeds then probably we can get it working. However the question will be if I will be brave enough to write in the flash with the risk to make a brick out of the nwsp2.

Thanks for you message.
I've indeed noticed that the boot-loader was the problem.

Did you already make a compatible boot-loader?
And what tool do you need to unbrick it, JTAG, or ISP?

Any change that it will be possible to flash the bootloader in a "save" way?

JTAG will be needed

no I do not have an updated u-boot yet although I was able to compile the lacie source. I am still looking for the difference between bootloader of nwsp lite and classic. Unfortunate the u-boot source code for the lite is not published until today. So it will not be on short notice, but it is still on the to do list.

If I manage to get read/write access from userland (linux) then it should be possible

I have come this far in the summer output from kernel when staring up (dmesg)

Code: Select all

<snip>
m25p80 spi0.0: mx25l4005a (512 Kbytes)
Creating 2 MTD partitions on "spi_flash":
0x000000000000-0x00000007dfff : "u-boot"
mtd: partition "u-boot" doesn't end on an erase block -- force read-only
0x00000007e000-0x00000007f000 : "u-boot-env"
<snip>


I can write to u-boot-env but that is overwritten by u-boot at boot so changing that is useless, need to find the correct end block and then recompile the kernel

Hmm okey.
I might have some access to JTAG.
Do we need a specific JTAG? (i'm not that familiar with JTAG yet).
And is there a way to pull the u-boot out of the Lite?

P.s. I am dutch too, so talking dutch is an option.

There might be another solution. Create the partitions 1,5-10 as usual, but omit partition 2. This will fill only the first 2GiB of the disk. If the bootloader isn't confused by the disksize, but succeeds in finding and loading the kernel, change some startscript. Instead of mounting sda2 as data partition, create a loop device:

Code: Select all

losetup -o 2147483648 /dev/loop0 /dev/sda

Now mount /dev/loop0 as data partition. Of course the offset must be big enough to bridge the OS partitions, and be a multiple of 512. (4096 in case of an 'advanced format' disk)

thanks for this tip Mijzelf, but our partition structure deviates from Lacie standard
In our case the data partition is partition 8.
Number 1 to 7 are system partitions and rather small and your suggestion is interesting, unfortunate I can not test it as I don't have a 3 TB disk

ps the bootloader expect an ms-dos partition table so a problem will arise when defining partition 4, that must an extended one covering the remainder of the disk..and then you have the max blocks issue again.

There might be another solution. Create the partitions 1,5-10 as usual, but omit partition 2. This will fill only the first 2GiB of the disk. If the bootloader isn't confused by the disksize, but succeeds in finding and loading the kernel, change some startscript. Instead of mounting sda2 as data partition, create a loop device:

Code: Select all
losetup -o 2147483648 /dev/loop0 /dev/sda

Now mount /dev/loop0 as data partition. Of course the offset must be big enough to bridge the OS partitions, and be a multiple of 512. (4096 in case of an 'advanced format' disk)

That might be a good idea.
Will this have a big impact on performance?
And i should be able to access the full 3TB with this method?

Also, do you know a guide to setup this loop device, since i don't know what offset to use, etc.
And what does the 2147483648 stand for in the losetup -o [edit: ah this will be the offset, how can i calculate this?]

I do have the 4096 advanced disk format.

And creating partitions 1,5-10, shall i make this with fdisk as usual, with this guide.

thanks for this tip Mijzelf, but our partition structure deviates from Lacie standard
In our case the data partition is partition 8.
Number 1 to 7 are system partitions and rather small and your suggestion is interesting, unfortunate I can not test it as I don't have a 3 TB disk

ps the bootloader expect an ms-dos partition table so a problem will arise when defining partition 4, that must an extended one covering the remainder of the disk..and then you have the max blocks issue again.

I think that mijzelf is referring to the original partition structure.
I don't care if i am using the original lacie firmware, or the custom nwsp2 firmware.
As long as i can get it working, i'll be happy :)

But is there any change that we can pull the uboot from the lite?
Maybe with JTAG?

But is there any change that we can pull the uboot from the lite?
Maybe with JTAG?

thats a no go, because processor and mainboard are different on the Lite, so U-boot needs to be compiled specific for the classic board just like a Linux kernel with the proper settings for the hardware.

I meant pull the U-Boot from the lite so you can compare them this way to make a GPT compatible U-Boot for the classic.
This instead of waiting for the sourcecode.