[U-Boot-Users] PCI Bridge on 8272ADS

[U-Boot-Users] PCI Bridge on 8272ADS

[Vitaly Bordug]

Hi Wolfgang,
I have a small question - do you have any comments/objection on adding 
support for PCI bridge of 8272ADS to the CVS?
It turned out now, that this can solve amount of problems concerning too 
slow board startup 
(http://ozlabs.org/pipermail/linuxppc-embedded/2005-March/017447.html) .
In short, some PCI cards need the udelay up to (1000000) after 
deassertion of RST#, which is... slow, at least.
While doing all necessary init in the firmware, enough time will almost 
surely be spent after clearing RST,  so  that resetting and delay can be 
eliminated from the kernel code.


-- 
Sincerely, 
Vitaly

[U-Boot-Users] Re: PCI Bridge on 8272ADS

[Wolfgang Denk]

Dear Vitaly,

in message <42518178.60801@ru.mvista.com> you wrote:
>
> I have a small question - do you have any comments/objection on adding 
> support for PCI bridge of 8272ADS to the CVS?

I hesitate. I feel it is the wrong thing to do, but I can  understand
your concerns.

> It turned out now, that this can solve amount of problems concerning too 
> slow board startup 
> (http://ozlabs.org/pipermail/linuxppc-embedded/2005-March/017447.html) .
> In short, some PCI cards need the udelay up to (1000000) after 
> deassertion of RST#, which is... slow, at least.

I understand that thisi s unacceptably slow for some situations,  but
then it's required by the standard, and you will have to live with it
one  way  or  abother  - the other option is not to use PCI connected
devices, i. e. fix the hardware design.

> While doing all necessary init in the firmware, enough time will almost 
> surely be spent after clearing RST,  so  that resetting and delay can be 
> eliminated from the kernel code.

I see the following problems:

* If you want to do it right you must  MAKE  SURE  to  wait  for  the
  required  time, i. e. even if you clear RST in the boot loader, you
  will still have to make sure to wait in Linux  until  2**25  clocks
  later;  this  requires  passing  some  time information between the
  bootloader and the kernel which is not in the  current  design.  Of
  course this is not difficult to add if there is a general agreement
  to  do  this  -  but  remeber that this affects everybody, not only
  PowerPC and not only U-Boot.

* I think it is not a good idea to export kernel problems to the boot
  loader. IMHO the kernel (and  all  subsytems  and  drivers  in  the
  kernel)  should  be  as independent from a boot loader as possible.
  They should not make any assumptions about the  previous  state  of
  the hardware, but always initialize it as they need it. Assumptions
  about  certain  pre-set  staes  only cause a lot of pain later, for
  example when the operation of drivers depends on  the  sequence  in
  which  modules  get  loaded,  or  drivers don't work when loaded as
  module at all, or ...

* Adding new requirements for bootloaders is a bad idea  in  general:
  instead  of  solving the problem once (where it originates - in the
  kernel) they would enforce changes to many boot loaders,  and  make
  the  kernel  break  on  old  versions  of the boot loaders, or even
  useless on boards where it is not possible to get  newer,  modified
  versions of the boot loader.

* I think it is also a bad idea to rely on the fact  that  U-Boot  is
  used  as  boot  loader.  Linux should never rely on a specific boot
  loader being used.

I can see that the suggested change solves  your  immediate  problem,
but  I don't think it's a good solution in general. [No, I don't know
of a "good" general solution - except avoiding PCI where  this  delay
is unacceptable.]

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never ascribe to malice that which can  adequately  be  explained  by
stupidity.