From: Grant Likely <hidden> Date: 2006-01-17 07:39:52
Let's keep this conversation on the mailing list.
Peter Ryser wrote:
Hi Grant and Andrei,
I'm glad to see some activity on the linuxppc email alias for the MLxxx
boards and appreciate the work put into moving the 2.4 support to 2.6.
I just tried to boot the 2.6 kernel with Grant's patches applied to
Linus' latest tree on both the ML300 and the ML403 and in both cases end
up with the PLB Error LED lit up. Both boards print the messages from
the bootloader, print "Now booting the kernel" and then nothing (but the
error LED). Anything you can think of that is going wrong?
Hmm, did you use the ml403 and ml300 def configs? What date did you
pull Linus' tree? Kumar and Paul were talking today about some serial
subsystem breakage on the linux-2.6 tree this weekend... I'll fast
forward tonight and try it on my board.
Try seeking to commit: 67daf5f11f06b9b15f8320de1d237ccc2e74fe43
That's what I generated the latest patches against.
Anyway, there is another issue that I would like to bring up and it has
to do with xparameters.h. The xparameters.h file, or more exactly, the
xparameters_* file, is automatically generated by EDK and is then used
to configure the devices in the Linux kernel at compile time. While I
understand the desire to get away from a static device definition to
device enumeration at run-time, the current set of patches is a step
backwards for users from a useability point of view. Users will now have
to modify xparameters*.h by hand which is an error-prone process.
Actually, users should *never* modifiy generated files. The intent is
that board specific fixups go directly into the top level xparameters.h
so that newly generated files don't have to be touched. But yes, I
understand what you mean.
Additionally, the original 'redefines' are now replaced with redefines
in xparameters.h but differently for every board. I suggest we keep the
2.4 methodology until we can come up with a better approach to enumerate
devices at run-time.
Andrei & I are already discussing this. I'm going to change the
xparameters redefines to provide a default set of mappings that can be
used if xparameters_*.h has the linux specific mappings.
However, due to the fact that generated xparam files don't have the
Linux redefines if the FPGA engineer doesn't select a linux bsp. I
think it's important to allow user defined 'fixups' for their board.
(I've personally worked on a couple of projects where the FPGA engineer
would not generate the Linux BSP). Design specific fixups can go into
the top level xparameters.h without touching the generated file
<rant> BTW; it really bugs me that edk will generate different xparam
files depending on the bsp; why isn't there a single standard set of
data that is loaded into all xparam files; regardless of software
target? Some no-OS targets need the same information that a Linux port
needs. </rant>
I've avoided using the same names as used by the Linux redefines because
I don't know how stable the linux bsp naming convention is, and I want
to avoid a naming conflict. If you can *guarantee* me that those linux
redefines are stable, then I have no problem using them instead of the
new defines that are currently in the patch. If they are not; then I'll
just do a one-to-one mapping into a non-conflicting namespace, and users
can provide custom definitions as needed.
This really isn't a big deal anyway; most of this discussion will become
moot in short order. Sometime in the next few releases, linuxppc will
flip over to using a flattened device tree to pass device information
from the boot loader to the kernel. xparameters will drop out of the
kernel proper entirely except for the edk-generated device drivers
(which is another issue entirely). All the xparam stuff will be
extracted into a device tree by u-boot or the zImage wrapper. The
kernel just won't care. :)
Specific to the patch: XPAR_DDR_SIZE is not the same as XPAR_MEM_*.
XPAR_DDR_SIZE is specifically defined by the user as part of the BSP
generation and indicates how much memory is available for Linux. This
can be (and typically is) the same as the physically available memory
but can be less than that. On the other hand XPAR_MEM_* can be the same
or a multiple of the physically available memory (aliasing for cached
and non-cached accesses). Statically defining the memory size in
xparameters_ml403.h is not desirable. This is especially true for the
multi-processor FPGA devices that might want to share the physically
available memory between themselves.
As you can see in embed_config.c; I already discovered this the hard way
:(
Hmmm, I don't see any XPAR mem defines in xparameters_ml300.h. (I don't
have a copy of the linux xparams for ml403 in front of me at the moment)
Is this something new?
Really, this isn't statically defined anyway. The bootloader (u-boot or
zImage) passes the memory size into the kernel; and in fact the kernel
command line; or the board setup code can restrict the amount of mem
used by the kernel. XPAR_MEM_* isn't used by the kernel proper at all.
- Peter
Thanks for the comments.
Another issue we need to discuss is if/how to support the xilinx
generated BSP in the kernel proper; but I'll leave that for a different
email.
If there's enough interest; I'll setup another git tree for the virtex
specific patches.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
From: Peter Ryser <hidden> Date: 2006-01-17 13:14:04
Hmm, did you use the ml403 and ml300 def configs? What date did you
pull Linus' tree? Kumar and Paul were talking today about some serial
subsystem breakage on the linux-2.6 tree this weekend... I'll fast
forward tonight and try it on my board.
Okay, please let me know how this works for you.
Try seeking to commit: 67daf5f11f06b9b15f8320de1d237ccc2e74fe43
That's what I generated the latest patches against.
Hmm, I only recently switched to using git. Is this number string some
kind of a tag that I can synchronize my local git tree to? If so, how?
quoted
Anyway, there is another issue that I would like to bring up and it
has to do with xparameters.h. The xparameters.h file, or more
exactly, the xparameters_* file, is automatically generated by EDK
and is then used to configure the devices in the Linux kernel at
compile time. While I understand the desire to get away from a static
device definition to device enumeration at run-time, the current set
of patches is a step backwards for users from a useability point of
view. Users will now have to modify xparameters*.h by hand which is
an error-prone process.
Actually, users should *never* modifiy generated files. The intent is
that board specific fixups go directly into the top level
xparameters.h so that newly generated files don't have to be touched.
But yes, I understand what you mean.
An EDK user is free to choose arbitrary names for his peripherals.
Additionally, Base System Builder uses different names for various
boards (historically). With that it is impossible to make static
assignments in xparameters.h. If you go back to the 2.4 kernel and have
a look at xparameters_ml300.h you can see that the assignment of boards
specific parameters to Linux specific parameters is done in there and
that xparameters.h is basically used to chose the proper xparameters_*
file for a given board.
quoted
Additionally, the original 'redefines' are now replaced with
redefines in xparameters.h but differently for every board. I suggest
we keep the 2.4 methodology until we can come up with a better
approach to enumerate devices at run-time.
Andrei & I are already discussing this. I'm going to change the
xparameters redefines to provide a default set of mappings that can be
used if xparameters_*.h has the linux specific mappings.
Thanks. Why not just use the xparameters_ml300.h file created by the
system_linux.xmp in the EDK reference design for the ML403 and rename it
to xparameters_ml403.h for inclusion into the kernel tree? We could then
make a change in EDK, add a parameter that lets the user specify the
board he uses, and with that automatically create an xparameters_ml403.h
(or any other board for that matter).
However, due to the fact that generated xparam files don't have the
Linux redefines if the FPGA engineer doesn't select a linux bsp.
That's not a recommended flow. It's very easy to create an EDK design
with the proper settings and since it is very likely that things change
during the design process of the FPGA the small investment into making
the proper settings in the tool will save a lot of time in the end.
I think it's important to allow user defined 'fixups' for their
board. (I've personally worked on a couple of projects where the FPGA
engineer would not generate the Linux BSP). Design specific fixups
can go into the top level xparameters.h without touching the generated
file
I strongly believe that this approach fixes things in the wrong place.
The correct thing to do is to use EDK to create a proper xparameters_*.h
that matches the FPGA design. In your methodology, if the user decides
to change the peripheral names in EDK he will have to go back and change
the defines in xparameters.h. With the 2.4 kernel methodology that is
not necessary as such changes will be represented in a regenerated
board-specific xparameters_*.h
<rant> BTW; it really bugs me that edk will generate different xparam
files depending on the bsp; why isn't there a single standard set of
data that is loaded into all xparam files; regardless of software
target? Some no-OS targets need the same information that a Linux
port needs. </rant>
EDK creates an xparameters.h that matches the names of the parameters in
the hardware design. However, EDK is capable of assuming other
personalities than 'standalone', for example Linux. With the Linux
personality it creates the proper files AND directory structure for
inclusion into the Linux kernel. Ideally, the source files that are used
to create the Linux bsp for a given FPGA design should be included in
the kernel tree and be maintained in there (maybe, in the xparameters
directory). I'm not so sure though how well this would be accepted in
the community. Opinions?
I've avoided using the same names as used by the Linux redefines
because I don't know how stable the linux bsp naming convention is,
and I want to avoid a naming conflict. If you can *guarantee* me that
those linux redefines are stable, then I have no problem using them
instead of the new defines that are currently in the patch. If they
are not; then I'll just do a one-to-one mapping into a non-conflicting
namespace, and users can provide custom definitions as needed.
The names are stable. They have not changed since xparameters_ml300.h
has been initially published to the 2.4 repository and there are no
intentions on changing them. And again, we really want to move towards a
structure that allows for detecting peripherals at run-time. That will
improve useability by a magnitude as no recompilation of the Linux
kernel will be needed when the FPGA design changes.
This really isn't a big deal anyway; most of this discussion will
become moot in short order. Sometime in the next few releases,
linuxppc will flip over to using a flattened device tree to pass
device information from the boot loader to the kernel. xparameters
will drop out of the kernel proper entirely except for the
edk-generated device drivers (which is another issue entirely). All
the xparam stuff will be extracted into a device tree by u-boot or the
zImage wrapper. The kernel just won't care. :)
I agree. That's the way to go. Let's work towards that goal and keep
xparameters_* as they have been in 2.4 for the moment.
quoted
Specific to the patch: XPAR_DDR_SIZE is not the same as XPAR_MEM_*.
XPAR_DDR_SIZE is specifically defined by the user as part of the BSP
generation and indicates how much memory is available for Linux. This
can be (and typically is) the same as the physically available memory
but can be less than that. On the other hand XPAR_MEM_* can be the
same or a multiple of the physically available memory (aliasing for
cached and non-cached accesses). Statically defining the memory size
in xparameters_ml403.h is not desirable. This is especially true for
the multi-processor FPGA devices that might want to share the
physically available memory between themselves.
As you can see in embed_config.c; I already discovered this the hard
way :(
Right. Sorry, I was quoting the wrong file. The value should not be
hard-coded in embed_config.c but instead XPAR_DDR_SIZE should be used
which is defined in xparameters_ml403.h.
Hmmm, I don't see any XPAR mem defines in xparameters_ml300.h. (I
don't have a copy of the linux xparams for ml403 in front of me at the
moment) Is this something new?
I was referring to XPAR*MEM*, i.e. the base address and high address
definition for the memory in EDK.
Really, this isn't statically defined anyway. The bootloader (u-boot
or zImage) passes the memory size into the kernel; and in fact the
kernel command line; or the board setup code can restrict the amount
of mem used by the kernel. XPAR_MEM_* isn't used by the kernel proper
at all.
Agreed.
Thanks for the comments.
Thanks for making this patch available. I know how much hard work it is
to get this done.
Another issue we need to discuss is if/how to support the xilinx
generated BSP in the kernel proper; but I'll leave that for a
different email.
Okay.
If there's enough interest; I'll setup another git tree for the virtex
specific patches.
Hmm, interesting idea. Let's see what others think.
- Peter
From: Grant Likely <hidden> Date: 2006-01-17 15:41:39
Peter Ryser wrote:
quoted
Hmm, did you use the ml403 and ml300 def configs? What date did you
pull Linus' tree? Kumar and Paul were talking today about some serial
subsystem breakage on the linux-2.6 tree this weekend... I'll fast
forward tonight and try it on my board.
Okay, please let me know how this works for you.
quoted
Try seeking to commit: 67daf5f11f06b9b15f8320de1d237ccc2e74fe43
That's what I generated the latest patches against.
Hmm, I only recently switched to using git. Is this number string some
kind of a tag that I can synchronize my local git tree to? If so, how?
Yea, the number is kind of like a raw tag without a name associated with
it. The cg-seek command can be used to get you there. (But you also
need to have cogito installed)
quoted
quoted
Anyway, there is another issue that I would like to bring up and it
has to do with xparameters.h. The xparameters.h file, or more
exactly, the xparameters_* file, is automatically generated by EDK
and is then used to configure the devices in the Linux kernel at
compile time. While I understand the desire to get away from a static
device definition to device enumeration at run-time, the current set
of patches is a step backwards for users from a useability point of
view. Users will now have to modify xparameters*.h by hand which is
an error-prone process.
Actually, users should *never* modifiy generated files. The intent is
that board specific fixups go directly into the top level
xparameters.h so that newly generated files don't have to be touched.
But yes, I understand what you mean.
An EDK user is free to choose arbitrary names for his peripherals.
Additionally, Base System Builder uses different names for various
boards (historically). With that it is impossible to make static
assignments in xparameters.h. If you go back to the 2.4 kernel and have
a look at xparameters_ml300.h you can see that the assignment of boards
specific parameters to Linux specific parameters is done in there and
that xparameters.h is basically used to chose the proper xparameters_*
file for a given board.
okay
quoted
quoted
Additionally, the original 'redefines' are now replaced with
redefines in xparameters.h but differently for every board. I suggest
we keep the 2.4 methodology until we can come up with a better
approach to enumerate devices at run-time.
Andrei & I are already discussing this. I'm going to change the
xparameters redefines to provide a default set of mappings that can be
used if xparameters_*.h has the linux specific mappings.
Thanks. Why not just use the xparameters_ml300.h file created by the
system_linux.xmp in the EDK reference design for the ML403 and rename it
to xparameters_ml403.h for inclusion into the kernel tree? We could then
make a change in EDK, add a parameter that lets the user specify the
board he uses, and with that automatically create an xparameters_ml403.h
(or any other board for that matter).
I don't understand what you mean. It sounds like your suggesting I do
exactly opposite what you're arguing; hand modify one of the
xparameters_*.h files. Are you saying that edk can't generate Linux
redefines for the ml403 at the moment?
I do *not* think I should replace the edk-generated xparameters_ml403.h
with a hacked xparameters_ml300.h file. I'd rather use the generated
_ml403 file and change the infrastructure when the Linux redefines are
ready.
quoted
However, due to the fact that generated xparam files don't have the
Linux redefines if the FPGA engineer doesn't select a linux bsp.
That's not a recommended flow. It's very easy to create an EDK design
with the proper settings and since it is very likely that things change
during the design process of the FPGA the small investment into making
the proper settings in the tool will save a lot of time in the end.
I understand that it's not *recommended*; I'm just saying it's not
always *reality* :p
quoted
I think it's important to allow user defined 'fixups' for their
board. (I've personally worked on a couple of projects where the FPGA
engineer would not generate the Linux BSP). Design specific fixups
can go into the top level xparameters.h without touching the generated
file
I strongly believe that this approach fixes things in the wrong place.
The correct thing to do is to use EDK to create a proper xparameters_*.h
that matches the FPGA design. In your methodology, if the user decides
to change the peripheral names in EDK he will have to go back and change
the defines in xparameters.h. With the 2.4 kernel methodology that is
not necessary as such changes will be represented in a regenerated
board-specific xparameters_*.h
???
Yes; but I already said that I'll change the patch to use the Xilinx
redefines. My argument is simply that *if* changes are required, there
is a way for the user to do it. In the normal (recommended) case;
nothing will need to be done. (think Larry Wall's quote: "easy things
easy; hard things possible)
When it is needed; the fixups will be in xparameters.h; not
xparameters_*.h; and they'll be for a specific port. The fixups will
only need to be done once per project (most likely).
quoted
<rant> BTW; it really bugs me that edk will generate different xparam
files depending on the bsp; why isn't there a single standard set of
data that is loaded into all xparam files; regardless of software
target? Some no-OS targets need the same information that a Linux
port needs. </rant>
EDK creates an xparameters.h that matches the names of the parameters in
the hardware design. However, EDK is capable of assuming other
personalities than 'standalone', for example Linux.
My point is that the Linux redefines are useful to more than just Linux
ports. Don't you think standalone apps could also benefit from a
sane-set of defines for peripherals? In other words; shouldn't the
Linux redefines be always available (and called something more generic)?
With the Linux
personality it creates the proper files AND directory structure for
inclusion into the Linux kernel. Ideally, the source files that are used
to create the Linux bsp for a given FPGA design should be included in
the kernel tree and be maintained in there (maybe, in the xparameters
directory). I'm not so sure though how well this would be accepted in
the community. Opinions?
I'll get back to you on this; I've got some thoughts; but they'll take a
while to coallate.
quoted
I've avoided using the same names as used by the Linux redefines
because I don't know how stable the linux bsp naming convention is,
and I want to avoid a naming conflict. If you can *guarantee* me that
those linux redefines are stable, then I have no problem using them
instead of the new defines that are currently in the patch. If they
are not; then I'll just do a one-to-one mapping into a non-conflicting
namespace, and users can provide custom definitions as needed.
The names are stable. They have not changed since xparameters_ml300.h
has been initially published to the 2.4 repository and there are no
intentions on changing them. And again, we really want to move towards a
structure that allows for detecting peripherals at run-time. That will
improve useability by a magnitude as no recompilation of the Linux
kernel will be needed when the FPGA design changes.
okay, I'll change the patch to use those names.
quoted
This really isn't a big deal anyway; most of this discussion will
become moot in short order. Sometime in the next few releases,
linuxppc will flip over to using a flattened device tree to pass
device information from the boot loader to the kernel. xparameters
will drop out of the kernel proper entirely except for the
edk-generated device drivers (which is another issue entirely). All
the xparam stuff will be extracted into a device tree by u-boot or the
zImage wrapper. The kernel just won't care. :)
I agree. That's the way to go. Let's work towards that goal and keep
xparameters_* as they have been in 2.4 for the moment.
quoted
quoted
Specific to the patch: XPAR_DDR_SIZE is not the same as XPAR_MEM_*.
XPAR_DDR_SIZE is specifically defined by the user as part of the BSP
generation and indicates how much memory is available for Linux. This
can be (and typically is) the same as the physically available memory
but can be less than that. On the other hand XPAR_MEM_* can be the
same or a multiple of the physically available memory (aliasing for
cached and non-cached accesses). Statically defining the memory size
in xparameters_ml403.h is not desirable. This is especially true for
the multi-processor FPGA devices that might want to share the
physically available memory between themselves.
As you can see in embed_config.c; I already discovered this the hard
way :(
Right. Sorry, I was quoting the wrong file. The value should not be
hard-coded in embed_config.c but instead XPAR_DDR_SIZE should be used
which is defined in xparameters_ml403.h.
ok
quoted
Hmmm, I don't see any XPAR mem defines in xparameters_ml300.h. (I
don't have a copy of the linux xparams for ml403 in front of me at the
moment) Is this something new?
I was referring to XPAR*MEM*, i.e. the base address and high address
definition for the memory in EDK.
quoted
Really, this isn't statically defined anyway. The bootloader (u-boot
or zImage) passes the memory size into the kernel; and in fact the
kernel command line; or the board setup code can restrict the amount
of mem used by the kernel. XPAR_MEM_* isn't used by the kernel proper
at all.
Agreed.
quoted
Thanks for the comments.
Thanks for making this patch available. I know how much hard work it is
to get this done.
quoted
Another issue we need to discuss is if/how to support the xilinx
generated BSP in the kernel proper; but I'll leave that for a
different email.
Okay.
quoted
If there's enough interest; I'll setup another git tree for the virtex
specific patches.
Hmm, interesting idea. Let's see what others think.
- Peter
cool, thanks.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
From: Peter Ryser <hidden> Date: 2006-01-17 17:07:15
I don't understand what you mean. It sounds like your suggesting I do
exactly opposite what you're arguing; hand modify one of the
xparameters_*.h files. Are you saying that edk can't generate Linux
redefines for the ml403 at the moment?
Yes, it can. It looks they are not present in the xparameters_ml403.h
that you submitted as part of your patch. I'll send you the
automatically generated file in a seperate email.
I do *not* think I should replace the edk-generated
xparameters_ml403.h with a hacked xparameters_ml300.h file. I'd
rather use the generated _ml403 file and change the infrastructure
when the Linux redefines are ready.
See above. BTW, I'm not sure how familiar you are with the process in
EDK. Let me know if I can help you step through it.
quoted
That's not a recommended flow. It's very easy to create an EDK design
with the proper settings and since it is very likely that things
change during the design process of the FPGA the small investment
into making the proper settings in the tool will save a lot of time
in the end.
I understand that it's not *recommended*; I'm just saying it's not
always *reality* :p
Yeah, that's true for user projects. However, I hope that we can get the
default included in the Linux 2.6 kernel right.
Yes; but I already said that I'll change the patch to use the Xilinx
redefines. My argument is simply that *if* changes are required,
there is a way for the user to do it. In the normal (recommended)
case; nothing will need to be done. (think Larry Wall's quote: "easy
things easy; hard things possible)
When it is needed; the fixups will be in xparameters.h; not
xparameters_*.h; and they'll be for a specific port. The fixups will
only need to be done once per project (most likely).
I'm not sure that I follow your argument here.
My point is that the Linux redefines are useful to more than just
Linux ports. Don't you think standalone apps could also benefit from
a sane-set of defines for peripherals? In other words; shouldn't the
Linux redefines be always available (and called something more generic)?
From: Grant Likely <hidden> Date: 2006-01-17 17:30:47
Peter Ryser wrote:
quoted
I don't understand what you mean. It sounds like your suggesting I do
exactly opposite what you're arguing; hand modify one of the
xparameters_*.h files. Are you saying that edk can't generate Linux
redefines for the ml403 at the moment?
Yes, it can. It looks they are not present in the xparameters_ml403.h
that you submitted as part of your patch. I'll send you the
automatically generated file in a seperate email.
okay good; I misunderstood what you were saying. I pulled
xparameters_ml403.h out of the ref design w/ the standalone bsp. I just
haven't bothered trying to generating the Linux bsp yet.
quoted
I do *not* think I should replace the edk-generated
xparameters_ml403.h with a hacked xparameters_ml300.h file. I'd
rather use the generated _ml403 file and change the infrastructure
when the Linux redefines are ready.
See above. BTW, I'm not sure how familiar you are with the process in
EDK. Let me know if I can help you step through it.
okay, I'll ping you when I've got questions.
quoted
I understand that it's not *recommended*; I'm just saying it's not
always *reality* :p
Yeah, that's true for user projects. However, I hope that we can get the
default included in the Linux 2.6 kernel right.
yes, definately
quoted
Yes; but I already said that I'll change the patch to use the Xilinx
redefines. My argument is simply that *if* changes are required,
there is a way for the user to do it. In the normal (recommended)
case; nothing will need to be done. (think Larry Wall's quote: "easy
things easy; hard things possible)
When it is needed; the fixups will be in xparameters.h; not
xparameters_*.h; and they'll be for a specific port. The fixups will
only need to be done once per project (most likely).
I'm not sure that I follow your argument here.
I'll compose my answer in code; watch for patches. :)
btw, once Linus closes the 2.6.16 merge window, it looks like we may be
able to use the powerpc.git tree for tracking these changes.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
From: Grant Likely <hidden> Date: 2006-01-17 19:31:45
Peter Ryser wrote:
quoted
Hmm, did you use the ml403 and ml300 def configs? What date did you
pull Linus' tree? Kumar and Paul were talking today about some serial
subsystem breakage on the linux-2.6 tree this weekend... I'll fast
forward tonight and try it on my board.
Okay, please let me know how this works for you.
Yeah, the head of Linus' tree is busted. Doing a cg-seek
67daf5f11f06b9b15f8320de1d237ccc2e74fe43 will work, but you first need
to remove the following line from arch/ppc/kernel/ppc_ksyms.c
EXPORT_SYMBOL(get_wchan);
The fix will be in post -rc1
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
From: Peter Ryser <hidden> Date: 2006-01-18 23:44:21
Yeah, the head of Linus' tree is busted. Doing a cg-seek
67daf5f11f06b9b15f8320de1d237ccc2e74fe43 will work, but you first need
to remove the following line from arch/ppc/kernel/ppc_ksyms.c
EXPORT_SYMBOL(get_wchan);
After applying your patches to the branch-point you mention above,
removing that symbol, and configuring for the ML403 I can get to a boot
prompt. Good.
Doing the same for the ML300, though, does not work, i.e. I get a single
line saying:
"Data machine check in kernel mode."
Digging in the kernel configuration I don't seem to find a place where I
can turn on more verbose output, i.e. a register dump at the time of the
machine check exception. Any idea where I might find that?
- Peter
From: David H. Lynch Jr. <hidden> Date: 2006-01-19 00:31:00
Grant Likely wrote:
Let's keep this conversation on the mailing list.
Peter Ryser wrote:
quoted
Hi Grant and Andrei,
I'm glad to see some activity on the linuxppc email alias for the MLxxx
boards and appreciate the work put into moving the 2.4 support to 2.6.
I just tried to boot the 2.6 kernel with Grant's patches applied to
Linus' latest tree on both the ML300 and the ML403 and in both cases end
up with the PLB Error LED lit up. Both boards print the messages from
the bootloader, print "Now booting the kernel" and then nothing (but the
error LED). Anything you can think of that is going wrong?
I am getting the same problem when I use Grant's patches. In my
instance I have isolated the problem to hanging in
ppc_sys_get_pdata(VIRTEX_UART).
This appears to be a fairly trivial routing, so my current assumption is
that I either have VIRTEX_UART defined improperly or I have the ppc_sys
data structure created wrong.
quoted
Anyway, there is another issue that I would like to bring up and it has
to do with xparameters.h. The xparameters.h file, or more exactly, the
xparameters_* file, is automatically generated by EDK and is then used
to configure the devices in the Linux kernel at compile time. While I
understand the desire to get away from a static device definition to
device enumeration at run-time, the current set of patches is a step
backwards for users from a useability point of view. Users will now have
to modify xparameters*.h by hand which is an error-prone process.
Actually, users should *never* modifiy generated files. The intent is
that board specific fixups go directly into the top level xparameters.h
so that newly generated files don't have to be touched. But yes, I
understand what you mean.
It would be really nice if the was either some comments in
xparameters.h or in the Documents directory explaining what the Linux
xparameters values are so that it it would be easy to know what items
from xparameters_xxx.h have to be mapped or redefined.
This really isn't a big deal anyway; most of this discussion will become
moot in short order. Sometime in the next few releases, linuxppc will
flip over to using a flattened device tree to pass device information
from the boot loader to the kernel. xparameters will drop out of the
kernel proper entirely except for the edk-generated device drivers
(which is another issue entirely). All the xparam stuff will be
extracted into a device tree by u-boot or the zImage wrapper. The
kernel just won't care. :)
Where can we get more information on what is happening here ?
I started the E12 port with most info in xparameters, but I have been
moving towards getting things passed in board_info. I am not using
u-boot as the E12 has a general purpose elf loader, and it was easier to
add a fee lines for Linux. Regardless I would like to be compatible with
whatever is coming - maybe even ahead fo the curve. The e12 is just the
first of a family of products - the e14 already exists. There maybe
revisions of each at different speeds with different memory.
From: Grant Likely <hidden> Date: 2006-01-19 05:12:24
Peter Ryser wrote:
quoted
Yeah, the head of Linus' tree is busted. Doing a cg-seek
67daf5f11f06b9b15f8320de1d237ccc2e74fe43 will work, but you first need
to remove the following line from arch/ppc/kernel/ppc_ksyms.c
EXPORT_SYMBOL(get_wchan);
After applying your patches to the branch-point you mention above,
removing that symbol, and configuring for the ML403 I can get to a boot
prompt. Good.
Doing the same for the ML300, though, does not work, i.e. I get a single
line saying:
"Data machine check in kernel mode."
Hi at all
Since two week I have this Problem and can't solve it. I allready read DULG
and search in
Mailinglists but I can't run linux. Perhaps had the same problem and can
help me.
My Problem:
After I load the uImage (uImage at 0x00400000 )
from server, I try to run in with command bootm.
=> bootm 00400000
Booting image at 00400000...
Image Name: Linux-2.4.24-pre2
Created: 2006-01-19 6:25:03 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 700730 Bytes = 684.3 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
don't start kernel
my board :
sdram 16m 0----ffffff
flash 4m ffc00000 ---fffffff
routing, so my current assumption is
that I either have VIRTEX_UART defined improperly or I have the ppc_sys
data structure created wrong.
quoted
It would be really nice if the was either some comments in
xparameters.h or in the Documents directory explaining what the Linux
xparameters values are so that it it would be easy to know what items
from xparameters_xxx.h have to be mapped or redefined.
quoted
This really isn't a big deal anyway; most of this discussion will become
moot in short order. Sometime in the next few releases, linuxppc will
flip over to using a flattened device tree to pass device information
from the boot loader to the kernel. xparameters will drop out of the
kernel proper entirely except for the edk-generated device drivers
(which is another issue entirely). All the xparam stuff will be
extracted into a device tree by u-boot or the zImage wrapper. The
kernel just won't care. :)
Where can we get more information on what is happening here ?
I started the E12 port with most info in xparameters, but I have been
moving towards getting things passed in board_info. I am not using
u-boot as the E12 has a general purpose elf loader, and it was easier to
add a fee lines for Linux. Regardless I would like to be compatible with
whatever is coming - maybe even ahead fo the curve. The e12 is just the
first of a family of products - the e14 already exists. There maybe
revisions of each at different speeds with different memory.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
From: Peter Ryser <hidden> Date: 2006-01-19 07:33:48
You need to apply a patch to the 2.4 Linux kernel to make it work with
U-Boot for the MLxxx boards. You can find that patch as part of Xilinx
Application Note 542 (XAPP542,
http://direct.xilinx.com/bvdocs/appnotes/xapp542.pdf,
http://direct.xilinx.com/bvdocs/appnotes/xapp542.zip)
The process on how to apply the patch is described in that application note.
- Peter
PS: The application note is out of date for EDK tools newer than 6.2.
The patch still works, though.
jeffer wrote:
Hi at all
Since two week I have this Problem and can't solve it. I allready read
DULG and search in
Mailinglists but I can't run linux. Perhaps had the same problem and
can help me.
My Problem:
After I load the uImage (uImage at 0x00400000 )
from server, I try to run in with command bootm.
=> bootm 00400000
Booting image at 00400000...
Image Name: Linux-2.4.24-pre2
Created: 2006-01-19 6:25:03 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 700730 Bytes = 684.3 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
don't start kernel
my board :
sdram 16m 0----ffffff
flash 4m ffc00000 ---fffffff
routing, so my current assumption is
that I either have VIRTEX_UART defined improperly or I have the
ppc_sys
data structure created wrong.
>
>
It would be really nice if the was either some comments in
xparameters.h or in the Documents directory explaining what the Linux
xparameters values are so that it it would be easy to know what items
from xparameters_xxx.h have to be mapped or redefined.
> This really isn't a big deal anyway; most of this discussion
will become
> moot in short order. Sometime in the next few releases,
linuxppc will
> flip over to using a flattened device tree to pass device
information
> from the boot loader to the kernel. xparameters will drop out
of the
> kernel proper entirely except for the edk-generated device drivers
> (which is another issue entirely). All the xparam stuff will be
> extracted into a device tree by u-boot or the zImage wrapper. The
> kernel just won't care. :)
Where can we get more information on what is happening here ?
I started the E12 port with most info in xparameters, but I have been
moving towards getting things passed in board_info. I am not using
u-boot as the E12 has a general purpose elf loader, and it was
easier to
add a fee lines for Linux. Regardless I would like to be
compatible with
whatever is coming - maybe even ahead fo the curve. The e12 is
just the
first of a family of products - the e14 already exists. There maybe
revisions of each at different speeds with different memory.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
------------------------------------------------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded