[U-Boot-Users] PATCH: PCMCIA and PXA250
Hi Woflgang,
Note that I had to change TEXT_ADDRESS for board/wepep250, otherwise the image does not fit in (with IDE, PCMCIA, FAT support). The TEXT_ADDRESS change is as minimal as it can get.
Note that before applying PXA PCMCIA, you need to apply Pierre's patch for IDE.
Can anyone that worked on ARM memory layout confirm that please?
Changes: o PCMCIA support for PXA
Build Report:
U-BOOT TOP BUILD REPORT:
builds that FAILED to build: AR405 ERIC EVAL5200 MPC8540ADS MPC8560ADS
U-BOOT PXA PCMCIA BUILD REPORT: (applied top-pxa-pcmcia patch)
builds that FAILED to build: AR405 ERIC EVAL5200 MPC8540ADS MPC8560ADS U-BOOT PXA PCMCIA BUILD REPORT: (applied top-pxa-pcmcia patch + configuration changes)
builds that FAILED to build: AR405 ERIC EVAL5200 MPC8540ADS MPC8560ADS
Any issues, let me know.
Dear Leon,
in message Pine.LNX.4.44.0403161449080.13005-101000@tt-devel.ultra.si you wrote:
Note that I had to change TEXT_ADDRESS for board/wepep250, otherwise the image does not fit in (with IDE, PCMCIA, FAT support). The TEXT_ADDRESS change is as minimal as it can get.
Thanks. One question: the patch brings in a couple of [Linux] system header files:
include/asm-arm/arch-pxa/io.h include/asm-arm/assembler.h include/asm-arm/io.h include/asm-arm/proc-armv/assembler.h include/linux/linkage.h
and even some assembler code:
lib_arm/io-readsw-armv4.S lib_arm/io-writesw-armv4.S
Do we _really_ need all these header files? At first glance I think it should be possible to without most of them. Also, the assembler files seem to be pulled in for ALL ARM boards?
Can you please check and verify that we really _need_ all this stuff?
Thanks.
Best regards,
Wolfgang Denk
Hi Wolfgang,
Thanks. One question: the patch brings in a couple of [Linux] system header files:
[ - snip - ]
and even some assembler code:
[ - snip - ]
Do we _really_ need all these header files? At first glance I think it should be possible to without most of them. Also, the assembler files seem to be pulled in for ALL ARM boards?
Can you please check and verify that we really _need_ all this stuff?
I'm not saying that I'm right, but here's my philosophy:
U-Boot uses Linux system header file or at least a portion of it. If I copy a portion of a Linux system header file and put it somewhere inside U-Boot I automaticaly loose the track of it. If I copy the whole file and put it at the same place then I can do diffs with Linux header file and the track is there - it's the same file. A header file will most likelky contain only macros and will not affect the image size at all.
That's my view, please let me know if you really want me to "hack" around this, remove the header files and put defines where they're needed.
About the lib_arm/ and assembly files. lib_arm is an archive. The boards that don't need __raw_readsw and __raw_writesw won't have it. It's an archive - object wont get linked if the symbol is not needed. I did MAKEALL for all the boards that are there and none of the build fails (except for those that fail in the -top-cvs too)
Let me know your thoughts,
Dear Leon,
in message 1080119893.1411.18.camel@tt-devel.ultra.si you wrote:
Can you please check and verify that we really _need_ all this stuff?
I'm not saying that I'm right, but here's my philosophy:
U-Boot uses Linux system header file or at least a portion of it.
The question is if we use a significant part of such a Linux header file or just 5 lines of definitions.
If I copy a portion of a Linux system header file and put it somewhere inside U-Boot I automaticaly loose the track of it. If I copy the whole file and put it at the same place then I can do diffs with Linux header file and the track is there - it's the same file. A header file will most likelky contain only macros and will not affect the image size at all.
I agree.
But I have seen many cases where a header file was pulled in for a 2 line macro definition, and the inclusin of this header file required 3 others to be added also, which in turn required another 5 or 6 header files.
That's my view, please let me know if you really want me to "hack" around this, remove the header files and put defines where they're needed.
That depends on how much you need. If it is a significant part of the Linux header file, then go for it. Otherwise just extract the relevant definitions.
And if the Linux header file depends on other headers, please check if these are required for your stuff, or only for other things you don't need. Often it's easy to add and to keep track of a few "#if 0" / "#endif" lines in a file to eliminate such references for stuff that is irrelevant to U-Boot.
About the lib_arm/ and assembly files. lib_arm is an archive. The boards that don't need __raw_readsw and __raw_writesw won't have it. It's an archive - object wont get linked if the symbol is not needed. I did MAKEALL for all the boards that are there and none of the build fails (except for those that fail in the -top-cvs too)
But we pull in 200 lines of code for 16 lines we need.
I don't want to add too many things that we don't actually use. People start to turn away from U-Boot when they see that the compressed tarball is 4 MB / uncompressed 26 MB. This is a LOT for just a boot loader.
Best regards,
Wolfgang Denk
Dear Leon,
in message Pine.LNX.4.44.0403161449080.13005-101000@tt-devel.ultra.si you wrote:
Changes: o PCMCIA support for PXA
Please resubmit your patch after removing trailing white space from your files.
Please also make the new header files idempotent. Affected are at least:
include/asm-arm/arch-pxa/wep-ep250.h include/asm-arm/assembler.h
Regarding include/asm-arm/assembler.h: U-Boot will never #define "__ARMEB__" or "__LINUX_ARM_ARCH__", so why do we need these definitions here?
What is include/asm-arm/proc-armv/assembler.h needed for? What do we need include/linux/linkage.h for? What do we need lib_arm/io-readsw-armv4.S for? What do we need lib_arm/io-writesw-armv4.S for?
In general, please restrict the number of new created files to the absolute minimum.
Best regards,
Wolfgang Denk
participants (2)
-
Leon KUKOVEC -
Wolfgang Denk