Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Pages: 1
Will ffp-reloaded source code compile and work on new armel architectures. E.g 2.6.32 orion flavors?
If not what must be changed to make it work.
Thanks!
Offline
Not sure I understand your question. If you want to use the reloaded function to leave the firmware behind and start a recent kernel, then it's possible. It's what ffp-reloaded was made for, actually.
Offline
From your other post, I read that you want to use the reloaded module while running a recent kernel.
If that's the question, then you need to recompile the kernel module against the kernel sources of the running kernel. I don't think you need to change anything. Only recompile so the binary module can be loaded by the running kernel.
Offline
Thanks Fonz. That was exactly my question. I am interested in using ffp-reloaded to reload a new kernel directly rather than having to first reboot through the original firmware and then reload the new kernel.
Offline
@puterboy - You could instead take a look at alt-f, a replacement firmware which runs a stripped down new kernel and enables installing it's own packages and ffp packages. It might be easier than doing it all yourself.
Take a look in the custom firmware section or google alt-f
Offline
Actually, I have been using ffp reloaded for several years now.
2 years ago I wrote and posted automated scripts that allow you to free up the memory occupied by the ramdisk while preserving all the existing firmware functionality by reloading the kernel with root on a USB disk or on a hard-drive. Much of the script is error checking since it all happens automatically from system startup.
Now I am interested in running a Debian install (with a Debian kernel, not a chroot) - but again I like the idea of using the reloaded module so that I don't have to mess with the firmware. But with Debian running, I like the idea of being able to reload the Debian kernel directly from Debian rather than having to reboot first into the old firmware and then reload.
I prefer the flexibility of running Debian off the hard drive or USB rather than having to cram it all into a stripped down firmware along with the dangers of messing with the firmware every time I want to upgrade kernels.
But Alt-F is still interesting of course in its own right.
Offline
ahhh makes sense.
How would performance and memory usage compare between an alt-f setup and a reloaded debian on usb?
Offline
If alt-f is like the original firmware then memory is much better since the root filesystem is stored on disk (either internal or USB). This frees up 16+MB of memory and except for the kernel footprint (which is only a few MB and pretty small when all the added functionality is in modules), you pretty much have all the rest of the memory available for added services and user space programs along with Linux buffers.
Regarding speed, well an internal disk will be faster than root on USB. But in general you shouldn't detect much speed difference since the kernel is always stored in memory and any frequently used routines will be cached. I mean my setup is exactly like a standard non-embedded systems where the root filesystem is almost always on a hard disk -- and you don't see people using a ram-based root filesystem in general use.
In fact, my way is likely to in general be *FASTER* since more memory available means less memory swapping to disk which is typically the real speed culprit.
Now if ALt-F uses a disk-based root then they would be similar, but my guess is that most basic replacement firmwares also use a ram-disk for root.
Offline
Thanks for the info.
I believe you are right about the location of root, although I'm not an authority on it.
Offline
puterboy wrote:
Regarding speed, well an internal disk will be faster than root on USB. But in general you shouldn't detect much speed difference since the kernel is always stored in memory and any frequently used routines will be cached.
Actually I think a rootfs for an embedded Linux system is faster on an USB stick than on a disk. A stick can do, let's say, 10MB/sec, while a disk can do 50. (I don't think a disk will be that fast on a NAS). But the access time for a disk is about 10msec/file, while it is around 0 msec on an USB stick. That means that a file smaller than 100kB will be loaded from stick, before the disk will even have positioned it's heads at the right place. There are not much files bigger than 100kB.
Offline
Pages: 1