Nicolas Pitre wrote:
> On Fri, 13 Apr 2001, weitin_lai wrote:
>
> > Thank for your help,I will report the result that I try it ASAP.
> > If there is any other method to sovle it, please tell me.
> > Thank you very much.
> >
> > Best Regards
> >
> > wei-ting Lai
> >
> > On Fri, Apr 13, 2001 at 12:27:46AM +0800, weitin_lai wrote:
> > > I have a IQ80310 board, redboot debug kits.
>
> I've never been able to make Linux boot with any version of Redboot so far.
> Redboot and/or the hardware seem to have bugs making that combination
> unreliable.
Well, I use it... but it's not for the timid... What I do is I use
the Redboot monitor to download via TFTP the 'package', then I use
the flash utility commands to burn that package into flash, then I remove the
Ethernet cable, reset the board, issue the go command, hope like hell that
'bash' comes up'...
I have thought that the reason why I could not just 'load and go', was
due to some unhandled interrupt left over from the ethernet download,
but the fiddling with the interrupt control register that I've done,
does not seem to eliminate the 'silent' death that occurs if I try to go
just after a TFTP load.
>
> Also note that boards prior to revision F contain design mistakes that
> prevent Linux from reliably make use of any PCI devices except for the
> on-board ethernet. Intel is supposed to make available new boards (rev F)
> in the near future with that problem solved.
My board has a silkscreen Rev D, but after that things are a bit uncertain...
One item that I've found, is that I had to set the '32 bit' PCI bus mode
switch.
The symptom was seeing data in memory which suggested the top 32
bits of the 64 bit word were not being written to memory.
Another is that my board appears to route the interrupt that comes from
the secondary PCI to the board's mega logic CPLD chip, which then can
be directed to the IRQ line rather than the FIQ line. There are a couple of
wires on the board, so perhaps not all boards have this mod.
I have also updated the CPLD logic with a later version as well, I believe
that PAL rev is 'F', but I'd have to look back and see that for sure.
I'm also using the HSI (now owned by WRS) JTAG probe. The
PAL update was required to properly handle the JTAG and other
control lines correctly.
Just as a note, this probe and attendant software at the moment,
if ever, does not support any 'mmu' modes other than none, or
1-1 physical to virtual. Hence for actual linux debug, it is useless.
However, for low level hardware test primitives, it's adquate, and
given some of the prices of the other probes (or was that just
one othe probe), this 'lack' may be acceptable.
I would have prefered to have had a choice in selection, and
would have probably not chosen a WRS product, but given
the price, and the non-existent alternatives at that price, I
had to take a more pragmatic approach.
Which does sort of bring up a point in passing, are there
any 'free Software' projects that are directed to interfacing with
JTAG control probes. HP made, or still makes, such a probe
which had an ETHERNET port, and so could be controled
by a machine on the network with 'appropriate' software...
_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
Please visit the above address for information on this list.
