PPCBoot memory mapping problems

PPCBoot memory mapping problems

[clark]

        Okay here is the situation,

        I have hacked & slashed the PPCBoot code to work with our custom
board (all except the flash portion). I have mapped the memory as show below.

  address       size            name            BR#/OR#         buswidth
0x00000000      8meg            Bank0           1               32
0x00800000      8meg            Bank1           2               32
0x40000000      2meg            Flash0          0               16
0x60000000*     2meg            Flash1          3               16
0xFFF00000      whatever        IMMR            N/A             N/A

(* Note will be remapped to the end of flash0 to form contigious flash block
when I get around to hacking the flash code)

        I have taken the "include/asm/mbx.h" and replaced its boardinfo
structure with the one I used in the PPCBoot code and then compiled the
kernel. Following the instructions in the readme file, I grabbed
arch/ppc/coffboot/vmlinux.gz and converted as shown. It is given a load
address of 0x00000000 and an entry point 0x0000000C. I put the converted
image into flash using our ICE at address 0x40020000.

        Our board boots up checks the kernels CRC then uncompresses it. It
then jumps to 0x0000000C. A little bit later it then jumps to some address
0xC000???? and faults.

        Is this what it is supposed to do? Am I supossed to have the RAM
mapped at 0xC0000000? If it loads at address 0 how do I remap it to
0xC0000000 once the kernel starts? Is there any way to force the kernel to
run in lower memory?


        Thanks in advance for any help.

        Conn Clark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: PPCBoot memory mapping problems

[Frank Smith]

> -----Original Message-----
> From: owner-linuxppc-embedded@lists.linuxppc.org
> [mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of
> clark@esteem.com
> Sent: Friday, August 18, 2000 9:49 PM
> To: linuxppc-embedded@lists.linuxppc.org
> Subject: PPCBoot memory mapping problems
>
...
>
>         Our board boots up checks the kernels CRC then uncompresses it. It
> then jumps to 0x0000000C. A little bit later it then jumps to some address
> 0xC000???? and faults.
>
>         Is this what it is supposed to do? Am I supossed to have the RAM

Jump to 0xC000????  Yup.  Fault?  No.

> mapped at 0xC0000000? If it loads at address 0 how do I remap it to
> 0xC0000000 once the kernel starts? Is there any way to force the kernel to

Basically, the kernel boot process should be doing this *for* you.

Part of the kernel boot process is to set up a memory mapping from
virtual C0000000 to physical 00000000, and then enable address translation.
This is done in arch/ppc/kernel/head.S using the BAT registers.

> run in lower memory?

I doubt it.  It shouldn't be necessary, tho.

>
>
>         Thanks in advance for any help.
>
>         Conn Clark
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: PPCBoot memory mapping problems

[Wolfgang Denk]

In message <00Aug18.231049adt.7303@dragon.appliedmicro.ns.ca>
Frank Smith wrote:
>
> > mapped at 0xC0000000? If it loads at address 0 how do I remap it to
> > 0xC0000000 once the kernel starts? Is there any way to force the kernel to
>
> Basically, the kernel boot process should be doing this *for* you.
>
> Part of the kernel boot process is to set up a memory mapping from
> virtual C0000000 to physical 00000000, and then enable address translation.

Right, but just to make this absolutely clear: this  is  done  within
the Linux kernel, you don't have to do anything for that in PPCBoot.

> > run in lower memory?
>
> I doubt it.  It shouldn't be necessary, tho.

There is no need to do anything like that in PPCBoot.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Comparing information  and  knowledge  is  like  asking  whether  the
fatness  of  a  pig  is more or less green than the designated hitter
rule."                                               - David Guaspari

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: PPCBoot memory mapping problems

[Wolfgang Denk]

Hi,

in message <1.5.4.32.20000819004501.006984e4@pop.esteem.com> you wrote:
>
>         I have hacked & slashed the PPCBoot code to work with our custom
> board (all except the flash portion). I have mapped the memory as show below.

Looks OK.

> kernel. Following the instructions in the readme file, I grabbed
> arch/ppc/coffboot/vmlinux.gz and converted as shown. It is given a load
> address of 0x00000000 and an entry point 0x0000000C. I put the converted

Be careful here! This depends on the kernel version! Entry point  0xC
is/was  used in "older" kernel versions like 2.2.13. This has changed
in 2.3.x kernels, which started executing code form 0, so if you  are
running a 2.3 / 2.4 kernel make sure to set the entry point to 0x0.

>         Our board boots up checks the kernels CRC then uncompresses it. It
> then jumps to 0x0000000C. A little bit later it then jumps to some address

This is OK - as soon as the kernel switches on the MMU  it  will  use
virtual addresses.

> 0xC000???? and faults.

This may be casued by a bad entry point (see above), or you might  be
fooled  if  you're  running  with  an ICE that does not work with MMU
(make sure to set the DER to a sensible value, or use a better ICE).

>         Is this what it is supposed to do? Am I supossed to have the RAM

The use of 0xC00xxxxx addresses is supposed to happen, the faults are
not supposed to happen - if they really are. I guess it's  just  your
ICE...

> mapped at 0xC0000000? If it loads at address 0 how do I remap it to
> 0xC0000000 once the kernel starts? Is there any way to force the kernel to
> run in lower memory?

You don't remap the  RAM;  the  kernel  will  take  care  of  address
translation of virtual to physical addresses.


Note 1: I'm not sure if too  many  people  on  the  linuxppc-embedded
        mailing   list   are   interested   in  PPCBoot  issues;  the
        ppcboot-users mailing list is  probably  a  more  appropriate
        place for such discussion.

Note 2: Although not yet officially announced, ppcboot-0.4.3  is  out
        (both   on   the   CVS   server   and   on   our  FTP  server
        (ftp://ftp.demx.de/pub/ppcboot/ppcboot-0.4.3.tar.gz); on  the
        CVS  server  there are even some more recent modifications in
        preparation of suport for some IBM 4xx based board.

Hope this helps,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
I have a theory that it's impossible to prove anything, but  I  can't
prove it.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: PPCBoot memory mapping problems

[Jerry Van Baren]

At 05:45 PM 8/18/00 -0700, clark@esteem.com wrote:

>         Okay here is the situation,
>
>         I have hacked & slashed the PPCBoot code to work with our custom
>board (all except the flash portion). I have mapped the memory as show
>below.
>
>   address       size            name            BR#/OR#         buswidth
>0x00000000      8meg            Bank0           1               32
>0x00800000      8meg            Bank1           2               32
>0x40000000      2meg            Flash0          0               16
>0x60000000*     2meg            Flash1          3               16
>0xFFF00000      whatever        IMMR            N/A             N/A
>
>(* Note will be remapped to the end of flash0 to form contigious flash
>block
>when I get around to hacking the flash code)

One thing that leaps out at me which could be a problem, depending on
conditions and code, is the IMMR address.  We found it much easier to
just set the IMMR to 0xF0000000 rather than fight the code to put it
elsewhere.  Theoretically, it can be anywhere above the virtual address
of RAM (0xC0000000).  You also have to be _very_ careful in your IMMR
remap code that it only is executed _once_.  If you execute it a second
time or try to remap it but don't have the correct current IMMR address
(you need the current IMMR address in order to set it to the new
address), you will (probably) cause a bus fault and Bad Things Will Happen.

It shouldn't be a problem, but I would strongly urge you to _not_ set
the IMMR to 0xFFF00000 because that is the magic boot address.  It will
be very confusing for everybody who follows in your footsteps as to why
you appear to be overwriting your boot code when you do IMMR I/O.  I
would recommend you use one of the power up selectable IMMR addresses
(0xF0000000 is the only one that is above 0xC0000000) and it is easier
if you set your boot configuration to set the IMMR to 0xF0000000 on
bootup to make it match the linux expectations.

Another possibility is your flash addresses.  The kernel makes
assumptions that the addresses of I/O is higher than the end of virtual
RAM: if your kernel is using the flash[01], it may be getting confused.

This is what Jon Diekema and I came up with for Linux memory mapping
rules, applied to mapping the resource on the EST SBC8260 board.

         * EST SBC8260 Linux memory mapping rules:

         Initial conditions:
         -------------------

         Tasks that need to be perform by the boot ROM before control is
         transferred to zImage (compressed Linux kernel):

         - Define the IMMR to 0xf0000000

         - Initialize the memory controller so that RAM is available at
           physical address 0x00000000.  On the SBC8260 is this 16M (64M)
           SDRAM.

         - Build the board information structure (see
           include/asm-ppc/est8260.h for its definition)

         - The compressed Linux kernel (zImage) contains a bootstrap
loader
           that is position independent; you can load it into any RAM,
           ROM or FLASH memory address >= 0x00200000 (above 2 MB).

           Note: If zImage is loaded at its link address of 0x00400000
(4 MB),
                 then zImage will skip the step of moving itself to
                 its link address.

         - Load R3 with the address of the board information structure

         - Transfer control to zImage

         - The Linux console port is SMC1, and the baud rate is controlled
           from the bi_baudrate field of the board information structure.
           On thing to keep in mind when picking the baud rate, is that
           there is no flow control on the SMC ports.  I would stick
           with something safe and standard like 19200.

           On the EST SBC8260, the SMC1 port is on the COM1 connector of
           the board.


         EST SBC8260 defaults:
         ---------------------

         0x00000000-0x00FFFFFF   16M (64M) SDRAM
         0xFE000000-0xFFFFFFFF    4M flash (SIMM)
         0xFC000000-0xFCFFFFFF    2M flash (8 bits wide, soldered to
the board)
         0x22000000-0x2200FFFF    8K EEPROM
         0x04000000-0x04FFFFFF    4M local bus SDRAM (soldered to the
board)
         0x21000000-0x21000000   Flash present detect (from the flash SIMM)
         0x21000001-0x21000001   Switches (read) and LEDs (write)

         - BATs can map 128K-256Mbytes each.  There are four data BATs and
           four instruction BATs.  Generally the data and instruction BATs
           are mapped the same.

         - The chip selects can map 32K blocks and up (powers of 2)

         - The SDRAM machine can handled up to 128Mbytes per chip select

         - The IMMR must be set above the kernel virtual memory addresses,
           which start at 0xC0000000.  Otherwise, the kernel may crash as
           soon as you start any threads or processes.

         - Linux uses the 60x bus memory (the SDRAM DIMM) for the
           communications buffers.

         - RAM is at physical address 0x00000000, and gets mapped to
0xC0000000
           for the kernel.


         Physical addresses used by the Linux kernel:
         --------------------------------------------

         0x00000000-0x3FFFFFFF   1GB reserved for RAM
         0xF0000000-0xF001FFFF   128K IMMR  64K used for dual port memory,
                                  64K for 8260 registers


         Logical addresses used by the Linux kernel:
         -------------------------------------------

         0xF0000000-0xFFFFFFFF   256M BAT0 (IMMR: dual port RAM, registers)
         0xE0000000-0xEFFFFFFF   256M BAT1 (I/O space for custom boards)
         0xC0000000-0xCFFFFFFF   256M BAT2 (RAM)
         0xD0000000-0xDFFFFFFF   256M BAT3 (if RAM > 256MByte)


         EST SBC8260 Linux mapping:
         --------------------------

         DBAT0, IBAT0, cache inhibited:

                                 Chip
         Memory                  Sel Use
         ---------------------   --- ---------------------------------
         0xFE000000-0xFFFFFFFF   CS0 4M/16M flash (SIMM)
         0xFD000000-0xFDFFFFFF   CS1 0M/16M Reserved for expanded SIMM
flash
         0xFC000000-0xFCFFFFFF   CS6 2M/16M flash (onboard)
         0xFA000000-0xFABFFFFF   CS4 4M/16M local bus SDRAM
         0xF8010000-0xF801FFFF   CS5 8K/64K EEPROM
         0xF8000000-0xF800FFFF   CS7 2B/64K LED, switches, flash
present detect
         0xF0000000-0xF001FFFF   n/a IMMR: dual port RAM, registers

         DBAT1, IBAT1, cache inhibited:


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: PPCBoot memory mapping problems

[diekema_jon]

Here is the complete document from the Linux tree,
Documentation/powerpc/SBC8260_memory_mapping.txt:

Please mail me (Jon Diekema, diekema_jon@si.com or diekema@cideas.com)
if you have questions, comments or corrections.

	* EST SBC8260 Linux memory mapping rules

	http://www.estc.com/
	http://www.estc.com/products/boards/SBC8260-8240_ds.html

	Initial conditions:
	-------------------

	Tasks that need to be perform by the boot ROM before control is
	transferred to zImage (compressed Linux kernel):

	- Define the IMMR to 0xf0000000

	- Initialize the memory controller so that RAM is available at
	  physical address 0x00000000.  On the SBC8260 is this 16M (64M)
	  SDRAM.

	- The boot ROM should only clear the RAM that it is using.

	  The reason for doing this is to enhances the chances of a
	  successful post mortem on a Linux panic.  One of the first
	  items to examine is the 16k (LOG_BUF_LEN) circular console
	  buffer called log_buf which is defined in kernel/printk.c.

	- To enhance boot ROM performance, the I-cache can be enabled.

	  Date: Mon, 22 May 2000 14:21:10 -0700
	  From: Neil Russell <caret@c-side.com>

	  LiMon (LInux MONitor) runs with and starts Linux with MMU
	  off, I-cache enabled, D-cache disabled.  The I-cache doesn't
	  need hints from the MMU to work correctly as the D-cache
	  does.  No D-cache means no special code to handle devices in
	  the presence of cache (no snooping, etc). The use of the
	  I-cache means that the monitor can run acceptably fast
	  directly from ROM, rather than having to copy it to RAM.

	- Build the board information structure (see
	  include/asm-ppc/est8260.h for its definition)

	- The compressed Linux kernel (zImage) contains a bootstrap loader
	  that is position independent; you can load it into any RAM,
	  ROM or FLASH memory address >= 0x00500000 (above 5 MB), or
	  at its link address of 0x00400000 (4 MB).

	  Note: If zImage is loaded at its link address of 0x00400000 (4 MB),
	        then zImage will skip the step of moving itself to
		its link address.

	- Load R3 with the address of the board information structure

	- Transfer control to zImage

	- The Linux console port is SMC1, and the baud rate is controlled
	  from the bi_baudrate field of the board information structure.
	  On thing to keep in mind when picking the baud rate, is that
	  there is no flow control on the SMC ports.  I would stick
	  with something safe and standard like 19200.

	  On the EST SBC8260, the SMC1 port is on the COM1 connector of
	  the board.


	EST SBC8260 defaults:
	---------------------

                                Chip
        Memory                  Sel  Bus   Use
        ---------------------   ---  ---   ----------------------------------
	0x00000000-0x03FFFFFF   CS2  60x   (16M or 64M)/64M SDRAM
	0x04000000-0x04FFFFFF   CS4  local  4M/16M SDRAM (soldered to the board)
	0x21000000-0x21000000   CS7  60x    1B/64K Flash present detect (from the flash SIMM)
	0x21000001-0x21000001   CS7  60x    1B/64K Switches (read) and LEDs (write)
	0x22000000-0x2200FFFF   CS5  60x    8K/64K EEPROM
	0xFC000000-0xFCFFFFFF   CS6  60x    2M/16M flash (8 bits wide, soldered to the board)
	0xFE000000-0xFFFFFFFF   CS0  60x    4M/16M flash (SIMM)

	Notes:
	------

	- The chip selects can map 32K blocks and up (powers of 2)

	- The SDRAM machine can handled up to 128Mbytes per chip select

	- Linux uses the 60x bus memory (the SDRAM DIMM) for the
	  communications buffers.

	- BATs can map 128K-256Mbytes each.  There are four data BATs and
	  four instruction BATs.  Generally the data and instruction BATs
	  are mapped the same.

	- The IMMR must be set above the kernel virtual memory addresses,
	  which start at 0xC0000000.  Otherwise, the kernel may crash as
	  soon as you start any threads or processes due to VM collisions
	  in the kernel or user process space.


	  Details from Dan Malek <dan_malek@mvista.com> on 10/29/1999:

	  The user application virtual space consumes the first 2 Gbytes
	  (0x00000000 to 0x7FFFFFFF).  The kernel virtual text starts at
	  0xC0000000, with data following.  There is a "protection hole"
	  between the end of kernel data and the start of the kernel
	  dynamically allocated space, but this space is still within
	  0xCxxxxxxx.

	  Obviously the kernel can't map any physical addresses 1:1 in
	  these ranges.


	  Details from Dan Malek <dan_malek@mvista.com> on 5/19/2000:

	  During the early kernel initialization, the kernel virtual
	  memory allocator is not operational.  Prior to this KVM
	  initialization, we choose to map virtual to physical addresses
	  1:1.  That is, the kernel virtual address exactly matches the
	  physical address on the bus.  These mappings are typically done
	  in arch/ppc/kernel/head.S, or arch/ppc/mm/init.c.  Only
	  absolutely necessary mappings should be done at this time, for
	  example board control registers or a serial uart.  Normal device
	  driver initialization should map resources later when necessary.

	  Although platform dependent, and certainly the case for embedded
	  8xx, traditionally memory is mapped at physical address zero,
	  and I/O devices above physical address 0x80000000.  The lowest
	  and highest (above 0xf0000000) I/O addresses are traditionally
	  used for devices or registers we need to map during kernel
	  initialization and prior to KVM operation.  For this reason,
	  and since it followed prior PowerPC platform examples, I chose
	  to map the embedded 8xx kernel to the 0xc0000000 virtual address.
	  This way, we can enable the MMU to map the kernel for proper
	  operation, and still map a few windows before the KVM is operational.

	  On some systems, you could possibly run the kernel at the
	  0x80000000 or any other virtual address.  It just depends upon
	  mapping that must be done prior to KVM operational.  You can never
	  map devices or kernel spaces that overlap with the user virtual
	  space.  This is why default IMMR mapping used by most BDM tools
	  won't work.  They put the IMMR at something like 0x10000000 or
	  0x02000000 for example.  You simply can't map these addresses early
	  in the kernel, and continue proper system operation.

	  The embedded 8xx/82xx kernel is mature enough that all you should
	  need to do is map the IMMR someplace at or above 0xf0000000 and it
	  should boot far enough to get serial console messages and KGDB
	  connected on any platform.  There are lots of other subtle memory
	  management design features that you simply don't need to worry
	  about.  If you are changing functions related to MMU initialization,
	  you are likely breaking things that are known to work and are
	  heading down a path of disaster and frustration.  Your changes
	  should be to make the flexibility of the processor fit Linux,
	  not force arbitrary and non-workable memory mappings into Linux.

	- You don't want to change KERNELLOAD or KERNELBASE, otherwise the
	  virtual memory and MMU code will get confused.

	  arch/ppc/Makefile:KERNELLOAD = 0xc0000000

	  include/asm-ppc/page.h:#define PAGE_OFFSET    0xc0000000
	  include/asm-ppc/page.h:#define KERNELBASE     PAGE_OFFSET

	- RAM is at physical address 0x00000000, and gets mapped to
	  virtual address 0xC0000000 for the kernel.


	Physical addresses used by the Linux kernel:
	--------------------------------------------

	0x00000000-0x3FFFFFFF   1GB reserved for RAM
	0xF0000000-0xF001FFFF   128K IMMR  64K used for dual port memory,
                                 64K for 8260 registers


        Logical addresses used by the Linux kernel:
	-------------------------------------------

	0xF0000000-0xFFFFFFFF   256M BAT0 (IMMR: dual port RAM, registers)
	0xE0000000-0xEFFFFFFF   256M BAT1 (I/O space for custom boards)
	0xC0000000-0xCFFFFFFF   256M BAT2 (RAM)
	0xD0000000-0xDFFFFFFF   256M BAT3 (if RAM > 256MByte)


	EST SBC8260 Linux mapping:
	--------------------------

	DBAT0, IBAT0, cache inhibited:

                                Chip
        Memory                  Sel  Use
        ---------------------   ---  ---------------------------------
        0xF0000000-0xF001FFFF   n/a  IMMR: dual port RAM, registers

        DBAT1, IBAT1, cache inhibited:

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: PPCBoot memory mapping problems

[Wolfgang Denk]

Maybe we should keep PPCBoot related discussion  out  of  this  list?
IMHO  it  belongs  to the ppcboot-users@lists.sourceforge.net mailing
list.

In message <4.3.2.20000821065652.00b573b0@falcon.si.com> you wrote:
>
> One thing that leaps out at me which could be a problem, depending on
> conditions and code, is the IMMR address.  We found it much easier to
> just set the IMMR to 0xF0000000 rather than fight the code to put it
> elsewhere.  Theoretically, it can be anywhere above the virtual address

Then change it. It's just a #define in the PPCBoot config file!

If you port PPCBoot for a EST8260 system, it makes sense to adapt the
settings from the Linux include/asm-ppc/est8260.h  file.  I  will  be
happy  to  include your config_EST8260.h file into the PPCBoot source
tree. Just send it to me...

> of RAM (0xC0000000).  You also have to be _very_ careful in your IMMR
> remap code that it only is executed _once_.  If you execute it a second
> time or try to remap it but don't have the correct current IMMR address
> (you need the current IMMR address in order to set it to the new
> address), you will (probably) cause a bus fault and Bad Things Will Happen.

I can't see any relation of this statement to current PPCBoot code.

> It shouldn't be a problem, but I would strongly urge you to _not_ set
> the IMMR to 0xFFF00000 because that is the magic boot address.  It will

Depends on your setup. My MPC8xx systems all start execution at 0x100 :-)

> be very confusing for everybody who follows in your footsteps as to why
> you appear to be overwriting your boot code when you do IMMR I/O.  I
> would recommend you use one of the power up selectable IMMR addresses
> (0xF0000000 is the only one that is above 0xC0000000) and it is easier
> if you set your boot configuration to set the IMMR to 0xF0000000 on
> bootup to make it match the linux expectations.

You can do so if you like - it's just a single #define in the PPCBoot
configuration file. What are you complaining about?

> Another possibility is your flash addresses.  The kernel makes
> assumptions that the addresses of I/O is higher than the end of virtual
> RAM: if your kernel is using the flash[01], it may be getting confused.

I've been using Linux with these mapping for a  _long_  time,  and  I
never  had  any  problems.  Our  flash  driver  works fine with these
addresses. Can you please explain where you see problems?

If there are really any problems it's trivial to change.

>          Initial conditions:
>          -------------------
>
>          Tasks that need to be perform by the boot ROM before control is
>          transferred to zImage (compressed Linux kernel):

Please note that PPCBoot does not need all the bootstrap code you get
with a zImage - all the initialization and uncompressing is  doen  by
PPCBoot,  so you just need the compressed kernel image: all the stuff
in arch/ppc/mbxboot is obsolete when you're using PPCBoot.


>          - Define the IMMR to 0xf0000000

OK, so use this value when you write the config_EST8260.h file.

>          - Initialize the memory controller so that RAM is available at
>            physical address 0x00000000.  On the SBC8260 is this 16M (64M)
>            SDRAM.

OK.

>          - Build the board information structure (see
>            include/asm-ppc/est8260.h for its definition)

OK.

>          - The compressed Linux kernel (zImage) contains a bootstrap
> loader
>            that is position independent; you can load it into any RAM,
>            ROM or FLASH memory address >= 0x00200000 (above 2 MB).

This is NOT NEEDED with PPCBoot. Don't waste flash memory for
duplicate code!

>          - Load R3 with the address of the board information structure

This is NOT enough. The Linux kernel parameters are:

	r3: ptr to board info data
	r4: initrd_start or 0 if no initrd
	r5: initrd_end - unused if r4 is 0
	r6: Start of command line string
	r7: End   of command line string

>          - The Linux console port is SMC1, and the baud rate is controlled
>            from the bi_baudrate field of the board information structure.

This is configurable with PPCBoot, and with all Linux kernels we are
using. We like to have the console on SMC2 on some boards...

>            On thing to keep in mind when picking the baud rate, is that
>            there is no flow control on the SMC ports.  I would stick
>            with something safe and standard like 19200.

Speeds up to 115200 work fine for me.


Again: may we please move this discussion to the ppcboot-users list?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"A complex system that works is invariably found to have evolved from
a simple system that worked."             - John Gall, _Systemantics_

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/