I have this Belkin router with the default firmware running 2.4.30.
Belkin provided the source code as specified by the GPL. I was wondering
how hard it would be to upgrade the kernel from 2.4.30 to 2.4.37.7. I
know that 2.6 would be extremely hard because the driver model has
changed so much. But, what changes happened between .30 and .37 that
would make it difficult to upgrade the code? Did the driver model or
other drastic changes happen? Could I just do a file diff; import the
new files Belkin added and update the make files and kconfig?
The CPU and wireless card are based on the Ralink 2880/2860 or something
like that.
Justin Madru
Hello,
On Fri, Jan 29, 2010 at 12:29:52PM -0800, Justin Madru wrote:
> I have this Belkin router with the default firmware running 2.4.30.
> Belkin provided the source code as specified by the GPL. I was wondering
> how hard it would be to upgrade the kernel from 2.4.30 to 2.4.37.7. I
> know that 2.6 would be extremely hard because the driver model has
> changed so much. But, what changes happened between .30 and .37 that
> would make it difficult to upgrade the code? Did the driver model or
> other drastic changes happen? Could I just do a file diff; import the
> new files Belkin added and update the make files and kconfig?
it will very likely work even without any change. I have some drivers
in my private tree which were written for various versions between
2.4.23 and 2.4.33, most of which apply without problem. In general
the only conflicts you can get are in Config.in or the makefiles
where the patch wants to add one line to enable the driver, because
the context might have changed. But that's really obvious to fix.
> The CPU and wireless card are based on the Ralink 2880/2860 or something
> like that.
Well, if you have the 2.4 driver and the hardware, it could also be
a nice exercise to try to port it to 2.6. It's not necessarily that
much complicated, as there are several drivers which are compatible
with both 2.4 and 2.6. They generally rely on some #define to rename
some struct members or use different macros depending on versions.
Regards,
Willy
Justin Madru <jdm64 <at> gawab.com> writes:
> I have this Belkin router with the default firmware running 2.4.30.
> Belkin provided the source code as specified by the GPL. I was wondering
> how hard it would be to upgrade the kernel from 2.4.30 to 2.4.37.7. I
> know that 2.6 would be extremely hard because the driver model has
> changed so much. But, what changes happened between .30 and .37 that
> would make it difficult to upgrade the code? Did the driver model or
> other drastic changes happen? Could I just do a file diff; import the
> new files Belkin added and update the make files and kconfig?
>
> The CPU and wireless card are based on the Ralink 2880/2860 or something
> like that.
Support for these chips is being worked on in the OpenWrt project.
We have some work in progress code based on Linux 2.6.32. It will be submitted
upstream when it's complete. Feel free to help us complete it, if you want to ;)
I know the code that Ralink provides for these chips, and I'd say any time spent
on changing it or using it for any purpose other than deriving hardware
information is a complete waste of time.
- Felix
On 01/29/2010 12:36 PM, Willy Tarreau wrote:
> Hello,
>
> On Fri, Jan 29, 2010 at 12:29:52PM -0800, Justin Madru wrote:
>
>> I have this Belkin router with the default firmware running 2.4.30.
>> Belkin provided the source code as specified by the GPL. I was wondering
>> how hard it would be to upgrade the kernel from 2.4.30 to 2.4.37.7. I
>> know that 2.6 would be extremely hard because the driver model has
>> changed so much. But, what changes happened between .30 and .37 that
>> would make it difficult to upgrade the code? Did the driver model or
>> other drastic changes happen? Could I just do a file diff; import the
>> new files Belkin added and update the make files and kconfig?
>>
> it will very likely work even without any change. I have some drivers
> in my private tree which were written for various versions between
> 2.4.23 and 2.4.33, most of which apply without problem. In general
> the only conflicts you can get are in Config.in or the makefiles
> where the patch wants to add one line to enable the driver, because
> the context might have changed. But that's really obvious to fix.
>
>
>> The CPU and wireless card are based on the Ralink 2880/2860 or something
>> like that.
>>
> Well, if you have the 2.4 driver and the hardware, it could also be
> a nice exercise to try to port it to 2.6. It's not necessarily that
> much complicated, as there are several drivers which are compatible
> with both 2.4 and 2.6. They generally rely on some #define to rename
> some struct members or use different macros depending on versions.
>
> Regards,
> Willy
>
>
>
Well, it's good that the driver might easily be updated to the latest 2.4.
I did a diff of the source code that was provided against 2.6.30.
Unfortunately, it looks like there's been more changes to the code than
simply adding drivers. Updates all across the tree have been made, some
minor that would be an easy merge. But some seem to be more involved
changes. Any suggestions on merging the code?
Justin
Hello,
On Sun, Jan 31, 2010 at 08:05:54PM -0800, Justin Madru wrote:
> Well, it's good that the driver might easily be updated to the latest 2.4.
>
> I did a diff of the source code that was provided against 2.6.30.
> Unfortunately, it looks like there's been more changes to the code than
> simply adding drivers. Updates all across the tree have been made, some
> minor that would be an easy merge. But some seem to be more involved
> changes. Any suggestions on merging the code?
Then I'd suggest that you progressively apply all 2.4 versions one by
one on top of their code. You should have less changes that way and
since you'll have changelogs, you'll be able to tell what the changes
want to do and whether you have to merge them or you can ignore them.
Once you reach 2.4.32, you can even choose to apply all patches one
at a time because the kernel migrated to use GIT. There are "only"
608 patches. Those are quickly reviewed to eliminate the arch-specific
ones you don't care about and only keep generic fixes.
Well that's just an idea. Also, keep a copy of intermediate versions
(or ideally put them into a git tree starting at plain 2.4.30).
Hoping this helps,
Willy