Subject: Re: PowerROMmed cards

From: Theo Markettos <[email-masked]>
Date: Mon, 18 May 1998 17:52:10 +0100

> 
>  This is the suggestion which was put to me:
> 
>  Each driver which supports a card that can be fitted with a PowerROM should
>  check through the modules which are present on the card.  It should look
>  for modules of the form `*TX'.  This is the only difference between the
>  ROMs.  Apparently it would be prohibitively expensive to change the product
>  ID for each style of card.

I don't think so.  What would be expensive is to change the ID
_retrospectively_, on ROMs already out there or in stock.  I don't see why
any future batches of ROMs that are ordered can't have the ID changed -
getting a new ID is a simple as emailing the nice Mr Glover at Pineapple and
asking for one. 
 
>  Here are the thoughts which occur to me:
>  2. How easy is it to read the chunk directory from the podule?  I did it
>     in a program called PodHacker once; I'll have to dig it out and see how
>     to do it.  If I used RISC OS SWIs and it can't be (easily|at all) done
>     under Linux then see suggestion 4.

The only possible problem is you need to know where the page latch was in the
address space, or call the loader, which could be tricky.  To clarify what
follows, the loader is a bit of ARM code stored in the first page of a podule
ROM that allows access to the rest of the podule ROM using a page latch.  The
page latch must be reset to allow the loader to be read out of ROM correctly
without the help of RISC OS.

Read the following slowly...

On bootup, the hardware is reset, so the page latch contains zero, and
therefore RISC OS can see the first page of ROM, which contains the loader. 
If RISC OS has read data from ROM other than in the first page, the page
latch may be pointing to another part of ROM, and without know where the page
latch is, you can't reset it to find the loader.  In this case, you need to
call the loader from RISC OS to access the loader code in ROM - you can't
simply read the loader from RISC OS's copy of it, because there's no way of
getting a pointer to this copy.

Therefore, you'd have to use Podule_ReadBytes (IIRC) to read out the loader
(this uses the loader), make a copy of it, go into Linux, then call this
loader to read out the rest of the ROM. The loader might call a few SWIs (if
it is badly written - it doesn't have to), which could cause problems.

I don't know which mode Linux runs in, but there might possibly be problems
running the 26-bit loader code on ARMs in 32-bit mode.

If you know the page latch address, you can effectively duplicate the loader
in the Linux kernel.
This address should be easily hackable out of the ROM loader code.  It would
however be different for every type of podule, so you'd need a PowerROM for
each of these cards to find it out.

Thinking about this, it might still be possible to read the ROM without
calling the loader or knowing the page latch address.  IIRC a Ctrl-Break does
not assert the /RESET line on the podule bus, so if this is the case, the
page latch must always point to the first page of ROM, otherwise a Ctrl-Break
would fail to identify the podules correctly because it sees the wrong page
of ROM. This all depends on whether RISC OS scans the podules on Ctrl-Break,
or just on reset.

Once you can read the whole ROM image, examining the modules isn't too
difficult.  The ROM format is detailed in PRM vol 4, and it's merely a method
of decoding this - it's not too tricky a task.

Apologies if this was confusing - using a loader to load the loader is not
the easiest process to describe.  Mail me or to the list if you want more
info.

Cheers,
Theo

-- 
Theo Markettos          Home:   [email-masked]
Liphook                 Work:   [email-masked]
Hampshire
UK                      Web site, including Acorn backup software
                        http://www.marketto.demon.co.uk/
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 18 May 1998 19:56:28 +0100 (BST)

Theo Markettos writes:
> On bootup, the hardware is reset, so the page latch contains zero...

Also, RiscOS will reset the page latches (using the loaders reset entry point)
after you pass the modules a Service_PreReset (as !Linux does).

> running the 26-bit loader code on ARMs in 32-bit mode.

It runs in 32-bit modes, and I have to maintain a blacklist of the loader
code that doesn't work.  It seems that most code does work, but there are
exceptions (eg, the PowerROMs of course).  Their code crashes if you call
it with 32-bit addresses etc.

I think that it may be possible to detect the card by the location of the
FAS216 (or NCR53C9x) chip.  I personally think that the drivers should
not load/initialise if they can't detect the SCSI chip where they believe
it should be.  This would then get around these problems.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 22 May 1998 22:54:01 +0100 (BST)

Theo Markettos writes:
> That sounds _very_ dodgy.  Firstly, IIRC some cards used a 5380 (A3000-style
> 8 bit ones spring to mind).  Secondly, if I had to design a podule with a
> ROM, page latch and SCSI chip in 4K of address space, there are a few obvious
> ways to do it, which might be used on more than one card, which would make
> telling the difference difficult.  Also, hardware probing may well be
> dangerous - you may be accessing read sensitive hardware, which could do
> nasty things (like generate an interrupt or FIQ) that you're not expecting.

Hang on - what I said was 'should not load'.  In other words, you're trying to
put a driver in that might not be correct for the card.  If you don't check
that the SCSI chip is there, then you'll read/write it anyway later to initialise
it and perform the SCSI bus scan.

If there is a different chip there, then yes, there is the possibility of crashing
the computer anyway *because* it's the wrong driver.  However, what I said was
that if possible, the driver should *refuse* to initialise if it can't find
the hardware it expects.

That way, if your machine *doesn't* crash, then the driver also hasn't been
initialsed, and it has been unloaded.  You can then try another driver.

I wasn't talking about creating one driver for all PowerROMmed cards, since
there is little point for that.

I would however, prefer it if it didn't crash, and that each PowerROMmed card
had it's original idents etc etc, and in light of that, I believe as I have
always believed that drivers should not initialise themselves if they
believe that no hardware is present.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: [email-masked] (Theo Markettos)
Date: Fri, 22 May 1998 20:20:14 +0100

A better (IMHO) solution I would propose would be to find out where the page
latch for each card is (should be hackable out of the PowerROM or original
loader), and then drive the ROM paging directly.  If the loader doesn't do
funny things, like map even pages to the first half of ROM and odd pages to
the second, it should be a case of bits 0 - x-1 of the ROM space address,
where x=LOG2(ROM size), are part of the podule address, and bits x - x+7 are
the page register value.  If you hack the Risc OS loader, you can also find
out the purpose of any other latched bits (eg reset, interrupt control), and
how they should be set for normal operation.

---

From: Theo Markettos <[email-masked]>
Date: Sat, 23 May 1998 15:17:30 +0100

On Fri, 22 May 1998 22:54:01 +0100 (BST), [email-masked] said:

> Theo Markettos writes:
> > > I think that it may be possible to detect the card by the location of
> > > the  FAS216 (or NCR53C9x) chip.  I personally think that the drivers
> > > should not load/initialise if they can't detect the SCSI chip where
> > > they believe it should be.  This would then get around these problems.
> > 
> > That sounds _very_ dodgy.  Firstly, IIRC some cards used a 5380
> > (A3000-style  8 bit ones spring to mind).  Secondly, if I had to design a
> > podule with a ROM, page latch and SCSI chip in 4K of address space, there
> > are a few obvious ways to do it, which might be used on more than one
> > card, which would make telling the difference difficult.  Also, hardware
> > probing may well be dangerous - you may be accessing read sensitive
> > hardware, which could do nasty things (like generate an interrupt or FIQ)
> > that you're not expecting.
>
> Hang on - what I said was 'should not load'.  In other words, you're trying
> to  put a driver in that might not be correct for the card.  If you don't
> check that the SCSI chip is there, then you'll read/write it anyway later
> to initialise  it and perform the SCSI bus scan.

I see - so you mean that once you've worked out what card it is and
therefore what the memory map is, you then check to see whether the chip is
where you think it is, and if it's not then you don't initialise the driver. 
That makes sense - it's something that might be handy for all podules, SCSI
or not.  If there's, say, a bad connection with the podule bus, you might be
able to read the ROM without problems, then find that you couldn't access the
driver chip.  If this was in the middle of some critical data transfer the
driver might hang waiting for a ready signal that never came because the chip
wasn't being read and rubbish was returned instead.

Apologies if this already happens for most drivers - I'm speaking as a RISC
OS and hardware person with a users knowledge of Unix, not a Unix hacker.

Cheers,
Theo

---

From: Philip Blundell <[email-masked]>
Date: Sat, 23 May 1998 20:52:38 +0100

>where you think it is, and if it's not then you don't initialise the driver. 
[...]
>Apologies if this already happens for most drivers - I'm speaking as a RISC

Most drivers do at least make an attempt at not locking the machine if 
something goes wrong.  If the chip was missing then it would be fairly 
obvious the first time you tried to talk to it.

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sat, 23 May 1998 21:14:27 +0100 (BST)

Theo Markettos writes:
> ...  If there's, say, a bad connection with the podule bus, you might be

I already do this with some of the drivers - ether3 checks whether the chip is
on an 8bit or 16bit bus, and then checks the on-board RAM (as does the ether1).

> OS and hardware person with a users knowledge of Unix, not a Unix hacker.

;)  Well, until I started ARMLinux, I wasn't a unix hacker ;)
   _____