[U-Boot] [PATCH] M28EVK: Fix build if CONFIG_CMD_NAND not selected
Signed-off-by: Marek Vasut Cc: Wolfgang Denk Cc: Stefano Babic --- include/configs/m28evk.h |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h index 39c841f..dcea878 100644 --- a/include/configs/m28evk.h +++ b/include/configs/m28evk.h @@ -140,6 +140,7 @@ /* * NAND */ +#defineCONFIG_ENV_SIZE (16 * 1024) #ifdef CONFIG_CMD_NAND #defineCONFIG_NAND_MXS #define CONFIG_APBH_DMA @@ -150,7 +151,6 @@ /* Environment is in NAND */ #defineCONFIG_ENV_IS_IN_NAND -#defineCONFIG_ENV_SIZE (16 * 1024) #defineCONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE #defineCONFIG_ENV_SECT_SIZE(128 * 1024) #defineCONFIG_ENV_RANGE(512 * 1024) @@ -173,6 +173,8 @@ "512k(redundant-environment)," \ "4m(kernel)," \ "-(filesystem)" +#else +#defineCONFIG_ENV_IS_NOWHERE #endif /* -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/19] Create generic board init and move ARM and x86 to it
Dear Simon Glass, In message you wrote: > > Also it does depend on expectations. I would hope that moving an > architecture over would be a fairly small task: > > - getting generic relocation working I don;t see why this would be a direct prerequisite here. We want to have that, no boubt about that. But it appears to be an unrelated change to me. > - adding functions for anything that is missing from board init code "anything that is missing from board init code" ? > - removing things which don't work on the architecture? That would probably reander systems broken that need these things? > - worrying about differences in ordering between functions This is indeed the biggest issue. Keep in mind that my original ida of providing a function call table was to allow to define this table in a board specific way (i. e. in the board config file). [Not that this idea found many friends...] > > pull out common init code like init_baudrate() and hang() and change the > > function signatures of the functions that require wrappers and move some > > #ifdef's into more appropriate locations - One example in board.c: > > Well it seems like a lot of work to refactor each arch/xxx/board.c > file into functions with a function pointer list, then later remove > this code function by function. Would that really be a clever approach? > My feeling is that with a generic board, it should hopefully be a > fairly small amount of work for someone familiar with an architecture > to find the bugs and patch the generic code to suit their > architecture. It is something that needs to be done once, not every > time there is a new patch removing (almost) common code. It is definitely not that easy. You fix one thing here, and break another board there. Ideally you would have to re-test any change on _all_ boards. > From previous discussions, if something is optional then the switch > will never happen. The code you are talking about is sometimes > identical, sometimes slightly different. In some cases the order is > different. I see many ways of introducing breakages. I do agree that And I bet most of them _will_ introduce breakages. > doing one architecture at a time is best - with the proviso that we > need to pick archs that have the most features (so ARM and PowerPC I > suppose) to make sure we are not deluding ourselves as to the > simplicity of the task. I would suggest to attempt to merge ARM into PPC. > So perhaps a generic board init that is the default can be switched > off on board-by-board basic would be the right approach. Then we can > flick the switch while providing for those affected to still get work > done until bugs are reported and found? Heh! Board specific init tables! > > Note that not all arches need and/or use ELF relocation - Attacking this > > first does not move towards unity of board.c > > It is a feature used by about half, and it does include the complexity > of jumping from pre-reloc to post-reloc init. I think it was a > reasonable first target. What exactly is the problem here? > Per Wolfgang's request to go with PPC as an early-adopter, this is No. It's the other way round. PPC is what should be adopted to. > Can anyone recommend a PowerPC board with a quick U-Boot program-run > cycle that I can easily get that will let me try out things there? Define "get easily". 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 People have one thing in common: they are all different. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [trivial] env: remove value from boolean defines
Acked-by: Mike Frysinger -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [trivial] common.h: remove value from bool defines
Acked-by: Mike Frysinger -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap4: fix boot issue on ES2.0 Panda
On 12/31/2011 01:27 PM, asad wrote: [snip] Jeez, obviously this is me... Thanks and sorry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap4: fix boot issue on ES2.0 Panda
On 12/29/2011 07:47 PM, Aneesh V wrote: > Fix boot issue on ES2.0 Panda by tuning some > IO settings. The CONTROL_EFUSE_2 register has > to be over-ridden in software for 4430 boards. > > Commit 23e9f0723e48615332119de4f4ec7a833a282628 > wrongly did this for CONTROL_EFUSE_1. Reverting > this and doing it for CONTROL_EFUSE_2. > > Signed-off-by: Aneesh V [snip] Hi, works fine: U-Boot SPL 2011.12-00046-gbfcc40b-dirty (Dec 31 2011 - 12:14:09) Texas Instruments OMAP4430 ES2.0 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2011.12-00046-gbfcc40b-dirty (Dec 31 2011 - 12:14:09) CPU : OMAP4430 ES2.0 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment Thanks! Tested-by: Raúl Porcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/19] Create generic board init and move ARM and x86 to it
Hi Simon, On 31/12/11 13:02, Simon Glass wrote: > Hi Graeme, > > On Fri, Dec 30, 2011 at 7:49 AM, Graeme Russ wrote: >> Hi Simon, >> [snip] >> However, I think this approach is not the right one - and I think the CFI >> driver backs me up. Your plan is to create generic code which you want ALL >> arches to cross over to, but you only look to migrate two initially and >> migrate the rest 'later'. This is similar to what happened with the CFI >> driver, and there are still boards with custom flash.c files which are >> completely redundant. >> >> But, creating a single patch-set to migrate everyone in one go is going to >> be too massive a job to do in one go, and too prone to introducing breakage. > > Yes to some extent. However, my patch basically splits the two > board_init_x() functions into parts, and puts them in a function > table. Ah yes, looking a bit closer I see this now in patches 5 & 6. However, I think if you look at my patches 9, 10, 12 and 13 I'm doing essentially the same thing for x86. The difference is, I'm moving live code, rather than creating dead code then switching over. I personally do not think your approach is very safe - If there is a breakage, it is spread over multiple patches - With the 'move code around' approach, all breakages are confined to a single patch > I don't think it is a huge job to do this for PowerPC also, and that > seems to be the most feature-full architecture. I agree - The init architecture is the same, but the sequence is bigger (and not in the same order) > Also it does depend on expectations. I would hope that moving an > architecture over would be a fairly small task: > > - getting generic relocation working > - adding functions for anything that is missing from board init code > - removing things which don't work on the architecture? > - worrying about differences in ordering between functions I see it as: 1) Rework the arch init sequence to be a pure list of 'int foo(void)' functions, adding helpers and wrappers where necessary 2) Switch over to use the generic init processing loop 3) Factor out common helpers and wrappers across all arches 4) Factor out common functionality (e.g. relocation) 5) After all arches are switched, remove wrappers by changing the function signature of the wrapped function 6) Move helpers into relevant driver/common source file I think 1 & 2 need to be done for at least ARM, x86 and PPC before starting 3 & 4 and 1-4 needs to be done for all arches before doing 5 & 6 [snip] >> If we work each individual arch to use a generic init sequence (like the >> proposed x86 code) then the init processing naturally falls out as common >> code and the patch to realise this is trivial. From there, we can start to >> pull out common init code like init_baudrate() and hang() and change the >> function signatures of the functions that require wrappers and move some >> #ifdef's into more appropriate locations - One example in board.c: > > Well it seems like a lot of work to refactor each arch/xxx/board.c > file into functions with a function pointer list, then later remove > this code function by function. Yes, it is more work, but it is intrinsically safer (and git bisect-able) > My feeling is that with a generic board, it should hopefully be a > fairly small amount of work for someone familiar with an architecture > to find the bugs and patch the generic code to suit their You seem to admit that your approach can introduce bugs > architecture. It is something that needs to be done once, not every > time there is a new patch removing (almost) common code. The safer approach is to tackle each arch independently - Convert each board.c to something similar to what I have shown with x86 and test those arch-specific changes to make sure nothing has been broken. Then it is a trivial matter of checking that there are no incompatibilities between the arch and the common case (and adjusting as required) and switching over to the common case [snip] >> The other big benefit is that you only touch one architecture at a time up >> until you 'pull the switch'. And when you do pull the switch, you should be >> factoring out identical code so the chances of breaking something should be >> vastly reduced. Take a look at the history of ARM relocation for example - >> that was constrained to one arch but still the amount of breakage was >> massive. > >>From previous discussions, if something is optional then the switch > will never happen. The code you are talking about is sometimes > identical, sometimes slightly different. In some cases the order is > different. I see many ways of introducing breakages. I do agree that The init sequence order is dictated arch-specifically through the init arrays which will (for the time being) remain in the arch specific board.c. But that is all arch/foo/lib/board.c will contain - init sequence arrays, no 'code' > doing one architecture at a time is best - with the proviso that we > need
