With all the interest in the i440bx I pulled out my old hardware and debugged the SMbus reads.
I can now dump the contents of the SPD on my RAM. Yah!! Only took a year or so.
Hopefully the rest can knock out pretty quickly. I'll do some more work tomorrow.
I have discoverd a some _very_ frustrating issues. And I believe I've reported one of these before.
Issue 1:
The dependency chain of the builds is not correct. I spent close to 2 hours trying to figure out why my code was not working when the problem was that my code was not getting recompiled by romcc.
The SPD code is done in a header file. Pehaps this was the 1st mistake but I copied it from the way another project did it.
If you make changes to that header file they are not picked up properly. So some work on dependency info may be in order.
Issue 2:
The build output of LinxBIOS is _way_ too noisy. Its extremely difficult to try and see if the code you are working on actually got recompiled.
We need to work on reducing the noise level.
* Richard Smith smithbone@gmail.com [060730 02:33]:
Issue 1:
The dependency chain of the builds is not correct. I spent close to 2 hours trying to figure out why my code was not working when the problem was that my code was not getting recompiled by romcc.
The SPD code is done in a header file. Pehaps this was the 1st mistake but I copied it from the way another project did it.
If you make changes to that header file they are not picked up properly. So some work on dependency info may be in order.
yes, in the build process auto.inc is only depending on auto.c but in the real world this is not true. To fix this we would probably need to create dependencies with gcc -MM (can we use gcc, or would romcc have to do this? Eric?) I did this dynamically for the flashrom utility a while ago, but for all of LinuxBIOS this would be a major task.
The build output of LinxBIOS is _way_ too noisy. Its extremely difficult to try and see if the code you are working on actually got recompiled.
We need to work on reducing the noise level.
One thing that desperately needs to happen is to pack all the preprocessor macros into a .h file and include it, be it by replacing all of them with a single --include preproc.h.
This has been wasting many hours of my time when the config mechanism decided to calculate some negative offsets that would end up with a compiler line including -DFOO=0x-fff3 leading to really crappy error messages.
The way it is now its a complete waste of time to even look at the compiler warnings. Which has by accident annoyed other people on this list.
Stefan
yes, in the build process auto.inc is only depending on auto.c but in the real world this is not true. To fix this we would probably need to create dependencies with gcc -MM (can we use gcc, or would romcc have to do this? Eric?) I did this dynamically for the flashrom utility a while ago, but for all of LinuxBIOS this would be a major task.
Currently I'm just 'rm'ing auto.inc and auto.c (auto.* actually) in the target as part of my build process. Perhaps thats a good short term fix? Re-generate auto.c every time?
One thing that desperately needs to happen is to pack all the preprocessor macros into a .h file and include it, be it by replacing all of them with a single --include preproc.h.
I've done a bit of work on this. I've tweaked the generated config.py so that outputs all the variables into a file called _board_options.h as #define VAR VALUE.
The problem is that some of those variable strings need to be interperted by the shell to get the right values. And several of them will not pass the compiler as is.
Currently I don't see any method of figureing out what variables are ok for adding to the _board_options.h file.
I was thinking of extending the options.lb file to include a "scope" parameter that indicates if the variable is ok for inclusion in to the _board_options.h file or if it needs to go to the shell and make system.
Any other ideas or perhaps something simpler?
* Richard Smith smithbone@gmail.com [060730 21:29]:
Currently I'm just 'rm'ing auto.inc and auto.c (auto.* actually) in the target as part of my build process. Perhaps thats a good short term fix? Re-generate auto.c every time?
Do you have a patch?
I've done a bit of work on this. I've tweaked the generated config.py so that outputs all the variables into a file called _board_options.h as #define VAR VALUE.
The problem is that some of those variable strings need to be interperted by the shell to get the right values. And several of them will not pass the compiler as is.
Can those be evaluated by the python config script during creation of the script? or into an extra file "dynamic_options.h" during build time?
I guess you are talking about
- gcc version - assembler version - ld version - build time
did i miss anything?
I was thinking of extending the options.lb file to include a "scope" parameter that indicates if the variable is ok for inclusion in to the _board_options.h file or if it needs to go to the shell and make system.
Any other ideas or perhaps something simpler?
If we're talking about the above and nothing that is _board_ or _build_ specific (but only environment specific), lets add an extra include file that is generated at build time (as opposed to configuration time) that probes the build environment and adds those defines.
They are only needed for philosophic reasons anyways: mailinglist support aka "is your compiler broken" and "have I flashed the latest version". This is not "configuration".
the target as part of my build process. Perhaps thats a good short term fix? Re-generate auto.c every time?
Do you have a patch?
All it does is create the file which is pretty easy. Nothing is done with it. So the patch would not be worth much. I'll post up something after I work out the shell variables thing.
Can those be evaluated by the python config script during creation of the script? or into an extra file "dynamic_options.h" during build time?
Probably but I still need some sort of marker that indicates that this particular variable needs post processing. All the variables are in 2 lists and the current code just iterates the list kicking them out. But now we have to be a bit smarter about what variable is what.
I guess you are talking about
- gcc version
- assembler version
- ld version
- build time
did i miss anything?
export ARCH:=i386 export CROSS_COMPILE:= export CC:=$(CROSS_COMPILE)gcc -m32 export HOSTCC:=gcc export OBJCOPY:=$(CROSS_COMPILE)objcopy --gap-fill 0xff
All of these need to be quoted at minimum to not cause compile errors. OBJCOPY needs to continue to get stuck into the makefile properly.
If we're talking about the above and nothing that is _board_ or _build_ specific (but only environment specific), lets add an extra include file that is generated at build time (as opposed to configuration time) that probes the build environment and adds those defines.
I'll see what I can come up with.
* Richard Smith smithbone@gmail.com [060731 05:46]:
Can those be evaluated by the python config script during creation of the script? or into an extra file "dynamic_options.h" during build time?
Probably but I still need some sort of marker that indicates that this particular variable needs post processing. All the variables are in 2 lists and the current code just iterates the list kicking them out. But now we have to be a bit smarter about what variable is what.
Wow. great idea! The complexity this might introduce scares me a bit though.
I think this can be made totally simple and stupid.
dogma 1: build environment is not a linuxbios _configuration_ issue. dogma 2: linuxbios configuration variables can not use shell at all.
I guess you are talking about
- gcc version
- assembler version
- ld version
- build time
did i miss anything?
export ARCH:=i386
Where's the problem with ARCH?
export CROSS_COMPILE:= export CC:=$(CROSS_COMPILE)gcc -m32 export HOSTCC:=gcc export OBJCOPY:=$(CROSS_COMPILE)objcopy --gap-fill 0xff
All of these need to be quoted at minimum to not cause compile errors. OBJCOPY needs to continue to get stuck into the makefile properly.
But none of them is needed within the code of LinuxBIOS, only in the Makefile. I would suggest completely taking them out of the configuration part and put them into the Makefile only.
Like other projects do this, if someone wants another compiler, it can be overridden when calling make. But this should be nothing for LinuxBIOS to care about internally. Nor?
Stefan
-
Richard Smith -
Stefan Reinauer