Subversion Repositories or1k

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 

          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  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  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: