RE: [U-Boot-Users] u-boot and NIOS dk 1s10 board
Hi All,
I agree with all of the comments I have seen so far WRT Nios configuration issues. My primary motivation is to make sure Nios users new to u-boot, can build a __working__ version of u-boot by simply:
$ make DK1C20_config | DK1S10_config | etc. $ make
As long as this holds true, I'm happy :-)
Yes, of course. We have to make different configuration files -- one for each board. But, do we really need different board directories with almost the same code in it?
u-boot has a clever mechanism we can use to avoid code duplication by using the VENDOR make variable. A good example is in board/siemens: the SCM and CCM boards both share common code.
Since this mechanism is supported ... and it is being used by other board families, we can do the same. It's a bit more work ... but I believe it will satisfy everyone :-)
Ex.: My current Stratix patch is based on the Cyclone board, because both boards are equal in context of u-boot basics need. Only the second serial i/f differs (not needed til now). So there will be more identicalness than differences for both boards.
Understood. We can create board/altera_nios (or some other meaningful name) and take advantage of the VENDOR variable to accommodate common code. Stephen & Patrice, please let me know your thoughts.
Best Regards, --Scott
Am Dienstag, 18. November 2003 15:13 schrieb Scott McNutt:
Hi All,
I agree with all of the comments I have seen so far WRT Nios configuration issues. My primary motivation is to make sure Nios users new to u-boot, can build a __working__ version of u-boot by simply:
$ make DK1C20_config | DK1S10_config | etc. $ makeAs long as this holds true, I'm happy :-)
Yes, right.
Yes, of course. We have to make different configuration files -- one for each board. But, do we really need different board directories with almost the same code in it?
u-boot has a clever mechanism we can use to avoid code duplication by using the VENDOR make variable. A good example is in board/siemens: the SCM and CCM boards both share common code.
Sounds interesting. I will spend some time on it next weekend.
Since this mechanism is supported ... and it is being used by other board families, we can do the same. It's a bit more work ... but I believe it will satisfy everyone :-)
Ex.: My current Stratix patch is based on the Cyclone board, because both boards are equal in context of u-boot basics need. Only the second serial i/f differs (not needed til now). So there will be more identicalness than differences for both boards.
Understood. We can create board/altera_nios (or some other meaningful name) and take advantage of the VENDOR variable to accommodate common code. Stephen & Patrice, please let me know your thoughts.
Hmm, sounds good to me. More comments next week. I have to look up the VENDOR make mechanism and play with it. I don't know more about it.
br, Stephan
In message 03111816211506.23084@pcj86 you wrote:
u-boot has a clever mechanism we can use to avoid code duplication by using the VENDOR make variable. A good example is in board/siemens: the SCM and CCM boards both share common code.
Sounds interesting. I will spend some time on it next weekend.
Another option is to pass configuration options from the Makefile. See for example how CPU type, core frequency, availability of L2 cache and bus mode are handled for the TQM82xx boards.
Best regards,
Wolfgang Denk
Am Dienstag, 18. November 2003 16:49 schrieb Wolfgang Denk:
In message 03111816211506.23084@pcj86 you wrote:
u-boot has a clever mechanism we can use to avoid code duplication by using the VENDOR make variable. A good example is in board/siemens: the SCM and CCM boards both share common code.
Sounds interesting. I will spend some time on it next weekend.
Another option is to pass configuration options from the Makefile. See for example how CPU type, core frequency, availability of L2 cache and bus mode are handled for the TQM82xx boards.
Yes, I know about because of my last few PPC projects, but I think there are to many options for a NIOS board. We have to configure whole CPU functionality (not only a board). I'll compare both ways.
br, Stephan
In message 03111908361707.23084@pcj86 you wrote:
Yes, I know about because of my last few PPC projects, but I think there are to many options for a NIOS board. We have to configure whole CPU functionality (not only a board). I'll compare both ways.
You can also set "board ID's" which then select blocks of definitions or sub-includes. See for example the PPChameleon board (not that I like the names used there much).
Best regards,
Wolfgang Denk
Am Mittwoch, 19. November 2003 10:01 schrieb Wolfgang Denk:
In message 03111908361707.23084@pcj86 you wrote:
Yes, I know about because of my last few PPC projects, but I think there are to many options for a NIOS board. We have to configure whole CPU functionality (not only a board). I'll compare both ways.
You can also set "board ID's" which then select blocks of definitions or sub-includes. See for example the PPChameleon board (not that I like the names used there much).
Hmm, that could be interesting for different board revisions like Stratix -- til now I know about two different board revisions (1S10 and 1S40). So it could be necessary to distinguish between the revisions by using a board ID.
Another question. Where just can I find the so named "board ID" in PPChameleon configuration flow? Do you meaning the CONFIG_PPCHAMELEON_MODULE_MODEL define?
br, Stephan Linz
In message 0311191037040A.23084@pcj86 you wrote:
Another question. Where just can I find the so named "board ID" in PPChameleon configuration flow? Do you meaning the CONFIG_PPCHAMELEON_MODULE_MODEL define?
Yes. The PPChameleon EVB (Eval board) comes in 3 configurations: "BA" (=basic), "ME" (=medium), and "HI" (= high end).
Best regards,
Wolfgang Denk
participants (3)
-
Scott McNutt -
Stephan Linz -
Wolfgang Denk