Stefan I believe I have a better fix for the LinuxBIOS table bug then __attribute__((packed)).
How does this look?
I am still worried about ppc, and big endian architectures in general. But I don't think we currently have any users there.
I don't know what is the best long term strategy for handling 64bit numbers but for this instance where we need a better definition for the current structure simply using a structure with 2 32bit ints looks like a sane way to go.
Eric
--- checkin/freebios2/src/include/boot/linuxbios_tables.h Tue Apr 22 13:01:45 2003 +++ linuxbios/freebios2/src/include/boot/linuxbios_tables.h Thu Dec 9 16:55:18 2004 @@ -57,14 +57,17 @@
#define LB_TAG_MEMORY 0x0001
+struct lb_uint64 { + uint32_t lo; + uint32_t hi; +}; struct lb_memory_range { - uint64_t start; - uint64_t size; + struct lb_uint64 start; + struct lb_uint64 size; uint32_t type; #define LB_MEM_RAM 1 /* Memory anyone can use */ #define LB_MEM_RESERVED 2 /* Don't use this memory region */ #define LB_MEM_TABLE 16 /* Ram configuration tables are kept in */ - };
struct lb_memory {
On Thu, 9 Dec 2004, Eric W. Biederman wrote:
I am still worried about ppc, and big endian architectures in general. But I don't think we currently have any users there.
we do. I think I'd like to hear Greg Watson's take on this as he is working with the PPC 970 guys and this will impact him.
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
On Thu, 9 Dec 2004, Eric W. Biederman wrote:
I am still worried about ppc, and big endian architectures in general. But I don't think we currently have any users there.
we do. I think I'd like to hear Greg Watson's take on this as he is working with the PPC 970 guys and this will impact him.
Ron we have users of the LinxuBIOS table on PPC? It was my impression that we did not.
I would be happy to hear what Greg has to say. If nothing uses this entry I will be happy to change this. Otherwise we need to know what the test program below reports on ppc.
If I can modify the definition to an equivalent one without breaking anything that is my intention. We have just enough users on x86 that anything else involves pain.
cat > test.c << EOF #include <stdint.h> #include <stdio.h> struct lb_memory_range { uint64_t start; uint64_t size; uint32_t type; };
int main(int argc, char **argv) { printf("sizeof(lb_memory_range): %d\n", sizeof(struct lb_memory_range)); return 0; } EOF
gcc -o ./test ./test.c ./test
Eric
On Dec 9, 2004, at 10:49 PM, Eric W. Biederman wrote:
"Ronald G. Minnich" rminnich@lanl.gov writes:
On Thu, 9 Dec 2004, Eric W. Biederman wrote:
I am still worried about ppc, and big endian architectures in general. But I don't think we currently have any users there.
we do. I think I'd like to hear Greg Watson's take on this as he is working with the PPC 970 guys and this will impact him.
Ron we have users of the LinxuBIOS table on PPC? It was my impression that we did not.
I would be happy to hear what Greg has to say. If nothing uses this entry I will be happy to change this. Otherwise we need to know what the test program below reports on ppc.
Nothing uses this currently, but I will be providing support to pass the entire device tree to a payload in the near future. Whether this will be using linuxbios tables, s-expressions or XML depends on the results of the current discussion.
On ppc32, gcc-3.2.2 I get a size of 24. I'll try ppc64 later today.
Greg
On Thu, 9 Dec 2004, Gin wrote:
Linuxbios successfully loads the payload FILO which brings up Linux> kernel. But the kernel hangs while waiting for a timer interrupt. See> below. I guess the interrupt table is not correct.
yes, it's a bad IRQ or MP table or both.
We have tools to extract them from the standard bios, see the util tree.
ron
src/util/getpir builds the IRQ table from the $PIR in memory, but which util extracts the MP table?
Steve
On Fri, 10 Dec 2004, Steve Kimball wrote:
src/util/getpir builds the IRQ table from the $PIR in memory, but which util extracts the MP table?
I've just added the mptable tool from freebios1 to freebios2. It is in util.
I am sending you a private copy in case you are 'cvs delay mode'
ron
On Fri, 2004-12-10 at 09:19, Ronald G. Minnich wrote:
On Fri, 10 Dec 2004, Steve Kimball wrote:
src/util/getpir builds the IRQ table from the $PIR in memory, but which util extracts the MP table?
I've just added the mptable tool from freebios1 to freebios2. It is in util.
I am sending you a private copy in case you are 'cvs delay mode'
Ron,
the mptable utility in freebios v1 has serious bugs. It does not work in 64 bit mode.
Ollie
On Fri, 10 Dec 2004, Li-Ta Lo wrote:
the mptable utility in freebios v1 has serious bugs. It does not work in 64 bit mode.
yes, it needs work, that's for sure.
It may be better than nothing, but I'm not sure. I did use it for several boards so far, however.
ron
Greg Watson gwatson@lanl.gov writes:
On Dec 9, 2004, at 10:49 PM, Eric W. Biederman wrote:
"Ronald G. Minnich" rminnich@lanl.gov writes:
On Thu, 9 Dec 2004, Eric W. Biederman wrote:
I am still worried about ppc, and big endian architectures in general. But I don't think we currently have any users there.
we do. I think I'd like to hear Greg Watson's take on this as he is working with the PPC 970 guys and this will impact him.
Ron we have users of the LinxuBIOS table on PPC? It was my impression that we did not.
I would be happy to hear what Greg has to say. If nothing uses this entry I will be happy to change this. Otherwise we need to know what the test program below reports on ppc.
Nothing uses this currently, but I will be providing support to pass the entire device tree to a payload in the near future. Whether this will be using linuxbios tables, s-expressions or XML depends on the results of the current discussion.
On ppc32, gcc-3.2.2 I get a size of 24. I'll try ppc64 later today.
Thanks. Then I am going to ``fix'' the table definition so it returns a size of 20 even on ppc.
What we do later is still in the air. But at least the current situation can be corrected without a flag day.
Eric
-
ebiederman＠lnxi.com -
Greg Watson -
Li-Ta Lo -
Ronald G. Minnich -
Steve Kimball