Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, November 06, 2010 8:35 AM To: Nishanth Menon Cc: u-boot@lists.denx.de; Koen Kooi Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table [snip] Note that for 36xx my patch sets the max to 720 -- this is because mainline/linux-omap currently does not support 1000. We can adjust that when kernel support for 1000 appears. [sp] 720MHz is not a valid frequency for 36x. It is the highest freq for OMAP35x - subject to associated bit set in the silicon. 600MHz would be be safe for all OMAP35x family processors. For 36xx, the freq should be 800MHz (if you don't want 1GHz). [snip] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] RFC: Aligning arch initialisation sequences
Hi All, I've been looking at how x86 does things compared to other arches, and it seems to have one big difference - Very little is initialised prior to relocation. The general order for x86 is: - ultra-low level board initialisation - DRAM controller initialisation - DRAM sizing - low-level board initialisation - Relocation - init_sequence[] (including timers, serial console Now ARM, m68k and PPC all call relocate_code well after init_sequence[] Now I'm wondering if I should change x86 to align with these other arch's. I think it can be done, but there are a few technicalities that make it a non-trival task. Two big problems I foresee are timers and the global data pointer. Timers for x86 use interrupts which use function hooks for the interrupt handlers - I can change all the call-back functions to use global data, and I will have to 're-hook' the call-back functions after relocation. The global data pointer is worse - x86 does not have a spare register to effectively use as a global variable. I would have to do all sorts of trickery probably involving putting the global data pointer at the very top of the stack segment and doing some very fancy shuffling of registers which will make global data suffer a pretty severe performance hit. On the other hand, if I leave things the way they are, there is beauty to be uncovered in board_init_r() - At the moment, board_init_r() consists of the init_sequence[] loop, followed by a whole raft of function calls wrapped around #idefs. That whole mess could all be converted to a unified init_sequence[]. Along with current discussions on weak functions, I think this might be a cleaner solution. So the question is, what does everyone think I should do? Should all architectures strive to look as much like one another as possible? Should we accept that maybe this particular issue be thrown in the too hard basket? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from library archives to partial linking
On Sat, 2010-11-06 at 18:21 +0100, Albert ARIBAUD wrote: Le 06/11/2010 15:28, Sebastien Carlier a écrit : Hello all, My previous patch missed some places that create library archives. A new 100% $(AR)-free version is available here: http://io.oiioiio.com/~sebc/0001-Use-partial-linking-v2.patch I have tested this patch with MAKEALL -A arm and checked that it does not break any build on this architecture. I have not yet tested the resulting binaries, but in theory they should work. :-) Feedback on other architectures is also welcome. For a few boards (balloon3, palmld, palmtc, pleb2, zipitz2) that disable CONFIG_CMD_NET, this patch also disables CONFIG_CMD_NFS to prevent net/nfs.o from being compiled and causing undefined symbols. I guess if this patch is ready to be pulled in a git repo, you should submit it using git format-patch / git send-email, ideally as a patchset with each patch dealing with one lib, because clearly each ex-library will require its own set of custodian ack(s), thus require its own patch in the set. You shouldn't need to send the patch using git send-email. The patch is greater than U-Boot's mailing list limit (100k) and posting the patch on a website is perfectly acceptable. Also, it shouldn't be necessary to split the patch into each separate patch's to address each lib. It'd be a lot of work on Sebastien's part to do this and not break bisection, and most maintainers can either ack this patch, or probably don't need to since its more of a build change, not low-level change that a maintainer has insight into. I had a couple of comments though: - You need to add your Signed-of-by: line to the patch. - A patch description illustrating why this approach is better than the current approach would be appreciated. - You shouldn't be making changes to stuff like CONFIG_CMD_NFS in this patch. Its unrelated, and should be dealt with in another patch. eg your patches could be: 1/2: Fix boards with CONFIG_CMD_NFS but !CONFIG_CMD_NET 2/2: Switch from library archives to partial linking I just tried compiling for PowerPC and ran into this: Configuring for cmi_mpc5xx board... net/libnet.o: In function `rpc_req': /home/ptyser/u-boot/u-boot/net/nfs.c:193: undefined reference to `NetEthHdrSize' /home/ptyser/u-boot/u-boot/net/nfs.c:202: undefined reference to `NetSendUDPPacket' net/libnet.o: In function `NfsStart': /home/ptyser/u-boot/u-boot/net/nfs.c:741: undefined reference to `NetSetTimeout' /home/ptyser/u-boot/u-boot/net/nfs.c:742: undefined reference to `NetSetHandler' net/libnet.o: In function `NfsHandler': /home/ptyser/u-boot/u-boot/net/nfs.c:656: undefined reference to `NetSetTimeout' net/libnet.o: In function `NfsTimeout': /home/ptyser/u-boot/u-boot/net/nfs.c:574: undefined reference to `NetStartAgain' /home/ptyser/u-boot/u-boot/net/nfs.c:577: undefined reference to `NetSetTimeout' net/libnet.o:(.got2+0x8): undefined reference to `NetTxPacket' net/libnet.o:(.got2+0xc): undefined reference to `NetServerEther' net/libnet.o:(.got2+0x18): undefined reference to `NetServerIP' net/libnet.o:(.got2+0x1c): undefined reference to `BootFile' net/libnet.o:(.got2+0x20): undefined reference to `NetOurIP' net/libnet.o:(.got2+0x30): undefined reference to `NetOurGatewayIP' net/libnet.o:(.got2+0x34): undefined reference to `NetOurSubnetMask' net/libnet.o:(.got2+0x40): undefined reference to `NetBootFileSize' net/libnet.o:(.got2+0x64): undefined reference to `NetState' net/libnet.o:(.got2+0x7c): undefined reference to `NetBootFileXferSize' make: *** [u-boot] Error 1 powerpc-linux-size: './u-boot': No such file I'm guessing lots of boards will have this same issue. I imagine its due to include/config_cmd_defaults.h, so maybe if you fix the issue in that one place all the compile issues will go away. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from library archives to partial linking
Dear Peter, On 11/07/2010 03:16 PM, Peter Tyser wrote: You shouldn't need to send the patch using git send-email. The patch is greater than U-Boot's mailing list limit (100k) and posting the patch on a website is perfectly acceptable. Also, it shouldn't be necessary to split the patch into each separate patch's to address each lib. It'd be a lot of work on Sebastien's part to do this and not break bisection, and most maintainers can either ack this patch, or probably don't need to since its more of a build change, not low-level change that a maintainer has insight into. That makes a lot of sense. I had a couple of comments though: - You need to add your Signed-of-by: line to the patch. Okay. As you may have guessed, I am a first-time git user. - A patch description illustrating why this approach is better than the current approach would be appreciated. Will do. - You shouldn't be making changes to stuff like CONFIG_CMD_NFS in this patch. Its unrelated, and should be dealt with in another patch. eg your patches could be: 1/2: Fix boards with CONFIG_CMD_NFS but !CONFIG_CMD_NET 2/2: Switch from library archives to partial linking Sounds good, will do. I'm guessing lots of boards will have this same issue. I imagine its due to include/config_cmd_defaults.h, so maybe if you fix the issue in that one place all the compile issues will go away. The generic fix is to include the following lines somewhere at the end of the config.h generated in the mkconfig script: #ifndef CONFIG_CMD_NET # undef CONFIG_CMD_NFS #endif These lines should probable be put in a new header file; would config_checks.h be an ok name for it? I suppose there might be other cases where a module (that is included by default) needs to be excluded when one of its dependencies is disabled. Regards, Sebastien Carlier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from library archives to partial linking
Dear Sebastien Carlier, Am 07.11.2010 um 16:11 schrieb Sebastien Carlier: Dear Peter, On 11/07/2010 03:16 PM, Peter Tyser wrote: - You shouldn't be making changes to stuff like CONFIG_CMD_NFS in this patch. Its unrelated, and should be dealt with in another patch. eg your patches could be: 1/2: Fix boards with CONFIG_CMD_NFS but !CONFIG_CMD_NET 2/2: Switch from library archives to partial linking Sounds good, will do. I'm guessing lots of boards will have this same issue. I imagine its due to include/config_cmd_defaults.h, so maybe if you fix the issue in that one place all the compile issues will go away. The generic fix is to include the following lines somewhere at the end of the config.h generated in the mkconfig script: #ifndef CONFIG_CMD_NET # undef CONFIG_CMD_NFS #endif These lines should probable be put in a new header file; would config_checks.h be an ok name for it? I suppose there might be other cases where a module (that is included by default) needs to be excluded when one of its dependencies is disabled. I guess the boards are broken before your library changes too. So yes you need to split these patches. But two points regarding your described approach. - The respective boards need a fix, if they do (conditionally) disable CMD_NET and miss CMD_NFS it is their fault and the respective boards config should be fixed - The build for net commands need a fix if they will build NFS stuff without NET stuff I dunno if it is required to have some config_checks.h, this may grow up to unexpected complexity. regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Standalone API
Hi, Is there a list, or header file containing prototypes of the U-Boot facilities that a standalone can make use of ? If so can somebody please direct me to it Regards, Andrew P.S. Also can somebody just responds anyway as a test. I'm not sure that my messages are getting out there. = Andrew Holt Senior Software Engineer Email: andrew.h...@electrans.com De Omnibus Dubitandum = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Standalone API
From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Andrew Holt (SE) Is there a list, or header file containing prototypes of the U-Boot facilities that a standalone can make use of ? If so can somebody please direct me to it Regards, Andrew P.S. Also can somebody just responds anyway as a test. I'm not sure that my messages are getting out there. Did you read doc/README.standalone? DaR ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from library archives to partial linking
Dear Andreas, On 11/07/2010 04:30 PM, Andreas Bießmann wrote: I guess the boards are broken before your library changes too. The boards in question do actually build with library archives. The final binary does not make use of the NFS stuff, therefore the linker does not need to resolve the undefined symbols in it. So yes you need to split these patches. Understood, I will post separate patches. But two points regarding your described approach. - The respective boards need a fix, if they do (conditionally) disable CMD_NET and miss CMD_NFS it is their fault and the respective boards config should be fixed The boards unconditionally disable CMD_NET and miss CMD_NFS. Although this is not a meaningful configuration, it used to build... - The build for net commands need a fix if they will build NFS stuff without NET stuff It is possible for net/Makefile to disable all modules if CMD_NET is disabled. I do not know if this is desirable, because it would allow situations where the C code believes that some features will be included and the build system does something else. It seems better to ensure consistency at the board config level, since autoconf.mk is automatically generated from that. I dunno if it is required to have some config_checks.h, this may grow up to unexpected complexity. How are dependencies between u-boot modules handled currently? Are they documented or available in any form that could be used to automatically check that a configuration is meaningful? Best regards, Sebastien Carlier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from library archives to partial linking
Dear Sebastien Carlier, Am 07.11.2010 um 17:18 schrieb Sebastien Carlier: Dear Andreas, On 11/07/2010 04:30 PM, Andreas Bießmann wrote: I guess the boards are broken before your library changes too. The boards in question do actually build with library archives. The final binary does not make use of the NFS stuff, therefore the linker does not need to resolve the undefined symbols in it. I see .. so I guess the build system for net should be fixed. But two points regarding your described approach. - The respective boards need a fix, if they do (conditionally) disable CMD_NET and miss CMD_NFS it is their fault and the respective boards config should be fixed The boards unconditionally disable CMD_NET and miss CMD_NFS. Although this is not a meaningful configuration, it used to build... Indeed this configuration makes no sense but the information let NFS stuff out is implicit, isn't it? To get your new linking fixed to work with this configuration you could introduce a new 'check service' to fixup those situations. But I think this should be fixed in the makefiles for net. And with that point of view those changes could go into the same patch which does the new linking. Cause you do not fixup boards to get them built but you make your linking more robust. - The build for net commands need a fix if they will build NFS stuff without NET stuff It is possible for net/Makefile to disable all modules if CMD_NET is disabled. In my eyes this is the better way to go for your concrete issue, but please let some others comment. I'm a fairly new contributor to u-boot and do not know about those questions. This is only my point of view. regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table
On Sun, Nov 7, 2010 at 6:56 AM, Nishanth Menon menon.nisha...@gmail.com wrote: Premi, Sanjeev wrote, on 11/07/2010 03:16 AM: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, November 06, 2010 8:35 AM To: Nishanth Menon Cc: u-boot@lists.denx.de; Koen Kooi Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table [snip] Note that for 36xx my patch sets the max to 720 -- this is because mainline/linux-omap currently does not support 1000. We can adjust that when kernel support for 1000 appears. [sp] 720MHz is not a valid frequency for 36x. It is the highest freq for OMAP35x - subject to associated bit set in the silicon. 600MHz would be be safe for all OMAP35x family processors. For 36xx, the freq should be 800MHz (if you don't want 1GHz). yep, Good catch :) , 720 is not valid either 800/1GHz :( Thanks for pointing out that I can go up to 800 Mhz. For the record, on my 3730 based system, using: Linux version 2.6.36 (st...@build.sakoman.com) (gcc version 4.3.3 (GCC) ) #1 Thu Nov 4 21:19:18 PDT 2010 The kernel reports the processor as: OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) I tried mpurate settings of 720, 800, and 1000. Though you say it is not valid, an mpurate setting of 720 is successful and yields: Switched to new clocking rate (Crystal/Core/MPU): 26.0/720/359 MHz An mpurate setting of 800 is successful and yields: Switched to new clocking rate (Crystal/Core/MPU): 26.0/800/359 MHz An mpurate setting of 1000 is not successful and yields: WARNING: at arch/arm/mach-omap2/clock.c:440 omap2_clk_switch_mpurate_at_boot+0x80/0xb4() clock: dpll1_ck: unable to set MPU rate to 1000: -22 I will resubmit the patch changing to 800 for 36XX/37XX. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/2] at91rm9200ek: add configure target for RAM boot
This patch also removes now unnecessary config.mk in board directory and make usage of new features in boards.cfg. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- changes since v1: - add MAKEALL target - move settings from boards.cfg to i/c/at91rm9200ek.h changes since v2: - remove MAKEALL stuff from this patch changes since v3: - fix RAMBOOT address - based on top of 7d44af08b823b9f83e328a4bc2192ab7cbb31e9a u-boot-atmel/at91 board/atmel/at91rm9200ek/config.mk |2 -- boards.cfg |3 ++- include/configs/at91rm9200ek.h | 14 ++ 3 files changed, 16 insertions(+), 3 deletions(-) delete mode 100644 board/atmel/at91rm9200ek/config.mk diff --git a/board/atmel/at91rm9200ek/config.mk b/board/atmel/at91rm9200ek/config.mk deleted file mode 100644 index c7323fe..000 --- a/board/atmel/at91rm9200ek/config.mk +++ /dev/null @@ -1,2 +0,0 @@ -# currently only NOR flash booting is supported -CONFIG_SYS_TEXT_BASE = 0x1000 diff --git a/boards.cfg b/boards.cfg index 6c2a667..6f7dc54 100644 --- a/boards.cfg +++ b/boards.cfg @@ -359,7 +359,8 @@ modnet50arm arm720t lpc2292sodimm arm arm720t - - lpc2292 eb_cpux9k2 arm arm920t - BuS at91 at91rm9200dk arm arm920t - atmel at91rm9200 -at91rm9200ek arm arm920t - atmel at91 +at91rm9200ek arm arm920t at91rm9200ekatmel at91 at91rm9200ek +at91rm9200ek_ram arm arm920t at91rm9200ekatmel at91at91rm9200ek:RAMBOOT sbc2410x arm arm920t - - s3c24x0 smdk2400 arm arm920t - samsung s3c24x0 smdk2410 arm arm920t - samsung s3c24x0 diff --git a/include/configs/at91rm9200ek.h b/include/configs/at91rm9200ek.h index 14559f5..ba2e9d3 100644 --- a/include/configs/at91rm9200ek.h +++ b/include/configs/at91rm9200ek.h @@ -33,6 +33,20 @@ #include asm/sizes.h /* + * set some initial configurations depending on configure target + * + * at91rm9200ek_config - boot from 0x0 in NOR Flash at CS0 + * at91rm9200ek_ram_config - continue booting from 0x2010 in RAM; lowlevel + *initialisation was done by some preloader + */ +#ifdef CONFIG_RAMBOOT +#define CONFIG_SKIP_LOWLEVEL_INIT +#define CONFIG_SYS_TEXT_BASE 0x2010 +#else +#define CONFIG_SYS_TEXT_BASE 0x1000 +#endif + +/* * AT91C_XTAL_CLOCK is the frequency of external xtal in hertz * AT91C_MAIN_CLOCK is the frequency of PLLA output * AT91C_MASTER_CLOCK is the peripherial clock -- 1.7.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/2] MAKEALL: fix AT91
* add boards_by_soc()
* remove boards already in boards.cfg from LIST_AT91
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---
introduced in v3
changes since v3:
- none
- based on top of 7d44af08b823b9f83e328a4bc2192ab7cbb31e9a u-boot-atmel/at91
MAKEALL | 18 +++---
1 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index c54c6e8..1b21df6 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -181,6 +181,7 @@ boards_by_field()
}
boards_by_arch() { boards_by_field 2 $@ ; }
boards_by_cpu() { boards_by_field 3 $@ ; }
+boards_by_soc() { boards_by_field 6 $@ ; }
#
## MPC5xx Systems
@@ -433,11 +434,8 @@ LIST_ARMV7= \
## AT91 Systems
#
-LIST_at91=\
- afeb9260\
- at91cap9adk \
- at91rm9200dk\
- at91rm9200ek\
+LIST_at91=$(boards_by_soc at91)\
+ $(boards_by_soc at91rm9200)\
at91sam9260ek \
at91sam9261ek \
at91sam9263ek \
@@ -445,19 +443,9 @@ LIST_at91=\
at91sam9g20ek \
at91sam9m10g45ek\
at91sam9rlek\
- cmc_pu2 \
CPUAT91 \
CPU9260 \
CPU9G20 \
- csb637 \
- eb_cpux9k2 \
- kb9202 \
- meesc \
- mp2usb \
- m501sk \
- otc570 \
- pm9261 \
- pm9263 \
pm9g45 \
SBC35_A9G20 \
TNY_A9260 \
--
1.7.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table
Steve Sakoman wrote, on 11/07/2010 11:00 AM: Though you say it is not valid, an mpurate setting of 720 is successful and yields: Switched to new clocking rate (Crystal/Core/MPU): 26.0/720/359 MHz this should be reported to linux-omap for a fix - unless someone has made some assumption in kernel.org that frequency x really means =x ;) might be good to know why if so.. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Standalone API
Hi, I hadn't, but I will, Thanks. I did find include/exports.h Another question would be, I guess exports.h holds a subset of routines that 'could' be called by a standalone. Is there a list of potential candidates ? Can you give me any guidance with regard to implementing the U-Boot API on SuperH ? What are the licences implications of a standalone calling these things ? Thanks for your help, it's good to know there is somebody out there :) Regards, Andrew On 7 Nov 2010, at 15:53, Dennis Ruffer wrote: From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Andrew Holt (SE) Is there a list, or header file containing prototypes of the U-Boot facilities that a standalone can make use of ? If so can somebody please direct me to it Regards, Andrew P.S. Also can somebody just responds anyway as a test. I'm not sure that my messages are getting out there. Did you read doc/README.standalone? DaR = Andrew Holt Senior Software Engineer Email: andrew.h...@electrans.com Questions are a burden to others; answers a prison for oneself. = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] hello
Hello my name is miss Lorita am a single girl never married, i come in contact with your email today as i was browsing on the internet searching for a true relationship, then i saw your email contact, i like to be your friend and i want to know more about you, i believe in reality of love, please contact me back with my email so that i can send my photos to you and tell you more about me for us to know more about each other, i wait for your mail thanks Lorita 4U. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
Dear Haiying Wang, In message 1288970062.1855.44.ca...@haiying-laptop you wrote: Wolfgang's latest commit to change all TEXT_BASE to CONFIG_SYS_TEXT_BASE breaks the build for nand_spl. He defined CONFIG_SYS_TEXT_BASE in board Which board(s) / configuration(s) are you talkign about? header file for CONFIG_NAND, and renamed TEXT_BASE to CONFIG_SYS_TEXT_BASE in nand_spl/board/.../Makefile. Then for u-boot-spl, the CONFIG_SYS_TEXT_BASE is always the value defined in header file, which is, for example, 0xf8f82000 for MPC8536/8569/p1_p2/, not the one defined in nand-spl's Makefile, which is 0xfff0. Thus it It is fundamentally broken to define such settings in a Makefile. They do not belong there, an never did. If you take for example the MPC8536DS_NAND configuration, this defines CONFIG_NAND as indication for the NAND booting config option, so it should be trivial to add some #ifdef CONFIG_NAND #define CONFIG_SYS_TEXT_BASE ... #else #define CONFIG_SYS_TEXT_BASE ... #endif to the respective board config file(s). Can you take a look at it? Defining CONFIG_SYS_TEXT_BASE in header file does impact the TEXT_BASE defined in Makefile for nand_spl. Please remove any such defines from Makefiles. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de All this doesn't alter anything, you know. The world is still full of stupid people. They don't use their brains. They don't seem to want to think straight.- Terry Pratchett, _Soul Music_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Standalone API
Replies inline below... -Original Message- From: Andrew Holt (SE) [mailto:andrew.h...@electrans.com] Sent: Sunday, November 07, 2010 12:44 PM To: Dennis Ruffer Cc: 'U-Boot List' Subject: Re: [U-Boot] Standalone API Hi, I hadn't, but I will, Thanks. I did find include/exports.h That's where the document points you to anyway. Another question would be, I guess exports.h holds a subset of routines that 'could' be called by a standalone. Is there a list of potential candidates ? If it's not in exports.h you can't call it, but you can add anything that follows the rules. Can you give me any guidance with regard to implementing the U-Boot API on SuperH ? Not really. I'm working on ARM and I haven't even written a standalone program myself yet. I've simply looked at it enough to have a good idea how to do it and I was working with a standalone program that someone else had written which didn't use any calls into uboot. So, I know it's possible. What are the licences implications of a standalone calling these things ? I'm not a lawyer, but I imagine that if you call u-boot routines, you still have to comply with their license. Thanks for your help, it's good to know there is somebody out there :) My impression is that most are in the far east, so I suspected you might not get many replies until tomorrow. I'm not really one of the official maintainers, but they might be able to help you on a SuperH. DaR Regards, Andrew On 7 Nov 2010, at 15:53, Dennis Ruffer wrote: From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Andrew Holt (SE) Is there a list, or header file containing prototypes of the U-Boot facilities that a standalone can make use of ? If so can somebody please direct me to it Regards, Andrew P.S. Also can somebody just responds anyway as a test. I'm not sure that my messages are getting out there. Did you read doc/README.standalone? DaR = Andrew Holt Senior Software Engineer Email: andrew.h...@electrans.com Questions are a burden to others; answers a prison for oneself. = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP4: quick image loading memory init on Pandaboard
Dear Sergiy Kibrik, In message 4cd4377b.2020...@globallogic.com you wrote: Improved default config for OMAP4 Pandaboard for faster boot: -reduced environment size to speed up memory initialization; -tweaked blob load address to avoid image relocation (according to default uImage load address); Signed-off-by: Sergiy Kibrik sergiy.kib...@globallogic.com --- include/configs/omap4_panda.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h index 74defab..5a2df35 100644 --- a/include/configs/omap4_panda.h +++ b/include/configs/omap4_panda.h @@ -62,10 +62,10 @@ /* * Size of malloc() pool - * Total Size Environment - 256k + * Total Size Environment - 2k An environment size of 2 kB seems way to small for amost practical purposes. I agree that 256 kB might be overkill, but why not chose a more reasonable size like 16 kB, or say 8 kB if you are really trying to squeeze any microsecond? * Malloc - add 256k */ -#define CONFIG_ENV_SIZE (256 10) +#define CONFIG_ENV_SIZE (256 4) 256 4 ? Who is supposed to easily read and understand this? If you mean 2 KiB, you could use either 2048 or (2 10). In any case - please reconside rif 16 KiB is nt more reasonable. The time difference should be minimal (did you measure it?). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Life and death are seldom logical. But attaining a desired goal always is. -- McCoy and Spock, The Galileo Seven, stardate 2821.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] BeagleBoard: Added LED driver
Dear Jason Kridner, In message aanlktim71jeaakjbhnhfv8fqdvcc5l=es1xfbwlbm...@mail.gmail.com you wrote: [sp] I see too many ifdef blocks in the code above. The also seems to be repetitive. Is user really expected to change the u-boot config for each LED bit/color? This is the existing architecture in status_led.h. I want to make sure this code compiles no matter which of the defines have been set. Can this be simplified by one function that takes an argument? Do you mean set vs. toggle? I think that would be great too, but again following an existing definition. Please don;t stick with bad examples just because they exist. Please feel free to come up ith an improvement. If you have time and resources, please feel free to clean up the status_led code as well. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Don't panic. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: Overo: Automatically set clock rate to maximum if mpurate env variable is auto
Dear Steve Sakoman, In message 1289012370.18546.66.ca...@quadra you wrote: The maximum clock rate for the OMAP3 processors on Overo depends on the processor type and revision. This patch sets the clock rate to the spec sheet maximum if the mpurate environment variable is set to auto. Otherwise it passes the mpurate variable unchanged on the kernel command line. I don't think this is a good idea. This logic does not belong into U-Boot; if anywhere, it belongs into the Linux kernel code. If I want to pass any specific value to the Linux kernel I want that U-Boot does not get in my way. And if I decide to set the mpurate to auto I want that U-Boot keeps this setting and does not change it silently behind my back into something else. Both looks conceptually broken to me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It became apparent that one reason why the Ice Giants were known as the Ice Giants was because they were, well, giants. The other was that they were made of ice. -Terry Pratchett, _Sourcery_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from library archives to partial linking
Dear Sebastien Carlier, In message 4cd56618.4010...@gmail.com you wrote: My previous patch missed some places that create library archives. A new 100% $(AR)-free version is available here: Please post your patch on the mailing list for review. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You might not be as stupid as you look. This is not hard. Let's think about this. I mean ... I'll think about this, and you can join in when you know the words. - Terry Pratchett, _Men at Arms_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Standalone API
On Sun, 2010-11-07 at 20:44 +, Andrew Holt (SE) wrote: Hi, I hadn't, but I will, Thanks. I did find include/exports.h Another question would be, I guess exports.h holds a subset of routines that 'could' be called by a standalone. Is there a list of potential candidates ? Can you give me any guidance with regard to implementing the U-Boot API on SuperH ? What are the licences implications of a standalone calling these things ? Thanks for your help, it's good to know there is somebody out there :) Its worth mentioning there are 2 external application interfaces, the older Standalone Application described in doc/README.standalone, and newer Standalone API described in api/README. I don't use the interfaces for non-GPL code or with the SuperH, so can't provide much input on the above questions. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from library archives to partial linking
Hi Wolfgang, In message 4cd56618.4010...@gmail.com you wrote: My previous patch missed some places that create library archives. A new 100% $(AR)-free version is available here: Please post your patch on the mailing list for review. For what its worth, Sebastien's patch is significantly larger than the 100K mailing list limit and I assume he was following the instructions at http://www.denx.de/wiki/U-Boot/Patches. He's been told conflicting stories about how to submit his patch - I just wanted to clarify for him (and me) what the current preferred method really is. Thanks, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from library archives to partial linking
Dear Peter Tyser, In message 1289168695.3511.11.ca...@ptyser-laptop you wrote: new 100% $(AR)-free version is available here: Please post your patch on the mailing list for review. For what its worth, Sebastien's patch is significantly larger than the 100K mailing list limit and I assume he was following the instructions at http://www.denx.de/wiki/U-Boot/Patches. He's been told conflicting stories about how to submit his patch - I just wanted to clarify for him (and me) what the current preferred method really is. Well, I would at least expect a description of the patch being posted. Something like new 100% $(AR)-free version is available does not tell me anything. It does not explain the rationale of the patch, nor what was changed (list of files etc.), or why. It does not even mention why the patch has not been posted. Oh, yes, by now I reas that other posting as well, but there was no threading used, so all this was completely out of context. Sebastien: For a new version, I expect at least to see the full commit message and diff-stat information posted (i. e. all what git format-patch gives, except the actual patch data). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A fanatic is a person who can't change his mind and won't change the subject. - Winston Churchill ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_mmc: fix compile warning
Signed-off-by: Lei Wen lei...@marvell.com --- common/env_mmc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/common/env_mmc.c b/common/env_mmc.c index 3d7fceb..7c9392c 100644 --- a/common/env_mmc.c +++ b/common/env_mmc.c @@ -29,6 +29,7 @@ #include linux/stddef.h #include malloc.h #include mmc.h +#include search.h #include errno.h /* references to names in env_common.c */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm926ejs, kirkwood: fix suen3 board port
- use GENERATED_GBL_DATA_SIZE - move CONFIG_SYS_KWD_CONFIG definition to include/configs/km_arm.h because this is arm only - move CONFIG_SYS_TEXT_BASE definition to include/configs/km_arm.h, because this default value is only for arm valid. Signed-off-by: Heiko Schocher h...@denx.de --- include/configs/keymile-common.h | 16 include/configs/km_arm.h | 20 +++- 2 files changed, 19 insertions(+), 17 deletions(-) diff --git a/include/configs/keymile-common.h b/include/configs/keymile-common.h index ccc71c9..62d21f6 100644 --- a/include/configs/keymile-common.h +++ b/include/configs/keymile-common.h @@ -30,22 +30,6 @@ #define CONFIG_BOOTCOUNT_LIMIT /* - * By default kwbimage.cfg from board specific folder is used - * If for some board, different configuration file need to be used, - * CONFIG_SYS_KWD_CONFIG should be defined in board specific header file - */ -#ifndef CONFIG_SYS_KWD_CONFIG -#defineCONFIG_SYS_KWD_CONFIG $(SRCTREE)/$(CONFIG_BOARDDIR)/kwbimage.cfg -#endif /* CONFIG_SYS_KWD_CONFIG */ - -/* - * CONFIG_SYS_TEXT_BASE can be defined in board specific header file, if needed - */ -#ifndef CONFIG_SYS_TEXT_BASE -#defineCONFIG_SYS_TEXT_BASE0x0040 -#endif /* CONFIG_SYS_TEXT_BASE */ - -/* * Command line configuration. */ #include config_cmd_default.h diff --git a/include/configs/km_arm.h b/include/configs/km_arm.h index bf77cc0..356eb7d 100644 --- a/include/configs/km_arm.h +++ b/include/configs/km_arm.h @@ -42,6 +42,24 @@ /* include common defines/options for all Keymile boards */ #include keymile-common.h + +/* + * By default kwbimage.cfg from board specific folder is used + * If for some board, different configuration file need to be used, + * CONFIG_SYS_KWD_CONFIG should be defined in board specific header file + */ +#ifndef CONFIG_SYS_KWD_CONFIG +#defineCONFIG_SYS_KWD_CONFIG $(SRCTREE)/$(CONFIG_BOARDDIR)/kwbimage.cfg +#endif /* CONFIG_SYS_KWD_CONFIG */ + +/* + * CONFIG_SYS_TEXT_BASE can be defined in board specific header file, if needed + */ +#ifndef CONFIG_SYS_TEXT_BASE +#defineCONFIG_SYS_TEXT_BASE0x0400 +#endif /* CONFIG_SYS_TEXT_BASE */ + + #undef CONFIG_CMD_DTT #undef CONFIG_BOOTCOUNT_LIMIT @@ -182,7 +200,7 @@ int get_scl (void); /* additions for new relocation code, must be added to all boards */ #define CONFIG_SYS_SDRAM_BASE 0x /* Kirkwood has 2k of Security SRAM, use it for SP */ -#define CONFIG_SYS_INIT_SP_ADDR0xC8012000 +#define CONFIG_SYS_INIT_SP_ADDR(0xC8012000 - GENERATED_GBL_DATA_SIZE) /* Do early setups now in board_init_f() */ #define CONFIG_BOARD_EARLY_INIT_F #endif /* _CONFIG_KM_ARM_H */ -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
