DSM-G600, DNS-3xx and NSA-220 Hack Forum

Unfortunately no one can be told what fun_plug is - you have to see it for yourself.

You are not logged in.

Announcement

#1 2011-01-04 21:09:37

puterboy
Member
Registered: 2008-09-18
Posts: 306

Can Fonz's ffp reloaded be compiled to work with new kernels?

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

 

#2 2011-01-04 22:03:03

fonz
Member / Developer
From: Berlin
Registered: 2007-02-06
Posts: 1716
Website

Re: Can Fonz's ffp reloaded be compiled to work with new kernels?

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

 

#3 2011-01-04 22:06:09

fonz
Member / Developer
From: Berlin
Registered: 2007-02-06
Posts: 1716
Website

Re: Can Fonz's ffp reloaded be compiled to work with new kernels?

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

 

#4 2011-01-05 01:08:33

puterboy
Member
Registered: 2008-09-18
Posts: 306

Re: Can Fonz's ffp reloaded be compiled to work with new kernels?

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

 

#5 2011-01-05 12:08:29

haim
Member
Registered: 2010-01-13
Posts: 83

Re: Can Fonz's ffp reloaded be compiled to work with new kernels?

@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

 

#6 2011-01-06 02:51:43

puterboy
Member
Registered: 2008-09-18
Posts: 306

Re: Can Fonz's ffp reloaded be compiled to work with new kernels?

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

 

#7 2011-01-06 11:20:15

haim
Member
Registered: 2010-01-13
Posts: 83

Re: Can Fonz's ffp reloaded be compiled to work with new kernels?

ahhh makes sense.

How would performance and memory usage compare between an alt-f setup and a reloaded debian on usb?

Offline

 

#8 2011-01-06 15:48:28

puterboy
Member
Registered: 2008-09-18
Posts: 306

Re: Can Fonz's ffp reloaded be compiled to work with new kernels?

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

 

#9 2011-01-07 10:12:49

haim
Member
Registered: 2010-01-13
Posts: 83

Re: Can Fonz's ffp reloaded be compiled to work with new kernels?

Thanks for the info.

I believe you are right about the location of root, although I'm not an authority on it.

Offline

 

#10 2011-01-07 12:24:38

Mijzelf
Member / Developer
Registered: 2008-07-05
Posts: 709

Re: Can Fonz's ffp reloaded be compiled to work with new kernels?

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

 

Board footer

Powered by PunBB
© Copyright 2002–2010 PunBB