Subject: Re: Porting mips based routers

From: Henk <[email-masked]>
Date: Thu, 14 Apr 2005 23:06:45 +0200

On Thu, Apr 14, 2005 at 07:05:27PM +0100, Ralf Baechle wrote:
> On Thu, Apr 14, 2005 at 06:26:34PM +0200, Henk wrote:
> > There's an initial wiki page on the openWRT site.
> > http://openwrt.org/Kernel26Firmware
> > 
> > If so I would like to see if we can set up some colaborative effort...
> 
> None of the code for the routers or ASICs has been contributed back to
> linux-mips.org so far so all you'll find there is a little blurb in the
> wiki and a bunch of pointers.

That little blurb in the wiki I contributed yesterday, in the hope of
raising some interest in the openwrt community ;)

I will try to see if I can get a list of 2.4 source files that need to
be contributed back to linux-mips.org, with a quick initial proposal on
how to migrate this to the 2.6 kernel tree.

The list can then be reviewed here (possibly added with comments on expected
code changes) and could serve as an initial porting roadmap.

Regards,
Henk

---

From: Waldemar Brodkorb <[email-masked]>
Date: Fri, 15 Apr 2005 08:55:58 +0200

Hi,
Henk wrote,

> how to migrate this to the 2.6 kernel tree.

If you like to help, I would be giving you detailed information
about the needed source code changes/addons.

I ported Linksys 2.4.20 patches to linux-mips 2.4.29 and added some
quirks to get the wlan binary kernel modul working.

All the stuff is really new for me, that is the reason I wait before
I contribute it back, because I like to see how stable this stuff
is in reality.

But may be it is time to send some patches...
 
bye
   Waldemar 

-- 
Waldemar Brodkorb                       [email-masked]                                     
dass IT GmbH                               Phone: +49.221.3565666-0
http://www.dass-IT.de                        Fax: +49.221.3565666-10

---

From: Henk <[email-masked]>
Date: Mon, 18 Apr 2005 14:48:09 +0200

> > how to migrate this to the 2.6 kernel tree.

See section 1.3 on the wiki page:
http://openwrt.org/Kernel26Firmware
Feel free to comment here on the list.

General comments on the WRT code:
 - There's some code bloat that enables the inclusion of code in other OS's
  this should probably be removed.
 - We should probably make some abstraction/API of the so called Silicon
  Backplane bus that broadcom defined. I see allot of drivers, even in
  the mainline kernel (b44 ethernet driver) that use this.

> about the needed source code changes/addons.

Yes! Do you have any objection to make these publicly available?

> But may be it is time to send some patches...

Again yes, it should be possible to get this train rolling with some colaborative effort.

Regards,

Henk

---

From: Andy Isaacson <[email-masked]>
Date: Tue, 19 Apr 2005 11:32:59 -0700

> Feel free to comment here on the list.

One comment:

# - Migrate: Should we cluster this with the sibyte stuf? Probably
# there's some shared code....

SiByte and the 47xx don't share anything significant beyond both being
MIPS, and both running CFE.  And people (including Ralf) actually have
SiByte hardware that they test on.  So not breaking SiByte would be a
good thing.

Because there's no technical connection between SiByte and 47xx I'd lean
towards leaving the SiByte stuff alone, and clean up the 47xx code on
its own.

> General comments on the WRT code:

The code is full of "Broadcom Proprietary" and "All Rights Reserved"
notices.  Does anyone have a clear written statement from Broadcom that
it's redistributable?  (If you're depending on the GPL release
requirements to justify relicensing, clear documentation of the chain of
release would be helpful.)

>   the mainline kernel (b44 ethernet driver) that use this.

The Silicon Backplane bus actually came from another company, it wasn't
defined by Broadcom; google knows all:
http://www.ocpip.org/socket/adoption/sonics

I think there are other OCP busses supported in the kernel; ISTR seeing
some PPC SoC from IBM that uses OCP... so perhaps this should be brought
up on l-k for general discussion.

But it's challenging to come up with a useful abstraction that covers
both the b44 scenario and the SoC scenario.

 - for b44, OCP is on the far side of the PCI bus, and is used only to
   access a single core (ethernet MAC).

 - for bcm947xx (and ppc SoC, I guess), OCP is the system bus, and is
   used to access everything from PCI to DRAM.

grep grep grep... Take a look at include/asm-ppc/ocp.h and
arch/ppc/platforms/*.c, it looks like the PowerPC people have already
done a bunch of work here.

-andy

---

From: Henk <[email-masked]>
Date: Tue, 19 Apr 2005 23:35:29 +0200

> towards leaving the SiByte stuff alone, and clean up the 47xx code on
Point taken, we should have a seperate broadcom branch.
I will update this on the wiki.

> release would be helpful.)

Maybe we should create patch sets that will transform the original wrt
branch into 2.6 code.

Anyway I don't think broadcom is a criminal company, I think it is obliged
by law to comply with the requirements of the GPL ;)

> done a bunch of work here.
Also of interest may be the new SOC abstraction on the hh.org branch, see
http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/Documentation/soc.txt

Thanks for your comments, greatly appreciated, I will update the OCP stuff
on the wiki.

The task seems a little more challenging than a week ago, anyway I will
focus on the boot code for a while so I can boot test kernels without
the need for reflashing...

regards,

Henk

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 20 Apr 2005 11:27:24 +0100

> release would be helpful.)

Broadcom's interpretation of these comments is that they don't contradict
the GPL.

> both the b44 scenario and the SoC scenario.

OCP is basically ISA on steroids - no configuration space, no nothing so
there is not terribly much OCP code that could potencially be shared.
Right now we treat OCP devices such as on PMC-Sierra's RM9000 series as
platform devices.

I'm clearly less than impressed by OCP ...

  Ralf