New subject: [PROPOSAL] extended payload handling

8 Jun 2004


      Eric,
What's your idea abut that? They are use cache as ram. ....
Regards
YH
-----邮件原件-----
发件人: Bari Ari [mailto:bari@onelabs.com] 
发送时间: 2004年6月8日 14:06
收件人: YhLu
抄送: LinuxBIOS
主题: Re: 答复: [PROPOSAL] extended payload handling
YhLu wrote:
...
Can you explain deailed about the difference between uboot and Linuxbios?
Here's the entire README from U-Boot:
http://cvs.sourceforge.net/viewcvs.py/u-boot/u-boot/README?rev=HEAD
Here's the section of the README from U-Boot that covers init. The
differences to LinuxBIOS should be apparent like no ROMCC in U-Boot:
The following is not intended to be a complete description of every
implementation detail. However, it should help to understand the
inner workings of U-Boot and make it easier to port it to custom
hardware.
Initial Stack, Global Data:
---------------------------
The implementation of U-Boot is complicated by the fact that U-Boot
starts running out of ROM (flash memory), usually without access to
system RAM (because the memory controller is not initialized yet).
This means that we don't have writable Data or BSS segments, and BSS
is not initialized as zero. To be able to get a C environment working
at all, we have to allocate at least a minimal stack. Implementation
options for this are defined and restricted by the CPU used: Some CPU
models provide on-chip memory (like the IMMR area on MPC8xx and
MPC826x processors), on others (parts of) the data cache can be
locked as (mis-) used as memory, etc.
Chris Hallinan posted a good summary of	 these	issues	to  the
    u-boot-users mailing list:
Subject: RE: [U-Boot-Users] RE: More On Memory Bank x (nothingness)?
    From: "Chris Hallinan" clh@net1plus.com
    Date: Mon, 10 Feb 2003 16:43:46 -0500 (22:43 MET)
    ...
Correct me if I'm wrong, folks, but the way I understand it
    is this: Using DCACHE as initial RAM for Stack, etc, does not
    require any physical RAM backing up the cache. The cleverness
    is that the cache is being used as a temporary supply of
    necessary storage before the SDRAM controller is setup. It's
    beyond the scope of this list to expain the details, but you
    can see how this works by studying the cache architecture and
    operation in the architecture and processor-specific manuals.
OCM is On Chip Memory, which I believe the 405GP has 4K. It
    is another option for the system designer to use as an
    initial stack/ram area prior to SDRAM being available. Either
    option should work for you. Using CS 4 should be fine if your
    board designers haven't used it for something that would
    cause you grief during the initial boot! It is frequently not
    used.
CFG_INIT_RAM_ADDR should be somewhere that won't interfere
    with your processor/board/system design. The default value
    you will find in any recent u-boot distribution in
    Walnut405.h should work for you. I'd set it to a value larger
    than your SDRAM module. If you have a 64MB SDRAM module, set
    it above 400_0000. Just make sure your board has no resources
    that are supposed to respond to that address! That code in
    start.S has been around a while and should work as is when
    you get the config right.
-Chris Hallinan
    DS4.COM, Inc.
It is essential to remember this, since it has some impact on the C
code for the initialization procedures:
* Initialized global data (data segment) is read-only. Do not attempt
  to write it.
* Do not use any unitialized global data (or implicitely initialized
  as zero data - BSS segment) at all - this is undefined, initiali-
  zation is performed later (when relocating to RAM).
* Stack space is very limited. Avoid big data buffers or things like
  that.
Having only the stack as writable memory limits means we cannot use
normal global data to share information beween the code. But it
turned out that the implementation of U-Boot can be greatly
simplified by making a global data structure (gd_t) available to all
functions. We could pass a pointer to this data as argument to _all_
functions, but this would bloat the code. Instead we use a feature of
the GCC compiler (Global Register Variables) to share the data: we
place a pointer (gd) to the global data into a register which we
reserve for this purpose.
When choosing a register for such a purpose we are restricted by the
relevant  (E)ABI  specifications for the current architecture, and by
GCC's implementation.
For PowerPC, the following registers have specific use:
    R1:	stack pointer
    R2:	TOC pointer
    R3-R4:	parameter passing and return values
    R5-R10: parameter passing
    R13:	small data area pointer
    R30:	GOT pointer
    R31:	frame pointer
(U-Boot also uses R14 as internal GOT pointer.)
==> U-Boot will use R29 to hold a pointer to the global data
Note: on PPC, we could use a static initializer (since the
    address of the global data structure is known at compile time),
    but it turned out that reserving a register results in somewhat
    smaller code - although the code savings are not that big (on
    average for all boards 752 bytes for the whole U-Boot image,
    624 text + 127 data).
On ARM, the following registers are used:
R0:	function argument word/integer result
    R1-R3:	function argument word
    R9:	GOT pointer
    R10:	stack limit (used only if stack checking if enabled)
    R11:	argument (frame) pointer
    R12:	temporary workspace
    R13:	stack pointer
    R14:	link register
    R15:	program counter
==> U-Boot will use R8 to hold a pointer to the global data
Memory Management:
------------------
U-Boot runs in system state and uses physical addresses, i.e. the
MMU is not used either for address mapping nor for memory protection.
The available memory is mapped to fixed addresses using the memory
controller. In this process, a contiguous block is formed for each
memory type (Flash, SDRAM, SRAM), even when it consists of several
physical memory banks.
U-Boot is installed in the first 128 kB of the first Flash bank (on
TQM8xxL modules this is the range 0x40000000 ... 0x4001FFFF). After
booting and sizing and initializing DRAM, the code relocates itself
to the upper end of DRAM. Immediately below the U-Boot code some
memory is reserved for use by malloc() [see CFG_MALLOC_LEN
configuration setting]. Below that, a structure with global Board
Info data is placed, followed by the stack (growing downward).
Additionally, some exception handler code is copied to the low 8 kB
of DRAM (0x00000000 ... 0x00001FFF).
So a typical memory configuration with 16 MB of DRAM could look like
this:
0x0000 0000	Exception Vector code
          :
    0x0000 1FFF
    0x0000 2000	Free for Application Use
          :
          :
:
          :
    0x00FB FF20	Monitor Stack (Growing downward)
    0x00FB FFAC	Board Info Data and permanent copy of global data
    0x00FC 0000	Malloc Arena
          :
    0x00FD FFFF
    0x00FE 0000	RAM Copy of Monitor Code
    ...		eventually: LCD or video framebuffer
    ...		eventually: pRAM (Protected RAM - unchanged by
reset)
    0x00FF FFFF	[End of RAM]
System Initialization:
----------------------
In the reset configuration, U-Boot starts at the reset entry point
(on most PowerPC systens at address 0x00000100). Because of the reset
configuration for CS0# this is a mirror of the onboard Flash memory.
To be able to re-map memory U-Boot then jumps to its link address.
To be able to implement the initialization code in C, a (small!)
initial stack is set up in the internal Dual Ported RAM (in case CPUs
which provide such a feature like MPC8xx or MPC8260), or in a locked
part of the data cache. After that, U-Boot initializes the CPU core,
the caches and the SIU.
Next, all (potentially) available memory banks are mapped using a
preliminary mapping. For example, we put them on 512 MB boundaries
(multiples of 0x20000000: SDRAM on 0x00000000 and 0x20000000, Flash
on 0x40000000 and 0x60000000, SRAM on 0x80000000). Then UPM A is
programmed for SDRAM access. Using the temporary configuration, a
simple memory test is run that determines the size of the SDRAM
banks.
When there is more than one SDRAM bank, and the banks are of
different size, the largest is mapped first. For equal size, the first
bank (CS2#) is mapped first. The first mapping is always for address
0x00000000, with any additional banks following immediately to create
contiguous memory starting from 0.
Then, the monitor installs itself at the upper end of the SDRAM area
and allocates memory for use by malloc() and for the global Board
Info data; also, the exception vector code is copied to the low RAM
pages, and the final stack is set up.
Only after this relocation will you have a "normal" C environment;
until that you are restricted in several ways, mostly because you are
running from ROM, and because the code will have to be relocated to a
new address in RAM.
U-Boot Porting Guide:
----------------------
[Based on messages by Jerry Van Baren in the U-Boot-Users mailing
list, October 2002]
int main (int argc, char *argv[])
{
    sighandler_t no_more_time;
signal (SIGALRM, no_more_time);
    alarm (PROJECT_DEADLINE - toSec (3 * WEEK));
if (available_money > available_manpower) {
    	pay consultant to port U-Boot;
    	return 0;
    }
Download latest U-Boot source;
Subscribe to u-boot-users mailing list;
if (clueless) {
    	email ("Hi, I am new to U-Boot, how do I get started?");
    }
while (learning) {
    	Read the README file in the top level directory;
    	Read http://www.denx.de/twiki/bin/view/DULG/Manual ;
    	Read the source, Luke;
    }
if (available_money > toLocalCurrency ($2500)) {
    	Buy a BDI2000;
    } else {
    	Add a lot of aggravation and time;
    }
Create your own board support subdirectory;
Create your own board config file;
while (!running) {
    	do {
    		Add / modify source code;
    	} until (compiles);
    	Debug;
    	if (clueless)
    		email ("Hi, I am having problems...");
    }
    Send patch file to Wolfgang;
return 0;
}
void no_more_time (int sig)
{
      hire_a_guru();
}

Re: [PROPOSAL] extended payload handling