[U-Boot] [PATCH] calimain: Update maintainers and their email addresses
Signed-off-by: Christian Riesch <christ...@riesch.at> Cc: Manfred Rudigier <manfred.rudig...@omicronenergy.com> Cc: Christoph Rüdisser <christoph.ruedis...@omicronenergy.com> --- board/omicron/calimain/MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/board/omicron/calimain/MAINTAINERS b/board/omicron/calimain/MAINTAINERS index f6e37a2..ad788a6 100644 --- a/board/omicron/calimain/MAINTAINERS +++ b/board/omicron/calimain/MAINTAINERS @@ -1,6 +1,6 @@ CALIMAIN BOARD -M: Manfred Rudigier <manfred.rudig...@omicron.at> -M: Christian Riesch <christian.rie...@omicron.at> +M: Manfred Rudigier <manfred.rudig...@omicronenergy.com> +M: Christoph Rüdisser <christoph.ruedis...@omicronenergy.com> S: Maintained F: board/omicron/calimain/ F: include/configs/calimain.h -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] autoboot: remove CONFIG_ZERO_BOOTDELAY_CHECK
On Tue, Jun 21, 2016 at 7:32 AM, Masahiro Yamada <yamada.masah...@socionext.com> wrote: > As the help message of CONFIG_BOOTDELAY says, CONFIG_BOOTDELAY=-2 > means the autoboot with no delay, with no abort check even if > CONFIG_ZERO_BOOTDELAY_CHECK is defined. > > To sum up, the autoboot behaves as follows: > > [1] CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=y > autoboot with no delay, but you can abort it by key input > > [2] CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=n > autoboot with no delay, with no check for abort > > [3] CONFIG_BOOTDELAY=-1 > disable autoboot > > [4] CONFIG_BOOTDELAY=-2 > autoboot with no delay, with no check for abort > > As you notice, [2] and [4] come to the same result, which means we > do not need CONFIG_ZERO_BOOTDELAY_CHECK. We can control all the > cases only by CONFIG_BOOTDELAY, like this: > > [1] CONFIG_BOOTDELAY=0 > autoboot with no delay, but you can abort it by key input > > [2] CONFIG_BOOTDELAY=-1 > disable autoboot > > [3] CONFIG_BOOTDELAY=-2 > autoboot with no delay, with no check for abort > > This commit converts the logic as follow: > CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=n > --> CONFIG_BOOTDELAY=-2 > > Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> For the calimain board Acked-by: Christian Riesch <christian.rie...@omicronenergy.com> Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] arm: Enable CONFIG_SYS_GENERIC_BOARD for all boards
Hi Simon, On Wed, Aug 19, 2015 at 6:35 AM, Simon Glass s...@chromium.org wrote: All boards should be converted to generic board by now. Change the rest over. If this causes run-time breakages then we can remove those boards. Why not just remove these apparently unmaintained boards, as announced in [1]? Regards, Christian [1] http://lists.denx.de/pipermail/u-boot/2015-January/201032.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: fix missing exception handling
Benoît, On Wed, Aug 20, 2014 at 12:47 PM, Benoît Thébaudeau benoit.thebaudeau@gmail.com wrote: On Wed, Aug 20, 2014 at 9:21 AM, Christian Riesch christian.rie...@omicron.at wrote: On Tue, Aug 19, 2014 at 8:35 PM, Benoît Thébaudeau benoit.thebaudeau@gmail.com wrote: Commit 41623c9 'arm: move exception handling out of start.S files' missed some linker scripts. Hence, some boards no longer had exception handling linked since this commit. Restore the original behavior by adding the .vectors section to these linker scripts. Signed-off-by: Benoît Thébaudeau benoit.thebaudeau@gmail.com Cc: Albert ARIBAUD albert.u.b...@aribaud.net Does this really _fix_ exception handling for all of these boards (as your message subject states) or just restore the state before commit 41623c9? I believe exception handling has never worked for most of these boards, they don't use it. See the discussion in [1], in particular [2] and [3]. Regards, Christian [1] http://marc.info/?t=14024710541r=1w=2 [2] http://marc.info/?l=u-bootm=140309659906074w=2 [3] http://marc.info/?l=u-bootm=140450616517545w=2 The issue is that commit 41623c9 silently removed exception handling for many boards. Whether it was working or not for these boards before this commit is another issue. My patch only fixes _missing_ exception handling, not exception handling itself. I had discussed that with Albert here: http://lists.denx.de/pipermail/u-boot/2014-July/183073.html Thanks for the pointer to the discussion. What do you suggest? - Changing the wording? In which way? Yes, how about Add missing .vectors section to linker scripts? Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] arm: include config.h in vectors.S
Hi Albert, On Tue, Aug 5, 2014 at 10:30 AM, Chris Packham judge.pack...@gmail.com wrote: On 14/07/14 17:01, Chris Packham wrote: In order to use configuration flags it is necessary to include config.h. Without this arm targets that use CONFIG_USE_IRQ or CONFIG_SPL_BUILD won't get the correct code. Signed-off-by: Chris Packham judge.pack...@gmail.com I submitted a similar patch on July 7, see http://patchwork.ozlabs.org/patch/367453/. Please apply either of them to get the issue fixed. Thanks, Christian --- Resent without corporate disclaimer arch/arm/lib/vectors.S |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S index e6538ef..a8b6c53 100644 --- a/arch/arm/lib/vectors.S +++ b/arch/arm/lib/vectors.S @@ -12,6 +12,7 @@ * * SPDX-License-Identifier: GPL-2.0+ */ +#include config.h /* * Ping? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: fix missing exception handling
Benoît, On Tue, Aug 19, 2014 at 8:35 PM, Benoît Thébaudeau benoit.thebaudeau@gmail.com wrote: Commit 41623c9 'arm: move exception handling out of start.S files' missed some linker scripts. Hence, some boards no longer had exception handling linked since this commit. Restore the original behavior by adding the .vectors section to these linker scripts. Signed-off-by: Benoît Thébaudeau benoit.thebaudeau@gmail.com Cc: Albert ARIBAUD albert.u.b...@aribaud.net Does this really _fix_ exception handling for all of these boards (as your message subject states) or just restore the state before commit 41623c9? I believe exception handling has never worked for most of these boards, they don't use it. See the discussion in [1], in particular [2] and [3]. Regards, Christian [1] http://marc.info/?t=14024710541r=1w=2 [2] http://marc.info/?l=u-bootm=140309659906074w=2 [3] http://marc.info/?l=u-bootm=140450616517545w=2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] the first 0x20 bytes in u-boot.bin
Hi, On Thu, Jul 31, 2014 at 12:24 PM, tiger...@via-alliance.com wrote: Hi, Albert: I am studying 2014.07 release u-boot package. I found u-boot.bin's first bytes were not code in start.S . For ARM processors, it's in arch/arm/lib/vectors.S. Regards, Christian Taken for compling smdkv310 as an example: The compiled u-boot.bin's first 0x20 bytes were: 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 .. So, Is it equal to ldr pc, [pc,#0x18] ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned (was: [PATCH] arm: fix a build error with CONFIG_USE_IRQ)
Hi Albert, On Fri, Jul 4, 2014 at 10:35 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Christian, On Wed, 2 Jul 2014 15:45:17 +0200, Christian Riesch christian.rie...@omicron.at wrote: Hello Albert, On Wed, Jun 18, 2014 at 2:55 PM, Christian Riesch christian.rie...@omicron.at wrote: Am I missing something here? What would be the preferred solution to make the board working again? Any comments on this? What shall we do to get the boards working again? Sorry for the delay. My opinion is that for these boards, there should actually be *no* exception vectors at the start of the image, since it would never serve any purpose anyway unless as you suggest we copy the vectors table from the image to the actual vectors table location (or set the VBAR to the image vector table location for those targets which allow it). (and I don't think this is limited to the three boards discussed here. IOW, the current exception/interrupt system in ARM U-Boot is FUBAR.) As far as fixing the boards, Masahiro had posted a series where one patch fixed the issue. I NAKed the submission for several reasons; I had expected a followup (v3) which I failed to ping for. MAsahiro: do you have a v3 ready? I assume you are talking about [1]. Adding this #include alone does not solve the issue for the calimain board. With adding the include, we would end up with #include config.h #ifdef CONFIG_SYS_DV_NOR_BOOT_CFG .word CONFIG_SYS_DV_NOR_BOOT_CFG #endif _start: ldr pc, _reset ... in arch/arm/lib/vectors.S. As a result, __image_copy_start points to 0x6000 (CONFIG_SYS_TEXT_BASE) and _start points is 0x6004. The relocation code in arch/arm/lib/relocate.S calculates its relocation offset based on __image_copy_start. However, arch/arm/lib/board.c calculates the offset as gd-reloc_off = addr - (ulong)_start; As the two are different, we have different offsets for the relocation code in relocate.S (based on __image_copy_start) and the calculation of the lr register in arch/arm/lib/crt0.S (gd-reloc_off). After relocation, the CPU jumps to the wrong address. So we can either unify the offset calculation (which of the two is the correct one?) or put the _start label where it was in earlier versions of u-boot: #include config.h _start: #ifdef CONFIG_SYS_DV_NOR_BOOT_CFG .word CONFIG_SYS_DV_NOR_BOOT_CFG #endif ldr pc, _reset ... What do you think? Thanks, Christian [1] http://lists.denx.de/pipermail/u-boot/2014-June/181334.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned (was: [PATCH] arm: fix a build error with CONFIG_USE_IRQ)
Hi again, On Mon, Jul 7, 2014 at 9:15 AM, Christian Riesch christian.rie...@omicron.at wrote: [...] As a result, __image_copy_start points to 0x6000 (CONFIG_SYS_TEXT_BASE) and _start points is 0x6004. The relocation code in arch/arm/lib/relocate.S calculates its relocation offset based on __image_copy_start. However, arch/arm/lib/board.c calculates the offset as gd-reloc_off = addr - (ulong)_start; I just noticed that I did my test without CONFIG_SYS_GENERIC_BOARD. Adding CONFIG_SYS_GENERIC_BOARD solves that problem, as the relocation offset calculation in common/board_f.c is based on CONFIG_SYS_TEXT_BASE. So adding the missing #include in vectors.S and adding CONFIG_SYS_GENERIC_BOARD (patch is already in u-boot-arm/master) fixes the calimain board. I'll post a patch for the missing include. Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: include config.h in arch/arm/lib/vectors.S
config.h is required for CONFIG_SYS_DV_NOR_BOOT_CFG. Signed-off-by: Christian Riesch christian.rie...@omicron.at Reported-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Masahiro Yamada yamad...@jp.panasonic.com Cc: Heiko Schocher h...@denx.de Cc: Sudhakar Rajashekhara sudhakar@ti.com --- arch/arm/lib/vectors.S |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S index e6538ef..493f337 100644 --- a/arch/arm/lib/vectors.S +++ b/arch/arm/lib/vectors.S @@ -13,6 +13,8 @@ * SPDX-License-Identifier:GPL-2.0+ */ +#include config.h + /* * * -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned (was: [PATCH] arm: fix a build error with CONFIG_USE_IRQ)
Hello Albert, On Wed, Jun 18, 2014 at 2:55 PM, Christian Riesch christian.rie...@omicron.at wrote: Am I missing something here? What would be the preferred solution to make the board working again? Any comments on this? What shall we do to get the boards working again? Thanks, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned (was: [PATCH] arm: fix a build error with CONFIG_USE_IRQ)
Hi Albert, I had one more look at this, please see my comments below. On Wed, Jun 11, 2014 at 9:14 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Masahiro, (to: the board maintainers for enbw_cmc, da850evm_direct_nor, and calimain) On Mon, 09 Jun 2014 18:29:26 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Albert, You changed the behaviour of three boards, enbw_cmc, da850evm_direct_nor, calimain! Probably they are broken. These boards expects 0x0011 (=CONFIG_SYS_DV_NOR_BOOT_CFG) at the beginning of the image. But since commit 41623c91, that is missing. If you still don't understand, you should checkout 41623c91^ and 41623c91 and compare u-boot.dis. Your description of the effects of my change is correct. However, this raises another question which I would like to see discussed before doing anything about these boards. Taking the last commit where the prefix word was actually emitted (that is, 41623c91^, which is actually 60a4f39f, arm: remove unused _end_vect and _vectors_end symbols), and reading arch/arm/cpu/arm926ejs/start.S, I see that the start of the image looks like this: offset Content +0x prefix word CONFIG_SYS_DV_NOR_BOOT_CFG +0x0004 reset vector +0x0008 undefined instruction vector +0x000c software interrupt vector +0x0010 prefetch abort vector +0x0014 data abort vector +0x0018 unused +0x001c irq vector +0x0020 fiq vector +0x0024 (end of vectors table) And that is /wrong/: the vectors table is misaligned by 4 bytes. Let's have a look at the calimain board. The vector exception table of this CPU (ARM926EJS) can be located either at 0x or at 0x (depending on CONFIG_SYS_EXCEPTION_VECTORS_HIGH). This SoC (Texas Instruments AM1808) has no physical memory at 0x, therefore CONFIG_SYS_EXCEPTION_VECTOR must be defined. The exception vector table is located in the internal RAM of the device, that is located at 0x. However, CONFIG_SYS_TEXT_BASE is 0x6000, that is the begin of NOR flash memory on this device. Later, u-boot relocates itself to some place DDR2 memory. So in the begin u-boot's vector table is located at 0x6004. Later, it is relocated to somewhere in the DDR2 memory. There is no code that actually touches the exception vector table at 0x. Exceptions are not used at all and therefore the location of this table in memory is totally irrelevant. What we actually need would be some code that copies the vector table to the right location (0x). But this code could copy the table from anywhere, so I don't understand why the CONFIG_SYS_DV_NOR_BOOT_CFG word would disturb the alignment of the table. If we accept that we do not use any exceptions we could either restore the old behavior: --- a/arch/arm/lib/vectors.S +++ b/arch/arm/lib/vectors.S @@ -13,6 +13,8 @@ * SPDX-License-Identifier:GPL-2.0+ */ +#include config.h + /* * * @@ -49,7 +51,6 @@ _start: .word CONFIG_SYS_DV_NOR_BOOT_CFG #endif -_start: ldr pc, _reset Obviously, the boards have been working fine for a long time, because no exception vector was used apparently (or because when exceptions did happen, the error was debugged without the need to analyze the exception). I suspect we could just remove the '.word CONFIG_SYS_DV_NOR_BOOT_CFG' line from the vectors.S file and prepend the word to the image /after/ linking. Or we could remove .word CONFIG_SYS_DV_NOR_BOOT_CFG as you suggested and later add the word after linking. But for this case we should be able to set CONFIG_SYS_TEXT_BASE to 0x6004. But due to the .align 5 statements below in arch/arm/lib/vectors.S this leads to a padding at the start of u-boot.bin, since the entire .vectors section will be aligned to 32 bytes: hexdump -C u-boot.bin 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0010 00 00 00 00 00 00 00 00 00 00 00 00 18 f0 9f e5 || 0020 18 f0 9f e5 18 f0 9f e5 18 f0 9f e5 18 f0 9f e5 || Now the ldr pc, _reset is at the wrong location, u-boot does not boot. Am I missing something here? What would be the preferred solution to make the board working again? Best regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned (was: [PATCH] arm: fix a build error with CONFIG_USE_IRQ)
On Wed, Jun 18, 2014 at 2:55 PM, Christian Riesch christian.rie...@omicron.at wrote: [...] And that is /wrong/: the vectors table is misaligned by 4 bytes. Let's have a look at the calimain board. The vector exception table of this CPU (ARM926EJS) can be located either at 0x or at 0x (depending on CONFIG_SYS_EXCEPTION_VECTORS_HIGH). This SoC (Texas Instruments AM1808) has no physical memory at 0x, therefore CONFIG_SYS_EXCEPTION_VECTOR must be defined. The exception s/CONFIG_SYS_EXCEPTION_VECTOR/CONFIG_SYS_EXCEPTION_VECTORS_HIGH/ :-) Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm, calimain: Add CONFIG_SYS_GENERIC_BOARD
Signed-off-by: Christian Riesch christian.rie...@omicron.at --- include/configs/calimain.h |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/configs/calimain.h b/include/configs/calimain.h index febee45..b27f973 100644 --- a/include/configs/calimain.h +++ b/include/configs/calimain.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2011 OMICRON electronics GmbH + * Copyright (C) 2011-2014 OMICRON electronics GmbH * * Based on da850evm.h. Original Copyrights follow: * @@ -18,6 +18,7 @@ #define CONFIG_DRIVER_TI_EMAC #define MACH_TYPE_CALIMAIN 3528 #define CONFIG_MACH_TYPE MACH_TYPE_CALIMAIN +#define CONFIG_SYS_GENERIC_BOARD /* * SoC Configuration -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned
On Wed, Jun 11, 2014 at 3:15 PM, Christian Riesch christian.rie...@omicron.at wrote: - test the same build with the 4-byte signature manually prepended (this may possibly require padding the image); No, this didn't work, I guess because the relocation offsets are wrong now. I tried to set CONFIG_SYS_TEXT_BASE in include/configs/calimain.h to 0x6004, but this resulted in some strange padding (28 bytes set to 0x00 prepend the u-boot image) which I currently don't understand. Which I currently don't understand means: I looks like the begin of the vector table is padded to align to 32 bytes. But I don't understand why and where this is set in the linker script etc. Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned
Hi all, On Wed, Jun 11, 2014 at 9:47 AM, Heiko Schocher h...@denx.de wrote: Hello Albert, Am 11.06.2014 09:14, schrieb Albert ARIBAUD: Hi Masahiro, (to: the board maintainers for enbw_cmc, da850evm_direct_nor, and calimain) On Mon, 09 Jun 2014 18:29:26 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Albert, You changed the behaviour of three boards, enbw_cmc, da850evm_direct_nor, calimain! Probably they are broken. These boards expects 0x0011 (=CONFIG_SYS_DV_NOR_BOOT_CFG) at the beginning of the image. But since commit 41623c91, that is missing. If you still don't understand, you should checkout 41623c91^ and 41623c91 and compare u-boot.dis. Your description of the effects of my change is correct. However, this raises another question which I would like to see discussed before doing anything about these boards. Taking the last commit where the prefix word was actually emitted (that is, 41623c91^, which is actually 60a4f39f, arm: remove unused _end_vect and _vectors_end symbols), and reading arch/arm/cpu/arm926ejs/start.S, I see that the start of the image looks like this: offset Content +0x prefix word CONFIG_SYS_DV_NOR_BOOT_CFG +0x0004 reset vector +0x0008 undefined instruction vector +0x000c software interrupt vector +0x0010 prefetch abort vector +0x0014 data abort vector +0x0018 unused +0x001c irq vector +0x0020 fiq vector +0x0024 (end of vectors table) And that is /wrong/: the vectors table is misaligned by 4 bytes. Obviously, the boards have been working fine for a long time, because no exception vector was used apparently (or because when exceptions did happen, the error was debugged without the need to analyze the exception). Probably a bit of both ;-) I don't know much about exceptions, so maybe this is just stupid, but: I had a look at some ARM documentation (and the datasheets of the AM1808 that is used on the calimain board). According to these, the exception vector table of this CPU is located at 0x. I had a look at the memory there, and the content of this table seems to be branches to the ROM bootloader located at 0xfffd. So my question is: Are we actually setting up the ARM's exception table for this device? And if yes, where is this done in the code? I suspect we could just remove the '.word CONFIG_SYS_DV_NOR_BOOT_CFG' line from the vectors.S file and prepend the word to the image /after/ linking. Yes, I think this would be the right way to do it. This, of course, requires confirmation from maintainers. Manfred, Christian, Sudhakar, Heiko: can any one of you let us know the reason for this signature word exactly, and how exactly it is used by the board? Ideally, can you also: See AM18xx Bootloader Application Report: http://www.ti.com/lit/pdf/spraba5 Section 3.1 NOR Boot on page 3ff This word is used to setup some settings ... Exactly. 0x6000 is the start of the NOR flash. 0x0011 as the first word tells the ROM bootloader to use the Direct NOR boot method, i.e. to branch to 0x6004, which is the start of u-boot. u-boot then relocates itself to RAM. - test a current build (which does not have the signature word) and confirm it fails to load); I tested a current build for calimain, and yes, it fails to load. - test the same build with the 4-byte signature manually prepended (this may possibly require padding the image); No, this didn't work, I guess because the relocation offsets are wrong now. I tried to set CONFIG_SYS_TEXT_BASE in include/configs/calimain.h to 0x6004, but this resulted in some strange padding (28 bytes set to 0x00 prepend the u-boot image) which I currently don't understand. Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm, davinci: Use CONFIG_SPL_PAD_TO for padding the SPL in an ais image
The commits commit b7b5f1a16ca66dfdd817e7339f0e263a5b9f2758 Author: Albert ARIBAUD albert.u.b...@aribaud.net da850evm, da850_am18xxevm: convert to CONFIG_SPL_MAX_FOOTPRINT and commit e7497891e34efe5cb2b3a3dc7c6c096c012ede28 Author: Albert ARIBAUD albert.u.b...@aribaud.net cam_enc_4xx: convert to CONFIG_SPL_MAX_FOOTPRINT replaced CONFIG_SPL_MAX_SIZE by CONFIG_SPL_MAX_FOOTPRINT. However, CONFIG_SPL_MAX_SIZE is used in the Makefile for padding the SPL when preparing an u-boot.ais image. By removing CONFIG_SPL_MAX_SIZE said commits broke the ais image of the da850evm and cam_enc_4xx configurations. This patch converts the u-boot.ais target to use CONFIG_SPL_PAD_TO instead of CONFIG_SPL_MAX_SIZE for padding the SPL and adds a #define CONFIG_SPL_PAD_TO where it is required. Signed-off-by: Christian Riesch christian.rie...@omicron.at Reported-by: Tom Taylor ttaylor.ta...@gmail.com Cc: Sudhakar Rajashekhara sudhakar@ti.com Cc: Heiko Schocher h...@denx.de Cc: Albert ARIBAUD albert.u.b...@aribaud.net --- Sent again since date was wrong in my earlier email. Sorry for that. Christian Makefile |2 +- include/configs/da850evm.h |1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index ff38a43..869f442 100644 --- a/Makefile +++ b/Makefile @@ -890,7 +890,7 @@ MKIMAGEFLAGS_u-boot-spl.ais = -s -n $(if $(CONFIG_AIS_CONFIG_FILE), \ spl/u-boot-spl.ais: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_MAX_SIZE) +OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) u-boot.ais: spl/u-boot-spl.ais u-boot.img FORCE $(call if_changed,pad_cat) diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h index 509fe20..0ca0c8d 100644 --- a/include/configs/da850evm.h +++ b/include/configs/da850evm.h @@ -386,6 +386,7 @@ #define CONFIG_SPL_STACK 0x8001ff00 #define CONFIG_SPL_TEXT_BASE 0x8000 #define CONFIG_SPL_MAX_FOOTPRINT 32768 +#define CONFIG_SPL_PAD_TO 32768 #endif /* Load U-Boot Image From MMC */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DA850EVM with USE_NAND config does not pad the AIS file
Tom, Thank you very much for your investigations :-) --On April 26, 2014 13:34 -0400 Tom Taylor ttaylor.ta...@gmail.com wrote: I'm a U-Boot newbie so please feel free to correct how I'm reporting this issue.. I recently downloaded the 2014.04-rc3 snapshot to build U-Boot for my custom DA850-based board. The only change was to add a new target dav850evm_nand in boards.cfg with the added parameter USE_NAND. The resulting AIS file was programmed into EVM-compatible NAND using standard sfh_OMAP-L138 method. The board failed to boot, and stayed in a loop printing the SPL console message repeatedly. After some debugging with CCS 5.5 and an XDS100v2, I found that incorrect code was being loaded into the 0xc108000 RAM destination. The da850evm.h file defines CONFIG_SYS_NAND_U_BOOT_OFFS as 0x28000, which corresponds to an AIS offset of 0x8000 but the u-boot header did not appear there in the AIS file. A search revealed that the Makefile catenated u-boot immediately after the SPL without any padding. Further investigation revealed that the target Makefile needs CONFIG_SPL_MAX_SIZE to be defined as 0x8000 in order for the padding to be performed properly; however, this constant was apparently deleted during a series of changes in April, 2013 to accommodate separate code and BSS size limits for another target. In its place, CONFIG_SPL_MAX_FOOTPRINT was defined as 32768. Unfortunately, the da850evm Makefile does not refer to this constant. To solve the problem, I added the following 2 lines in my custom-modified da850evm.h: # define CONFIG_SPL_PAD_TO0x8000 # define CONFIG_SPL_MAX_SIZE 0x8000 although the first line may not be strictly required. Yes, CONFIG_SPL_PAD_TO is currently not used for the 'make u-boot.ais' target in the Makefile. Instead, the Makefile uses CONFIG_SPL_MAX_SIZE for padding the SPL, which is probably wrong. This solved the problem and allowed the board to boot. Doesn't this mean that other similar targets may be broken? I think yes. I think the right fix would be to change the Makefile to use CONFIG_SPL_PAD_TO instead of CONFIG_SPL_MAX_SIZE for the u-boot.ais target. diff --git a/Makefile b/Makefile index ff38a43..869f442 100644 --- a/Makefile +++ b/Makefile @@ -890,7 +890,7 @@ MKIMAGEFLAGS_u-boot-spl.ais = -s -n $(if $(CONFIG_AIS_CONFIG_FILE), \ spl/u-boot-spl.ais: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_MAX_SIZE) +OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) u-boot.ais: spl/u-boot-spl.ais u-boot.img FORCE $(call if_changed,pad_cat) And then check all ARM926EJS/Davinci configurations that use SPL: (extending Tom Rini's grep command from his email) $ git grep -l ARM926EJS include/configs/ | xargs grep -l DAVINCI | xargs grep -l _SPL_ include/configs/cam_enc_4xx.h include/configs/da830evm.h include/configs/da850evm.h include/configs/hawkboard.h include/configs/ipam390.h For the cam_enc_4xx CONFIG_SPL_PAD_TO is already defined, so it should work fine after fixing the Makefile. Heiko, any comments on this? Are you actually using the u-boot.ais target? da830evm and hawkboard did not use CONFIG_SPL_MAX_SIZE, so no need to fix them. da850evm: We should add CONFIG_SPL_PAD_TO as already suggested by you. ipam390.h: I think the #define CONFIG_SPL_MAX_SIZE 0x2 should be removed or replaced by #define CONFIG_SPL_PAD_TO 0x2. But actually the board has been added after the commits that replace CONFIG_SPL_MAX_SIZE by CONFIG_SPL_MAX_FOOTPRINT, so why didn't that issue come up when adding the board to mainline? Heiko, any comments? Are you using make u-boot.ais here or something else? Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DA850EVM with USE_NAND config does not pad the AIS file
Tom, Thank you very much for your investigations :-) --On April 26, 2014 13:34 -0400 Tom Taylor ttaylor.ta...@gmail.com wrote: I'm a U-Boot newbie so please feel free to correct how I'm reporting this issue.. I recently downloaded the 2014.04-rc3 snapshot to build U-Boot for my custom DA850-based board. The only change was to add a new target dav850evm_nand in boards.cfg with the added parameter USE_NAND. The resulting AIS file was programmed into EVM-compatible NAND using standard sfh_OMAP-L138 method. The board failed to boot, and stayed in a loop printing the SPL console message repeatedly. After some debugging with CCS 5.5 and an XDS100v2, I found that incorrect code was being loaded into the 0xc108000 RAM destination. The da850evm.h file defines CONFIG_SYS_NAND_U_BOOT_OFFS as 0x28000, which corresponds to an AIS offset of 0x8000 but the u-boot header did not appear there in the AIS file. A search revealed that the Makefile catenated u-boot immediately after the SPL without any padding. Further investigation revealed that the target Makefile needs CONFIG_SPL_MAX_SIZE to be defined as 0x8000 in order for the padding to be performed properly; however, this constant was apparently deleted during a series of changes in April, 2013 to accommodate separate code and BSS size limits for another target. In its place, CONFIG_SPL_MAX_FOOTPRINT was defined as 32768. Unfortunately, the da850evm Makefile does not refer to this constant. To solve the problem, I added the following 2 lines in my custom-modified da850evm.h: # define CONFIG_SPL_PAD_TO0x8000 # define CONFIG_SPL_MAX_SIZE 0x8000 although the first line may not be strictly required. Yes, CONFIG_SPL_PAD_TO is currently not used for the 'make u-boot.ais' target in the Makefile. Instead, the Makefile uses CONFIG_SPL_MAX_SIZE for padding the SPL, which is probably wrong. This solved the problem and allowed the board to boot. Doesn't this mean that other similar targets may be broken? I think yes. I think the right fix would be to change the Makefile to use CONFIG_SPL_PAD_TO instead of CONFIG_SPL_MAX_SIZE for the u-boot.ais target. diff --git a/Makefile b/Makefile index ff38a43..869f442 100644 --- a/Makefile +++ b/Makefile @@ -890,7 +890,7 @@ MKIMAGEFLAGS_u-boot-spl.ais = -s -n $(if $(CONFIG_AIS_CONFIG_FILE), \ spl/u-boot-spl.ais: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_MAX_SIZE) +OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) u-boot.ais: spl/u-boot-spl.ais u-boot.img FORCE $(call if_changed,pad_cat) And then check all ARM926EJS/Davinci configurations that use SPL: (extending Tom Rini's grep command from his email) $ git grep -l ARM926EJS include/configs/ | xargs grep -l DAVINCI | xargs grep -l _SPL_ include/configs/cam_enc_4xx.h include/configs/da830evm.h include/configs/da850evm.h include/configs/hawkboard.h include/configs/ipam390.h For the cam_enc_4xx CONFIG_SPL_PAD_TO is already defined, so it should work fine after fixing the Makefile. Heiko, any comments on this? Are you actually using the u-boot.ais target? da830evm and hawkboard did not use CONFIG_SPL_MAX_SIZE, so no need to fix them. da850evm: We should add CONFIG_SPL_PAD_TO as already suggested by you. ipam390.h: I think the #define CONFIG_SPL_MAX_SIZE 0x2 should be removed or replaced by #define CONFIG_SPL_PAD_TO 0x2. But actually the board has been added after the commits that replace CONFIG_SPL_MAX_SIZE by CONFIG_SPL_MAX_FOOTPRINT, so why didn't that issue come up when adding the board to mainline? Heiko, any comments? Are you using make u-boot.ais here or something else? Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm, davinci: Use CONFIG_SPL_PAD_TO for padding the SPL in an ais image
The commits commit b7b5f1a16ca66dfdd817e7339f0e263a5b9f2758 Author: Albert ARIBAUD albert.u.b...@aribaud.net da850evm, da850_am18xxevm: convert to CONFIG_SPL_MAX_FOOTPRINT and commit e7497891e34efe5cb2b3a3dc7c6c096c012ede28 Author: Albert ARIBAUD albert.u.b...@aribaud.net cam_enc_4xx: convert to CONFIG_SPL_MAX_FOOTPRINT replaced CONFIG_SPL_MAX_SIZE by CONFIG_SPL_MAX_FOOTPRINT. However, CONFIG_SPL_MAX_SIZE is used in the Makefile for padding the SPL when preparing an u-boot.ais image. By removing CONFIG_SPL_MAX_SIZE said commits broke the ais image of the da850evm and cam_enc_4xx configurations. This patch converts the u-boot.ais target to use CONFIG_SPL_PAD_TO instead of CONFIG_SPL_MAX_SIZE for padding the SPL and adds a #define CONFIG_SPL_PAD_TO where it is required. Signed-off-by: Christian Riesch christian.rie...@omicron.at Reported-by: Tom Taylor ttaylor.ta...@gmail.com Cc: Sudhakar Rajashekhara sudhakar@ti.com Cc: Heiko Schocher h...@denx.de Cc: Albert ARIBAUD albert.u.b...@aribaud.net --- Makefile |2 +- include/configs/da850evm.h |1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index ff38a43..869f442 100644 --- a/Makefile +++ b/Makefile @@ -890,7 +890,7 @@ MKIMAGEFLAGS_u-boot-spl.ais = -s -n $(if $(CONFIG_AIS_CONFIG_FILE), \ spl/u-boot-spl.ais: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_MAX_SIZE) +OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) u-boot.ais: spl/u-boot-spl.ais u-boot.img FORCE $(call if_changed,pad_cat) diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h index 509fe20..0ca0c8d 100644 --- a/include/configs/da850evm.h +++ b/include/configs/da850evm.h @@ -386,6 +386,7 @@ #define CONFIG_SPL_STACK 0x8001ff00 #define CONFIG_SPL_TEXT_BASE 0x8000 #define CONFIG_SPL_MAX_FOOTPRINT 32768 +#define CONFIG_SPL_PAD_TO 32768 #endif /* Load U-Boot Image From MMC */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DA850EVM with USE_NAND config does not pad the AIS file
Hello Heiko, --On May 06, 2014 16:46 +0200 Heiko Schocher h...@denx.de wrote: Hello Christian, Am 06.05.2014 13:30, schrieb Christian Riesch: Tom, Thank you very much for your investigations :-) --On April 26, 2014 13:34 -0400 Tom Taylor ttaylor.ta...@gmail.com wrote: I'm a U-Boot newbie so please feel free to correct how I'm reporting this issue.. I recently downloaded the 2014.04-rc3 snapshot to build U-Boot for my custom DA850-based board. The only change was to add a new target dav850evm_nand in boards.cfg with the added parameter USE_NAND. The resulting AIS file was programmed into EVM-compatible NAND using standard sfh_OMAP-L138 method. The board failed to boot, and stayed in a loop printing the SPL console message repeatedly. After some debugging with CCS 5.5 and an XDS100v2, I found that incorrect code was being loaded into the 0xc108000 RAM destination. The da850evm.h file defines CONFIG_SYS_NAND_U_BOOT_OFFS as 0x28000, which corresponds to an AIS offset of 0x8000 but the u-boot header did not appear there in the AIS file. A search revealed that the Makefile catenated u-boot immediately after the SPL without any padding. Further investigation revealed that the target Makefile needs CONFIG_SPL_MAX_SIZE to be defined as 0x8000 in order for the padding to be performed properly; however, this constant was apparently deleted during a series of changes in April, 2013 to accommodate separate code and BSS size limits for another target. In its place, CONFIG_SPL_MAX_FOOTPRINT was defined as 32768. Unfortunately, the da850evm Makefile does not refer to this constant. To solve the problem, I added the following 2 lines in my custom-modified da850evm.h: # define CONFIG_SPL_PAD_TO 0x8000 # define CONFIG_SPL_MAX_SIZE 0x8000 although the first line may not be strictly required. Yes, CONFIG_SPL_PAD_TO is currently not used for the 'make u-boot.ais' target in the Makefile. Instead, the Makefile uses CONFIG_SPL_MAX_SIZE for padding the SPL, which is probably wrong. Yes, CONFIG_SPL_PAD_TO is the correct define. On the other hand the question is is CONFIG_SPL_PAD_TO not always equal to CONFIG_SPL_MAX_SIZE ? I guess yes. This solved the problem and allowed the board to boot. Doesn't this mean that other similar targets may be broken? I think yes. I think the right fix would be to change the Makefile to use CONFIG_SPL_PAD_TO instead of CONFIG_SPL_MAX_SIZE for the u-boot.ais target. diff --git a/Makefile b/Makefile index ff38a43..869f442 100644 --- a/Makefile +++ b/Makefile @@ -890,7 +890,7 @@ MKIMAGEFLAGS_u-boot-spl.ais = -s -n $(if $(CONFIG_AIS_CONFIG_FILE), \ spl/u-boot-spl.ais: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_MAX_SIZE) +OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) u-boot.ais: spl/u-boot-spl.ais u-boot.img FORCE $(call if_changed,pad_cat) And then check all ARM926EJS/Davinci configurations that use SPL: (extending Tom Rini's grep command from his email) $ git grep -l ARM926EJS include/configs/ | xargs grep -l DAVINCI | xargs grep -l _SPL_ include/configs/cam_enc_4xx.h include/configs/da830evm.h include/configs/da850evm.h include/configs/hawkboard.h include/configs/ipam390.h For the cam_enc_4xx CONFIG_SPL_PAD_TO is already defined, so it should work fine after fixing the Makefile. Heiko, any comments on this? Are you actually using the u-boot.ais target? I have no board to test, but I think it is used. da830evm and hawkboard did not use CONFIG_SPL_MAX_SIZE, so no need to fix them. da850evm: We should add CONFIG_SPL_PAD_TO as already suggested by you. ipam390.h: I think the #define CONFIG_SPL_MAX_SIZE 0x2 should be removed or replaced by #define CONFIG_SPL_PAD_TO 0x2. But actually the board has been added after the commits that replace grep -lr CONFIG_SPL_MAX_SIZE by CONFIG_SPL_MAX_FOOTPRINT, so why didn't that issue come up when adding the board to mainline? Heiko, any comments? Are you using make u-boot.ais here or something else? I am not sure, if we can just remove CONFIG_SPL_MAX_SIZE for this board, as it maybe has only 0x2 space for the SPL ? I had another look at ipam390.h, currently there is #define CONFIG_SPL_MAX_SIZE 0x2 #define CONFIG_SPL_MAX_FOOTPRINT32768 So according to README, the linker checks if the SPL including BSS is smaller than 32kB, and if the SPL excluding BSS is smaller than 128 kB. So the check against CONFIG_SPL_MAX_SIZE is always fulfilled. Therefore it is save to replace CONFIG_SPL_MAX_SIZE with CONFIG_SPL_PAD_TO. maybe: # if !defined(CONFIG_SPL_PAD_TO) define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE # endif is better? Heh, thats the case, see: ./include/config_fallbacks.h so, your Makefile patch should be Ok ... Ok, so no change is required for ipam390. I'll send a patch. Christian bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235
[U-Boot] [PATCH] da850evm: Use clrbits function with correct endianess
The current code uses clrbits_be32 which is incorrect since we are on
a little endian machine here. This patch fixes this issue and also removes
some unnecessary code: Reading the current GPIO bank state is not required
if we are using the SET and CLEAR GPIO registers for setting/clearing
bits.
Signed-off-by: Christian Riesch christian.rie...@omicron.at
Cc: Nagabhushana Netagunte nagabhushana.netagu...@ti.com
Cc: Rajashekhara, Sudhakar sudhakar@ti.com
---
Hi,
due to lack of hardware I only compile tested this code.
I am looking forward to your comments.
Regards, Christian
board/davinci/da8xxevm/da850evm.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/board/davinci/da8xxevm/da850evm.c
b/board/davinci/da8xxevm/da850evm.c
index 0c7aabb..147013c 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -335,10 +335,6 @@ int board_early_init_f(void)
int board_init(void)
{
-#if defined(CONFIG_USE_NOR) || defined(CONFIG_DAVINCI_MMC)
- u32 val;
-#endif
-
#ifndef CONFIG_USE_IRQ
irq_init();
#endif
@@ -378,12 +374,10 @@ int board_init(void)
#ifdef CONFIG_USE_NOR
/* Set the GPIO direction as output */
- clrbits_be32((u32 *)GPIO_BANK0_REG_DIR_ADDR, (0x01 11));
+ clrbits_le32((u32 *)GPIO_BANK0_REG_DIR_ADDR, (0x01 11));
/* Set the output as low */
- val = readl(GPIO_BANK0_REG_SET_ADDR);
- val |= (0x01 11);
- writel(val, GPIO_BANK0_REG_CLR_ADDR);
+ writel(0x01 11, GPIO_BANK0_REG_CLR_ADDR);
#endif
#ifdef CONFIG_DAVINCI_MMC
@@ -391,9 +385,7 @@ int board_init(void)
clrbits_le32((u32 *)GPIO_BANK0_REG_DIR_ADDR, (0x01 11));
/* Set the output as high */
- val = readl(GPIO_BANK0_REG_SET_ADDR);
- val |= (0x01 11);
- writel(val, GPIO_BANK0_REG_SET_ADDR);
+ writel(0x01 11, GPIO_BANK0_REG_SET_ADDR);
#endif
#ifdef CONFIG_DRIVER_TI_EMAC
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] [PATCH] arm: da830: moved pinmux configurations to the arch tree
On 2013-05-30 09:55, Vishwanathrao Badarkhe, Manish wrote: Move pinmux configurations for the DA830 SoCs from board file to the arch tree so that it can be used for all da830 based devices. Also, avoids duplicate pinmuxing in case of NAND. Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com Acked-by: Christian Riesch christian.rie...@omicron.at Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] calimain: Generate random MAC address for factory tests
Hello Wolfgang,
Thank you again for your comments.
On 2013-01-08 18:39, Wolfgang Denk wrote:
Dear Christian Riesch,
In message 6cc4810c-1e2e-4ebf-912a-96936f035...@mary.at.omicron.at you wrote:
Signed-off-by: Christian Riesch christian.rie...@omicron.at
---
board/omicron/calimain/calimain.c | 31 ++-
include/configs/calimain.h|2 ++
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/board/omicron/calimain/calimain.c
b/board/omicron/calimain/calimain.c
index 1060a1f..80e3893 100644
--- a/board/omicron/calimain/calimain.c
+++ b/board/omicron/calimain/calimain.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2011 OMICRON electronics GmbH
+ * Copyright (C) 2011-2013 OMICRON electronics GmbH
*
* Based on da850evm.c. Original Copyrights follow:
*
@@ -136,6 +136,35 @@ int board_init(void)
return 0;
}
+/* seed random number generator with uninitialized SRAM content */
+static void srand_sram(void)
+{
+ int *p;
+ int seed = 0;
+
+ for (p = (int *) 0x8000; p (int *) 0x8001; p++)
+ seed ^= *p;
+
+ srand(seed);
+}
Note that your uninitialized SRAM content is probably not so much
random at all -
There are several papers around describing the use of initial SRAM value
after power up for the generation of random numbers. This is why I gave
it a try, and it works pretty well for me. I get a different seed for
each power-up cycle. I guess that the randomness is limited and that
part of the generated seed is more a fingerprint for the chip, therefore
it may not be good enough for security related stuff, but for my purpose
it's ok.
I guess, it is much less random than the originally
used timer value.
In my case the timer value is not random at all since it is reset to
zero at power-up. Since seeding the random number generator is always
done at the same time after power-up in the current code, the seed will
always be the same for my devices. Therefore the generated MAC address
will always be the same for all devices.
What exactly is your justification for such a change? Please
elucidate...
Actually I do not change anything ;-)
For the lsxl board that is currently the only user of eth_random_enet(),
nothing changes. get_timer(0) remains the source of the randomness for
this board. My patches only allow other boards to use a sources of
randomness that is available to them instead of forcing everyone to use
get_timer(0).
+int board_late_init(void)
+{
+ uchar enetaddr[6];
+
+ if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
+ srand_sram();
+ eth_random_enetaddr(enetaddr);
+ if (eth_setenv_enetaddr(ethaddr, enetaddr)) {
+ printf(Failed to set random ethernet address\n);
+ } else {
+ printf(Setting random ethernet address %pM.\n,
+ enetaddr);
+ }
+ }
+ return 0;
+}
NAK! You are but duplicating the code already present in net/eth.c
Apparently I am missing something here. I do not see a call of
eth_random_enetaddr() in net/eth.c. To which part of net/eth.c are you
referring?
Regards, Christian
This makes no sense.
Best regards,
Wolfgang Denk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] calimain: Generate random MAC address for factory tests
Signed-off-by: Christian Riesch christian.rie...@omicron.at
---
board/omicron/calimain/calimain.c | 31 ++-
include/configs/calimain.h|2 ++
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/board/omicron/calimain/calimain.c
b/board/omicron/calimain/calimain.c
index 1060a1f..80e3893 100644
--- a/board/omicron/calimain/calimain.c
+++ b/board/omicron/calimain/calimain.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2011 OMICRON electronics GmbH
+ * Copyright (C) 2011-2013 OMICRON electronics GmbH
*
* Based on da850evm.c. Original Copyrights follow:
*
@@ -136,6 +136,35 @@ int board_init(void)
return 0;
}
+/* seed random number generator with uninitialized SRAM content */
+static void srand_sram(void)
+{
+ int *p;
+ int seed = 0;
+
+ for (p = (int *) 0x8000; p (int *) 0x8001; p++)
+ seed ^= *p;
+
+ srand(seed);
+}
+
+int board_late_init(void)
+{
+ uchar enetaddr[6];
+
+ if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
+ srand_sram();
+ eth_random_enetaddr(enetaddr);
+ if (eth_setenv_enetaddr(ethaddr, enetaddr)) {
+ printf(Failed to set random ethernet address\n);
+ } else {
+ printf(Setting random ethernet address %pM.\n,
+ enetaddr);
+ }
+ }
+ return 0;
+}
+
#ifdef CONFIG_DRIVER_TI_EMAC
/*
* Initializes on-board ethernet controllers.
diff --git a/include/configs/calimain.h b/include/configs/calimain.h
index 5c2b35d..8cea0d9 100644
--- a/include/configs/calimain.h
+++ b/include/configs/calimain.h
@@ -30,6 +30,7 @@
#define CONFIG_DRIVER_TI_EMAC
#define MACH_TYPE_CALIMAIN 3528
#define CONFIG_MACH_TYPE MACH_TYPE_CALIMAIN
+#define CONFIG_BOARD_LATE_INIT
/*
* SoC Configuration
@@ -202,6 +203,7 @@
#define CONFIG_BOOTP_DNS2
#define CONFIG_BOOTP_SEND_HOSTNAME
#define CONFIG_NET_RETRY_COUNT 10
+#define CONFIG_RANDOM_MACADDR
#endif
/*
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] net: Remove call of srand from eth_random_enetaddr()
Currently eth_random_enetaddr() seeds the random number generator with
get_timer(0). Some boards might want to use other sources for the seed,
therefore move the call of srand() to the board specific code.
Signed-off-by: Christian Riesch christian.rie...@omicron.at
Cc: Michael Walle mich...@walle.cc
Cc: Joe Hershberger joe.hershber...@gmail.com
---
board/buffalo/lsxl/lsxl.c |1 +
include/net.h |3 +++
net/eth.c |2 --
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/board/buffalo/lsxl/lsxl.c b/board/buffalo/lsxl/lsxl.c
index 57776fb..b7eb0dc 100644
--- a/board/buffalo/lsxl/lsxl.c
+++ b/board/buffalo/lsxl/lsxl.c
@@ -248,6 +248,7 @@ static void rescue_mode(void)
printf(Entering rescue mode..\n);
#ifdef CONFIG_RANDOM_MACADDR
if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
+ srand(get_timer(0));
eth_random_enetaddr(enetaddr);
if (eth_setenv_enetaddr(ethaddr, enetaddr)) {
printf(Failed to set ethernet address\n);
diff --git a/include/net.h b/include/net.h
index 970d4d1..5fc3693 100644
--- a/include/net.h
+++ b/include/net.h
@@ -141,6 +141,9 @@ extern int eth_getenv_enetaddr_by_index(const char
*base_name, int index,
*
* In these cases, we generate a random locally administered ethernet address.
*
+ * Remember to seed the random number generator with srand() before calling
+ * this functon.
+ *
* Args:
* enetaddr - returns 6 byte hardware address
*/
diff --git a/net/eth.c b/net/eth.c
index 321d5b1..dc4cc20 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -84,8 +84,6 @@ void eth_random_enetaddr(uchar *enetaddr)
{
uint32_t rval;
- srand(get_timer(0));
-
rval = rand();
enetaddr[0] = rval 0xff;
enetaddr[1] = (rval 8) 0xff;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] calimain: Generate random MAC address for factory testing
Hi, This patchset allows the calimain board to use a random MAC address if no MAC address has been set yet. We use this feature for tests during production of our boards. Later, official MAC addresses are assigned to the boards. To seed the random number generator I use the content of the uninitialized SRAM of the AM1808 SoC. Regards, Christian Cc: Tom Rini tr...@ti.com Cc: Joe Hershberger joe.hershber...@gmail.com Cc: Michael Walle mich...@walle.cc Christian Riesch (2): net: Remove call of srand from eth_random_enetaddr() calimain: Generate random MAC address for factory tests board/buffalo/lsxl/lsxl.c |1 + board/omicron/calimain/calimain.c | 31 ++- include/configs/calimain.h|2 ++ include/net.h |3 +++ net/eth.c |2 -- 5 files changed, 36 insertions(+), 3 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: Remove call of srand from eth_random_enetaddr()
Hello Wolfgang, Thank you for your comments. On Tuesday, January 8, 2013, Wolfgang Denk wrote: Dear Christian Riesch, In message 419e5c6e-b2ef-44c2-a4c1-bb25c50fc...@mary.at.omicron.atjavascript:; you wrote: Currently eth_random_enetaddr() seeds the random number generator with get_timer(0). Some boards might want to use other sources for the seed, therefore move the call of srand() to the board specific code. Signed-off-by: Christian Riesch christian.rie...@omicron.atjavascript:; Cc: Michael Walle mich...@walle.cc Cc: Joe Hershberger joe.hershber...@gmail.com javascript:; I don't like this change. What exactly is wrong with using the timer here? It is probably much more random that the (so-called) un-initialized memory you suggest to use instead. On the AM1808 SoC the counter is reset to zero on power up. So using it to generate random numbers in code that is called interactively by the user is fine and will yield a random MAC address, but in my case I will get the same MAC address on each board at each power up. If there is really need to use another inital valu, only this should be fixed - but the srand() call itself should remain as is. For other boards it may be ok to use a counter, and for some there may be no SRAM or it may be already overwritten, e.g by the SPL... Therefore I am not changing this for all boards, but make it board specific. Regards, Christian You cannot do this. 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.dejavascript:; You can observe a lot just by watchin'. - Yogi Berra ___ U-Boot mailing list U-Boot@lists.denx.de javascript:; http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2013.01-rc2 released
Hi Tom, On Fri, Dec 14, 2012 at 10:52 PM, Tom Rini tr...@ti.com wrote: Hey all, I've tagged and pushed v2013.01-rc2 now. The next branch has been open for a little bit, and is still open now, and in sync. Here's where we're at: - I expect a USB pull request from Marek soon. - I've locally build-tested Simon's gd-arch series and will run-time test it on a few platforms I have soon now. - I know Albert is around and working on a u-boot-arm pull request. In my TODO list in patchwork, nothing strikes me as new feature posted before the merge window closed. I see a few bug fixes I might pull in, or might sit on to make sure they don't cause surprises. It's of course possible I missed something, or something is assigned to someone else so if this strikes anyone as wrong, please speak up now. Also, if you have any bugfixes you expect me to pull, please get them out sooner rather than later. The release is still planned for Jan 15, a month away, but there's holidays in there which mean both some folks are not working and other folks have some free time for hobby projects. The 'make env' build is currently (v2013.01-rc2) broken for me, the fix is http://patchwork.ozlabs.org/patch/198243/ The patchset includes also these patches, please see the comments/ACKs/NAKs. http://patchwork.ozlabs.org/patch/198241/ http://patchwork.ozlabs.org/patch/198242/ Thank you! Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] fw_env: fix incorrect usage of open(O_CREAT)
Hi,
On Sun, Nov 11, 2012 at 6:47 AM, Mike Frysinger vap...@gentoo.org wrote:
When using open(), the O_CREAT flag must be given a mode, otherwise it
uses random garbage from the stack. Also, it can fail to build:
In file included from /usr/include/fcntl.h:290:0,
from fw_env_main.c:42:
In function 'open',
inlined from 'main' at fw_env_main.c:97:9:
/usr/include/bits/fcntl2.h:50:24: error: call to '__open_missing_mode'
declared
with attribute error: open with O_CREAT in second argument needs 3
arguments
Could someone please pick up this patchset?
http://patchwork.ozlabs.org/patch/198241/
http://patchwork.ozlabs.org/patch/198243/
http://patchwork.ozlabs.org/patch/198242/
make env is currently broken for me.
Thank you!
Regards, Christian
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
tools/env/fw_env_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/env/fw_env_main.c b/tools/env/fw_env_main.c
index c855f4c..40ea3f6 100644
--- a/tools/env/fw_env_main.c
+++ b/tools/env/fw_env_main.c
@@ -94,7 +94,7 @@ int main(int argc, char *argv[])
int lockfd = -1;
int retval = EXIT_SUCCESS;
- lockfd = open(lockname, O_WRONLY | O_CREAT | O_TRUNC);
+ lockfd = open(lockname, O_WRONLY | O_CREAT | O_TRUNC, 0666);
if (-1 == lockfd) {
fprintf(stderr, Error opening lock file %s\n, lockname);
return EXIT_FAILURE;
--
1.7.12.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
Hi, On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut ma...@denx.de wrote: Dear José Miguel Gonçalves, On 09/16/2012 11:06 AM, Marek Vasut wrote: Dear José Miguel Gonçalves, On 09/15/2012 07:03 PM, Marek Vasut wrote: Dear José Miguel Gonçalves, Jumping to board_init_r is not performed due to a bug on address computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue. The issue is what I've explained in the patch comments. Jumping to board_init_r is not performed due to a bug on address computation. Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway .. Same for me - I have no idea what you are trying to fix here. In my SPL configuration, _TEXT_BASE and _start point to the same location, so please explain why they are different on your board. Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL or something like that. Marek, going into board_init_r is fine for SPL, for example the davinci SPL does some hw initialization in board_init_f and then loads u-boot in board_init_r. Regards, Christian What do you boot the rest from ? If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board. Relocation offsets are not needed when building SPL. Do they cause any trouble? No! Just not needed. Signed-off-by: José Miguel Gonçalves jose.goncal...@inov.pt --- Changes for v2: - None --- arch/arm/cpu/arm926ejs/start.S |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot #else ldr r0, _board_init_r_ofs -ldr r1, _TEXT_BASE +adr r1, _start add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */ @@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start #endif +#ifndef CONFIG_SPL_BUILD _rel_dyn_start_ofs: .word __rel_dyn_start - _start _rel_dyn_end_ofs: .word __rel_dyn_end - _start _dynsym_start_ofs: .word __dynsym_start - _start +#endif /* ** *** Best regards, Marek Vasut Best regards, José Gonçalves Best regards, Marek Vasut Best regards, José Gonçalves ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
Hi,
On Sun, Sep 16, 2012 at 11:27 AM, José Miguel Gonçalves
jose.goncal...@inov.pt wrote:
On 09/14/2012 08:08 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
Samsung's S3C24XX SoCs need this in order to generate a binary image
with the SPL and U-Boot concatenated.
Signed-off-by: Jos?? Miguel Gon??alves jose.goncal...@inov.pt
---
Changes for v2:
- None
---
Makefile |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 058fb53..595b5f6 100644
--- a/Makefile
+++ b/Makefile
@@ -442,13 +442,14 @@ $(obj)u-boot.sha1:$(obj)u-boot.bin
$(obj)u-boot.dis: $(obj)u-boot
$(OBJDUMP) -d $ $@
-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
+$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
$(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin
$(obj)u-boot-ubl.bin
+ rm $(obj)spl/u-boot-spl-pad.bin
+
+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
$(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
-e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
$(obj)u-boot.ubl
- rm $(obj)u-boot-ubl.bin
- rm $(obj)spl/u-boot-spl-pad.bin
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(obj)tools/mkimage -s -n $(if
$(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),/dev/null) \
This diff is hard to read, but what exactly are you changing? The
u-boot-ubl target is also used on TI platforms. It looks like you're
making it such that u-boot-ubl.bin produces the old binary and
u-boot-ubl adds a new target which is the mkimage header on top of the
same bits as before, but without possibly padding the output image. I
suspect in your case you could just set PAD_TO to 8192 in
board/../config.mk and use the existing target.
In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL image
padded at 8KB concatenated with the standard U-Boot. What I've done was to
split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use to
program the Flash, and u-boot-ubl that remains with the same functionality
as before, just now it depends on u-boot-ubl.bin.
I think you should drop the UBL names from your padding target
(u-boot-ubl.bin) since this is TI specific, use something more
generic.
Regards, Christian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
Hi, On Mon, Sep 17, 2012 at 10:34 AM, José Miguel Gonçalves jose.goncal...@inov.pt wrote: On 09/17/2012 07:28 AM, Christian Riesch wrote: Hi, On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut ma...@denx.de wrote: Dear José Miguel Gonçalves, On 09/16/2012 11:06 AM, Marek Vasut wrote: Dear José Miguel Gonçalves, On 09/15/2012 07:03 PM, Marek Vasut wrote: Dear José Miguel Gonçalves, Jumping to board_init_r is not performed due to a bug on address computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue. The issue is what I've explained in the patch comments. Jumping to board_init_r is not performed due to a bug on address computation. Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway .. Same for me - I have no idea what you are trying to fix here. In my SPL configuration, _TEXT_BASE and _start point to the same location, so please explain why they are different on your board. They are different because of how start.S is implemented in arm926ejs. In my SPL map file I see: .text 0x 0xc24 arch/arm/cpu/arm926ejs/start.o(.text) .text 0x 0x120 arch/arm/cpu/arm926ejs/start.o 0x_start 0x0040_TEXT_BASE 0x0044_bss_start_ofs 0x0048_bss_end_ofs 0x004c_end_ofs 0x0050IRQ_STACK_START_IN 0x0074relocate_code So _start is 0x, and in your config/include/include/configs/mini2416.h you have #define CONFIG_SPL_TEXT_BASE 0x and in arch/arm/cpu/arm926ejs/start.S we have .globl _TEXT_BASE _TEXT_BASE: #ifdef CONFIG_NAND_SPL /* deprecated, use instead CONFIG_SPL_BUILD */ .word CONFIG_SYS_TEXT_BASE #else #ifdef CONFIG_SPL_BUILD .word CONFIG_SPL_TEXT_BASE #else .word CONFIG_SYS_TEXT_BASE #endif #endif So ldr r1, _TEXT_BASE should be the same as adr r1, _start However, if you do not load your SPL to 0x but to another address and execute it from there, it will be different, since adr uses relative adressing, right? Are you sure you are loading it to 0x? Regards, Christian Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL or something like that. Marek, going into board_init_r is fine for SPL, for example the davinci SPL does some hw initialization in board_init_f and then loads u-boot in board_init_r. Regards, Christian What do you boot the rest from ? If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board. Relocation offsets are not needed when building SPL. Do they cause any trouble? No! Just not needed. Signed-off-by: José Miguel Gonçalves jose.goncal...@inov.pt --- Changes for v2: - None --- arch/arm/cpu/arm926ejs/start.S |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot #else ldr r0, _board_init_r_ofs -ldr r1, _TEXT_BASE +adr r1, _start add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */ @@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start #endif +#ifndef CONFIG_SPL_BUILD _rel_dyn_start_ofs: .word __rel_dyn_start - _start _rel_dyn_end_ofs: .word __rel_dyn_end - _start _dynsym_start_ofs: .word __dynsym_start - _start +#endif /* ** *** Best regards, Marek Vasut Best regards, José Gonçalves Best regards, Marek Vasut Best regards, José Gonçalves Best regards, José Gonçalves ___ U-Boot mailing list U-Boot
Re: [U-Boot] [PATCH v5 20/25] da850: Add README.da850
On Tue, Aug 28, 2012 at 1:18 AM, Tom Rini tr...@ti.com wrote: This file documents when to build for da850evm and when to build for da850_am18xxevm. It also documents how to write the u-boot.ais file to persistent storage (such as SPI), in some cases as well as how to write a recovery image. Signed-off-by: Tom Rini tr...@ti.com Acked-by: Christian Riesch christian.rie...@omicron.at Regards, Christian --- Changes in v2: - Add README.da850_am18xxevm Changes in v3: - Fix thinko, Nand - SPI (spotted by Prabhakar Lad) - Rename to README.da850, add more direct recovery method (Christian Riesch) Changes in v4: - Further re-word README.da850 based on feedback from Christian Riesch board/davinci/da8xxevm/README.da850 | 68 +++ 1 file changed, 68 insertions(+) create mode 100644 board/davinci/da8xxevm/README.da850 diff --git a/board/davinci/da8xxevm/README.da850 b/board/davinci/da8xxevm/README.da850 new file mode 100644 index 000..621a95d --- /dev/null +++ b/board/davinci/da8xxevm/README.da850 @@ -0,0 +1,68 @@ +Summary +=== +The README is for the boot procedure used for various DA850 (or compatible +parts such as the AM1808) based boards. + +In the context of U-Boot, the board is booted in three stages. The initial +bootloader which executes upon reset is the ROM Boot Loader (RBL) and sits +in the internal ROM. The RBL initializes the internal memory and then +depending on the exact board and pin configurations will initialize another +controller (such as SPI or NAND) to continue the boot process by loading +the secondary program loader (SPL). The SPL will initialize the system +further (some clocks, SDRAM) and then load the full u-boot from a +predefined location in persistent storage to DDR and jumps to the u-boot +entry point. + +AIS is an image format defined by TI for the images that are to be loaded +to memory by the RBL. The image is divided into a series of sections and +the image's entry point is specified. Each section comes with meta data +like the target address the section is to be copied to and the size of the +section, which is used by the RBL to load the image. At the end of the +image the RBL jumps to the image entry point. The AIS format allows for +other things such as programming the clocks and SDRAM if the header is +programmed for it. We do not take advantage of this and instead use SPL as +it allows for additional flexibility (run-time detect of board revision, +loading the next image from a different media, etc). + + +Compilation +=== +The exact build target you need will depend on the board you have. For +Logic PD boards, or other boards which store the ethernet MAC address at +the end of SPI flash, run 'make da850evm'. For boards which store the +ethernet MAC address in the i2c EEPROM located at 0x50, run +'make da850_am18xxevm'. Once this build completes you will have a +u-boot.ais file that needs to be written to the correct persistent +storage. + + +Flashing the images to SPI +== +The AIS image can be written to SPI flash using the following commands. +Assuming that the network is configured and enabled and the u-boot.ais file +is tftp'able. + +U-Boot sf probe 0 +U-Boot sf erase 0 +32 +U-Boot tftp u-boot.ais +U-Boot sf write c070 0 $filesize + + +Recovery + + +In the case of a bricked board, you need to use the TI tools found +here[1] to write the u-boot.ais file. An example of recovering to the SPI +flash of an AM1808 would be: + +$ mono sfh_OMAP-L138.exe -targetType AM1808 -p /dev/ttyUSB0 \ + -flash_noubl /path/to/u-boot.ais + +For other target types and flash locations: + +$ mono sfh_OMAP-L138.exe -h + +Links += +[1] + http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L137 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 20/25] da850: Add README.da850
Hi Tom, one more comment, please see below. On Tue, Aug 28, 2012 at 1:18 AM, Tom Rini tr...@ti.com wrote: This file documents when to build for da850evm and when to build for da850_am18xxevm. It also documents how to write the u-boot.ais file to persistent storage (such as SPI), in some cases as well as how to write a recovery image. Signed-off-by: Tom Rini tr...@ti.com --- Changes in v2: - Add README.da850_am18xxevm Changes in v3: - Fix thinko, Nand - SPI (spotted by Prabhakar Lad) - Rename to README.da850, add more direct recovery method (Christian Riesch) Changes in v4: - Further re-word README.da850 based on feedback from Christian Riesch board/davinci/da8xxevm/README.da850 | 68 +++ 1 file changed, 68 insertions(+) create mode 100644 board/davinci/da8xxevm/README.da850 diff --git a/board/davinci/da8xxevm/README.da850 b/board/davinci/da8xxevm/README.da850 new file mode 100644 index 000..621a95d --- /dev/null +++ b/board/davinci/da8xxevm/README.da850 @@ -0,0 +1,68 @@ +Summary +=== +The README is for the boot procedure used for various DA850 (or compatible +parts such as the AM1808) based boards. + +In the context of U-Boot, the board is booted in three stages. The initial +bootloader which executes upon reset is the ROM Boot Loader (RBL) and sits +in the internal ROM. The RBL initializes the internal memory and then +depending on the exact board and pin configurations will initialize another +controller (such as SPI or NAND) to continue the boot process by loading +the secondary program loader (SPL). The SPL will initialize the system +further (some clocks, SDRAM) and then load the full u-boot from a +predefined location in persistent storage to DDR and jumps to the u-boot +entry point. + +AIS is an image format defined by TI for the images that are to be loaded +to memory by the RBL. The image is divided into a series of sections and +the image's entry point is specified. Each section comes with meta data +like the target address the section is to be copied to and the size of the +section, which is used by the RBL to load the image. At the end of the +image the RBL jumps to the image entry point. The AIS format allows for +other things such as programming the clocks and SDRAM if the header is +programmed for it. We do not take advantage of this and instead use SPL as +it allows for additional flexibility (run-time detect of board revision, +loading the next image from a different media, etc). + + +Compilation +=== +The exact build target you need will depend on the board you have. For +Logic PD boards, or other boards which store the ethernet MAC address at +the end of SPI flash, run 'make da850evm'. For boards which store the +ethernet MAC address in the i2c EEPROM located at 0x50, run +'make da850_am18xxevm'. Once this build completes you will have a +u-boot.ais file that needs to be written to the correct persistent +storage. + + +Flashing the images to SPI +== +The AIS image can be written to SPI flash using the following commands. +Assuming that the network is configured and enabled and the u-boot.ais file +is tftp'able. + +U-Boot sf probe 0 +U-Boot sf erase 0 +32 +U-Boot tftp u-boot.ais +U-Boot sf write c070 0 $filesize + + +Recovery + + +In the case of a bricked board, you need to use the TI tools found +here[1] to write the u-boot.ais file. An example of recovering to the SPI +flash of an AM1808 would be: + +$ mono sfh_OMAP-L138.exe -targetType AM1808 -p /dev/ttyUSB0 \ + -flash_noubl /path/to/u-boot.ais + +For other target types and flash locations: + +$ mono sfh_OMAP-L138.exe -h + +Links += +[1] + http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L137 I'm not sure if the flash loader for the L137 would work for the L138 and the AM1808 as well, please use this URL instead: http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138 Sorry, I didn't notice that in earlier versions... Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/19] ARM: SPL: Make more generic, merge DaVinci and OMAP
Hi Tom, On Thu, Aug 23, 2012 at 1:19 AM, Tom Rini tr...@ti.com wrote: Hey all, The following patch series merges the davinci and omap-common SPL frameworks into a single framework, CONFIG_SPL_FRAMEWORK along with a few small cleanups to the code to make it a little smaller and more flexible. The end result is that davinci can now opt in on SPL-boots-Linux by just setting the right defines and other platforms would just need to adapt to this framework. In my testing, davinci gains between 300 and 700 bytes for this (not enabling the SPL OS feature) and omap4/5/etc lose just a little bit (from the printf-puts changes). I've tested this on omap3_beagle (xM and classic) and omap4_panda. I don't have any davinci platforms that were previously using SPL so I can't boot-test those changes but since everyone sets CONFIG_SPL_MAX_SIZE, we're OK in that department. To make this series easier to test I've placed it on http://github.com/trini/u-boot WIP/spl-improvements I've looked a little into re-reducing the size and the biggest problem I see is that SPI a lot of informational prints that we don't need, strictly speaking, but are nice in a normal U-Boot context. I'm unsure of the best way to quiet these as I don't like the idea of sprinkling http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 and I'm sending another email to discuss that. -- Tom Changes in v2: - Add - Add CONFIG_SYS_SPL_MALLOC_START / SIZE defines from Christian Riesch - Add arch/arm/cpu/arm926ejs/davinci/config.mk to build u-boot.ais - Fix checkpatch warning (u32* boot_params_ptr - u32 *boot_params_ptr) - Place files into common/spl (due to gcc bug #54303) and include/spl.h - Reorder all of the patches that used to follow this to precede. Changes in v3: CONFIG_SPL_FRAMEWORK perform early init. Fixes the cannot reset problem. Tested it on the LogicPD AM1808 experimenter's kit, works fine now :-) Thanks! Christian - Fix checkpatch.pl warning - Fix thinko, Nand - SPI (spotted by Prabhakar Lad) - Make u-boot.ais use u-boot.img not u-boot.bin, now that it uses - Make use of board_init_f being a weak function now so that we can - Rename to README.da850, add more direct recovery method (Christian Riesch) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 17/19] da850: Add README.da850
Hi Tom, On Thu, Aug 23, 2012 at 1:19 AM, Tom Rini tr...@ti.com wrote: This file documents when to build for da850evm and when to build for da850_am18xxevm. It also documents how to write the u-boot.ais file to persistent storage (such as SPI), in some cases as well as how to write a recovery image. Signed-off-by: Tom Rini tr...@ti.com --- Changes in v2: - Add Changes in v3: - Fix thinko, Nand - SPI (spotted by Prabhakar Lad) - Rename to README.da850, add more direct recovery method (Christian Riesch) board/davinci/da8xxevm/README.da850 | 62 +++ 1 file changed, 62 insertions(+) create mode 100644 board/davinci/da8xxevm/README.da850 diff --git a/board/davinci/da8xxevm/README.da850 b/board/davinci/da8xxevm/README.da850 new file mode 100644 index 000..55291f3 --- /dev/null +++ b/board/davinci/da8xxevm/README.da850 @@ -0,0 +1,62 @@ +Summary +=== +The README is for the boot procedure used for various DA850 (or compatible +parts such as the AM1808) based boards. + +The board is booted in three stages. The initial bootloader which executes +upon reset is the ROM Boot Loader (RBL) which sits in the internal ROM. The +RBL initializes the memory and then depending on the exact board will The RBL can initialize the PLLs and the memory (I assume you are talking about DDR/SDRAM here), but only if the AIS tells it to do so and provides the configuration data like timing etc. However, for the da850evm configuration the AIS only tells the RBL to copy the SPL to the internal SRAM of the SoC. Then, the SPL initializes the DDR memory. Actually we wouldn't need SPL to boot from SPI on the da850. We could as well do memory initialization with AIS/RBL and then let the RBL copy u-boot to DDR memory. The reason why I introduced SPL for booting from SPI here is that it gives us more flexibility, e.g. on my custom board I must check the board revision before configuring the PLLs because I have different oscillator frequencies on different revisions. +initialize another controller (such as SPI or NAND) to continue the boot +process. + +AIS is an image format defined by TI for the images that are to be +loaded to memory by the RBL. The image is divided into a series of +sections and the image's entry point is specified. Each section comes +with meta data like the target address the section is to be copied to +and the size of the section, which is used by the RBL to load the +image. At the end of the image the RBL jumps to the image entry +point. + +The secondary stage bootloader (SPL) which is loaded by the RBL then ... initializes the PLLs and the memory controller and ... loads +the u-boot from a predefined location in persistent storage to DDR and +jumps to the u-boot entry point. + + +Compilation +=== +The exact build target you need will depend on the board you have. For +Logic PD boards, or other boards which store the ethernet MAC address at +the end of SPI flash, run 'make da850evm'. For boards which store the +ethernet MAC address in the i2c EEPROM located at 0x50, run +'make da850_am18xxevm'. Once this build completes you will have a +u-boot.ais file that needs to be written to the correct persistent +storage. + + +Flashing the images to SPI +== +The AIS image can be written to SPI flash using the following commands. +Assuming that the network is configured and enabled and the u-boot.ais file +is tftp'able. + +U-Boot sf probe 0 +U-Boot sf erase 0 +32 +U-Boot tftp u-boot.ais +U-Boot sf write c070 0 $filesize + + +Recovery + + +In the case of a bricked board, you need to use the TI tools found +here[1] to write the u-boot.ais file. An example of recovering to the SPI +flash would be: + +$ mono sfh_OMAP-L138.exe -targetType AM1808 -p /dev/ttyUSB0 \ + -flash_noubl /path/to/u-boot.ais + I believe for the OMAP-L138 boards you will need -targetType OMAPL138 (or just omit the option because OMAPL138 is the default). Thanks! Regards, Christian + +Links += +[1] + http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L137 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 16/19] ARM: SPL: Convert davinci to CONFIG_SPL_FRAMEWORK
Hi Tom,
On Thu, Aug 23, 2012 at 1:19 AM, Tom Rini tr...@ti.com wrote:
- Convert the non-relocation part of board_init_f to spl_board_init,
turn on CONFIG_SPL_BOARD_INIT in the configs.
- Remove duplicated code.
- Add spl_boot_device() that returns the statically chosen boot device.
Signed-off-by: Tom Rini tr...@ti.com
[...]
diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
b/arch/arm/cpu/arm926ejs/davinci/spl.c
index 74632e5..46c0bfd 100644
--- a/arch/arm/cpu/arm926ejs/davinci/spl.c
+++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
@@ -21,6 +21,7 @@
* MA 02111-1307 USA
*/
#include common.h
+#include spl.h
#include asm/u-boot.h
#include asm/utils.h
#include nand.h
@@ -29,14 +30,7 @@
#include malloc.h
#include spi_flash.h
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
-
-DECLARE_GLOBAL_DATA_PTR;
-/* Define global data structure pointer to it*/
-static gd_t gdata __attribute__ ((section(.data)));
-static bd_t bdata __attribute__ ((section(.data)));
-
-#else
+#ifndef CONFIG_SPL_LIBCOMMON_SUPPORT
void puts(const char *str)
{
@@ -54,43 +48,37 @@ void putc(char c)
#endif /* CONFIG_SPL_LIBCOMMON_SUPPORT */
-inline void hang(void)
-{
- puts(### ERROR ### Please RESET the board ###\n);
- for (;;)
- ;
-}
-
void board_init_f(ulong dummy)
{
+ /* First, perform our low-level init. */
#ifdef CONFIG_SOC_DM365
dm36x_lowlevel_init(0);
#endif
#ifdef CONFIG_SOC_DA8XX
arch_cpu_init();
#endif
- relocate_code(CONFIG_SPL_STACK, NULL, CONFIG_SPL_TEXT_BASE);
+
+ /*
+* Next we call relocate_code() with relocation target same as the
+* CONFIG_SYS_SPL_TEXT_BASE. This will result in relocation getting
+* skipped. Instead, only .bss initialization will happen.
+*/
+ relocate_code(CONFIG_SPL_STACK, gdata, CONFIG_SPL_TEXT_BASE);
}
-void board_init_r(gd_t *id, ulong dummy)
+void spl_board_init(void)
{
-#ifdef CONFIG_SPL_NAND_LOAD
- nand_init();
- puts(Nand boot...\n);
- nand_boot();
-#endif
-#ifdef CONFIG_SPL_SPI_LOAD
- mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
- CONFIG_SYS_MALLOC_LEN);
-
- gd = gdata;
- gd-bd = bdata;
- gd-flags |= GD_FLG_RELOC;
- gd-baudrate = CONFIG_BAUDRATE;
- serial_init(); /* serial communications setup */
- gd-have_console = 1;
+ preloader_console_init();
+}
- puts(SPI boot...\n);
- spi_boot();
+u32 spl_boot_device(void)
+{
+#ifdef CONFIG_SPL_NAND_LOAD
+ return BOOT_DEVICE_NAND;
+#elif defined(CONFIG_SPL_SPI_LOAD)
+ return BOOT_DEVICE_SPI;
+#else
This will not apply on u-boot-ti since it is missing the MMC-SPL
patches that have already been merged, right?
Regards, Christian
+ puts(Unknown boot device\n);
+ hang();
#endif
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/18] da850_am18xxevm: Add README.da850_am18xxevm
[cc'd Manjunath Hadli] Hi Tom, On Mon, Aug 20, 2012 at 6:45 PM, Tom Rini tr...@ti.com wrote: Add a board-specific README that documents how to write u-boot.ais to the SPI found on this board. Changes-series: 2 - Add Signed-off-by: Tom Rini tr...@ti.com --- board/davinci/da8xxevm/README.da850_am18xxevm | 53 + 1 file changed, 53 insertions(+) create mode 100644 board/davinci/da8xxevm/README.da850_am18xxevm diff --git a/board/davinci/da8xxevm/README.da850_am18xxevm b/board/davinci/da8xxevm/README.da850_am18xxevm new file mode 100644 index 000..382b718 --- /dev/null +++ b/board/davinci/da8xxevm/README.da850_am18xxevm @@ -0,0 +1,53 @@ +Summary +=== +The README is for the boot procedure used for the LogicPD AM1808 EVM. + +The board is booted in three stages. The initial bootloader which executes +upon reset is the Rom Boot Loader(RBL) which sits in the internal ROM. The +RBL initialises the memory and the SPI controller and reads the AIS image +starting at block 0. This image can contain both the SPL and U-Boot +binaries. + +AIS is an image format defined by TI for the images that are to be +loaded to memory by the RBL. The image is divided into a series of +sections and the image's entry point is specified. Each section comes +with meta data like the target address the section is to be copied to +and the size of the section, which is used by the RBL to load the +image. At the end of the image the RBL jumps to the image entry +point. + +The secondary stage bootloader(spl) which is loaded by the RBL then loads +the u-boot from a predefined location in SPI to DDR and jumps to the u-boot +entry point. + + +Compilation +=== +To build a SPI-bootable image, run 'make da850_am18xxevm'. This will build da850_am18xxevm is for the Spectrum Digital EVM for the AM1808. For the Logic PD board you will need 'make da850evm'. See [1] Regards, Christian [1] http://lists.denx.de/pipermail/u-boot/2012-February/117082.html +the u-boot.ais file that needs to be written to SPI flash. + + +Flashing the images to Nand +=== +The AIS image can be written to SPI flash using the following commands. +Assuming that the network is configured and enabled and the u-boot.ais file +is tftp'able. + +U-Boot sf probe 0 +U-Boot sf erase 0 +32 +U-Boot tftp u-boot.ais +U-Boot sf write c070 0 $filesize + + +Recovery + + +In the case of a bricked board, you need to use the TI tools found +here[1] to write a UBL file and u-boot.bin. Once the system is running +again from these tools a good u-boot.ais may be re-written to SPI flash. + + +Links += +[1] + http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L137 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/18] da850_am18xxevm: Add README.da850_am18xxevm
Hi Prabhakar, On Wed, Aug 22, 2012 at 11:07 AM, Prabhakar Lad prabhakar@ti.com wrote: Hi, On Wednesday 22 August 2012 01:43 PM, Christian Riesch wrote: [cc'd Manjunath Hadli] Hi Tom, On Mon, Aug 20, 2012 at 6:45 PM, Tom Rini tr...@ti.com wrote: Add a board-specific README that documents how to write u-boot.ais to the SPI found on this board. Changes-series: 2 - Add Signed-off-by: Tom Rini tr...@ti.com --- board/davinci/da8xxevm/README.da850_am18xxevm | 53 + 1 file changed, 53 insertions(+) create mode 100644 board/davinci/da8xxevm/README.da850_am18xxevm diff --git a/board/davinci/da8xxevm/README.da850_am18xxevm b/board/davinci/da8xxevm/README.da850_am18xxevm new file mode 100644 index 000..382b718 --- /dev/null +++ b/board/davinci/da8xxevm/README.da850_am18xxevm @@ -0,0 +1,53 @@ +Summary +=== +The README is for the boot procedure used for the LogicPD AM1808 EVM. + +The board is booted in three stages. The initial bootloader which executes +upon reset is the Rom Boot Loader(RBL) which sits in the internal ROM. The +RBL initialises the memory and the SPI controller and reads the AIS image +starting at block 0. This image can contain both the SPL and U-Boot +binaries. + +AIS is an image format defined by TI for the images that are to be +loaded to memory by the RBL. The image is divided into a series of +sections and the image's entry point is specified. Each section comes +with meta data like the target address the section is to be copied to +and the size of the section, which is used by the RBL to load the +image. At the end of the image the RBL jumps to the image entry +point. + +The secondary stage bootloader(spl) which is loaded by the RBL then loads +the u-boot from a predefined location in SPI to DDR and jumps to the u-boot +entry point. + + +Compilation +=== +To build a SPI-bootable image, run 'make da850_am18xxevm'. This will build da850_am18xxevm is for the Spectrum Digital EVM for the AM1808. For the Logic PD board you will need 'make da850evm'. See [1] May be having a common README for am18x and omap-l138 would be good ? This is a good idea. But just to make it clear: Afaik the da850evm configuration works for both the AM1808 and the OMAP-L138 board from LogicPD (at least I am using it with the AM1808 experimenter's kit from LogicPD). The da850_am18xxevm is for the Spectrum Digital board. At least this is what I understood from the discussion with Manjunath Hadli in the in the u-boot mailing list thread I cited earlier. I hope this is correct, I haven't got other boards than the AM1808 board from LogicPD to test. Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/18] ARM: SPL: Convert davinci to CONFIG_SPL_FRAMEWORK
Hi Tom, On Mon, Aug 20, 2012 at 6:45 PM, Tom Rini tr...@ti.com wrote: - Convert the non-relocation part of board_init_f to spl_board_init, turn on CONFIG_SPL_BOARD_INIT in the configs. - Remove duplicated code. - Add spl_boot_device() that returns the statically chosen boot device. I tested the patchset on the LogicPD AM1808 experimenter's kit: make da850evm and flashing to SPI flash with mono sfh_OMAP-L138.exe -targetType AM1808 -p /dev/ttyUSB0 -flash_noubl u-boot.ais The board boots up fine, but after pressing the reset button or issuing the u-boot reset command, it is dead. Only power-cycling helps. Before enabling the SPL framework in this patch reset works fine. Any ideas? Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/18] da850_am18xxevm: Add README.da850_am18xxevm
Hi Prabhakar, On Wednesday, August 22, 2012, Prabhakar Lad wrote: Hi Christian, On Wednesday 22 August 2012 02:47 PM, Christian Riesch wrote: Hi Prabhakar, On Wed, Aug 22, 2012 at 11:07 AM, Prabhakar Lad prabhakar@ti.comjavascript:; wrote: Hi, On Wednesday 22 August 2012 01:43 PM, Christian Riesch wrote: [cc'd Manjunath Hadli] Hi Tom, On Mon, Aug 20, 2012 at 6:45 PM, Tom Rini tr...@ti.com javascript:; wrote: Add a board-specific README that documents how to write u-boot.ais to the SPI found on this board. Changes-series: 2 - Add Signed-off-by: Tom Rini tr...@ti.com javascript:; --- board/davinci/da8xxevm/README.da850_am18xxevm | 53 + 1 file changed, 53 insertions(+) create mode 100644 board/davinci/da8xxevm/README.da850_am18xxevm diff --git a/board/davinci/da8xxevm/README.da850_am18xxevm b/board/davinci/da8xxevm/README.da850_am18xxevm new file mode 100644 index 000..382b718 --- /dev/null +++ b/board/davinci/da8xxevm/README.da850_am18xxevm @@ -0,0 +1,53 @@ +Summary +=== +The README is for the boot procedure used for the LogicPD AM1808 EVM. + +The board is booted in three stages. The initial bootloader which executes +upon reset is the Rom Boot Loader(RBL) which sits in the internal ROM. The +RBL initialises the memory and the SPI controller and reads the AIS image +starting at block 0. This image can contain both the SPL and U-Boot +binaries. + +AIS is an image format defined by TI for the images that are to be +loaded to memory by the RBL. The image is divided into a series of +sections and the image's entry point is specified. Each section comes +with meta data like the target address the section is to be copied to +and the size of the section, which is used by the RBL to load the +image. At the end of the image the RBL jumps to the image entry +point. + +The secondary stage bootloader(spl) which is loaded by the RBL then loads +the u-boot from a predefined location in SPI to DDR and jumps to the u-boot +entry point. + + +Compilation +=== +To build a SPI-bootable image, run 'make da850_am18xxevm'. This will build da850_am18xxevm is for the Spectrum Digital EVM for the AM1808. For the Logic PD board you will need 'make da850evm'. See [1] May be having a common README for am18x and omap-l138 would be good ? This is a good idea. But just to make it clear: Afaik the da850evm configuration works for both the AM1808 and the OMAP-L138 board from LogicPD (at least I am using it with the AM1808 experimenter's kit from LogicPD). The da850_am18xxevm is for the Spectrum Digital board. At least this is what I understood from the discussion with Manjunath Hadli in the in the u-boot mailing list thread I cited earlier. I hope this is correct, I haven't got other boards than the AM1808 board from LogicPD to test. AFAIK the difference between AM1808 and OMAP-L138 is that, 1: The AM1808 has EEPROM and stores the MAC address in it where as OMAP-L138 stores the MAC address in SPI flash. Are you sure? I don't see that in datasheets/schematics. Christian 2: The revision number differs for both. Thx, --Prabhakar Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de javascript:; http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] Consolidate bootcount code into drivers/bootcount
Hi Stefan, On Fri, Aug 17, 2012 at 5:55 AM, Stefan Roese s...@denx.de wrote: This patch moves all bootcount implementations into a common directory: drivers/bootcount. The generic bootcount driver is now usable not only by powerpc platforms, but others as well. Signed-off-by: Stefan Roese s...@denx.de Cc: Heiko Schocher h...@denx.de Cc: Valentin Longchamp valentin.longch...@keymile.com Cc: Christian Riesch christian.rie...@omicron.at Cc: Manfred Rudigier manfred.rudig...@omicron.at Cc: Mike Frysinger vap...@gentoo.org Cc: Rob Herring rob.herr...@calxeda.com Cc: Reinhard Meyer reinhard.me...@emk-elektronik.de Tested-by: Valentin Longchamp valentin.longch...@keymile.com Tested-by: Christian Riesch christian.rie...@omicron.at I tested it again on the calimain board and confirmed that it still works fine :-) Thank you! Regards, Christian Acked-by: Rob Herring rob.herr...@calxeda.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/17] ARM: SPL: Convert davinci to CONFIG_SPL_FRAMEWORK
Hi Tom, I tested the entire patchset with the da850evm booting from SPI flash with SPL (make da850evm_config make u-boot.ais). I had to add defines for mem_malloc_init to make it work, please see my comment below. On Wed, Aug 15, 2012 at 11:30 PM, Tom Rini tr...@ti.com wrote: - Convert the non-relocation part of board_init_f to spl_board_init, turn on CONFIG_SPL_BOARD_INIT in the configs. - Remove duplicated code. - Add spl_boot_device() that returns the statically chosen boot device. Signed-off-by: Tom Rini tr...@ti.com --- arch/arm/cpu/arm926ejs/davinci/spl.c| 45 +++ arch/arm/include/asm/arch-davinci/spl.h | 28 +++ include/configs/cam_enc_4xx.h |2 ++ include/configs/da850evm.h |2 ++ include/configs/hawkboard.h |2 ++ 5 files changed, 44 insertions(+), 35 deletions(-) create mode 100644 arch/arm/include/asm/arch-davinci/spl.h [...] diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h index e6adb1f..5bb5379 100644 --- a/include/configs/da850evm.h +++ b/include/configs/da850evm.h @@ -313,6 +313,8 @@ /* defines for SPL */ #define CONFIG_SPL +#define CONFIG_SPL_FRAMEWORK +#define CONFIG_SPL_BOARD_INIT #define CONFIG_SPL_SPI_SUPPORT #define CONFIG_SPL_SPI_FLASH_SUPPORT #define CONFIG_SPL_SPI_LOAD Please add #define CONFIG_SYS_SPL_MALLOC_START (CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN) #define CONFIG_SYS_SPL_MALLOC_SIZE CONFIG_SYS_MALLOC_LEN here, booting from SPI requires malloc. Apart from that it works great, I like it :-) Thank you! Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Consolidate bootcount code into drivers/bootcount
Hi Stefan,
On Monday, August 13, 2012, Stefan Roese wrote:
This patch moves all bootcount implementations into a common
directory: drivers/bootcount. The generic bootcount driver
is now usable not only by powerpc platforms, but others as well.
Signed-off-by: Stefan Roese s...@denx.de javascript:;
Cc: Heiko Schocher h...@denx.de javascript:;
Cc: Valentin Longchamp valentin.longch...@keymile.com javascript:;
Cc: Christian Riesch christian.rie...@omicron.at javascript:;
Cc: Manfred Rudigier manfred.rudig...@omicron.at javascript:;
Cc: Mike Frysinger vap...@gentoo.org javascript:;
Cc: Rob Herring rob.herr...@calxeda.com javascript:;
Cc: Reinhard Meyer reinhard.me...@emk-elektronik.de javascript:;
Tested-by: Valentin Longchamp valentin.longch...@keymile.comjavascript:;
Tested-by: Christian Riesch christian.rie...@omicron.at javascript:;
I tested v2 and v3 of this patch, but not v4. I can do this on Friday when
I am back from my vacation.
Regards, Christian
Acked-by: Rob Herring rob.herr...@calxeda.com javascript:;
---
v4:
- Rebased against TOT
- Addressed Mike's comments
v3:
- Moved le-/be-accessors into header so that they now can be
used by all bootcount drivers.
- Changed CONFIG_BOOTCOUNT_LE to CONFIG_SYS_BOOTCOUNT_LE
- Enabled CONFIG_SYS_BOOTCOUNT_LE in highbank
- Enabled CONFIG_SYS_BOOTCOUNT_SINGLEWORD in highbank
v2:
- Added CONFIG_BOOTCOUNT_LE to bootcount_davinci.c and enabled it
in calimain.h to select little-endian accessors.
Makefile | 1 +
arch/arm/cpu/arm926ejs/at91/cpu.c | 26
arch/arm/cpu/armv7/highbank/Makefile | 2 +-
arch/arm/cpu/armv7/highbank/bootcount.c| 36 ---
arch/arm/cpu/ixp/cpu.c | 22 ---
arch/powerpc/lib/Makefile | 1 -
board/enbw/enbw_cmc/enbw_cmc.c | 29 -
board/keymile/km_arm/km_arm.c | 51 ---
board/omicron/calimain/calimain.c | 29 -
drivers/bootcount/Makefile | 45 ++
.../powerpc/lib = drivers/bootcount}/bootcount.c | 25
drivers/bootcount/bootcount_at91.c | 43 +
.../bootcount/bootcount_blackfin.c | 0
drivers/bootcount/bootcount_davinci.c | 49 +++
drivers/bootcount/bootcount_ram.c | 72
++
include/bootcount.h| 51 +++
include/configs/calimain.h | 1 +
include/configs/enbw_cmc.h | 1 +
include/configs/highbank.h | 2 +
include/configs/km/km_arm.h| 2 +
20 files changed, 282 insertions(+), 206 deletions(-)
delete mode 100644 arch/arm/cpu/armv7/highbank/bootcount.c
create mode 100644 drivers/bootcount/Makefile
rename {arch/powerpc/lib = drivers/bootcount}/bootcount.c (82%)
create mode 100644 drivers/bootcount/bootcount_at91.c
rename arch/blackfin/cpu/bootcount.c =
drivers/bootcount/bootcount_blackfin.c (100%)
create mode 100644 drivers/bootcount/bootcount_davinci.c
create mode 100644 drivers/bootcount/bootcount_ram.c
create mode 100644 include/bootcount.h
diff --git a/Makefile b/Makefile
index 5ce5cc3..2b662b4 100644
--- a/Makefile
+++ b/Makefile
@@ -249,6 +249,7 @@ LIBS-y += net/libnet.o
LIBS-y += disk/libdisk.o
LIBS-y += drivers/bios_emulator/libatibiosemu.o
LIBS-y += drivers/block/libblock.o
+LIBS-$(CONFIG_BOOTCOUNT_LIMIT) += drivers/bootcount/libbootcount.o
LIBS-y += drivers/dma/libdma.o
LIBS-y += drivers/fpga/libfpga.o
LIBS-y += drivers/gpio/libgpio.o
diff --git a/arch/arm/cpu/arm926ejs/at91/cpu.c
b/arch/arm/cpu/arm926ejs/at91/cpu.c
index c47fb31..5cf4fad 100644
--- a/arch/arm/cpu/arm926ejs/at91/cpu.c
+++ b/arch/arm/cpu/arm926ejs/at91/cpu.c
@@ -71,29 +71,3 @@ int print_cpuinfo(void)
return 0;
}
#endif
-
-#ifdef CONFIG_BOOTCOUNT_LIMIT
-/*
- * We combine the BOOTCOUNT_MAGIC and bootcount in one 32-bit register.
- * This is done so we need to use only one of the four GPBR registers.
- */
-void bootcount_store (ulong a)
-{
- at91_gpbr_t *gpbr = (at91_gpbr_t *) ATMEL_BASE_GPBR;
-
- writel((BOOTCOUNT_MAGIC 0x) | (a 0x),
- gpbr-reg[AT91_GPBR_INDEX_BOOTCOUNT]);
-}
-
-ulong bootcount_load (void)
-{
- at91_gpbr_t *gpbr = (at91_gpbr_t *) ATMEL_BASE_GPBR;
-
- ulong val = readl(gpbr-reg[AT91_GPBR_INDEX_BOOTCOUNT]);
- if ((val 0x) != (BOOTCOUNT_MAGIC 0x))
- return 0;
- else
- return val 0x;
-}
-
-#endif /* CONFIG_BOOTCOUNT_LIMIT */
diff --git a/arch/arm/cpu/armv7/highbank/Makefile
b/arch/arm/cpu/armv7/highbank/Makefile
index 917c3a3..76faeb0 100644
--- a/arch/arm/cpu/armv7/highbank
Re: [U-Boot] Board-specific commands unintentionally linked into SPL?
[cc'd Prabhakar Lad, Tom Rini, and Scott Wood] Tyler, On Thu, Jul 26, 2012 at 5:37 PM, Tyler Olmstead tyler.j.olmst...@gmail.com wrote: Hi all, I have encountered some issues adding a board-specific command to the board file of a project I have been working on. Specifically, after adding a U-Boot shell command to my board file, I have been seeing link-stage failures when attempting to build SPL. It's hard to tell without having your code, but I think this problem was already discussed in [1]. However I do not remember how Prabhakar solved it in the end. In [1] I suggested to put an #ifndef CONFIG_SPL_BUILD U_BOOT_CMD( ... ); #endif around the command definition in the board file. But also other solutions were discussed in that thread, please have a look. Regards, Christian [1] http://marc.info/?t=13274854893 snip UNDEF_SYM=`arm-arago-linux-gnueabi-objdump -x /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/cpu/arm926ejs/davinci/libdavinci.o /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/cpu/arm926ejs/libarm926ejs.o /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/lib/libarm.o /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/board/davinci/da8xxevm/libda8xxevm.o /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/drivers/mtd/nand/libnand.o /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/drivers/serial/libserial.o /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/lib/libgeneric.o | sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/ arm-arago-linux-gnueabi-ld -T /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/u-boot-spl.lds --gc-sections -Bstatic -Ttext 0xc108 $UNDEF_SYM arch/arm/cpu/arm926ejs/start.o --start-group arch/arm/cpu/arm926ejs/davinci/libdavinci.o arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o board/davinci/da8xxevm/libda8xxevm.o drivers/mtd/nand/libnand.o drivers/serial/libserial.o lib/libgeneric.o --end-group /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/lib/eabi_compat.o -L /usr/local/ti-sdk-am180x-evm/linux-devkit/bin/../lib/gcc/arm-arago-linux-gnueabi/4.3.3 -lgcc -Map u-boot-spl.map -o u-boot-spl board/davinci/da8xxevm/libda8xxevm.o: In function `do_mycmd': /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:121: undefined reference to `eth_get_dev_by_index' /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:123: undefined reference to `eth_write_hwaddr' /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/board/davinci/da8xxevm/awpb3.c:126: undefined reference to `printf' make[1]: *** [/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/u-boot-spl] Error 1 make[1]: Leaving directory `/home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl' make: *** [spl/u-boot-spl.bin] Error 2 /snip In the output above, one can see the environment variable $UNDEF_SYM being defined as the result of the following SPL makefile (spl/Makefile) target: GEN_UBOOT = \ UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) | \ sed -n -e 's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\ cd $(obj) $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $$UNDEF_SYM $(__START) \ --start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \ -Map u-boot-spl.map -o u-boot-spl $(obj)u-boot-spl: depend $(START) $(LIBS) $(obj)u-boot-spl.lds $(GEN_UBOOT) For my target, $UNDEF_SYM expands to the following: -u__u_boot_cmd_mycmd As I understand it, this is to force the inclusion of the commands into the command table located in the special .u_boot_cmd section so that unreferenced commands are not linked out of the final U-Boot binary. However, I don't think that the inclusion of commands into the SPL is intended. Removing the $UNDEF_SYM variable from the SPL makefile resolves my build issues. I am planning on submitting a patch. Does anyone see a flaw in my thinking? Thanks, -- Tyler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Board-specific commands unintentionally linked into SPL?
Hi, On Thursday, July 26, 2012, Aneesh V wrote: Hi Tyler, On 07/26/2012 11:54 AM, Tyler Olmstead wrote: Hi Christian, On Thu, Jul 26, 2012 at 10:03 AM, Christian Riesch christian.rie...@omicron.at wrote: [cc'd Prabhakar Lad, Tom Rini, and Scott Wood] Tyler, On Thu, Jul 26, 2012 at 5:37 PM, Tyler Olmstead tyler.j.olmst...@gmail.com wrote: Hi all, I have encountered some issues adding a board-specific command to the board file of a project I have been working on. Specifically, after adding a U-Boot shell command to my board file, I have been seeing link-stage failures when attempting to build SPL. It's hard to tell without having your code, but I think this problem was already discussed in [1]. However I do not remember how Prabhakar solved it in the end. Yes, I ran into this thread while debugging the problem, which ultimately lead me to my solution. From that same thread [1], Wolfgang Denk writes: quote *I want to add a command using U_BOOT_CMD in uboot, where SPL_BUILD is enabled for example for da850evm in spl frame work how can i do that * This makes no sense. Commands can only be executed when we have full U-Boot running (actually even only after relocation). You cannot run commands in the SPL. /quote I understand of course why it makes no sense to have command support in the SPL. However, the crux of this problem is that U-Boot and SPL both link in the same board object file, so in that sense compile-time switches wont work. From later in [1], Scott Wood writes: No that's not correct. For SPL we build the object files into a different directory spl/. Please see the below in spl/Makefile # We want the final binaries in this directory obj := $(OBJTREE)/spl/ Object files used for U-Boot and SPL are not the same. You can use compile-time switches and it should work just fine. Thanks for pointing that out, Aneesh. Therefore an #ifndef CONFIG_SPL_BUILD would work for Tyler's problem and I think that it's also easier to read than some build magic that removes u-boot commands. Christian -Aneesh __**_ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/**listinfo/u-boothttp://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with running commands
Hi Sughosh, On Mon, Jul 2, 2012 at 9:24 PM, Sughosh Ganu urwithsugh...@gmail.com wrote: hi, While testing on hawkboard with the latest commit, i hit an issue of commands not being accepted. hawkboard reset Unknown command '�' - try 'help' hawkboard Running git bisect showed that this is caused due to commit 054ea170f271: cmd_mem: cmp: unify size code paths. Has anyone seen this issue -- i don't think this is board/arch specific. I tried to reproduce this on the calimain board (AM1808 SoC), but without success. The reset command works fine with current mainline u-boot. Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/9] feature additions and fixes for da850/omap-l138
Hi Tom, hi Prabhakar, On Mon, Jun 25, 2012 at 6:46 PM, Tom Rini tr...@ti.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/25/2012 12:35 AM, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar@ti.com This series adds MMC/SD, NAND and NOR SPL support for Logic PD's DA850/OMAP-L138 EVM. This series also fixes some issues found on the EVM during testing. The patches are sent in a series as these patches need to be applied in the order they are sent. The V2 version of patch series has been tested by Sughosh Ganu(urwithsugh...@gmail.com) and V3 version of the patch series has been tested by Christian Riesch (christian.rie...@omicron.at) for regression. Changes for v2: 1: Fixed comments from Tom to remove unused macro and add comment. 2: Fixed comments from Christian to move GPIO pins to board file and add a check to perform initializations only when CONFIG_SPL_LIBCOMMON_SUPPORT is defined. Changes for v3: 1: Fixed comments from Christian, to define CONFIG_SPL_MMC_LOAD config while booting from MMC. 2: Splitted patch 5(of v2), one for CONFIG_SPL_LIBCOMMON_SUPPORT check, one to define SPI specific configs of SP only when SPI flash is used and lastly to add NAND SPL support. 3: Rearranged the patch sequence. Changes for v4: 1: Fixed comment from Christian, to use clrbits_le32() which was wrongly using clrbits_be32(). Under the assumption that Christian will be providing acks soon when he can test the patches, I've staged this to my local u-boot-ti/next and confirmed everything is still bisect'able. Thanks for working through the iterations on this series! I tested v4 of the patchset on the AM1808 experimenter's kit (da850evm configuration, make u-boot.ais, booting from SPI flash with SPL) and on the calimain board. I found no regression due to this patchset. Tested-by: Christian Riesch christian.rie...@omicron.at Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] arm/davinci: fix DDR2/mDDR memory controller initialization for Omap L138
Hi Mikhail, On Tue, Jun 12, 2012 at 11:15 PM, Mikhail Kshevetskiy mikhail.kshevets...@gmail.com wrote: follow section 15.2.13.1 (Initializing Following Device Power Up or Reset) of OMAP-L138 DSP+ARM Processor Technical Reference Manual Thanks for fixing this! Just out of curiosity: Did you hit any problem or were you just comparing the code with the reference manual? Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com --- arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c | 25 --- arch/arm/include/asm/arch-davinci/hardware.h|1 + 2 files changed, 19 insertions(+), 7 deletions(-) Acked-by: Christian Riesch christian.rie...@omicron.at For the calimain board Tested-by: Christian Riesch christian.rie...@omicron.at Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] arm/davinci: fix DDR2/mDDR memory controller initialization for Omap L138
Hi Mikhail,
On Tue, Jun 12, 2012 at 11:15 PM, Mikhail Kshevetskiy
mikhail.kshevets...@gmail.com wrote:
follow section 15.2.13.1 (Initializing Following Device Power Up or Reset) of
OMAP-L138 DSP+ARM Processor Technical Reference Manual
Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com
Your patch causes a few checkpatch warnings, see below.
---
arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c | 25
---
arch/arm/include/asm/arch-davinci/hardware.h | 1 +
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
index df7d6a2..9682407 100644
--- a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
+++ b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
@@ -190,13 +190,21 @@ int da850_ddr_setup(void)
setbits_le32(davinci_syscfg1_regs-vtpio_ctl, VTP_LOCK);
setbits_le32(davinci_syscfg1_regs-vtpio_ctl, VTP_POWERDWN);
-
- setbits_le32(davinci_syscfg1_regs-vtpio_ctl, VTP_IOPWRDWN);
}
-
+ setbits_le32(davinci_syscfg1_regs-vtpio_ctl, VTP_IOPWRDWN);
writel(CONFIG_SYS_DA850_DDR2_DDRPHYCR, dv_ddr2_regs_ctrl-ddrphycr);
- clrbits_le32(davinci_syscfg1_regs-ddr_slew,
- (1 DDR_SLEW_CMOSEN_BIT));
+
+ if (CONFIG_SYS_DA850_DDR2_SDBCR (1 DV_DDR_SDCR_DDR2EN_SHIFT)){
missing whitespace before {
+ /* DDR2 */
+ clrbits_le32(davinci_syscfg1_regs-ddr_slew,
+ (1 DDR_SLEW_DDR_PDENA_BIT) |
+ (1 DDR_SLEW_CMOSEN_BIT));
+ }else{
missing whitespaces before and after else.
+ /* MOBILE DDR */
+ setbits_le32(davinci_syscfg1_regs-ddr_slew,
+ (1 DDR_SLEW_DDR_PDENA_BIT) |
+ (1 DDR_SLEW_CMOSEN_BIT));
+ }
/*
* SDRAM Configuration Register (SDCR):
@@ -216,7 +224,10 @@ int da850_ddr_setup(void)
writel(tmp, dv_ddr2_regs_ctrl-sdbcr);
/* write memory configuration and timing */
- writel(CONFIG_SYS_DA850_DDR2_SDBCR2, dv_ddr2_regs_ctrl-sdbcr2);
+ if (!(CONFIG_SYS_DA850_DDR2_SDBCR (1 DV_DDR_SDCR_DDR2EN_SHIFT))){
missing whitespace before {
Please fix these warnings and resubmit. Thank you!
Regards, Christian
+ /* MOBILE DDR only*/
+ writel(CONFIG_SYS_DA850_DDR2_SDBCR2,
dv_ddr2_regs_ctrl-sdbcr2);
+ }
writel(CONFIG_SYS_DA850_DDR2_SDTIMR, dv_ddr2_regs_ctrl-sdtimr);
writel(CONFIG_SYS_DA850_DDR2_SDTIMR2, dv_ddr2_regs_ctrl-sdtimr2);
@@ -240,7 +251,7 @@ int da850_ddr_setup(void)
/* disable self refresh */
clrbits_le32(dv_ddr2_regs_ctrl-sdrcr,
- DV_DDR_SDRCR_LPMODEN | DV_DDR_SDRCR_LPMODEN);
+ DV_DDR_SDRCR_LPMODEN | DV_DDR_SDRCR_MCLKSTOPEN);
writel(CONFIG_SYS_DA850_DDR2_PBBPR, dv_ddr2_regs_ctrl-pbbpr);
return 0;
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h
b/arch/arm/include/asm/arch-davinci/hardware.h
index b145c6e..56e5743 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -505,6 +505,7 @@ struct davinci_syscfg1_regs {
((struct davinci_syscfg1_regs *)DAVINCI_SYSCFG1_BASE)
#define DDR_SLEW_CMOSEN_BIT 4
+#define DDR_SLEW_DDR_PDENA_BIT 5
#define VTP_POWERDWN (1 6)
#define VTP_LOCK (1 7)
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] serial/ns16550: ns16550 has a different register layout on SOC_DA8XX
Hi Mikhail,
On Tue, Jun 12, 2012 at 11:15 PM, Mikhail Kshevetskiy
mikhail.kshevets...@gmail.com wrote:
also fix NS16550_init() as we need 16x divider
Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com
---
drivers/serial/ns16550.c | 2 +-
include/ns16550.h | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 0c23955..e6dec0c 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -52,7 +52,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
serial_out((baud_divisor 8) 0xff, com_port-dlm);
serial_out(UART_LCRVAL, com_port-lcr);
#if (defined(CONFIG_OMAP) !defined(CONFIG_OMAP3_ZOOM2)) || \
- defined(CONFIG_AM33XX)
+ defined(CONFIG_AM33XX) || defined(CONFIG_SOC_DA8XX)
Please fix the checkpatch warning here (no spaces at start of line).
Otherwise:
Acked-by: Christian Riesch christian.rie...@omicron.at
Tested-by: Christian Riesch christian.rie...@omicron.at
Regards, Christian
#if defined(CONFIG_APTIX)
/* /13 mode so Aptix 6MHz can hit 115200 */
diff --git a/include/ns16550.h b/include/ns16550.h
index e9d2eda..51cb5b4 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -46,6 +46,14 @@ struct NS16550 {
UART_REG(lsr); /* 5 */
UART_REG(msr); /* 6 */
UART_REG(spr); /* 7 */
+#ifdef CONFIG_SOC_DA8XX
+ UART_REG(reg8); /* 8 */
+ UART_REG(reg9); /* 9 */
+ UART_REG(revid1); /* A */
+ UART_REG(revid2); /* B */
+ UART_REG(pwr_mgmt); /* C */
+ UART_REG(mdr1); /* D */
+#else
UART_REG(mdr1); /* 8 */
UART_REG(reg9); /* 9 */
UART_REG(regA); /* A */
@@ -58,6 +66,7 @@ struct NS16550 {
UART_REG(ssr); /* 11*/
UART_REG(reg12); /* 12*/
UART_REG(osc_12m_sel); /* 13*/
+#endif
};
#define thr rbr
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/9] da850/omap-l138: modifications for Logic PD Rev.3 AM18xx EVM
Hi Prabhakar,
On Thu, Jun 21, 2012 at 9:51 AM, Prabhakar Lad prabhakar@ti.com wrote:
From: Rajashekhara, Sudhakar sudhakar@ti.com
AHCLKR/UART1_RTS/GP0[11] pin needs to be configured for
MMC and NOR to work on DA850/OMAP-L138 Rev.3 EVM. When
GP0[11] is low, the SD0 interface will not work, but NOR
flash will. When GP0[11] is high, SD0 will work but NOR
flash will not.
Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Hadli, Manjunath manjunath.ha...@ti.com
---
board/davinci/da8xxevm/da850evm.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/board/davinci/da8xxevm/da850evm.c
b/board/davinci/da8xxevm/da850evm.c
index 88337ff..0d75b84 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -335,7 +335,7 @@ int board_early_init_f(void)
int board_init(void)
{
-#ifdef CONFIG_USE_NOR
+#if defined(CONFIG_USE_NOR) || defined(CONFIG_DAVINCI_MMC)
u32 val;
#endif
@@ -386,6 +386,16 @@ int board_init(void)
writel(val, GPIO_BANK0_REG_CLR_ADDR);
#endif
+#ifdef CONFIG_DAVINCI_MMC
+ /* Set the GPIO direction as output */
+ clrbits_be32((u32 *)GPIO_BANK0_REG_DIR_ADDR, (0x01 11));
big endian? I think you want clrbits_le32.
Regards, Christian
+
+ /* Set the output as high */
+ val = readl(GPIO_BANK0_REG_SET_ADDR);
+ val |= (0x01 11);
+ writel(val, GPIO_BANK0_REG_SET_ADDR);
+#endif
+
#ifdef CONFIG_DRIVER_TI_EMAC
davinci_emac_mii_mode_sel(HAS_RMII);
#endif /* CONFIG_DRIVER_TI_EMAC */
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/9] arm, davinci: perform check for initalizing global data and serial init
On Thu, Jun 21, 2012 at 9:51 AM, Prabhakar Lad prabhakar@ti.com wrote:
From: Lad, Prabhakar prabhakar@ti.com
initialize baudrate, flags, data and serial intialization,
initialization
only when CONFIG_SPL_LIBCOMMON_SUPPORT is defined.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
Signed-off-by: Hadli, Manjunath manjunath.ha...@ti.com
Acked-by: Christian Riesch christian.rie...@omicron.at
Regards, Christian
---
Chnages for v3:
1: Creted new patch by splitting patch 6 of v2, to make
it more readable.
arch/arm/cpu/arm926ejs/davinci/spl.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
b/arch/arm/cpu/arm926ejs/davinci/spl.c
index 74632e5..7d9b289 100644
--- a/arch/arm/cpu/arm926ejs/davinci/spl.c
+++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
@@ -74,12 +74,7 @@ void board_init_f(ulong dummy)
void board_init_r(gd_t *id, ulong dummy)
{
-#ifdef CONFIG_SPL_NAND_LOAD
- nand_init();
- puts(Nand boot...\n);
- nand_boot();
-#endif
-#ifdef CONFIG_SPL_SPI_LOAD
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
CONFIG_SYS_MALLOC_LEN);
@@ -90,6 +85,14 @@ void board_init_r(gd_t *id, ulong dummy)
serial_init(); /* serial communications setup */
gd-have_console = 1;
+#endif
+
+#ifdef CONFIG_SPL_NAND_LOAD
+ nand_init();
+ puts(Nand boot...\n);
+ nand_boot();
+#endif
+#ifdef CONFIG_SPL_SPI_LOAD
puts(SPI boot...\n);
spi_boot();
#endif
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] feature additions and fixes for da850/omap-l138
Hi Prabhakar, On Thu, Jun 21, 2012 at 9:51 AM, Prabhakar Lad prabhakar@ti.com wrote: From: Lad, Prabhakar prabhakar@ti.com This series adds MMC/SD, NAND and NOR SPL support for Logic PD's DA850/OMAP-L138 EVM. This series also fixes some issues found on the EVM during testing. The patches are sent in a series as these patches need to be applied in the order they are sent. I tested the entire patchset on the AM1808 experimenter's kit (da850evm configuration booting from SPI flash with SPL) and on the calimain board, there is no regression due to your patchset. Tested-by: Christian Riesch christian.rie...@omicron.at Regards, Christian Changes for v2: 1: Fixed comments from Tom to remove unused macro and add comment. 2: Fixed comments from Christian to move GPIO pins to board file and add a check to perform initializations only when CONFIG_SPL_LIBCOMMON_SUPPORT is defined. Changes for v3: 1: Fixed comments from Christian, to define CONFIG_SPL_MMC_LOAD config while booting from MMC. 2: Splitted patch 5(of v2), one for CONFIG_SPL_LIBCOMMON_SUPPORT check, one to define SPI specific configs of SP only when SPI flash is used and lastly to add NAND SPL support. 3: Rearranged the patch sequnece. Lad, Prabhakar (7): da850/omap-l138: Add MMC support for DA850/OMAP-L138 arm, davinci: perform check for initalizing global data and serial init da850/omap-l138: Define SPI specific configs for SPL only when SPI is used da850/omap-l138: Add support to read u-boot image from MMC/SD da850/omap-l138: Fix NAND flash timings da850/omap-l138: Add support for NAND SPL da850/omap-l138: add support for direct NOR boot mode Rajashekhara, Sudhakar (2): da850/omap-l138: modifications for Logic PD Rev.3 AM18xx EVM da850/omap-l138: Make MMC and NOR support mutually exclusive arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c | 11 +++ arch/arm/cpu/arm926ejs/davinci/spl.c | 24 +-- arch/arm/include/asm/arch-davinci/hardware.h | 1 + arch/arm/include/asm/arch-davinci/pinmux_defs.h | 3 + board/davinci/da8xxevm/da850evm.c | 54 -- boards.cfg | 1 + drivers/mmc/Makefile | 4 + drivers/mmc/spl_mmc_load.c | 62 +++ include/configs/da850evm.h | 92 +-- include/mmc.h | 2 + 10 files changed, 234 insertions(+), 20 deletions(-) create mode 100644 drivers/mmc/spl_mmc_load.c -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] da850/omap-l138: Add support to read u-boot image from MMC/SD
Hi Prabhakar, On Tue, Jun 19, 2012 at 7:06 AM, Lad, Prabhakar prabhakar@ti.com wrote: Hi Christian, On Tue, Jun 19, 2012 at 01:09:08, Christian Riesch wrote: Hi, Sorry for the delay, had a lot of other work to do :-/ On Thursday, June 7, 2012, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar@ti.com javascript:; DA850/OMAP-L138 does not support strict MMC/SD boot mode. SPL will be in SPI flash and U-Boot image will be in MMC/SD card. SPL will do the low level initialization and then loads the u-boot image from MMC/SD card. Define the CONFIG_SPL_MMC_LOAD macro in the DA850/OMAP-L138 configuration file to enable this feature. Signed-off-by: Lad, Prabhakar prabhakar@ti.com javascript:; Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com javascript:; Signed-off-by: Hadli, Manjunath manjunath.ha...@ti.com javascript:; --- arch/arm/cpu/arm926ejs/davinci/spl.c | 12 ++- drivers/mmc/Makefile | 4 ++ drivers/mmc/spl_mmc_load.c | 62 ++ include/configs/da850evm.h | 8 include/mmc.h | 2 + 5 files changed, 87 insertions(+), 1 deletions(-) create mode 100644 drivers/mmc/spl_mmc_load.c diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..be397ce 100644 --- a/arch/arm/cpu/arm926ejs/davinci/spl.c +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c @@ -28,6 +28,11 @@ #include ns16550.h #include malloc.h #include spi_flash.h +#include mmc.h +#include fat.h +#include version.h +#include asm/arch/davinci_misc.h +#include asm/arch/pinmux_defs.h #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT @@ -91,6 +96,11 @@ void board_init_r(gd_t *id, ulong dummy) gd-have_console = 1; puts(SPI boot...\n); +#ifdef CONFIG_SPL_MMC_LOAD + spl_mmc_load(); +#else spi_boot(); -#endif Hmm, now the code prints SPI boot and then it boots from MMC, right? Please output correct messages. The board is booted up in SPI boot mode only, ie the SPL is loaded from SPI flash itself and finally when low level initialization is completed The SPL loads the U-boot image in MMC/SD card when CONFIG_SPL_MMC_LOAD Config is defined. If CONFIG_SPL_MMC_LOAD is not defined by default the SPL loads the U-boot image from SPI flash itself. Yes, but your code prints SPI boot for both cases, doesn't it? +#endif /* CONFIG_SPL_MMC_LOAD */ + +#endif /* CONFIG_SPL_SPI_LOAD */ So, CONFIG_SPL_SPI_LOAD must be defined to boot from MMC?? Ths does not make sense to me. No not to boot from MMC, its indicating to SPL which is flashed in SPI flash to load the U-boot image(u-boot.bin) from MMC. Yes, but your code requires both CONFIG_SPL_MMC_LOAD and CONFIG_SPL_SPI_LOAD to be defined to load u-boot from MMC, right? This is confusing. Of course SPL itself is loaded from SPI flash in both cases, but this does not matter here, since the SPL has already loaded to the internal SRAM of the SoC by the ROM bootloader of the chip. The SPL could have been loaded from some other kind of memory (or UART) as well and would not know the difference. Regards, Christian Thx, --Prabhakar Lad Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] da850/omap-l138: Add support to read u-boot image from MMC/SD
Hi, Sorry for the delay, had a lot of other work to do :-/ On Thursday, June 7, 2012, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar@ti.com javascript:; DA850/OMAP-L138 does not support strict MMC/SD boot mode. SPL will be in SPI flash and U-Boot image will be in MMC/SD card. SPL will do the low level initialization and then loads the u-boot image from MMC/SD card. Define the CONFIG_SPL_MMC_LOAD macro in the DA850/OMAP-L138 configuration file to enable this feature. Signed-off-by: Lad, Prabhakar prabhakar@ti.com javascript:; Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com javascript:; Signed-off-by: Hadli, Manjunath manjunath.ha...@ti.com javascript:; --- arch/arm/cpu/arm926ejs/davinci/spl.c | 12 ++- drivers/mmc/Makefile |4 ++ drivers/mmc/spl_mmc_load.c | 62 ++ include/configs/da850evm.h |8 include/mmc.h|2 + 5 files changed, 87 insertions(+), 1 deletions(-) create mode 100644 drivers/mmc/spl_mmc_load.c diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..be397ce 100644 --- a/arch/arm/cpu/arm926ejs/davinci/spl.c +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c @@ -28,6 +28,11 @@ #include ns16550.h #include malloc.h #include spi_flash.h +#include mmc.h +#include fat.h +#include version.h +#include asm/arch/davinci_misc.h +#include asm/arch/pinmux_defs.h #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT @@ -91,6 +96,11 @@ void board_init_r(gd_t *id, ulong dummy) gd-have_console = 1; puts(SPI boot...\n); +#ifdef CONFIG_SPL_MMC_LOAD + spl_mmc_load(); +#else spi_boot(); -#endif Hmm, now the code prints SPI boot and then it boots from MMC, right? Please output correct messages. +#endif /* CONFIG_SPL_MMC_LOAD */ + +#endif /* CONFIG_SPL_SPI_LOAD */ So, CONFIG_SPL_SPI_LOAD must be defined to boot from MMC?? Ths does not make sense to me. Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] arm/davinci: spl - boot device selection
Hi,
On Tuesday, June 12, 2012, Mikhail Kshevetskiy wrote:
Signed-off-by: Mikhail Kshevetskiy
mikhail.kshevets...@gmail.comjavascript:;
---
arch/arm/cpu/arm926ejs/davinci/Makefile |5 ++
arch/arm/cpu/arm926ejs/davinci/spl.c | 91
+++---
arch/arm/cpu/arm926ejs/davinci/spl_mmc.c | 37 +
arch/arm/cpu/arm926ejs/davinci/spl_nand.c| 11 +++
arch/arm/cpu/arm926ejs/davinci/spl_spi_flash.c | 25 ++
arch/arm/cpu/arm926ejs/davinci/spl_ymodem.c | 41 ++
arch/arm/include/asm/arch-davinci/davinci_boot.h | 25 ++
include/configs/cam_enc_4xx.h| 12 +--
include/configs/da850evm.h | 19 +++--
include/configs/hawkboard.h | 11 +--
10 files changed, 247 insertions(+), 30 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/davinci/spl_mmc.c
create mode 100644 arch/arm/cpu/arm926ejs/davinci/spl_nand.c
create mode 100644 arch/arm/cpu/arm926ejs/davinci/spl_spi_flash.c
create mode 100644 arch/arm/cpu/arm926ejs/davinci/spl_ymodem.c
create mode 100644 arch/arm/include/asm/arch-davinci/davinci_boot.h
diff --git a/arch/arm/cpu/arm926ejs/davinci/Makefile
b/arch/arm/cpu/arm926ejs/davinci/Makefile
index da7efac..12bd37a 100644
--- a/arch/arm/cpu/arm926ejs/davinci/Makefile
+++ b/arch/arm/cpu/arm926ejs/davinci/Makefile
@@ -40,6 +40,11 @@ ifdef CONFIG_SPL_BUILD
COBJS-y+= spl.o
COBJS-$(CONFIG_SOC_DM365) += dm365_lowlevel.o
COBJS-$(CONFIG_SOC_DA8XX) += da850_lowlevel.o
+
+COBJS-$(CONFIG_SPL_NAND_SUPPORT) += spl_nand.o
+COBJS-$(CONFIG_SPL_SPI_FLASH_SUPPORT) += spl_spi_flash.o
+COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += spl_ymodem.o
+COBJS-$(CONFIG_SPL_MMC_SUPPORT)+= spl_mmc.o
endif
SOBJS = reset.o
diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
b/arch/arm/cpu/arm926ejs/davinci/spl.c
index 74632e5..a8c318c 100644
--- a/arch/arm/cpu/arm926ejs/davinci/spl.c
+++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
@@ -25,9 +25,11 @@
#include asm/utils.h
#include nand.h
#include asm/arch/dm365_lowlevel.h
+#include asm/arch/davinci_boot.h
#include ns16550.h
#include malloc.h
#include spi_flash.h
+#include linux/compiler.h
#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
@@ -72,25 +74,92 @@ void board_init_f(ulong dummy)
relocate_code(CONFIG_SPL_STACK, NULL, CONFIG_SPL_TEXT_BASE);
}
+u32 davinci_boot_device(void){
+#ifdef CONFIG_SOC_DA8XX
+ u32 bootmode = ((*((vu_long*)0x01C14020)) 0x1F);
You should probably introduce defines for the address and the bitmask. How
about using readl?
+ switch(bootmode){
+ case 0x0E: /* NAND 8 */
+ case 0x10: /* NAND 16 */
+ return BOOT_DEVICE_NAND;
+ case 0x0A:
+ case 0x0C:
+ return BOOT_DEVICE_SPI_FLASH;
+ case 0x16: /* UART0 */
+ case 0x17: /* UART1 */
+ case 0x14: /* UART2 */
+ return BOOT_DEVICE_UART;
+ case 0x1C: /* MMC/SD */
+ return BOOT_DEVICE_MMC;
+ default:
+ return BOOT_DEVICE_NONE;
+ }
Nice :-)
+#else
+#ifdef
+#endif CONFIG_SPL_NAND_SUPPORT
+ return BOOT_DEVICE_NAND;
+#endif
+#ifdef BOOT_DEVICE_SPI_FLASH
+ return BOOT_DEVICE_SPI_FLASH;
+#endif
+#ifdef CONFIG_SPL_YMODEM_SUPPORT
+ return BOOT_DEVICE_UART;
+#endif
+#ifdef CONFIG_SPL_MMC_SUPPORT
+ return BOOT_DEVICE_MMC;
+#endif
+}
+
void board_init_r(gd_t *id, ulong dummy)
{
-#ifdef CONFIG_SPL_NAND_LOAD
- nand_init();
- puts(Nand boot...\n);
- nand_boot();
-#endif
-#ifdef CONFIG_SPL_SPI_LOAD
- mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
- CONFIG_SYS_MALLOC_LEN);
+ u32 boot_device;
+ void (*uboot)(void) __noreturn;
+
+ mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
+ CONFIG_SYS_SPL_MALLOC_SIZE);
gd = gdata;
gd-bd = bdata;
gd-flags |= GD_FLG_RELOC;
+#ifdef CONFIG_SPL_SERIAL_SUPPORT
gd-baudrate = CONFIG_BAUDRATE;
- serial_init(); /* serial communications setup */
+ serial_init();
gd-have_console = 1;
+#endif
- puts(SPI boot...\n);
- spi_boot();
+ boot_device = davinci_boot_device();
+ debug(boot device - %d\n, boot_device);
+ switch (boot_device) {
+#ifdef CONFIG_SPL_NAND_SUPPORT
+ case BOOT_DEVICE_NAND:
+ puts(Booting from nand flash ...\n);
+ spl_nand_load_image();
+ break;
+#endif
+#ifdef CONFIG_SPL_SPI_FLASH_SUPPORT
+ case BOOT_DEVICE_SPI_FLASH:
+ puts(Booting from spi flash ...\n);
+ spl_spi_flash_load_image();
+ break;
#endif
+#ifdef CONFIG_SPL_YMODEM_SUPPORT
+ case BOOT_DEVICE_UART:
+ puts(Booting from
Re: [U-Boot] [PATCH 1/7] da850/omap-l138: Add MMC support for DA850/OMAP-L138
Hi,
On Fri, Jun 1, 2012 at 4:30 PM, Prabhakar Lad prabhakar@ti.com wrote:
From: Lad, Prabhakar prabhakar@ti.com
This patch adds support for MMC/SD on DA850/OMAP-L138.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
Signed-off-by: Hadli, Manjunath manjunath.ha...@ti.com
---
arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c | 13 ++
arch/arm/include/asm/arch-davinci/hardware.h | 1 +
arch/arm/include/asm/arch-davinci/pinmux_defs.h | 3 ++
board/davinci/da8xxevm/da850evm.c | 28
+++
include/configs/da850evm.h | 14 +++
5 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c
b/arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c
index fa07fb5..a95e419 100644
--- a/arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c
+++ b/arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c
@@ -169,3 +169,16 @@ const struct pinmux_config emifa_pins_nor[] = {
{ pinmux(12), 1, 6 }, /* EMA_A[1] */
{ pinmux(12), 1, 7 }, /* EMA_A[0] */
};
+
+/* MMC0 pin muxer settings */
+const struct pinmux_config mmc0_pins[] = {
+ /* GP0[11] is required for SD to work on Rev 3 EVMs */
+ { pinmux(0), 8, 4 }, /* GP0[11] */
Please move GP0[11] to the board specific file, e.g., add it to static
const struct pinmux_config gpio_pins[] in
board/davinci/da8xxevm/da850evm.c. Other boards might use other (or
no) GPIOs for this purpose...
+ { pinmux(10), 2, 0 }, /* MMCSD0_CLK */
+ { pinmux(10), 2, 1 }, /* MMCSD0_CMD */
+ { pinmux(10), 2, 2 }, /* MMCSD0_DAT_0 */
+ { pinmux(10), 2, 3 }, /* MMCSD0_DAT_1 */
+ { pinmux(10), 2, 4 }, /* MMCSD0_DAT_2 */
+ { pinmux(10), 2, 5 }, /* MMCSD0_DAT_3 */
+ /* DA850 supports only 4-bit mode, remaining pins are not configured
*/
+};
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h
b/arch/arm/include/asm/arch-davinci/hardware.h
index b145c6e..f6b7a2c 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -446,6 +446,7 @@ struct davinci_pllc_regs {
#define DAVINCI_SPI1_CLKID (cpu_is_da830() ? 2 : ASYNC3)
/* Clock IDs */
enum davinci_clk_ids {
+ DAVINCI_MMCSD_CLKID = 2,
DAVINCI_SPI0_CLKID = 2,
DAVINCI_UART2_CLKID = 2,
DAVINCI_MMC_CLKID = 2,
diff --git a/arch/arm/include/asm/arch-davinci/pinmux_defs.h
b/arch/arm/include/asm/arch-davinci/pinmux_defs.h
index 07aceaa..c9ac697 100644
--- a/arch/arm/include/asm/arch-davinci/pinmux_defs.h
+++ b/arch/arm/include/asm/arch-davinci/pinmux_defs.h
@@ -48,4 +48,7 @@ extern const struct pinmux_config emifa_pins_cs4[1];
extern const struct pinmux_config emifa_pins_nand[12];
extern const struct pinmux_config emifa_pins_nor[43];
+/* MMC pin muxer settings */
+extern const struct pinmux_config mmc0_pins[7];
+
#endif
diff --git a/board/davinci/da8xxevm/da850evm.c
b/board/davinci/da8xxevm/da850evm.c
index 82d707f..608c652 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -36,6 +36,11 @@
#include asm/errno.h
#include hwconfig.h
+#ifdef CONFIG_DAVINCI_MMC
+#include mmc.h
+#include asm/arch/sdmmc_defs.h
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_DRIVER_TI_EMAC
@@ -204,6 +209,23 @@ int misc_init_r(void)
return 0;
}
+#ifdef CONFIG_DAVINCI_MMC
+static struct davinci_mmc mmc_sd0 = {
+ .reg_base = (struct davinci_mmc_regs *)DAVINCI_MMC_SD0_BASE,
+ .host_caps = MMC_MODE_4BIT, /* DA850 supports only 4-bit SD/MMC */
+ .voltages = MMC_VDD_32_33 | MMC_VDD_33_34,
+ .version = MMC_CTLR_VERSION_2,
+};
+
+int board_mmc_init(bd_t *bis)
+{
+ mmc_sd0.input_clk = clk_get(DAVINCI_MMCSD_CLKID);
+
+ /* Add slot-0 to mmc subsystem */
+ return davinci_mmc_init(bis, mmc_sd0);
+}
+#endif
+
static const struct pinmux_config gpio_pins[] = {
#ifdef CONFIG_USE_NOR
/* GP0[11] is required for NOR to work on Rev 3 EVMs */
@@ -236,6 +258,9 @@ const struct pinmux_resource pinmuxes[] = {
PINMUX_ITEM(emifa_pins_nor),
#endif
PINMUX_ITEM(gpio_pins),
+#ifdef CONFIG_DAVINCI_MMC
+ PINMUX_ITEM(mmc0_pins),
+#endif
};
const int pinmuxes_size = ARRAY_SIZE(pinmuxes);
@@ -246,6 +271,9 @@ const struct lpsc_resource lpsc[] = {
{ DAVINCI_LPSC_EMAC }, /* image download */
{ DAVINCI_LPSC_UART2 }, /* console */
{ DAVINCI_LPSC_GPIO },
+#ifdef CONFIG_DAVINCI_MMC
+ { DAVINCI_LPSC_MMC_SD },
+#endif
};
const int lpsc_size = ARRAY_SIZE(lpsc);
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 989472b..9301a3b 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -313,6 +313,20 @@
#undef CONFIG_CMD_ENV
#endif
+/* SD/MMC */
+#define CONFIG_MMC
Re: [U-Boot] [PATCH] da850/omap-l138: enable SPI flash in RMII mode
Hi, On Fri, Jun 1, 2012 at 3:48 PM, Prabhakar Lad prabhakar@ti.com wrote: From: Rajashekhara, Sudhakar sudhakar@ti.com According to DA850/OMAP-L138 schematics, GP2[6] line has to be driven high for RMII mode to work. In RMII mode, SPI flash becomes un-usable. But during testing it was found out that, driving GP2[6] low also enables RMII and in this configuration SPI flash is also accessible. How about just removing all the code that is related to GP2[6]? There's a pull-down resistor on the board and the pin is high impedance by default. Regards, Christian Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com Signed-off-by: Hadli, Manjunath manjunath.ha...@ti.com --- board/davinci/da8xxevm/da850evm.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/board/davinci/da8xxevm/da850evm.c b/board/davinci/da8xxevm/da850evm.c index 004d5ad..82d707f 100644 --- a/board/davinci/da8xxevm/da850evm.c +++ b/board/davinci/da8xxevm/da850evm.c @@ -438,10 +438,10 @@ int rmii_hw_init(void) CONFIG_SYS_I2C_EXPANDER_ADDR); } - /* Set the output as high */ - temp = REG(GPIO_BANK2_REG_SET_ADDR); + /* Set the output as low */ + temp = REG(GPIO_BANK2_REG_CLR_ADDR); temp |= (0x01 6); - REG(GPIO_BANK2_REG_SET_ADDR) = temp; + REG(GPIO_BANK2_REG_CLR_ADDR) = temp; /* Set the GPIO direction as output */ temp = REG(GPIO_BANK2_REG_DIR_ADDR); -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] da850/omap-l138: Add support for NAND SPL
Hi,
On Fri, Jun 1, 2012 at 4:30 PM, Prabhakar Lad prabhakar@ti.com wrote:
From: Lad, Prabhakar prabhakar@ti.com
This patch adds support for NAND SPL on DA850/OMAP-L138.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
Signed-off-by: Hadli, Manjunath manjunath.ha...@ti.com
---
arch/arm/cpu/arm926ejs/davinci/spl.c | 13 ++-
include/configs/da850evm.h | 39 +
2 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
b/arch/arm/cpu/arm926ejs/davinci/spl.c
index be397ce..53df581 100644
--- a/arch/arm/cpu/arm926ejs/davinci/spl.c
+++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
@@ -79,12 +79,6 @@ void board_init_f(ulong dummy)
void board_init_r(gd_t *id, ulong dummy)
{
-#ifdef CONFIG_SPL_NAND_LOAD
- nand_init();
- puts(Nand boot...\n);
- nand_boot();
-#endif
-#ifdef CONFIG_SPL_SPI_LOAD
mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
CONFIG_SYS_MALLOC_LEN);
@@ -95,6 +89,13 @@ void board_init_r(gd_t *id, ulong dummy)
serial_init(); /* serial communications setup */
gd-have_console = 1;
This breaks the build for the cam_enc_4xx board and the hawkboard.
You may do this initializations only if CONFIG_SPL_LIBCOMMON_SUPPORT
is defined. Please test your patchset with ./MAKEALL -s davinci
Regards, Christian
+#ifdef CONFIG_SPL_NAND_LOAD
+ puts(Nand boot...\n);
+ nand_init();
+ puts(Nand Initalized...\n);
+ nand_boot();
+#endif
+#ifdef CONFIG_SPL_SPI_LOAD
puts(SPI boot...\n);
#ifdef CONFIG_SPL_MMC_LOAD
spl_mmc_load();
[...]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] da850/omap-l138: Enable auto negotiation in RMII mode
Hi, On Fri, Jun 1, 2012 at 3:34 PM, Prabhakar Lad prabhakar@ti.com wrote: From: Rajashekhara, Sudhakar sudhakar@ti.com On DA850/OMAP-L138 it was observed that in RMII mode, auto negotiation was not performed. This patch enables auto negotiation in RMII mode. Without this patch, EMAC initialization takes more time and sometimes tftp fails in RMII mode. This patch causes a warning for the ea20 board: davinci_emac.c: In function 'davinci_emac_initialize': davinci_emac.c:901:2: warning: passing argument 1 of 'gen_auto_negotiate' makes integer from pointer without a cast davinci_emac.c:355:12: note: expected 'int' but argument is of type 'u_int8_t *' (found with ./MAKEALL -s davinci) Regards, Christian Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com Signed-off-by: Hadli, Manjunath manjunath.ha...@ti.com --- drivers/net/davinci_emac.c | 5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c index fbd0f1b..9bbd625 100644 --- a/drivers/net/davinci_emac.c +++ b/drivers/net/davinci_emac.c @@ -895,5 +895,10 @@ int davinci_emac_initialize(void) miiphy_register(phy[i].name, davinci_mii_phy_read, davinci_mii_phy_write); } + +#if defined(CONFIG_DRIVER_TI_EMAC_USE_RMII) \ + defined(CONFIG_MACH_DAVINCI_DA850_EVM) + gen_auto_negotiate(active_phy_addr); +#endif return(1); } -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Consolidate bootcount code into drivers/bootcount
Hi, On Mon, Jun 4, 2012 at 3:14 PM, Stefan Roese s...@denx.de wrote: On Monday 04 June 2012 15:03:27 Rob Herring wrote: On 06/04/2012 07:38 AM, Stefan Roese wrote: This patch moves all bootcount implementations into a common directory: drivers/bootcount. The generic bootcount driver is now usable not only by powerpc platforms, but others as well. Signed-off-by: Stefan Roese s...@denx.de Cc: Heiko Schocher h...@denx.de Cc: Valentin Longchamp valentin.longch...@keymile.com Cc: Christian Riesch christian.rie...@omicron.at Cc: Manfred Rudigier manfred.rudig...@omicron.at Cc: Mike Frysinger vap...@gentoo.org Cc: Rob Herring rob.herr...@calxeda.com Cc: Reinhard Meyer reinhard.me...@emk-elektronik.de --- v2: - Added CONFIG_BOOTCOUNT_LE to bootcount_davinci.c and enabled it Thanks a lot! I will test it on the calimain board. in calimain.h to select little-endian accessors. highbank is also LE. Yes, sure. I could move those inline functions to a header, so that they can be used by the other drivers as well. Okay? I don't think this is necessary. As long as a board uses its native endianess to store the boot counter, nothing special is needed. Regards, Christian Why don't you use __BYTE_ORDER rather than a new define? Unfortunately not. There are LE platforms that use BE accessors for the bootcounter already (Davinci enbw_cmc). Mostly historical reasons I assume, since the original bootcount implementation was powerpc specific with those be32() functions. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Consolidate bootcount code into drivers/bootcount
Hi Stefan,
On Mon, Jun 4, 2012 at 2:38 PM, Stefan Roese s...@denx.de wrote:
This patch moves all bootcount implementations into a common
directory: drivers/bootcount. The generic bootcount driver
is now usable not only by powerpc platforms, but others as well.
For the calimain board
Tested-by: Christian Riesch christian.rie...@omicron.at
Thanks, Christian
Signed-off-by: Stefan Roese s...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Valentin Longchamp valentin.longch...@keymile.com
Cc: Christian Riesch christian.rie...@omicron.at
Cc: Manfred Rudigier manfred.rudig...@omicron.at
Cc: Mike Frysinger vap...@gentoo.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Reinhard Meyer reinhard.me...@emk-elektronik.de
---
v2:
- Added CONFIG_BOOTCOUNT_LE to bootcount_davinci.c and enabled it
in calimain.h to select little-endian accessors.
Makefile | 3 +
arch/arm/cpu/arm926ejs/at91/cpu.c | 26 ---
arch/arm/cpu/armv7/highbank/Makefile | 2 +-
arch/arm/cpu/armv7/highbank/bootcount.c | 36 --
arch/arm/cpu/ixp/cpu.c | 22 --
arch/powerpc/lib/Makefile | 1 -
board/enbw/enbw_cmc/enbw_cmc.c | 29
board/keymile/km_arm/km_arm.c | 51 --
board/omicron/calimain/calimain.c | 29
drivers/bootcount/Makefile | 47 +
.../powerpc/lib = drivers/bootcount}/bootcount.c | 10 ++-
drivers/bootcount/bootcount_at91.c | 43
.../bootcount/bootcount_blackfin.c | 0
drivers/bootcount/bootcount_davinci.c | 72
drivers/bootcount/bootcount_ram.c | 72
include/configs/calimain.h | 1 +
include/configs/km/km_arm.h | 2 +
17 files changed, 248 insertions(+), 198 deletions(-)
delete mode 100644 arch/arm/cpu/armv7/highbank/bootcount.c
create mode 100644 drivers/bootcount/Makefile
rename {arch/powerpc/lib = drivers/bootcount}/bootcount.c (92%)
create mode 100644 drivers/bootcount/bootcount_at91.c
rename arch/blackfin/cpu/bootcount.c =
drivers/bootcount/bootcount_blackfin.c (100%)
create mode 100644 drivers/bootcount/bootcount_davinci.c
create mode 100644 drivers/bootcount/bootcount_ram.c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Consolidate bootcount code into drivers/bootcount
Hi Stefan,
On Fri, Jun 1, 2012 at 11:52 AM, Stefan Roese s...@denx.de wrote:
This patch moves all bootcount implementations into a common
directory: drivers/bootcount. The generic bootcount driver
(bootcount.c) is now usable not only by powerpc platforms, but
others as well. Highbank is already moved to this generic
code. For all other non-generic implementations, SoC specific
drivers have been created (e.g. bootcount_at91.c).
Thank you for this patch! I have reviewed and tested the
davinci/calimain parts of it, please see below.
[...]
diff --git a/drivers/bootcount/bootcount_davinci.c
b/drivers/bootcount/bootcount_davinci.c
new file mode 100644
index 000..8674eb7
--- /dev/null
+++ b/drivers/bootcount/bootcount_davinci.c
@@ -0,0 +1,50 @@
+/*
+ * (C) Copyright 2011
+ * Heiko Schocher, DENX Software Engineering, h...@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.
+ *
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/arch/da850_lowlevel.h
+#include asm/arch/davinci_misc.h
+
+void bootcount_store(ulong a)
+{
+ struct davinci_rtc *reg =
+ (struct davinci_rtc *)CONFIG_SYS_BOOTCOUNT_ADDR;
+
+ /*
+ * write RTC kick register to enable write
+ * for RTC Scratch registers. Scratch0 and 1 are
+ * used for bootcount values.
+ */
+ writel(RTC_KICK0R_WE, reg-kick0r);
+ writel(RTC_KICK1R_WE, reg-kick1r);
+ out_be32(reg-scratch0, a);
+ out_be32(reg-scratch1, BOOTCOUNT_MAGIC);
This code here seems to be copied from the enbw_cmc board. The
calimain board uses writel instead of out_be32 for the scratch
registers (because I didn't understand why we should use big endian on
a little endian machine). So your patch changes the byte order here
for the calimain board and thus breaks our boot counter support.
What's the reason for using out_be32 here?
+}
+
+ulong bootcount_load(void)
+{
+ struct davinci_rtc *reg =
+ (struct davinci_rtc *)CONFIG_SYS_BOOTCOUNT_ADDR;
+
+ if (in_be32(reg-scratch1) != BOOTCOUNT_MAGIC)
+ return 0;
+ else
+ return in_be32(reg-scratch0);
Same as above, the calimain board uses readl instead of in_be32.
I replaced out_be32 by writel and in_be32 by readl and tested it on
the calimain board, it works fine :-)
Regards, Christian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] calimain, enbw_cmc: Fix typo in comments
Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Heiko Schocher h...@denx.de Cc: Tom Rini tr...@ti.com --- board/enbw/enbw_cmc/enbw_cmc.c|2 +- board/omicron/calimain/calimain.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/board/enbw/enbw_cmc/enbw_cmc.c b/board/enbw/enbw_cmc/enbw_cmc.c index 16d1b08..6c0d931 100644 --- a/board/enbw/enbw_cmc/enbw_cmc.c +++ b/board/enbw/enbw_cmc/enbw_cmc.c @@ -525,7 +525,7 @@ void bootcount_store(ulong a) /* * write RTC kick register to enable write -* for RTC Scratch registers. Cratch0 and 1 are +* for RTC Scratch registers. Scratch0 and 1 are * used for bootcount values. */ writel(RTC_KICK0R_WE, reg-kick0r); diff --git a/board/omicron/calimain/calimain.c b/board/omicron/calimain/calimain.c index 97ba74a..54415ce 100644 --- a/board/omicron/calimain/calimain.c +++ b/board/omicron/calimain/calimain.c @@ -166,7 +166,7 @@ void bootcount_store(ulong a) /* * write RTC kick register to enable write -* for RTC Scratch registers. Cratch0 and 1 are +* for RTC Scratch registers. Scratch0 and 1 are * used for bootcount values. */ writel(RTC_KICK0R_WE, reg-kick0r); -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Don't use printf() in SPL builds
Hi Simon, On Thu, Mar 15, 2012 at 6:23 AM, Simon Glass s...@chromium.org wrote: Yes I am talking about building with the generic relocation series included, so a slightly different point. With that I get: $ make -j8 -s Generating include/generated/asm-offsets.h arch/arm/cpu/arm926ejs/davinci/libdavinci.o: In function `board_init_f': /home/sjg/trunk/src/third_party/u-boot/files/arch/arm/cpu/arm926ejs/davinci/spl.c:75: undefined reference to `relocate_code' make[1]: *** [/home/sjg/trunk/src/third_party/u-boot/files/spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl.bin] Error 2 make: *** Waiting for unfinished jobs relocate_code is also called in the da850evm and hawkboard configurations from spl.c, so I guess we will get this error for these boards as well. I would like to test your generic relocation patches also on my board. Which patchsets are required, what's their latest version? Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] spl: add ymodem support
Hi, On Wednesday, March 7, 2012, Mikhail Kshevetskiy mikhail.kshevets...@gmail.com wrote: On Tue, 6 Mar 2012 22:28:46 + Laurence Withers lwith...@guralp.com wrote: On Wed, Mar 07, 2012 at 12:54:05AM +0400, Mikhail Kshevetskiy wrote: We have an omap l138 based board without jtag and empty spi flash. UART is an only way to load something on this board, so we are using uart to load spl image u-boot and then we are using ymodem to load the rest part of u-boot. Dear Mikhail, I am asking mainly out of curiousity, rather than giving feedback on the patch, but the OMAP-L138 boot ROM has the capability to load both SPL and U-Boot into empty SPI flash using the UART and sfh program or equivalent. (sfh is serial flash host for those following along, a program to talk to the boot ROM over the UART and download some code that the boot ROM can burn into SPI flash). It's a combination of boot ROM and a programmer code (sfh) that is downloaded to the SoC and does the actual lowlevel config of the chip and the programming to flash. This code must be adapted (and maintained) for custom boards. What is the advantage in allowing the SPL to flash U-Boot also? sfh and boot rom does not understand our flash. So there is also another advantage: You can use the same lowlevel initialization code for downloading code and for normal operation, you will only need to maintain u-boot for your board. Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Do we really need CONFIG_ARCH_CPU_INIT ?
Hi, On Thu, Mar 1, 2012 at 9:48 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Le 01/03/2012 14:23, Fabio Estevam a écrit : Hi, Currently CONFIG_ARCH_CPU_INIT is used to select arch_cpu_init() function. arch_cpu_init() does CPU level initialization, so why do we need to include CONFIG_ARCH_CPU_INIT in the include/configs/boardXYZ files, which are board related files ? For example: Let's say boards X, Y and Z are based on SoC S: 1. If processor S has a arch_cpu_init() defined, then it means that X,Y,Z need the code from arch_cpu_init() and then we need to define CONFIG_ARCH_CPU_INIT for each of these boards (actually all the boards based on this processor would need CONFIG_ARCH_CPU_INIT) 2. If not all boards need the code inside arch_cpu_init() for processor S, then it means that this code is not really CPU specific and then it should be moved to board code. ... or some of these boards have a kind of preloader that does CPU level inits before U-Boot is loaded, but other have not. Exactly. da850 based systems have several options to to lowlevel configuration, either in the AIS (a script interpreted by the ROM bootloader of the SoC), or by UBL (a user bootloader from Texas Instruments that does low level init and then loads u-boot) or by u-boot itself in arch_cpu_init(). Which way is used is board specific, but if the initialization is done by u-boot, the code is the same for all boards, it does not make sense to duplicate it. Boards that use the low level initialization in u-boot define CONFIG_ARCH_CPU_INIT, boards that rely on AIS or UBL do not define it. So if CONFIG_ARCH_CPU_INIT is removed, what should be done with da850 based boards? Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Do we really need CONFIG_ARCH_CPU_INIT ?
Hi again, On Fri, Mar 2, 2012 at 9:46 AM, Christian Riesch christian.rie...@omicron.at wrote: Hi, On Thu, Mar 1, 2012 at 9:48 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Le 01/03/2012 14:23, Fabio Estevam a écrit : Hi, Currently CONFIG_ARCH_CPU_INIT is used to select arch_cpu_init() function. arch_cpu_init() does CPU level initialization, so why do we need to include CONFIG_ARCH_CPU_INIT in the include/configs/boardXYZ files, which are board related files ? For example: Let's say boards X, Y and Z are based on SoC S: 1. If processor S has a arch_cpu_init() defined, then it means that X,Y,Z need the code from arch_cpu_init() and then we need to define CONFIG_ARCH_CPU_INIT for each of these boards (actually all the boards based on this processor would need CONFIG_ARCH_CPU_INIT) 2. If not all boards need the code inside arch_cpu_init() for processor S, then it means that this code is not really CPU specific and then it should be moved to board code. ... or some of these boards have a kind of preloader that does CPU level inits before U-Boot is loaded, but other have not. Exactly. da850 based systems have several options to to lowlevel configuration, either in the AIS (a script interpreted by the ROM bootloader of the SoC), or by UBL (a user bootloader from Texas Instruments that does low level init and then loads u-boot) or by u-boot itself in arch_cpu_init(). Which way is used is board specific, but if the initialization is done by u-boot, the code is the same for all boards, it does not make sense to duplicate it. Boards that use the low level initialization in u-boot define CONFIG_ARCH_CPU_INIT, boards that rely on AIS or UBL do not define it. So if CONFIG_ARCH_CPU_INIT is removed, what should be done with da850 based boards? Christian Sorry, please forget what I wrote above. We already have a CONFIG_DA850_LOWLEVEL option that already solves the problem. So removing CONFIG_ARCH_CPU_INIT is fine for me. Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/13] davinci: Use correct #ifdef around gdata/bdata
Hi,
On Mon, Feb 27, 2012 at 11:16 AM, Sughosh Ganu urwithsugh...@gmail.com wrote:
hi Simon,
On Sun Feb 26, 2012 at 09:56:37AM -0800, Simon Glass wrote:
Hi Sughosh,
On Thu, Feb 23, 2012 at 9:25 AM, Sughosh Ganu urwithsugh...@gmail.com
wrote:
hi Simon,
On Mon Feb 20, 2012 at 05:32:49PM -0800, Simon Glass wrote:
This fixes the following warnings in an SPL build when libcommon is
in use:
spl.c:37: warning: 'gdata' defined but not used
spl.c:38: warning: 'bdata' defined but not used
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v4:
- Add new patch to fix davinci build warnings
arch/arm/cpu/arm926ejs/davinci/spl.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
b/arch/arm/cpu/arm926ejs/davinci/spl.c
index b1eff26..2861907 100644
--- a/arch/arm/cpu/arm926ejs/davinci/spl.c
+++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
@@ -32,10 +32,12 @@
#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+#ifdef CONFIG_SPL_SPI_LOAD
DECLARE_GLOBAL_DATA_PTR;
/* Define global data structure pointer to it*/
static gd_t gdata __attribute__ ((section(.data)));
static bd_t bdata __attribute__ ((section(.data)));
+#endif
In arch/arm/cpu/arm926ejs/davinci/spl.c gdata and bdata are used for
serial_init() to allow output to the console from the SPL. However,
this is only the case when LIBCOMMON is used. LIBCOMMON is required
for booting from SPI, but not for booting from NAND. Up to now davinci
boards that boot from NAND with SPL did not use LIBCOMMON but used the
puts and putc functions defined in spl.c for console output.
Can you specify which boards you get this warning for. With your
patch to add libcommon to hawkboard's spl image, this is now also
needed for hawkboard which uses CONFIG_SPL_NAND_LOAD.
Simon's patch is for the hawkboard, since due to another patch in his
patchset LIBCOMMON is enabled in hawkboard's SPL. Now we have a board
that boots from NAND with SPL and has LIBCOMMON enabled (Simon, I did
not check the rest of your patchset, why do you need LIBCOMMON on the
hawkboard at all?)
However, the patch fixes the warning, but now we use putc and puts
from LIBCOMMON without initializing them. Thus it breaks the console
output of the hawkboard SPL.
So the correct solution would be to keep the ifdefs around the
definition of gdata and bdata as they are, but change board_init_f()
like this:
void board_init_r(gd_t *id, ulong dummy)
{
#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
CONFIG_SYS_MALLOC_LEN);
gd = gdata;
gd-bd = bdata;
gd-flags |= GD_FLG_RELOC;
gd-baudrate = CONFIG_BAUDRATE;
serial_init(); /* serial communications setup */
gd-have_console = 1;
#endif
#ifdef CONFIG_SPL_NAND_LOAD
nand_init();
puts(Nand boot...\n);
nand_boot();
#endif
#ifdef CONFIG_SPL_SPI_LOAD
puts(SPI boot...\n);
spi_boot();
#endif
}
Regards, Christian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/13] davinci: Use correct #ifdef around gdata/bdata
Hi Sughosh,
On Mon, Feb 27, 2012 at 11:56 AM, Sughosh Ganu urwithsugh...@gmail.com wrote:
hi Christian,
On Mon Feb 27, 2012 at 11:39:42AM +0100, Christian Riesch wrote:
Hi,
On Mon, Feb 27, 2012 at 11:16 AM, Sughosh Ganu urwithsugh...@gmail.com
wrote:
snip
arch/arm/cpu/arm926ejs/davinci/spl.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
b/arch/arm/cpu/arm926ejs/davinci/spl.c
index b1eff26..2861907 100644
--- a/arch/arm/cpu/arm926ejs/davinci/spl.c
+++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
@@ -32,10 +32,12 @@
#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+#ifdef CONFIG_SPL_SPI_LOAD
DECLARE_GLOBAL_DATA_PTR;
/* Define global data structure pointer to it*/
static gd_t gdata __attribute__ ((section(.data)));
static bd_t bdata __attribute__ ((section(.data)));
+#endif
snip
Can you specify which boards you get this warning for. With your
patch to add libcommon to hawkboard's spl image, this is now also
needed for hawkboard which uses CONFIG_SPL_NAND_LOAD.
Simon's patch is for the hawkboard, since due to another patch in his
patchset LIBCOMMON is enabled in hawkboard's SPL. Now we have a board
that boots from NAND with SPL and has LIBCOMMON enabled (Simon, I did
not check the rest of your patchset, why do you need LIBCOMMON on the
hawkboard at all?)
LIBCOMMON is now needed as the generic relocation based functions
are part of the libcommon.o, which are being enabled in the same
patchset for all arm boards. So if i understand correct, all arm
board based spl's now need libcommon and libgeneric.
The only thing i see is that libcommon and libgeneric are not
defined for cam_enc_4xx board which uses spl, and this patchset does
not add it either. Not sure whether it got missed.
When I asked Heiko Schocher a few month ago why he defined putc and
puts in arch/arm/cpu/arm926ejs/davinci/spl.c he replied that he could
not use LIBCOMMON due to size limitations for the SPL. So I guess that
this board will not be able to use the generic relocation functions,
unless the SPL is smaller than 16kB, right? Simon's patchset will
break this board then, right?
However, I we can make all davinci boards use LIBCOMMON, we can remove
the putc/puts functions from spl.c.
However, the patch fixes the warning, but now we use putc and puts
from LIBCOMMON without initializing them. Thus it breaks the console
output of the hawkboard SPL.
So the correct solution would be to keep the ifdefs around the
definition of gdata and bdata as they are, but change board_init_f()
like this:
I have a patch for this, which i will send today. There is only one
question i have though.
void board_init_r(gd_t *id, ulong dummy)
{
#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
CONFIG_SYS_MALLOC_LEN);
Can you please explain why we need the mem_malloc_init. I did not
include this, and spl boots up just fine on my board.
malloc is required for the SPI code only, so you could also put it
within #ifdef CONFIG_SPL_SPI_LOAD
Regards, Christian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V3] arm926: Flush the data cache before disabling it
Hi Albert, On Saturday, February 18, 2012, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Le 14/01/2012 15:02, Sughosh Ganu a écrit : The current implementation invalidates the cache instead of flushing it. This causes problems on platforms where the spl/u-boot is already loaded to the RAM, with caches enabled by a first stage bootloader. Also fix the comments to match code. Signed-off-by: Sughosh Ganuurwithsugh...@gmail.com Cc: Albert Aribaudalbert.u.b...@aribaud.net Cc: Tom Rinitr...@ti.com --- Changes since V3 * Removed tampering of the V bit setting. Would be done in a separate patch on the lines of review comments by Albert. Changes since V2 * Added code to invalidate I cache, based on review comment by Aneesh. * Fixed comments to match the code. Changes since V1 * Added arm926 keyword to the subject line * Removed the superfluous setting of r0. * Fixed the comment to reflect the fact that V is not being cleared arch/arm/cpu/arm926ejs/start.S | 12 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6a09c02..d64165a 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -355,14 +355,18 @@ _dynsym_start_ofs: */ cpu_init_crit: /* -* flush v4 I/D caches +* flush D cache before disabling it */ mov r0, #0 - mcr p15, 0, r0, c7, c7, 0 /* flush v3/v4 cache */ - mcr p15, 0, r0, c8, c7, 0 /* flush v4 TLB */ Please add a comment explaining what the loop is waiting for exactly: +flush_dcache: + mrc p15, 0, r15, c7, c10, 3 + bne flush_dcache That's the flush dcache code that is given in ARM's TRM for the 926ejs. Anyway, that's already in mainline. Shall we prepare a patch that adds a comment? Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/7] arm, arm926ejs: Do not clear the V bit on DA850 SoCs
Hello Heiko and Sughosh, On Wed, Feb 1, 2012 at 8:33 AM, Heiko Schocher h...@denx.de wrote: Sughosh Ganu wrote: On Tue, Jan 31, 2012 at 7:26 PM, Christian Riesch christian.rie...@omicron.at wrote: The V bit of the c1 register of CP15 should not be cleared since the SoC has no valid memory at 0x. Signed-off-by: Christian Riesch christian.rie...@omicron.at Reported-by: Sughosh Ganu urwithsugh...@gmail.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com --- arch/arm/cpu/arm926ejs/start.S | 5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index b39ed8a..b350480 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -372,7 +372,10 @@ flush_dcache: * disable MMU and D cache, and enable I cache */ mrc p15, 0, r0, c1, c0, 0 - bic r0, r0, #0x2300 /* clear bits 13, 9:8 (--V- --RS) */ + bic r0, r0, #0x0300 /* clear bits 9:8 ( --RS) */ +#ifndef CONFIG_SOC_DA850 + bic r0, r0, #0x2000 /* clear bit 13 (--V- ) */ +#endif Instead of checking for a particular SOC, can we introduce a generic config, something like CONFIG_EXCEPTION_VECTORS_LOW. This way, if other SOC's have a similar requirement, it won't be needed to keep adding checks here. It would also help in case this needs to be implemented for other arm cores, so that we can have a common config option for bypassing this V-bit clear. Just my suggestion. Maybe Tom and Albert can comment. Yep, I vote for this too, also this config option should be documented in the README. Ok, I'll change this to #ifdef CONFIG_EXCEPTION_VECTORS_HIGH orr r0, r0, #0x2000 /* set bit 13 (--V- ) */ #else bic r0, r0, #0x2000 /* clear bit 13 (--V- ) */ #endif Or should it be CONFIG_SYS_EXCEPTION_VECTORS_HIGH? I think I don't understand the explanation in README whether it should be _SYS_ or not. Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 7/7] arm, davinci: Add support for the Calimain board from OMICRON electronics
This patch adds support for the Calimain board from
OMICRON electronics GmbH. The board features a Texas Instruments AM1808
SoC, 128 MB DDR2 memory, and 64 MB NOR flash memory connected to CS2 and
CS3.
Signed-off-by: Christian Riesch christian.rie...@omicron.at
---
MAINTAINERS |5 +
board/omicron/calimain/Makefile | 45 +
board/omicron/calimain/calimain.c | 188 +++
boards.cfg|1 +
include/configs/calimain.h| 363 +
5 files changed, 602 insertions(+), 0 deletions(-)
create mode 100644 board/omicron/calimain/Makefile
create mode 100644 board/omicron/calimain/calimain.c
create mode 100644 include/configs/calimain.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 353f23d..61f9537 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -796,6 +796,11 @@ Thierry Reding thierry.red...@avionic-design.de
plutux Tegra2 (ARM7 A9 Dual Core)
medcom Tegra2 (ARM7 A9 Dual Core)
+Christian Riesch christian.rie...@omicron.at
+Manfred Rudigier manfred.rudig...@omicron.at
+
+ calimainARM926EJS (AM1808 SoC)
+
Tom Rini tr...@ti.com
omap3_evm ARM ARMV7 (OMAP3xx SoC)
diff --git a/board/omicron/calimain/Makefile b/board/omicron/calimain/Makefile
new file mode 100644
index 000..cd1f0d4
--- /dev/null
+++ b/board/omicron/calimain/Makefile
@@ -0,0 +1,45 @@
+#
+# (C) Copyright 2000, 2001, 2002
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# Copyright (C) 2007 Sergey Kubushyn k...@koi8.net
+#
+# 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 := $(BOARD).o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+# This is for $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/omicron/calimain/calimain.c
b/board/omicron/calimain/calimain.c
new file mode 100644
index 000..97ba74a
--- /dev/null
+++ b/board/omicron/calimain/calimain.c
@@ -0,0 +1,188 @@
+/*
+ * Copyright (C) 2011 OMICRON electronics GmbH
+ *
+ * Based on da850evm.c. Original Copyrights follow:
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2009 Nick Thompson, GE Fanuc, Ltd. nick.thomp...@gefanuc.com
+ * Copyright (C) 2007 Sergey Kubushyn k...@koi8.net
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include common.h
+#include i2c.h
+#include net.h
+#include netdev.h
+#include watchdog.h
+#include asm/io.h
+#include asm/arch/hardware.h
+#include asm/arch/gpio.h
+#include asm/arch/emif_defs.h
+#include asm/arch/emac_defs.h
+#include asm/arch/pinmux_defs.h
+#include asm/arch/davinci_misc.h
+#include asm/arch/timer_defs.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define CALIMAIN_HWVERSION_MASK0x7f00
+#define CALIMAIN_HWVERSION_SHIFT 24
+
+/* Hardware version pinmux settings */
+const struct pinmux_config hwversion_pins[] = {
+ { pinmux(16), 8, 2 }, /* GP7[15] */
+ { pinmux(16), 8, 3 }, /* GP7[14] */
+ { pinmux(16), 8, 4 }, /* GP7[13] */
+ { pinmux(16), 8, 5 }, /* GP7[12] */
+ { pinmux(16), 8, 6 }, /* GP7[11] */
+ { pinmux(16), 8, 7 }, /* GP7[10
[U-Boot] [PATCH v6 5/7] arm, arm926ejs: Enable icache only if CONFIG_SYS_ICACHE_OFF is not defined
Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com Acked-by: Heiko Schocher h...@denx.de Tested-by: Heiko Schocher h...@denx.de --- arch/arm/cpu/arm926ejs/start.S |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 525c112..6f05f1a 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -369,7 +369,8 @@ flush_dcache: mcr p15, 0, r0, c7, c5, 0 /* invalidate I Cache */ /* -* disable MMU and D cache, and enable I cache +* disable MMU and D cache +* enable I cache if CONFIG_SYS_ICACHE_OFF is not defined */ mrc p15, 0, r0, c1, c0, 0 bic r0, r0, #0x0300 /* clear bits 9:8 ( --RS) */ @@ -380,7 +381,9 @@ flush_dcache: bic r0, r0, #0x2000 /* clear bit 13 (--V- ) */ #endif orr r0, r0, #0x0002 /* set bit 2 (A) Align */ +#ifndef CONFIG_SYS_ICACHE_OFF orr r0, r0, #0x1000 /* set bit 12 (I) I-Cache */ +#endif mcr p15, 0, r0, c1, c0, 0 /* -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 0/7] Change ARM926EJ-S startup code, hawkboard and calimain
Hi,
In this patchset I tried to put everything from the discussion
in http://lists.denx.de/pipermail/u-boot/2012-January/115212.html
Although this is the second version of this patchset, the version number
is v6 since Sughosh's patches were already v4.
Changes since v5:
- introduced CONFIG_SYS_EXCEPTION_VECTORS_HIGH as requested by Sughosh
and Heiko
- added Acked-bys and Tested-bys
Regards, Christian
Christian Riesch (5):
arm, davinci: Add lowlevel_init for SoCs other than DM644X
arm, arm926ejs: Do cpu critical inits only for boards that require it
arm, arm926ejs: Add option CONFIG_SYS_EXCEPTION_VECTORS_HIGH
arm, arm926ejs: Enable icache only if CONFIG_SYS_ICACHE_OFF is not
defined
arm, davinci: Add support for the Calimain board from OMICRON
electronics
Sughosh Ganu (2):
arm, arm926ejs: Flush the data cache before disabling it
Changes to move hawkboard to the new spl infrastructure
MAINTAINERS|5 +
README |6 +
arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c| 24 +-
arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S |4 +
arch/arm/cpu/arm926ejs/davinci/spl.c |4 +-
arch/arm/cpu/arm926ejs/start.S | 28 ++-
arch/arm/include/asm/arch-davinci/da850_lowlevel.h |9 +
board/davinci/da8xxevm/da850evm.c |4 +-
board/davinci/da8xxevm/hawkboard.c | 23 ++
board/davinci/da8xxevm/hawkboard_nand_spl.c| 115 --
.../{u-boot-spl.lds = u-boot-spl-da850evm.lds}|0
.../davinci/da8xxevm/u-boot-spl-hawk.lds | 22 +-
board/enbw/enbw_cmc/enbw_cmc.c | 13 +-
board/omicron/calimain/Makefile| 45 +++
board/omicron/calimain/calimain.c | 188 ++
boards.cfg |2 +-
doc/README.hawkboard | 43 ++--
include/configs/calimain.h | 363
include/configs/cam_enc_4xx.h |6 -
include/configs/da850evm.h |7 +-
include/configs/enbw_cmc.h |6 +-
include/configs/hawkboard.h| 24 +-
nand_spl/board/davinci/da8xxevm/Makefile | 155 -
23 files changed, 750 insertions(+), 346 deletions(-)
delete mode 100644 board/davinci/da8xxevm/hawkboard_nand_spl.c
rename board/davinci/da8xxevm/{u-boot-spl.lds = u-boot-spl-da850evm.lds}
(100%)
rename nand_spl/board/davinci/da8xxevm/u-boot.lds =
board/davinci/da8xxevm/u-boot-spl-hawk.lds (86%)
create mode 100644 board/omicron/calimain/Makefile
create mode 100644 board/omicron/calimain/calimain.c
create mode 100644 include/configs/calimain.h
delete mode 100644 nand_spl/board/davinci/da8xxevm/Makefile
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 3/7] arm, arm926ejs: Flush the data cache before disabling it
From: Sughosh Ganu urwithsugh...@gmail.com The current implementation invalidates the data cache before turning it off and causes problems on the hawkboard. See the discussion in http://lists.denx.de/pipermail/u-boot/2012-January/115212.html According to the ARM926EJ-S Technical Reference Manual, the cache should be flushed instead. Also fix the comments to match code. Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com Rebased and corrected commit message. Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com Acked-by: Heiko Schocher h...@denx.de Tested-by: Heiko Schocher h...@denx.de --- arch/arm/cpu/arm926ejs/start.S | 12 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index bb4d00b..b39ed8a 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -358,14 +358,18 @@ _dynsym_start_ofs: #ifndef CONFIG_SKIP_LOWLEVEL_INIT cpu_init_crit: /* -* flush v4 I/D caches +* flush D cache before disabling it */ mov r0, #0 - mcr p15, 0, r0, c7, c7, 0 /* flush v3/v4 cache */ - mcr p15, 0, r0, c8, c7, 0 /* flush v4 TLB */ +flush_dcache: + mrc p15, 0, r15, c7, c10, 3 + bne flush_dcache + + mcr p15, 0, r0, c8, c7, 0 /* invalidate TLB */ + mcr p15, 0, r0, c7, c5, 0 /* invalidate I Cache */ /* -* disable MMU stuff and caches +* disable MMU and D cache, and enable I cache */ mrc p15, 0, r0, c1, c0, 0 bic r0, r0, #0x2300 /* clear bits 13, 9:8 (--V- --RS) */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 2/7] arm, arm926ejs: Do cpu critical inits only for boards that require it
This patch reverts commit ca4b55800ed74207c35271bf7335a092d4955416 arm, arm926ejs: always do cpu critical inits since it impacts all arm926ejs based configurations and caused problems, e.g., with the hawkboard. Instead the patch removes the CONFIG_SKIP_LOWLEVEL_INIT defines from the board configurations that need low level initialization. Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com Cc: Heiko Schocher h...@denx.de Acked-by: Heiko Schocher h...@denx.de Tested-by: Heiko Schocher h...@denx.de --- arch/arm/cpu/arm926ejs/start.S |6 -- include/configs/cam_enc_4xx.h |6 -- include/configs/da850evm.h |1 - include/configs/enbw_cmc.h |1 - 4 files changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6a09c02..bb4d00b 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -194,7 +194,9 @@ reset: * we do sys-critical inits only at reboot, * not when booting from ram! */ +#ifndef CONFIG_SKIP_LOWLEVEL_INIT bl cpu_init_crit +#endif /* Set stackpointer in internal RAM to call board_init_f */ call_board_init_f: @@ -353,6 +355,7 @@ _dynsym_start_ofs: * * */ +#ifndef CONFIG_SKIP_LOWLEVEL_INIT cpu_init_crit: /* * flush v4 I/D caches @@ -371,15 +374,14 @@ cpu_init_crit: orr r0, r0, #0x1000 /* set bit 12 (I) I-Cache */ mcr p15, 0, r0, c1, c0, 0 -#ifndef CONFIG_SKIP_LOWLEVEL_INIT /* * Go setup Memory and board specific bits prior to relocation. */ mov ip, lr /* perserve link reg across call */ bl lowlevel_init /* go setup pll,mux,memory */ mov lr, ip /* restore link */ -#endif /* CONFIG_SKIP_LOWLEVEL_INIT */ mov pc, lr /* back to my caller */ +#endif /* CONFIG_SKIP_LOWLEVEL_INIT */ #ifndef CONFIG_SPL_BUILD /* diff --git a/include/configs/cam_enc_4xx.h b/include/configs/cam_enc_4xx.h index a21d448..f4fe444 100644 --- a/include/configs/cam_enc_4xx.h +++ b/include/configs/cam_enc_4xx.h @@ -265,12 +265,6 @@ #define CONFIG_SYS_NAND_U_BOOT_OFFS0xc #define CONFIG_SYS_NAND_U_BOOT_SIZE0x6 -/* - * U-Boot is a 3rd stage loader and if booting with spl, cpu setup is - * done in board_init_f from c code. - */ -#define CONFIG_SKIP_LOWLEVEL_INIT - /* for UBL header */ #define CONFIG_SYS_UBL_BLOCK (CONFIG_SYS_NAND_PAGE_SIZE) diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h index fcbbace..f15a0a6 100644 --- a/include/configs/da850evm.h +++ b/include/configs/da850evm.h @@ -42,7 +42,6 @@ #define CONFIG_SYS_TIMERBASE DAVINCI_TIMER0_BASE #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID) #define CONFIG_SYS_HZ 1000 -#define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_SYS_TEXT_BASE 0xc108 /* diff --git a/include/configs/enbw_cmc.h b/include/configs/enbw_cmc.h index c427dc7..21cf647 100644 --- a/include/configs/enbw_cmc.h +++ b/include/configs/enbw_cmc.h @@ -45,7 +45,6 @@ #define CONFIG_SYS_TIMERBASE DAVINCI_TIMER0_BASE #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID) #define CONFIG_SYS_HZ 1000 -#define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_DA850_LOWLEVEL #define CONFIG_ARCH_CPU_INIT #define CONFIG_DA8XX_GPIO -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 4/7] arm, arm926ejs: Add option CONFIG_SYS_EXCEPTION_VECTORS_HIGH
The V bit of the c1 register of CP15 should not be cleared on DA850 SoCs since they have no valid memory at 0x. This patch introduces a configuration option CONFIG_SYS_EXCEPTION_VECTORS_HIGH that allows setting the correct value for the V bit. Signed-off-by: Christian Riesch christian.rie...@omicron.at Reported-by: Sughosh Ganu urwithsugh...@gmail.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com Cc: Sughosh Ganu urwithsugh...@gmail.com Cc: Heiko Schocher h...@denx.de --- README |6 ++ arch/arm/cpu/arm926ejs/start.S |7 ++- include/configs/da850evm.h |1 + include/configs/enbw_cmc.h |1 + include/configs/hawkboard.h|1 + 5 files changed, 15 insertions(+), 1 deletions(-) diff --git a/README b/README index 9d713e8..c5b0941 100644 --- a/README +++ b/README @@ -420,6 +420,12 @@ The following options need to be configured: XWAY SoCs for booting from NOR flash. The U-Boot image needs to be swapped if a flash programmer is used. +- ARM options: + CONFIG_SYS_EXCEPTION_VECTORS_HIGH + + Select high exception vectors of the ARM core, e.g., do not + clear the V bit of the c1 register of CP15. + - Linux Kernel Interface: CONFIG_CLOCKS_IN_MHZ diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index b39ed8a..525c112 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -372,8 +372,13 @@ flush_dcache: * disable MMU and D cache, and enable I cache */ mrc p15, 0, r0, c1, c0, 0 - bic r0, r0, #0x2300 /* clear bits 13, 9:8 (--V- --RS) */ + bic r0, r0, #0x0300 /* clear bits 9:8 ( --RS) */ bic r0, r0, #0x0087 /* clear bits 7, 2:0 (B--- -CAM) */ +#ifdef CONFIG_SYS_EXCEPTION_VECTORS_HIGH + orr r0, r0, #0x2000 /* set bit 13 (--V- ) */ +#else + bic r0, r0, #0x2000 /* clear bit 13 (--V- ) */ +#endif orr r0, r0, #0x0002 /* set bit 2 (A) Align */ orr r0, r0, #0x1000 /* set bit 12 (I) I-Cache */ mcr p15, 0, r0, c1, c0, 0 diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h index f15a0a6..85016df 100644 --- a/include/configs/da850evm.h +++ b/include/configs/da850evm.h @@ -37,6 +37,7 @@ #define CONFIG_ARM926EJS /* arm926ejs CPU core */ #define CONFIG_SOC_DA8XX /* TI DA8xx SoC */ #define CONFIG_SOC_DA850 /* TI DA850 SoC */ +#define CONFIG_SYS_EXCEPTION_VECTORS_HIGH #define CONFIG_SYS_CLK_FREQclk_get(DAVINCI_ARM_CLKID) #define CONFIG_SYS_OSCIN_FREQ 2400 #define CONFIG_SYS_TIMERBASE DAVINCI_TIMER0_BASE diff --git a/include/configs/enbw_cmc.h b/include/configs/enbw_cmc.h index 21cf647..0c9ab4c 100644 --- a/include/configs/enbw_cmc.h +++ b/include/configs/enbw_cmc.h @@ -40,6 +40,7 @@ #define CONFIG_ARM926EJS /* arm926ejs CPU core */ #define CONFIG_SOC_DA8XX /* TI DA8xx SoC */ #define CONFIG_SOC_DA850 /* TI DA850 SoC */ +#define CONFIG_SYS_EXCEPTION_VECTORS_HIGH #define CONFIG_SYS_CLK_FREQclk_get(DAVINCI_ARM_CLKID) #define CONFIG_SYS_OSCIN_FREQ 2400 #define CONFIG_SYS_TIMERBASE DAVINCI_TIMER0_BASE diff --git a/include/configs/hawkboard.h b/include/configs/hawkboard.h index 12acb27..ce78d3c 100644 --- a/include/configs/hawkboard.h +++ b/include/configs/hawkboard.h @@ -35,6 +35,7 @@ #define CONFIG_ARM926EJS /* arm926ejs CPU core */ #define CONFIG_SOC_DA8XX /* TI DA8xx SoC */ #define CONFIG_SOC_DA850 /* TI DA850 SoC */ +#define CONFIG_SYS_EXCEPTION_VECTORS_HIGH #define CONFIG_SYS_CLK_FREQclk_get(DAVINCI_ARM_CLKID) #define CONFIG_SYS_OSCIN_FREQ 2400 #define CONFIG_SYS_TIMERBASE DAVINCI_TIMER0_BASE -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 6/7] Changes to move hawkboard to the new spl infrastructure
From: Sughosh Ganu urwithsugh...@gmail.com
This patch moves hawkboard to the new spl infrastructure from the
older nand_spl one.
Removed the hawkboard_nand_config build option -- The spl code now
gets compiled with hawkboard_config, after building the main u-boot
image, using the CONFIG_SPL_TEXT_BASE. Modified the README.hawkboard
to reflect the same.
Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Christian Riesch christian.rie...@omicron.at
Cc: Sudhakar Rajashekhara sudhakar@ti.com
Cc: Tom Rini tr...@ti.com
Acked-by: Christian Riesch christian.rie...@omicron.at
---
arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c| 24 ++-
arch/arm/cpu/arm926ejs/davinci/spl.c |4 +-
arch/arm/include/asm/arch-davinci/da850_lowlevel.h |9 +
board/davinci/da8xxevm/da850evm.c |4 +-
board/davinci/da8xxevm/hawkboard.c | 23 +++
board/davinci/da8xxevm/hawkboard_nand_spl.c| 115 ---
.../{u-boot-spl.lds = u-boot-spl-da850evm.lds}|0
.../davinci/da8xxevm/u-boot-spl-hawk.lds | 22 ++-
board/enbw/enbw_cmc/enbw_cmc.c | 13 +--
boards.cfg |1 -
doc/README.hawkboard | 43 +++---
include/configs/da850evm.h |5 +-
include/configs/enbw_cmc.h |4 +-
include/configs/hawkboard.h| 23 +++-
nand_spl/board/davinci/da8xxevm/Makefile | 155
15 files changed, 114 insertions(+), 331 deletions(-)
delete mode 100644 board/davinci/da8xxevm/hawkboard_nand_spl.c
rename board/davinci/da8xxevm/{u-boot-spl.lds = u-boot-spl-da850evm.lds}
(100%)
rename nand_spl/board/davinci/da8xxevm/u-boot.lds =
board/davinci/da8xxevm/u-boot-spl-hawk.lds (86%)
delete mode 100644 nand_spl/board/davinci/da8xxevm/Makefile
diff --git a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
index eec06bc..df7d6a2 100644
--- a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
+++ b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
@@ -32,6 +32,7 @@
#include asm/arch/emif_defs.h
#include asm/arch/pll_defs.h
+#if defined(CONFIG_SYS_DA850_PLL_INIT)
void da850_waitloop(unsigned long loopcnt)
{
unsigned long i;
@@ -163,7 +164,9 @@ int da850_pll_init(struct davinci_pllc_regs *reg, unsigned
long pllmult)
return 0;
}
+#endif /* CONFIG_SYS_DA850_PLL_INIT */
+#if defined(CONFIG_SYS_DA850_DDR_INIT)
int da850_ddr_setup(void)
{
unsigned long tmp;
@@ -242,6 +245,7 @@ int da850_ddr_setup(void)
return 0;
}
+#endif /* CONFIG_SYS_DA850_DDR_INIT */
__attribute__((weak))
void board_gpio_init(void)
@@ -249,10 +253,6 @@ void board_gpio_init(void)
return;
}
-/* pinmux_resource[] vector is defined in the board specific file */
-extern const struct pinmux_resource pinmuxes[];
-extern const int pinmuxes_size;
-
int arch_cpu_init(void)
{
/* Unlock kick registers */
@@ -266,13 +266,11 @@ int arch_cpu_init(void)
if (davinci_configure_pin_mux_items(pinmuxes, pinmuxes_size))
return 1;
+#if defined(CONFIG_SYS_DA850_PLL_INIT)
/* PLL setup */
da850_pll_init(davinci_pllc0_regs, CONFIG_SYS_DA850_PLL0_PLLM);
da850_pll_init(davinci_pllc1_regs, CONFIG_SYS_DA850_PLL1_PLLM);
-
- /* GPIO setup */
- board_gpio_init();
-
+#endif
/* setup CSn config */
#if defined(CONFIG_SYS_DA850_CS2CFG)
writel(CONFIG_SYS_DA850_CS2CFG, davinci_emif_regs-ab1cr);
@@ -281,7 +279,12 @@ int arch_cpu_init(void)
writel(CONFIG_SYS_DA850_CS3CFG, davinci_emif_regs-ab2cr);
#endif
- lpsc_on(CONFIG_SYS_DA850_LPSC_UART);
+ da8xx_configure_lpsc_items(lpsc, lpsc_size);
+
+ /* GPIO setup */
+ board_gpio_init();
+
+
NS16550_init((NS16550_t)(CONFIG_SYS_NS16550_COM1),
CONFIG_SYS_NS16550_CLK / 16 / CONFIG_BAUDRATE);
@@ -293,6 +296,9 @@ int arch_cpu_init(void)
DAVINCI_UART_PWREMU_MGMT_UTRST),
davinci_uart2_ctrl_regs-pwremu_mgmt);
+#if defined(CONFIG_SYS_DA850_DDR_INIT)
da850_ddr_setup();
+#endif
+
return 0;
}
diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
b/arch/arm/cpu/arm926ejs/davinci/spl.c
index f475f9b..74632e5 100644
--- a/arch/arm/cpu/arm926ejs/davinci/spl.c
+++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
@@ -74,12 +74,12 @@ void board_init_f(ulong dummy)
void board_init_r(gd_t *id, ulong dummy)
{
-#ifdef CONFIG_SOC_DM365
+#ifdef CONFIG_SPL_NAND_LOAD
nand_init();
puts(Nand boot...\n);
nand_boot();
#endif
-#ifdef CONFIG_SOC_DA8XX
+#ifdef CONFIG_SPL_SPI_LOAD
mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
CONFIG_SYS_MALLOC_LEN);
diff --git a/arch/arm/include/asm
[U-Boot] [PATCH v6 1/7] arm, davinci: Add lowlevel_init for SoCs other than DM644X
The low level initialization code in arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S was written for DM644X SoCs only. This patch makes the lowlevel_init function in this file a dummy function for SoCs other than DM644X. Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Tom Rini tr...@ti.com Cc: Sergey Kubushyn k...@koi8.net Acked-by: Heiko Schocher h...@denx.de Tested-by: Heiko Schocher h...@denx.de --- arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S b/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S index 7a169b1..5b39484 100644 --- a/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S +++ b/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S @@ -49,6 +49,7 @@ .globl lowlevel_init lowlevel_init: +#ifdef CONFIG_SOC_DM644X /*---* * Mask all IRQs by setting all bits in the EINT default * @@ -707,3 +708,6 @@ DDR2_START_ADDR: .word 0x8000 DUMMY_VAL: .word 0xa55aa55a +#else /* CONFIG_SOC_DM644X */ + mov pc, lr +#endif -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] da850evm: add board specific functions
Hi, Thank you for re-submitting the patchset! On Thu, Feb 2, 2012 at 2:42 PM, Manjunath Hadli manjunath.ha...@ti.com wrote: There are two da850 SOC based EVMs, one from Spectrum digital and other from Logic PD. Boards from Spectrum digital have mac address stored in I2C EEPROM and they have spi flash manufactured by WINBOND. Boards from Logic PD store mac address in ST Microelectronics SPI flash. This patch series adds support to read mac address from the appropriate device. Ok, so we have two configurations, we have da850evm which is for LogicPD's OMAP-L138 SoM and for LogicPD's AM1808 SoM, and we have da850_am18xxevm which must be used for the AM1808 board from Spectrum Digital. Is that correct? I wonder if we should change the name of the da850_am18xxevm configuration. It's quite confusing, until today I thought that the da850_am18xxevm was a configuration for LogicPD's AM1808 SoM... Are there also OMAP-L138 boards from Spectrum Digital? Regards, Christian These patches have undergone a review previously, but since the tree has moved ahead Christian and Tom asked to resubmit the patches for review. (http://www.mail-archive.com/u-boot@lists.denx.de/msg76220.html) Manjunath Hadli (2): da850evm: add support to read mac address from spi flash da850evm: read mac address from I2C EEPROM on AM18x EVM board/davinci/da8xxevm/da850evm.c | 66 + boards.cfg | 4 +- 2 files changed, 68 insertions(+), 2 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/7] Change ARM926EJ-S startup code, hawkboard and calimain
Hi,
In this patchset I tried to put everything from the discussion
in http://lists.denx.de/pipermail/u-boot/2012-January/115212.html
Although this is the first version of this patchset, the version number
is v5 since Sughosh's patches were already v4.
Regards, Christian
Christian Riesch (5):
arm, davinci: Add lowlevel_init for SoCs other than DM644X
arm, arm926ejs: Do cpu critical inits only for boards that require it
arm, arm926ejs: Do not clear the V bit on DA850 SoCs
arm, arm926ejs: Enable icache only if CONFIG_SYS_ICACHE_OFF is not
defined
arm, davinci: Add support for the Calimain board from OMICRON
electronics
Sughosh Ganu (2):
arm, arm926ejs: Flush the data cache before disabling it
Changes to move hawkboard to the new spl infrastructure
MAINTAINERS|5 +
arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c| 24 +-
arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S |4 +
arch/arm/cpu/arm926ejs/davinci/spl.c |4 +-
arch/arm/cpu/arm926ejs/start.S | 26 +-
arch/arm/include/asm/arch-davinci/da850_lowlevel.h |9 +
board/davinci/da8xxevm/da850evm.c |4 +-
board/davinci/da8xxevm/hawkboard.c | 23 ++
board/davinci/da8xxevm/hawkboard_nand_spl.c| 115 ---
.../{u-boot-spl.lds = u-boot-spl-da850evm.lds}|0
.../davinci/da8xxevm/u-boot-spl-hawk.lds | 22 +-
board/enbw/enbw_cmc/enbw_cmc.c | 13 +-
board/omicron/calimain/Makefile| 45 +++
board/omicron/calimain/calimain.c | 188 ++
boards.cfg |2 +-
doc/README.hawkboard | 43 ++--
include/configs/calimain.h | 362
include/configs/cam_enc_4xx.h |6 -
include/configs/da850evm.h |6 +-
include/configs/enbw_cmc.h |5 +-
include/configs/hawkboard.h| 23 +-
nand_spl/board/davinci/da8xxevm/Makefile | 155 -
22 files changed, 738 insertions(+), 346 deletions(-)
delete mode 100644 board/davinci/da8xxevm/hawkboard_nand_spl.c
rename board/davinci/da8xxevm/{u-boot-spl.lds = u-boot-spl-da850evm.lds}
(100%)
rename nand_spl/board/davinci/da8xxevm/u-boot.lds =
board/davinci/da8xxevm/u-boot-spl-hawk.lds (86%)
create mode 100644 board/omicron/calimain/Makefile
create mode 100644 board/omicron/calimain/calimain.c
create mode 100644 include/configs/calimain.h
delete mode 100644 nand_spl/board/davinci/da8xxevm/Makefile
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 5/7] arm, arm926ejs: Enable icache only if CONFIG_SYS_ICACHE_OFF is not defined
Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com --- arch/arm/cpu/arm926ejs/start.S |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index b350480..829065f 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -369,7 +369,8 @@ flush_dcache: mcr p15, 0, r0, c7, c5, 0 /* invalidate I Cache */ /* -* disable MMU and D cache, and enable I cache +* disable MMU and D cache +* enable I cache if CONFIG_SYS_ICACHE_OFF is not defined */ mrc p15, 0, r0, c1, c0, 0 bic r0, r0, #0x0300 /* clear bits 9:8 ( --RS) */ @@ -378,7 +379,9 @@ flush_dcache: #endif bic r0, r0, #0x0087 /* clear bits 7, 2:0 (B--- -CAM) */ orr r0, r0, #0x0002 /* set bit 2 (A) Align */ +#ifndef CONFIG_SYS_ICACHE_OFF orr r0, r0, #0x1000 /* set bit 12 (I) I-Cache */ +#endif mcr p15, 0, r0, c1, c0, 0 /* -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 4/7] arm, arm926ejs: Do not clear the V bit on DA850 SoCs
The V bit of the c1 register of CP15 should not be cleared since the SoC has no valid memory at 0x. Signed-off-by: Christian Riesch christian.rie...@omicron.at Reported-by: Sughosh Ganu urwithsugh...@gmail.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com --- arch/arm/cpu/arm926ejs/start.S |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index b39ed8a..b350480 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -372,7 +372,10 @@ flush_dcache: * disable MMU and D cache, and enable I cache */ mrc p15, 0, r0, c1, c0, 0 - bic r0, r0, #0x2300 /* clear bits 13, 9:8 (--V- --RS) */ + bic r0, r0, #0x0300 /* clear bits 9:8 ( --RS) */ +#ifndef CONFIG_SOC_DA850 + bic r0, r0, #0x2000 /* clear bit 13 (--V- ) */ +#endif bic r0, r0, #0x0087 /* clear bits 7, 2:0 (B--- -CAM) */ orr r0, r0, #0x0002 /* set bit 2 (A) Align */ orr r0, r0, #0x1000 /* set bit 12 (I) I-Cache */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/7] arm, davinci: Add lowlevel_init for SoCs other than DM644X
The low level initialization code in arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S was written for DM644X SoCs only. This patch makes the lowlevel_init function in this file a dummy function for SoCs other than DM644X. Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Tom Rini tr...@ti.com Cc: Sergey Kubushyn k...@koi8.net --- arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S b/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S index 7a169b1..5b39484 100644 --- a/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S +++ b/arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S @@ -49,6 +49,7 @@ .globl lowlevel_init lowlevel_init: +#ifdef CONFIG_SOC_DM644X /*---* * Mask all IRQs by setting all bits in the EINT default * @@ -707,3 +708,6 @@ DDR2_START_ADDR: .word 0x8000 DUMMY_VAL: .word 0xa55aa55a +#else /* CONFIG_SOC_DM644X */ + mov pc, lr +#endif -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 7/7] arm, davinci: Add support for the Calimain board from OMICRON electronics
This patch adds support for the Calimain board from
OMICRON electronics GmbH. The board features a Texas Instruments AM1808
SoC, 128 MB DDR2 memory, and 64 MB NOR flash memory connected to CS2 and
CS3.
Signed-off-by: Christian Riesch christian.rie...@omicron.at
---
MAINTAINERS |5 +
board/omicron/calimain/Makefile | 45 +
board/omicron/calimain/calimain.c | 188 +++
boards.cfg|1 +
include/configs/calimain.h| 362 +
5 files changed, 601 insertions(+), 0 deletions(-)
create mode 100644 board/omicron/calimain/Makefile
create mode 100644 board/omicron/calimain/calimain.c
create mode 100644 include/configs/calimain.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 353f23d..61f9537 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -796,6 +796,11 @@ Thierry Reding thierry.red...@avionic-design.de
plutux Tegra2 (ARM7 A9 Dual Core)
medcom Tegra2 (ARM7 A9 Dual Core)
+Christian Riesch christian.rie...@omicron.at
+Manfred Rudigier manfred.rudig...@omicron.at
+
+ calimainARM926EJS (AM1808 SoC)
+
Tom Rini tr...@ti.com
omap3_evm ARM ARMV7 (OMAP3xx SoC)
diff --git a/board/omicron/calimain/Makefile b/board/omicron/calimain/Makefile
new file mode 100644
index 000..cd1f0d4
--- /dev/null
+++ b/board/omicron/calimain/Makefile
@@ -0,0 +1,45 @@
+#
+# (C) Copyright 2000, 2001, 2002
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# Copyright (C) 2007 Sergey Kubushyn k...@koi8.net
+#
+# 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 := $(BOARD).o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+# This is for $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/omicron/calimain/calimain.c
b/board/omicron/calimain/calimain.c
new file mode 100644
index 000..97ba74a
--- /dev/null
+++ b/board/omicron/calimain/calimain.c
@@ -0,0 +1,188 @@
+/*
+ * Copyright (C) 2011 OMICRON electronics GmbH
+ *
+ * Based on da850evm.c. Original Copyrights follow:
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2009 Nick Thompson, GE Fanuc, Ltd. nick.thomp...@gefanuc.com
+ * Copyright (C) 2007 Sergey Kubushyn k...@koi8.net
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include common.h
+#include i2c.h
+#include net.h
+#include netdev.h
+#include watchdog.h
+#include asm/io.h
+#include asm/arch/hardware.h
+#include asm/arch/gpio.h
+#include asm/arch/emif_defs.h
+#include asm/arch/emac_defs.h
+#include asm/arch/pinmux_defs.h
+#include asm/arch/davinci_misc.h
+#include asm/arch/timer_defs.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define CALIMAIN_HWVERSION_MASK0x7f00
+#define CALIMAIN_HWVERSION_SHIFT 24
+
+/* Hardware version pinmux settings */
+const struct pinmux_config hwversion_pins[] = {
+ { pinmux(16), 8, 2 }, /* GP7[15] */
+ { pinmux(16), 8, 3 }, /* GP7[14] */
+ { pinmux(16), 8, 4 }, /* GP7[13] */
+ { pinmux(16), 8, 5 }, /* GP7[12] */
+ { pinmux(16), 8, 6 }, /* GP7[11] */
+ { pinmux(16), 8, 7 }, /* GP7[10
[U-Boot] [PATCH v5 3/7] arm, arm926ejs: Flush the data cache before disabling it
From: Sughosh Ganu urwithsugh...@gmail.com The current implementation invalidates the data cache before turning it off and causes problems on the hawkboard. See the discussion in http://lists.denx.de/pipermail/u-boot/2012-January/115212.html According to the ARM926EJ-S Technical Reference Manual, the cache should be flushed instead. Also fix the comments to match code. Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com Rebased and corrected commit message. Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com --- arch/arm/cpu/arm926ejs/start.S | 12 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index bb4d00b..b39ed8a 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -358,14 +358,18 @@ _dynsym_start_ofs: #ifndef CONFIG_SKIP_LOWLEVEL_INIT cpu_init_crit: /* -* flush v4 I/D caches +* flush D cache before disabling it */ mov r0, #0 - mcr p15, 0, r0, c7, c7, 0 /* flush v3/v4 cache */ - mcr p15, 0, r0, c8, c7, 0 /* flush v4 TLB */ +flush_dcache: + mrc p15, 0, r15, c7, c10, 3 + bne flush_dcache + + mcr p15, 0, r0, c8, c7, 0 /* invalidate TLB */ + mcr p15, 0, r0, c7, c5, 0 /* invalidate I Cache */ /* -* disable MMU stuff and caches +* disable MMU and D cache, and enable I cache */ mrc p15, 0, r0, c1, c0, 0 bic r0, r0, #0x2300 /* clear bits 13, 9:8 (--V- --RS) */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/7] arm, arm926ejs: Do cpu critical inits only for boards that require it
This patch reverts commit ca4b55800ed74207c35271bf7335a092d4955416 arm, arm926ejs: always do cpu critical inits since it impacts all arm926ejs based configurations and caused problems, e.g., with the hawkboard. Instead the patch removes the CONFIG_SKIP_LOWLEVEL_INIT defines from the board configurations that need low level initialization. Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com Cc: Heiko Schocher h...@denx.de --- arch/arm/cpu/arm926ejs/start.S |6 -- include/configs/cam_enc_4xx.h |6 -- include/configs/da850evm.h |1 - include/configs/enbw_cmc.h |1 - 4 files changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6a09c02..bb4d00b 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -194,7 +194,9 @@ reset: * we do sys-critical inits only at reboot, * not when booting from ram! */ +#ifndef CONFIG_SKIP_LOWLEVEL_INIT bl cpu_init_crit +#endif /* Set stackpointer in internal RAM to call board_init_f */ call_board_init_f: @@ -353,6 +355,7 @@ _dynsym_start_ofs: * * */ +#ifndef CONFIG_SKIP_LOWLEVEL_INIT cpu_init_crit: /* * flush v4 I/D caches @@ -371,15 +374,14 @@ cpu_init_crit: orr r0, r0, #0x1000 /* set bit 12 (I) I-Cache */ mcr p15, 0, r0, c1, c0, 0 -#ifndef CONFIG_SKIP_LOWLEVEL_INIT /* * Go setup Memory and board specific bits prior to relocation. */ mov ip, lr /* perserve link reg across call */ bl lowlevel_init /* go setup pll,mux,memory */ mov lr, ip /* restore link */ -#endif /* CONFIG_SKIP_LOWLEVEL_INIT */ mov pc, lr /* back to my caller */ +#endif /* CONFIG_SKIP_LOWLEVEL_INIT */ #ifndef CONFIG_SPL_BUILD /* diff --git a/include/configs/cam_enc_4xx.h b/include/configs/cam_enc_4xx.h index a21d448..f4fe444 100644 --- a/include/configs/cam_enc_4xx.h +++ b/include/configs/cam_enc_4xx.h @@ -265,12 +265,6 @@ #define CONFIG_SYS_NAND_U_BOOT_OFFS0xc #define CONFIG_SYS_NAND_U_BOOT_SIZE0x6 -/* - * U-Boot is a 3rd stage loader and if booting with spl, cpu setup is - * done in board_init_f from c code. - */ -#define CONFIG_SKIP_LOWLEVEL_INIT - /* for UBL header */ #define CONFIG_SYS_UBL_BLOCK (CONFIG_SYS_NAND_PAGE_SIZE) diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h index fcbbace..f15a0a6 100644 --- a/include/configs/da850evm.h +++ b/include/configs/da850evm.h @@ -42,7 +42,6 @@ #define CONFIG_SYS_TIMERBASE DAVINCI_TIMER0_BASE #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID) #define CONFIG_SYS_HZ 1000 -#define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_SYS_TEXT_BASE 0xc108 /* diff --git a/include/configs/enbw_cmc.h b/include/configs/enbw_cmc.h index c427dc7..21cf647 100644 --- a/include/configs/enbw_cmc.h +++ b/include/configs/enbw_cmc.h @@ -45,7 +45,6 @@ #define CONFIG_SYS_TIMERBASE DAVINCI_TIMER0_BASE #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID) #define CONFIG_SYS_HZ 1000 -#define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_DA850_LOWLEVEL #define CONFIG_ARCH_CPU_INIT #define CONFIG_DA8XX_GPIO -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 6/7] Changes to move hawkboard to the new spl infrastructure
From: Sughosh Ganu urwithsugh...@gmail.com
This patch moves hawkboard to the new spl infrastructure from the
older nand_spl one.
Removed the hawkboard_nand_config build option -- The spl code now
gets compiled with hawkboard_config, after building the main u-boot
image, using the CONFIG_SPL_TEXT_BASE. Modified the README.hawkboard
to reflect the same.
Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Christian Riesch christian.rie...@omicron.at
Cc: Sudhakar Rajashekhara sudhakar@ti.com
Cc: Tom Rini tr...@ti.com
Acked-by: Christian Riesch christian.rie...@omicron.at
---
arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c| 24 ++-
arch/arm/cpu/arm926ejs/davinci/spl.c |4 +-
arch/arm/include/asm/arch-davinci/da850_lowlevel.h |9 +
board/davinci/da8xxevm/da850evm.c |4 +-
board/davinci/da8xxevm/hawkboard.c | 23 +++
board/davinci/da8xxevm/hawkboard_nand_spl.c| 115 ---
.../{u-boot-spl.lds = u-boot-spl-da850evm.lds}|0
.../davinci/da8xxevm/u-boot-spl-hawk.lds | 22 ++-
board/enbw/enbw_cmc/enbw_cmc.c | 13 +--
boards.cfg |1 -
doc/README.hawkboard | 43 +++---
include/configs/da850evm.h |5 +-
include/configs/enbw_cmc.h |4 +-
include/configs/hawkboard.h| 23 +++-
nand_spl/board/davinci/da8xxevm/Makefile | 155
15 files changed, 114 insertions(+), 331 deletions(-)
delete mode 100644 board/davinci/da8xxevm/hawkboard_nand_spl.c
rename board/davinci/da8xxevm/{u-boot-spl.lds = u-boot-spl-da850evm.lds}
(100%)
rename nand_spl/board/davinci/da8xxevm/u-boot.lds =
board/davinci/da8xxevm/u-boot-spl-hawk.lds (86%)
delete mode 100644 nand_spl/board/davinci/da8xxevm/Makefile
diff --git a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
index eec06bc..df7d6a2 100644
--- a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
+++ b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
@@ -32,6 +32,7 @@
#include asm/arch/emif_defs.h
#include asm/arch/pll_defs.h
+#if defined(CONFIG_SYS_DA850_PLL_INIT)
void da850_waitloop(unsigned long loopcnt)
{
unsigned long i;
@@ -163,7 +164,9 @@ int da850_pll_init(struct davinci_pllc_regs *reg, unsigned
long pllmult)
return 0;
}
+#endif /* CONFIG_SYS_DA850_PLL_INIT */
+#if defined(CONFIG_SYS_DA850_DDR_INIT)
int da850_ddr_setup(void)
{
unsigned long tmp;
@@ -242,6 +245,7 @@ int da850_ddr_setup(void)
return 0;
}
+#endif /* CONFIG_SYS_DA850_DDR_INIT */
__attribute__((weak))
void board_gpio_init(void)
@@ -249,10 +253,6 @@ void board_gpio_init(void)
return;
}
-/* pinmux_resource[] vector is defined in the board specific file */
-extern const struct pinmux_resource pinmuxes[];
-extern const int pinmuxes_size;
-
int arch_cpu_init(void)
{
/* Unlock kick registers */
@@ -266,13 +266,11 @@ int arch_cpu_init(void)
if (davinci_configure_pin_mux_items(pinmuxes, pinmuxes_size))
return 1;
+#if defined(CONFIG_SYS_DA850_PLL_INIT)
/* PLL setup */
da850_pll_init(davinci_pllc0_regs, CONFIG_SYS_DA850_PLL0_PLLM);
da850_pll_init(davinci_pllc1_regs, CONFIG_SYS_DA850_PLL1_PLLM);
-
- /* GPIO setup */
- board_gpio_init();
-
+#endif
/* setup CSn config */
#if defined(CONFIG_SYS_DA850_CS2CFG)
writel(CONFIG_SYS_DA850_CS2CFG, davinci_emif_regs-ab1cr);
@@ -281,7 +279,12 @@ int arch_cpu_init(void)
writel(CONFIG_SYS_DA850_CS3CFG, davinci_emif_regs-ab2cr);
#endif
- lpsc_on(CONFIG_SYS_DA850_LPSC_UART);
+ da8xx_configure_lpsc_items(lpsc, lpsc_size);
+
+ /* GPIO setup */
+ board_gpio_init();
+
+
NS16550_init((NS16550_t)(CONFIG_SYS_NS16550_COM1),
CONFIG_SYS_NS16550_CLK / 16 / CONFIG_BAUDRATE);
@@ -293,6 +296,9 @@ int arch_cpu_init(void)
DAVINCI_UART_PWREMU_MGMT_UTRST),
davinci_uart2_ctrl_regs-pwremu_mgmt);
+#if defined(CONFIG_SYS_DA850_DDR_INIT)
da850_ddr_setup();
+#endif
+
return 0;
}
diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
b/arch/arm/cpu/arm926ejs/davinci/spl.c
index f475f9b..74632e5 100644
--- a/arch/arm/cpu/arm926ejs/davinci/spl.c
+++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
@@ -74,12 +74,12 @@ void board_init_f(ulong dummy)
void board_init_r(gd_t *id, ulong dummy)
{
-#ifdef CONFIG_SOC_DM365
+#ifdef CONFIG_SPL_NAND_LOAD
nand_init();
puts(Nand boot...\n);
nand_boot();
#endif
-#ifdef CONFIG_SOC_DA8XX
+#ifdef CONFIG_SPL_SPI_LOAD
mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
CONFIG_SYS_MALLOC_LEN);
diff --git a/arch/arm/include/asm
Re: [U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.
Hi Tom, On Mon, Jan 30, 2012 at 6:03 PM, Tom Rini tom.r...@gmail.com wrote: On Sun, Jan 29, 2012 at 6:36 AM, Christian Riesch christian.rie...@omicron.at wrote: 3) As Sughosh pointed out, the current code changes the V bit (location of exceptions). Sughosh's patch removes this code that does this change. I'm not sure if this is correct or not, so maybe you, Tom, could put your TI hat on again and clarify this? OK, I've asked Christian for questions I can pass along, and here's what's I've learned: Thanks a lot! Q1) Currently, the low level initialization code for ARM926EJS CPUs in the u-boot bootloader clears the V-bit of the cp15 control register c1. By default, this bit is set on AM1808 and OMAP-L138 before u-boot ist started. Sughosh Ganu now submitted a patch to remove the code that clears the V bit because he states that these SoCs have no valid memory region at 0x0. I had a look at the memory map of the AM1808 and yes, there is no valid memory at 0x0, so the V bit should be set and not cleared. My question is: Since the AM1808 has no valid memory at 0x0, does clearing the V bit have any effect on the operation of the processor? Or is is just a don't care bit since it doesn't make any sense to clear it? A1) This may be a design question, but I can say that the default value of the V-bit is set to 1 because of tie-offs to the core, but I'm not sure if the functionality of the V-bit is still active. I would guess that it is because I see no reason we would have mucked around in the ARM core design to remove that functionality, so unless there is another tie-off to the core that disables the V-bit functionality entirely, I would guess clearing the V-bit is not a good idea. In fact, I don't see why the u-boot init code needs to mess with the default value of that bit ever, for any device or arch. Ok. So this should not be cleared, at least not for davinci. Q2) RBL: In an earlier post to the u-boot mailing list Tom Rini wrote that the RBLs of AM1808 and OMAP-L138 do not turn on caches. Does this mean that caches (dcache and/or icache) are *never* enabled or does it mean that they get enabled and then disabled before RBL exits. In the latter case, does RBL do everything that is necessary to ensure consistency between data and instruction streams (as described in the ARM926EJ-S Technical Reference Manual, http://infocenter.arm.com/help/index.jsp, Section Instruction Memory Barrier.1. About the instruction memory barrier operation)? Are there maybe earlier versions of RBL in earlier versions of the SoC that have a bug here? A2) The RBL NEVER enables the caches. Unfortunately, this does slow the operation of the ROM boot loader, but it is what is I think this ends our speculations about RBL causing the hawkboard problems. We will need someone with a hawkboard and a JTAG debugger to find out more... For now I think we should make these changes: 1) correct the comments 2) replace invalidating the cache with flushing the cache since this is the way to do it according to the ARM manual (Sughosh's patch) 3) do not clear the V bit on DA850 SoCs 4) revert Heiko's patch that changes the behavior of CONFIG_SKIP_LOWLEVEL_INIT and add a possibility to remove this option on boards that need lowlevel config 2) respect CONFIG_SYS_ICACHE_OFF I prepared a patchset that also includes Sughosh's patches and have just submitted it (The people on Cc received it twice, sorry for this...). Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] slow flash write with Freescale P1020 and PC28F256J3 NOR-flash
Hi Daniel, On Tuesday, January 31, 2012, Daniel Nilsson gnuf...@gmail.com wrote: I am bringing up a board that has a Freescale P1020 (PowerPC e500v2) and a 16-bit PC28F256J3 NOR-flash on it. My problem is that both erases and programming takes very long time. Reading from the flash on the other hand, is quite fast (at least a few MByte/s). I have set up the BR0, OR0 and other GPCM-related parameters to be as fast as the datasheet allows. To give an example of how slow it is, programming 24MiB data takes around 45 minutes. Erasing the area before programming takes 2-3 minutes. I have based my project on a 2011.09 version of u-boot. Is there any known limitation, problem or workaround? Erasing: sounds ok, seems to agree with the data sheet. Writing should be faster. I had the same problem until I enabled buffer write. Make sure you have #define CONFIG_SYS_FLASH_USE_BUFFER_WRITE in your board config. Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] SPL: Add YMODEM over UART load support
Hi Tom, Hi Matt,
On Tuesday, January 31, 2012, Tom Rini tr...@ti.com wrote:
From: Matt Porter mpor...@ti.com
Adds support for loading U-Boot from UART using YMODEM protocol.
If YMODEM support is enabled in SPL and the romcode indicates
that SPL loaded via UART then SPL will wait for start of a
YMODEM transfer via the console port.
:-) I like this feature!
I tried something similar a few month ago for the da850evm and my own
board, it worked but I never had time to finished it and submit it, it was
just a hack.
For my tests I used the UART loader utility from TI to load the SPL and
then minicom for loading u-boot. Do you have an automated solution for
this? Would be nice to have something like this in tools/.
Signed-off-by: Matt Porter mpor...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/omap-common/Makefile |3 +
arch/arm/cpu/armv7/omap-common/spl.c|5 ++
arch/arm/cpu/armv7/omap-common/spl_ymodem.c | 76
+++
arch/arm/include/asm/omap_common.h |3 +
common/Makefile |3 +
lib/Makefile|3 +
6 files changed, 93 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/cpu/armv7/omap-common/spl_ymodem.c
[...]
diff --git a/arch/arm/cpu/armv7/omap-common/spl_ymodem.c
b/arch/arm/cpu/armv7/omap-common/spl_ymodem.c
Could this be somewhere where it's accessible for other SoC families like
davinci? E.g. We have nand_spl_load.c in drivers/mtd/nand and something
similar for SPI flash.
Regards, Christian
new file mode 100644
index 000..47663f7
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/spl_ymodem.c
@@ -0,0 +1,76 @@
+/*
+ * (C) Copyright 2000-2004
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * (C) Copyright 2011
+ * Texas Instruments, www.ti.com
+ *
+ * Matt Porter mpor...@ti.com
+ *
+ * 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 common.h
+#include xyzModem.h
+#include asm/u-boot.h
+#include asm/utils.h
+#include asm/arch/sys_proto.h
+#include asm/omap_common.h
+
+#define BUF_SIZE 1024
+
+static int getcymodem(void) {
+ if (tstc())
+ return (getc());
+ return -1;
+}
+
+void spl_ymodem_load_image(void)
+{
+ int size = 0;
+ int err;
+ int res;
+ int ret;
+ connection_info_t info;
+ char buf[BUF_SIZE];
+ ulong store_addr = ~0;
+ ulong addr = 0;
+
+ info.mode = xyzModem_ymodem;
+ ret = xyzModem_stream_open(info, err);
+
+ if (!ret) {
+ while ((res =
+ xyzModem_stream_read(buf, BUF_SIZE, err)) 0) {
+ if (addr == 0)
+ spl_parse_image_header((struct
image_header *)buf);
+ store_addr = addr + spl_image.load_addr;
+ size += res;
+ addr += res;
+ memcpy((char *)(store_addr), buf, res);
+ }
+ } else {
+ printf(spl: ymodem err - %s\n, xyzModem_error(err));
+ hang();
+ }
+
+ xyzModem_stream_close(err);
+ xyzModem_stream_terminate(false, getcymodem);
+
+ printf(Loaded %d bytes\n, size);
+}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.
Hi, On Monday, January 30, 2012, Heiko Schocher h...@denx.de wrote: Hello Christian, Christian Riesch wrote: Hi all, On Fri, Jan 27, 2012 at 7:33 PM, Tom Rini tom.r...@gmail.com wrote: So, what do we want to do here? We really want to get this fix in so we can get the hawkboard SPL changes in, and the other platforms / fixups that are gated by that. If I can sum it up, in the relevant section of code we have incorrect comments and the init code is not following what the manual says the correct sequence is. However, given the (potentially wide) impact the changes would have, Albert had previously requested making the change opt-in (but I believe this request came before the the manual says we must do ...). If this is still the case? If so, can we get an updated patch? Thanks! A few thoughts: 1) Before commit ca4b55800ed74207c35271bf7335a092d4955416 the low level initialization code that we are discussing here was only executed if CONFIG_SKIP_LOWLEVEL_INIT is not defined. For ARM926EJS the relevant section in start.S looked like this #ifndef CONFIG_SKIP_LOWLEVEL_INIT flush caches turn off dcache, do some other configurations of the CPU, enable icache call the SoC specific lowlevel_init #endif For DA850 SoCs we had no lowlevel_init routine and therefore CONFIG_SKIP_LOWLEVEL_INIT defined in all board configurations. The lowlevel initialization was done by TI's UBL boot loader. Now we have boards that don't use UBL (e.g. enbw_cmc, calimain, da850evm when used with the SPL), therefore we need some lowlevel init. Most important configuration is enabling icache, otherwise u-boot startup gets really slow. Since commit ca4b55800ed74207c35271bf7335a092d4955416 it is flush caches turn off dcache, do some other configurations of the CPU, enable icache #ifndef CONFIG_SKIP_LOWLEVEL_INIT call the SoC specific lowlevel_init #endif So the change that has a big impact is already done and in mainline. Yep. Perhaps we should revert that change and instead remove CONFIG_SKIP_LOWLEVEL_INIT from the da850 board config files. But since we don't need the lowlevel_init function for DA850 SoCs we must either add a dummy function or add some additional defines that allow removing the CONFIG_SKIP_LOWLEVEL_INIT define without calling lowlevel_init. Any suggestions how such defines should be called or how the logic behind them should be so it doesn't cause breakage of existing boards? or we should introduce a CONFIG_SKIP_CPU_CRIT_INIT define, which if defined, prevent the jump to cpu_init_crit ... so we have the same behaviour as before commit ca4b55800ed74207c35271bf7335a092d4955416 Boards which have problems with cpu_crit_init, should define this new define ... but it would be better to find out, what is really going on here ... Yes, that would be good of course. Another idea: Actually the init code that we are discussing here is executed twice. First in the SPL and then in the full-blown u-boot. Sughosh, are you sure it is the execution of the code in SPL that causes the trouble? I'm asking since we don't do any memory barrier related stuff in the code that loads u-boot from flash in SPL. Of course, dcache is off but icache is on. Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.
Hello Heiko, On Mon, Jan 30, 2012 at 7:39 AM, Heiko Schocher h...@denx.de wrote: Christian Riesch wrote: 2) The current version of Sughosh's patch does not change the logic behind the LOWLEVEL_INIT defines but just fixes the code to agree with ARM's manual. Instead of invalidating the cache it now is flushed. I think we should therefore merge his patch (@Tom: Yes, the manual says we must do.). The big change that Albert fears was already done earlier in commit ca4b55800ed74207c35271bf7335a092d4955416. And while we are doing this we also get the comments right. What do you mean with commit ca4b55800ed74207c35271bf7335a092d4955416? I could not find it in mainline ... commit ca4b55800ed74207c35271bf7335a092d4955416 Author: Heiko Schocher h...@denx.de Date: Wed Nov 9 20:06:23 2011 + arm, arm926ejs: always do cpu critical inits Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.
Hi all, On Fri, Jan 27, 2012 at 7:33 PM, Tom Rini tom.r...@gmail.com wrote: So, what do we want to do here? We really want to get this fix in so we can get the hawkboard SPL changes in, and the other platforms / fixups that are gated by that. If I can sum it up, in the relevant section of code we have incorrect comments and the init code is not following what the manual says the correct sequence is. However, given the (potentially wide) impact the changes would have, Albert had previously requested making the change opt-in (but I believe this request came before the the manual says we must do ...). If this is still the case? If so, can we get an updated patch? Thanks! A few thoughts: 1) Before commit ca4b55800ed74207c35271bf7335a092d4955416 the low level initialization code that we are discussing here was only executed if CONFIG_SKIP_LOWLEVEL_INIT is not defined. For ARM926EJS the relevant section in start.S looked like this #ifndef CONFIG_SKIP_LOWLEVEL_INIT flush caches turn off dcache, do some other configurations of the CPU, enable icache call the SoC specific lowlevel_init #endif For DA850 SoCs we had no lowlevel_init routine and therefore CONFIG_SKIP_LOWLEVEL_INIT defined in all board configurations. The lowlevel initialization was done by TI's UBL boot loader. Now we have boards that don't use UBL (e.g. enbw_cmc, calimain, da850evm when used with the SPL), therefore we need some lowlevel init. Most important configuration is enabling icache, otherwise u-boot startup gets really slow. Since commit ca4b55800ed74207c35271bf7335a092d4955416 it is flush caches turn off dcache, do some other configurations of the CPU, enable icache #ifndef CONFIG_SKIP_LOWLEVEL_INIT call the SoC specific lowlevel_init #endif So the change that has a big impact is already done and in mainline. Perhaps we should revert that change and instead remove CONFIG_SKIP_LOWLEVEL_INIT from the da850 board config files. But since we don't need the lowlevel_init function for DA850 SoCs we must either add a dummy function or add some additional defines that allow removing the CONFIG_SKIP_LOWLEVEL_INIT define without calling lowlevel_init. Any suggestions how such defines should be called or how the logic behind them should be so it doesn't cause breakage of existing boards? What do you think? Or is reverting to dangerous since we would change the behavior of start.S twice if we do so? 2) The current version of Sughosh's patch does not change the logic behind the LOWLEVEL_INIT defines but just fixes the code to agree with ARM's manual. Instead of invalidating the cache it now is flushed. I think we should therefore merge his patch (@Tom: Yes, the manual says we must do.). The big change that Albert fears was already done earlier in commit ca4b55800ed74207c35271bf7335a092d4955416. And while we are doing this we also get the comments right. 3) As Sughosh pointed out, the current code changes the V bit (location of exceptions). Sughosh's patch removes this code that does this change. I'm not sure if this is correct or not, so maybe you, Tom, could put your TI hat on again and clarify this? 4) The current code turns on icache. This is great since my board executes u-boot directly from flash until it relocates itself and thus the startup time is greatly reduced by using icache. However, there is this CONFIG_SYS_ICACHE_OFF define. Should the code be changed to respect this define? Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot-Users]-compilation error
Hi, On Fri, Jan 27, 2012 at 7:32 AM, periyasamy samy eceperiyas...@gmail.com wrote: hi.. i am new to u-boot and for my practice i compiled arm720t impa7 source code using abacus-anurag-linux compiler. i am getting the following I'm not familiar with abacus-anurag, but isn't that a different architecture? This is not ARM, right? So you try to build an ARM configuration with a non-ARM toolchain, right? This won't work. errors.. could you help me to clear the errors. root@user-Invalid-entry-length-0-DMI-table-is-broken-Stop:/home/user/u-boot-1.1.6# I like your hostname :-D Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: Davinci uboot
Hi Manju, On Fri, Jan 27, 2012 at 12:34 PM, Hadli, Manjunath manjunath.ha...@ti.com wrote: Hi Tom, These patches have been posted earlier and have gone necessary reviews and I feel they are ready to be pulled. Please pull these pathes. I think the last time you posted these patches was in September, right? Since then, a number of patches have been applied that do changes in arch/arm/cpu/arm926ejs/davinci and two boards have been added (Added Heiko Schocher to CC). Also, include/configs/da850_am18xxevm.h was removed. Support for the new SPL framework was introduced for davinci boards and I see that you had to change your patches due to these changes. I think you should therefore re-submit the entire series for review. Regards, Christian Thanks and Regards, -Manju The following changes since commit 3325ee67f2194d821f0755b94dc57adb1d579d7b: Yegor Yefremov (1): am3517evm: remove rootfstype kernel parameter for MMC boot device are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git ubootos Manjunath Hadli (5): da850evm: add support to read mac address from spi flash da850evm: read MAC address from I2C EEPROM on AM18x EVM davinci : move clock related functions to new file davinci: remove macro CONFIG_DISPLAY_CPUINFO davinci: add clocks command arch/arm/cpu/arm926ejs/davinci/Makefile | 2 +- arch/arm/cpu/arm926ejs/davinci/cpu.c | 208 arch/arm/cpu/arm926ejs/davinci/speed.c | 230 +++ board/davinci/da8xxevm/da850evm.c | 68 + boards.cfg | 4 +- include/configs/cam_enc_4xx.h | 1 - include/configs/davinci_dm355evm.h | 1 - include/configs/davinci_dm355leopard.h | 1 - include/configs/davinci_dm6467Tevm.h | 1 - include/configs/davinci_dm6467evm.h | 1 - include/configs/davinci_dvevm.h | 1 - include/configs/davinci_schmoogie.h | 1 - include/configs/davinci_sffsdr.h | 1 - include/configs/davinci_sonata.h | 1 - include/configs/enbw_cmc.h | 1 - 15 files changed, 301 insertions(+), 221 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/davinci/speed.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL Framework: Add support for U_BOOT_CMD
Hi, On Wed, Jan 25, 2012 at 10:52 AM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: *I want to add a command using U_BOOT_CMD in uboot, where SPL_BUILD is enabled for example for da850evm in spl frame work how can i do that * Why do you want to do that? A command in an SPL? *When I tried to that I get following error, error: no memory region specified for loadable section* *When i add printf statements and build I get errors for hawkboard_nand board puts works fine. Is printf being removed as of buffer overriding *issues or *is there a support yet* to be added for printf? Could you please post an example of what you are trying to do? Are you using Sughosh Ganu's Hawkboard SPL patches or not? Without those patches hawkboard does not use the new SPL framework. [U-Boot,1/2,V4] arm926: Flush the data cache before disabling it http://patchwork.ozlabs.org/patch/136079/ [U-Boot,2/2,V4] Changes to move hawkboard to the new spl infrastructure http://patchwork.ozlabs.org/patch/135433/ Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
