Use of PogoPlug NAND

[LavaChild]

Hello!

I've a question I hope you may be able to answer. I've been holding off posting this one for a while because I am sure I'll get flamed by those that see this as an 'obvious' question but I assure you I have spent time trying to answer this myself. Note that although I am interested in the answers to my questions in their generality, I am asking from the point of view of a PogoPlug v2 owner.

On the Arch Linux ARM website it states that PogoPlug v2 (Pink/Gray) has a NAND of 128MB [*]. Can somebody please explain what this is used for when ALARM is installed as per the 'official' installation guide [**]?

From my understanding this holds *only* the UBoot and Kernel (stage 3 of instructions), with RootFS (including /boot) installed to the USB drive (stage 7 of instructions). Again, from my understanding the UBoot installed is the 'stock' PogoPlug UBoot with some otherwise 'spare' space used to add extra functionality required for ALARM such as the ability to boot from USB drives.

If my understanding has been correct up to now; what else can the internal NAND be used for? For example, can we install ALARM (or anything else useful) to it instead? For example, I have zero interest in the PogoPlug OS being left available for use and would rather something else.

I notice that the instructions for the different supported ARMv5 devices (let's keep it simple and restrict ourselves to this class) are all slightly different. Presumably ALARM is the same so I can only imagine the difference is down at the UBoot level. Does one device offer more functionality in this region than another? For example, I have noticed that the Seagate GoFlex Home and Net instructions mention installing UBoot Install Toolkit (UBIT) [***] which research suggests is a recovery tool. Is it possible to put this on the PogoPlug and if so why does the PogoPlug guide not detail this?

I appreciate there is a lot to answer here however I would be very grateful if you could go through the questions I ask... I am finding my time here very interesting and I am learning a great deal about these devices, it'd be great to understand this area too!

Thanks!

[*] http://archlinuxarm.org/platforms/armv5 ... 2-pinkgray
[**] http://archlinuxarm.org/platforms/armv5 ... s-ui-tabs2
[***] http://archlinuxarm.org/platforms/armv5 ... s-ui-tabs2

[WarheadsSE]

The Kirkwood based Pogoplug V1 & V2 devices' NANDs are almost entirely un-modified, and only a chained u-boot is installed. There is no kernel put into NAND, and unless Jeff Doozan's method has changed for them, the u-boot is not outright replaced.

The PPV4 also has a chain-loaded u-boot placed into NAND.

The GoFlex models are a special case with UBIT/u-boot being placed into NAND, and to be honest, I do not fully understand what happens in that process.

The Pogoplug V3 (and all PLX NAS782x, ox820 "oxnas") boards have an alteration made to u-boot parameters, and 2 copies of a kernel placed into NAND.

Various other v5te architectures have other easier boot methods.

[LavaChild]

Thank you for the breakdown

Specific to the PogoPlug v2 - Can the NAND be used for anything else? For example, would it be possible to install ALARM directly to this? (Even if not for 'permanent' use, just as a backup as the original PogoPlug OS is used now).

I appreciate you do not fully understand the GoFlex boot process, but do you know 'how' the GoFlex and (say) PogoPlug v2 UBoot process differs? Does the GoFlex UBoot (in NAND) offer something over the PogoPlug v2 one? (I keep reading about 'recovery'). If so, is it possible to use this on the PogoPlug v2?

The only reason I ask is because the ALARM installation (intentionally) leaves the PogoPlug OS alone as much as possible, however I have no need (or want) for the PogoPlug OS and so I would be happy to put the NAND to better use should this be possible.

Thanks for your help and understanding

[WarheadsSE]

Honestly, you can do what you want with the NAND, but understand the file systems used, why they are used, and limiting factors such as writes, space and make appropriate changes. You don't want to run a "stock" alarm install in NAND.

[LavaChild]

I see, thanks

Definitely something for me to research - Lot's to learn! Do you have any particular recommendations, Google aside, to read about some of the factors you mention? E.g., file systems used, why they are used, and limiting factors such as writes, space and appropriate changes.

Are you aware of any particular uses that the 'community' are investigating for use with the NAND? System recovery or NAND-specific (considering the factors mentioned previously) ALARM installations, etc?

Thank you!