Ron mentioned he had strange hangs in pll_reset on various targets. This may be due to miscompilation of XIP objects which do not have _MAINBOBJECT defined. This issue was impossible to see on qemu because no such object existed. Introduce initram_printktest.c in the Qemu target, which will test for miscompilation and crash with a descriptive error message.
This has been build tested and runtime tested on Qemu, and with my compiler/linker combination it indeed crashes. gcc (GCC) 4.2.1 (SUSE Linux) GNU ld (GNU Binutils) 2.17.50.20070726-14 (SUSE Linux)
Trying with gcc-4.1 (GCC) 4.1.3 20070724 (prerelease) (SUSE Linux) and the linker above had exactly the same results.
Unless we manage to fix the bug uncovered by this patch, leaving the Qemu target in crashing state is the best thing we can do because this behaviour mirrors the state of all other targets.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
(don't forget "svn add ainboard/emulation/qemu-x86/initram_printktest.c" if you commit)
Index: LinuxBIOSv3-xiptest/mainboard/emulation/qemu-x86/initram.c =================================================================== --- LinuxBIOSv3-xiptest/mainboard/emulation/qemu-x86/initram.c (Revision 532) +++ LinuxBIOSv3-xiptest/mainboard/emulation/qemu-x86/initram.c (Arbeitskopie) @@ -2,6 +2,7 @@ * This file is part of the LinuxBIOS project. * * Copyright (C) 2007 Stefan Reinauer stepan@coresystems.de + * Copyright (C) 2007 Carl-Daniel Hailfinger * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -21,6 +22,8 @@
#include <console.h>
+int printktest(void); + /* printktest1() is here to increase the likelihood of main() not ending up at * the beginning of the file, so we can check whether the entry point at main() * was honored. @@ -39,6 +42,9 @@ printk(BIOS_INFO, "RAM init code started.\n"); printk(BIOS_INFO, "Nothing to do.\n"); printktest1(); + printk(BIOS_INFO, "Trying absolute call from non-_MAINOBJECT XIP code.\n"); + printktest(); + printk(BIOS_INFO, "Done.\n");
return 0; } Index: LinuxBIOSv3-xiptest/mainboard/emulation/qemu-x86/initram_printktest.c =================================================================== --- LinuxBIOSv3-xiptest/mainboard/emulation/qemu-x86/initram_printktest.c (Revision 0) +++ LinuxBIOSv3-xiptest/mainboard/emulation/qemu-x86/initram_printktest.c (Revision 0) @@ -0,0 +1,31 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2007 Carl-Daniel Hailfinger + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include <console.h> + +int printktest(void) +{ + /* If printk succeeds, it will print the message below. This is not a + * success message after a test, but a success message used as test. + * In case of compiler/linker bugs the printk call is likely to crash. + */ + printk(BIOS_INFO, "Absolute call successful.\n"); + + return 0; +} Index: LinuxBIOSv3-xiptest/mainboard/emulation/qemu-x86/Makefile =================================================================== --- LinuxBIOSv3-xiptest/mainboard/emulation/qemu-x86/Makefile (Revision 532) +++ LinuxBIOSv3-xiptest/mainboard/emulation/qemu-x86/Makefile (Arbeitskopie) @@ -40,5 +40,6 @@ # directory and is built from what was auto.c in v2. #
-INITRAM_OBJ = $(obj)/mainboard/$(MAINBOARDDIR)/initram.o +INITRAM_OBJ = $(obj)/mainboard/$(MAINBOARDDIR)/initram.o \ + $(obj)/mainboard/$(MAINBOARDDIR)/initram_printktest.o
On 30.11.2007 18:35, Carl-Daniel Hailfinger wrote:
Ron mentioned he had strange hangs in pll_reset on various targets. This may be due to miscompilation of XIP objects which do not have _MAINBOBJECT defined. This issue was impossible to see on qemu because no such object existed. Introduce initram_printktest.c in the Qemu target, which will test for miscompilation and crash with a descriptive error message.
This has been build tested and runtime tested on Qemu, and with my compiler/linker combination it indeed crashes. gcc (GCC) 4.2.1 (SUSE Linux) GNU ld (GNU Binutils) 2.17.50.20070726-14 (SUSE Linux)
Trying with gcc-4.1 (GCC) 4.1.3 20070724 (prerelease) (SUSE Linux) and the linker above had exactly the same results.
Unless we manage to fix the bug uncovered by this patch, leaving the Qemu target in crashing state is the best thing we can do because this behaviour mirrors the state of all other targets.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
(don't forget "svn add mainboard/emulation/qemu-x86/initram_printktest.c" if you commit)
Ack anyone? I have another patch which fixes the bug revealed by this patch, but I want to commit them in separate steps to make it more obvious that one patch points out the problem, and one is a possible solution.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 30.11.2007 18:35, Carl-Daniel Hailfinger wrote:
Ron mentioned he had strange hangs in pll_reset on various targets. This may be due to miscompilation of XIP objects which do not have _MAINBOBJECT defined. This issue was impossible to see on qemu because no such object existed. Introduce initram_printktest.c in the Qemu target, which will test for miscompilation and crash with a descriptive error message.
This has been build tested and runtime tested on Qemu, and with my compiler/linker combination it indeed crashes. gcc (GCC) 4.2.1 (SUSE Linux) GNU ld (GNU Binutils) 2.17.50.20070726-14 (SUSE Linux)
Trying with gcc-4.1 (GCC) 4.1.3 20070724 (prerelease) (SUSE Linux) and the linker above had exactly the same results.
Unless we manage to fix the bug uncovered by this patch, leaving the Qemu target in crashing state is the best thing we can do because this behaviour mirrors the state of all other targets.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
(don't forget "svn add mainboard/emulation/qemu-x86/initram_printktest.c" if you commit)
Ack anyone? I have another patch which fixes the bug revealed by this patch, but I want to commit them in separate steps to make it more obvious that one patch points out the problem, and one is a possible solution.
Regards, Carl-Daniel
I think this is rather an experiment and should not be committed in this way. It's not a functionality of LinuxBIOS. Do we really need this?
Stefan
On 01.12.2007 13:10, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 30.11.2007 18:35, Carl-Daniel Hailfinger wrote:
Ron mentioned he had strange hangs in pll_reset on various targets. This may be due to miscompilation of XIP objects which do not have _MAINBOBJECT defined. This issue was impossible to see on qemu because no such object existed. Introduce initram_printktest.c in the Qemu target, which will test for miscompilation and crash with a descriptive error message.
This has been build tested and runtime tested on Qemu, and with my compiler/linker combination it indeed crashes. gcc (GCC) 4.2.1 (SUSE Linux) GNU ld (GNU Binutils) 2.17.50.20070726-14 (SUSE Linux)
Trying with gcc-4.1 (GCC) 4.1.3 20070724 (prerelease) (SUSE Linux) and the linker above had exactly the same results.
Unless we manage to fix the bug uncovered by this patch, leaving the Qemu target in crashing state is the best thing we can do because this behaviour mirrors the state of all other targets.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
(don't forget "svn add mainboard/emulation/qemu-x86/initram_printktest.c" if you commit)
Ack anyone? I have another patch which fixes the bug revealed by this patch, but I want to commit them in separate steps to make it more obvious that one patch points out the problem, and one is a possible solution.
Regards, Carl-Daniel
I think this is rather an experiment and should not be committed in this way. It's not a functionality of LinuxBIOS. Do we really need this?
If you want to boot v3 on any hardware target, yes. The reason Ron is seeing crashes in pll_reset is exactly the same reason why this patch causes a crash as well. Basically, we not only use the wrong compiler options for initram, we also use the wrong linker options for initram. Both happen to work by accident in combination, but only for the Qemu target. Once the patch is applied, Qemu behaviour mirrors hardware target behaviour.
Oh, and btw, the gcc behaviour we depend on is undocumented and partially undefined and may change with the moon phase. The patch actually gives us a chance to verify later that gcc did what we wanted. And yes, i have code for that as well. But committing just the "fix" without the Qemu target modifications leaves those testing with real hardware with heavy problems once the "fix" is no enough anymore to invoke moon-phase-dependent behaviour of gcc.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
If you want to boot v3 on any hardware target, yes. The reason Ron is seeing crashes in pll_reset is exactly the same reason why this patch causes a crash as well. Basically, we not only use the wrong compiler options for initram, we also use the wrong linker options for initram. Both happen to work by accident in combination, but only for the Qemu target. Once the patch is applied, Qemu behaviour mirrors hardware target behaviour.
Why do you say the linker and compiler options are wrong? Sounds like magic. Mind to share an explanation or a fix for the less enlighted ;-))
Oh, and btw, the gcc behaviour we depend on is undocumented and partially undefined and may change with the moon phase.
Oh sure. But its not the moon phase, people probably sit there and have good ideas and valid reasons for their changes. As we had when choosing that set of compiler options. We just have a little communication problem here.
As I mentioned since the time this was first discussed: The clean way of solving the inter-stage function calls is with a function pointer array at a fixed position in the bootblock, defining a fixed API.
The patch actually gives us a chance to verify later that gcc did what we wanted.
How is that? In what cases do we have to do that verification?
Maybe we can build that test into the build system, namely xcompile? Maybe a stripped down test that can automatically be analyzed? Then we could warn about "broken" toolchains.
We will be facing problems with tool chains until we grow old and gray. These compilers are just not made for writing firmware. Nor did anyone writing them ever have firmware in mind. In fact, they tend to be wonderful for writing Linux userspace applications. Most of the time. For what we do, those tools are usually too smart. They don't just compile and link but take estimates on our intentions. We need to learn to talk our problems to the gcc community and have their input. Or we change our architecture so that such problems just don't appear.
All the best,
Stefan
I am comfortable with this. If hardware is broken, qemu should be broken. I avidly wait the fix :-)
Acked-by: Ronald G. Minnich rminnich@gmail.com
On 01.12.2007 18:24, ron minnich wrote:
I am comfortable with this. If hardware is broken, qemu should be broken. I avidly wait the fix :-)
Acked-by: Ronald G. Minnich rminnich@gmail.com
Thanks, r535.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
ron minnich -
Stefan Reinauer