Re: [U-Boot] [PATCH v2 4/9] arm: add _thumb1_case_uqi to libgcc
On Mon, Aug 13, 2012 at 5:36 PM, Allen Martin amar...@nvidia.com wrote: On Mon, Aug 13, 2012 at 04:44:05PM -0700, Stephen Warren wrote: On 08/01/2012 02:32 PM, Allen Martin wrote: Add function required by some thumb switch statements diff --git a/arch/arm/lib/_thumb1_case_uqi.S b/arch/arm/lib/_thumb1_case_uqi.S + .force_thumb I believe that line should be removed. The issue here is that when gcc emits Thumb code to call this function, it actually emits: 108af8: f000 f94a bl 108d90 gnu_thumb1_case_uqi_from_thumb which is implemented as: 00108d90 gnu_thumb1_case_uqi_from_thumb: 108d90: 4778bx pc 108d92: 46c0nop ; (mov r8, r8) 108d94: eafffde1b 108520 __gnu_thumb1_case_uqi i.e. it switches to ARM mode then jumps to that function. Hence, __gnu_thumb1_case_uqi must be compiled as ARM, not as Thumb. The function is supposed to be thumb code, it's basically a thumb optimization of a switch statement, and in the ARM case the compiler just emits the code directly instead of calling into libgcc. So it doesn't really make sense for the function to be anything but thumb. I think the real problem is the linker incorrectly thought the code was ARM so it generated a thumb to ARM interworking veneer. Can you try adding a .type __gnu_thumb1_case_uqi STT_FUNC instead? I've seen cases where the assembler generates the wrong type of symbol without some explicit guidance which messes up the linker's interworking generator. This might be one of those. Yes, not having STT_FUNC or %function is troublesome. I have faced this before. Maybe you should wrap the assembly functions with standard ENTRY, END_PROC macros from linkage.h. This will take care of STT_FUNC best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/9] arm: use thumb interworking returns in libgcc
Hi Allen, On Wed, Aug 1, 2012 at 1:32 PM, Allen Martin amar...@nvidia.com wrote: If CONFIG_SYS_THUMB_BUILD is enabled, use thumb interworking return instructions from libgcc routines, otherwise use ARM returns. Signed-off-by: Allen Martin amar...@nvidia.com --- arch/arm/include/asm/assembler.h | 10 ++ arch/arm/lib/_ashldi3.S |3 ++- arch/arm/lib/_ashrdi3.S |3 ++- arch/arm/lib/_divsi3.S | 15 +++ arch/arm/lib/_lshrdi3.S |3 ++- arch/arm/lib/_modsi3.S |9 - arch/arm/lib/_udivsi3.S |8 +--- arch/arm/lib/_umodsi3.S | 18 +- arch/arm/lib/memcpy.S| 10 ++ arch/arm/lib/memset.S|3 ++- 10 files changed, 69 insertions(+), 13 deletions(-) diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 5e4789b..25ece01 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -13,6 +13,7 @@ * Do not include any C declarations in this file - it is included by * assembler source. */ +#include config.h /* * Endian independent macros for shifting bytes within registers. @@ -58,3 +59,12 @@ * Cache alligned */ #define CALGN(code...) code + +/* + * return instruction + */ +#ifdef CONFIG_SYS_THUMB_BUILD +#define RETbx lr +#else +#define RETmov pc, lr Why not bx lr in all cases? In that case you can just replace all the instances of mov pc, lr directly by bx lr instead of this macro. That looks cleaner to me. BTW, as far as I remember when I did this originally my compiler was compiling all assembly functions in ARM and it was automatically converting mov pc, lr to bx lr ,where necessary. Maybe that was just my compiler and I don't remember the details now. Did you really face any issue with mov pc, lr making wrong jumps? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/9] arm: use thumb interworking returns in libgcc
Hi Allen, On Wed, Aug 1, 2012 at 2:55 PM, Allen Martin amar...@nvidia.com wrote: On Wed, Aug 01, 2012 at 02:11:48PM -0700, V, Aneesh wrote: Hi Allen, On Wed, Aug 1, 2012 at 1:32 PM, Allen Martin amar...@nvidia.commailto: amar...@nvidia.com wrote: If CONFIG_SYS_THUMB_BUILD is enabled, use thumb interworking return instructions from libgcc routines, otherwise use ARM returns. Signed-off-by: Allen Martin amar...@nvidia.commailto: amar...@nvidia.com --- arch/arm/include/asm/assembler.h | 10 ++ arch/arm/lib/_ashldi3.S |3 ++- arch/arm/lib/_ashrdi3.S |3 ++- arch/arm/lib/_divsi3.S | 15 +++ arch/arm/lib/_lshrdi3.S |3 ++- arch/arm/lib/_modsi3.S |9 - arch/arm/lib/_udivsi3.S |8 +--- arch/arm/lib/_umodsi3.S | 18 +- arch/arm/lib/memcpy.S| 10 ++ arch/arm/lib/memset.S|3 ++- 10 files changed, 69 insertions(+), 13 deletions(-) diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 5e4789b..25ece01 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -13,6 +13,7 @@ * Do not include any C declarations in this file - it is included by * assembler source. */ +#include config.h /* * Endian independent macros for shifting bytes within registers. @@ -58,3 +59,12 @@ * Cache alligned */ #define CALGN(code...) code + +/* + * return instruction + */ +#ifdef CONFIG_SYS_THUMB_BUILD +#define RETbx lr +#else +#define RETmov pc, lr Why not bx lr in all cases? In that case you can just replace all the instances of mov pc, lr directly by bx lr instead of this macro. That looks cleaner to me. I didn't want to break any older ARM architectures that don't support the bx instruction but use this code. Which is earlier than armv4t, right? On quick look it didn't seem there is anything older than that in u-boot. But yes, it's perhaps better to be safe. BTW, as far as I remember when I did this originally my compiler was compiling all assembly functions in ARM and it was automatically converting mov pc, lr to bx lr ,where necessary. Maybe that was just my compiler and I don't remember the details now. Did you really face any issue with mov pc, lr making wrong jumps? Yes, without this change if I disassemble the code I'm seeing it's still a mov instruction and it hangs. Ok. br, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: enable unaligned access on ARMv7
Hi Albert, On Sat, Jun 23, 2012 at 2:01 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Aneesh, On Fri, 22 Jun 2012 15:13:39 -0700, Aneesh V ane...@ti.com wrote: On 06/22/2012 03:11 PM, Aneesh V wrote: +Tom Hi Lucas, On 06/22/2012 04:47 AM, Lucas Stach wrote: Hi Albert, Am Freitag, den 22.06.2012, 13:16 +0200 schrieb Albert ARIBAUD: I am not too happy with enabling a lax behavior only to avoid an issue which apparently is diagnosed and could / should be fixed at its root. Can you point me to the relevant LKML thread so that I get the details and understand what prevents fixing this by 'simply' aligning the USB structures? I'm with you that the issue for this particular fault that I ran into should be fixed at it's root and I will do so as soon as I have enough time to do so, i.e. within the next three weeks. You can find a thread about this here: https://lkml.org/lkml/2011/4/27/278 From what I understand, the issue was not to allow unaligned access at the hardware level, but to modify the attributes of the structure, first by removing the packed attribute, then by reinstating the packed attribute along with align(4). But apart from this, we certainly have situations where we have unaligned accesses that are justified and could not be removed. [...] I cannot see how enabling a hardware feature can be seen as allowing of lax behaviour. As some of the USB structs are used to access hardware registers, we can not align every struct there. If the access is in true RAM, then we can always realign the data; and I don't know of memory-mapped registers which would be unaligned wrt their width. If some USB controller is designed so, then the fix should only and explicitly affect that controller, because we don't know it it will always be used with an ARM implementation that can do unaligned accesses. I think this issue was discussed before here(I haven't gone through all the details of your problem, but it looks similar). And I think Tom fixed this by wrapping the problematic accesses with get/set_unaligned(). Could be a solution if the structures themselves cannot be fixed. Please look at this thread, especially starting from my post reporting the OMAP4 regression: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/113347/ Thanks for the reference. There seems to have been no confirmation that the structures involved needed packing in the first place, and my general opinion on packing structures is DO NOT -- if packing a structure has an effect, it can alway be to de-align some field, which barely makes sense as far as HW prgramming is concerned (I can only see some point in packing a struct when you deal with network layer 7 data in very special cases). BTW, I agree that enabling un-aligned access is not a bad idea. Just being not a bad idea is not enough for me to accept this. It will have to be the sole sound solution to a problem, and at this point, I do not think it is as far as USB structure mis-alignement issues are concerned. My point is that enabling un-aligned accesses in itsown merit is not a bad idea, not as a solution to this problem. I have seen it being enabled in HLOS environment. TI's Symbian port for instance had it enabled for OMAP3. I don't know why Linux too shoudln't take advantage of such hw features. Perhaps you don't want to take it at this point of time to force the real solution to the USB problem, which is reasonable. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP: Add function to get state of a GPIO output
Hi Sandeep, Joel,
On Sun, Sep 4, 2011 at 11:10 PM, s-paul...@ti.com wrote:
From: Joel A Fernandes agnel.j...@gmail.com
Read directly from OMAP_GPIO_DATAOUT to get the output state of the GPIO pin
Signed-off-by: Joel A Fernandes agnel.j...@gmail.com
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
---
arch/arm/cpu/armv7/omap-common/gpio.c | 20
arch/arm/include/asm/omap_gpio.h | 2 ++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/gpio.c
b/arch/arm/cpu/armv7/omap-common/gpio.c
index 2fcaf5a..4749524 100644
--- a/arch/arm/cpu/armv7/omap-common/gpio.c
+++ b/arch/arm/cpu/armv7/omap-common/gpio.c
@@ -151,6 +151,26 @@ int omap_get_gpio_datain(int gpio)
(1 get_gpio_index(gpio))) != 0;
}
+int omap_get_gpio_dataout(int gpio)
This patch added a build warning like this:
gpio.c: In function 'omap_get_gpio_dataout':
gpio.c:161: warning: assignment discards qualifiers from pointer target type
The fix is this:
diff --git a/arch/arm/cpu/armv7/omap-common/gpio.c
b/arch/arm/cpu/armv7/omap-common/gpio.c
index 4749524..c4126fe 100644
--- a/arch/arm/cpu/armv7/omap-common/gpio.c
+++ b/arch/arm/cpu/armv7/omap-common/gpio.c
@@ -153,7 +153,7 @@ int omap_get_gpio_datain(int gpio)
int omap_get_gpio_dataout(int gpio)
{
- struct gpio_bank *bank;
+ const struct gpio_bank *bank;
void *reg;
if (check_gpio(gpio) 0)
+{
+ struct gpio_bank *bank;
+ void *reg;
+
+ if (check_gpio(gpio) 0)
+ return -EINVAL;
+ bank = get_gpio_bank(gpio);
+ reg = bank-base;
+ switch (bank-method) {
+ case METHOD_GPIO_24XX:
+ reg += OMAP_GPIO_DATAOUT;
+ break;
+ default:
+ return -EINVAL;
+ }
+ return (__raw_readl(reg)
+ (1 get_gpio_index(gpio))) != 0;
+}
+
static void _reset_gpio(const struct gpio_bank *bank, int gpio)
{
_set_gpio_direction(bank, get_gpio_index(gpio), 1);
diff --git a/arch/arm/include/asm/omap_gpio.h
b/arch/arm/include/asm/omap_gpio.h
index 3089e1c..8741572 100644
--- a/arch/arm/include/asm/omap_gpio.h
+++ b/arch/arm/include/asm/omap_gpio.h
@@ -61,5 +61,7 @@ void omap_set_gpio_direction(int gpio, int is_input);
void omap_set_gpio_dataout(int gpio, int enable);
/* Get the value of a gpio input */
int omap_get_gpio_datain(int gpio);
+/* Get the value of a gpio output */
+int omap_get_gpio_dataout(int gpio);
#endif /* _GPIO_H_ */
--
1.6.0.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] [STATUS] ARM
Hi Albert, On Sun, Aug 21, 2011 at 12:52 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Dirk, Le 21/08/2011 09:11, Dirk Behme a écrit : But, hmm, http://git.denx.de/?p=u-boot/u-boot-arm.git;a=summary doesn't show the applied patches yet? Did I miss something? You did not; I did -- forgot to push master. Fixed now, thanks for pointing this out. How about this series: http://patchwork.ozlabs.org/bundle/aneeshv/armv7-cache-fixes/ If you pull this, I would prefer that you take all the patches so that there is no regression for OMAP. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] ARM
Hi Albert, On Sat, Aug 20, 2011 at 9:02 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi all, Le 20/08/2011 13:12, Albert ARIBAUD a écrit : 1. http://patchwork.ozlabs.org/patch/107678/ This one lowers bad board builds from 69 to 62, and has been applied. 2. http://patchwork.ozlabs.org/patch/108865/ This one kind of half-fixes the two boards it touches: they now build but with warnings, all the same, of which here is one: clocks.c:274: warning: comparison is always true due to limited range of data type My tool-chain (Sourcery G++ Lite 2010q1 - GCC 4.4.1) never reported this issue. But looks like there is indeed a problem. Hopefully the following patch should solve it: http://patchwork.ozlabs.org/patch/110811/ best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] ARM
Hi Dirk, On Sun, Aug 21, 2011 at 1:16 PM, Dirk Behme dirk.be...@googlemail.com wrote: On 20.08.2011 17:32, Albert ARIBAUD wrote: Hi all, Le 20/08/2011 13:12, Albert ARIBAUD a écrit : ... 2. http://patchwork.ozlabs.org/patch/108865/ This one kind of half-fixes the two boards it touches: they now build but with warnings, all the same, of which here is one: clocks.c:274: warning: comparison is always true due to limited range of data type I'll put this one on hold unless somebody can tell me what's going on. First, the patch 108865 above fixes a linking issue with the SPL for these boards. So I think that this is independent of the clocks.c warning you report above. That would mean it would be worth to apply 108865 to fix at least the linking issue. Second, applying 108865 to the recent u-boot-arm.git doesn't show any clocks.c warning for me [1]. Could this be tool chain dependent? I tried it with [2] and [3], without any warning. Btw, about which clocks.c (directory) do we talk? I too didn't get this warning. But I see a problem with omap4/clocks.c. I have submitted a patch just now. http://patchwork.ozlabs.org/patch/110811/ BTW, thanks for looking into this. br, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] ARM
Hi Albert, On Sun, Aug 21, 2011 at 1:44 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Aneesh, Le 21/08/2011 09:51, V, Aneesh a écrit : Hi Albert, On Sat, Aug 20, 2011 at 9:02 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi all, Le 20/08/2011 13:12, Albert ARIBAUD a écrit : 1. http://patchwork.ozlabs.org/patch/107678/ This one lowers bad board builds from 69 to 62, and has been applied. 2. http://patchwork.ozlabs.org/patch/108865/ This one kind of half-fixes the two boards it touches: they now build but with warnings, all the same, of which here is one: clocks.c:274: warning: comparison is always true due to limited range of data type My tool-chain (Sourcery G++ Lite 2010q1 - GCC 4.4.1) never reported this issue. But looks like there is indeed a problem. Hopefully the following patch should solve it: http://patchwork.ozlabs.org/patch/110811/ This indeed fixes it. Strange that the warning is not emitted by your toolchain. Yes, that's indeed strange. Even with your tool-chain it should've emitted more warnings. Many of those unsigned variables were assigned -1 in elsewhere. That was also never reported. br, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] ARM: ARM926EJS - Add cache operations
Hi Eric,
On Mon, Aug 22, 2011 at 7:44 AM, Hong Xu hong...@atmel.com wrote:
Hi Aneesh,
On 08/19/2011 10:20 PM, Aneesh V wrote:
Hi Hong,
On Friday 19 August 2011 02:53 PM, Hong Xu wrote:
Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache operations
into this file.
Signed-off-by: Hong Xuhong...@atmel.com
Tested-by: Elen Songelen.s...@atmel.com
CC: Albert Aribaudalbert.u.b...@aribaud.net
---
Since V1
Modified copyright line
Fix for compiling warnings
Changed the way to use CONFIG_SYS_CACHELINE_SIZE
When unaligned buffer detected, emit ERROR instead of WARNING
Do not make a common v5,v6 cache file. It seems arm946 is lack of
Test-and-Clean DCache operation. And maybe more differents...
arch/arm/cpu/arm926ejs/Makefile | 2 +-
arch/arm/cpu/arm926ejs/cache.c | 135
+++
2 files changed, 136 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/cache.c
[...]
+
+/*
+ * The buffer range to be flushed is [start, stop)
+ */
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+ cache_range_op(start, stop, FLUSH_CACHE_OP);
+}
+
+void flush_dcache_all(void)
+{
+ /*
+ * ARM926EJ-S Technical Reference Manual, Chap 2.3.8
+ * Clean Invalidate the entire DCache
+ */
+ asm(0: mrc p15, 0, r15, c7, c14, 3\n\t bne 0b\n : : :
memory);
+ /* Drain WB */
+ asm(mcr p15, 0, %0, c7, c10, 4\n : : r (0));
While looking at the manuals for the armv5 compatibility I stumbled
upon the following in Chapter 2.3.8. Are you sure your flush_dcache_all
implementation is correct? I suspect the above is flushing only one
line?
The test, clean, and invalidate DCache instruction is the same as test
and clean DCache,
except that when the entire cache has been cleaned, it is invalidated.
This means that
you can use the following loop to clean and invalidate the entire
DCache:
tci_loop: MRC p15, 0, r15, c7, c14, 3
BNE tci_loop
As stated in the manual, we can use a loop to clean and invalidate the
entire DCache.
The asm statement above is a loop, isn't it? ;-)
Oops! I didn't notice that. Sorry for the noise. But, maybe, it could be made
two separate lines to make it more readable.
br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] u-boot-arm/master branch complete wrt merge window?
Hi Albert, On Fri, Aug 12, 2011 at 11:39 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Aneesh, Le 12/08/2011 16:06, Aneesh V a écrit : Hi Albert, On Friday 12 August 2011 06:53 PM, Albert ARIBAUD wrote: Hi all, I *think* I've finished getting in all patches that should have gone in from the merge window, and also bugfixes. However, I seem to remember a mail asking me to consider some patches I'd missed, but I could not find this mail in any of my folders to save my life. :( Maybe, that was me. I had sent you a mail yesterday requesting to pull the following: 1. http://marc.info/?l=u-bootm=131307370323792w=2 Formally, of these four patches initially submitted on aug 1st, after the merge window close, arm: do not force d-cache enable on all boards omap: enable caches at system start-up armv7: stronger barrier for cache-maintenance operations armv7: cache: remove flush on un-aligned invalidate ... the second is not a fix and shall be applied on next, then moved to master after the september release. That'll end up in a regression for OMAP. Caches were enabled in OMAP without any issues. This series was done to save trouble for other boards. In the process OMAP will end up losing the cache support temporarily unless patch 2/4 is taken. 2. http://patchwork.ozlabs.org/patch/107678/ 3. http://patchwork.ozlabs.org/patch/108865/ Those are fixes, so they'll go in. In addition, I have this series for consideration: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/105329 But this one was submitted after the merge window closed and is not that critical. Is omap4: make SDRAM init work for ES1.0 silicon to be considered a fix, and can it be applied alone? If yes to both questions, then I might take it in for master. The rest would go to next. Yes, that's a bug fix and can be applied alone. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] u-boot-arm/master branch complete wrt merge window?
Hi Sandeep, On Sat, Aug 13, 2011 at 3:34 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Le 12/08/2011 20:09, Albert ARIBAUD a écrit : Hi Aneesh, Le 12/08/2011 16:06, Aneesh V a écrit : Hi Albert, On Friday 12 August 2011 06:53 PM, Albert ARIBAUD wrote: Hi all, I *think* I've finished getting in all patches that should have gone in from the merge window, and also bugfixes. However, I seem to remember a mail asking me to consider some patches I'd missed, but I could not find this mail in any of my folders to save my life. :( Maybe, that was me. I had sent you a mail yesterday requesting to pull the following: 1. http://marc.info/?l=u-bootm=131307370323792w=2 Formally, of these four patches initially submitted on aug 1st, after the merge window close, arm: do not force d-cache enable on all boards omap: enable caches at system start-up armv7: stronger barrier for cache-maintenance operations armv7: cache: remove flush on un-aligned invalidate ... the second is not a fix and shall be applied on next, then moved to master after the september release. 2. http://patchwork.ozlabs.org/patch/107678/ 3. http://patchwork.ozlabs.org/patch/108865/ Those are fixes, so they'll go in. ... but OMAP, so maybe through Sandeep's tree? Hope you are considering the above for pull + the SDRAM fix in: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/105329 omap4: make SDRAM init work for ES1.0 silicon best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] arm: do not force d-cache enable on all boards
Hi Simon,
On Sun, Aug 14, 2011 at 4:39 PM, Simon Guinot si...@sequanux.org wrote:
Hi Aneesh,
On Thu, Aug 11, 2011 at 08:05:42PM +0530, Aneesh V wrote:
c2dd0d45540397704de9b13287417d21049d34c6 added dcache_enable()
to board_init_r(). This enables d-cache for all ARM boards.
As a result some of the arm boards that are not cache-ready
are broken. Revert this change and allow platform code to
take the decision on d-cache enabling.
Also add some documentation for cache usage in ARM.
Signed-off-by: Aneesh V ane...@ti.com
---
V2:
Updated with additional guidelines in the README.
---
arch/arm/lib/board.c | 8 ++
arch/arm/lib/cache.c | 12 +++
doc/README.arm-caches | 51
+
include/common.h | 1 +
4 files changed, 67 insertions(+), 5 deletions(-)
create mode 100644 doc/README.arm-caches
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 14a56f6..38a31d8 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -451,11 +451,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
gd-flags |= GD_FLG_RELOC; /* tell others: relocation done */
monitor_flash_len = _end_ofs;
- /*
- * Enable D$:
- * I$, if needed, must be already enabled in start.S
- */
- dcache_enable();
+
+ /* Enable caches */
+ enable_caches();
debug(monitor flash len: %08lX\n, monitor_flash_len);
board_init(); /* Setup chipselects */
diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c
index 92b61a2..b545fb7 100644
--- a/arch/arm/lib/cache.c
+++ b/arch/arm/lib/cache.c
@@ -53,3 +53,15 @@ void __flush_dcache_all(void)
}
void flush_dcache_all(void)
__attribute__((weak, alias(__flush_dcache_all)));
+
+
+/*
+ * Default implementation of enable_caches()
+ * Real implementation should be in platform code
+ */
+void __enable_caches(void)
+{
+ puts(WARNING: Caches not enabled\n);
+}
+void enable_caches(void)
+ __attribute__((weak, alias(__enable_caches)));
diff --git a/doc/README.arm-caches b/doc/README.arm-caches
new file mode 100644
index 000..a833eee
--- /dev/null
+++ b/doc/README.arm-caches
@@ -0,0 +1,51 @@
+Disabling I-cache:
+- Set CONFIG_SYS_ICACHE_OFF
+
+Disabling D-cache:
+- Set CONFIG_SYS_DCACHE_OFF
+
+Enabling I-cache:
+- Make sure CONFIG_SYS_ICACHE_OFF is not set and call icache_enable().
+
+Enabling D-cache:
+- Make sure CONFIG_SYS_ICACHE_OFF is not set and call dcache_enable().
^
Maybe you will prefer to check for CONFIG_SYS_DCACHE_OFF ?
Yes. That's a typo. Will fix it. Thank you for pointing it out.
best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/4] arm: changes in cache handling
Hi Albert, On Sat, Aug 13, 2011 at 3:39 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Le 11/08/2011 16:35, Aneesh V a écrit : - Avoid enabling caches for all ARM boards - Enable caches for omap3/4 - Stronger barrier for armv7 cache-maintenance operations. V2: * Rebased to latest HEAD of u-boot/master * Improved the README * Added a patch for removing the flush in invalidate and for printing a warning in such cases. V3: * Improve the error message on un-aligned invalidate Aneesh V (4): arm: do not force d-cache enable on all boards omap: enable caches at system start-up armv7: stronger barrier for cache-maintenance operations armv7: cache: remove flush on un-aligned invalidate arch/arm/cpu/armv7/cache_v7.c | 26 ++- arch/arm/cpu/armv7/omap3/board.c | 8 ++ arch/arm/cpu/armv7/omap4/board.c | 8 ++ arch/arm/lib/board.c | 8 ++--- arch/arm/lib/cache-pl310.c | 15 ++ arch/arm/lib/cache.c | 12 + doc/README.arm-caches | 51 ++ include/common.h | 1 + 8 files changed, 106 insertions(+), 23 deletions(-) create mode 100644 doc/README.arm-caches Please in the future leave history in individual patches (but you can keep int in cover letters as well). That is a burden, but it provides for better tracking on patchwork, where cover letters are not recorded, and individual patches are the only place where history can appear. I add history in both cover letter and in individual patches. However, I change the history of a patch only if there's some update in that revision. That is, I do not add something like: Changes in V2: None Is that fine? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] preloader_console_init()
Hi Simon, On Mon, Jul 25, 2011 at 8:36 PM, Simon Schwarz simonschwarz...@googlemail.com wrote: Hi Aneesh, I'am nearly done with OMAP3 - I think I can release the patch today. I have just one problem left: You implemented preloader_console_init() in omap-common to call setup_clocks_for_console(). This is a OMAP4 specific call - OMAP3 only has per_clocks_init() - which inits a bunch of clocks. Sorry. I was on a short travel and didn't have mail access for a couple of days. The idea was to enable the console at the earliest, even before prcm_init(). If OMAP3 doesn't need this I would suggest moving setup_clocks_for_console() call to s_init() in omap4/board.c BTW, how did you fix this in your patches fianlly? br, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 3/5] nand spl: add NAND Library to new SPL
Hi Simon, Scott, On Wed, Jul 27, 2011 at 2:52 PM, Simon Schwarz simonschwarz...@googlemail.com wrote: Dear Scott Wood, On 07/26/2011 08:04 PM, Scott Wood wrote: On Tue, 26 Jul 2011 14:09:16 +0200 Simon Schwarzsimonschwarz...@googlemail.com wrote: diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 8b598f6..cdc9a14 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -26,12 +26,16 @@ include $(TOPDIR)/config.mk LIB := $(obj)libnand.o ifdef CONFIG_CMD_NAND +ifdef CONFIG_SPL_BUILD +COBJS-y += nand_spl.o +else COBJS-y += nand.o COBJS-y += nand_base.o COBJS-y += nand_bbt.o -COBJS-y += nand_ecc.o COBJS-y += nand_ids.o COBJS-y += nand_util.o +endif +COBJS-y += nand_ecc.o You're assuming all NAND SPLs will want nand_ecc -- this will not fit in most current ones. True. I changed it to: ifdef CONFIG_SPL_BUILD COBJS-y += nand_spl.o ifdef CONFIG_OMAP34XX -ffunction-sections, -fdata-sections and --gc-sections are enabled globally for SPL. Source files are #ifdef'ed out in Makefile's for SPL primarily to reduce build time. I would suggest to enable the super set of all files needed for all SPL's in these Makefile's and not clutter it with any more #ifdef's best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 00/12] U-Boot MMC SPL for OMAP4
Hi Sandeep, On Thu, Jul 21, 2011 at 3:01 AM, Paulraj, Sandeep s-paul...@ti.com wrote: Aneesh V (11): omap4: utility function to identify the context of hw init omap4: cleanup pin mux data omap4: add OMAP4430 revision check omap4: add clock support omap4: add sdram init support omap4: calculate EMIF register values omap4: automatic sdram detection armv7: start.S: fixes and enhancements for SPL omap: add basic SPL support Correct ih_os for u-boot.img omap: add MMC and FAT support to SPL John Rigby (1): mkimage: Add OMAP boot image support Patch #8 of this seires does not apply on the current u-boot-ti U-boot-ti now has the updated SPL framework Please rebase with u-boot-ti and send updated patch sets for both your series. I have done my re-basing. Will send out my series shortly. However, please note that u-boot-ti/master is not building for me. You will need this fix: Fix typo from 'mb_alloc' - 'lmb_alloc http://patchwork.ozlabs.org/patch/105364/ best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 00/12] U-Boot MMC SPL for OMAP4
Hi Sandeep, On Thu, Jul 21, 2011 at 3:01 AM, Paulraj, Sandeep s-paul...@ti.com wrote: Aneesh V (11): omap4: utility function to identify the context of hw init omap4: cleanup pin mux data omap4: add OMAP4430 revision check omap4: add clock support omap4: add sdram init support omap4: calculate EMIF register values omap4: automatic sdram detection armv7: start.S: fixes and enhancements for SPL omap: add basic SPL support Correct ih_os for u-boot.img omap: add MMC and FAT support to SPL John Rigby (1): mkimage: Add OMAP boot image support Patch #8 of this seires does not apply on the current u-boot-ti U-boot-ti now has the updated SPL framework There was v4 for just two of the patches of the framework series: 2/9 and 5/9. I think you missed them. Can you correct this? Please rebase with u-boot-ti and send updated patch sets for both your series. Sure. I will do that. Thanks, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add assert() for debug assertions
On Thu, Jun 23, 2011 at 2:53 AM, Mike Frysinger vap...@gentoo.org wrote:
On Wednesday, June 22, 2011 17:04:49 Simon Glass wrote:
+/*
+ * An assertion is run-time check done in debug mode only. If DEBUG is not
+ * defined then it is skipped. It does not BUG or halt U-Boot, but tries
to + * continue execution in any case. It is hoped that all failing
assertions + * are found before release, and after release it is hoped
that they don't + * matter. But in any case these failing assertions
cannot be fixed with a + * BUG-type reset (which may just do the same
assertion again).
+ */
+#define assert(x) \
+ ({ if (!(x)) printf(Assertion failure '%s' %s line %d\n, \
+ #x, __FILE__, __LINE__); })
#else
#define debug(fmt,args...)
#define debugX(level,fmt,args...)
+#define assert(x)
#endif /* DEBUG */
the trouble with ifdef magic like this is that errors/warnings can be
introduced when DEBUG isnt defined, and then only noticed when DEBUG is
defined. so how about:
Symbian OS, that had an array of defensive programming features, had two
ASSERT macros:
Something like ASSERT_DEBUG(x) and ASSERT_ALWAYS(x).
ASSERT_DEBUG(x) could be used more liberally because it is compiled out in
production image and ASSERT_ALWAYS(x) could be used in more critical run-time
errors.
My rule of thumb for using these two was this:
1. ASSERT_DEBUG(x) was used for invariant checking, that's for catching errors
that could arise out of programming errors. This was used more liberally in the
code.
2. ASSERT_ALWAYS(x) was used to catch erros due to invalid run-time parameters
that one may not be able to catch during testing.
best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/9] armv7: cache maintenance operations
On Wed, Jun 22, 2011 at 11:11 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi All, Le 17/06/2011 11:30, Aneesh V a écrit : With D-cache and MMU enabled for ARM in u-boot it becomes imperative to support a minimal set of cache maintenance operations and necessary initializations before enabling MMU. This series of patches attempt to do the following for armv7: * Necessary initialization sequence before enabling MMU that includes invalidation of TLB, data caches, branch predictor array etc. * Framework for supporting SOC specific outer caches in a generic manner (using a structure of function pointers - inspired by the Linux implementation) * Generic armv7 cache maintenance operations for caches known to the CPU * Support for ARM PL310 L2 cache controller used in OMAP4 * Cleanup of the cleanup_before_linux() function * Adapting all armv7 SOCs to use the new framework and removing duplicated code Sandeep, Minkyu: is the patch series OK with you? If so I'll pull it all in ARM and issue a last pull request. Sandeep, Minkyu, Would you please let me know if you have any concerns about this series. If not, it will be good to see this going upstream this release. The necessary initializations before enabling the cache are missing today. Also, the absence of proper invalidate and flush functions will be missed by any driver that uses DMA. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Sat, Jun 18, 2011 at 3:58 AM, Scott Wood scottw...@freescale.com wrote: On Fri, 17 Jun 2011 22:18:57 +0530 Aneesh V ane...@ti.com wrote: @@ -1158,6 +1164,7 @@ clobber: clean @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name * -type l -print | xargs rm -f @[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name * -type l -print | xargs rm -f @[ ! -d $(obj)mmc_spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f + @[ ! -d $(obj)spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f That last mmc_spl should just be spl. +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += mmc/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += mmc/libonenand.o Oops!! That was a copy paste error. It was intended to be: +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += nand/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += onenand/libonenand.o Why are these in mmc? What is it you propose would be in these files? +$(LIBS-y): depend + $(MAKE) -C $(dir $(subst $(obj),,$@)) all If no libraries are selected, this will produce a rule with an empty target, which is undefined behavior. The top-level Makefile doesn't include any source files by itself. All SPL content comes from one or more of libraries. So, there will be at least one library defined, I believe(unless there is an error, of course). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Hi Wolfgang, On Tue, May 17, 2011 at 2:57 PM, Wolfgang Denk w...@denx.de wrote: Dear Aneesh V, In message 4dd23561.70...@ti.com you wrote: In fact I had searched for a macro for similar needs as my set_bit_field() is addressing in Linux Kernel too but didn't find any. ... I couldn't find any utility macros/functions for doing something like this. Please somebody correct me if I am wrong. I am not aware of such a functionality in the Linux kernel, either. A quick search did not even show any attempts to introduce such macros to Linux. It appears they don't need such a feature ? Wolfgang, what's your final take on this. Can I continue to use the utility macros given that I don't have any 'standard' alternative. For register accesses I shall move to setclrbits*() macros that you had suggested. But for bit operations I do not have any alternatives. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to use the NEON instruction at u-boot?
Hi Kyungmin Park,
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-
boun...@lists.denx.de] On Behalf Of Kyungmin Park
Sent: Thursday, November 11, 2010 11:05 AM
To: u-boot@lists.denx.de
Cc: Minkyu Kang
Subject: [U-Boot] How to use the NEON instruction at u-boot?
Hi,
Now I'm trying to use the NEON instruction at u-boot. but it's
failed
and got the data abort.
Are there any way to use the NEON instruction at u-boot?
The main purpose is to use the neon memcpy as below.
bge 1f
// copies 4 bytes, destination 32-bits aligned
vld4.8 {d0[0], d1[0], d2[0], d3[0]}, [r1]!
vst4.8 {d0[0], d1[0], d2[0], d3[0]}, [r0, :32]!
1: bcc 2f
I am not sure if there is a valid use-case for this. But if you
are keen on using Neon you will have to enable the co-processor first.
Here is a piece of code I wrote for doing this in another bootloader.
#define VMSR_FPSCR_r0 dcd 0xeee80a10
#define VMRS_r0_FPSCR dcd 0xeef80a10
__asm uint32 enable_neon(void)
{
ldr r0, =0x00F0
MCR p15,0,r0,c1,c0,2 // CP15 Coprocessor Access Control Register
ldr r0, =0x4000
VMSR_FPSCR_r0
VMRS_r0_FPSCR
bx r14
}
This is written for RVCT tool chain. So you may have to convert it
for GCC. Also, my assembler didn't allow ARMv7 instructions. So, I
used DCD. You can either use .word in gcc or use the real instructions
if your assembler understands those instructions.
Thank you,
Kyungmin Park
___
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] [RFC] arm926ejs: fix jump to RAM nand_boot
Dear Wofgang, -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Wednesday, November 03, 2010 4:58 PM To: V, Aneesh Cc: Reinhard Meyer; Albert ARIBAUD; u-boot@lists.denx.de; h...@denx.de Subject: Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot Dear V, Aneesh, In message ff55437e1f14da4baeb721a458b6701706fd313...@dbde02.ent.ti.com you wrote: If the preloader loads the u-boot to the location that it is built for everything should work fine once bss is initialized, right? There is no such thing as a location that it is built for, as the location in RAM may differ, depending on enabled features - for example, pRAM size or (shared) frame buffer size may change depending on environment variable settings. In the result, the location of U-Boot in RAM shifts. You cannot know the final address at build time. Just curious. Why don't we allocate memory for such needs below the u-boot (lower address) like we do for malloc area and stack. This way the location where u-boot is relocated will only depend on the SDRAM size and size of u-boot itself, right? Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Dear Albert, Wolfgang, -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Wednesday, November 03, 2010 5:38 PM To: V, Aneesh Cc: Wolfgang Denk; u-boot@lists.denx.de; h...@denx.de Subject: Re: [RFC] arm926ejs: fix jump to RAM nand_boot Le 03/11/2010 13:03, V, Aneesh a écrit : Just curious. Why don't we allocate memory for such needs below the u-boot (lower address) like we do for malloc area and stack. This way the location where u-boot is relocated will only depend on the SDRAM size and size of u-boot itself, right? My guess is that the same memory will be allocated by the OS after u-boot, and allocating at the same location in both occasions allows for things like flicker-free boot splashes and such. And if you allocate this below u-boot, you end up with a split memory map with some allocated space in the middle of useable OS or user space. So we allocate that at top of RAM, and later on, Linux can use all the memory below as a single contiguous area. I get it now. But in any case, there are many boards that do not use these features like ours. Skipping relocation, if the support is provided may be useful for such boards. Anyway, as I said earlier, we will come back with data on how much time can be saved by skipping relocation. Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Dear Wolfgang, -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Wednesday, November 03, 2010 6:30 PM To: V, Aneesh Cc: Reinhard Meyer; Albert ARIBAUD; u-boot@lists.denx.de; h...@denx.de Subject: Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot Dear V, Aneesh, In message ff55437e1f14da4baeb721a458b6701706fd313...@dbde02.ent.ti.com you wrote: Just curious. Why don't we allocate memory for such needs below the u-boot (lower address) like we do for malloc area and stack. This way the location where u-boot is relocated will only depend on the SDRAM=20 size and size of u-boot itself, right? That would mean that all the memory where U-Boot was located is lost for use in Linux, as we reserve these areas by adjusting the mem= boot argument. Allocation of such memory blocks must start at the top, ang do downwards. And U-Boot lies below that, then. Thanks. It's clear now. Also, I checked the time it takes to do relocation. On OMAP4430 with Cortex-A9 at 1GHz and LPDDR2 SDRAM at 400MHz it took a mere 16 ms to do the relocation of u-boot image that was about 146 KB. I agree with you. Skipping relocation is not worth the complexity. Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Dear Reinhard, Wolfgang, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Reinhard Meyer Sent: Tuesday, November 02, 2010 3:04 PM To: Albert ARIBAUD Cc: u-boot@lists.denx.de; h...@denx.de Subject: Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot Dear Albert ARIBAUD, Le 02/11/2010 09:57, Reinhard Meyer a écrit : Dear Heiko Schocher, But there is a possibility to prevent one copy, if TEXT_BASE = relocation address = CONFIG_SYS_NAND_U_BOOT_DST In this case nand_spl code copies u-boot from nand to CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address, no need to copy code in relocate_code(). But as codesize changes (and with it relocation address) this is not a perfect solution. Worse: it would certainly crash since the original and relocated memory areas must not overlap - they sure would with even the slightest size change. I'm not sure I get you there. If u-boot was linked for a given address and happends to be loaded at that same address, then there is no need to relocate, right? *if* the code size changes, need for relocation would arise... I would recommend that we add code to check for overlapping relocation into board.c and print a panic message if an overlap is detected. I *think* overlap would be correctly handled if we modify the copy code to copy from top to bottom, because we know that the destination is higher than the source. No, in above case the (new) destination could be lower than the loaded address (e.g. code size increased). In any case it is not worth the effort to plan for overlapping relocations. We can always load u-boot to a very low address of SDRAM and let it relocate. The only tricky case would be when the target address is right in the middle of the source relocation code, because then the last iteratons of the copy code would corrupt this code; that can be avoided by making sure the SPL loads u-boot low enough in RAM. Exactly. My original message was: please to not give people the idea that they can avoid relocation by loading u-boot at the exact address the relocation would calculate. That is bound to *really* break at the slightest change to u-boot. Shouldn't we provide a CONFIG option by which users can disable Elf relocation? On production systems you know exactly how much memory you have. Relocation may not be very useful. On the other hand faster boot is a bigger concern. Shouldn't we support this case? Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: wrong Relocation and not cleared BSS
Albert, -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Tuesday, November 02, 2010 1:11 PM To: V, Aneesh Cc: dar...@theia.denx.de; h...@denx.de; u-boot@lists.denx.de; Augulis Subject: Re: arm: wrong Relocation and not cleared BSS Le 02/11/2010 08:18, V, Aneesh a écrit : Thanks. This helps. I did the .lds change and it seems to be booting now. Good! However, I can't still explain my earlier observation because even in the absence of this fix .rel.dyn had some content and the offsets should have been different if I were to believe objdump. Do you have any clue? There were two issues: First, older linkers always emitted input relocation sections with the name .rel.dyn whereas newer linkers emitted them with names of the form .rel*. As our linker files only took .rel.dyn to form the output section, using newer linkers would produce empty .rel.dyn sections. My .rel.dyn was not empty even before taking your fix. This is what puzzled me. When I dumped the ELF headers with 'objdump -h' .rel.dyn seemed to have some content: Please see the diff of objdump's output before and after applying your patch. Please note that .rel.dyn was there even without the patch having the same size but at a different offset. So, this is what it looks like to me: Even when our rule in .lds was not correct the linker generated .rel.dyn section by default putting together the 'rel*' sections that were not covered by any rules. But since it didn't use our rule for this, the labels associated with our rule indicated zero size. @@ -9,7 +9,7 @@ Idx Name Size VMA LMA File off Algn CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .interp 0011 80e9e6d0 80e9e6d0 000266d0 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA - 3 .dynamic 0080 80ea343c 80ea343c 0002b43c 2**2 + 3 .dynamic 0080 80e9f7ec 80e9f7ec 000277ec 2**2 CONTENTS, ALLOC, LOAD, DATA 4 .dynsym 0100 80ea34c8 80ea34c8 0002b4c8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA @@ -17,12 +17,12 @@ Idx Name Size VMA LMA File off Algn CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .hash 0054 80e9e7a4 80e9e7a4 000267a4 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA - 7 .rel.dyn 3c50 80e9e7f8 80e9e7f8 000267f8 2**2 - CONTENTS, ALLOC, LOAD, READONLY, DATA - 8 .data 0ff4 80ea2448 80ea2448 0002a448 2**2 + 7 .data 0ff4 80e9e7f8 80e9e7f8 000267f8 2**2 CONTENTS, ALLOC, LOAD, DATA - 9 .got.plt 000c 80ea34bc 80ea34bc 0002b4bc 2**2 + 8 .got.plt 000c 80e9f86c 80e9f86c 0002786c 2**2 CONTENTS, ALLOC, LOAD, DATA + 9 .rel.dyn 3c50 80e9f878 80e9f878 00027878 2**2 + CONTENTS, ALLOC, LOAD, READONLY, DATA 10 .u_boot_cmd 0540 80ea35c8 80ea35c8 0002b5c8 2**2 CONTENTS, ALLOC, LOAD, DATA 11 .bss 00031210 80ea3b08 80ea3b08 0002bb08 2**3 Second, a fix to the first issue was RFCed to the list which worked on several boards but tx25 would not boot completely. The root cause of this second issue is that CONFIG_SYS_NAND_U_BOOT_SIZE in the board config file hard-codes the size of the u-boot binary that will be read from NAND and put in RAM. When/if u-boot grows in size, this constant must be adjusted, and it was not. What hit you was the first issue for sure, and this explains why _rel_dyn_start_ofs and _rel_dyn_end_ofs are identical. What *could* have hit you was the second issue *if* your board boots from NAND *and* if u-boot grew beyond your CONFIG_SYS_NAND_U_BOOT_SIZE. We did not face the second issue because we are loading the entire u-boot.bin using a separate preloader. BTW, Wolfgang, couldn't this 'constant' be generated once objcopy has produced u-boot.bin? A script could 'du' its size, round it up as required, and generate a .h with the result so that the SPL would always compile with a correct value. Best regards, Aneesh Amicalement, -- Albert. Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: wrong Relocation and not cleared BSS
Hello Heiko, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Heiko Schocher Sent: Sunday, October 31, 2010 1:18 PM To: Alexander Holler Cc: Darius Augulis; u-boot@lists.denx.de Subject: Re: [U-Boot] arm: wrong Relocation and not cleared BSS Hello Alexander Alexander Holler wrote: I've just tested an u-boot build by Wolfgang Denx with the ELDK 4.2 (using the HEAD of the current master with the same patches than I've used). Thanks for that, Wolfgang. This one works without any problems. So it seems to be proved, that it Great! (And as we thought on 27.10.2010 ...) is a problem of the current relocation code as found in start.S in conjunction with a newer version of gcc. Yep, seems so ... I am also facing similar issues with booting OMAP4430 SDP(Cortex-A9) and did some debugging. I am using GCC 4.4.1. I found some strange issues with the code generated by the compiler. Looks like the following labels created in start.S do not work as intended. Please look at the header information and assembly listing generated by objdump. *** Code: * _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 Assembly listing: * 80e8017c _board_init_r_ofs: 80e8017c: 0748.word 0x0748 80e80180 _rel_dyn_start_ofs: 80e80180: 0002358c.word 0x0002358c 80e80184 _rel_dyn_end_ofs: 80e80184: 0002358c.word 0x0002358c 80e80188 _dynsym_start_ofs: 80e80188: 0002358c.word 0x0002358c Header dump: u-boot: file format elf32-littlearm Sections: Idx Name Size VMA LMA File off Algn 0 .text 000187b4 80e8 80e8 8000 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 5fde 80e987b4 80e987b4 000207b4 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .interp 0011 80e9e792 80e9e792 00026792 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .dynamic 0080 80ea3500 80ea3500 0002b500 2**2 CONTENTS, ALLOC, LOAD, DATA 4 .dynsym 0100 80ea358c 80ea358c 0002b58c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .dynstr 00c2 80e9e7a3 80e9e7a3 000267a3 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .hash 0054 80e9e868 80e9e868 00026868 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .rel.dyn 3c50 80e9e8bc 80e9e8bc 000268bc 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .data 0ff4 80ea250c 80ea250c 0002a50c 2**2 CONTENTS, ALLOC, LOAD, DATA 9 .got.plt 000c 80ea3580 80ea3580 0002b580 2**2 CONTENTS, ALLOC, LOAD, DATA 10 .u_boot_cmd 0540 80ea368c 80ea368c 0002b68c 2**2 CONTENTS, ALLOC, LOAD, DATA 11 .bss 00031220 80ea3bd0 80ea3bd0 0002bbcc 2**3 ALLOC So, there seems to be a problem in the way 'as' assembles the labels. I see the following 'warning' in the 'as' manual: Machines with a 32-bit address space, but that do less than 32-bit addressing, require the following special treatment. If the machine of interest to you does 32-bit addressing (or doesn't require it; see Chapter 9 [Machine Dependencies], page 75), you can ignore this issue. In order to assemble compiler output into something that works, as occasionally does strange things to `.word' directives. Directives of the form `.word sym1-sym2' are often emitted by compilers as part of jump tables. Therefore, when as assembles a directive of the form `.word sym1-sym2', and the difference between sym1 and sym2 does not fit in 16 bits, as creates a secondary jump table, immediately before the next label. This secondary jump table is preceded by a short-jump to the first byte after the secondary table. This short-jump prevents the flow of control from accidentally falling into the new table. Inside the table is a long-jump to sym2. The original `.word' contains sym1 minus the address of the long-jump to sym2. If there were several occurrences of `.word sym1-sym2' before the secondary jump table, all of them are adjusted. If there was a `.word sym3-sym4', that also did not fit in sixteen bits, a long-jump to sym4 is included in the secondary jump table, and the .word directives are adjusted to contain sym3 minus the address of the long-jump to sym4; and so on, for as many entries in the original jump table as necessary. ** Looks like part of the issue is due to these labels. However, there seems to be other
Re: [U-Boot] arm: wrong Relocation and not cleared BSS
Hi Heiko, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of V, Aneesh Sent: Tuesday, November 02, 2010 11:10 AM To: h...@denx.de; Alexander Holler Cc: Darius Augulis; u-boot@lists.denx.de Subject: Re: [U-Boot] arm: wrong Relocation and not cleared BSS Assembly listing: * 80e8017c _board_init_r_ofs: 80e8017c: 0748.word 0x0748 80e80180 _rel_dyn_start_ofs: 80e80180: 0002358c.word 0x0002358c 80e80184 _rel_dyn_end_ofs: 80e80184: 0002358c.word 0x0002358c 80e80188 _dynsym_start_ofs: 80e80188: 0002358c.word 0x0002358c I don't know if this was clear in the previous mail. Please note that last three labels have same value. Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP4: Calculate SDRAM size
Dear Wolfgang Denk, -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Sunday, September 26, 2010 8:07 PM To: Nishanth Menon Cc: V, Aneesh; u-boot@lists.denx.de; Steve Sakoman Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP4: Calculate SDRAM size Dear Nishanth Menon, In message 4c9f3e4f.3040...@gmail.com you wrote: I think you are referring to SDRAM initialization. Yes, it is assumed that SDRAM initialization(at least the DMM part of it) is done before the call to sdram_size(). The right location for this seems to be the initial part of sdram_init(). thanks for the clarification.. NOR boot is usually going to have initial part in XIP - we'd traditionally relocate to SDRAM before the call to sdram_size() happens. Yes, this was the way how many ARM boards id, and this is what I'm trying to explain: this is WRONG. SDRAM configuration must be done while still running from NOR, i. e. before relocation. Only then free reconfiguration, auto-sizing etc. is possible. We shall rework the patch to do SDRAM size calculation as part of 'lowlevel_init' that is called before relocation. I hope that should solve the problem. Please note that we are always running from SDRAM because none of the OMAP4 boards so far have any XIP device. Regarding true run-time detection of SDRAM size and configuration: We do not support it today. However, LPDDR2 supports Mode Registers that have size info and our memory controller can read it. This coupled with the base AC timings specified by the LPDDR2 spec creates the possibility of doing a truly run-time detection and configuration of SDRAM that works for all boards. I was indeed thinking of trying it out sometime. Please note that the base AC timing values may not be optimal for all memory parts. Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP4: Calculate SDRAM size
Dear Wolfgang Denk, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of V, Aneesh Sent: Monday, September 27, 2010 12:03 PM To: Wolfgang Denk; Nishanth Menon Cc: u-boot@lists.denx.de; Steve Sakoman Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP4: Calculate SDRAM size Dear Wolfgang Denk, -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Sunday, September 26, 2010 8:07 PM To: Nishanth Menon Cc: V, Aneesh; u-boot@lists.denx.de; Steve Sakoman Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP4: Calculate SDRAM size Dear Nishanth Menon, In message 4c9f3e4f.3040...@gmail.com you wrote: I think you are referring to SDRAM initialization. Yes, it is assumed that SDRAM initialization(at least the DMM part of it) is done before the call to sdram_size(). The right location for this seems to be the initial part of sdram_init(). thanks for the clarification.. NOR boot is usually going to have initial part in XIP - we'd traditionally relocate to SDRAM before the call to sdram_size() happens. Yes, this was the way how many ARM boards id, and this is what I'm trying to explain: this is WRONG. SDRAM configuration must be done while still running from NOR, i. e. before relocation. Only then free reconfiguration, auto-sizing etc. is possible. We shall rework the patch to do SDRAM size calculation as part of 'lowlevel_init' that is called before relocation. I hope that should solve the problem. I realize that gd will not be setup at this point of time. So, I would propose keeping the same patch. sdram_size() can be called at any point of time as SDRAM is initialized by the time u-boot starts. We can do whatever extra needed to support the new relocation scheme once those patches are upstream. Please note that we are always running from SDRAM because none of the OMAP4 boards so far have any XIP device. Regarding true run-time detection of SDRAM size and configuration: We do not support it today. However, LPDDR2 supports Mode Registers that have size info and our memory controller can read it. This coupled with the base AC timings specified by the LPDDR2 spec creates the possibility of doing a truly run-time detection and configuration of SDRAM that works for all boards. I was indeed thinking of trying it out sometime. Please note that the base AC timing values may not be optimal for all memory parts. Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP4: Calculate SDRAM size
Hi Nishanth -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Nishanth Menon Sent: Saturday, September 25, 2010 8:30 PM To: Steve Sakoman Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP4: Calculate SDRAM size On 09/23/2010 04:12 PM, Steve Sakoman wrote: From: Aneesh Vane...@ti.com Calculate the SDRAM size from DMM configuration registers instead of using hard-coded values. This gives correct values for all different boards. It's assumed that DMM sections do not overlap memory areas. How do we handle NOR boot? is it assumed that the configuration will be done way befor the sdram_init? I think you are referring to SDRAM initialization. Yes, it is assumed that SDRAM initialization(at least the DMM part of it) is done before the call to sdram_size(). The right location for this seems to be the initial part of sdram_init(). Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
Hi, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Vipin Kumar Sent: Tuesday, September 14, 2010 3:52 PM To: Stefan Roese Cc: u-boot@lists.denx.de; Shiraz HASHIM Subject: Re: [U-Boot] Multiple binaries built through u-boot source On 9/14/2010 12:46 PM, Stefan Roese wrote: Hello Stefan, On Tuesday 14 September 2010 07:22:10 Vipin Kumar wrote: This is about a generic problem which may also be faced by other developers. Our SoC has a masked bootrom area which copies an image from NOR/NAND memories to an internal embedded SRAM. The size of this SRAM is only 8K. This binary initializes the DDR for larger binaries (u-boot/OS) to be placed in RAM and executed from there. I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. It's sheer coincidence that I also wanted to post a very similar query today. We have a similar requirement for OMAP platforms. Presently, we are maintaining a mini bootloader(called x-loader, based on u-boot)separately. We want to integrate x-loader with u-boot and up-stream the source code. Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/26] ARM: cp15: setup mmu and enable dcache
Hello Heiko, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Heiko Schocher Sent: Wednesday, August 11, 2010 11:46 PM To: U-Boot user list Cc: Alessandro Rubini Subject: [U-Boot] [PATCH 03/26] ARM: cp15: setup mmu and enable dcache This has been tested on at91sam9263 and STN8815. Again, I didn't check if it has bad effects on non-arm926 cores. Initially I had a done bit to only set up page tables at the beginning. However, since the aligmnent requirement was for the whole object file, this extra integer tool 16kB in BSS, so I chose to remove it. This is rather strange. I thought the linker would have done better. However, I could overcome this problem by making 'done' a non-zero initialized variable. Can't you try that? I think the 'done' bit is quite useful. I see that the dcache_enable() is called from multiple places. I tested your patch on OMAP4430(Cortex-A9). It works fine Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/26] ARM: cp15: setup mmu and enable dcache
Hello Heiko Schocher,
boun...@lists.denx.de] On Behalf Of Heiko Schocher
+static inline void mmu_setup(void)
+{
+ static u32 __attribute__((aligned(16384))) page_table[4096];
+ bd_t *bd = gd-bd;
+ int i, j;
+ u32 reg;
+
+ /* Set up an identity-mapping for all 4GB, rw for everyone */
+ for (i = 0; i 4096; i++)
+ page_table[i] = i 20 | (3 10) | 0x12;
+ /* Then, enable cacheable and bufferable for RAM only */
+ for (j = 0; j CONFIG_NR_DRAM_BANKS; j++) {
+ for (i = bd-bi_dram[j].start 20;
+ i (bd-bi_dram[j].start + bd-bi_dram[j].size)
20;
+ i++) {
+ page_table[i] = i 20 | (3 10) | CACHE_SETUP;
+ }
+ }
+
+ /* Copy the page table address to cp15 */
+ asm volatile(mcr p15, 0, %0, c2, c0, 0
+ : : r (page_table) : memory);
+ /* Set the access control to all-supervisor */
+ asm volatile(mcr p15, 0, %0, c3, c0, 0
+ : : r (~0));
+ /* and enable the mmu */
+ reg = get_cr(); /* get control reg. */
+ cp_delay();
+ set_cr(reg | CR_M);
I think you need to invalidate caches, TLB, branch-prediction array etc before
enabling MMU. I don't think the caches are guaranteed to be invalidated at
power on reset.
Please find below some experimental(but working) code I had written for
enabling MMU and caches for an internal project. It's written for the ARM RVCT
tool chain. So, it will not compile straight away on GCC.
It has code for invalidating caches, TLB, Branch prediction array etc. Also, it
uses macros for the bit fields in the SCTLR register. However, the L1 D$
cleaning is not generic. It assumes the size and organization of the L1 cache.
arch/arm/cpu/armv7/omap3/cache.S has a more generic implementation of
invalidating the entire L1 D$.
In case you find it useful, you are welcome to reuse any part of this code. If
you want me to create a patch myself I am open to do that too.
Best regards,
Aneesh
Mmu.c:
/*
* (C) Copyright 2008
* Texas Instruments, www.ti.com
* Author:
* Aneesh V ane...@ti.com
*
* 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's version 2 of
* the License.
*
* 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 utils.h
#ifdef MMU_ENABLED
extern unsigned int pagetable[1024*4];
extern unsigned int Vector(void);
#define PAGE_TAB_SECTION_CONSTANTS 0x40002
#define NS_BIT_1 0x8
#define nG_0 0
#define S_BIT_1 0x01
#define AP_FULL_ACCESS 0x00C00
#define DOMAIN_0 0
#define XN_1 0x10
#define TEX_C_B_NORMAL_I_WBWA_O_WBWA 0x05004
#define TEX_C_B_NORMAL_I_WBWA_O_NC 0x04004
#define TEX_C_B_NORMAL_I_NC_O_NC 0x01002
#define TEX_C_B_NORMAL_SHARABLE_DEVICE 0x4
#define SECTION_ENTRY_FULL_ACCESS_FULL_CACHED
(PAGE_TAB_SECTION_CONSTANTS|NS_BIT_1|nG_0|S_BIT_1|AP_FULL_ACCESS|DOMAIN_0|TEX_C_B_NORMAL_I_WBWA_O_WBWA)
#define SECTION_ENTRY_FULL_ACCESS_FULL_CACHED_NON_SHARED
(PAGE_TAB_SECTION_CONSTANTS|NS_BIT_1|nG_0|AP_FULL_ACCESS|DOMAIN_0|TEX_C_B_NORMAL_I_WBWA_O_WBWA)
#define SECTION_ENTRY_FULL_ACCESS_NORMAL_NC
(PAGE_TAB_SECTION_CONSTANTS|NS_BIT_1|nG_0|S_BIT_1|AP_FULL_ACCESS|DOMAIN_0|TEX_C_B_NORMAL_I_NC_O_NC)
#define SECTION_ENTRY_FULL_ACCESS_SHARED_DEVICE
(PAGE_TAB_SECTION_CONSTANTS|NS_BIT_1|nG_0|S_BIT_1|AP_FULL_ACCESS|DOMAIN_0|TEX_C_B_NORMAL_SHARABLE_DEVICE)
#define M_BIT_1 0x1
#define C_BIT_1 0x4
#define Z_BIT_1 0x800
#define I_BIT_1 0x1000
#define V_BIT_1 0x2000
#define SCTRL_VALUE (M_BIT_1|C_BIT_1|Z_BIT_1|I_BIT_1|V_BIT_1)
//#define SCTRL_VALUE (M_BIT_1|Z_BIT_1|I_BIT_1|V_BIT_1)
__asm void setvector(void);
void setup_pagetable(unsigned int *pagetable, unsigned int devicemem_attr,
unsigned int code_and_data);
__asm unsigned int setup_vector(unsigned int (*vector)(void));
__asm unsigned int setup_ttbr0(unsigned int ttbr0value);
__asm unsigned int setup_ttbr1(unsigned int ttbr1value);
__asm unsigned int setup_ttbrc(unsigned int ttbrc_value);
__asm unsigned int setup_dacr(unsigned int dacr_value);
__asm unsigned int setup_sctlr(unsigned int sctlrr_value);
__asm void invalidate_caches(void);
__asm void barriers(void);
__asm void enable_pl310(void);
void invalidate_dcache_setway(unsigned int setway);
void stresstestaftermmu(void);
__asm unsigned int setup_prrr(unsigned int prrr_value)
{
MCR p15,0,r0,c10,c2,0 ; Read CP15 Primary Region Remap Register
bx lr
}
__asm unsigned int setup_nmrr(unsigned int
Re: [U-Boot] [PATCH 03/26] ARM: cp15: setup mmu and enable dcache
Hello Heiko,
-Original Message-
From: Heiko Schocher [mailto:h...@denx.de]
Sent: Wednesday, September 01, 2010 4:56 PM
To: V, Aneesh
Cc: U-Boot user list; Alessandro Rubini
Subject: Re: [U-Boot] [PATCH 03/26] ARM: cp15: setup mmu and enable
dcache
Hello V, Aneesh,
V, Aneesh wrote:
Hello Heiko Schocher,
boun...@lists.denx.de] On Behalf Of Heiko Schocher
+static inline void mmu_setup(void)
+{
+ static u32 __attribute__((aligned(16384))) page_table[4096];
+ bd_t *bd = gd-bd;
+ int i, j;
+ u32 reg;
+
+ /* Set up an identity-mapping for all 4GB, rw for everyone */
+ for (i = 0; i 4096; i++)
+ page_table[i] = i 20 | (3 10) | 0x12;
+ /* Then, enable cacheable and bufferable for RAM only */
+ for (j = 0; j CONFIG_NR_DRAM_BANKS; j++) {
+ for (i = bd-bi_dram[j].start 20;
+ i (bd-bi_dram[j].start + bd-bi_dram[j].size)
20;
+ i++) {
+ page_table[i] = i 20 | (3 10) | CACHE_SETUP;
+ }
+ }
+
+ /* Copy the page table address to cp15 */
+ asm volatile(mcr p15, 0, %0, c2, c0, 0
+ : : r (page_table) : memory);
+ /* Set the access control to all-supervisor */
+ asm volatile(mcr p15, 0, %0, c3, c0, 0
+ : : r (~0));
+ /* and enable the mmu */
+ reg = get_cr(); /* get control reg. */
+ cp_delay();
+ set_cr(reg | CR_M);
I think you need to invalidate caches, TLB, branch-prediction
array etc before enabling MMU. I don't think the caches are
guaranteed to be invalidated at power on reset.
Please find below some experimental(but working) code I had
written for enabling MMU and caches for an internal project. It's
written for the ARM RVCT tool chain. So, it will not compile
straight away on GCC.
It has code for invalidating caches, TLB, Branch prediction array
etc. Also, it uses macros for the bit fields in the SCTLR register.
However, the L1 D$ cleaning is not generic. It assumes the size and
organization of the L1 cache.
arch/arm/cpu/armv7/omap3/cache.S has a more generic implementation
of invalidating the entire L1 D$.
In case you find it useful, you are welcome to reuse any part of
this code. If you want me to create a patch myself I am open to do
that too.
Thanks!
I try to try out your suggestions, if you can make a patch
(and try it on a plattform it would be great ;-)
I will try this out as time permits. I should be able to test it on
OMAP3430(Cortex-A8) and OMAP4430(Cortex-A9).
Thanks,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm: cortexa9: adding support for TI OMAP4430 SDP
Hello Wolfgang,
Thanks for your comments. We will fix the issues you have pointed out.
+#endif /* CONFIG_DISPLAY_BOARDINFO */
...
+#ifdef CONFIG_DISPLAY_CPUINFO
These #defines have never been documented. It seems they are being
copied around a lot, but I'm not sure if anybody ever does NOT set
these.
I think we should at least document these - or rather drop them
everywhere. What do you think?
I'm ok with dropping it everywhere.
+{
+
+ printf (CPU : OMAP4430 ES1.0 \n);
puts()?
And: no spaces after function names please (fix globally!).
But how about this rule mentioned in your wiki:
All contributions to U-Boot should conform to the Linux kernel coding style;
see the file Documentation/CodingStyle and the script scripts/Lindent in
your Linux kernel source directory. In sources originating from U-Boot a style
corresponding to Lindent -pcs (adding spaces before parameters to function
calls) is actually used.
http://www.denx.de/wiki/U-Boot/CodingStyle
In fact, I didn't add spaces initially. They got added when I ran Lindent
-pcs. Is this rule not applicable anymore? Or am I missing something?
Best regards,
Aneesh
-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Sunday, June 06, 2010 1:25 AM
To: V, Aneesh
Cc: u-boot@lists.denx.de; olbp...@list.ti.com - OMAP Linux Baseport
Development Team (May contain non-TIers)
Subject: Re: [U-Boot] [PATCH 2/2] arm: cortexa9: adding support for TI
OMAP4430 SDP
Dear Aneesh V,
In message 1274769577-29021-3-git-send-email-ane...@ti.com you wrote:
Adding support for OMAP4430 SDP board based on the TI OMAP4430 SOC.
TI OMAP4430 is an SOC based on ARM Cortex-A9 cpu.
OMAP4430 SDP is a reference board based on OMAP4430.
This patch adds minimum support for booting the board.
OMAP4430 SDP does not support XIP. U-boot is loaded to SDRAM with the
help of
another small bootloader running from SRAM. U-boot currently relies on
this
bootloader for clock, mux, and SDRAM initialization.
This will change when OMAP4430 Configuration Header(CH) is attached
to u-boot. CH is a feature by which ROM code can be made to intialize
the
clocks and SDRAM and to copy u-boot directly into SDRAM from a non-XIP
device.
More support such as MMC, ethernet etc will be added in subsequent
patches.
Signed-off-by: Aneesh V ane...@ti.com
In addition to John's comments:
Makefile|8 +-
arch/arm/cpu/armv7/omap4/Makefile | 50 +
arch/arm/cpu/armv7/omap4/cache.S| 128
arch/arm/cpu/armv7/omap4/lowlevel_init.S| 49 +
arch/arm/cpu/armv7/omap4/omap4.c| 97 +
arch/arm/cpu/armv7/omap4/reset.S| 36
arch/arm/cpu/armv7/omap4/sys_info.c | 58 ++
arch/arm/cpu/armv7/omap4/timer.c| 140 +
arch/arm/include/asm/arch-omap4/cpu.h | 89 +
arch/arm/include/asm/arch-omap4/omap4.h | 142 ++
arch/arm/include/asm/arch-omap4/sys_proto.h | 36
board/ti/sdp4430/Makefile | 49 +
board/ti/sdp4430/config.mk | 32 +++
board/ti/sdp4430/sdp.c | 56 ++
include/configs/omap4_sdp4430.h | 280
+++
15 files changed, 1249 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/cpu/armv7/omap4/Makefile
create mode 100644 arch/arm/cpu/armv7/omap4/cache.S
create mode 100644 arch/arm/cpu/armv7/omap4/lowlevel_init.S
create mode 100644 arch/arm/cpu/armv7/omap4/omap4.c
create mode 100644 arch/arm/cpu/armv7/omap4/reset.S
create mode 100644 arch/arm/cpu/armv7/omap4/sys_info.c
create mode 100644 arch/arm/cpu/armv7/omap4/timer.c
create mode 100644 arch/arm/include/asm/arch-omap4/cpu.h
create mode 100644 arch/arm/include/asm/arch-omap4/omap4.h
create mode 100644 arch/arm/include/asm/arch-omap4/sys_proto.h
create mode 100644 board/ti/sdp4430/Makefile
create mode 100644 board/ti/sdp4430/config.mk
create mode 100644 board/ti/sdp4430/sdp.c
create mode 100644 include/configs/omap4_sdp4430.h
Entries to MAKEALL and MAINTAINERS files missing.
+int checkboard (void)
+{
+ printf (%s\n, sysinfo.board_string);
+ return 0;
+}
Consider using puts() when you don't need any output formatting.
+#endif /* CONFIG_DISPLAY_BOARDINFO */
...
+#ifdef CONFIG_DISPLAY_CPUINFO
These #defines have never been documented. It seems they are being
copied around a lot, but I'm not sure if anybody ever does NOT set
these.
I think we should at least document these - or rather drop them
everywhere. What do you think?
+{
+
+ printf (CPU : OMAP4430 ES1.0 \n);
puts()?
And: no spaces after function names please (fix globally!).
...
+/*
+ * High Level Configuration Options
+ */
+#define CONFIG_ARMCORTEXA9 1
[U-Boot] make: how to add post-build step?
Hi, We would like to add a post-build step for OMAP4430SDP. The intention of this step is to attach a header at the beginning of u-boot.bin and create a new binary. We do not mind having this as part of the main make step(i.e. as part of the target ALL) or as a separate target(let's say omap4_header). 1. Do we need to modify the top-level Makefile for this? OR 2. Can we do this somehow through the board level config.mk? If 2 is not possible, will you take a patch to do this by 1. We can try to make this as generic as possible. Attaching headers may be done by other boards too? Has this been done earlier? Any input on this will be appreciated. Regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
