RE: PPCBOOT activities

Wolfgang,

	My vote is for small & simple base,  then modularize the more
complex and powerful bells & whistle to be added in by the user on a desired
basis.  We like to get the smallest possible loader for our production
boards and then leave it alone.

I volunteer for any FADS testing we have an 823.

-----Original Message-----
From: Wolfgang Denk [mailto:wd <at> denx.de]
Sent: Monday, June 26, 2000 4:55 PM
To: ppcboot-internal <at> lists.sourceforge.net
Cc: ppcboot-users <at> lists.sourceforge.net; Kirk Haderlie; Neil Russell
Subject: PPCBOOT activities

Friends,

sorry for posting to both the "users" and the "internal"  lists,  but
it seems most of you are hanging out on "users" waiting for something
to happen...

OK - current status:

I started looking at the sources, checking old "fadsrom" and "8xxrom"
sources as well as contributions by several people (David Brown, Kirk
Haderlie), plus several other available sources (DINK32 by  Motorola,
LiMon by Neil Russell, some ecos code by Cygnus).

I tried a few things out, and right now I have a  quite  nice  (IMHO)
framework (just the very basic features) running on our TQ systems.

I have reached a point where I need your help.

Before I continue, I'd like to have a bit of  discussion.  There  are
several design decisions where I'm not sure what makes sense.

(1) Small & simple versus flexible & powerfull

    I can think of two different ways to implement "ppcboot":

    - Version "A" is configured at compile time for  a  specific  CPU
      model,  clock  rate,  type  and  size  of RAM, type and size of
      FLASH, etc.

    - Version "B" is more intelligent;  it  will  auto-detect  things
      like  CPU  type,  clock  speed,  RAM and FLASH types and sizes,
      automatically adjust DRAM timings, etc.

    Both ways have advantages and disadvantages: Obviously  "A"  will
    result  in  smaller code, which is probably easier to port to new
    hardware; "B" will be more complex,  but  will  not  need  to  be
    changed  for  instance when you change the speed or the memory on
    your board.

    What is your opinion?

(2) Both "fadsrom" and "8xxrom" are running from Flash  memory,  they
    use  a  fixed  address  map,  and  you  have  to be careful about
    initialization of data and BSS segments. One of  the  features  I
    need  to have is Flash support, i. e. commands to download images
    (over serial line or ethernet) and write the data to  flash.  But
    this means that the code CANNOT be running from FLASH (as sson as
    you  set any of the special flash chip modes like autoselect etc.
    you cannot read normal data anymore, thus you  cannot  fetch  any
    instructions ==> crash).

    Again, there are several options to solve this problem:

    A. Write a small "loader" (probably  position-independend,  maybe
       in  assembler)  that  does  just minimal initialization of the
       system and then relocates a binary image (which  includes  95%
       of  the  monitor  code)  to a well-known position in RAM [just
       like Linux is booted].

       Disadvantages: at least CPU, clocks, FLASH  and  RAM  must  be
       checked and initialized before we can do the relocation, and I
       would like to keep existing C code to do this.

    B. We could try to write the monitor in a way that remains  relo-
       catable,  so  that it can move itself to a new position in RAM
       and continue running from there.

       Disadvantages: from what I've seen,  this  is  not  a  trivial
       thing  to  do;  at  least  I  haven't dealt with Global Offset
       Tables and all these things before.

    C. We could isolate very small parts of code that need to be  run
       from   RAM,  implement  them  in  a  position-independend  way
       (probably in assembler), and copy just those parts to RAM  for
       execution.  [That's what I'm using at the moment for the FLASH
       identification code.]

       Disadvantages:  it  seems  necessary  to  do  some  things  in
       assembler  to  have  better control about the code, and it still does
       not solve some other problems, for instance when the start address of
       the monitor in FLASH is not known.

    What I would also like to be able to do is to download a  monitor
    image  to  RAM  (probably  using  a simple BDM tool without FLASH
    support) and run the monitor in RAM,  so  that  we  can  use  the
    monitor to bootstrap itself into flash.

    Do you have any suggestions?

(3) I will be able to run all kinds of thests on several  TQ  systems
    (823,  850,  860, soon 855, old and new, with and without bugs in
    the silicon). Also, I will have one or two custom boards soon  to
    run  ppcboot  on.  But  I don't have other hardware available for
    tests: no Embedded Planet boards, no Motorola (F)ADS.

    Is anybody interested doing this? You  know  that  this  probably
    means  one  or two steps back from what you already have now with
    8xxrom or LiMon, you it won't help you with *your* work  [but  it
    would definitely help ppcboot.]

    Volunteers?

Ok - that's all for now, I'm waiting for your feedback.

Wolfgang

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
If you think the problem is bad now, just wait until we've solved it.
                                                        Epstein's Law