From: Michael Sokolov <hidden> Date: 2002-03-29 23:59:44
Mark A. Greer [off-list ref] wrote:
I have other things to do so I won't be able to finish today. In case
someone wants to work on this over the weekend, attached is a patch of
what I have so far. It implements the example bi_rec's emailed before
for the ev64260 board. Feel free to use it or do a better job.
Looks OK except for 2 major problems:
1. You are using find_bootinfo() in EV-64260 platform_init to find the bi_recs.
This is bad, as the magic location where find_bootinfo looks for the bi_recs is
unavailable to bootloaders outside the linux source tree. Instead I have
adopted the convention (which Tom Rini has accepted for the K2 port and
implemented in the wrapper) to pass the physical address of bi_recs to the
kernel in R3. You should use r3 + KERNELBASE in platform_init to find the
bi_recs. This works with the wrapper just as well as find_bootinfo(), but is
much nicer for external bootloaders.
2. You are also using find_bootinfo() in the gt64260_eth driver to find its
bi_recs. In addition to the problems mentioned above, this has the extra
problem in that find_bootinfo's magic location, or any other bootloader's
location for that matter, has certainly been overwritten at this point. If you
want to peek at bi_recs after platform_init(), you have to have setup.c or
something copy them into memory that the kernel will retain.
Because of problem #2 your code will most certainly not work as it is right
now.
MS
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Mark A. Greer <hidden> Date: 2002-03-29 22:24:11
Michael Sokolov wrote:
Mark A. Greer [off-list ref] wrote:
quoted
I have other things to do so I won't be able to finish today. In case
someone wants to work on this over the weekend, attached is a patch of
what I have so far. It implements the example bi_rec's emailed before
for the ev64260 board. Feel free to use it or do a better job.
Looks OK except for 2 major problems:
1. You are using find_bootinfo() in EV-64260 platform_init to find the bi_recs.
This is bad, as the magic location where find_bootinfo looks for the bi_recs is
unavailable to bootloaders outside the linux source tree. Instead I have
adopted the convention (which Tom Rini has accepted for the K2 port and
implemented in the wrapper) to pass the physical address of bi_recs to the
kernel in R3. You should use r3 + KERNELBASE in platform_init to find the
bi_recs. This works with the wrapper just as well as find_bootinfo(), but is
much nicer for external bootloaders.
It *is* in the kernel source (and not the bootloader). Also, 15 of the *_setup.c
files in arch/ppc/platforms call find_bootinfo including ev64260_setup.c before I
modified it. I think the R3 way of doing things is out of date now but maybe Tom
can elaborate.
2. You are also using find_bootinfo() in the gt64260_eth driver to find its
bi_recs. In addition to the problems mentioned above, this has the extra
problem in that find_bootinfo's magic location, or any other bootloader's
location for that matter, has certainly been overwritten at this point. If you
want to peek at bi_recs after platform_init(), you have to have setup.c or
something copy them into memory that the kernel will retain.
Because of problem #2 your code will most certainly not work as it is right
now.
You may have a point here. I thought the bi_rec's were left around but I need to
verify.
Mark
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Mark A. Greer <hidden> Date: 2002-03-29 22:30:51
"Mark A. Greer" wrote:
Michael Sokolov wrote:
quoted
Because of problem #2 your code will most certainly not work as it is right
now.
You may have a point here. I thought the bi_rec's were left around but I need to
verify.
I took a quick look and didn't see it being reused but I may have missed it.
Mark
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Mark A. Greer <hidden> Date: 2002-03-29 22:41:45
"Mark A. Greer" wrote:
"Mark A. Greer" wrote:
quoted
Michael Sokolov wrote:
quoted
Because of problem #2 your code will most certainly not work as it is right
now.
You may have a point here. I thought the bi_rec's were left around but I need to
verify.
I took a quick look and didn't see it being reused but I may have missed it.
Okay, the bi_recs need to be copied. Something for you to do over the weekend ;)
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Fri, Mar 29, 2002 at 05:24:11PM -0500, Mark A. Greer wrote:
Michael Sokolov wrote:
quoted
Mark A. Greer [off-list ref] wrote:
quoted
I have other things to do so I won't be able to finish today. In case
someone wants to work on this over the weekend, attached is a patch of
what I have so far. It implements the example bi_rec's emailed before
for the ev64260 board. Feel free to use it or do a better job.
Looks OK except for 2 major problems:
1. You are using find_bootinfo() in EV-64260 platform_init to find the
bi_recs. This is bad, as the magic location where find_bootinfo looks for
the bi_recs is
unavailable to bootloaders outside the linux source tree. Instead I have
adopted the convention (which Tom Rini has accepted for the K2 port and
implemented in the wrapper) to pass the physical address of bi_recs to the
kernel in R3. You should use r3 + KERNELBASE in platform_init to find the
bi_recs. This works with the wrapper just as well as find_bootinfo(), but is
much nicer for external bootloaders.
It *is* in the kernel source (and not the bootloader). Also, 15 of
the *_setup.c files in arch/ppc/platforms call find_bootinfo including
ev64260_setup.c before I modified it. I think the R3 way of doing things
is out of date now but maybe Tom can elaborate.
OK. The problem is that the original PPC location of the bi_recs was
kernel BSS + some. This posed 2 problems. First, a big enough kernel
could overwrite the bi_recs when they're here. The second problem is
that anything out side of the kernel shouldn't have to know where the
bss is (in-kernel does because of linker magic). So r3 is where the
bi_rec location can be. This might be changed later (or we'll just pass
along the PReP residual data (not Motorola like I said in my last email,
whoops) location in a bi_rec. :)
So the always-correct call for platform_init() is:
parse_bootinfo((struct bi_record *) (r3 + KERNELBASE));
But, since Michael has only worked on a few boards, only a few boards do
that right now.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Mon, Apr 01, 2002 at 10:09:37AM -0500, Mark A. Greer wrote:
Tom Rini wrote:
quoted
OK. The problem is that the original PPC location of the bi_recs was
Acutally, my problem was that I misread his respone. I thought he was trying to
say the find_bootinfo was in the bootloader or something like that.
quoted
So the always-correct call for platform_init() is:
parse_bootinfo((struct bi_record *) (r3 + KERNELBASE));
Is there a reason we shouldn't just fix find_bootinfo then?
The intent of parse_bootinfo taking a location was to allow it to be a
per-platform thing. Eg pmac/chrp/prep don't use r3, and can't always
anyhow. Everything else uses r3 just because it's where the
bootloader/wrapper caneasily put things.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Paul Mackerras <hidden> Date: 2002-04-02 02:50:56
Mark A. Greer writes:
quoted
So the always-correct call for platform_init() is:
parse_bootinfo((struct bi_record *) (r3 + KERNELBASE));
Is there a reason we shouldn't just fix find_bootinfo then?
The reason why I split the original parse_bootinfo into two pieces,
find_bootinfo and parse_bootinfo, was to allow for the case where the
bootloader passes in the address of the bi_recs. In other words,
if you know where the bi_recs are, you don't need to call
find_bootinfo, just parse_bootinfo.
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/