256mb Nand Flash - Free Space For Apps?

[Prophet]

I don't know much about Linux (beyond trying a few livecd distros on my PC out of curiosity), but do you think there might be much space left free in the NAND after the OS?

I'm just wondering if it would be possible store a few regularly used apps there, or will users have to realistically store all apps on SD cards?

 

[craigix]

We don't really want anyone to mess with the NAND in any way, this includes programs trying to install libs to it.

We just want to avoid DLL hell or 'NAND is full' errors.

 

[Prophet]

OK, thanks.

 

[Zarneth]

We don't really want anyone to mess with the NAND in any way, this includes programs trying to install libs to it.

We just want to avoid DLL hell or 'NAND is full' errors.
What's intended to be stored there exactly then? Will the OS even run off it at all?

Would be good to store the users settings (home directory) there so they're consistent over any OS changes.

Oh and I assume you mean dependency hell.

 

[Vorporeal]

We don't really want anyone to mess with the NAND in any way, this includes programs trying to install libs to it.

We just want to avoid DLL hell or 'NAND is full' errors.
What's intended to be stored there exactly then? Will the OS even run off it at all?

Would be good to store the users settings (home directory) there so they're consistent over any OS changes.

Oh and I assume you mean dependency hell.

The firmware (and therefore the OS) is all stored on the NAND. Important libraries are stored there, but any other libraries used by an app should either be packaged in with the app or statically linked. Because it's just going to contain the basic OS files, it shouldn't be necessary to update it very often.

 

[Megamixman]

The main thing is that the NAND is part of the PCB or even the main SoC. Which means it is a PITA to replace if it fails. Flash is quite resilient when it comes to reads, but far less so when it comes to writes. Remember that the voltages being applied during writes are higher then reads. This combined with the limited amounts of writes means you need to be carefull, albiet far less then before. In the end better safe then sorry.
SD cards on the other hand, can easily be replaced with little headache(plus data loss).

 

[nubie]

2 SD slots, count them, 2 SD card slots.

You can find 4GB SD cards for under $30 nowadays, why would we ever want to store stuff on the NAND? If we are that pressed for space just leave a cheap (2GB $15 - 7 Pounds) SD in one of the slots.

I wouldn't want to touch the NAND anyway.

Unless of course you are going to have both slots filled with some sort of SD accessory (Cameras for 3D movie making?), I don't see a good reason for NAND writing.

 

[kloplop321]

I was thinking it would be simple for the O/S to install on the cards and have the $PATH variable linked to the cards' installation folders. Text links are small compared to the actual app

 

[Hitnrun]

Maybe adding by default an LD_LIBRARY_PATH pointing to the SD card? Like to /mnt/sd/lib? This way, an user could have in his card a new dynamic link library like SDL, so the applications could be dynamic linked.

 

[Qatz]

Why not have the base system mount the sd card via a union. That way it would be easy to add to the system(lib and exe wise) without modify the nand, and you would still be able to use the proper libs in the proper filesystem layout.

 

[bigtruck]

Why not have the base system mount the sd card via a union. That way it would be easy to add to the system(lib and exe wise) without modify the nand, and you would still be able to use the proper libs in the proper filesystem layout.

Ooh. I didn't know what that was, but after a bit of googling (go here for a brief explanation), that sounds perfect. I was thinking there would have to be some convoluted setup using symlinking or something, but a union mount would be perfect. It would just mean the SD would have to be unmounted when the OS is updated, or at least not mounted in this fashion, but I'd think that would be trivial. This would even allow people to try hacky things like installing newer versions of libraries than the official ones without any risk of breaking anything.

 

[AireTamStorm]

Why not have the base system mount the sd card via a union. That way it would be easy to add to the system(lib and exe wise) without modify the nand, and you would still be able to use the proper libs in the proper filesystem layout.

Ooh. I didn't know what that was, but after a bit of googling (go here for a brief explanation), that sounds perfect. I was thinking there would have to be some convoluted setup using symlinking or something, but a union mount would be perfect. It would just mean the SD would have to be unmounted when the OS is updated, or at least not mounted in this fashion, but I'd think that would be trivial. This would even allow people to try hacky things like installing newer versions of libraries than the official ones without any risk of breaking anything.


I discussed this in a previous topic. The idea is, reduce the writes on NAND while letting the OS get updates on libraries and install programs. Of course you would have to keep the SD card jacked into the Pandora most of the time, but that is what the Dual SD card slots are for.

 

[sindbad]

I plan on writing on that NAND all my user settings and every single package that fits. Those things are very, very resilient nowadays.

 

[aliking]

Thought this was a more applicable place for my question than starting a new thread even if it's on the older side...

I wondered; does the firmware have to do some really pretty new and clever stuff to cope with the fact that large sections of the working memory of the device can be removed? Or is this something that is coped with easily by linux usually?

For example if I want to unmount one of the SDs to take it out, how does the firmware cope with any apps that might have been loaded from there and might expect that memory space to exist?

Here's a use case: I want to transfer files between 2 SD cards. I already have 2 other SD cards inserted, one full of games, the other with apps and media. Maybe I've got a couple of apps or daemons running. How exactly could I go about making this transfer? The ideal way is to pop out the two that are in there, insert the 2 that I'm transfering data on and start copying, but is something horrible going to happen if I start removing the cards?

Not something that might happen often, but definitely one of the listed benefits whenever anyone says "Why 2 SDs?". Sorry if this is all a bit confused, but I'm a bit confused

a

 

[God Ginrai]

Thought this was a more applicable place for my question than starting a new thread even if it's on the older side...

I wondered; does the firmware have to do some really pretty new and clever stuff to cope with the fact that large sections of the working memory of the device can be removed? Or is this something that is coped with easily by linux usually?

For example if I want to unmount one of the SDs to take it out, how does the firmware cope with any apps that might have been loaded from there and might expect that memory space to exist?

Here's a use case: I want to transfer files between 2 SD cards. I already have 2 other SD cards inserted, one full of games, the other with apps and media. Maybe I've got a couple of apps or daemons running. How exactly could I go about making this transfer? The ideal way is to pop out the two that are in there, insert the 2 that I'm transfering data on and start copying, but is something horrible going to happen if I start removing the cards?

Not something that might happen often, but definitely one of the listed benefits whenever anyone says "Why 2 SDs?". Sorry if this is all a bit confused, but I'm a bit confused

a

Well, for all we know, the firmware might have its own app that copies files between two SDs.

As for keeping other programs running, it might be possible to load that app into RAM if it doesn't use too much space, but keep in mind this is purely conjecture on my part.

-God Ginrai

 

[sindbad]

Nothing usually happens to software that is already running if you delete/remove it, unless it continuously checks/reads for files in it's directory. I often remove/update software while it's running on my kubuntu box.

 

[WizardStan]

deleting a file from hard drive in Linux is not the same as physically removing the drive. If I recall correctly from my OS class (and it was quite a while ago, so things may have changed drastically, or I'm misremembering) a good OS will not delete open files. It'll delete the headers for it, and you can even overwrite with a new file of the same name, but the old file remains until it is closed. This includes executables. This is relevant because, in a memory swap system, if the executable needs to be swapped to disk, the OS may decide that it will just free the memory, knowing it can just go back to the original executable again, thus saving some mem copying. I never dealt with hot swappable media in that class, but it would seem to me that if running off an SD card, and then removing that SD card, the OS would have to be able to recognize that the software no longer exists else it may try to free the memory, swap back in the executable, and fail because it doesn't exist.
This is, of course, a moot point on the pandora since it doesn't perform memory swapping anyway.

On the other hand, if you're playing a game with large data files that need to be constantly read, removing the card will cause the game to fail on load. I once accidentally removed my memstick in my PSP in the middle of a game, and it continued to run fine until I moved onto the next screen and it locked up, at which point I realized I accidentally removed my memstick.
The Pandora, having a full OS, would probably handle it a lot more gracefully, presumably to the effect of throwing up an error "Cannot open file XYZ" and then either crashing the game, or possibly (if we're lucky) allowing you to reinsert the SD card and retry.

 

[TaG]

An SD card with apps on could be running 'background apps' eg a personal choice of GUI , or anything not included in the firmware. Under such circumstances would you still be able to unmount - I would have thought the OS saw it was in use and refuse to unmount.

 

[WizardStan]

If you tell the OS to unmount, sure. Doesn't keep you from accidentally (or purposefully) bumping it and ejecting the card.

 

[TaG]

If you tell the OS to unmount, sure. Doesn't keep you from accidentally (or purposefully) bumping it and ejecting the card.

OK. I haven't got hardware to test this for myself at present so...

Will the OS accept the two different SDs or be expecting to find the original files? Would just 'refreshing' bring up the new files/structure?