Re: Re: [Etherboot-developers] 3C905CX-TXM flashing with cromutil hangs

On Friday 04 July 2003 19:34, Donald Becker wrote:
> On Fri, 4 Jul 2003, Hans-Peter Jansen wrote:
> > pretty late follow up, sorry. On the bright side, my netbooted
> > ramdisk rescue environment has pretty nice evolved 'til the last
> > time...
>
> Using PXE to load an interactive rescue environment?  Presumably not
> NFS root, which can complicate things...

Well, dhcp in comb. with etherboot menus are used as a network wide 
bootmanager, running anything from dos to SuSE prof. install and 
slightly tuned rescue (with root pw), running completely from ramdisk. 

<OT>
Can flash etherboot code on Intel Pro/1000 nics in such a dos box.

Got a relabeled graphical boot progress (from 8.2) working in the 
diskless setup ;-)
</OT>

> > ON FRIDAY 18 April 2003 18:18, Donald Becker wrote:
> > > On Fri, 18 Apr 2003, Hans-Peter Jansen wrote:
>
>...
>
> > Saved EEPROM settings of a 3Com Vortex/Boomerang:
> >  3Com Node Address 00:0A:0D:D4:77:D7 (used as a unique ID only).
> >  OEM Station address 00:0A:0D:D4:77:D7 (used as the ethernet
> > address). Device ID 9200,  Manufacturer ID 6d50.
> >   Manufacture date (MM/DD/YYYY) 11/12/2001, division H, product SZ.
> >   No BIOS ROM is present.                   <- vortex-diag doesn't
> >                                                recognize the flash
> > ->
>
> Not exactly -- the serial EEPROM is programmed so that the board
> reports that no BIOS ROM exists.

Yet another undocumented? design change from 3com...

> > Hmmm, no response to the ID command, trying again with '80/60'..
> > That did not work either, trying with '90/01'...
> >
> > <!-- 90/01 is expected to work with this device, but it doesn't
> > --!>
> >
> > ACKKK, this may not be a programmable Flash part!
> >  BIOS ROM ID 55 AA, looking up vendor...
> > Unknown BIOS ROM ID 55 AA.
> > 0x000: 55 aa 08 e9 bf 07 55 4c 44 52 00 00 05 03 00 00
> > U.....ULDR...... 0x010: 00 00 e0 06 50 05 70 00 58 00 38 00 6d 00
> > 30 04 ....P.p.X.8.m.0.
>
> The good news is that the Flash ROM can be read.
> Usually that means that it may be written as well.
> But if the read-ID command doesn't work, the write commands won't
> work.

This leaves the question, what prevent us from reading that fscking id?

> > According to
> > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_
> >docs/21527d.pdf p. 16, the command sequence seems to differ from
> > other such devices, therefor I experimented with a specialized
> > do_cmd():
> >
> > static void do_am_cmd(long addr_ioaddr, long data_ioaddr, int cmd)
> > {
> > 	flash_out(addr_ioaddr, data_ioaddr, 0x555, 0xAA);
> > 	flash_out(addr_ioaddr, data_ioaddr, 0x2AA, 0x55);
> > 	flash_out(addr_ioaddr, data_ioaddr, 0x555, cmd);
> > 	/* Alternate command is simply
> > 	   flash_out(addr_ioaddr, data_ioaddr, 0, cmd); */
> > }
> >
> > in both, the first do_cmd() and the one in the 90/01 method in
> > get_part_id() without success. Does 3com fiddle with any hardware
> > protection here? But I doubt, that this would protect the id
> > reading. Am I on a lost track? What can I try next?
>
> I don't know -- I don't believe that there is a new write-protection
> method.  I'll have to track down a board with this Flash part.
>
> > BTW, attached is a gcc3.3 compile fix for vortex-diag.c.
>
> Grrrrr, this is perfectly valid C code, of the type that has worked
> for a quarter century.  And someone had to break it in a
> pseudo-pedantic crusade.

I tend to not even try to comment on this, in still hope, that somebody 
will come and clean up __that__ mess.

Cheers,
Pete
_______________________________________________
vortex mailing list
[email protected]
http://www.scyld.com/mailman/listinfo/vortex