Booting linux for 405EP --> mem_pieces_find( ) nightmare

Garcia Jérémie GARCIAJ at
Thu Apr 28 20:36:03 EST 2005

First of all tks everybody for your answers but I found a way to solve my problem.
I know it's not a very clean solution but it could help for people in emergency as me

In fact the problem had its roots much earlier. 
I had to have a look in the file "arch/ppc/kernel/ppc_4xx_setup.c" in the platform_init() function.
I saw that the residual structure given traditionnaly by the bootloader is retreived there as below:

	 * If we were passed in a board information, copy it into the
	 * residual data area.
	if (r3) {
		memcpy((void *) __res, (void *) (r3 + KERNELBASE),sizeof (bd_t));

This variable "__res" is used after that in several actions. In my case, that was directly linked to my mapping problem cause 
the kernel wasn't able to get the quantity of ram available. In ordr to do that, it uses the following function in my case:

    bd_t *bip = (bd_t *) __res;
    return ((unsigned long) bip->bi_memsize);

So the return of this function was incoherent and drove me to a kernel panic.

As a conclusion I just defined my own board info structure in the platform_init() function:

  bd_t my_bd_t;
  strcpy(my_bd_t.bi_s_version,"v1");                  /*  Version of this structure   */
  strcpy(my_bd_t.bi_r_version,"bootrom linux 1.0") ;  /*  Version of the IBM ROM      */
  my_bd_t.bi_memsize      = 16000000 ;                /* DRAM installed, in bytes     */
  my_bd_t.bi_enetaddr[0][0] = 0x00;                   /* Local Ethernet MAC address 1 */
  my_bd_t.bi_enetaddr[0][1] = 0x01;
  my_bd_t.bi_enetaddr[0][2] = 0x73;
  my_bd_t.bi_enetaddr[0][3] = 0x01;
  my_bd_t.bi_enetaddr[0][4] = 0xC1;
  my_bd_t.bi_enetaddr[0][5] = 0x3B;
  my_bd_t.bi_enetaddr[1][0] = 0x00;                   /* Local Ethernet MAC address 2 */
  my_bd_t.bi_enetaddr[1][1] = 0x01;
  my_bd_t.bi_enetaddr[1][2] = 0x73;
  my_bd_t.bi_enetaddr[1][3] = 0x01;
  my_bd_t.bi_enetaddr[1][4] = 0xC1;
  my_bd_t.bi_enetaddr[1][5] = 0x3C;
  my_bd_t.bi_intfreq      = 200000000 ;     /* Processor speed, in Hz       */
  my_bd_t.bi_busfreq      = 100000000 ;     /* PLB Bus speed, in Hz         */
  my_bd_t.bi_pllouta_freq = 800000000 ;     /* PLL OUTA speed, in Hz        */
  my_bd_t.bi_opb_busfreq  = 50000000 ;      /* OPB Bus speed, in Hz         */
  my_bd_t.bi_iic_fast[0]  = 0 ;             /* Use fast i2c mode            */   

  memcpy((void *) __res, (void *) &my_bd_t,sizeof (bd_t));     

  And here we go!
  I know that this is a terrible hack but I haven't find better solution.

  Regards, Jérémie

-------- Message d'origine--------
De: Conn Clark [mailto:clark at]
Date: mer. 27/04/2005 11:21
À: Garcia Jérémie
Cc: linuxppc-dev at
Objet : Re: Booting linux for 405EP --> mem_pieces_find( ) nightmare
Hi Jérémie,

Garcia Jérémie wrote:
> Hi everybody,
> I'm tryin to adapt a linux LSP deom Montavista (the one for the 405EP evaluation board) to a proprietary hardware using a 405EP.
> Unfortunately, it is not as easy as I thought. Here is my problem:
> To load our linux image (zImage.treeboot), we use the "VxWorks bootrom" bootloader which download the image via tftp.
> That works well except the fact that in the LSP, linux tried to get a board info structure in flash memory at an address where we have nothing. So we replace this behavior in "embed_config.c" with the following lines (note: I had to re-code the strcpy although there is the #include<string.h> because it cannot find the reference at the link level... why???):

I would recomend using u-boot for a boot rom. It was a god send to us in 
getting our MPC850 board up and going the first time. On our 405EP board 
we did have to do some slight hacking but nothing really major.

> /* We use VxWorks bootrom, so we have to create ourselves the boot info structure */


> Jérémie        \\ (°.°) //~ ~ ~ HELP ~ ~ ~ \\ (°.°) //
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at

-- Conn

Blessed be the heretic, for he causes some to think and unites
the rest against him.

Conn Clark
Engineering Assistant                clark at
Electronic Systems Technology Inc.

Stock Ticker Symbol                ELST

More information about the Linuxppc-dev mailing list