Re: [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code
Le 22/10/2011 03:20, Marek Vasut a écrit : > On Saturday, October 22, 2011 02:41:54 AM Albert ARIBAUD wrote: >> Le 22/10/2011 02:19, Marek Vasut a écrit : >>> On Saturday, October 22, 2011 02:04:52 AM Tom Rini wrote: On Fri, Oct 21, 2011 at 4:45 PM, Marek Vasut wrote: > On Saturday, October 22, 2011 01:08:43 AM Albert ARIBAUD wrote: >> Le 22/10/2011 00:46, Marek Vasut a écrit : >>> On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote: Le 22/10/2011 00:00, Marek Vasut a écrit : > On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote: >> Hi Marek, >> >> Le 21/10/2011 22:44, Marek Vasut a écrit : >>> On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote: This allows the SPL to avoid compiling in the CPU support code. Signed-off-by: Marek Vasut Cc: Stefano Babic Cc: Wolfgang Denk Cc: Detlev Zundel Cc: Scott Wood --- arch/arm/cpu/arm926ejs/Makefile |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o START = start.o COBJS = cpu.o +ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +START := +COBJS := +endif +endif + SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START)) >>> >>> Hi Albert, >>> >>> can we get this applied please? >> >> I still don't understand what this is supposed to do -- why not >> linking this code is required. >> >> Amicalement, > > Hi Albert, > > I use very different start.S in SPL. And I don't need cpu.o at all. That I understand; but is there a /problem/ in linking cpu.o in? >>> >>> I suppose it'll be optimized out at link time ? >> >> That indirectly answers my question: what you want to achieve is >> removing dead code. > > The code IS USED in U-Boot, but IS NOT USED in SPL ! Right, but linked and unused code in SPL is (or should be!) thrown away, is what's trying to be driven home right now. If the file is going to go away, and it's compiled thrown away at final link of SPL, lets just ignore that it exists for a little longer, and then it won't. >>> >>> My distrust towards compiler abilities to optimize such stuff out tells >>> me it's better to avoid it even to be compiled in at all. >> >> Optimizing unused functions is a rather simple and reliable ability in >> tolchains. The issue is not really whether the toolchain is able to do >> the removal (it is); rather, the issue is whether the linker command >> line will cause the removal (it will IMO as long as -gc-sections is >> specified). >> >> Amicalement, > > So what you suggest is to leave cpu.o compiling and drop only start.S ? Yes -- once you're sure that -gc-sections is there. > Cheers Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A bit about board.c, board.c
Le 22/10/2011 07:11, Simon Glass a écrit : > Hi, > > Each architecture has its own board.c but they are mostly quite similar. > > New features such as fdt, boot timing, trace, profiling, etc. must be > done separately for each arch, even if there are no > architecture-specific bits. > > What would you say to adding something like lib/board.c which is a > simplified cleaned-up copy of one of the existing board.c files, and a > CONFIG_ARCH_GENERIC_BOARD option to select that in preference to the > architecture-specific one. Then perhaps people could try it out and we > could slowly move to it over time... I'd say anything that factorizes ARM code is a good thing. :) However I'm not in favor of a CONFIG option that would force the board code to provide some functions just in odrer to override one, not if weak definitions can do a finer job. I am looking into that already for cache management function specialization, and it seems like there is the same kind of possibility here, with lib functions defined weak and the board code overriding the ones it deems necessary to. I will look into it a bit more this morning. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
Le 22/10/2011 07:05, Simon Glass a écrit : >>> Well I actually haven't moved it! It is just that previously it was >>> impossible to call cp15_init from anywhere later. >> >> It is moved, in that it belongs to low level init... of A9. > > OK, I see - you mean moved in order if not in source code file. Yes. In the code, though, it belongs to low-level init. >>> What you say can be done, it would involve some assembler though and >>> would need to be another CONFIG option. Was trying to avoid adding new >>> assembler. >> >> Low level init is about assembler and, well, low level. :) > > Yes but it's yuck. Part of the clean-up is to remove most of the > assembler - really very little is needed. I don't think "yuck" is a valid reasoned argument against assembly language :) but I assume what you mainly mean is 'hard to understand and replaceable by easy to understand C code'. I agree to the first part, and to the second one for the general case, but not for the startup path where, precisely, we don't have a working C run-time and most of the understanding requires knowledge of hardware, not only general programming knowledge. Past that, C is ok -- but then beware: some C++ guy could chime in and contend that C is "yuck" by your own standards. :) >> But I don't see why there should be another CONFIG option. IIUC, you should >> be able to do with only CONFIG_SKIP_LOWLEVEL_INIT: within the low level init >> code under it, you would do the equivalent of a switch, with one branch for >> AVM (and DDR init etc) and one branch for A9 (with cp15 init etc). > > Yes I can, but I need to be able to call cp15_init. And I can't do > that because if CONFIG_SKIP_LOWLEVEL_INIT is defined, that code is > compiled out! So I need to move that cp15_init code outside the > CONFIG_SKIP_LOWLEVEL_INIT #ifdef. That is all I am trying to do, > honest! I understand, and I think the approach here is wrong, because you *do* want low-level init in the A9 case, and thus you should not have CONFIG_SKIP_LOWLEVEL_INIT set. But you also need the AVP low-level init to be empty, and the AVP and A9 must follow the same startup path. And all this it not necessarily required for all armv7 platforms, but some of them will want lowlevel init, and some not. Considering all this... For now, I would opt for a CONFIG_ARCH_GENERIC_LOWLEVEL_INIT option which start.S would use to compile out the low level init code definition (like CONFIG_SKIP_LOWLEVEL_INIT does) but not the the calls to it (UNline CONFIG_SKIP_LOWLEVEL_INIT does). Then you could provide a SoC-specific version of lowlevel_init. In the longer term, I would be more in favor of a weak definition system with hierarchical ARCH, ISA, SoC, board priority order (yes, I am kind of fond of it) for lowlevel init -- but that will require looking into asm weak symbol handling and may require splitting of the assembly code function by function. > Regards, > Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] Add tftpput command for uploading files over network
Le 22/10/2011 06:51, Simon Glass a écrit : > The tftpboot command permits reading of files over a network interface > using the Trivial FTP protocol. This patch series adds the ability to > transfer files the other way. > > Why is this useful? > > - Uploading boot time data to a server > - Uploading profiling information > - Uploading large mounts of data for comparison / checking on a host > (e.g. use tftpput and ghex2 instead of the 'md' command) Especially I find it interesting for backing up things like MTD and small disk files (not partitions, though). Most of my work currently is trying to bring mainline U-Boot support to existing boards with bad U-Boot implementations, and being able to backup things from U-Boot (as opposed to having to set up NFS root and Linux boot) would definitely be a plus. > Mostly the existing code can be re-used and I have tried to avoid too > much refactoring or cleaning up. :) > The feature is activated by the CONFIG_CMD_TFTPPUT option. > > This has been very lightly tested on a Seaboard with a USB network > adaptor. I don't think it handles block number overflow. What size does this limit transfers to? > Simon Glass (8): >Move simple_itoa to vsprintf >Add setenv_uint() and setenv_addr() >tftpput: Rename TFTP to TFTPGET >tftpput: move common code into separate functions >tftpput: support selecting get/put for tftp >tftpput: add save_addr and save_size global variables >tftpput: implement tftp logic >tftpput: add tftpput command Many U-Boot environments use 'tftp' as a shorthand to tftpboot. Did you verify that this is not broken by the introduction of 'tftpput'? Also, I'd be happy to test this if a branch exists that already holds these commits. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] NS16550: buffer reads
Le 17/10/2011 22:58, Simon Glass a écrit : > Hi Wolfgang, > > On Mon, Oct 17, 2011 at 1:33 PM, Wolfgang Denk wrote: >> Dear Simon Glass, >> >> In >> message >> you wrote: >>> >>> Can you please tell me which ELDK version this is using? I see that >>> the 405 board seems to need ppc_4xx which suggests 4.2 rather than 5, >>> since in 5 the compiler is called powerpc- >> >> Right, I was testing this with ELDK 4.2. > > I am struggling to repeat this and don't even get the same numbers... Could be due to two things: 1) both of you do not work from the same exact tree commit, or 2) both of you work in a different base directory > For your AR405 board, you saw: >> - 246058 12972 14636 273666 42d02 /work/wd/tmp-ppc/u-boot >> + 246062 12972 14636 273670 42d06 /work/wd/tmp-ppc/u-boot > For me: > 24594212964 14632 273538 42c82 ppc/u-boot I suggest Wolfgang and you compare your trees to eliminate risk 1, and make sure you compare .bin files to reduce risk 2. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] NS16550: buffer reads
Le 17/10/2011 18:40, Simon Glass a écrit : >> So essentially you are saying: hey, we now have multi-line input, >> but it works only a bit. It will fail sooner or later, without >> error messages, and I cannot even tell you what the limits for your >> system are. And it depends on which input you send. >> >> This does not exactly sound promising. > > That all sounds reasonable. > > I think it is good enough, but not perfect. Due to the fundamental > design decision you mention at the top, we cannot squirrel away serial > input in the background. The best we can do is squirrel it away in the > foreground, as we output new serial data (I suppose we could squirrel > it away in net loops and other places but I don't want to go there!). > This turns out to be mostly good enough, because it is rare for people > to want to paste 'sleep 10' and the like into their terminal (your > other message). I think you're not seeing the point that while your patch is good enough for 'making multiline input less impractical in some cases', it is not good enough for 'making multiline input reliable': it adds marginal benefits and we have clear evidence that it will never guarantee a correct result however you tweak it, because the only way it could would be by multi-tasking in some way; otherwise, there can always be some U-Boot activity in between input readings that will be long enough to cause character loss. > I would like to spit out a warning when serial input is lost - as I > mentioned that could be combined with a serial overhaul at some point. I don't think the warning would make the functionality better. >> On the other hand, we also have the rule that things that are useful >> to some and that don't hurt others should be allowed to go in. >> >> What makes me hesitate are two things: >> >> - The patch promises a feature (multi-line input), but fails to >> provide a reliably working implementation. > > I *think* it does the best possible within the fundamental design > decision constraint. If there is more it can do, please let me have > your ideas. I don't believe buffering conflicts with the constraint - > they are separate things. But yes in systems with interrupts normally > the input buffer is filled in the background and drained in the > foreground. There *is* a much better solution within the fundamental single tasking design constraint, and it is the one that was invented precisely for this: flow control. Granted, hardware flow control may be impractical, and that's why software flow control was conceived as early as 1963 and is still widely used today and supported by any serial software or driver worth its salt. >> - As it turns out, the patch increases code size even for boards that >> do not activate this feature. > > Yes, I will take a look at this problem. > >> >> >> I have to admit that I'm at a loss with a decision here. > > Well it's not easy being a maintainer :-) Well, FWIW, were I the serial code maintainer, I'd NAK this and ask for a XON/XOFF implementation. > In any case this patch is > not the end of the story as serial needs some work - another objection > you didn't mention above is that this function lives in only one > driver. Is that a good thing (hide it away) or a bad thing (all > drivers should support it and the implementation should move up a > level)? Software flow control, whatever way it is implemented, is pure SW and hardware independent, so it should be a generic thing. If XON/XOFF input flow control gets implemented (and I believe it should), then it should be done above hardware serial drivers. > Regards, > Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] [PATCH 00/39] Rework of the debug() macro
Le 22/10/2011 03:18, Marek Vasut a écrit : > On Saturday, October 22, 2011 02:35:13 AM Albert ARIBAUD wrote: >> Hi Marek, >> >> Le 22/10/2011 02:16, Marek Vasut a écrit : >>> This patch series reworks the debug() and debugX() macro in >>> include/common.h to be compatible with GCC 4.6. >>> >>> This series needs further discussion: >>> * Some files suffer size growth with gcc4.2, why ? >>> >>> - Possibility is that the GCC4.2 is incapable to optimize code out so >>> deep >>> >>> * Does this change break any platforms? Compile tested on PowerPC. >>> >>> - Please run MAKEALL on your platforms to test this. >> >> Any git branch we could pull and rebase on our trees rather than am'ing >> 39 patches one by one? > > Please try: > > git://git.denx.de/u-boot-marex.git , "debug" branch. > > Cheers A differential 'MAKEALL arm' (ELDK42) show a sharp rise in board not building properly, from 74 to 141 (out of a total of 248). Of the 67 boards, many show , essentially due to a lot of printf format warnings such as: ks8695eth.c: In function 'ks8695_eth_send': ks8695eth.c:199: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'volatile void *' (in cm4008, cm41xx), or lcd.c: In function 'lcd_setmem': lcd.c:446: warning: format '%d' expects type 'int', but argument 2 has type 'u_long' lcd.c:446: warning: format '%d' expects type 'int', but argument 3 has type 'u_long' (in at91sam9261ek_nandflash). Another, different, case is smdk2410: s3c2410_nand.c: In function 's3c2410_hwcontrol': s3c2410_nand.c:59: error: 'DEBUG' undeclared (first use in this function) s3c2410_nand.c:59: error: (Each undeclared identifier is reported only once s3c2410_nand.c:59: error: for each function it appears in.) s3c2410_nand.c: In function 's3c2410_dev_ready': s3c2410_nand.c:86: error: 'DEBUG' undeclared (first use in this function) s3c2410_nand.c: In function 'board_nand_init': Seems like you're trading some warnings against some others, depending on the compiler. :( Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] [PATCH 00/39] Rework of the debug() macro
On Saturday, October 22, 2011 11:48:43 AM Albert ARIBAUD wrote: > Le 22/10/2011 03:18, Marek Vasut a écrit : > > On Saturday, October 22, 2011 02:35:13 AM Albert ARIBAUD wrote: > >> Hi Marek, > >> > >> Le 22/10/2011 02:16, Marek Vasut a écrit : > >>> This patch series reworks the debug() and debugX() macro in > >>> include/common.h to be compatible with GCC 4.6. > >>> > >>> This series needs further discussion: > >>> * Some files suffer size growth with gcc4.2, why ? > >>> > >>> - Possibility is that the GCC4.2 is incapable to optimize code out > >>> so deep > >>> > >>> * Does this change break any platforms? Compile tested on PowerPC. > >>> > >>> - Please run MAKEALL on your platforms to test this. > >> > >> Any git branch we could pull and rebase on our trees rather than am'ing > >> 39 patches one by one? > > > > Please try: > > > > git://git.denx.de/u-boot-marex.git , "debug" branch. > > > > Cheers > > A differential 'MAKEALL arm' (ELDK42) show a sharp rise in board not > building properly, from 74 to 141 (out of a total of 248). This was expected ... will fix. > > Of the 67 boards, many show , essentially due to a lot of printf format > warnings such as: > > ks8695eth.c: In function 'ks8695_eth_send': > ks8695eth.c:199: warning: format '%x' expects type 'unsigned int', but > argument 4 has type 'volatile void *' > > (in cm4008, cm41xx), or > > lcd.c: In function 'lcd_setmem': > lcd.c:446: warning: format '%d' expects type 'int', but argument 2 has > type 'u_long' > lcd.c:446: warning: format '%d' expects type 'int', but argument 3 has > type 'u_long' > > (in at91sam9261ek_nandflash). Another, different, case is smdk2410: > > s3c2410_nand.c: In function 's3c2410_hwcontrol': > s3c2410_nand.c:59: error: 'DEBUG' undeclared (first use in this function) > s3c2410_nand.c:59: error: (Each undeclared identifier is reported only once > s3c2410_nand.c:59: error: for each function it appears in.) > s3c2410_nand.c: In function 's3c2410_dev_ready': > s3c2410_nand.c:86: error: 'DEBUG' undeclared (first use in this function) > s3c2410_nand.c: In function 'board_nand_init': > > Seems like you're trading some warnings against some others, depending > on the compiler. :( Not trading, the typechecking wasn't there and now that it is there, these kind of warnings keep popping up. Did you ever try to build those boards with DEBUG enabled? Cheers ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] [PATCH 00/39] Rework of the debug() macro
Le 22/10/2011 16:19, Marek Vasut a écrit : > On Saturday, October 22, 2011 11:48:43 AM Albert ARIBAUD wrote: >> Le 22/10/2011 03:18, Marek Vasut a écrit : >>> On Saturday, October 22, 2011 02:35:13 AM Albert ARIBAUD wrote: Hi Marek, Le 22/10/2011 02:16, Marek Vasut a écrit : > This patch series reworks the debug() and debugX() macro in > include/common.h to be compatible with GCC 4.6. > > This series needs further discussion: > * Some files suffer size growth with gcc4.2, why ? > > - Possibility is that the GCC4.2 is incapable to optimize code out > so deep > > * Does this change break any platforms? Compile tested on PowerPC. > > - Please run MAKEALL on your platforms to test this. Any git branch we could pull and rebase on our trees rather than am'ing 39 patches one by one? >>> >>> Please try: >>> >>> git://git.denx.de/u-boot-marex.git , "debug" branch. >>> >>> Cheers >> >> A differential 'MAKEALL arm' (ELDK42) show a sharp rise in board not >> building properly, from 74 to 141 (out of a total of 248). > > This was expected ... will fix. Much welcome. :) >> Of the 67 boards, many show , essentially due to a lot of printf format >> warnings such as: >> >> ks8695eth.c: In function 'ks8695_eth_send': >> ks8695eth.c:199: warning: format '%x' expects type 'unsigned int', but >> argument 4 has type 'volatile void *' >> >> (in cm4008, cm41xx), or >> >> lcd.c: In function 'lcd_setmem': >> lcd.c:446: warning: format '%d' expects type 'int', but argument 2 has >> type 'u_long' >> lcd.c:446: warning: format '%d' expects type 'int', but argument 3 has >> type 'u_long' >> >> (in at91sam9261ek_nandflash). Another, different, case is smdk2410: >> >> s3c2410_nand.c: In function 's3c2410_hwcontrol': >> s3c2410_nand.c:59: error: 'DEBUG' undeclared (first use in this function) >> s3c2410_nand.c:59: error: (Each undeclared identifier is reported only once >> s3c2410_nand.c:59: error: for each function it appears in.) >> s3c2410_nand.c: In function 's3c2410_dev_ready': >> s3c2410_nand.c:86: error: 'DEBUG' undeclared (first use in this function) >> s3c2410_nand.c: In function 'board_nand_init': >> >> Seems like you're trading some warnings against some others, depending >> on the compiler. :( > > Not trading, the typechecking wasn't there and now that it is there, these > kind > of warnings keep popping up. Did you ever try to build those boards with DEBUG > enabled? Not the whole code; I only enabled debug in very specific areas. > Cheers Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
Hi Albert, On Sat, Oct 22, 2011 at 12:56 AM, Albert ARIBAUD wrote: > Le 22/10/2011 07:05, Simon Glass a écrit : > Well I actually haven't moved it! It is just that previously it was impossible to call cp15_init from anywhere later. >>> >>> It is moved, in that it belongs to low level init... of A9. >> >> OK, I see - you mean moved in order if not in source code file. > > Yes. In the code, though, it belongs to low-level init. Arguably this could go in a library like arch/arm/cpu/armv7/lib/cache.S > What you say can be done, it would involve some assembler though and would need to be another CONFIG option. Was trying to avoid adding new assembler. >>> >>> Low level init is about assembler and, well, low level. :) >> >> Yes but it's yuck. Part of the clean-up is to remove most of the >> assembler - really very little is needed. > > I don't think "yuck" is a valid reasoned argument against assembly language > :) but I assume what you mainly mean is 'hard to understand and replaceable > by easy to understand C code'. I agree to the first part, and to the second > one for the general case, but not for the startup path where, precisely, we > don't have a working C run-time and most of the understanding requires > knowledge of hardware, not only general programming knowledge. Past that, C I'm not arguing for the cache init stuff to move to C, just trying to avoid any creeping growth of assembler when C can do it. > is ok -- but then beware: some C++ guy could chime in and contend that C is > "yuck" by your own standards. :) The C++ guy who finds himself in U-Boot is probably lost :-) > >>> But I don't see why there should be another CONFIG option. IIUC, you >>> should >>> be able to do with only CONFIG_SKIP_LOWLEVEL_INIT: within the low level >>> init >>> code under it, you would do the equivalent of a switch, with one branch >>> for >>> AVM (and DDR init etc) and one branch for A9 (with cp15 init etc). >> >> Yes I can, but I need to be able to call cp15_init. And I can't do >> that because if CONFIG_SKIP_LOWLEVEL_INIT is defined, that code is >> compiled out! So I need to move that cp15_init code outside the >> CONFIG_SKIP_LOWLEVEL_INIT #ifdef. That is all I am trying to do, >> honest! > > I understand, and I think the approach here is wrong, because you *do* want > low-level init in the A9 case, and thus you should not have > CONFIG_SKIP_LOWLEVEL_INIT set. But you also need the AVP low-level init to > be empty, and the AVP and A9 must follow the same startup path. And all this > it not necessarily required for all armv7 platforms, but some of them will > want lowlevel init, and some not. Considering all this... > > For now, I would opt for a CONFIG_ARCH_GENERIC_LOWLEVEL_INIT option which > start.S would use to compile out the low level init code definition (like > CONFIG_SKIP_LOWLEVEL_INIT does) but not the the calls to it (UNline > CONFIG_SKIP_LOWLEVEL_INIT does). Then you could provide a SoC-specific > version of lowlevel_init. If I understand you correctly, this is the opposite of what I want. It is basically what we have now. All ARMv7 chips are going to turn off MMU, caches, flush TLBs, and the like - this is an architecture feature, not an SOC one. We have conflated ARM arch init with SOC init as you say, but the solution is not to force the SOC to copy code from start.S just so that it can do ARM arch init later. And I'd argue for LOWLEVEL_INIT being about setting up the memory so we can run code, and in particular relocate it later. The cp15_init stuff should arguably be in arch_cpu_init() (or perhaps a new arch_init()) as the first thing called from board_init_f() in my view. So how about I create a patch to move the cp15_init() code into arch/arm/cpu/armv7/lib/lowlevel.S or similar so I can call it later? > > In the longer term, I would be more in favor of a weak definition system > with hierarchical ARCH, ISA, SoC, board priority order (yes, I am kind of > fond of it) for lowlevel init -- but that will require looking into asm weak > symbol handling and may require splitting of the assembly code function by > function. I think you are trying to avoid the #ifdef CONFIG_ARCH_CPU_INIT arch_cpu_init, #endif #ifdef ... some_other_thing #endif in the board_init_f() function table. Yes I agree it would tidy things up, although I wonder if Graeme's initcall thing isn't better again. It has the same confusion level coefficient (only the linker decides what code is included) with a bit more flexibility. Then each arch / board / cpu / soc / squirrel can decide on its own init and put it in its own file. C only please :-) Regards, Simon > >> Regards, >> Simon > > Amicalement, > -- > Albert. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] Add tftpput command for uploading files over network
Hi Albert, On Sat, Oct 22, 2011 at 1:21 AM, Albert ARIBAUD wrote: > Le 22/10/2011 06:51, Simon Glass a écrit : >> >> The tftpboot command permits reading of files over a network interface >> using the Trivial FTP protocol. This patch series adds the ability to >> transfer files the other way. >> >> Why is this useful? >> >> - Uploading boot time data to a server >> - Uploading profiling information >> - Uploading large mounts of data for comparison / checking on a host >> (e.g. use tftpput and ghex2 instead of the 'md' command) > > Especially I find it interesting for backing up things like MTD and small > disk files (not partitions, though). Most of my work currently is trying to > bring mainline U-Boot support to existing boards with bad U-Boot > implementations, and being able to backup things from U-Boot (as opposed to > having to set up NFS root and Linux boot) would definitely be a plus. > >> Mostly the existing code can be re-used and I have tried to avoid too >> much refactoring or cleaning up. > > :) > >> The feature is activated by the CONFIG_CMD_TFTPPUT option. >> >> This has been very lightly tested on a Seaboard with a USB network >> adaptor. I don't think it handles block number overflow. > > What size does this limit transfers to? I think about 1468 * 65535 - around 95MB - it's fairly easy to fix just by copying out the existing tftp get wrap code. I put it in the commit message so it wouldn't get lost. > >> Simon Glass (8): >> Move simple_itoa to vsprintf >> Add setenv_uint() and setenv_addr() >> tftpput: Rename TFTP to TFTPGET >> tftpput: move common code into separate functions >> tftpput: support selecting get/put for tftp >> tftpput: add save_addr and save_size global variables >> tftpput: implement tftp logic >> tftpput: add tftpput command > > Many U-Boot environments use 'tftp' as a shorthand to tftpboot. Did you > verify that this is not broken by the introduction of 'tftpput'? > > Also, I'd be happy to test this if a branch exists that already holds these > commits. I will see if I can organise one at Denx. Regards, Simon > > Amicalement, > -- > Albert. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A bit about board.c, board.c
Hi Albert, On Sat, Oct 22, 2011 at 12:17 AM, Albert ARIBAUD wrote: > Le 22/10/2011 07:11, Simon Glass a écrit : >> >> Hi, >> >> Each architecture has its own board.c but they are mostly quite similar. >> >> New features such as fdt, boot timing, trace, profiling, etc. must be >> done separately for each arch, even if there are no >> architecture-specific bits. >> >> What would you say to adding something like lib/board.c which is a >> simplified cleaned-up copy of one of the existing board.c files, and a >> CONFIG_ARCH_GENERIC_BOARD option to select that in preference to the >> architecture-specific one. Then perhaps people could try it out and we >> could slowly move to it over time... > > I'd say anything that factorizes ARM code is a good thing. :) > > However I'm not in favor of a CONFIG option that would force the board code > to provide some functions just in odrer to override one, not if weak My suggestion was: CONFIG_ARCH_GENERIC_BOARD - you get lib/board.c not CONFIG_ARCH_GENERIC_BOARD - you get arch/xxx/lib/board.c > definitions can do a finer job. I am looking into that already for cache > management function specialization, and it seems like there is the same kind > of possibility here, with lib functions defined weak and the board code > overriding the ones it deems necessary to. ok. Just one little point. Weak symbols are the punishment our C++ overlords gave us for not having to understand what code is executed when we instantiate a C++ subclass. It is nice to know what code is being linked in and avoid having to disassemble to find out. I think using weak symbols to avoid a OBJS-$(CONFIG_ARCH_GENERIC_BOARD) in a couple of Makefiles risks going too far. Regards, Simon Regards, Simon Regards, Simon > > I will look into it a bit more this morning. > > Amicalement, > -- > Albert. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] pick up the first $5,000.00,USD
Hello, The below payment has been awarded to you by the Nigeria Government/World Bank to compensate you on the past experience had with scammers and internet fraudsters. We have already sent you $5,000.00 through Western Union as we have been given the mandate to transfer your full compensation payment total sum of $250,000.00 via Western Union by the Government. I have on a good authority email you the MTCN and sender's details to enable you pick up the first $5,000.00,USD and confirm receipt to us so as to enable us wire the next USD5,000.00 by tomorrow and subsequent ones since we can only send USD5,000.00 a day. Please pick up this information and get to any western union in your country to pick up the $5,000.00 and email the Western Union outlets incharge of the payment so that they could send you another payment tomorrow and you are to fill the form below for confirmation. Rev Godspower Umukoro Western Union contact information: Manager: Email: wumt_moneytrans...@w.cn your contact is needed If there is any problem with them paying you, make sure to contact this Western Union outlet with the information given to you above.Below is the western union information for pick up: and you are to Track your payment on the website to be sure:https://wumt.westernunion.com/asp/orderStatus.asp?country=global MONEY TRANSFER CONTROL NUMBER(MTCN): 780-670-9836 FIRST NAME OF SENDER: Norma LAST NAME OF SENDER: Caycho Question: COLOUR Answer: PINK Amount:$5,000.00 They will be expecting your e-mail via this email: wumt_moneytrans...@w.cn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A bit about board.c, board.c
Hi Simon, On 23/10/11 03:36, Simon Glass wrote: > Hi Graeme, > > Did you mean to send to list? Oops, yes I did - Done now > On Fri, Oct 21, 2011 at 10:49 PM, Graeme Russ wrote: >> Hi Simon >> >> On Oct 22, 2011 4:11 PM, "Simon Glass" wrote: >>> >>> Hi, >>> >>> Each architecture has its own board.c but they are mostly quite similar. >>> >>> New features such as fdt, boot timing, trace, profiling, etc. must be >>> done separately for each arch, even if there are no >>> architecture-specific bits. >> >> Yes, it is a mess - something my unit sequence patches tried to clean up >> >>> What would you say to adding something like lib/board.c which is a >>> simplified cleaned-up copy of one of the existing board.c files, and a >> >> 100% agree >> >>> CONFIG_ARCH_GENERIC_BOARD option to select that in preference to the >>> architecture-specific one. Then perhaps people could try it out and we >>> could slowly move to it over time... >> >> I vote to pick an arch, convert it to a unified style and move it to >> lib/board.c and then merge each arch over. This should be done in a single >> series rather than the ol' 'migrate over time' which never happens. > > I thing you mean merge each arch over in its own series? > >> >> x86 is a good arch to start with because the number of boards is so small >> (1) >> >> Also, I'd personally like the init sequence patches I posted earlier to be >> re-examined > > I already examined and thought it was good. Let's be careful to keep > it simple in the sense that we only need a very small number of init > functions. Most of the board_init_r() code should not be there as I > understand it (e.g. on ARM MMC, USB, NAND should be inited if/when > used and not before). Need to be careful not to confuse this bit with > driver init or any refactor of the driver model. So we have things > like > > - init memory and make it so we can relocate code, etc. (this is > called from start.S at present) > - init the CPU core > - arch init like turn off caches, MMU, flush TLBs, etc. > - early board init (hopefully just requires an initcall in board code if > needed) > - the current init sequence like banner, serial, etc. > - relocate > - console init > - board_init (initcall in board code if needed) > - (hopefully all other post-relocation init can be punted) > > So board.c becomes a few functions and about a dozen initcalls. Albert > will want to use weak symbols instead of #ifdef, and we will be done. > > Regards, > Simon > >> >> Regards, >> >> Graeme >> > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A bit about board.c, board.c
Hi Simon, On 23/10/11 08:41, Graeme Russ wrote: > Hi Simon, > > > On 23/10/11 03:36, Simon Glass wrote: >> Hi Graeme, [snip] >>> I vote to pick an arch, convert it to a unified style and move it to >>> lib/board.c and then merge each arch over. This should be done in a single >>> series rather than the ol' 'migrate over time' which never happens. >> >> I thing you mean merge each arch over in its own series? I mean merge all arches in one series >>> x86 is a good arch to start with because the number of boards is so small >>> (1) >>> >>> Also, I'd personally like the init sequence patches I posted earlier to be >>> re-examined >> >> I already examined and thought it was good. Let's be careful to keep >> it simple in the sense that we only need a very small number of init >> functions. Most of the board_init_r() code should not be there as I >> understand it (e.g. on ARM MMC, USB, NAND should be inited if/when >> used and not before). Need to be careful not to confuse this bit with >> driver init or any refactor of the driver model. So we have things >> like My biggest gripe with the init code is the lack of consistency. There are two prime examples of this: 1) The pre-relocation sequence and post-relocation sequences can be implemented using identical code (a sequence loop) - x86 almost gets there, other arches only loop for one, and have sequential logic for the other 2) Even with the init loop, there is a lot of sequential code after the loop that could be merged into the loop >> - init memory and make it so we can relocate code, etc. (this is >> called from start.S at present) >> - init the CPU core >> - arch init like turn off caches, MMU, flush TLBs, etc. >> - early board init (hopefully just requires an initcall in board code if >> needed) >> - the current init sequence like banner, serial, etc. >> - relocate >> - console init >> - board_init (initcall in board code if needed) >> - (hopefully all other post-relocation init can be punted) >> >> So board.c becomes a few functions and about a dozen initcalls. Albert >> will want to use weak symbols instead of #ifdef, and we will be done. The INIT_CALL approach eliminated this need - If the .c file does not get compiled in, the INIT_CALL does not get included. And adding a new INIT_CALL was as simple as including the macro in the .c file without needing to mess with board.c at all - simple :) INIT_CALL is a completely separate issue to what you are looking at and would be easier to implement after board.c was merged into lib Regard, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] NS16550: buffer reads
Hi Simon, Albert, On 22/10/11 19:44, Albert ARIBAUD wrote: > Le 17/10/2011 18:40, Simon Glass a écrit : [snip] >>> On the other hand, we also have the rule that things that are useful >>> to some and that don't hurt others should be allowed to go in. >>> >>> What makes me hesitate are two things: >>> >>> - The patch promises a feature (multi-line input), but fails to >>> provide a reliably working implementation. I fully agree with this - We should strive to eliminate bugs, not cover them with more dirt :) >> I *think* it does the best possible within the fundamental design >> decision constraint. If there is more it can do, please let me have >> your ideas. I don't believe buffering conflicts with the constraint - >> they are separate things. But yes in systems with interrupts normally >> the input buffer is filled in the background and drained in the >> foreground. > > There *is* a much better solution within the fundamental single tasking > design constraint, and it is the one that was invented precisely for > this: flow control. Granted, hardware flow control may be impractical, > and that's why software flow control was conceived as early as 1963 and > is still widely used today and supported by any serial software or > driver worth its salt. Agree - flow control is the way to go > Well, FWIW, were I the serial code maintainer, I'd NAK this and ask for > a XON/XOFF implementation. > >> In any case this patch is >> not the end of the story as serial needs some work - another objection >> you didn't mention above is that this function lives in only one >> driver. Is that a good thing (hide it away) or a bad thing (all >> drivers should support it and the implementation should move up a >> level)? > > Software flow control, whatever way it is implemented, is pure SW and > hardware independent, so it should be a generic thing. If XON/XOFF input > flow control gets implemented (and I believe it should), then it should > be done above hardware serial drivers. One problem I see with XON/XOFF is that if we don't send XOFF at the right time, we run the risk of entering a busy loop (any reasonable timeout delay for example) and loosing input. So in theory, we would need to send XOFF after every getc() and XON before each getc() and then need to delay a bit to wait for the character (unless tstc returns true in which case we can just grab the char in the buffer) which seems a bit excessive. Maybe we need disable/enable flow control functions for when we know we will be entering a busy loop the consumes serial input (ymodem and kermit transfers and readline for example) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] [PATCH 00/39] Rework of the debug() macro
On Saturday, October 22, 2011 05:23:52 PM Albert ARIBAUD wrote: > Le 22/10/2011 16:19, Marek Vasut a écrit : > > On Saturday, October 22, 2011 11:48:43 AM Albert ARIBAUD wrote: > >> Le 22/10/2011 03:18, Marek Vasut a écrit : > >>> On Saturday, October 22, 2011 02:35:13 AM Albert ARIBAUD wrote: > Hi Marek, > > Le 22/10/2011 02:16, Marek Vasut a écrit : > > This patch series reworks the debug() and debugX() macro in > > include/common.h to be compatible with GCC 4.6. > > > > This series needs further discussion: > > * Some files suffer size growth with gcc4.2, why ? > > > > - Possibility is that the GCC4.2 is incapable to optimize code > > out so deep > > > > * Does this change break any platforms? Compile tested on PowerPC. > > > > - Please run MAKEALL on your platforms to test this. > > Any git branch we could pull and rebase on our trees rather than > am'ing 39 patches one by one? > >>> > >>> Please try: > >>> > >>> git://git.denx.de/u-boot-marex.git , "debug" branch. > >>> > >>> Cheers > >> > >> A differential 'MAKEALL arm' (ELDK42) show a sharp rise in board not > >> building properly, from 74 to 141 (out of a total of 248). > > > > This was expected ... will fix. > > Much welcome. :) > > >> Of the 67 boards, many show , essentially due to a lot of printf format > >> warnings such as: > >> > >> ks8695eth.c: In function 'ks8695_eth_send': > >> ks8695eth.c:199: warning: format '%x' expects type 'unsigned int', but > >> argument 4 has type 'volatile void *' > >> > >> (in cm4008, cm41xx), or > >> > >> lcd.c: In function 'lcd_setmem': > >> lcd.c:446: warning: format '%d' expects type 'int', but argument 2 has > >> type 'u_long' > >> lcd.c:446: warning: format '%d' expects type 'int', but argument 3 has > >> type 'u_long' > >> > >> (in at91sam9261ek_nandflash). Another, different, case is smdk2410: > >> > >> s3c2410_nand.c: In function 's3c2410_hwcontrol': > >> s3c2410_nand.c:59: error: 'DEBUG' undeclared (first use in this > >> function) s3c2410_nand.c:59: error: (Each undeclared identifier is > >> reported only once s3c2410_nand.c:59: error: for each function it > >> appears in.) > >> s3c2410_nand.c: In function 's3c2410_dev_ready': > >> s3c2410_nand.c:86: error: 'DEBUG' undeclared (first use in this > >> function) s3c2410_nand.c: In function 'board_nand_init': > >> > >> Seems like you're trading some warnings against some others, depending > >> on the compiler. :( > > > > Not trading, the typechecking wasn't there and now that it is there, > > these kind of warnings keep popping up. Did you ever try to build those > > boards with DEBUG enabled? > > Not the whole code; I only enabled debug in very specific areas. So because noone actually bothered to compile u-boot with DEBUG enabled, we (me ?) now have literally piles of places to fix. Hm :-( Cheers > > > Cheers > > Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91: Add support for Bluewater Systems Snapper 9G45 module
Snapper 9G45 is a ARM9-based CPU module with 1GB NAND and 128MB
DDR SDRAM. This patch includes NAND and Ethernet support.
Signed-off-by: Simon Glass
---
board/bluewater/snapper9g45/Makefile | 43 +++
board/bluewater/snapper9g45/snapper9g45.c | 155 +++
boards.cfg|1 +
include/configs/snapper9g45.h | 189 +
4 files changed, 388 insertions(+), 0 deletions(-)
create mode 100644 board/bluewater/snapper9g45/Makefile
create mode 100644 board/bluewater/snapper9g45/snapper9g45.c
create mode 100644 include/configs/snapper9g45.h
diff --git a/board/bluewater/snapper9g45/Makefile
b/board/bluewater/snapper9g45/Makefile
new file mode 100644
index 000..9016e5a
--- /dev/null
+++ b/board/bluewater/snapper9g45/Makefile
@@ -0,0 +1,43 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# 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; either version 2 of
+# the License, or (at your option) any later version.
+#
+# 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., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y += snapper9g45.o
+
+SRCS := $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/bluewater/snapper9g45/snapper9g45.c
b/board/bluewater/snapper9g45/snapper9g45.c
new file mode 100644
index 000..f057e59
--- /dev/null
+++ b/board/bluewater/snapper9g45/snapper9g45.c
@@ -0,0 +1,155 @@
+/*
+ * (C) Copyright 2011 Bluewater Systems Ltd
+ * Author: Andre Renaud
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static void macb_hw_init(void)
+{
+ struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+ struct at91_port *pioa = (struct at91_port *)ATMEL_BASE_PIOA;
+ struct at91_rstc *rstc = (struct at91_rstc *)ATMEL_BASE_RSTC;
+ unsigned long erstl;
+
+ /* Enable clock */
+ writel(1 << ATMEL_ID_EMAC, &pmc->pcer);
+
+ /*
+* Disable pull-up on:
+* RXDV (PA15) => PHY normal mode (not Test mode) / CRSDV
+* ERX0 (PA12) => PHY ADDR0 / RXD0
+* ERX1 (PA13) => PHY ADDR1 => PHYADDR = 0x0 / RXD1
+*
+* PHY has internal pull-down
+*/
+ writel(pin_to_mask(AT91_PIN_PA15) |
+ pin_to_mask(AT91_PIN_PA12) |
+ pin_to_mask(AT91_PIN_PA13),
+ &pioa->pudr);
+
+ /* Need to reset PHY -> 500ms reset */
+ erstl = readl(&rstc->mr) & AT91_RSTC_MR_ERSTL_MASK;
+ writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(13) |
+ AT91_RSTC_MR_URSTEN, &rstc->mr);
+ writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST, &rstc->cr);
+
+ /* Wait for end hardware reset */
+ while (!(readl(&rstc->sr) & AT91_RSTC_SR_NRSTL))
+ ;
+
+ /* Restore NRST value */
+ writel(AT91_RSTC_KEY | erstl | AT91_RSTC_MR_URSTEN, &rstc->mr);
+
+ /* The phy internal reset take 21ms */
+ udelay(21 * 1000);
+
+ /* Re-enable pull-up */
+ writel(pin_to_mask(AT91_PIN_PA15) |
+ pin_to_mask(AT91_PIN_P
Re: [U-Boot] [PATCH] at91: Add support for Bluewater Systems Snapper 9G45 module
Dear Simon Glass,
> Snapper 9G45 is a ARM9-based CPU module with 1GB NAND and 128MB
> DDR SDRAM. This patch includes NAND and Ethernet support.
>
> Signed-off-by: Simon Glass
> ---
> board/bluewater/snapper9g45/Makefile | 43 +++
> board/bluewater/snapper9g45/snapper9g45.c | 155 +++
> boards.cfg|1 +
> include/configs/snapper9g45.h | 189
> +
> 4 files changed, 388 insertions(+), 0 deletions(-)
> create mode 100644 board/bluewater/snapper9g45/Makefile
> create mode 100644 board/bluewater/snapper9g45/snapper9g45.c
> create mode 100644 include/configs/snapper9g45.h
>
> [...]
> +
> +#ifndef NEW
> +#define CONFIG_PCA953X
> +#define CONFIG_SYS_I2C_PCA953X_ADDR 0x28
> +#define CONFIG_SYS_I2C_PCA953X_WIDTH { {0x28, 16} }
> +#endif
if that is a board variant, use something better than just "NEW" -
and where would that ever get defined?
> +/* Command line configuration */
> +#include
Space missing here.
Please run checkpatch before submitting!
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] Add setenv_uint() and setenv_addr()
On Sat, Oct 22, 2011 at 00:51, Simon Glass wrote:
> +int setenv_ulong(const char *varname, ulong value)
> +{
> + char *str = simple_itoa(value);
> +
> + return setenv(varname, str);
> +}
could be a one liner, but works either way
> +int setenv_addr(const char *varname, const void *addr)
> +{
> + char str[17];
char str[sizeof(addr) * 2 + 1];
> + sprintf(str, "%x", (uintptr_t)addr);
i wonder if we should use %p and drop the cast
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] [PATCH 00/39] Rework of the debug() macro
On Sat, Oct 22, 2011 at 05:48, Albert ARIBAUD wrote: > A differential 'MAKEALL arm' (ELDK42) show a sharp rise in board not > building properly, from 74 to 141 (out of a total of 248). these boards are broken already. Marek is just making their problems more apparent. -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v3] Add assert() for debug assertions
On Fri, Oct 21, 2011 at 18:20, Wolfgang Denk wrote:
> Simon Glass wrote:
>> +void __assert_fail(const char *assertion, const char *file, unsigned line,
>> + const char *function)
>> +{
>> + /* This will not return */
>> + panic("%s:%u: %s: Assertion `%s' failed.", file, line, function,
>> + assertion);
>> +}
>
> Can you please #ifdef it so it doesn't get added for the non-debug
> case, too?
most arches are building with --gc-sections now which means there is
no overhead added for them. should we look at fixing the few holdouts
rather than adding #ifdefs ?
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/39] DEBUG: Fix debug macros
On Fri, Oct 21, 2011 at 20:16, Marek Vasut wrote:
> The current implementation of debug doesn't play well with GCC4.6.
> This implementation also fixes GCC4.6 complaints about unused variables
> while maintaining code size.
i think this patch should come last rather than first that way you fix
all the warnings/failures *before* making the debug() code
unconditional
> +#define debug_cond(cond, fmt, args...) \
> + do { \
> + if (cond) \
> + printf(fmt, ##args); \
> + } while (0)
> +
> +#define debug(fmt, args...) \
> + debug_cond(_DEBUG, fmt, ##args)
> +
> +#define debugX(level, fmt, args...) \
> + debug_cond((_DEBUG && DEBUG >= (level)), fmt, ##args)
i thought we were just going to punt debugX() ?
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/39] GCC4.6: Squash warning in usb_storage.c
On Fri, Oct 21, 2011 at 20:17, Marek Vasut wrote: > #ifdef USB_STOR_DEBUG > -#define USB_STOR_PRINTF(fmt, args...) printf(fmt , ##args) > +#define USB_BLK_DEBUG 1 > #else > -#define USB_STOR_PRINTF(fmt, args...) > +#define USB_BLK_DEBUG 0 > #endif #defineUSB_BLK_DEBUG. -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
