* Réf. : Re: starting RAM adress for linux kernel
@ 2005-06-03 14:55 scarayol
2005-06-03 15:58 ` Wolfgang Denk
0 siblings, 1 reply; 3+ messages in thread
From: scarayol @ 2005-06-03 14:55 UTC (permalink / raw)
To: wd; +Cc: ctrichet, linuxppc-embedded
Dear Wolfgang,
we need to have the start of Ram at 0x0300 0000 because we use the comm=
and
mem=3D40M (for uboot) to force Linux
in the low part of memory and to reserve the high part of memory (218M
exactly ) for ioremap (for our application) but we keep
the same flash mapping (to avoid more problems).
So how can we do that ? The boot seems OK but there is some problems in=
Kernel after uncompressing the kernel image.
Is the only solution is to inverse the mapping with Ram from 0 to 258M =
and
the flash above ?
Finally, will Busybox work with Ram starting at 0x03000000 ?
Thank you really for your help.
Sophie CARAYOL.
=
=
Wolfgang Denk =
=
<wd@denx.de> Pour : scarayol@assystembrime=
.com =
Envoy=E9 par : cc : linuxppc-embedded@oz=
labs.org, ctrichet@assystembrime.com =
=20
wd@denx.de Objet : Re: starting RAM =
adress for linux kernel =
=
=
=
=
03/06/05 =
=
16:14 =
=
=
=
=
=
Dear Sophie,
in message <OFED9D0639.75930571-ONC1257015.0031274C@brime.fr> you wrote=
:
>
> We have a platform similar to MPC885ADS (xith Kernel version 2.4.26)
except
> that :
> - the RAM is at 0x0300 0000 (size 0x10000000)
> - the flash is at 0x0280 0000 (size 0x00200000)
> - IMMR =3D 0x0220 0000
Ummm - just to avoid any misunderstandings: there is no technical
reason for such a memory map, and no other good reason either as such
a configuration will not be able to run Linux.
> After u-boot on MPC885ADS, we get the following platform information =
:
> - RAM at 0 size 0x0080 0000
> - FLASH at 0xFE00 0000 size 0x00200000
> - IMMR at 0xFF00 0000
>
> This information is different from the documentation of MPC885ADS :
> - FLASH at 0x0280 0000 size 0x00800000
> - IMMR at 0x0220 0000
So what is your problem? The memory map ist just something you define
as it fits your project. The values in the MPC885ADS are not really
useful for any practical purposes, so U-Boot choses to define
different, more useful values. This is perfectly fine.
> 1) in fads.h of u-boot, it is specified that RAM __must_ start at 0 :=
it
> isn't true on our board :
This applies for your board, too.
> - can linux work with RAM not beginning at 0 on this board ?
You can make it work, but there is no good reason to do this. Juts
change your memory map to use a more sensible configuration.
> - what modifications should we make in the kernel to accept RAM at
0x03000000 ?
Please forget this idea.
> 2) is brd_info the only structure given to kernel by u-boot ?
> That is to say is it the only way for the kernel to have information
about
> the boad ?
It also gets passed the kernel commandline and some other data in
registers.
> 4) are the following values important if CONFIG_HIGHMEM is not defin=
ed
You don't want to play with these data unless you know exactly what
you are doing.
> (they are automatically generated by our Metrowerks PCS tool in
autoconf.h ) ?
Then please ask Metrowerks support who provided such a tool which is
unknown to me.
> 5) is the base value of IMMR very important (real value in u-boot
different
> from documentation) ?
Yes, it is very important. Your current memory map cannot work with
Linux.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Fascinating is a word I use for the unexpected.
-- Spock, "The Squire of Gothos", stardate 2124.5
=
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Réf. : Re: starting RAM adress for linux kernel
2005-06-03 14:55 Réf. : Re: starting RAM adress for linux kernel scarayol
@ 2005-06-03 15:58 ` Wolfgang Denk
0 siblings, 0 replies; 3+ messages in thread
From: Wolfgang Denk @ 2005-06-03 15:58 UTC (permalink / raw)
To: scarayol; +Cc: ctrichet, linuxppc-embedded
Dear Sphie,
in message <OFF1C6B550.9120AF42-ONC1257015.004EFCD3@brime.fr> you wrote:
>
> we need to have the start of Ram at 0x0300 0000 because we use the command
> mem=40M (for uboot) to force Linux
> in the low part of memory and to reserve the high part of memory (218M
> exactly ) for ioremap (for our application) but we keep
I don't see any reason why this would prevent you from mapping the
RAM at physical address 0.
> the same flash mapping (to avoid more problems).
I don't know which problems you want to avoid by your chosen memory
map, but I guess that the problems you *cause* by this choice are
more, and more severe.
> Is the only solution is to inverse the mapping with Ram from 0 to 258M and
> the flash above ?
Yes.
> Finally, will Busybox work with Ram starting at 0x03000000 ?
No, it will not, as BB is application code which requires a running
kernel, and your kernel will not run with such a mapping.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"It may be that our role on this planet is not to worship God but to
create him." - Arthur C. Clarke
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: Réf. : Re: starting RAM adress for linux kernel
@ 2005-06-03 15:06 Steven Blakeslee
0 siblings, 0 replies; 3+ messages in thread
From: Steven Blakeslee @ 2005-06-03 15:06 UTC (permalink / raw)
To: scarayol, wd; +Cc: ctrichet, linuxppc-embedded
>=20
> we need to have the start of Ram at 0x0300 0000 because we=20
> use the command mem=3D40M (for uboot) to force Linux in the low=20
> part of memory and to reserve the high part of memory (218M=20
> exactly ) for ioremap (for our application) but we keep the=20
> same flash mapping (to avoid more problems).
> So how can we do that ? The boot seems OK but there is some=20
> problems in Kernel after uncompressing the kernel image.
> Is the only solution is to inverse the mapping with Ram from=20
> 0 to 258M and the flash above ?
RAM should always start at address 0x0 in your chip select mapping. =
When you pass mem=3D40M Linux will claim
RAM from 0x0 to 0x02800000. The rest of the RAM, 0x02800000 to the end =
will be available for ioremap. The reason your kernel does nothing =
after being uncompressed is because it has no idea where it is and =
probably is not being uncompressed to a valid RAM address.
The sensible place to map FLASH is the end of memory, or anywhere out of =
the way. I assume you are low booting and that is why you think FLASH =
needs to be at the beginning of memory. It does not, even though that =
is where you boot from you can remap the FLASH.
>=20
> Finally, will Busybox work with Ram starting at 0x03000000 ?
Busy box is part of your ramdisk, it does not know anything about the =
memory map. If your kernel does not get past uncompressing then you did =
not get anywhere near busy box running.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-06-03 15:59 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-03 14:55 Réf. : Re: starting RAM adress for linux kernel scarayol
2005-06-03 15:58 ` Wolfgang Denk
-- strict thread matches above, loose matches on Subject: below --
2005-06-03 15:06 Steven Blakeslee
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).