headers
Adam Hamsik | 2 Oct 2007 10:53
Picon
Gravatar

flashing linksys with netbsd


Hello folks

I have chosen my  school project,  I will write step by step guide  
howto install netbsd on linksys router. But I have some questions.

Informations about my router:

Linksys wrt54GL v1.1

Bootloader     : CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
System-On-Chip : Broadcom 5352EKPB
CPU Speed      : 200 MHz
Flash size     : 4 MB (Intel TE28F320 or Samsung)
RAM            : 16 MB (Hynix HY5DU281622ET)
Wireless       : Integrated Broadcom BCM2050KML
Switch         : Built-in
USB            : None
Serial         : yes (JP2)
JTAG           : assumed on JP1

The WRT54GL v1.1 uses a Broadcom 5352 CPU with integrated switch.

Questions?

1) Do you have some hints how to build and boot netbsd for this platform

   build.sh -m {mipsco|evbmips} tools

   build.sh -m {mipsco|evbmips} distribution
(Continue reading)

Permalink | Reply | 2 comments |
headers
Martijn van Buul | 2 Oct 2007 13:09

Re: flashing linksys with netbsd

* Adam Hamsik:
>
> Hello folks
>
> I have chosen my  school project,  I will write step by step guide  
> howto install netbsd on linksys router. 

Warning, you might have bitten off more than you can chew :(

> 1) Do you have some hints how to build and boot netbsd for this platform

we don't support it (yet). You'd have to start a new port for it, which is a
lot more work than writing a howto. A *lot* more work. I guess you can borrow
quite a bit from other mips targets.

> 2) Any hints how to get network run ? Do we or FreeBSD,OpenBSD have  
> drivers for that switch ?

Nope. It's a tagged switch, which defaults to isolating all ports, so without
*some* support for it, the built-in ethernet NIC is useless. To add insult
to injury, the our bce driver (which would *probably* work) has no VLAN
support. 

There's no hope from Linux either; even though there are several Linux
distributions out for these critters, they all communicate with the switch
using a binary-only kernel module and proprietary tools. 

> And what about wifi it is Integrated  Broadcom BCM2050KML.  

Yes, and as such not supported. Open source Linux drivers are rumoured to
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Young | 2 Oct 2007 21:06
Picon
Favicon

Re: flashing linksys with netbsd

On Tue, Oct 02, 2007 at 10:53:33AM +0200, Adam Hamsik wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello folks
> 
> I have chosen my  school project,  I will write step by step guide  
> howto install netbsd on linksys router. But I have some questions.

Hi Adam,

One of my Google Summer of Code students in 2006, Ada Lim, began porting
to the Asus WL-500G, which must resemble your Linksys WRT54.  I have
the sources, and I will be happy to share them with you.  As I recall,
Ada did not get her Asus router to boot to single-user, and lots has
changed in -current since Ada began her port.

Carefully weigh the costs with the benefits of developing for this
particular platform: the Broadcom chips are poorly documented,
and developing without proper documentation is oftentimes risky and
frustrating.  The capabilities of the Linksys router are rather low:
to the best of my knowledge, nobody runs a useful NetBSD router in 4 MB
Flash and 16 MB RAM; shrinking NetBSD to fit on such a router would be
a major contribution in and of itself.  Also, the availability of the
WRT54GL is not assured.

Producing a driver for the Broadcom wireless may be a lot of pain for
very little gain, depending how you get your kicks :-).  I believe it
deserves to be a separate project.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Toru Nishimura | 4 Oct 2007 17:09

Re: flashing linksys with netbsd

David Young dyoung <at> pobox.com  said;

> Let me suggest a few embedded projects that I believe are less risky and
> more widely applicable.
>
>        * develop a driver for the NAND Flash storage on the RouterBOARD
>         1xx series, www.RouterBOARD.com.  Demo writing a bootable
>          NetBSD image to the Flash.  Demo running NetBSD from the flash
>          (read-only).
>
>          (RouterBOARD is an open-architecture board with MiniPCI slots
>          for wireless cards, et cetera.  The cheapest boards in the
>          1xx series have no CompactFlash slot.)

I've ported NetBSD to Mesa Electronics 4C81 PC104plus SBC.  The storage
is 32MB/64MB bare NAND which holds BSDFFS.  Bad blocks are forwarded
by a preconfigured badblock list.  No MTD included.  Bootloader knows and
handles /netbsd.  The NAND block device driver allows writes.  It'd be likely
to get highly criticized but the decision was made weighing "the rootfs is
seldom written beyond configuration mods by administrators."  Software ECC
is always calc'ed and verified, block write is counted and recorded inside
NAND spare fields.

Toru Nishimura/ALKYL Technology
Permalink | Reply | 1 comment |
headers
David Young | 5 Oct 2007 03:16
Picon
Favicon

nand flash (was Re: flashing linksys with netbsd)

On Fri, Oct 05, 2007 at 12:09:10AM +0900, Toru Nishimura wrote:
> David Young dyoung <at> pobox.com  said;
> 
> >Let me suggest a few embedded projects that I believe are less risky and
> >more widely applicable.
> >
> >       * develop a driver for the NAND Flash storage on the RouterBOARD
> >        1xx series, www.RouterBOARD.com.  Demo writing a bootable
> >         NetBSD image to the Flash.  Demo running NetBSD from the flash
> >         (read-only).
> >
> >         (RouterBOARD is an open-architecture board with MiniPCI slots
> >         for wireless cards, et cetera.  The cheapest boards in the
> >         1xx series have no CompactFlash slot.)
> 
> I've ported NetBSD to Mesa Electronics 4C81 PC104plus SBC.  The storage
> is 32MB/64MB bare NAND which holds BSDFFS.  Bad blocks are forwarded
> by a preconfigured badblock list.  No MTD included.  Bootloader knows and
> handles /netbsd.  The NAND block device driver allows writes.  It'd be 
> likely
> to get highly criticized but the decision was made weighing "the rootfs is
> seldom written beyond configuration mods by administrators."  Software ECC
> is always calc'ed and verified, block write is counted and recorded inside
> NAND spare fields.

How do you handle the bad blocks that develop as the device "wears" ?

Dave

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Toru Nishimura | 5 Oct 2007 04:00

Re: nand flash

David Young  asked;

>> but the decision was made weighing "the rootfs is
>> seldom written beyond configuration mods by administrators."  Software ECC
>> is always calc'ed and verified, block write is counted and recorded inside
>> NAND spare fields.
>
> How do you handle the bad blocks that develop as the device "wears" ?

The answer is "by manual intervention," just like good-old-days Winchester
style hard disk drive bad sector management practice.  I wrote a cmdline
tool to manage bad block list and relocate block contents.  In principle we
neglect the whole NAND woe/buzz to happen due to the above mentioned
rational.  "this tools may cause hazardous results to hurt you, trained service
personel only, or don't use this."

If I have chose MMC/SD/CF media to go, I would build vnd on a large file
on the FAT filesys and forget how good/bad to gauge badblock and
wear-leveling schemes inside.

Toru Nishimura/ALKYL Technology
Permalink | Reply | 1 comment |
headers
YoctoGram | 5 Oct 2007 04:29
Picon

Re: nand flash

>>> I've ported NetBSD to Mesa Electronics 4C81 PC104plus SBC.  The storage
>>> is 32MB/64MB bare NAND which holds BSDFFS.

>> How do you handle the bad blocks that develop as the device "wears" ?

Could LFS be more appropriate for 'wear levelling' ?
Especially now that we can use it as root filesystem...

// Yocto

----- Original Message ----- 
From: "Toru Nishimura" <locore64 <at> alkyltechnology.com>
To: <tech-embed <at> netbsd.org>
Sent: Thursday, October 04, 2007 10:00 PM
Subject: Re: nand flash

> David Young  asked;
>
>>> but the decision was made weighing "the rootfs is
>>> seldom written beyond configuration mods by administrators."  Software 
>>> ECC
>>> is always calc'ed and verified, block write is counted and recorded 
>>> inside
>>> NAND spare fields.
>>
>> How do you handle the bad blocks that develop as the device "wears" ?
>
> The answer is "by manual intervention," just like good-old-days Winchester
> style hard disk drive bad sector management practice.  I wrote a cmdline
> tool to manage bad block list and relocate block contents.  In principle
(Continue reading)

Permalink | Reply | 0 comments |
headers
H. Johnson | 5 Oct 2007 08:29

[TechEmbedBSD] Subject format for tech-embed BSD

Hi,
I appreciate the information contained in the forum, but find handling 
the individual emails more difficulty than it should be due to sparse 
info in the Subject line.

Would it be possible to prefix the Subject with something like 
[TechEmbedBSD] so the the Subject line reads as follows?

[TechEmbedBSD] Users subject appended here

Most other lists do this.

Thanks!
Permalink | Reply | 12 comments |
headers
SODA Noriyuki | 5 Oct 2007 09:36
Picon

Re: [TechEmbedBSD] Subject format for tech-embed BSD

>>>>> On Thu, 04 Oct 2007 23:29:06 -0700,
      "H. Johnson" <misc <at> faradayco.com> said:

> Would it be possible to prefix the Subject with something like 
> [TechEmbedBSD] so the the Subject line reads as follows?

Such configuration makes verification of DKIM signature (and DomainKey
Signature) fail.
So, anti-spam measures which use DKIM signature won't work with it.

Isn't it problematic?
--

-- 
soda
Permalink | Reply | 11 comments |
headers
Martin Husemann | 5 Oct 2007 10:20
Picon

Re: [TechEmbedBSD] Subject format for tech-embed BSD

It also wastes screen estates for those who file every group into their
own mailbox (or those who do not care for the exact list a thread is on).

I bet procmail (or similar tools) can do it localy on the receiver side.

Martin
Permalink | Reply | 0 comments |

Gmane