Marvell

[Dan Williams]

On Mon, 2007-09-10 at 22:37 -0400, Albert Cahalan wrote:
> Edward Cherlin writes:
> 
> > We need the Marvell documentation, and the location of the code OLPC
> > has written on top of the microkernel. (Both easy enough, I assume.)
> 
> You'd think so, but nobody has coughed this up despite repeated pleas.
> I can't even get the extra hardware I asked for, which gets to be
> rather critical when the time comes to test what things do.
> I also didn't get my project hosting request approved.
> 
> Not that documentation is required; reverse engineering is fun.
> 
> Martin Langhoff quoting Edward Cherlin:
> 
> >> Who would like to work on it?
> >
> > I think that is the key problem. If someone can hack in that area
> > (of which I only know enough to say that I cannot even get started),
> > and is interested/motivated enough to do it, they'd be doing it already.
> > The only thing you can do is roll up your sleeves and hack on it
> > yourself if you can, and start posting code and notes.
> 
> Indeed. Join the party. Notes are here:
> http://wiki.laptop.org/go/88W8388
> 
> For those who haven't ever tried it: reverse engineering is fun!
> It's a really intense mental activity. Unlike regular coding, it's
> even more fun with a friend. It would make a wonderful activity
> for sharing over the mesh. Of course, it's still plenty of fun all
> by yourself as you empty a 12-pack of Mountain Dew at 4:00 AM.
> Nothing is better for satisfying a hard-core hacking urge.
> 
> At least initially, you don't even need hardware for this. You can
> post your discoveries right here, anonymously if you prefer. Just
> get the firmware files and go for it.
> 
> BTW, if any of you are in the USA and start really enjoying this
> kind of thing, I can probably get you a job doing it full-time.
> 
> Bernardo Innocenti writes:
> 
> > Implementing the whole 802.11 protocol stack and doing that without
> > any documentation of the MAC hardware and maybe with no access to
> > fancy RF equipment for testing the output...
> >
> > ...*that* would be no fun!  Or maybe a lot of fun, depending on
> > how much you like challenges!
> 
> It is fun as long as you believe that the effort is appreciated and
> that documentation will not appear without your efforts.
> 
> It is even more fun if you can discover dark secrets, such as when
> somebody spotted Marvell using the GPL eCos OS for a different chip.
> That guy even had the balls to attack the firmware with objdump.
> Most people prefer an interactive disassembler like IDA or ChARMeD.
> 
> Dan Williams writes:
> 
> > Somebody needs to take ownership of the issue and run with it.
> > There's no bandwidth right now to do that at OLPC.
> 
> No problem. Please approve the hosting request. Also, I can only
> do so much without hardware. Ideally I'd have hardware to spare,
> because it is possible to scramble the boot2 firmware and may
> even be possible to do other hardware damage. I'll certainly need
> something to sniff mesh packets, and doing the mesh protocol will
> not work without enough devices for a mesh.
> 
> > And it's not just the runtime firmware.  Would RMS refuse to
> > recommend the XO because the boot2 firmware that's burned
> > into SPI flash on the wireless module
> 
> Maybe. In any case, open boot2 firmware would be a good idea.
> Somebody needs to find a way to unbrick a chip with messed-up
> boot2 firmware.

This is "simple".  You unsolder the SPI flash from the 8388 board and
solder in a freshly programmed SPI flash chip (or the bricked one just
fixed).  For this of course you need some soldering skills, and an SPI
flash programmer.  We've bricked SPI flash before and done this
procedure to figure out exactly _why_ the flash was bricked (the updater
didn't wait long enough for the 8388 to write the new boot2 to the SPI
flash) and then to resurrect the part.

Dan