Re: [U-Boot] Board-specific commands unintentionally linked into SPL?

[Aneesh V]

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.

-Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 4/6] armv7: Use -march=armv7-a and thereby enable Thumb-2

[Aneesh V]

Hi Marek,

On 07/06/2012 04:32 PM, Tetsuyuki Kobayashi wrote:

Hello,

On 2012/07/07, at 8:02, Marek Vasut wrote:


Dear Aneesh V,


Enable -march=armv7-a for armv7 platforms if the tool-chain
supports it. This in turn results in Thumb-2 code generated
for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.

Signed-off-by: Aneesh Vane...@ti.com
---


For some reason, this patch breaks USB EHCI on mx51 efika boards. The board just
freezes instead of detecting USB devices. Reverting this patch fixes the issue.

Note I use gcc 4.7.1 (!), might be compiler issue?

Tom, can you try on one of your beagle-dogs please? :)



Just for your information,
I doubt unaligned access causes this problem.

My investigation is here,
http://lists.denx.de/pipermail/u-boot/2012-June/127020.html
My patch
[PATCH] arm: armv7: add compile option  -mno-unaligned-access if available
http://lists.denx.de/pipermail/u-boot/2012-July/127260.html


This makes sense. You might want to try this patch. Also, to be sure
that it's nothing to do with Thumb you can make sure you are not
enabling CONFIG_SYS_THUMB_BUILD.

best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/9] CACHE: Add cache_aligned() macro

[Aneesh V]

Hi Marek,

On 06/25/2012 04:30 PM, Marek Vasut wrote:

Dear Scott Wood,


On 06/24/2012 07:17 PM, Marek Vasut wrote:

This macro returns 1 if the argument (address) is aligned, returns
zero otherwise. This will be used to test user-supplied address to
various commands to prevent user from loading data to/from unaligned
address when using caches.

This is made as a macro, because macros are expanded where they are
used. Therefore it can be easily instrumented to report position of
the fault.

Signed-off-by: Marek Vasutma...@denx.de
Cc: Wolfgang Denkw...@denx.de
---

  include/common.h |   18 ++
  1 file changed, 18 insertions(+)

diff --git a/include/common.h b/include/common.h
index 322569e..17c64b0 100644
--- a/include/common.h
+++ b/include/common.h
@@ -730,6 +730,24 @@ void   invalidate_dcache_range(unsigned long start,
unsigned long stop);

  void  invalidate_dcache_all(void);
  void  invalidate_icache_all(void);

+/* Test if address is cache-aligned. Returns 0 if it is, 1 otherwise. */
+#define cacheline_aligned(addr)

\

+   ({  \
+   int __ret;  \
+   if (!dcache_status()) { \
+   __ret = 1;  \
+   } else if ((addr)  (ARCH_DMA_MINALIGN - 1)) {  \
+   puts(Align load address to  \
+   __stringify(ARCH_DMA_MINALIGN)  \
+bytes when using caches!\n);   \
+   __ret = 0;  \
+   } else {\
+   __ret = 1;  \
+   }   \
+   __ret;  \
+   })


What if it's a store rather than a load?


Goot point #1


If this is only supposed to be
used for loads (because on a store you can flush the cache rather than
invalidate), it's not labelled that way, the changelog says to/from
unaligned address, and the caller might be common code that doesn't
know which direction the transfer is in.


And we're back at the flush/invalidate thing. This is what I'd really love to
understand once and for all:

1) We must prevent user from loading to address 0x...1 (unaligned), I'll get
back to this later on.

2) If the user had address that starts at aligned location but ends at
unaligned:

Terminology:
va -- unrelated variable
[] -- aligned range

2a) LOAD from external source to local address:
The cache must be invalidated over that area. I see the following issue:

[-buffer-][va]
[][][]
So consider the scenario where
i) va is written in u-boot
ii) data arrive into the buffer via DMA at the same time
iii) cache is invalidated over whole buffer

This will cause variable va to be lost forever. The va variable might as
well be user data, therefore in order to protect those, we should first flush
the user-supplied area.


Flushing the last cache line may corrupt the data you just DMAed in.
The current implementation after a lot of discussions [1] with Albert
is this:

Invalidate only the aligned part of the buffer. So, in the above case
the first two [] will get invalidated not the last one.
The last un-aligned cache line will result in a warning.

[1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/105113


2b) STORE from local address to external source:
Basically the inverted problem as in 2a), but if the driver is written properly,
shouldn't be any issue.


No. Store doesn't have any problem because flush doesn't harm anything.

I have laid down the invalidate/flush requirements for DMA buffers in:
doc/README.arm-caches

best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/9] CACHE: nand read/write: Test if start address is aligned

[Aneesh V]

On 06/24/2012 05:17 PM, Marek Vasut wrote:

This prevents the scenario where data cache is on and the
device uses DMA to deploy data. In that case, it might not
be possible to flush/invalidate data to RAM properly. The
other option is to use bounce buffer, but that involves a
lot of copying and therefore degrades performance rapidly.
Therefore disallow this possibility of unaligned load address
altogether if data cache is on.

Signed-off-by: Marek Vasutma...@denx.de
Cc: Scott Woodscottw...@freescale.com
---
  common/cmd_nand.c |9 +
  1 file changed, 9 insertions(+)

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index a91ccf4..122a91c 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -609,6 +609,8 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * 
const argv[])
goto usage;

addr = (ulong)simple_strtoul(argv[2], NULL, 16);
+   if (!cacheline_aligned(addr))
+   return 1;


You need to check the end address too. Also, I agree with Scott that
that this is an un-justifiable restriction on cache-coherent
architectures. IMO, such checks should be done in platform specific
code where the DMA is being attempted.

best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions

[Aneesh V]

Hi Sricharan,

On 06/21/2012 02:25 AM, Sricharan R wrote:

Hi,
[snip..]

On 06/15/2012 07:48 AM, R, Sricharan wrote:

Hi,


On Fri, Jun 15, 2012 at 12:31 AM, Tom Rinitr...@ti.com   wrote:

If we are built with D-CACHE enabled but have run 'dcache off' and

then

attempt to flush unaligned regions we spam the console with

problems

that aren't true (as the cache was off).


Today we do cache maintenance operations after the dcache is

turned off.

One example is before jumping to kernel, we try to invalidate

the caches,

in cache turned off state. So with this patch those maintenance

calls will

do nothing, which is not correct.


Ah yes,  But, shouldn't we be doing these same operations as part of
turning the cache off?


The problem is that while turning of dcaches, we flush it, and

turn

   cache and MMU off.  But these operations are not happening
   automatically in a single call. So there is a chance of  valid
   entries present in cache even after it is OFF.


I think this is what we need to fix. Otherwise, Tom's change looks good
to me. How about an invalidate in dcache_disable() or something like
that?


   Correct. So if the cleaning up sequence is fine, then ok.
   So there should be no need to check if caches are OFF inside
   the maintenance functions. Kernel does not looks like doing such checks.
   The real issue looks like we should have had assembly level functions
   to do the cleanup routines for flush-invalidate-turn OFF caches/MMU
atomically.


Sorry for the late reply. Yes, kernel doesn't do such checks. But
kernel's implementation is different from u-boot implementation. In
kernel the invalidate routine flushes unaligned lines in the end which,
after a lot of discussions[1], we decided to avoid in u-boot. Instead
we printed noisy error messages to alert the user. Now these messages
will appear even if we are calling the maintenance functions after the
disable and that's what Tom is trying to avoid.

br,
Aneeesh

[1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/105113
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions

[Aneesh V]

Sricharan,

On 06/21/2012 08:23 AM, R, Sricharan wrote:

Hi Aneesh,

On Thu, Jun 21, 2012 at 2:55 PM, Sricharan Rr.sricha...@ti.com  wrote:

Hi,
[snip..]

On 06/15/2012 07:48 AM, R, Sricharan wrote:

Hi,


On Fri, Jun 15, 2012 at 12:31 AM, Tom Rinitr...@ti.comwrote:

If we are built with D-CACHE enabled but have run 'dcache off' and

then

attempt to flush unaligned regions we spam the console with

problems

that aren't true (as the cache was off).


Today we do cache maintenance operations after the dcache is

turned off.

One example is before jumping to kernel, we try to invalidate

the caches,

in cache turned off state. So with this patch those maintenance

calls will

do nothing, which is not correct.


Ah yes,  But, shouldn't we be doing these same operations as part of
turning the cache off?


The problem is that while turning of dcaches, we flush it, and

turn

   cache and MMU off.  But these operations are not happening
   automatically in a single call. So there is a chance of  valid
   entries present in cache even after it is OFF.


I think this is what we need to fix. Otherwise, Tom's change looks good
to me. How about an invalidate in dcache_disable() or something like
that?


  Correct. So if the cleaning up sequence is fine, then ok.
  So there should be no need to check if caches are OFF inside
  the maintenance functions. Kernel does not looks like doing such checks.
  The real issue looks like we should have had assembly level functions
  to do the cleanup routines for flush-invalidate-turn OFF caches/MM
atomically.

   Actually, with something like speculation in the behind, only way of
ensuring that
we do not have any valid entries is to do a invalidate all, after
turn of caches/mmu.
So this means that we will have a maintenance after turning off.


Good point. But we need that invalidate just one last time after the
disable, right? How about making the cache_status a variable rather
than reading the C bit. And then disable_cache() shall be like this:

1. Flush all
2. Disable C bit
3. Invalidate all
4. cache_status = disabled

Maybe, not the best solution. But I can't think of anything better.
Please note that after this point there won't be any valid entries in
the cache per ARMv7 Architecture reference manual(section B2.2.2):

If the cache is disabled, it is guaranteed that no new allocation of 
memory locations into the cache will occur.


br,
Aneeesh
___
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

[Aneesh V]

Hi Albert,

On 06/25/2012 01:34 PM, Albert ARIBAUD wrote:

Hi Aneesh,


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.


What is the (non-contrived) problem to which allowing mis-aligned
accesses would be a solution?


memcpy() when there is a mismatch in the alignment of source and
destination buffers. Let's say the source buffer is 4 byte aligned
but the destination buffer is only 2 byte aligned. I believe relaxed
alignment requirements will help in writing an accelerated memcpy
routine for this case.

Again, my point is that as a platform software provider I would like
to enable such features to make maximum things work on my platform,
where as the developer of a generic sw module should probably avoid
depending on such features to ensure maximum portability.

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

[Aneesh V]

+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:

Hi Lucas,


Linux in particular does reinitialize this state and I expect any
reasonable OS to do so.


Then what is the point of enabling it on U-Boot? Does it fix some
issue whereby some mis-aligned piece of data cannot be properly
aligned?


Yes, it fixes U-Boot USB on Tegra, when built with a recent toolchain.
Fixing the alignment of some of the structures in the USB code should
also be done, but this is a whole lot more invasive and requires some
more thought, as the discussion about this on LKML shows. The issue
doesn't show for older toolchains, as they by default emit code to
work around unaligned accesses.

This patch fixes all unaligned issues, that may appear with recent
toolchains. We avoid having to instruct the toolchain to work around
unaligned accesses and gain better performance in cases where it is
needed.


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
The problem here is that simply removing the packed attribute is not the
right thing to do for structures that are used for accessing hardware
registers. I have to read a bit more of the USB code to come up with the
right thing to do for every structure there.

But apart from this, we certainly have situations where we have
unaligned accesses that are justified and could not be removed.
Activating the aligned access hardware check is crippling a feature of
the ARMv7 architecture that's apparently useful enough that all recent
toolchains default to using it and not using compiler side workarounds.
Furthermore setting the check bit doesn't even deactivate unaligned
access (there is also a bit for this, which is forced to 1 by all v7
implementations), but just traps the processor in case you care about
such unaligned accesses. Linux for example only sets this check bit if
you choose to install a trap handler for this.

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. Our options are either:
1. instruct the toolchain to insert workaround code or
2. allow v7 hardware to do the unaligned access on it's own
My comment about fixing the USB code applies only to part of the structs
used there as some of them generate _unnecessary_ unaligned accesses,
the issue that all unaligned accesses fail with current U-Boot built
with a recent toolchain has to be fixed either way and is exactly what
this patch does.


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().

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/

best regards,
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

[Aneesh V]

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:

Hi Lucas,


Linux in particular does reinitialize this state and I expect any
reasonable OS to do so.


Then what is the point of enabling it on U-Boot? Does it fix some
issue whereby some mis-aligned piece of data cannot be properly
aligned?


Yes, it fixes U-Boot USB on Tegra, when built with a recent toolchain.
Fixing the alignment of some of the structures in the USB code should
also be done, but this is a whole lot more invasive and requires some
more thought, as the discussion about this on LKML shows. The issue
doesn't show for older toolchains, as they by default emit code to
work around unaligned accesses.

This patch fixes all unaligned issues, that may appear with recent
toolchains. We avoid having to instruct the toolchain to work around
unaligned accesses and gain better performance in cases where it is
needed.


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
The problem here is that simply removing the packed attribute is not the
right thing to do for structures that are used for accessing hardware
registers. I have to read a bit more of the USB code to come up with the
right thing to do for every structure there.

But apart from this, we certainly have situations where we have
unaligned accesses that are justified and could not be removed.
Activating the aligned access hardware check is crippling a feature of
the ARMv7 architecture that's apparently useful enough that all recent
toolchains default to using it and not using compiler side workarounds.
Furthermore setting the check bit doesn't even deactivate unaligned
access (there is also a bit for this, which is forced to 1 by all v7
implementations), but just traps the processor in case you care about
such unaligned accesses. Linux for example only sets this check bit if
you choose to install a trap handler for this.

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. Our options are either:
1. instruct the toolchain to insert workaround code or
2. allow v7 hardware to do the unaligned access on it's own
My comment about fixing the USB code applies only to part of the structs
used there as some of them generate _unnecessary_ unaligned accesses,
the issue that all unaligned accesses fail with current U-Boot built
with a recent toolchain has to be fixed either way and is exactly what
this patch does.


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().

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/


BTW, I agree that enabling un-aligned access is not a bad idea.

br,
Aneeesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions

[Aneesh V]

Hi Sricharan,

On 06/15/2012 07:48 AM, R, Sricharan wrote:

Hi,


On Fri, Jun 15, 2012 at 12:31 AM, Tom Rinitr...@ti.com  wrote:

If we are built with D-CACHE enabled but have run 'dcache off' and then
attempt to flush unaligned regions we spam the console with problems
that aren't true (as the cache was off).


   Today we do cache maintenance operations after the dcache is turned off.
   One example is before jumping to kernel, we try to invalidate the caches,
   in cache turned off state. So with this patch those maintenance calls will
   do nothing, which is not correct.


Ah yes,  But, shouldn't we be doing these same operations as part of
turning the cache off?


   The problem is that while turning of dcaches, we flush it, and turn
  cache and MMU off.  But these operations are not happening
  automatically in a single call. So there is a chance of  valid
  entries present in cache even after it is OFF.


I think this is what we need to fix. Otherwise, Tom's change looks good
to me. How about an invalidate in dcache_disable() or something like
that?

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Relocation issue on armv7 targets

[Aneesh V]

Hi Jagan,

On 06/19/2012 08:36 AM, jagan wrote:

Hi Albert,

I have observed an issue regarding u-boot relocation, it's working with
_TEXT_BASE address but
for other address in DDR it's not working. Stops at relocation offset.


This is not quite clear to me. What's working and what's not working.
Please note that according to the new relocation scheme, u-boot should
start at CONFIG_SYS_TEXT_BASE. u-boot then relocates itself to the
end of available SDRAM. U-Boot will not work if it starts from any
other location.

Contrast this with the earlier scheme where U-boot could start from a
location other than CONFIG_SYS_TEXT_BASE and then it relocates itself
to CONFIG_SYS_TEXT_BASE

The following thread has some discussion on this topic.
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/95967/

br,
Aneesh




I was trying this on both QEMU as well as real target.

Here are my findings:
-
VExpress# tftp 0x8000 u-boot.bin
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 192.168.0.3; our IP address is 192.168.0.4
Filename 'u-boot.bin'.
Load address: 0x8000
Loading: ##
done
Bytes transferred = 128736 (1f6e0 hex)
VExpress# go 0x8000
## Starting application at 0x8000 ...


U-Boot 2012.04.01-4-gdd16cc2-dirty (Jun 19 2012 - 20:42:05)

U-Boot code: 6080 -  6081C200  BSS: -  60851C88
monitor len: 00051C88
ramsize: 0800
TLB table at: 67ff
Top of RAM usable for U-Boot at: 67ff
Reserving 327k for U-Boot at: 67f9e000
Reserving 144k for malloc() at: 67f7a000
Reserving 44 Bytes for Board Info at: 67f79fd4
Reserving 120 Bytes for Global Data at: 67f79f5c
New Stack Pointer is: 67f79f50
DRAM:  128 MiB
relocation Offset is: 0779e000
qemu: fatal: Trying to execute code outside RAM or ROM at 0x077a6a68

R00=67f79f5c R01=67f9e000 R02= R03=6081f610
R04=67f9e000 R05=67f79f5c R06=67f9e000 R07=0002
R08=6f80 R09=0779e000 R10=6081f610 R11=67f79ad9
R12=6ff8 R13=67f79f50 R14=077a6a68 R15=077a6a68
PSR=61d3 -ZC- A svc32
Aborted

 From the logs, it's unable to get the exact lr value a/f relocation
happens, due to
that board_init_r not been called.

Could you please help me, Do I need to change any TEXT_BASE or liker script
for this.?

I have analyzed and understood the code and seems to be some wired thing on
start code.
I found some hack for this, but does it a valid issue or did I make any
mistake.

Request for your help.

Regards,
Jagan.




___
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] OMAP4/5: Change omap4_sdp, omap4_panda, omap5_evm maintainer

[Aneesh V]

On 05/08/2012 10:16 PM, R Sricharan wrote:

Signed-off-by: R Sricharanr.sricha...@ti.com
CC: Aneesh Vane...@ti.com
CC: Tom Rinitr...@ti.com
---
  MAINTAINERS |   12 ++--
  1 files changed, 6 insertions(+), 6 deletions(-)


Acked-by: Aneesh V ane...@ti.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] image: add support for Android's boot image format

[Aneesh V]

On 03/17/2012 03:05 PM, Wolfgang Denk wrote:

Dear Aneesh V,

In message4f153c83.20...@ti.com  you wrote:


What is your final call on this? The above arguments sound convincing
to me, but I have to admit that I am no legal expert. Either way, it
will be great to have a closure on this. Lack of fastboot support was
the greatest impediment to adoption of mainline U-Boot in our previous
platforms. It will be really unfortunate if the same happens to OMAP5
that has just arrived.

 The license issue was a mistake on my side.

However, there is still cleanup needed for the commit message.


Thanks. I will see if somebody can take it forward.

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 0/6] Enable Thumb build for ARM platforms

[Aneesh V]

Tom, Albert,

Does this series look good?

On Thursday 08 March 2012 10:50 PM, Aneesh V wrote:

Thumb is an alternate instruction set available in many
ARM processors. Below is a detailed description from ARM
specs:

The Thumb instruction set is a re-encoded subset of the
ARM instruction set. Thumb instructions execute in their
own processor state, with the architecture defining the
mechanisms required to transition between ARM and Thumb
states. The key difference is that Thumb instructions are
half the size of ARM instructions(16 bits compared with 32
bits). Greater code density can usually be achieved by using
the Thumb instruction set in preference to the ARM instruction
set, at a cost of some reduction in performance

In ARMv6T2, Thumb-2 technology is introduced. This technology
makes it possible to extend the original Thumb instruction set
with many 32-bit instructions. The range of 32-bit Thumb instructions
included in ARMv6T2 permits Thumb code to achieve performance
similar to ARM code, with code density better than that of earlier
Thumb code. From ARMv6T2, the ARM and Thumb instruction sets provide
almost identical functionality

This series adds Thumb support in U-Boot and enables it for
OMAP4. It also fixes issues faced while booting OMAP4 with
Thumb-2 images of U-Boot and SPL.

Thumb mode is becoming increasingly relevant for U-Boot with
the advent of SPL. It's very important to keep SPL size smaller
considering the internal RAM size constraints on many platforms.
On OMAP4 the size reduction enables us to use SPL on secure devices
that have smaller internal RAM available for non-secure world.

To enable support for new platforms you just need to add
CONFIG_SYS_THUMB_BUILD in your config file.

Tool-chains tried:
1. Sourcery G++ Lite 2010q1-202
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1
GNU ld (Sourcery G++ Lite 2010q1-202) - binutils 2.19.51.20090709

2. Linaro 4.6-2012.01
arm-linux-gnueabi-gcc (crosstool-NG linaro-1.13.1-2012.01-20120125 -
Linaro GCC 2012.01) 4.6.3 20120105 (prerelease)
GNU ld (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 2012.01) 2.22

Code-size reduction:
Image   ARM build   Thumb build % Reduction
u-boot.bin  190408  144676  24.01%
u-boot-spl.bin  33200   25096   24.40%

Performance(timestamp just before the main loop):
ARM build   Thumb build % Reduction
898510us878247us-2.25%

Performance actually improved marginally for the Thumb
build, maybe because of the reduced image sizes.

Aneesh V (6):
   arm: adapt asm/linkage.h from Linux
   armv7: add appropriate headers for assembly functions
   ARM: enable Thumb build
   armv7: Use -march=armv7-a and thereby enable Thumb-2
   omap4+: Avoid using __attribute__ ((__packed__))
   OMAP4: enable Thumb build

  README |8 +
  arch/arm/config.mk |   22 +
  arch/arm/cpu/armv7/config.mk   |7 +++-
  arch/arm/cpu/armv7/mx5/lowlevel_init.S |5 ++-
  arch/arm/cpu/armv7/mx6/lowlevel_init.S |5 ++-
  arch/arm/cpu/armv7/omap-common/lowlevel_init.S |   14 
  arch/arm/cpu/armv7/omap-common/reset.S |5 ++-
  arch/arm/cpu/armv7/omap3/lowlevel_init.S   |   41 ---
  arch/arm/cpu/armv7/s5pc1xx/cache.S |   10 +++--
  arch/arm/cpu/armv7/s5pc1xx/reset.S |5 ++-
  arch/arm/cpu/armv7/start.S |   13 ---
  arch/arm/cpu/armv7/tegra2/lowlevel_init.S  |5 ++-
  arch/arm/cpu/armv7/u8500/lowlevel.S|9 +++--
  arch/arm/include/asm/arch-omap4/mux_omap4.h|2 +-
  arch/arm/include/asm/arch-omap5/mux_omap5.h|2 +-
  arch/arm/include/asm/linkage.h |7 
  include/configs/omap4_common.h |2 +
  include/linux/linkage.h|7 +++-
  18 files changed, 106 insertions(+), 63 deletions(-)
  create mode 100644 arch/arm/include/asm/linkage.h



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/6] arm: adapt asm/linkage.h from Linux

[Aneesh V]

On Sunday 11 March 2012 07:31 AM, Mike Frysinger wrote:

On Thursday 08 March 2012 12:20:17 Aneesh V wrote:

This will add ARM specific over-rides for the defines
from linux/linkage.h


Tested-by: Mike Frysingervap...@gentoo.org
-mike



Thanks Mike.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 3/6] ARM: enable Thumb build

[Aneesh V]

On Sunday 11 March 2012 07:32 AM, Mike Frysinger wrote:

Acked-by: Mike Frysingervap...@gentoo.org
-mike


Thanks Mike.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Building uboot image for panda board

[Aneesh V]

Hi Charles,

On Thursday 08 March 2012 04:48 PM, charlesKAO wrote:


Hi i am charles.
I am building the panda uboot image, but something wrong.

make[1]: Leaving directory
`/home/charles/Work_100G/PandaBoard/U_boot/u-boot/arch/arm/cpu/armv7'
make -C tools all
make[1]: Entering directory
`/home/charles/Work_100G/PandaBoard/U_boot/u-boot/tools'
make[1]: Leaving directory
`/home/charles/Work_100G/PandaBoard/U_boot/u-boot/tools'
make -C spl/board/ti/panda all
make[1]: Entering directory
`/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/board/ti/panda'
/home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-gcc
-g  -Os   -fno-common -ffixed-r8 -msoft-float   -D__KERNEL__
-DCONFIG_SYS_TEXT_BASE=0x80e8
-I/home/charles/Work_100G/PandaBoard/U_boot/u-boot/include -fno-builtin
-ffreestanding -nostdinc -isystem
/home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/include
-pipe  -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork  -mabi=aapcs-linux
-march=armv5 -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector
-DCONFIG_PRELOADER -Os -ffixed-r8 -ffunction-sections -fdata-sections
-march=armv7-a -mthumb -c -o spl-omap.o spl-omap.c
cd /home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/board/ti/panda
/home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-ld
-Bstatic -T
/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl-generated.lds
--gc-sections  start.o reset.o lowlevel_init.o  serial.o ns16550.o string.o
vsprintf.o console.o stdio.o ctype.o eabi_compat.o div64.o omap_hsmmc.o
omap24xx_i2c.o mmc.o time.o part.o part_dos.o fat.o syslib.o utils.o timer.o
spl-omap.o board.o clocks.o emif.o sdram_elpida.o \
-L
/home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/thumb
-lgcc \
-Map 
/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl.map \
-o 
/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl
clocks.o: In function `prcm_init':
clocks.c:(.text.prcm_init+0x8a): undefined reference to
`omap_set_gpio_direction'
clocks.c:(.text.prcm_init+0x92): undefined reference to
`omap_set_gpio_dataout'
make[1]: ***
[/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl] Error 1
make[1]: Leaving directory
`/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/board/ti/panda'
make: *** [SPL] Error 2


I believe you are trying an older version. The current HEAD of master
doesn't have gpio functions in clocks.c?

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/6] arm: adapt asm/linkage.h from Linux

[Aneesh V]

This will add ARM specific over-rides for the defines
from linux/linkage.h

Signed-off-by: Aneesh V ane...@ti.com
---
Not adding the defines for __ALIGN and __ALIGN_STR
because it's not clear why alignment is set to 0
(single byte alignment).

Creates a checkpatch error that can not be avoided

Changes in v4:
- Use STT_FUNC in the definition of ENDPROC in
  include/linux/linkage.h that is more portable
  than the '*function' versions. Now, remove the
  definition of ENDPROC from the arm linkage.h

Changes in v3:
- None

Changes in v2:
 - Newly added
---
 arch/arm/include/asm/linkage.h |7 +++
 include/linux/linkage.h|7 ++-
 2 files changed, 13 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/include/asm/linkage.h

diff --git a/arch/arm/include/asm/linkage.h b/arch/arm/include/asm/linkage.h
new file mode 100644
index 000..dbe4b4e
--- /dev/null
+++ b/arch/arm/include/asm/linkage.h
@@ -0,0 +1,7 @@
+#ifndef __ASM_LINKAGE_H
+#define __ASM_LINKAGE_H
+
+#define __ALIGN .align 0
+#define __ALIGN_STR .align 0
+
+#endif
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index ed4cf6c..7b749bb 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -44,8 +44,13 @@
 #define SYMBOL_NAME_LABEL(X)   X:
 #endif
 
+#ifndef __ALIGN
 #define __ALIGN .align 4
+#endif
+
+#ifndef __ALIGN_STR
 #define __ALIGN_STR.align 4
+#endif
 
 #ifdef __ASSEMBLY__
 
@@ -67,7 +72,7 @@
 
 #ifndef ENDPROC
 #define ENDPROC(name) \
-   .type name, @function; \
+   .type name STT_FUNC; \
END(name)
 #endif
 
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/6] armv7: add appropriate headers for assembly functions

[Aneesh V]

Use ENTRY and ENDPROC with assembly functions to ensure
necessary assembler directives for all functions.

Signed-off-by: Aneesh V ane...@ti.com
---
Changes in v4:
- None

Changes in v3:
- None

Changes in V2:
- Newly added
---
 arch/arm/cpu/armv7/mx5/lowlevel_init.S |5 ++-
 arch/arm/cpu/armv7/mx6/lowlevel_init.S |5 ++-
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |   14 
 arch/arm/cpu/armv7/omap-common/reset.S |5 ++-
 arch/arm/cpu/armv7/omap3/lowlevel_init.S   |   41 ---
 arch/arm/cpu/armv7/s5pc1xx/cache.S |   10 +++--
 arch/arm/cpu/armv7/s5pc1xx/reset.S |5 ++-
 arch/arm/cpu/armv7/start.S |   13 ---
 arch/arm/cpu/armv7/tegra2/lowlevel_init.S  |5 ++-
 arch/arm/cpu/armv7/u8500/lowlevel.S|9 +++--
 10 files changed, 61 insertions(+), 51 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S 
b/arch/arm/cpu/armv7/mx5/lowlevel_init.S
index 01f6d75..5344410 100644
--- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S
@@ -22,6 +22,7 @@
 #include config.h
 #include asm/arch/imx-regs.h
 #include generated/asm-offsets.h
+#include linux/linkage.h
 
 /*
  * L2CC Cache setup/invalidation/disable
@@ -312,8 +313,7 @@
 
 .section .text.init, x
 
-.globl lowlevel_init
-lowlevel_init:
+ENTRY(lowlevel_init)
 #if defined(CONFIG_MX51)
ldr r0, =GPIO1_BASE_ADDR
ldr r1, [r0, #0x0]
@@ -334,6 +334,7 @@ lowlevel_init:
 
/* r12 saved upper lr*/
mov pc,lr
+ENDPROC(lowlevel_init)
 
 /* Board level setting value */
 W_DP_OP_864:  .word DP_OP_864
diff --git a/arch/arm/cpu/armv7/mx6/lowlevel_init.S 
b/arch/arm/cpu/armv7/mx6/lowlevel_init.S
index 1864356..acadef2 100644
--- a/arch/arm/cpu/armv7/mx6/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/mx6/lowlevel_init.S
@@ -18,7 +18,8 @@
  */
 .section .text.init, x
 
-.globl lowlevel_init
-lowlevel_init:
+#include linux/linkage.h
 
+ENTRY(lowlevel_init)
mov pc, lr
+ENDPROC(lowlevel_init)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S 
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 35f38ac..ccc6bb6 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -27,9 +27,9 @@
  */
 
 #include asm/arch/omap.h
+#include linux/linkage.h
 
-.global save_boot_params
-save_boot_params:
+ENTRY(save_boot_params)
/*
 * See if the rom code passed pointer is valid:
 * It is not valid if it is not in non-secure SRAM
@@ -76,10 +76,9 @@ save_boot_params:
strbr2, [r3, #CH_FLAGS_OFFSET]
 1:
bx  lr
+ENDPROC(save_boot_params)
 
-
-.globl lowlevel_init
-lowlevel_init:
+ENTRY(lowlevel_init)
/*
 * Setup a temporary stack
 */
@@ -95,12 +94,13 @@ lowlevel_init:
 */
bl  s_init
pop {ip, pc}
+ENDPROC(lowlevel_init)
 
-.globl set_pl310_ctrl_reg
-set_pl310_ctrl_reg:
+ENTRY(set_pl310_ctrl_reg)
PUSH{r4-r11, lr}@ save registers - ROM code may pollute
@ our registers
LDR r12, =0x102 @ Set PL310 control register - value in R0
.word   0xe1600070  @ SMC #0 - hand assembled because -march=armv5
@ call ROM Code API to set control register
POP {r4-r11, pc}
+ENDPROC(set_pl310_ctrl_reg)
diff --git a/arch/arm/cpu/armv7/omap-common/reset.S 
b/arch/arm/cpu/armv7/omap-common/reset.S
index 838b122..179a476 100644
--- a/arch/arm/cpu/armv7/omap-common/reset.S
+++ b/arch/arm/cpu/armv7/omap-common/reset.S
@@ -22,9 +22,9 @@
  */
 
 #include config.h
+#include linux/linkage.h
 
-.global reset_cpu
-reset_cpu:
+ENTRY(reset_cpu)
ldr r1, rstctl  @ get addr for global reset
@ reg
ldr r3, rstbit  @ sw reset bit
@@ -36,3 +36,4 @@ rstctl:
.word   PRM_RSTCTRL
 rstbit:
.word   PRM_RSTCTRL_RESET
+ENDPROC(reset_cpu)
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S 
b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index c42c5dd..ebf69fa 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -31,22 +31,22 @@
 #include version.h
 #include asm/arch/mem.h
 #include asm/arch/clocks_omap3.h
+#include linux/linkage.h
 
 _TEXT_BASE:
.word   CONFIG_SYS_TEXT_BASE/* sdram load addr from config.mk */
 
 #ifdef CONFIG_SPL_BUILD
-.global save_boot_params
-save_boot_params:
+ENTRY(save_boot_params)
ldr r4, =omap3_boot_device
ldr r5, [r0, #0x4]
and r5, r5, #0xff
str r5, [r4]
bx  lr
+ENDPROC(save_boot_params)
 #endif
 
-.global omap3_gp_romcode_call
-omap3_gp_romcode_call:
+ENTRY(omap3_gp_romcode_call)
PUSH {r4-r12, lr} @ Save all registers from ROM code!
MOV r12, r0 @ Copy

[U-Boot] [PATCH 4/6] armv7: Use -march=armv7-a and thereby enable Thumb-2

[Aneesh V]

Enable -march=armv7-a for armv7 platforms if the tool-chain
supports it. This in turn results in Thumb-2 code generated
for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.

Signed-off-by: Aneesh V ane...@ti.com
---
I believe armv7-a is fine for all the SoCs except Tegra2
and I see that Tegra2 is already making the necessary
exception in .../armv7/tegra2/config.mk

Let me know if any other SoC has a problem with armv7-a

Changes in V4:
- Replaced += with := for make variable that involves
  computation

Changes in V3:
- None

Changes from V1 to V2:
- None

Changes from RFC to V1:
- Enabled armv7-a from armv7/config.mk instead of from
  omap config.mk files
---
 arch/arm/cpu/armv7/config.mk |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
index 83ddf10..6d4b13c 100644
--- a/arch/arm/cpu/armv7/config.mk
+++ b/arch/arm/cpu/armv7/config.mk
@@ -22,8 +22,11 @@
 #
 PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 
-# Make ARMv5 to allow more compilers to work, even though its v7a.
-PLATFORM_CPPFLAGS += -march=armv5
+# If armv7-a is not supported by GCC fall-back to armv5, which is
+# supported by more tool-chains
+PF_CPPFLAGS_ARMV7 := $(call cc-option, -march=armv7-a, -march=armv5)
+PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARMV7)
+
 # =
 #
 # Supply options according to compiler version
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/6] ARM: enable Thumb build

[Aneesh V]

Enable Thumb build and ARM-Thumb interworking based on the new
config flag CONFIG_SYS_THUMB_BUILD

Signed-off-by: Aneesh V ane...@ti.com
---
Changes in v4:
- Use ':=' instead of '+=' when computed make variables
  are involved

Changes in v3:
- None

Changes from V1 to V2:
- None

Changes from RFC to V1:
- Fixed review comments from Tom Rini tr...@ti.com
---
 README |8 
 arch/arm/config.mk |   22 +++---
 2 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/README b/README
index 8964672..bdb428e 100644
--- a/README
+++ b/README
@@ -426,6 +426,14 @@ The following options need to be configured:
Select high exception vectors of the ARM core, e.g., do not
clear the V bit of the c1 register of CP15.
 
+   CONFIG_SYS_THUMB_BUILD
+
+   Use this flag to build U-Boot using the Thumb instruction
+   set for ARM architectures. Thumb instruction set provides
+   better code density. For ARM architectures that support
+   Thumb2 this flag will result in Thumb2 code generated by
+   GCC.
+
 - Linux Kernel Interface:
CONFIG_CLOCKS_IN_MHZ
 
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 45f9dca..d4fa1f8 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -33,25 +33,33 @@ endif
 
 PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__
 
-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
-PF_CPPFLAGS_ARM := $(call cc-option,-marm,)
+# Choose between ARM/Thumb instruction sets
+ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
+PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\
+   $(call cc-option,-marm,)\
+   $(call cc-option,-mno-thumb-interwork,)\
+   )
+else
+PF_CPPFLAGS_ARM := $(call cc-option,-marm,) \
+   $(call cc-option,-mno-thumb-interwork,)
+endif
 
 # Try if EABI is supported, else fall back to old API,
 # i. e. for example:
 # - with ELDK 4.2 (EABI supported), use:
-#  -mabi=aapcs-linux -mno-thumb-interwork
+#  -mabi=aapcs-linux
 # - with ELDK 4.1 (gcc 4.x, no EABI), use:
-#  -mabi=apcs-gnu -mno-thumb-interwork
+#  -mabi=apcs-gnu
 # - with ELDK 3.1 (gcc 3.x), use:
-#  -mapcs-32 -mno-thumb-interwork
+#  -mapcs-32
 PF_CPPFLAGS_ABI := $(call cc-option,\
-   -mabi=aapcs-linux -mno-thumb-interwork,\
+   -mabi=aapcs-linux,\
$(call cc-option,\
-mapcs-32,\
$(call cc-option,\
-mabi=apcs-gnu,\
)\
-   ) $(call cc-option,-mno-thumb-interwork,)\
+   )\
)
 PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARM) $(PF_CPPFLAGS_ABI)
 
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 5/6] omap4+: Avoid using __attribute__ ((__packed__))

[Aneesh V]

Avoid using __attribute__ ((__packed__)) unless it's
absolutely necessary. packed will remove alignment
requirements for the respective objects and may cause
alignment issues unless alignment is also enforced
using a pragma.

Here, these packed attributes were causing alignment
faults in Thumb build.

Signed-off-by: Aneesh V ane...@ti.com
---

Changes in v4:
- None

Changes in v3:
- Newly added
---
 arch/arm/include/asm/arch-omap4/mux_omap4.h |2 +-
 arch/arm/include/asm/arch-omap5/mux_omap5.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap4/mux_omap4.h 
b/arch/arm/include/asm/arch-omap4/mux_omap4.h
index 30bfad7..4de7c70 100644
--- a/arch/arm/include/asm/arch-omap4/mux_omap4.h
+++ b/arch/arm/include/asm/arch-omap4/mux_omap4.h
@@ -34,7 +34,7 @@ struct pad_conf_entry {
 
u16 val;
 
-} __attribute__ ((packed));
+};
 
 #ifdef CONFIG_OFF_PADCONF
 #define OFF_PD  (1  12)
diff --git a/arch/arm/include/asm/arch-omap5/mux_omap5.h 
b/arch/arm/include/asm/arch-omap5/mux_omap5.h
index b8c2185..af6874f 100644
--- a/arch/arm/include/asm/arch-omap5/mux_omap5.h
+++ b/arch/arm/include/asm/arch-omap5/mux_omap5.h
@@ -34,7 +34,7 @@ struct pad_conf_entry {
 
u16 val;
 
-} __attribute__ ((__packed__));
+};
 
 #ifdef CONFIG_OFF_PADCONF
 #define OFF_PD  (1  12)
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 6/6] OMAP4: enable Thumb build

[Aneesh V]

Signed-off-by: Aneesh V ane...@ti.com
---
Changes in v4:
- None

Changes in v3:
- None

Changes from V1 to V2:
- None

Changes from RFC to V1:
- None
---
 include/configs/omap4_common.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index a989721..01b4d6c 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -287,4 +287,6 @@
 
 #define CONFIG_SYS_ENABLE_PADS_ALL
 
+#define CONFIG_SYS_THUMB_BUILD
+
 #endif /* __CONFIG_OMAP4_COMMON_H */
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] arm: adapt asm/linkage.h from Linux

[Aneesh V]

Missed adding 'v4' in the subject. Please ignore this series. Will
re-send correcting the subject.

On Thursday 08 March 2012 10:40 PM, Aneesh V wrote:

This will add ARM specific over-rides for the defines
from linux/linkage.h

Signed-off-by: Aneesh Vane...@ti.com
---
Not adding the defines for __ALIGN and __ALIGN_STR
because it's not clear why alignment is set to 0
(single byte alignment).

Creates a checkpatch error that can not be avoided

Changes in v4:
- Use STT_FUNC in the definition of ENDPROC in
   include/linux/linkage.h that is more portable
   than the '*function' versions. Now, remove the
   definition of ENDPROC from the arm linkage.h

Changes in v3:
- None

Changes in v2:
  - Newly added
---
  arch/arm/include/asm/linkage.h |7 +++
  include/linux/linkage.h|7 ++-
  2 files changed, 13 insertions(+), 1 deletions(-)
  create mode 100644 arch/arm/include/asm/linkage.h

diff --git a/arch/arm/include/asm/linkage.h b/arch/arm/include/asm/linkage.h
new file mode 100644
index 000..dbe4b4e
--- /dev/null
+++ b/arch/arm/include/asm/linkage.h
@@ -0,0 +1,7 @@
+#ifndef __ASM_LINKAGE_H
+#define __ASM_LINKAGE_H
+
+#define __ALIGN .align 0
+#define __ALIGN_STR .align 0
+
+#endif
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index ed4cf6c..7b749bb 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -44,8 +44,13 @@
  #define SYMBOL_NAME_LABEL(X)  X:
  #endif

+#ifndef __ALIGN
  #define __ALIGN .align4
+#endif
+
+#ifndef __ALIGN_STR
  #define __ALIGN_STR   .align 4
+#endif

  #ifdef __ASSEMBLY__

@@ -67,7 +72,7 @@

  #ifndef ENDPROC
  #define ENDPROC(name) \
-   .type name, @function; \
+   .type name STT_FUNC; \
END(name)
  #endif



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 0/6] Enable Thumb build for ARM platforms

[Aneesh V]

Thumb is an alternate instruction set available in many
ARM processors. Below is a detailed description from ARM
specs:

The Thumb instruction set is a re-encoded subset of the
ARM instruction set. Thumb instructions execute in their
own processor state, with the architecture defining the
mechanisms required to transition between ARM and Thumb
states. The key difference is that Thumb instructions are
half the size of ARM instructions(16 bits compared with 32
bits). Greater code density can usually be achieved by using
the Thumb instruction set in preference to the ARM instruction
set, at a cost of some reduction in performance

In ARMv6T2, Thumb-2 technology is introduced. This technology
makes it possible to extend the original Thumb instruction set
with many 32-bit instructions. The range of 32-bit Thumb instructions
included in ARMv6T2 permits Thumb code to achieve performance
similar to ARM code, with code density better than that of earlier
Thumb code. From ARMv6T2, the ARM and Thumb instruction sets provide
almost identical functionality

This series adds Thumb support in U-Boot and enables it for
OMAP4. It also fixes issues faced while booting OMAP4 with
Thumb-2 images of U-Boot and SPL.

Thumb mode is becoming increasingly relevant for U-Boot with
the advent of SPL. It's very important to keep SPL size smaller
considering the internal RAM size constraints on many platforms.
On OMAP4 the size reduction enables us to use SPL on secure devices
that have smaller internal RAM available for non-secure world. 

To enable support for new platforms you just need to add
CONFIG_SYS_THUMB_BUILD in your config file.

Tool-chains tried:
1. Sourcery G++ Lite 2010q1-202
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1
GNU ld (Sourcery G++ Lite 2010q1-202) - binutils 2.19.51.20090709

2. Linaro 4.6-2012.01
arm-linux-gnueabi-gcc (crosstool-NG linaro-1.13.1-2012.01-20120125 -
Linaro GCC 2012.01) 4.6.3 20120105 (prerelease)
GNU ld (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 2012.01) 2.22

Code-size reduction:
Image   ARM build   Thumb build % Reduction
u-boot.bin  190408  144676  24.01%
u-boot-spl.bin  33200   25096   24.40%

Performance(timestamp just before the main loop):
ARM build   Thumb build % Reduction
898510us878247us-2.25%

Performance actually improved marginally for the Thumb
build, maybe because of the reduced image sizes. 

Aneesh V (6):
  arm: adapt asm/linkage.h from Linux
  armv7: add appropriate headers for assembly functions
  ARM: enable Thumb build
  armv7: Use -march=armv7-a and thereby enable Thumb-2
  omap4+: Avoid using __attribute__ ((__packed__))
  OMAP4: enable Thumb build

 README |8 +
 arch/arm/config.mk |   22 +
 arch/arm/cpu/armv7/config.mk   |7 +++-
 arch/arm/cpu/armv7/mx5/lowlevel_init.S |5 ++-
 arch/arm/cpu/armv7/mx6/lowlevel_init.S |5 ++-
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |   14 
 arch/arm/cpu/armv7/omap-common/reset.S |5 ++-
 arch/arm/cpu/armv7/omap3/lowlevel_init.S   |   41 ---
 arch/arm/cpu/armv7/s5pc1xx/cache.S |   10 +++--
 arch/arm/cpu/armv7/s5pc1xx/reset.S |5 ++-
 arch/arm/cpu/armv7/start.S |   13 ---
 arch/arm/cpu/armv7/tegra2/lowlevel_init.S  |5 ++-
 arch/arm/cpu/armv7/u8500/lowlevel.S|9 +++--
 arch/arm/include/asm/arch-omap4/mux_omap4.h|2 +-
 arch/arm/include/asm/arch-omap5/mux_omap5.h|2 +-
 arch/arm/include/asm/linkage.h |7 
 include/configs/omap4_common.h |2 +
 include/linux/linkage.h|7 +++-
 18 files changed, 106 insertions(+), 63 deletions(-)
 create mode 100644 arch/arm/include/asm/linkage.h

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 1/6] arm: adapt asm/linkage.h from Linux

[Aneesh V]

This will add ARM specific over-rides for the defines
from linux/linkage.h

Signed-off-by: Aneesh V ane...@ti.com
---
Not adding the defines for __ALIGN and __ALIGN_STR
because it's not clear why alignment is set to 0
(single byte alignment).

Creates a checkpatch error that can not be avoided

Changes in v4:
- Use STT_FUNC in the definition of ENDPROC in
  include/linux/linkage.h that is more portable
  than the '*function' versions. Now, remove the
  definition of ENDPROC from the arm linkage.h

Changes in v3:
- None

Changes in v2:
 - Newly added
---
 arch/arm/include/asm/linkage.h |7 +++
 include/linux/linkage.h|7 ++-
 2 files changed, 13 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/include/asm/linkage.h

diff --git a/arch/arm/include/asm/linkage.h b/arch/arm/include/asm/linkage.h
new file mode 100644
index 000..dbe4b4e
--- /dev/null
+++ b/arch/arm/include/asm/linkage.h
@@ -0,0 +1,7 @@
+#ifndef __ASM_LINKAGE_H
+#define __ASM_LINKAGE_H
+
+#define __ALIGN .align 0
+#define __ALIGN_STR .align 0
+
+#endif
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index ed4cf6c..7b749bb 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -44,8 +44,13 @@
 #define SYMBOL_NAME_LABEL(X)   X:
 #endif
 
+#ifndef __ALIGN
 #define __ALIGN .align 4
+#endif
+
+#ifndef __ALIGN_STR
 #define __ALIGN_STR.align 4
+#endif
 
 #ifdef __ASSEMBLY__
 
@@ -67,7 +72,7 @@
 
 #ifndef ENDPROC
 #define ENDPROC(name) \
-   .type name, @function; \
+   .type name STT_FUNC; \
END(name)
 #endif
 
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 2/6] armv7: add appropriate headers for assembly functions

[Aneesh V]

Use ENTRY and ENDPROC with assembly functions to ensure
necessary assembler directives for all functions.

Signed-off-by: Aneesh V ane...@ti.com
---
Changes in v4:
- None

Changes in v3:
- None

Changes in V2:
- Newly added
---
 arch/arm/cpu/armv7/mx5/lowlevel_init.S |5 ++-
 arch/arm/cpu/armv7/mx6/lowlevel_init.S |5 ++-
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |   14 
 arch/arm/cpu/armv7/omap-common/reset.S |5 ++-
 arch/arm/cpu/armv7/omap3/lowlevel_init.S   |   41 ---
 arch/arm/cpu/armv7/s5pc1xx/cache.S |   10 +++--
 arch/arm/cpu/armv7/s5pc1xx/reset.S |5 ++-
 arch/arm/cpu/armv7/start.S |   13 ---
 arch/arm/cpu/armv7/tegra2/lowlevel_init.S  |5 ++-
 arch/arm/cpu/armv7/u8500/lowlevel.S|9 +++--
 10 files changed, 61 insertions(+), 51 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S 
b/arch/arm/cpu/armv7/mx5/lowlevel_init.S
index 01f6d75..5344410 100644
--- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S
@@ -22,6 +22,7 @@
 #include config.h
 #include asm/arch/imx-regs.h
 #include generated/asm-offsets.h
+#include linux/linkage.h
 
 /*
  * L2CC Cache setup/invalidation/disable
@@ -312,8 +313,7 @@
 
 .section .text.init, x
 
-.globl lowlevel_init
-lowlevel_init:
+ENTRY(lowlevel_init)
 #if defined(CONFIG_MX51)
ldr r0, =GPIO1_BASE_ADDR
ldr r1, [r0, #0x0]
@@ -334,6 +334,7 @@ lowlevel_init:
 
/* r12 saved upper lr*/
mov pc,lr
+ENDPROC(lowlevel_init)
 
 /* Board level setting value */
 W_DP_OP_864:  .word DP_OP_864
diff --git a/arch/arm/cpu/armv7/mx6/lowlevel_init.S 
b/arch/arm/cpu/armv7/mx6/lowlevel_init.S
index 1864356..acadef2 100644
--- a/arch/arm/cpu/armv7/mx6/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/mx6/lowlevel_init.S
@@ -18,7 +18,8 @@
  */
 .section .text.init, x
 
-.globl lowlevel_init
-lowlevel_init:
+#include linux/linkage.h
 
+ENTRY(lowlevel_init)
mov pc, lr
+ENDPROC(lowlevel_init)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S 
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 35f38ac..ccc6bb6 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -27,9 +27,9 @@
  */
 
 #include asm/arch/omap.h
+#include linux/linkage.h
 
-.global save_boot_params
-save_boot_params:
+ENTRY(save_boot_params)
/*
 * See if the rom code passed pointer is valid:
 * It is not valid if it is not in non-secure SRAM
@@ -76,10 +76,9 @@ save_boot_params:
strbr2, [r3, #CH_FLAGS_OFFSET]
 1:
bx  lr
+ENDPROC(save_boot_params)
 
-
-.globl lowlevel_init
-lowlevel_init:
+ENTRY(lowlevel_init)
/*
 * Setup a temporary stack
 */
@@ -95,12 +94,13 @@ lowlevel_init:
 */
bl  s_init
pop {ip, pc}
+ENDPROC(lowlevel_init)
 
-.globl set_pl310_ctrl_reg
-set_pl310_ctrl_reg:
+ENTRY(set_pl310_ctrl_reg)
PUSH{r4-r11, lr}@ save registers - ROM code may pollute
@ our registers
LDR r12, =0x102 @ Set PL310 control register - value in R0
.word   0xe1600070  @ SMC #0 - hand assembled because -march=armv5
@ call ROM Code API to set control register
POP {r4-r11, pc}
+ENDPROC(set_pl310_ctrl_reg)
diff --git a/arch/arm/cpu/armv7/omap-common/reset.S 
b/arch/arm/cpu/armv7/omap-common/reset.S
index 838b122..179a476 100644
--- a/arch/arm/cpu/armv7/omap-common/reset.S
+++ b/arch/arm/cpu/armv7/omap-common/reset.S
@@ -22,9 +22,9 @@
  */
 
 #include config.h
+#include linux/linkage.h
 
-.global reset_cpu
-reset_cpu:
+ENTRY(reset_cpu)
ldr r1, rstctl  @ get addr for global reset
@ reg
ldr r3, rstbit  @ sw reset bit
@@ -36,3 +36,4 @@ rstctl:
.word   PRM_RSTCTRL
 rstbit:
.word   PRM_RSTCTRL_RESET
+ENDPROC(reset_cpu)
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S 
b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index c42c5dd..ebf69fa 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -31,22 +31,22 @@
 #include version.h
 #include asm/arch/mem.h
 #include asm/arch/clocks_omap3.h
+#include linux/linkage.h
 
 _TEXT_BASE:
.word   CONFIG_SYS_TEXT_BASE/* sdram load addr from config.mk */
 
 #ifdef CONFIG_SPL_BUILD
-.global save_boot_params
-save_boot_params:
+ENTRY(save_boot_params)
ldr r4, =omap3_boot_device
ldr r5, [r0, #0x4]
and r5, r5, #0xff
str r5, [r4]
bx  lr
+ENDPROC(save_boot_params)
 #endif
 
-.global omap3_gp_romcode_call
-omap3_gp_romcode_call:
+ENTRY(omap3_gp_romcode_call)
PUSH {r4-r12, lr} @ Save all registers from ROM code!
MOV r12, r0 @ Copy

[U-Boot] [PATCH v4 3/6] ARM: enable Thumb build

[Aneesh V]

Enable Thumb build and ARM-Thumb interworking based on the new
config flag CONFIG_SYS_THUMB_BUILD

Signed-off-by: Aneesh V ane...@ti.com
---
Changes in v4:
- Use ':=' instead of '+=' when computed make variables
  are involved

Changes in v3:
- None

Changes from V1 to V2:
- None

Changes from RFC to V1:
- Fixed review comments from Tom Rini tr...@ti.com
---
 README |8 
 arch/arm/config.mk |   22 +++---
 2 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/README b/README
index 8964672..bdb428e 100644
--- a/README
+++ b/README
@@ -426,6 +426,14 @@ The following options need to be configured:
Select high exception vectors of the ARM core, e.g., do not
clear the V bit of the c1 register of CP15.
 
+   CONFIG_SYS_THUMB_BUILD
+
+   Use this flag to build U-Boot using the Thumb instruction
+   set for ARM architectures. Thumb instruction set provides
+   better code density. For ARM architectures that support
+   Thumb2 this flag will result in Thumb2 code generated by
+   GCC.
+
 - Linux Kernel Interface:
CONFIG_CLOCKS_IN_MHZ
 
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 45f9dca..d4fa1f8 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -33,25 +33,33 @@ endif
 
 PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__
 
-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
-PF_CPPFLAGS_ARM := $(call cc-option,-marm,)
+# Choose between ARM/Thumb instruction sets
+ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
+PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\
+   $(call cc-option,-marm,)\
+   $(call cc-option,-mno-thumb-interwork,)\
+   )
+else
+PF_CPPFLAGS_ARM := $(call cc-option,-marm,) \
+   $(call cc-option,-mno-thumb-interwork,)
+endif
 
 # Try if EABI is supported, else fall back to old API,
 # i. e. for example:
 # - with ELDK 4.2 (EABI supported), use:
-#  -mabi=aapcs-linux -mno-thumb-interwork
+#  -mabi=aapcs-linux
 # - with ELDK 4.1 (gcc 4.x, no EABI), use:
-#  -mabi=apcs-gnu -mno-thumb-interwork
+#  -mabi=apcs-gnu
 # - with ELDK 3.1 (gcc 3.x), use:
-#  -mapcs-32 -mno-thumb-interwork
+#  -mapcs-32
 PF_CPPFLAGS_ABI := $(call cc-option,\
-   -mabi=aapcs-linux -mno-thumb-interwork,\
+   -mabi=aapcs-linux,\
$(call cc-option,\
-mapcs-32,\
$(call cc-option,\
-mabi=apcs-gnu,\
)\
-   ) $(call cc-option,-mno-thumb-interwork,)\
+   )\
)
 PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARM) $(PF_CPPFLAGS_ABI)
 
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 4/6] armv7: Use -march=armv7-a and thereby enable Thumb-2

[Aneesh V]

Enable -march=armv7-a for armv7 platforms if the tool-chain
supports it. This in turn results in Thumb-2 code generated
for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.

Signed-off-by: Aneesh V ane...@ti.com
---
I believe armv7-a is fine for all the SoCs except Tegra2
and I see that Tegra2 is already making the necessary
exception in .../armv7/tegra2/config.mk

Let me know if any other SoC has a problem with armv7-a

Changes in V4:
- Replaced += with := for make variable that involves
  computation

Changes in V3:
- None

Changes from V1 to V2:
- None

Changes from RFC to V1:
- Enabled armv7-a from armv7/config.mk instead of from
  omap config.mk files
---
 arch/arm/cpu/armv7/config.mk |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
index 83ddf10..6d4b13c 100644
--- a/arch/arm/cpu/armv7/config.mk
+++ b/arch/arm/cpu/armv7/config.mk
@@ -22,8 +22,11 @@
 #
 PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 
-# Make ARMv5 to allow more compilers to work, even though its v7a.
-PLATFORM_CPPFLAGS += -march=armv5
+# If armv7-a is not supported by GCC fall-back to armv5, which is
+# supported by more tool-chains
+PF_CPPFLAGS_ARMV7 := $(call cc-option, -march=armv7-a, -march=armv5)
+PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARMV7)
+
 # =
 #
 # Supply options according to compiler version
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 5/6] omap4+: Avoid using __attribute__ ((__packed__))

[Aneesh V]

Avoid using __attribute__ ((__packed__)) unless it's
absolutely necessary. packed will remove alignment
requirements for the respective objects and may cause
alignment issues unless alignment is also enforced
using a pragma.

Here, these packed attributes were causing alignment
faults in Thumb build.

Signed-off-by: Aneesh V ane...@ti.com
---

Changes in v4:
- None

Changes in v3:
- Newly added
---
 arch/arm/include/asm/arch-omap4/mux_omap4.h |2 +-
 arch/arm/include/asm/arch-omap5/mux_omap5.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap4/mux_omap4.h 
b/arch/arm/include/asm/arch-omap4/mux_omap4.h
index 30bfad7..4de7c70 100644
--- a/arch/arm/include/asm/arch-omap4/mux_omap4.h
+++ b/arch/arm/include/asm/arch-omap4/mux_omap4.h
@@ -34,7 +34,7 @@ struct pad_conf_entry {
 
u16 val;
 
-} __attribute__ ((packed));
+};
 
 #ifdef CONFIG_OFF_PADCONF
 #define OFF_PD  (1  12)
diff --git a/arch/arm/include/asm/arch-omap5/mux_omap5.h 
b/arch/arm/include/asm/arch-omap5/mux_omap5.h
index b8c2185..af6874f 100644
--- a/arch/arm/include/asm/arch-omap5/mux_omap5.h
+++ b/arch/arm/include/asm/arch-omap5/mux_omap5.h
@@ -34,7 +34,7 @@ struct pad_conf_entry {
 
u16 val;
 
-} __attribute__ ((__packed__));
+};
 
 #ifdef CONFIG_OFF_PADCONF
 #define OFF_PD  (1  12)
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 6/6] OMAP4: enable Thumb build

[Aneesh V]

Signed-off-by: Aneesh V ane...@ti.com
---
Changes in v4:
- None

Changes in v3:
- None

Changes from V1 to V2:
- None

Changes from RFC to V1:
- None
---
 include/configs/omap4_common.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index a989721..01b4d6c 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -287,4 +287,6 @@
 
 #define CONFIG_SYS_ENABLE_PADS_ALL
 
+#define CONFIG_SYS_THUMB_BUILD
+
 #endif /* __CONFIG_OMAP4_COMMON_H */
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/6] arm: adapt asm/linkage.h from Linux

[Aneesh V]

On Friday 24 February 2012 05:22 AM, Mike Frysinger wrote:

On Thursday 23 February 2012 12:40:54 Aneesh V wrote:

On Thursday 23 February 2012 08:29 PM, Mike Frysinger wrote:

On Thursday 23 February 2012 09:06:01 Aneesh V wrote:

--- /dev/null
+++ b/arch/arm/include/asm/linkage.h
@@ -0,0 +1,11 @@
+#ifndef __ASM_LINKAGE_H
+#define __ASM_LINKAGE_H


needs copyright/license comment header


As Tom mentioned, I don't know whose copyright it is.


sorry, i assumed you were creating it from scratch


+#define ENDPROC(name) \
+.type name, %function; \
+END(name)


please change linux/linkage.h instead.  % should be safe for everyone.


The spec says that STT_FUNC will work for all archs. How about using
that?


i'd prefer to use %function in the common code, but i won't fight too hard.
reading gas/config/obj-elf.c seems to back up your STT_FUNC claims; it's just
that i've found @function/%function to be much more common in practice than
using STT_FUNC.  i've only see the latter in more esoteric code ...


I don't have any strong preference either. I was just trying to see if
it's documented in gcc manuals that %function works for all and I
stumbled upon STT_FUNC. I agree that %function looks more natural, but
since we are hiding it in a macro, I think it doesn't matter much
anyway. I will do it with STT_FUNC.

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] arm: add %function attribute to assembly functions

[Aneesh V]

On Monday 20 February 2012 09:38 PM, Aneesh V wrote:

On Saturday 18 February 2012 10:18 PM, Albert ARIBAUD wrote:

Hi Aneesh,



[...]


I will get back with more details on the Linaro GCC 2012.01 later.


I meant the Linaro GCC 2012.01 tool-chain problem

This is a different problem. Some of the .rodata symbols are given an
odd address although they should be aligned to at least 2-byte boundary
). In fact the data is actually put at the even address but the symbol's
value is +1 of the actual address. This is the ARM convention for Thumb
functions, but they have applied it here for data too. That's the
problem. I see that this doesn't happen to all the .rodata in SPL.
Neither could I reproduce it with a small program. But the workaround
for this problem is to avoid -fdata-sections. The following patch works
around it.

diff --git a/config.mk b/config.mk
index ddaa477..723286a 100644
--- a/config.mk
+++ b/config.mk
@@ -190,7 +190,7 @@ CPPFLAGS := $(DBGFLAGS) $(OPTFLAGS) $(RELFLAGS) \

# Enable garbage collection of un-used sections for SPL
ifeq ($(CONFIG_SPL_BUILD),y)
-CPPFLAGS += -ffunction-sections -fdata-sections
+CPPFLAGS += -ffunction-sections
LDFLAGS_FINAL += --gc-sections
endif

Will you take a patch to make -fdata-sections optional, that is, having
it under something like CONFIG_SYS_SPL_NO_FDATA_SECTIONS?


Hmm... considering you're seeing the issue in a fairly new toolchain
release, I prefer notifying the toolchain makers, rather than removing
the -fdata-sections from SPL even for specific boards. Can you go and
see why the Linaro toolchain generated odd thumb data at all and get
this fixed?


I tried investigating a bit. As I mentioned earlier it doesn't happen
with some other files that use the same compiler and linker commands.
So, I don't know what's going on. Also, I couldn't reproduce it with a
simple program unlike in the other cases. Anyway, I have notified
tool-chain folks at Linaro:

http://article.gmane.org/gmane.linux.linaro.toolchain/2096


Ulrich Weigand has identified the root-cause [1]. The problem was due
to __attribute__ ((packed)) used in a structure. Let me quote him:

**
I can reproduce the odd addresses of .rodata symbols.  However, this
occurs simply because the linker put *no* alignment requirement whatsoever
on those sections:

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg Lk
Inf Al
[snip]
  [11] .rodata.wkup_padc PROGBITS 000100 04 00   A  0
0  1
  [12] .rodata.wkup_padc PROGBITS 000104 48 00   A  0
0  1
  [13] .rodata.wkup_padc PROGBITS 00014c 0c 00   A  0
0  1
  [14] .rodata.wkup_padc PROGBITS 000158 04 00   A  0
0  1

Note the Al column values of 1.  In the final executable, those sections
happen to end up immediately following a .rodata.str string section with
odd
lenght, and since they don't have any alignment requirement, they start out
at an odd address.

The reason for the lack of alignment requirement is actually in the source:

const struct pad_conf_entry core_padconf_array_essential[] = {

where

struct pad_conf_entry {

u16 offset;

u16 val;

} __attribute__ ((packed));

The packed attribute specifies that all struct elements ought to be
considered to have alignment requirement 1 instead of their default
alignment.  Thus the whole struct ends up having alignment requirement 1;
and since the section contains only a single variable of such struct
type, this is then also the alignment requirement of the section.
**


I tried removing packed and it works. I will send an updated series
with this fix.

br,
Aneesh


[1] http://article.gmane.org/gmane.linux.linaro.toolchain/2099
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 1/5] arm: adapt asm/linkage.h from Linux

[Aneesh V]

This will add ARM specific over-rides for the defines
from linux/linkage.h

Signed-off-by: Aneesh V ane...@ti.com
---
Not adding the defines for __ALIGN and __ALIGN_STR
because it's not clear why alignment is set to 0
(single byte alignment).

Creates a checkpatch error that can not be avoided

Changes in V2:
 - Newly added
---
 arch/arm/include/asm/linkage.h |   11 +++
 include/linux/linkage.h|5 +
 2 files changed, 16 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/linkage.h

diff --git a/arch/arm/include/asm/linkage.h b/arch/arm/include/asm/linkage.h
new file mode 100644
index 000..bb2f937
--- /dev/null
+++ b/arch/arm/include/asm/linkage.h
@@ -0,0 +1,11 @@
+#ifndef __ASM_LINKAGE_H
+#define __ASM_LINKAGE_H
+
+#define __ALIGN .align 0
+#define __ALIGN_STR .align 0
+
+#define ENDPROC(name) \
+.type name, %function; \
+END(name)
+
+#endif
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index ed4cf6c..adf3762 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -44,8 +44,13 @@
 #define SYMBOL_NAME_LABEL(X)   X:
 #endif
 
+#ifndef __ALIGN
 #define __ALIGN .align 4
+#endif
+
+#ifndef __ALIGN_STR
 #define __ALIGN_STR.align 4
+#endif
 
 #ifdef __ASSEMBLY__
 
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 2/5] armv7: add appropriate headers for assembly functions

[Aneesh V]

Use ENTRY and ENDPROC with assembly functions to ensure
necessary assembler directives for all functions.

Signed-off-by: Aneesh V ane...@ti.com
---
Changes in V2:
- Newly added
---
 arch/arm/cpu/armv7/mx5/lowlevel_init.S |5 ++-
 arch/arm/cpu/armv7/mx6/lowlevel_init.S |5 ++-
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |   14 
 arch/arm/cpu/armv7/omap-common/reset.S |5 ++-
 arch/arm/cpu/armv7/omap3/lowlevel_init.S   |   41 ---
 arch/arm/cpu/armv7/s5pc1xx/cache.S |   10 +++--
 arch/arm/cpu/armv7/s5pc1xx/reset.S |5 ++-
 arch/arm/cpu/armv7/start.S |   13 ---
 arch/arm/cpu/armv7/tegra2/lowlevel_init.S  |5 ++-
 arch/arm/cpu/armv7/u8500/lowlevel.S|9 +++--
 10 files changed, 61 insertions(+), 51 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S 
b/arch/arm/cpu/armv7/mx5/lowlevel_init.S
index 01f6d75..5344410 100644
--- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S
@@ -22,6 +22,7 @@
 #include config.h
 #include asm/arch/imx-regs.h
 #include generated/asm-offsets.h
+#include linux/linkage.h
 
 /*
  * L2CC Cache setup/invalidation/disable
@@ -312,8 +313,7 @@
 
 .section .text.init, x
 
-.globl lowlevel_init
-lowlevel_init:
+ENTRY(lowlevel_init)
 #if defined(CONFIG_MX51)
ldr r0, =GPIO1_BASE_ADDR
ldr r1, [r0, #0x0]
@@ -334,6 +334,7 @@ lowlevel_init:
 
/* r12 saved upper lr*/
mov pc,lr
+ENDPROC(lowlevel_init)
 
 /* Board level setting value */
 W_DP_OP_864:  .word DP_OP_864
diff --git a/arch/arm/cpu/armv7/mx6/lowlevel_init.S 
b/arch/arm/cpu/armv7/mx6/lowlevel_init.S
index 1864356..acadef2 100644
--- a/arch/arm/cpu/armv7/mx6/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/mx6/lowlevel_init.S
@@ -18,7 +18,8 @@
  */
 .section .text.init, x
 
-.globl lowlevel_init
-lowlevel_init:
+#include linux/linkage.h
 
+ENTRY(lowlevel_init)
mov pc, lr
+ENDPROC(lowlevel_init)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S 
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 35f38ac..ccc6bb6 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -27,9 +27,9 @@
  */
 
 #include asm/arch/omap.h
+#include linux/linkage.h
 
-.global save_boot_params
-save_boot_params:
+ENTRY(save_boot_params)
/*
 * See if the rom code passed pointer is valid:
 * It is not valid if it is not in non-secure SRAM
@@ -76,10 +76,9 @@ save_boot_params:
strbr2, [r3, #CH_FLAGS_OFFSET]
 1:
bx  lr
+ENDPROC(save_boot_params)
 
-
-.globl lowlevel_init
-lowlevel_init:
+ENTRY(lowlevel_init)
/*
 * Setup a temporary stack
 */
@@ -95,12 +94,13 @@ lowlevel_init:
 */
bl  s_init
pop {ip, pc}
+ENDPROC(lowlevel_init)
 
-.globl set_pl310_ctrl_reg
-set_pl310_ctrl_reg:
+ENTRY(set_pl310_ctrl_reg)
PUSH{r4-r11, lr}@ save registers - ROM code may pollute
@ our registers
LDR r12, =0x102 @ Set PL310 control register - value in R0
.word   0xe1600070  @ SMC #0 - hand assembled because -march=armv5
@ call ROM Code API to set control register
POP {r4-r11, pc}
+ENDPROC(set_pl310_ctrl_reg)
diff --git a/arch/arm/cpu/armv7/omap-common/reset.S 
b/arch/arm/cpu/armv7/omap-common/reset.S
index 838b122..179a476 100644
--- a/arch/arm/cpu/armv7/omap-common/reset.S
+++ b/arch/arm/cpu/armv7/omap-common/reset.S
@@ -22,9 +22,9 @@
  */
 
 #include config.h
+#include linux/linkage.h
 
-.global reset_cpu
-reset_cpu:
+ENTRY(reset_cpu)
ldr r1, rstctl  @ get addr for global reset
@ reg
ldr r3, rstbit  @ sw reset bit
@@ -36,3 +36,4 @@ rstctl:
.word   PRM_RSTCTRL
 rstbit:
.word   PRM_RSTCTRL_RESET
+ENDPROC(reset_cpu)
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S 
b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index c42c5dd..ebf69fa 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -31,22 +31,22 @@
 #include version.h
 #include asm/arch/mem.h
 #include asm/arch/clocks_omap3.h
+#include linux/linkage.h
 
 _TEXT_BASE:
.word   CONFIG_SYS_TEXT_BASE/* sdram load addr from config.mk */
 
 #ifdef CONFIG_SPL_BUILD
-.global save_boot_params
-save_boot_params:
+ENTRY(save_boot_params)
ldr r4, =omap3_boot_device
ldr r5, [r0, #0x4]
and r5, r5, #0xff
str r5, [r4]
bx  lr
+ENDPROC(save_boot_params)
 #endif
 
-.global omap3_gp_romcode_call
-omap3_gp_romcode_call:
+ENTRY(omap3_gp_romcode_call)
PUSH {r4-r12, lr} @ Save all registers from ROM code!
MOV r12, r0 @ Copy the Service ID in R12
MOV r0, r1  @ Copy

[U-Boot] [PATCH v2 3/5] ARM: enable Thumb build

[Aneesh V]

Enable Thumb build and ARM-Thumb interworking based on the new
config flag CONFIG_SYS_THUMB_BUILD

Signed-off-by: Aneesh V ane...@ti.com
---
Changes from RFC to V1:
- Fixed review comments from Tom Rini tr...@ti.com

Changes from V1 to V2:
- None
---
 README |8 
 arch/arm/config.mk |   20 ++--
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/README b/README
index eba6378..1f4e2e8 100644
--- a/README
+++ b/README
@@ -426,6 +426,14 @@ The following options need to be configured:
Select high exception vectors of the ARM core, e.g., do not
clear the V bit of the c1 register of CP15.
 
+   CONFIG_SYS_THUMB_BUILD
+
+   Use this flag to build U-Boot using the Thumb instruction
+   set for ARM architectures. Thumb instruction set provides
+   better code density. For ARM architectures that support
+   Thumb2 this flag will result in Thumb2 code generated by
+   GCC.
+
 - Linux Kernel Interface:
CONFIG_CLOCKS_IN_MHZ
 
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 45f9dca..de9aa53 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -33,25 +33,33 @@ endif
 
 PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__
 
-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
+# Choose between ARM/Thumb instruction sets
+ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
+PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\
+   $(call cc-option,-marm,)\
+   $(call cc-option,-mno-thumb-interwork,)\
+   )
+else
 PF_CPPFLAGS_ARM := $(call cc-option,-marm,)
+PF_CPPFLAGS_ARM += $(call cc-option,-mno-thumb-interwork,)
+endif
 
 # Try if EABI is supported, else fall back to old API,
 # i. e. for example:
 # - with ELDK 4.2 (EABI supported), use:
-#  -mabi=aapcs-linux -mno-thumb-interwork
+#  -mabi=aapcs-linux
 # - with ELDK 4.1 (gcc 4.x, no EABI), use:
-#  -mabi=apcs-gnu -mno-thumb-interwork
+#  -mabi=apcs-gnu
 # - with ELDK 3.1 (gcc 3.x), use:
-#  -mapcs-32 -mno-thumb-interwork
+#  -mapcs-32
 PF_CPPFLAGS_ABI := $(call cc-option,\
-   -mabi=aapcs-linux -mno-thumb-interwork,\
+   -mabi=aapcs-linux,\
$(call cc-option,\
-mapcs-32,\
$(call cc-option,\
-mabi=apcs-gnu,\
)\
-   ) $(call cc-option,-mno-thumb-interwork,)\
+   )\
)
 PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARM) $(PF_CPPFLAGS_ABI)
 
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 5/5] OMAP4: enable Thumb build

[Aneesh V]

Signed-off-by: Aneesh V ane...@ti.com
---
Changes from RFC to V1:
- None

Changes from V1 to V2:
- None
---
 include/configs/omap4_common.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index a989721..01b4d6c 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -287,4 +287,6 @@
 
 #define CONFIG_SYS_ENABLE_PADS_ALL
 
+#define CONFIG_SYS_THUMB_BUILD
+
 #endif /* __CONFIG_OMAP4_COMMON_H */
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 4/5] armv7: Use -march=armv7-a and thereby enable Thumb-2

[Aneesh V]

Enable -march=armv7-a for armv7 platforms if the tool-chain
supports it. This in turn results in Thumb-2 code generated
for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.

Signed-off-by: Aneesh V ane...@ti.com
---
I believe armv7-a is fine for all the SoCs except Tegra2
and I see that Tegra2 is already making the necessary
exception in .../armv7/tegra2/config.mk

Let me know if any other SoC has a problem with armv7-a

Changes from RFC to V1:
- Enabled armv7-a from armv7/config.mk instead of from
  omap config.mk files

Changes from V1 to V2:
- None
---
 arch/arm/cpu/armv7/config.mk |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
index 83ddf10..b66fb6f 100644
--- a/arch/arm/cpu/armv7/config.mk
+++ b/arch/arm/cpu/armv7/config.mk
@@ -22,8 +22,9 @@
 #
 PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 
-# Make ARMv5 to allow more compilers to work, even though its v7a.
-PLATFORM_CPPFLAGS += -march=armv5
+# If armv7-a is not supported by GCC fall-back to armv5, which is
+# supported by more tool-chains
+PLATFORM_CPPFLAGS += $(call cc-option, -march=armv7-a, -march=armv5)
 # =
 #
 # Supply options according to compiler version
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/5] arm: adapt asm/linkage.h from Linux

[Aneesh V]

Please ignore this series. I missed sending one patch. I will send v3
shortly.

On Thursday 23 February 2012 07:09 PM, Aneesh V wrote:

This will add ARM specific over-rides for the defines
from linux/linkage.h

Signed-off-by: Aneesh Vane...@ti.com
---
Not adding the defines for __ALIGN and __ALIGN_STR
because it's not clear why alignment is set to 0
(single byte alignment).

Creates a checkpatch error that can not be avoided

Changes in V2:
  - Newly added
---
  arch/arm/include/asm/linkage.h |   11 +++
  include/linux/linkage.h|5 +
  2 files changed, 16 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/include/asm/linkage.h

diff --git a/arch/arm/include/asm/linkage.h b/arch/arm/include/asm/linkage.h
new file mode 100644
index 000..bb2f937
--- /dev/null
+++ b/arch/arm/include/asm/linkage.h
@@ -0,0 +1,11 @@
+#ifndef __ASM_LINKAGE_H
+#define __ASM_LINKAGE_H
+
+#define __ALIGN .align 0
+#define __ALIGN_STR .align 0
+
+#define ENDPROC(name) \
+.type name, %function; \
+END(name)
+
+#endif
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index ed4cf6c..adf3762 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -44,8 +44,13 @@
  #define SYMBOL_NAME_LABEL(X)  X:
  #endif

+#ifndef __ALIGN
  #define __ALIGN .align4
+#endif
+
+#ifndef __ALIGN_STR
  #define __ALIGN_STR   .align 4
+#endif

  #ifdef __ASSEMBLY__



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 1/6] arm: adapt asm/linkage.h from Linux

[Aneesh V]

This will add ARM specific over-rides for the defines
from linux/linkage.h

Signed-off-by: Aneesh V ane...@ti.com
---
Not adding the defines for __ALIGN and __ALIGN_STR
because it's not clear why alignment is set to 0
(single byte alignment).

Creates a checkpatch error that can not be avoided

Changes in V2:
 - Newly added
---
 arch/arm/include/asm/linkage.h |   11 +++
 include/linux/linkage.h|5 +
 2 files changed, 16 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/linkage.h

diff --git a/arch/arm/include/asm/linkage.h b/arch/arm/include/asm/linkage.h
new file mode 100644
index 000..bb2f937
--- /dev/null
+++ b/arch/arm/include/asm/linkage.h
@@ -0,0 +1,11 @@
+#ifndef __ASM_LINKAGE_H
+#define __ASM_LINKAGE_H
+
+#define __ALIGN .align 0
+#define __ALIGN_STR .align 0
+
+#define ENDPROC(name) \
+.type name, %function; \
+END(name)
+
+#endif
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index ed4cf6c..adf3762 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -44,8 +44,13 @@
 #define SYMBOL_NAME_LABEL(X)   X:
 #endif
 
+#ifndef __ALIGN
 #define __ALIGN .align 4
+#endif
+
+#ifndef __ALIGN_STR
 #define __ALIGN_STR.align 4
+#endif
 
 #ifdef __ASSEMBLY__
 
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 2/6] armv7: add appropriate headers for assembly functions

[Aneesh V]

Use ENTRY and ENDPROC with assembly functions to ensure
necessary assembler directives for all functions.

Signed-off-by: Aneesh V ane...@ti.com
---
Changes in V2:
- Newly added
---
 arch/arm/cpu/armv7/mx5/lowlevel_init.S |5 ++-
 arch/arm/cpu/armv7/mx6/lowlevel_init.S |5 ++-
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |   14 
 arch/arm/cpu/armv7/omap-common/reset.S |5 ++-
 arch/arm/cpu/armv7/omap3/lowlevel_init.S   |   41 ---
 arch/arm/cpu/armv7/s5pc1xx/cache.S |   10 +++--
 arch/arm/cpu/armv7/s5pc1xx/reset.S |5 ++-
 arch/arm/cpu/armv7/start.S |   13 ---
 arch/arm/cpu/armv7/tegra2/lowlevel_init.S  |5 ++-
 arch/arm/cpu/armv7/u8500/lowlevel.S|9 +++--
 10 files changed, 61 insertions(+), 51 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S 
b/arch/arm/cpu/armv7/mx5/lowlevel_init.S
index 01f6d75..5344410 100644
--- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S
@@ -22,6 +22,7 @@
 #include config.h
 #include asm/arch/imx-regs.h
 #include generated/asm-offsets.h
+#include linux/linkage.h
 
 /*
  * L2CC Cache setup/invalidation/disable
@@ -312,8 +313,7 @@
 
 .section .text.init, x
 
-.globl lowlevel_init
-lowlevel_init:
+ENTRY(lowlevel_init)
 #if defined(CONFIG_MX51)
ldr r0, =GPIO1_BASE_ADDR
ldr r1, [r0, #0x0]
@@ -334,6 +334,7 @@ lowlevel_init:
 
/* r12 saved upper lr*/
mov pc,lr
+ENDPROC(lowlevel_init)
 
 /* Board level setting value */
 W_DP_OP_864:  .word DP_OP_864
diff --git a/arch/arm/cpu/armv7/mx6/lowlevel_init.S 
b/arch/arm/cpu/armv7/mx6/lowlevel_init.S
index 1864356..acadef2 100644
--- a/arch/arm/cpu/armv7/mx6/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/mx6/lowlevel_init.S
@@ -18,7 +18,8 @@
  */
 .section .text.init, x
 
-.globl lowlevel_init
-lowlevel_init:
+#include linux/linkage.h
 
+ENTRY(lowlevel_init)
mov pc, lr
+ENDPROC(lowlevel_init)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S 
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 35f38ac..ccc6bb6 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -27,9 +27,9 @@
  */
 
 #include asm/arch/omap.h
+#include linux/linkage.h
 
-.global save_boot_params
-save_boot_params:
+ENTRY(save_boot_params)
/*
 * See if the rom code passed pointer is valid:
 * It is not valid if it is not in non-secure SRAM
@@ -76,10 +76,9 @@ save_boot_params:
strbr2, [r3, #CH_FLAGS_OFFSET]
 1:
bx  lr
+ENDPROC(save_boot_params)
 
-
-.globl lowlevel_init
-lowlevel_init:
+ENTRY(lowlevel_init)
/*
 * Setup a temporary stack
 */
@@ -95,12 +94,13 @@ lowlevel_init:
 */
bl  s_init
pop {ip, pc}
+ENDPROC(lowlevel_init)
 
-.globl set_pl310_ctrl_reg
-set_pl310_ctrl_reg:
+ENTRY(set_pl310_ctrl_reg)
PUSH{r4-r11, lr}@ save registers - ROM code may pollute
@ our registers
LDR r12, =0x102 @ Set PL310 control register - value in R0
.word   0xe1600070  @ SMC #0 - hand assembled because -march=armv5
@ call ROM Code API to set control register
POP {r4-r11, pc}
+ENDPROC(set_pl310_ctrl_reg)
diff --git a/arch/arm/cpu/armv7/omap-common/reset.S 
b/arch/arm/cpu/armv7/omap-common/reset.S
index 838b122..179a476 100644
--- a/arch/arm/cpu/armv7/omap-common/reset.S
+++ b/arch/arm/cpu/armv7/omap-common/reset.S
@@ -22,9 +22,9 @@
  */
 
 #include config.h
+#include linux/linkage.h
 
-.global reset_cpu
-reset_cpu:
+ENTRY(reset_cpu)
ldr r1, rstctl  @ get addr for global reset
@ reg
ldr r3, rstbit  @ sw reset bit
@@ -36,3 +36,4 @@ rstctl:
.word   PRM_RSTCTRL
 rstbit:
.word   PRM_RSTCTRL_RESET
+ENDPROC(reset_cpu)
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S 
b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index c42c5dd..ebf69fa 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -31,22 +31,22 @@
 #include version.h
 #include asm/arch/mem.h
 #include asm/arch/clocks_omap3.h
+#include linux/linkage.h
 
 _TEXT_BASE:
.word   CONFIG_SYS_TEXT_BASE/* sdram load addr from config.mk */
 
 #ifdef CONFIG_SPL_BUILD
-.global save_boot_params
-save_boot_params:
+ENTRY(save_boot_params)
ldr r4, =omap3_boot_device
ldr r5, [r0, #0x4]
and r5, r5, #0xff
str r5, [r4]
bx  lr
+ENDPROC(save_boot_params)
 #endif
 
-.global omap3_gp_romcode_call
-omap3_gp_romcode_call:
+ENTRY(omap3_gp_romcode_call)
PUSH {r4-r12, lr} @ Save all registers from ROM code!
MOV r12, r0 @ Copy the Service ID in R12
MOV r0, r1  @ Copy

[U-Boot] [PATCH v3 3/6] ARM: enable Thumb build

[Aneesh V]

Enable Thumb build and ARM-Thumb interworking based on the new
config flag CONFIG_SYS_THUMB_BUILD

Signed-off-by: Aneesh V ane...@ti.com
---
Changes from RFC to V1:
- Fixed review comments from Tom Rini tr...@ti.com

Changes from V1 to V2:
- None
---
 README |8 
 arch/arm/config.mk |   20 ++--
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/README b/README
index eba6378..1f4e2e8 100644
--- a/README
+++ b/README
@@ -426,6 +426,14 @@ The following options need to be configured:
Select high exception vectors of the ARM core, e.g., do not
clear the V bit of the c1 register of CP15.
 
+   CONFIG_SYS_THUMB_BUILD
+
+   Use this flag to build U-Boot using the Thumb instruction
+   set for ARM architectures. Thumb instruction set provides
+   better code density. For ARM architectures that support
+   Thumb2 this flag will result in Thumb2 code generated by
+   GCC.
+
 - Linux Kernel Interface:
CONFIG_CLOCKS_IN_MHZ
 
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 45f9dca..de9aa53 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -33,25 +33,33 @@ endif
 
 PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__
 
-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
+# Choose between ARM/Thumb instruction sets
+ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
+PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\
+   $(call cc-option,-marm,)\
+   $(call cc-option,-mno-thumb-interwork,)\
+   )
+else
 PF_CPPFLAGS_ARM := $(call cc-option,-marm,)
+PF_CPPFLAGS_ARM += $(call cc-option,-mno-thumb-interwork,)
+endif
 
 # Try if EABI is supported, else fall back to old API,
 # i. e. for example:
 # - with ELDK 4.2 (EABI supported), use:
-#  -mabi=aapcs-linux -mno-thumb-interwork
+#  -mabi=aapcs-linux
 # - with ELDK 4.1 (gcc 4.x, no EABI), use:
-#  -mabi=apcs-gnu -mno-thumb-interwork
+#  -mabi=apcs-gnu
 # - with ELDK 3.1 (gcc 3.x), use:
-#  -mapcs-32 -mno-thumb-interwork
+#  -mapcs-32
 PF_CPPFLAGS_ABI := $(call cc-option,\
-   -mabi=aapcs-linux -mno-thumb-interwork,\
+   -mabi=aapcs-linux,\
$(call cc-option,\
-mapcs-32,\
$(call cc-option,\
-mabi=apcs-gnu,\
)\
-   ) $(call cc-option,-mno-thumb-interwork,)\
+   )\
)
 PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARM) $(PF_CPPFLAGS_ABI)
 
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 4/6] armv7: Use -march=armv7-a and thereby enable Thumb-2

[Aneesh V]

Enable -march=armv7-a for armv7 platforms if the tool-chain
supports it. This in turn results in Thumb-2 code generated
for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.

Signed-off-by: Aneesh V ane...@ti.com
---
I believe armv7-a is fine for all the SoCs except Tegra2
and I see that Tegra2 is already making the necessary
exception in .../armv7/tegra2/config.mk

Let me know if any other SoC has a problem with armv7-a

Changes from RFC to V1:
- Enabled armv7-a from armv7/config.mk instead of from
  omap config.mk files

Changes from V1 to V2:
- None
---
 arch/arm/cpu/armv7/config.mk |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
index 83ddf10..b66fb6f 100644
--- a/arch/arm/cpu/armv7/config.mk
+++ b/arch/arm/cpu/armv7/config.mk
@@ -22,8 +22,9 @@
 #
 PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 
-# Make ARMv5 to allow more compilers to work, even though its v7a.
-PLATFORM_CPPFLAGS += -march=armv5
+# If armv7-a is not supported by GCC fall-back to armv5, which is
+# supported by more tool-chains
+PLATFORM_CPPFLAGS += $(call cc-option, -march=armv7-a, -march=armv5)
 # =
 #
 # Supply options according to compiler version
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 5/6] omap4+: Avoid using __attribute__ ((__packed__))

[Aneesh V]

Avoid using __attribute__ ((__packed__)) unless it's
absolutely necessary. packed will remove alignment
requirements for the respective objects and may cause
alignment issues unless alignment is also enforced
using a pragma.

Here, these packed attributes were causing alignment
faults in Thumb build.

Signed-off-by: Aneesh V ane...@ti.com
---
 arch/arm/include/asm/arch-omap4/mux_omap4.h |2 +-
 arch/arm/include/asm/arch-omap5/mux_omap5.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap4/mux_omap4.h 
b/arch/arm/include/asm/arch-omap4/mux_omap4.h
index 30bfad7..4de7c70 100644
--- a/arch/arm/include/asm/arch-omap4/mux_omap4.h
+++ b/arch/arm/include/asm/arch-omap4/mux_omap4.h
@@ -34,7 +34,7 @@ struct pad_conf_entry {
 
u16 val;
 
-} __attribute__ ((packed));
+};
 
 #ifdef CONFIG_OFF_PADCONF
 #define OFF_PD  (1  12)
diff --git a/arch/arm/include/asm/arch-omap5/mux_omap5.h 
b/arch/arm/include/asm/arch-omap5/mux_omap5.h
index b8c2185..af6874f 100644
--- a/arch/arm/include/asm/arch-omap5/mux_omap5.h
+++ b/arch/arm/include/asm/arch-omap5/mux_omap5.h
@@ -34,7 +34,7 @@ struct pad_conf_entry {
 
u16 val;
 
-} __attribute__ ((__packed__));
+};
 
 #ifdef CONFIG_OFF_PADCONF
 #define OFF_PD  (1  12)
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 6/6] OMAP4: enable Thumb build

[Aneesh V]

Signed-off-by: Aneesh V ane...@ti.com
---
Changes from RFC to V1:
- None

Changes from V1 to V2:
- None
---
 include/configs/omap4_common.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index a989721..01b4d6c 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -287,4 +287,6 @@
 
 #define CONFIG_SYS_ENABLE_PADS_ALL
 
+#define CONFIG_SYS_THUMB_BUILD
+
 #endif /* __CONFIG_OMAP4_COMMON_H */
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 5/6] omap4+: Avoid using __attribute__ ((__packed__))

[Aneesh V]

On Thursday 23 February 2012 07:51 PM, Tom Rini wrote:

On Thu, Feb 23, 2012 at 7:06 AM, Aneesh Vane...@ti.com  wrote:

Avoid using __attribute__ ((__packed__)) unless it's
absolutely necessary. packed will remove alignment
requirements for the respective objects and may cause
alignment issues unless alignment is also enforced
using a pragma.

Here, these packed attributes were causing alignment
faults in Thumb build.

Signed-off-by: Aneesh Vane...@ti.com


Why did we pack these to start with?  Otherwise seems fine (and I see
the rest of the TI parts don't have this particular packing).



I think that was to save some space - to make sure that the compiler
didn't pad the structure to have the u16 fields at word boundary. But
even without packed the complier is not padding it. I checked that
today, the size of the mux arrays remain the same even after removing
the packed. So, I guess the packed didn't have any impact.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 5/6] omap4+: Avoid using __attribute__ ((__packed__))

[Aneesh V]

On Thursday 23 February 2012 08:33 PM, Mike Frysinger wrote:

On Thursday 23 February 2012 09:21:00 Tom Rini wrote:

On Thu, Feb 23, 2012 at 7:06 AM, Aneesh Vane...@ti.com  wrote:

Avoid using __attribute__ ((__packed__)) unless it's
absolutely necessary. packed will remove alignment
requirements for the respective objects and may cause
alignment issues unless alignment is also enforced
using a pragma.

Here, these packed attributes were causing alignment
faults in Thumb build.


Why did we pack these to start with?  Otherwise seems fine (and I see
the rest of the TI parts don't have this particular packing).


because these represent hardware register blocks which get used with writew()
and typically those blocks get marked packed.


No. That's not the case. This is just a table that has the mux data for
the board. It's not directly mapped to hardware. The hardware register
offset is part of this table.



if the arch won't introduce padding with the members, then this change should
be ok, and looking at the structs which are just 2 16bit members, that should
be the case here.

if you really want to be pedantic, i think the alternative would be:
struct pad_conf_entry {} __packed __aligned(2);


I had tried that and it had solved the problem too, but the packed is
not needed at all. That's purely a software table.

regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/5] ARM: enable Thumb build

[Aneesh V]

On Thursday 23 February 2012 08:27 PM, Mike Frysinger wrote:

On Thursday 23 February 2012 08:39:43 Aneesh V wrote:

--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk

-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be
-mthumb: +# Choose between ARM/Thumb instruction sets
+ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
+PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\
+   $(call cc-option,-marm,)\
+   $(call cc-option,-mno-thumb-interwork,)\
+   )
+else
  PF_CPPFLAGS_ARM := $(call cc-option,-marm,)
+PF_CPPFLAGS_ARM += $(call cc-option,-mno-thumb-interwork,)


this 2nd part is no good.  += is not the same thing as :=.


I don't understand the difference. '+=' is done after ':=' right?



might be simpler to do:
PF_CPPFLAGS_MARM := $(call cc-option,-marm)
PF_CPPFLAGS_THUMB := $(call cc-option,-mthumb -mthumb-interwork)
PF_CPPFLAGS_NO_THUMB := $(call cc-option,-mno-thumb-interwork)

ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
PF_CPPFLAGS_ARM = $(PF_CPPFLAGS_THUMB)
else
PF_CPPFLAGS_ARM = $(PF_CPPFLAGS_MARM) $(PF_CPPFLAGS_NO_THUMB)
endif
-mike


Are you trying to avoid all '+='. If so, why?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/6] arm: adapt asm/linkage.h from Linux

[Aneesh V]

On Thursday 23 February 2012 08:29 PM, Mike Frysinger wrote:

On Thursday 23 February 2012 09:06:01 Aneesh V wrote:

--- /dev/null
+++ b/arch/arm/include/asm/linkage.h
@@ -0,0 +1,11 @@
+#ifndef __ASM_LINKAGE_H
+#define __ASM_LINKAGE_H


needs copyright/license comment header


As Tom mentioned, I don't know whose copyright it is.




+#define ENDPROC(name) \
+.type name, %function; \
+END(name)


please change linux/linkage.h instead.  % should be safe for everyone.


The spec says that STT_FUNC will work for all archs. How about using
that?

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/5] ARM: enable Thumb build

[Aneesh V]

On Thursday 23 February 2012 11:04 PM, Tom Rini wrote:

On Thu, Feb 23, 2012 at 10:58:36PM +0530, Aneesh V wrote:

On Thursday 23 February 2012 08:27 PM, Mike Frysinger wrote:

On Thursday 23 February 2012 08:39:43 Aneesh V wrote:

--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk

-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be
-mthumb: +# Choose between ARM/Thumb instruction sets
+ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
+PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\
+   $(call cc-option,-marm,)\
+   $(call cc-option,-mno-thumb-interwork,)\
+   )
+else
  PF_CPPFLAGS_ARM := $(call cc-option,-marm,)
+PF_CPPFLAGS_ARM += $(call cc-option,-mno-thumb-interwork,)


this 2nd part is no good.  += is not the same thing as :=.


I don't understand the difference. '+=' is done after ':=' right?


'+=' is evaluated every file we build, ':=' is evaluated once.  We use
the latter to keep build times down.



Ok. so, are we trying to reduce the number of +=, right?

Thanks for clarifying.

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 4/6] armv7: Use -march=armv7-a and thereby enable Thumb-2

[Aneesh V]

On Thursday 23 February 2012 08:35 PM, Mike Frysinger wrote:

On Thursday 23 February 2012 09:06:04 Aneesh V wrote:

--- a/arch/arm/cpu/armv7/config.mk
+++ b/arch/arm/cpu/armv7/config.mk

-# Make ARMv5 to allow more compilers to work, even though its v7a.
-PLATFORM_CPPFLAGS += -march=armv5
+# If armv7-a is not supported by GCC fall-back to armv5, which is
+# supported by more tool-chains
+PLATFORM_CPPFLAGS += $(call cc-option, -march=armv7-a, -march=armv5)


NAK: you need to use := before +=:
PF_CPPFLAGS_MARCH := $(call cc-option, -march=armv7-a, -march=armv5)
PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_MARCH)


Will do.

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/5] ARM: enable Thumb build

[Aneesh V]

On Thursday 23 February 2012 11:21 PM, Tom Rini wrote:

On Thu, Feb 23, 2012 at 11:19:59PM +0530, Aneesh V wrote:

On Thursday 23 February 2012 11:04 PM, Tom Rini wrote:

On Thu, Feb 23, 2012 at 10:58:36PM +0530, Aneesh V wrote:

On Thursday 23 February 2012 08:27 PM, Mike Frysinger wrote:

On Thursday 23 February 2012 08:39:43 Aneesh V wrote:

--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk

-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be
-mthumb: +# Choose between ARM/Thumb instruction sets
+ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
+PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\
+   $(call cc-option,-marm,)\
+   $(call cc-option,-mno-thumb-interwork,)\
+   )
+else
  PF_CPPFLAGS_ARM := $(call cc-option,-marm,)
+PF_CPPFLAGS_ARM += $(call cc-option,-mno-thumb-interwork,)


this 2nd part is no good.  += is not the same thing as :=.


I don't understand the difference. '+=' is done after ':=' right?


'+=' is evaluated every file we build, ':=' is evaluated once.  We use
the latter to keep build times down.



Ok. so, are we trying to reduce the number of +=, right?


Yes, it should already be at or near 0 uses.


We need at least one for finally appending to the exported variable,
right. So, looks like one += for adding '-mthumb -mthumb-interwork'
together is better than having one each for the two options? Is that
the logic?

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/5] ARM: enable Thumb build

[Aneesh V]

On Thursday 23 February 2012 11:34 PM, Mike Frysinger wrote:

On Thursday 23 February 2012 12:28:36 Aneesh V wrote:

On Thursday 23 February 2012 08:27 PM, Mike Frysinger wrote:

On Thursday 23 February 2012 08:39:43 Aneesh V wrote:

--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk

-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be
-mthumb: +# Choose between ARM/Thumb instruction sets
+ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
+PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\
+   $(call cc-option,-marm,)\
+   $(call cc-option,-mno-thumb-interwork,)\
+   )
+else

   PF_CPPFLAGS_ARM := $(call cc-option,-marm,)

+PF_CPPFLAGS_ARM += $(call cc-option,-mno-thumb-interwork,)


this 2nd part is no good.  += is not the same thing as :=.


I don't understand the difference. '+=' is done after ':=' right?


might be simpler to do:
PF_CPPFLAGS_MARM := $(call cc-option,-marm)
PF_CPPFLAGS_THUMB := $(call cc-option,-mthumb -mthumb-interwork)
PF_CPPFLAGS_NO_THUMB := $(call cc-option,-mno-thumb-interwork)

ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
PF_CPPFLAGS_ARM = $(PF_CPPFLAGS_THUMB)
else
PF_CPPFLAGS_ARM = $(PF_CPPFLAGS_MARM) $(PF_CPPFLAGS_NO_THUMB)
endif


Are you trying to avoid all '+='. If so, why?


+= does delayed evaluation and is the whole reason we started using := in
makefiles for *computed* values

when you do:
FOO := $(call cc-option,-marm)
you're storing the result of the computation in $(FOO)

if you do:
FOO += $(call cc-option,-marm)
you're appending $(call cc-option,-marm) to $(FOO) and that won't actually
get computed until $(FOO) gets used

so if you append $(call ...) to $(CPPFLAGS), then you end up doing the cc-
option computation every time you compile a file that uses $(CPPFLAGS)


Get it. Thanks for explaining. I missed the computation part.

br,
Aneesh



-mike


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/5] ARM: enable Thumb build

[Aneesh V]

On Thursday 23 February 2012 11:39 PM, Aneesh V wrote:

On Thursday 23 February 2012 11:21 PM, Tom Rini wrote:

On Thu, Feb 23, 2012 at 11:19:59PM +0530, Aneesh V wrote:

On Thursday 23 February 2012 11:04 PM, Tom Rini wrote:

On Thu, Feb 23, 2012 at 10:58:36PM +0530, Aneesh V wrote:

On Thursday 23 February 2012 08:27 PM, Mike Frysinger wrote:

On Thursday 23 February 2012 08:39:43 Aneesh V wrote:

--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk

-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be
-mthumb: +# Choose between ARM/Thumb instruction sets
+ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
+PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\
+ $(call cc-option,-marm,)\
+ $(call cc-option,-mno-thumb-interwork,)\
+ )
+else
PF_CPPFLAGS_ARM := $(call cc-option,-marm,)
+PF_CPPFLAGS_ARM += $(call cc-option,-mno-thumb-interwork,)


this 2nd part is no good. += is not the same thing as :=.


I don't understand the difference. '+=' is done after ':=' right?


'+=' is evaluated every file we build, ':=' is evaluated once. We use
the latter to keep build times down.



Ok. so, are we trying to reduce the number of +=, right?


Yes, it should already be at or near 0 uses.


We need at least one for finally appending to the exported variable,
right. So, looks like one += for adding '-mthumb -mthumb-interwork'
together is better than having one each for the two options? Is that
the logic?



Please ignore this question. It's clear to me now with Mike's latest 
explanation. Thanks.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] arm: add %function attribute to assembly functions

[Aneesh V]

On Tuesday 21 February 2012 09:12 PM, Mike Frysinger wrote:

On Tuesday 21 February 2012 09:33:31 Tom Rini wrote:

On Mon, Feb 20, 2012 at 11:19:14PM -0500, Mike Frysinger wrote:

On Monday 20 February 2012 16:53:40 Simon Glass wrote:

On Mon, Feb 20, 2012 at 12:07 PM, Tom Rini wrote:

On Sun, Feb 19, 2012 at 02:15:30AM -0500, Mike Frysinger wrote:

On Saturday 18 February 2012 17:03:59 Simon Glass wrote:

On Wed, Feb 15, 2012 at 5:57 AM, Aneesh V wrote:

-.globl reset_cpu
+.type  reset_cpu, %function
+.globalreset_cpu


Should we introduce a macro to deal with this rather than writing
it out each time? EXPORT()?


we have it already with the linux/linkage.h header :)


Well, unless my tree is out of date (or stuff is in-flight) we don't
have the full compliment here.  We havelinux/linkage.h  for all and
asm/linkage.h  for bfin.  That said, yes, we should grab at least
the ARM version and make use of ENTRY/END_FUNC ala the kernel.  I'm
behind on my convert __attribute__((...)) to __attr series already
or I'd say more :)


In case one of you is going to look at this, can we try to use
asm-generic as much as possible?


i don't know what you mean ... we already have linux/linkage.h with
sane defaults for pretty much everyone.  the Blackfin asm/linkage.h is
an empty file to satisfy building.


Well, the kernel version for blackfin sets ALIGN/ALIGN_STR, so are they
out of sync?


the overall linkage.h concept is the same, but we've unified things better in
the u-boot code.  Linux's common linkage.h has x86-centric defaults which we
specifically avoided in the u-boot version.

we might want to tweak the ENDPROC() in u-boot's linkage.h to use % rather
than @ since the latter is a comment char in arm asm and the former should
work for all the arches i know of just the same as @.  i expect the arm guys
to submit a patch though at the same time they add a stub asm/linkage.h ;).


I was planning to do that in the next revision of this series. BTW, I
guess the following in the arm linkage.h of kernel is useful too. Any
thoughts?

#define __ALIGN .align 0
#define __ALIGN_STR .align 0

BTW, I am not volunteering to convert all the assembly functions in ARM
to the new format:) I shall do it for armv7.

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] arm: add %function attribute to assembly functions

[Aneesh V]

On Wednesday 22 February 2012 12:58 AM, Mike Frysinger wrote:

On Tuesday 21 February 2012 13:03:55 Aneesh V wrote:

I was planning to do that in the next revision of this series. BTW, I
guess the following in the arm linkage.h of kernel is useful too. Any
thoughts?

#define __ALIGN .align 0
#define __ALIGN_STR .align 0


arm allows unaligned instruction execution ?  i would have thought it'd
require higher alignment than that.  i don't think that'd be a good default
for everyone ...


Unaligned instruction execution - No. ARM instruction should be 4 byte
aligned and Thumb instruction should be 2 byte aligned.

Unaligned data access - to a certain extent yes and is programmable.
IIRC, access to 32 bit integer is possible at 2 byte boundary but not
at an odd address.

Yes, I was also a little puzzled by that one.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] arm: add %function attribute to assembly functions

[Aneesh V]

On Saturday 18 February 2012 10:18 PM, Albert ARIBAUD wrote:

Hi Aneesh,



[...]


I will get back with more details on the Linaro GCC 2012.01 later.


I meant the Linaro GCC 2012.01 tool-chain problem

This is a different problem. Some of the .rodata symbols are given an
odd address although they should be aligned to at least 2-byte boundary
). In fact the data is actually put at the even address but the symbol's
value is +1 of the actual address. This is the ARM convention for Thumb
functions, but they have applied it here for data too. That's the
problem. I see that this doesn't happen to all the .rodata in SPL.
Neither could I reproduce it with a small program. But the workaround
for this problem is to avoid -fdata-sections. The following patch works
around it.

diff --git a/config.mk b/config.mk
index ddaa477..723286a 100644
--- a/config.mk
+++ b/config.mk
@@ -190,7 +190,7 @@ CPPFLAGS := $(DBGFLAGS) $(OPTFLAGS) $(RELFLAGS) \

# Enable garbage collection of un-used sections for SPL
ifeq ($(CONFIG_SPL_BUILD),y)
-CPPFLAGS += -ffunction-sections -fdata-sections
+CPPFLAGS += -ffunction-sections
LDFLAGS_FINAL += --gc-sections
endif

Will you take a patch to make -fdata-sections optional, that is, having
it under something like CONFIG_SYS_SPL_NO_FDATA_SECTIONS?


Hmm... considering you're seeing the issue in a fairly new toolchain
release, I prefer notifying the toolchain makers, rather than removing
the -fdata-sections from SPL even for specific boards. Can you go and
see why the Linaro toolchain generated odd thumb data at all and get
this fixed?


I tried investigating a bit. As I mentioned earlier it doesn't happen
with some other files that use the same compiler and linker commands.
So, I don't know what's going on. Also, I couldn't reproduce it with a
simple program unlike in the other cases. Anyway, I have notified
tool-chain folks at Linaro:

http://article.gmane.org/gmane.linux.linaro.toolchain/2096

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] arm: add %function attribute to assembly functions

[Aneesh V]

On Friday 17 February 2012 10:43 PM, Mike Frysinger wrote:

On Wednesday 15 February 2012 08:57:31 Aneesh V wrote:

This is done using the following directive preceding
each function definition:

.typefunc-name, %function

This marks the symbol as a function in the object
header which in turn helps the linker in some cases.

In particular this was found needed for resolving ARM/Thumb
calls correctly in a build with Thumb interworking enabled.


ideally arm would use the new linkage.h header and then these would change to
doing what Linux does:
ENTRY(foo)
asm
ENDPROC(foo)


Thanks for the info. So, what do you suggest? Fix only the problematic
function and leave the rest to be converted to the above form later?

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] arm: add %function attribute to assembly functions

[Aneesh V]

Hi Albert,

On Saturday 18 February 2012 03:43 PM, Albert ARIBAUD wrote:

Hi Aneesh,

Le 17/02/2012 12:09, Aneesh V a écrit :

Hi Albert,

On Wednesday 15 February 2012 07:27 PM, Aneesh V wrote:

This is done using the following directive preceding
each function definition:

.typefunc-name, %function

This marks the symbol as a function in the object
header which in turn helps the linker in some cases.

In particular this was found needed for resolving ARM/Thumb
calls correctly in a build with Thumb interworking enabled.

This solves the following problem I had reported earlier:

When U-Boot/SPL is built using the Thumb instruction set the
toolchain has a potential issue with weakly linked symbols.
If a function has a weakly linked default implementation in C
and a real implementation in assembly GCC is confused about the
instruction set of the assembly implementation. As a result
the assembly function that is built in ARM is executed as
if it is Thumb. This results in a crash

Signed-off-by: Aneesh Vane...@ti.com


Does this look good to you. I was a bit nervous about touching so many
files. Please let me know if you would prefer to change only the OMAP
function that was creating the ARM/Thumb problem. I did a MAKEALL -a
arm and didn't see any new errors.

Let me know if this is an acceptable solution to the problem.


Regarding the solution: it is quite ok to me. I would just like to
understand the exact effect of the .function directive, what its options
are and if some of these should not be explicitly specified.

Regarding touching many files: I won't be worried as long as you check
that the first three patches have no effect on existing boards. This can
be verified as follows -- if you haven't done so already:

- build your OMAP target without the patch set and do a hex dump of
u-boot.bin;

- apply the first three patches of your set, rebuild your OMAP target
without the patch set and do a hex dump of u-boot.bin;

- compare both dumps. Normally you should only see one difference, in
the build version and date -- if .function does not actually alter the
assembly code, which I hope it indeed does not when building for ARM.

If there are more changes than build version and date, then they might
be due to .function requiring some yet unknown additional option, or to
some change in patch 1 or 3 not being completely conditioned on
CONFIG_SYS_THUMB_BUILD.


I can reproduce the problem with a simple test program.
Note: I can reproduce this with Sourcery G++ Lite 2010q1-202 (GCC 4.4.1
- Binutils 2.19.51.20090709)
But I *can not* reproduce reproduce this with Linaro GCC 2012.01 (GCC
4.6.3 , Binutils 2.22)
So apparently the issue has been fixed recently. Unfortunately Linaro
GCC 2012.01 creates a new Thumb problem that I am investigating now.
Somehow I missed this when I tested earlier. So, my Thumb build is
not working with Linaro GCC 2012.01. But this one is not reproduced on
Sourcery G++ Lite 2010q1-202!

Here is the program I used to reproduce the problem in Sourcery G++
Lite 2010q1-202 that this patch is addressing

a.c:

extern void foo (void) __attribute__ ((weak, alias (__foo)));

void __foo (void)
{
}

extern void call_foo(void);

int main (void)
{
  call_foo ();
}

b.S:

.text
.align  2
.global foo
foo:
push{r7}
add r7, sp, #0
mov sp, r7
pop {r7}
bx  lr
.size   foo, .-foo


c.S:

.text
.align  2

.global call_foo
call_foo:
bl  foo
bx  lr

.global __aeabi_unwind_cpp_pr0
__aeabi_unwind_cpp_pr0:
bx  lr

Now build it and take the assembly dump using the following commands:

arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c a.c
arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c b.S
arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c c.S
arm-none-linux-gnueabi-ld -r a.o -o alib.o
arm-none-linux-gnueabi-ld -r b.o -o blib.o
arm-none-linux-gnueabi-ld -r c.o -o clib.o
arm-none-linux-gnueabi-ld --start-group clib.o  alib.o blib.o 
--end-group -o a.out

arm-none-linux-gnueabi-objdump -S --reloc a.out

You will get something like this in the assembly dump:
8094 call_foo:
8094:   fa06blx 80b4 foo
8098:   e12fff1ebx  lr

The blx is wrong as we are jumping to an ARM function from ARM.

Now if you change b.S like this:

 .text
 .align  2
+.type foo, %function
 .global foo
 foo:
push{r7}


And compile it again in the same way you will see:
8094 call_foo:
8094:   eb06bl  80b4 foo
8098:   e12fff1ebx  lr

Please note that the branch to foo is correct now.

I hope this convinces you that %function indeed has an effect.

I will get back with more details on the Linaro GCC 2012.01 later.

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] arm: add %function attribute to assembly functions

[Aneesh V]

On Saturday 18 February 2012 06:54 PM, Aneesh V wrote:

Hi Albert,

On Saturday 18 February 2012 03:43 PM, Albert ARIBAUD wrote:

Hi Aneesh,

Le 17/02/2012 12:09, Aneesh V a écrit :

Hi Albert,

On Wednesday 15 February 2012 07:27 PM, Aneesh V wrote:

This is done using the following directive preceding
each function definition:

.typefunc-name, %function

This marks the symbol as a function in the object
header which in turn helps the linker in some cases.

In particular this was found needed for resolving ARM/Thumb
calls correctly in a build with Thumb interworking enabled.

This solves the following problem I had reported earlier:

When U-Boot/SPL is built using the Thumb instruction set the
toolchain has a potential issue with weakly linked symbols.
If a function has a weakly linked default implementation in C
and a real implementation in assembly GCC is confused about the
instruction set of the assembly implementation. As a result
the assembly function that is built in ARM is executed as
if it is Thumb. This results in a crash

Signed-off-by: Aneesh Vane...@ti.com


Does this look good to you. I was a bit nervous about touching so many
files. Please let me know if you would prefer to change only the OMAP
function that was creating the ARM/Thumb problem. I did a MAKEALL -a
arm and didn't see any new errors.

Let me know if this is an acceptable solution to the problem.


Regarding the solution: it is quite ok to me. I would just like to
understand the exact effect of the .function directive, what its options
are and if some of these should not be explicitly specified.

Regarding touching many files: I won't be worried as long as you check
that the first three patches have no effect on existing boards. This can
be verified as follows -- if you haven't done so already:

- build your OMAP target without the patch set and do a hex dump of
u-boot.bin;

- apply the first three patches of your set, rebuild your OMAP target
without the patch set and do a hex dump of u-boot.bin;

- compare both dumps. Normally you should only see one difference, in
the build version and date -- if .function does not actually alter the
assembly code, which I hope it indeed does not when building for ARM.

If there are more changes than build version and date, then they might
be due to .function requiring some yet unknown additional option, or to
some change in patch 1 or 3 not being completely conditioned on
CONFIG_SYS_THUMB_BUILD.


I can reproduce the problem with a simple test program.
Note: I can reproduce this with Sourcery G++ Lite 2010q1-202 (GCC 4.4.1
- Binutils 2.19.51.20090709)
But I *can not* reproduce reproduce this with Linaro GCC 2012.01 (GCC
4.6.3 , Binutils 2.22)


Linaro GCC 2012.01 has the same problem when assembly function(ARM is
called from C (Thumb). I can reproduce it using this program:

a.c:

int main (void)
{
  foo ();
}

b.S:

.text
.align  2
.global foo
foo:
push{r7}
add r7, sp, #0
mov sp, r7
pop {r7}
bx  lr
.size   foo, .-foo

.global __aeabi_unwind_cpp_pr0
__aeabi_unwind_cpp_pr0:
bx  lr

arm-linux-gnueabi-gcc -mthumb -mthumb-interwork -c a.c
arm-linux-gnueabi-gcc -mthumb -mthumb-interwork -c b.S
arm-linux-gnueabi-ld -r a.o -o alib.o
arm-linux-gnueabi-ld -r b.o -o blib.o
arm-linux-gnueabi-ld --start-group alib.o blib.o --end-group -o a.out
arm-linux-gnueabi-objdump -S --reloc a.out

gives:
8076:   af00add r7, sp, #0
8078:   f000 f802   bl  8080 foo
807c:   4618mov r0, r3

It should have been blx foo

Again, %function solves it. Conclusion: %function is necessary with
both old and new tool-chains when building for Thumb.


It should have been blx   8080 foo, isn't it? Again, %function
solves it.

Conclusion: %function is necessary with both old and new tool-chains
when building for Thumb.


So apparently the issue has been fixed recently. Unfortunately Linaro
GCC 2012.01 creates a new Thumb problem that I am investigating now.
Somehow I missed this when I tested earlier. So, my Thumb build is
not working with Linaro GCC 2012.01. But this one is not reproduced on
Sourcery G++ Lite 2010q1-202!

Here is the program I used to reproduce the problem in Sourcery G++
Lite 2010q1-202 that this patch is addressing

a.c:

extern void foo (void) __attribute__ ((weak, alias (__foo)));

void __foo (void)
{
}

extern void call_foo(void);

int main (void)
{
call_foo ();
}

b.S:

.text
.align 2
.global foo
foo:
push {r7}
add r7, sp, #0
mov sp, r7
pop {r7}
bx lr
.size foo, .-foo


c.S:

.text
.align 2

.global call_foo
call_foo:
bl foo
bx lr

.global __aeabi_unwind_cpp_pr0
__aeabi_unwind_cpp_pr0:
bx lr

Now build it and take the assembly dump using the following commands:

arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c a.c
arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c b.S
arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c c.S
arm

Re: [U-Boot] [PATCH 2/4] arm: add %function attribute to assembly functions

[Aneesh V]

Hi Albert,

On Wednesday 15 February 2012 07:27 PM, Aneesh V wrote:

This is done using the following directive preceding
each function definition:

.typefunc-name, %function

This marks the symbol as a function in the object
header which in turn helps the linker in some cases.

In particular this was found needed for resolving ARM/Thumb
calls correctly in a build with Thumb interworking enabled.

This solves the following problem I had reported earlier:

When U-Boot/SPL is built using the Thumb instruction set the
toolchain has a  potential issue with weakly linked symbols.
If a function has a weakly linked default implementation in C
and a real implementation in assembly GCC is confused about the
instruction set of the assembly implementation. As a result
the assembly function that is built in ARM is executed as
if it is Thumb. This results in a crash

Signed-off-by: Aneesh Vane...@ti.com


Does this look good to you. I was a bit nervous about touching so many
files. Please let me know if you would prefer to change only the OMAP
function that was creating the ARM/Thumb problem. I did a MAKEALL -a
arm and didn't see any new errors.

Let me know if this is an acceptable solution to the problem.

regards,
Aneesh



---
Changes from RFC to V1:
- This change completely replaces the previous workaround for
   the ARM/Thumb interwork problem, which was to wrap around
   the assembly function in question with a naked C function
---
  arch/arm/cpu/arm1136/omap24xx/reset.S  |3 +-
  arch/arm/cpu/arm1136/start.S   |7 +++-
  arch/arm/cpu/arm1176/s3c64xx/cpu_init.S|3 +-
  arch/arm/cpu/arm1176/s3c64xx/reset.S   |3 +-
  arch/arm/cpu/arm1176/start.S   |9 +++--
  arch/arm/cpu/arm1176/tnetv107x/lowlevel_init.S |3 +-
  arch/arm/cpu/arm720t/lpc2292/iap_entry.S   |3 +-
  arch/arm/cpu/arm720t/start.S   |   12 --
  arch/arm/cpu/arm920t/a320/reset.S  |1 +
  arch/arm/cpu/arm920t/at91/lowlevel_init.S  |3 +-
  arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S|3 +-
  arch/arm/cpu/arm920t/ks8695/lowlevel_init.S|3 +-
  arch/arm/cpu/arm920t/start.S   |6 ++-
  arch/arm/cpu/arm925t/start.S   |9 +++--
  arch/arm/cpu/arm926ejs/at91/lowlevel_init.S|4 +-
  arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S |3 +-
  arch/arm/cpu/arm926ejs/davinci/reset.S |3 +-
  arch/arm/cpu/arm926ejs/mx28/start.S|3 +-
  arch/arm/cpu/arm926ejs/nomadik/reset.S |3 +-
  arch/arm/cpu/arm926ejs/omap/reset.S|3 +-
  arch/arm/cpu/arm926ejs/orion5x/lowlevel_init.S |3 +-
  arch/arm/cpu/arm926ejs/start.S |9 +++--
  arch/arm/cpu/arm926ejs/versatile/reset.S   |3 +-
  arch/arm/cpu/arm946es/start.S  |9 +++--
  arch/arm/cpu/arm_intcm/start.S |   15 ++--
  arch/arm/cpu/armv7/mx5/lowlevel_init.S |3 +-
  arch/arm/cpu/armv7/mx6/lowlevel_init.S |3 +-
  arch/arm/cpu/armv7/omap-common/lowlevel_init.S |9 +++--
  arch/arm/cpu/armv7/omap-common/reset.S |1 +
  arch/arm/cpu/armv7/omap3/lowlevel_init.S   |   45 
  arch/arm/cpu/armv7/s5pc1xx/cache.S |2 +
  arch/arm/cpu/armv7/s5pc1xx/reset.S |3 +-
  arch/arm/cpu/armv7/start.S |9 +++--
  arch/arm/cpu/armv7/tegra2/lowlevel_init.S  |1 +
  arch/arm/cpu/armv7/u8500/lowlevel.S|6 ++-
  arch/arm/cpu/ixp/start.S   |9 +++--
  arch/arm/cpu/lh7a40x/start.S   |9 +++--
  arch/arm/cpu/pxa/start.S   |6 ++-
  arch/arm/cpu/s3c44b0/start.S   |6 ++-
  arch/arm/cpu/sa1100/start.S|9 +++--
  arch/arm/lib/_ashldi3.S|6 ++-
  arch/arm/lib/_ashrdi3.S|6 ++-
  arch/arm/lib/_divsi3.S |6 ++-
  arch/arm/lib/_lshrdi3.S|6 ++-
  arch/arm/lib/_modsi3.S |3 +-
  arch/arm/lib/_udivsi3.S|6 ++-
  arch/arm/lib/memcpy.S  |3 +-
  arch/arm/lib/memset.S  |3 +-
  48 files changed, 186 insertions(+), 100 deletions(-)

diff --git a/arch/arm/cpu/arm1136/omap24xx/reset.S 
b/arch/arm/cpu/arm1136/omap24xx/reset.S
index 5f8343f..917a934 100644
--- a/arch/arm/cpu/arm1136/omap24xx/reset.S
+++ b/arch/arm/cpu/arm1136/omap24xx/reset.S
@@ -30,7 +30,8 @@

  #includeasm/arch/omap2420.h

-.globl reset_cpu
+.type  reset_cpu, %function
+.globalreset_cpu
  reset_cpu:
ldr r1, rstctl  /* get addr for global reset reg */
mov r3, #0x2/* full reset pll+mpu */
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index c0db96c..972fc0e 100644
--- a/arch/arm/cpu

[U-Boot] [PATCH] armv7: omap3: leave outer cache enabled

[Aneesh V]

Mainline kernel for OMAP3 doesn't enable L2 cache
It expects L2$ to be enabled by ROM-code/bootloader.

Leaving L2$ enabled can be troublesome in cases where
the L2 cache is not under CP15 control, such as in
Cortex-A9. This problem is explained in detail in
the commit dc7100f4080952798413fb63bb4134b22c57623a

However, this problem doesn't apply to Cortex-A8
because L2$ in Cortex-A8 is under CP15 control and
hence the generic armv7 maintenance opertions work
for it.

As such we can make an exception for OMAP3 and
leave the L2$ enabled when we jump to kernel. This
is done by removing the strongly-linked implementation
of v7_outer_cache_disable() and allowing it to fall
back to the weakly linked implementation that doesn't
do anything.

Signed-off-by: Aneesh V ane...@ti.com
---
I haven't tested this patch as I don't have an OMAP3
board with me right now. Appreciate if anybody with
a Beagle could try it out.
---
 arch/arm/cpu/armv7/omap3/board.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 871aa37..21cf455 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -426,7 +426,7 @@ void v7_outer_cache_enable(void)
omap3_update_aux_cr(0x2, 0);
 }
 
-void v7_outer_cache_disable(void)
+void omap3_outer_cache_disable(void)
 {
/* Clear L2EN */
omap3_update_aux_cr_secure(0, 0x2);
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/4] Enable Thumb build for ARM platforms

[Aneesh V]

Thumb is an alternate instruction set available in many
ARM processors. Below is a detailed description from ARM
specs:

The Thumb instruction set is a re-encoded subset of the
ARM instruction set. Thumb instructions execute in their
own processor state, with the architecture defining the
mechanisms required to transition between ARM and Thumb
states. The key difference is that Thumb instructions are
half the size of ARM instructions(16 bits compared with 32
bits). Greater code density can usually be achieved by using
the Thumb instruction set in preference to the ARM instruction
set, at a cost of some reduction in performance

In ARMv6T2, Thumb-2 technology is introduced. This technology
makes it possible to extend the original Thumb instruction set
with many 32-bit instructions. The range of 32-bit Thumb instructions
included in ARMv6T2 permits Thumb code to achieve performance
similar to ARM code, with code density better than that of earlier
Thumb code. From ARMv6T2, the ARM and Thumb instruction sets provide
almost identical functionality

This series adds Thumb support in U-Boot and enables it for
OMAP4. It also fixes issues faced while booting OMAP4 with
Thumb-2 images of U-Boot and SPL.

Thumb mode is becoming increasingly relevant for U-Boot with
the advent of SPL. It's very important to keep SPL size smaller
considering the internal RAM size constraints on many platforms.
On OMAP4 the size reduction enables us to use SPL on secure devices
that have smaller internal RAM available for non-secure world. 

I would request all who are interested in this feature to test it
and give feedback. To make that easier I have pushed my patches
here (along with the timer patch from Nicolas that fixes boot on
OMAP4): 

g...@github.com:aneeshv/u-boot.git
branch: thumb

To enable support for new platforms you just need to add
CONFIG_SYS_THUMB_BUILD in your config file.

Tool-chains tried:
1. Sourcery G++ Lite 2010q1-202
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1
GNU ld (Sourcery G++ Lite 2010q1-202) - binutils 2.19.51.20090709

2. Linaro 4.6-2012.01
arm-linux-gnueabi-gcc (crosstool-NG linaro-1.13.1-2012.01-20120125 -
Linaro GCC 2012.01) 4.6.3 20120105 (prerelease)
GNU ld (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 2012.01) 2.22

Code-size reduction:
Image   ARM build   Thumb build % Reduction
u-boot.bin  190408  144676  24.01%
u-boot-spl.bin  33200   25096   24.40%

Performance(timestamp just before the main loop):
ARM build   Thumb build % Reduction
898510us878247us-2.25%

Performance actually improved marginally for the Thumb
build, maybe because of the reduced image sizes. 

Aneesh V (4):
  ARM: enable Thumb build
  arm: add %function attribute to assembly functions
  armv7: Use -march=armv7-a and thereby enable Thumb-2
  OMAP4: enable Thumb build

 README |9 +
 arch/arm/config.mk |   20 +++---
 arch/arm/cpu/arm1136/omap24xx/reset.S  |3 +-
 arch/arm/cpu/arm1136/start.S   |7 +++-
 arch/arm/cpu/arm1176/s3c64xx/cpu_init.S|3 +-
 arch/arm/cpu/arm1176/s3c64xx/reset.S   |3 +-
 arch/arm/cpu/arm1176/start.S   |9 +++--
 arch/arm/cpu/arm1176/tnetv107x/lowlevel_init.S |3 +-
 arch/arm/cpu/arm720t/lpc2292/iap_entry.S   |3 +-
 arch/arm/cpu/arm720t/start.S   |   12 --
 arch/arm/cpu/arm920t/a320/reset.S  |1 +
 arch/arm/cpu/arm920t/at91/lowlevel_init.S  |3 +-
 arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S|3 +-
 arch/arm/cpu/arm920t/ks8695/lowlevel_init.S|3 +-
 arch/arm/cpu/arm920t/start.S   |6 ++-
 arch/arm/cpu/arm925t/start.S   |9 +++--
 arch/arm/cpu/arm926ejs/at91/lowlevel_init.S|4 +-
 arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S |3 +-
 arch/arm/cpu/arm926ejs/davinci/reset.S |3 +-
 arch/arm/cpu/arm926ejs/mx28/start.S|3 +-
 arch/arm/cpu/arm926ejs/nomadik/reset.S |3 +-
 arch/arm/cpu/arm926ejs/omap/reset.S|3 +-
 arch/arm/cpu/arm926ejs/orion5x/lowlevel_init.S |3 +-
 arch/arm/cpu/arm926ejs/start.S |9 +++--
 arch/arm/cpu/arm926ejs/versatile/reset.S   |3 +-
 arch/arm/cpu/arm946es/start.S  |9 +++--
 arch/arm/cpu/arm_intcm/start.S |   15 ++--
 arch/arm/cpu/armv7/config.mk   |5 ++-
 arch/arm/cpu/armv7/mx5/lowlevel_init.S |3 +-
 arch/arm/cpu/armv7/mx6/lowlevel_init.S |3 +-
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |9 +++--
 arch/arm/cpu/armv7/omap-common/reset.S |1 +
 arch/arm/cpu/armv7/omap3/lowlevel_init.S   |   45 
 arch/arm/cpu/armv7/s5pc1xx/cache.S |2 +
 arch/arm/cpu/armv7/s5pc1xx/reset.S |3

[U-Boot] [PATCH 1/4] ARM: enable Thumb build

[Aneesh V]

Enable Thumb build and ARM-Thumb interworking based on the new
config flag CONFIG_SYS_THUMB_BUILD

Signed-off-by: Aneesh V ane...@ti.com
---
Changes from RFC to V1:
- Fixed review comments from Tom Rini tr...@ti.com
---
 README |9 +
 arch/arm/config.mk |   20 ++--
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/README b/README
index 4343057..5345ad2 100644
--- a/README
+++ b/README
@@ -420,6 +420,15 @@ 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_THUMB_BUILD
+
+   Use this flag to build U-Boot using the Thumb instruction
+   set for ARM architectures. Thumb instruction set provides
+   better code density. For ARM architectures that support
+   Thumb2 this flag will result in Thumb2 code generated by
+   GCC.
+
 - Linux Kernel Interface:
CONFIG_CLOCKS_IN_MHZ
 
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 45f9dca..de9aa53 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -33,25 +33,33 @@ endif
 
 PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__
 
-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
+# Choose between ARM/Thumb instruction sets
+ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
+PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\
+   $(call cc-option,-marm,)\
+   $(call cc-option,-mno-thumb-interwork,)\
+   )
+else
 PF_CPPFLAGS_ARM := $(call cc-option,-marm,)
+PF_CPPFLAGS_ARM += $(call cc-option,-mno-thumb-interwork,)
+endif
 
 # Try if EABI is supported, else fall back to old API,
 # i. e. for example:
 # - with ELDK 4.2 (EABI supported), use:
-#  -mabi=aapcs-linux -mno-thumb-interwork
+#  -mabi=aapcs-linux
 # - with ELDK 4.1 (gcc 4.x, no EABI), use:
-#  -mabi=apcs-gnu -mno-thumb-interwork
+#  -mabi=apcs-gnu
 # - with ELDK 3.1 (gcc 3.x), use:
-#  -mapcs-32 -mno-thumb-interwork
+#  -mapcs-32
 PF_CPPFLAGS_ABI := $(call cc-option,\
-   -mabi=aapcs-linux -mno-thumb-interwork,\
+   -mabi=aapcs-linux,\
$(call cc-option,\
-mapcs-32,\
$(call cc-option,\
-mabi=apcs-gnu,\
)\
-   ) $(call cc-option,-mno-thumb-interwork,)\
+   )\
)
 PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARM) $(PF_CPPFLAGS_ABI)
 
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/4] armv7: Use -march=armv7-a and thereby enable Thumb-2

[Aneesh V]

Enable -march=armv7-a for armv7 platforms if the tool-chain
supports it. This in turn results in Thumb-2 code generated
for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.

Signed-off-by: Aneesh V ane...@ti.com
---
I believe armv7-a is fine for all the SoCs except Tegra2
and I see that Tegra2 is already making the necessary
exception in .../armv7/tegra2/config.mk

Let me know if any other SoC has a problem with armv7-a

Changes from RFC to V1:
- Enabled armv7-a from armv7/config.mk instead of from
  omap config.mk files
---
 arch/arm/cpu/armv7/config.mk |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
index 83ddf10..b66fb6f 100644
--- a/arch/arm/cpu/armv7/config.mk
+++ b/arch/arm/cpu/armv7/config.mk
@@ -22,8 +22,9 @@
 #
 PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 
-# Make ARMv5 to allow more compilers to work, even though its v7a.
-PLATFORM_CPPFLAGS += -march=armv5
+# If armv7-a is not supported by GCC fall-back to armv5, which is
+# supported by more tool-chains
+PLATFORM_CPPFLAGS += $(call cc-option, -march=armv7-a, -march=armv5)
 # =
 #
 # Supply options according to compiler version
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/4] arm: add %function attribute to assembly functions

[Aneesh V]

This is done using the following directive preceding
each function definition:

.type func-name, %function

This marks the symbol as a function in the object
header which in turn helps the linker in some cases.

In particular this was found needed for resolving ARM/Thumb
calls correctly in a build with Thumb interworking enabled.

This solves the following problem I had reported earlier:

When U-Boot/SPL is built using the Thumb instruction set the
toolchain has a  potential issue with weakly linked symbols.
If a function has a weakly linked default implementation in C
and a real implementation in assembly GCC is confused about the
instruction set of the assembly implementation. As a result
the assembly function that is built in ARM is executed as
if it is Thumb. This results in a crash

Signed-off-by: Aneesh V ane...@ti.com
---
Changes from RFC to V1:
- This change completely replaces the previous workaround for
  the ARM/Thumb interwork problem, which was to wrap around
  the assembly function in question with a naked C function
---
 arch/arm/cpu/arm1136/omap24xx/reset.S  |3 +-
 arch/arm/cpu/arm1136/start.S   |7 +++-
 arch/arm/cpu/arm1176/s3c64xx/cpu_init.S|3 +-
 arch/arm/cpu/arm1176/s3c64xx/reset.S   |3 +-
 arch/arm/cpu/arm1176/start.S   |9 +++--
 arch/arm/cpu/arm1176/tnetv107x/lowlevel_init.S |3 +-
 arch/arm/cpu/arm720t/lpc2292/iap_entry.S   |3 +-
 arch/arm/cpu/arm720t/start.S   |   12 --
 arch/arm/cpu/arm920t/a320/reset.S  |1 +
 arch/arm/cpu/arm920t/at91/lowlevel_init.S  |3 +-
 arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S|3 +-
 arch/arm/cpu/arm920t/ks8695/lowlevel_init.S|3 +-
 arch/arm/cpu/arm920t/start.S   |6 ++-
 arch/arm/cpu/arm925t/start.S   |9 +++--
 arch/arm/cpu/arm926ejs/at91/lowlevel_init.S|4 +-
 arch/arm/cpu/arm926ejs/davinci/lowlevel_init.S |3 +-
 arch/arm/cpu/arm926ejs/davinci/reset.S |3 +-
 arch/arm/cpu/arm926ejs/mx28/start.S|3 +-
 arch/arm/cpu/arm926ejs/nomadik/reset.S |3 +-
 arch/arm/cpu/arm926ejs/omap/reset.S|3 +-
 arch/arm/cpu/arm926ejs/orion5x/lowlevel_init.S |3 +-
 arch/arm/cpu/arm926ejs/start.S |9 +++--
 arch/arm/cpu/arm926ejs/versatile/reset.S   |3 +-
 arch/arm/cpu/arm946es/start.S  |9 +++--
 arch/arm/cpu/arm_intcm/start.S |   15 ++--
 arch/arm/cpu/armv7/mx5/lowlevel_init.S |3 +-
 arch/arm/cpu/armv7/mx6/lowlevel_init.S |3 +-
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |9 +++--
 arch/arm/cpu/armv7/omap-common/reset.S |1 +
 arch/arm/cpu/armv7/omap3/lowlevel_init.S   |   45 
 arch/arm/cpu/armv7/s5pc1xx/cache.S |2 +
 arch/arm/cpu/armv7/s5pc1xx/reset.S |3 +-
 arch/arm/cpu/armv7/start.S |9 +++--
 arch/arm/cpu/armv7/tegra2/lowlevel_init.S  |1 +
 arch/arm/cpu/armv7/u8500/lowlevel.S|6 ++-
 arch/arm/cpu/ixp/start.S   |9 +++--
 arch/arm/cpu/lh7a40x/start.S   |9 +++--
 arch/arm/cpu/pxa/start.S   |6 ++-
 arch/arm/cpu/s3c44b0/start.S   |6 ++-
 arch/arm/cpu/sa1100/start.S|9 +++--
 arch/arm/lib/_ashldi3.S|6 ++-
 arch/arm/lib/_ashrdi3.S|6 ++-
 arch/arm/lib/_divsi3.S |6 ++-
 arch/arm/lib/_lshrdi3.S|6 ++-
 arch/arm/lib/_modsi3.S |3 +-
 arch/arm/lib/_udivsi3.S|6 ++-
 arch/arm/lib/memcpy.S  |3 +-
 arch/arm/lib/memset.S  |3 +-
 48 files changed, 186 insertions(+), 100 deletions(-)

diff --git a/arch/arm/cpu/arm1136/omap24xx/reset.S 
b/arch/arm/cpu/arm1136/omap24xx/reset.S
index 5f8343f..917a934 100644
--- a/arch/arm/cpu/arm1136/omap24xx/reset.S
+++ b/arch/arm/cpu/arm1136/omap24xx/reset.S
@@ -30,7 +30,8 @@
 
 #include asm/arch/omap2420.h
 
-.globl reset_cpu
+.type  reset_cpu, %function
+.globalreset_cpu
 reset_cpu:
ldr r1, rstctl  /* get addr for global reset reg */
mov r3, #0x2/* full reset pll+mpu */
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index c0db96c..972fc0e 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -31,7 +31,8 @@
 #include asm-offsets.h
 #include config.h
 #include version.h
-.globl _start
+.type  _start, %function
+.global_start
 _start: b  reset
 #ifdef CONFIG_SPL_BUILD
ldr pc, _hang
@@ -178,7 +179,8 @@ call_board_init_f:
  * after relocating the monitor code.
  *
  */
-   .globl  relocate_code
+.type  relocate_code, %function
+.global

[U-Boot] [PATCH 4/4] OMAP4: enable Thumb build

[Aneesh V]

Signed-off-by: Aneesh V ane...@ti.com
---
Changes from RFC to V1:
- None
---
 include/configs/omap4_common.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index a989721..01b4d6c 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -287,4 +287,6 @@
 
 #define CONFIG_SYS_ENABLE_PADS_ALL
 
+#define CONFIG_SYS_THUMB_BUILD
+
 #endif /* __CONFIG_OMAP4_COMMON_H */
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 2/4] OMAP3+: fix issues with Thumb build

[Aneesh V]

Hi Albert,

On Tuesday 07 February 2012 02:36 AM, Albert ARIBAUD wrote:

Le 06/02/2012 12:37, Aneesh V a écrit :

When U-Boot/SPL is built using the Thumb instruction set the
toolchain has a potential issue with weakly linked symbols.
If a function has a weakly linked default implementation in C
and a real implementation in assembly GCC is confused about the
instruction set of the assembly implementation. As a result
the assembly function that is built in ARM is executed as
if it is Thumb. This results in a crash.

We need to investigate further to see if this is a toolchain
issue or an issue with our usage of it. In the meanwhile, we
can workaround the issue by having both the weakly linked alias
and the real implementation in C.


I would tend to NAK a patch submission where an issue is known and
investigation is considered but is actually bypassed by a workaround.
These tend to turn from 'temporary fix' to 'old crust' with time,
because there is no incentive for a better solution when the quick fix
works, after all.


I have a solution to this problem now. The following change solves it.

diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S 
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S

index 35f38ac..177af7a 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -28,6 +28,7 @@

 #include asm/arch/omap.h

+.type   save_boot_params, %function
 .global save_boot_params
 save_boot_params:
/*

Apparently having the symbol marked as %function type in the symbol
table helps ld. However, not having the %function tag doesn't prevent
ld from linking correctly to this function. It affects only ARM/Thumb
resolution. Strange!

I came to this solution from the test-code provided by Ulrich Weigand
in reply to my queries in Linaro ML [1]. I couldn't reproduce the
problem with his code, but eventually could break it when I removed
the %function.

I will continue this discussion there and to understand whether this is
a limitation with GCC.

However, hope you are fine with the above solution. I shall fix up all
assembly functions in arm.

[1] http://article.gmane.org/gmane.linux.linaro.devel/3073

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6?

[Aneesh V]

On Thursday 09 February 2012 05:14 PM, Wolfgang Denk wrote:

Dear Aneesh V,

In message4f33614d.8020...@ti.com  you wrote:



What exactly are you talking about here that was adding a
considerable delay - the memory copy ?  Are you really sure about
that?


I didn't measure it part by part, but removing relocation gave a
noticeable speed-up, this platform is several orders of magnitude
slower than the real silicon. So, that should not be surprising.


Could you please start using exact terminology, so we understand what
you actually refer to?  Did you really remove the _relocation_, i. e.
link for a static address, or did you just skip the memory copy?  Note
that the latter should be a no-op anyway if you just load the image to
the resulting target address.


I defeated relocation by passing to the relocate_code() function the
same address as it is linked to. I patched up arch/arm/lib/board.c for
this and fixed up the relocate_code() to correctly handle this special
case. So, relocate_code() does only .bss init now.




Maybe, I should stop the arguments now and wait till that framework is
a reality.


I am very much convinced that you are tracking down a red herring.  It
does not really matter if you run the code on real silicon or in an
emulation - the relative times will always be the same.  Without any
detailed timing analysis I simply do not believe you that you really
have found a hot spot.  You focus on it because you found out that it
exists and you think it was not needed in your configuration -
without spending time on real optimization.


Please note that our bootloaders and kernel are customized and scaled
down for this environment. For instance, u-boot doesn't load the kernel
from network or a memory device. The kernel is preloaded in the modeled
memory for it. So, u-boot was just used to jump to the kernel. As such,
the u-boot run-time is now more dominated by pure software stuff such
as relocation. The relative timing doesn't quite apply.



This is a fundamentally broken approach, and it will remain to be
broken even if new concepts get implemented that may make it easier to
skip certain steps of the initialization.

If you are concerned about boot time optimization, you _must_ start
with timing measurements.  You know where premature optimization leads
to, don't you?


As I mentioned earlier boot-time is not my key care-about. Even on an
emulation platform I will probably try SPL Linux boot next time. My key
concerns are about the other aspects I mentioned, namely avoidable
complexity and problems with debugger.

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6?

[Aneesh V]

Dear Wolfgang,

On Wednesday 08 February 2012 07:28 PM, Wolfgang Denk wrote:

Dear Aneesh V,

In message4f3219a8.7090...@ti.com  you wrote:


As for ignoring comments, I think you are culpable of that more than me
in this specific instance:) (of course I know you are busy person, but
still..). For instance, my arguments in the previous round [1] never
got an answer from you.

[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/96371


I don't see any question from you that has not been answered?

You suggest to do things in a way that introduces a number of
often discussed disadvantages.  And you claim that for you this would
be good enough.  What should I comment on this?

For the record:

- You continiue to talk about relocation, but you mean something
   different (a memory copy).  I am not sure if you really understand
   the difference.


I do understand what the ELF relocation does.



- You claim omitting this copy operation would be important to
   optimize boot times, but you cannot provide any real numbers that
   support such a claim:

   * You do not know how much time exactly is needed for this copy
 operation, so you don't know how much you can potentially safe,
 and if this would result in any perceptible imprvement of the boot
 time.


I had provided data for OMAP4 and agreed with you that from the boot
time point of view it doesn't make sense to disable relocation [1].

But since then I changed my mind due to some other factors:
1. Difficulty in debugging. I use JTAG debuggers. The workarounds
available are still painful and not many people know about it.

2. On FPGA platform, it was adding a considerable delay (I don't have
the exact number, but that will be in minutes). The u-boot was already
scaled down and was doing minimal stuff, but this one could not be
removed easily. That's when I created that patch.

3. Un-necessary complexity without any benefit for our platform. I
nearly get exhausted explaining to new u-boot users how it all works
and nearly always gets confronted with the question why do we
need it? In our platforms U-Boot starts from SDRAM and we do not need
any of the flexibilities relocation may provide.



   * You did not investigate how long other parts of the boot process
 are talking, so you don't really know where the hot spot where you
 should focus your optimization efforts.

   * You did not investigate how the timing behaviour changes if you
 enable both instruction and data cache in the SPL. In my
 experience this would be a way more rewarding target for
 optimization efforts than omitting a little memcpy().


We have caches enabled. But anyway, these two points are irrelevant
because my argument is not from the point of view of time.

At the end of the day I think we are making U-Boot way too complex for
a bootloader and I think relocation is one of the factors.

[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88288
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6?

[Aneesh V]

On Wednesday 08 February 2012 09:53 PM, Wolfgang Denk wrote:

Dear Aneesh V,

In message4f328b41.2050...@ti.com  you wrote:


But since then I changed my mind due to some other factors:
1. Difficulty in debugging. I use JTAG debuggers. The workarounds
available are still painful and not many people know about it.


We use JTAG debuggers all day, and have been doing so for well over 10
years.  All development of PPCBoot nad U-Boot has been done withJTAG
debuggers.  Relocation has never been a real problem here.

Reasinf the manual may help - this is documented in detail there.

This is not a good reason to reconsider.


2. On FPGA platform, it was adding a considerable delay (I don't have
the exact number, but that will be in minutes). The u-boot was already
scaled down and was doing minimal stuff, but this one could not be
removed easily. That's when I created that patch.


What exactly are you talking about here that was adding a
considerable delay - the memory copy ?  Are you really sure about
that?


I didn't measure it part by part, but removing relocation gave a
noticeable speed-up, this platform is several orders of magnitude
slower than the real silicon. So, that should not be surprising.




3. Un-necessary complexity without any benefit for our platform. I


Maintaining different configurations of the code that behave
differently, that can cause different types of addressing, compile
and link and debug issues is also adding complexity.  Using a single,
well tested approach is one of the benefits even for your platform.


Fair enough. But will the new INITCALL framework help? I haven't really
followed the discussions on it. But if, as Graeme claims, all
relocation stuff is collected in one place and is easily pluggable
then maintainability is not a problem, right?

Maybe, I should stop the arguments now and wait till that framework is
a reality.

best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6?

[Aneesh V]

Dear Wolfgang,

On Wednesday 08 February 2012 04:56 AM, Wolfgang Denk wrote:

Dear Aneesh V,

In message4f30d06e.8060...@ti.com  you wrote:


I agree. Even on some platforms that are not fully static (such as having
variants with different memory sizes) the minimum available memory is
more than enough to allocate big enough partitions for each need at
U-Boot level. And my guess (or rather speculation) is that platforms
that do not have any real dynamic needs are in the majority. I sincerely
believe that platforms should be allowed to enable/disable
relocation based on their needs.


This is your opinion.  It is noted, and appreciated.

But you should not try to continue to ignore all the previous
discussion to that topic.  There have been no new arguments in this
round, so there will be no change of the previously made decisions.


First of all I am not arguing in favor of taking it in the current
form. But as Graeme mentioned if the new initcall framework makes it
clean and maintainable I am hoping that you will consider it more
favorably. And this is indeed a new argument because the biggest
objection previously was that the no-relocation case will be difficult
to maintain.

As for ignoring comments, I think you are culpable of that more than me
in this specific instance:) (of course I know you are busy person, but
still..). For instance, my arguments in the previous round [1] never
got an answer from you.

[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/96371

best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH 0/4] Enable Thumb build for ARM platforms

[Aneesh V]

Thumb is an alternate instruction set available in many
ARM processors. Below is a detailed description from ARM
specs:

The Thumb instruction set is a re-encoded subset of the
ARM instruction set. Thumb instructions execute in their
own processor state, with the architecture defining the
mechanisms required to transition between ARM and Thumb
states. The key difference is that Thumb instructions are
half the size of ARM instructions(16 bits compared with 32
bits). Greater code density can usually be achieved by using
the Thumb instruction set in preference to the ARM instruction
set, at a cost of some reduction in performance

In ARMv6T2, Thumb-2 technology is introduced. This technology
makes it possible to extend the original Thumb instruction set
with many 32-bit instructions. The range of 32-bit Thumb instructions
included in ARMv6T2 permits Thumb code to achieve performance
similar to ARM code, with code density better than that of earlier
Thumb code. From ARMv6T2, the ARM and Thumb instruction sets provide
almost identical functionality

This series adds Thumb support in U-Boot and enables it for
OMAP4. It also fixes issues faced while booting OMAP4 with
Thumb-2 images of U-Boot and SPL.

Thumb mode is becoming increasingly relevant for U-Boot with
the advent of SPL. It's very important to keep SPL size smaller
considering the internal RAM size constraints on many platforms.
On OMAP4 the size reduction enables us to use SPL on secure devices
that have smaller internal RAM available for non-secure world. 

I would request all who are interested in this feature to test it
and give feedback. To make that easier I have pushed my patches
here (along with the timer patch from Nicolas that fixes boot on
OMAP4): 

g...@github.com:aneeshv/u-boot.git
branch: thumb

To enable support for new platforms you just need to add
CONFIG_SYS_THUMB_BUILD in your config file.

Aneesh V (4):
  ARM: enable Thumb build
  OMAP3+: fix issues with Thumb build
  OMAP3+: Use -march=armv7-a and thereby enable Thumb-2
  OMAP4: enable Thumb build

 README |9 +++
 arch/arm/config.mk |   29 ++--
 arch/arm/cpu/armv7/cpu.c   |4 ++-
 arch/arm/cpu/armv7/omap-common/config.mk   |1 -
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |   25 
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |4 +-
 arch/arm/cpu/armv7/omap3/config.mk |2 +
 arch/arm/cpu/armv7/omap4/config.mk |2 +
 include/configs/omap4_common.h |2 +
 9 files changed, 62 insertions(+), 16 deletions(-)

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH 1/4] ARM: enable Thumb build

[Aneesh V]

Enable Thumb build and ARM-Thumb interworking based on the new
config flag CONFIG_SYS_THUMB_BUILD

Signed-off-by: Aneesh V ane...@ti.com
---
 README |9 +
 arch/arm/config.mk |   29 +
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/README b/README
index 9d713e8..dfe7fb3 100644
--- a/README
+++ b/README
@@ -420,6 +420,15 @@ 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_THUMB_BUILD
+
+   Use this flag to build U-Boot using the Thumb instruction
+   set for ARM architectures. Thumb instruction set provides
+   better code density. For ARM architectures that support
+   Thumb2 this flag will result in Thumb2 code generated by
+   GCC.
+
 - Linux Kernel Interface:
CONFIG_CLOCKS_IN_MHZ
 
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 45f9dca..9a450d7 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -33,26 +33,31 @@ endif
 
 PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__
 
-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
-PF_CPPFLAGS_ARM := $(call cc-option,-marm,)
+# Choose between ARM/Thumb instruction sets
+ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
+PF_CPPFLAGS_ARM += $(call cc-option, -mthumb -mthumb-interwork, \
+   -marm -mno-thumb-interwork)
+else
+PF_CPPFLAGS_ARM += $(call cc-option, -marm -mno-thumb-interwork)
+endif
 
 # Try if EABI is supported, else fall back to old API,
 # i. e. for example:
 # - with ELDK 4.2 (EABI supported), use:
-#  -mabi=aapcs-linux -mno-thumb-interwork
+#  -mabi=aapcs-linux
 # - with ELDK 4.1 (gcc 4.x, no EABI), use:
-#  -mabi=apcs-gnu -mno-thumb-interwork
+#  -mabi=apcs-gnu
 # - with ELDK 3.1 (gcc 3.x), use:
-#  -mapcs-32 -mno-thumb-interwork
-PF_CPPFLAGS_ABI := $(call cc-option,\
-   -mabi=aapcs-linux -mno-thumb-interwork,\
-   $(call cc-option,\
-   -mapcs-32,\
+#  -mapcs-32
+PLATFORM_CPPFLAGS += $(call cc-option,\
+   -mabi=aapcs-linux,\
$(call cc-option,\
-   -mabi=apcs-gnu,\
+   -mapcs-32,\
+   $(call cc-option,\
+   -mabi=apcs-gnu,\
+   )\
)\
-   ) $(call cc-option,-mno-thumb-interwork,)\
-   )
+   )
 PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARM) $(PF_CPPFLAGS_ABI)
 
 # For EABI, make sure to provide raise()
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH 2/4] OMAP3+: fix issues with Thumb build

[Aneesh V]

When U-Boot/SPL is built using the Thumb instruction set the
toolchain has a  potential issue with weakly linked symbols.
If a function has a weakly linked default implementation in C
and a real implementation in assembly GCC is confused about the
instruction set of the assembly implementation. As a result
the assembly function that is built in ARM is executed as
if it is Thumb. This results in a crash.

We need to investigate further to see if this is a toolchain
issue or an issue with our usage of it. In the meanwhile, we
can workaround the issue by having both the weakly linked alias
and the real implementation in C.

Signed-off-by: Aneesh V ane...@ti.com
---
 arch/arm/cpu/armv7/cpu.c   |4 ++-
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |   25 
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |4 +-
 3 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index 662c496..3844556 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -37,8 +37,10 @@
 #include asm/cache.h
 #include asm/armv7.h
 
-void save_boot_params_default(u32 r0, u32 r1, u32 r2, u32 r3)
+void __attribute__((naked)) save_boot_params_default(u32 r0, u32 r1,
+   u32 r2, u32 r3)
 {
+   asm volatile (blx lr);
 }
 
 void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c 
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index ab46bff..16dfbed 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -237,3 +237,28 @@ void enable_caches(void)
dcache_enable();
 }
 #endif
+
+/*
+ * This function is a wrapper to do_save_boot_params that does the
+ * real implementation of the functionality. 'do_save_boot_params()' is
+ * implemented in assembly because this is called very early in the boot
+ * when stack is not available. We had to wrap it around in this 'naked'
+ * C function because of a potential issue with the tool-chain.
+ *
+ * When U-Boot/SPL is built using the Thumb instruction set compiler
+ * potential issue with weakly linked symbols. If a function has a weakly
+ * linked default implementation in C and a real implementation in assembly
+ * GCC is confused about the instruction set of the assembly implementation
+ * As a result the assembly function that is built in ARM is executed as
+ * if it is Thumb. This results in a crash. The solution (or workaround)
+ * is to have both the weakly linked alias and the real implementation
+ * in C.
+ *
+ * This function runs without a valid stack. So, never try to use a stack
+ * or any other fancy stuff.
+ */
+void __attribute__((naked)) save_boot_params(u32 r0, u32 r1, u32 r2, u32 r4)
+{
+   asm volatile (ldr r12, =do_save_boot_params);
+   asm volatile (bx r12);
+}
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S 
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 35f38ac..38ca054 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -28,8 +28,8 @@
 
 #include asm/arch/omap.h
 
-.global save_boot_params
-save_boot_params:
+.global do_save_boot_params
+do_save_boot_params:
/*
 * See if the rom code passed pointer is valid:
 * It is not valid if it is not in non-secure SRAM
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH 3/4] OMAP3+: Use -march=armv7-a and thereby enable Thumb-2

[Aneesh V]

Enable -march=armv7-a for OMAP3+ platforms. This in turn
results in Thumb-2 code generated for these platforms if
CONFIG_SYS_THUMB_BUILD is enabled.

Signed-off-by: Aneesh V ane...@ti.com
---
 arch/arm/cpu/armv7/omap-common/config.mk |1 -
 arch/arm/cpu/armv7/omap3/config.mk   |2 ++
 arch/arm/cpu/armv7/omap4/config.mk   |2 ++
 3 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/config.mk 
b/arch/arm/cpu/armv7/omap-common/config.mk
index c400dcc..2a1a5f3 100644
--- a/arch/arm/cpu/armv7/omap-common/config.mk
+++ b/arch/arm/cpu/armv7/omap-common/config.mk
@@ -23,7 +23,6 @@
 PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 
 # Make ARMv5 to allow more compilers to work, even though its v7a.
-PLATFORM_CPPFLAGS += -march=armv5
 # =
 #
 # Supply options according to compiler version
diff --git a/arch/arm/cpu/armv7/omap3/config.mk 
b/arch/arm/cpu/armv7/omap3/config.mk
index b34fa64..4421fe2 100644
--- a/arch/arm/cpu/armv7/omap3/config.mk
+++ b/arch/arm/cpu/armv7/omap3/config.mk
@@ -28,3 +28,5 @@ ALL-y += $(OBJTREE)/MLO
 else
 ALL-y  += $(obj)u-boot.img
 endif
+
+PLATFORM_CPPFLAGS += $(call cc-option, -march=armv7-a, -march=armv5)
diff --git a/arch/arm/cpu/armv7/omap4/config.mk 
b/arch/arm/cpu/armv7/omap4/config.mk
index b34fa64..4421fe2 100644
--- a/arch/arm/cpu/armv7/omap4/config.mk
+++ b/arch/arm/cpu/armv7/omap4/config.mk
@@ -28,3 +28,5 @@ ALL-y += $(OBJTREE)/MLO
 else
 ALL-y  += $(obj)u-boot.img
 endif
+
+PLATFORM_CPPFLAGS += $(call cc-option, -march=armv7-a, -march=armv5)
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH 4/4] OMAP4: enable Thumb build

[Aneesh V]

Signed-off-by: Aneesh V ane...@ti.com
---
 include/configs/omap4_common.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index a989721..01b4d6c 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -287,4 +287,6 @@
 
 #define CONFIG_SYS_ENABLE_PADS_ALL
 
+#define CONFIG_SYS_THUMB_BUILD
+
 #endif /* __CONFIG_OMAP4_COMMON_H */
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 0/4] Enable Thumb build for ARM platforms

[Aneesh V]

On Monday 06 February 2012 05:07 PM, Aneesh V wrote:

Thumb is an alternate instruction set available in many
ARM processors. Below is a detailed description from ARM
specs:

The Thumb instruction set is a re-encoded subset of the
ARM instruction set. Thumb instructions execute in their
own processor state, with the architecture defining the
mechanisms required to transition between ARM and Thumb
states. The key difference is that Thumb instructions are
half the size of ARM instructions(16 bits compared with 32
bits). Greater code density can usually be achieved by using
the Thumb instruction set in preference to the ARM instruction
set, at a cost of some reduction in performance

In ARMv6T2, Thumb-2 technology is introduced. This technology
makes it possible to extend the original Thumb instruction set
with many 32-bit instructions. The range of 32-bit Thumb instructions
included in ARMv6T2 permits Thumb code to achieve performance
similar to ARM code, with code density better than that of earlier
Thumb code. From ARMv6T2, the ARM and Thumb instruction sets provide
almost identical functionality

This series adds Thumb support in U-Boot and enables it for
OMAP4. It also fixes issues faced while booting OMAP4 with
Thumb-2 images of U-Boot and SPL.

Thumb mode is becoming increasingly relevant for U-Boot with
the advent of SPL. It's very important to keep SPL size smaller
considering the internal RAM size constraints on many platforms.
On OMAP4 the size reduction enables us to use SPL on secure devices
that have smaller internal RAM available for non-secure world.

I would request all who are interested in this feature to test it
and give feedback. To make that easier I have pushed my patches
here (along with the timer patch from Nicolas that fixes boot on
OMAP4):

g...@github.com:aneeshv/u-boot.git
branch: thumb

To enable support for new platforms you just need to add
CONFIG_SYS_THUMB_BUILD in your config file.


Some statistics:

Code-size reduction:
Image   ARM build   Thumb build % Reduction
u-boot.bin  190408  144676  24.01%
u-boot-spl.bin  33200   25096   24.40%

Performance(timestamp just before the main loop):
ARM build   Thumb build % Reduction
898510us878247us-2.25%

That is, performance actually improved marginally for the Thumb
build, maybe because of the reduced image sizes.

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 0/4] Enable Thumb build for ARM platforms

[Aneesh V]

On Monday 06 February 2012 05:56 PM, Aneesh V wrote:

On Monday 06 February 2012 05:07 PM, Aneesh V wrote:

Thumb is an alternate instruction set available in many
ARM processors. Below is a detailed description from ARM
specs:

The Thumb instruction set is a re-encoded subset of the
ARM instruction set. Thumb instructions execute in their
own processor state, with the architecture defining the
mechanisms required to transition between ARM and Thumb
states. The key difference is that Thumb instructions are
half the size of ARM instructions(16 bits compared with 32
bits). Greater code density can usually be achieved by using
the Thumb instruction set in preference to the ARM instruction
set, at a cost of some reduction in performance

In ARMv6T2, Thumb-2 technology is introduced. This technology
makes it possible to extend the original Thumb instruction set
with many 32-bit instructions. The range of 32-bit Thumb instructions
included in ARMv6T2 permits Thumb code to achieve performance
similar to ARM code, with code density better than that of earlier
Thumb code. From ARMv6T2, the ARM and Thumb instruction sets provide
almost identical functionality

This series adds Thumb support in U-Boot and enables it for
OMAP4. It also fixes issues faced while booting OMAP4 with
Thumb-2 images of U-Boot and SPL.

Thumb mode is becoming increasingly relevant for U-Boot with
the advent of SPL. It's very important to keep SPL size smaller
considering the internal RAM size constraints on many platforms.
On OMAP4 the size reduction enables us to use SPL on secure devices
that have smaller internal RAM available for non-secure world.

I would request all who are interested in this feature to test it
and give feedback. To make that easier I have pushed my patches
here (along with the timer patch from Nicolas that fixes boot on
OMAP4):

g...@github.com:aneeshv/u-boot.git
branch: thumb

To enable support for new platforms you just need to add
CONFIG_SYS_THUMB_BUILD in your config file.


Some statistics:

Code-size reduction:
Image ARM build Thumb build % Reduction
u-boot.bin 190408 144676 24.01%
u-boot-spl.bin 33200 25096 24.40%

Performance(timestamp just before the main loop):
ARM build Thumb build % Reduction
898510us 878247us -2.25%

That is, performance actually improved marginally for the Thumb
build, maybe because of the reduced image sizes.


Oops! I missed details about the tool-chains I used. I succcessfully
tried the following tool-chains for the Thumb build.

1. Sourcery G++ Lite 2010q1-202
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1
GNU ld (Sourcery G++ Lite 2010q1-202) - binutils 2.19.51.20090709

2. Linaro 4.6-2012.01
arm-linux-gnueabi-gcc (crosstool-NG linaro-1.13.1-2012.01-20120125 - 
Linaro GCC 2012.01) 4.6.3 20120105 (prerelease)
GNU ld (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 
2012.01) 2.22


Test reports with different tool-chains will be greatly appreciated!

best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6?

[Aneesh V]

On Sunday 05 February 2012 11:49 AM, Simon Glass wrote:

Hi,

On Sat, Feb 4, 2012 at 1:15 AM, Aneesh Vane...@ti.com  wrote:

Hi Dirk,


On Friday 03 February 2012 12:55 PM, Dirk Behme wrote:


Hi,

on i.MX6 devices, e.g. ARM2 or SabreLite, the ROM boot loader copies the
U-Boot image from the boot device, e.g. the SD card, to the main memory.
This does mean that U-Boot is started in RAM.

With this, one might wonder why any relocation RAM -  RAM is done anyway
and if this could be skipped?

Looking into the details shows that board_init_f() in
arch/arm/lib/board.c and relocate_code() in arch/arm/cpu/armv7/start.S
[1] are involved in this.

In board_init_f() the relocation destination address 'addr' is
calculated. This is basically at the end of the available RAM (- some
space for various stuff like TLB tables etc.). At SabreLite this results
in 0x4FF8D000.

By the boot loader, the U-Boot is loaded to

CONFIG_SYS_TEXT_BASE 0x1780

This results in relocate_code() copying U-Boot from RAM 0x1780 to
RAM 0x4FF8D000.

Setting CONFIG_SYS_TEXT_BASE to the relocation destination address
0x4FF8D000 does avoid the (unnecessary?) copy by

cmp r0, r6
moveq r9, #0 /* no relocation. relocation offset(r9) = 0 */
beq clear_bss /* skip relocation */

in relocate_code().

But:

1) The resulting image still runs without the relocation
(CONFIG_SYS_TEXT_BASE 0x4FF8D000). But e.g. the U-Boot command line
doesn't work properly any more. Most probably this is because not only
the copy is skipped by the 'beq clear_bss', but the whole 'fix .rel.dyn
relocations' is skipped too.

2) It's hard to set CONFIG_SYS_TEXT_BASE at compile time to the
relocation address calculated at runtime in board_init_f() due to the
amount of #ifdef and runtime calculation done there. So finding a
generic approach which could easily defined in the config files to avoid
the relocation seems difficult.



I haven't really completely read your mail. But here is an
implementation I had provided long time back for ARM. But Wolfgang
didn't want to take it. You can see the patch and the following
discussion in this thread:

http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/96352


 From your patch Aneesh I evolved something that I still use - it deals
with the case where malloc cannot fit below the text area.

I find any sort of messing with the ICE startup a pain - although I
have often been able to script it. But for me I need to attach the
device tree to the binary and a few other things so I might as well
disable relocation at the same time. It also allows me to debug
seamlessly in board_init_f() as well as afterwards.

I will send a patch.


Great!



It would be good to get something in mainline despite the
protestations, if only to avoid all the work that people have to do to
figure out this problem.


I am always in favor of that:)

best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] OMAP4460: Reduce MPU clock speed from 920 to 700

[Aneesh V]

We do not have thermal management or Smartreflex
enabled at U-Boot level. So, it's better to stick
to OPP100 for MPU instead of the OPP Turbo that is
used now. Adjust the VDD_MPU accordingly.

Tested-by: Sebastien Jan s-...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
---
 arch/arm/cpu/armv7/omap4/clocks.c |   22 +++---
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap4/clocks.c 
b/arch/arm/cpu/armv7/omap4/clocks.c
index 0886f92..311a720 100644
--- a/arch/arm/cpu/armv7/omap4/clocks.c
+++ b/arch/arm/cpu/armv7/omap4/clocks.c
@@ -67,15 +67,15 @@ const u32 sys_clk_array[8] = {
  * Please use this tool for creating the table for any new frequency.
  */
 
-/* dpll locked at 1840 MHz MPU clk at 920 MHz(OPP Turbo 4460) - DCC OFF */
-static const struct dpll_params mpu_dpll_params_1840mhz[NUM_SYS_CLKS] = {
-   {230, 2, 1, -1, -1, -1, -1, -1},/* 12 MHz   */
-   {920, 12, 1, -1, -1, -1, -1, -1},   /* 13 MHz   */
-   {219, 3, 1, -1, -1, -1, -1, -1},/* 16.8 MHz */
-   {575, 11, 1, -1, -1, -1, -1, -1},   /* 19.2 MHz */
-   {460, 12, 1, -1, -1, -1, -1, -1},   /* 26 MHz   */
-   {920, 26, 1, -1, -1, -1, -1, -1},   /* 27 MHz   */
-   {575, 23, 1, -1, -1, -1, -1, -1}/* 38.4 MHz */
+/* dpll locked at 1400 MHz MPU clk at 700 MHz(OPP100) - DCC OFF */
+static const struct dpll_params mpu_dpll_params_1400mhz[NUM_SYS_CLKS] = {
+   {175, 2, 1, -1, -1, -1, -1, -1},/* 12 MHz   */
+   {700, 12, 1, -1, -1, -1, -1, -1},   /* 13 MHz   */
+   {125, 2, 1, -1, -1, -1, -1, -1},/* 16.8 MHz */
+   {401, 10, 1, -1, -1, -1, -1, -1},   /* 19.2 MHz */
+   {350, 12, 1, -1, -1, -1, -1, -1},   /* 26 MHz   */
+   {700, 26, 1, -1, -1, -1, -1, -1},   /* 27 MHz   */
+   {638, 34, 1, -1, -1, -1, -1, -1}/* 38.4 MHz */
 };
 
 /* dpll locked at 1584 MHz - MPU clk at 792 MHz(OPP Turbo 4430) */
@@ -217,7 +217,7 @@ const struct dpll_params *get_mpu_dpll_params(void)
else if (omap_rev  OMAP4460_ES1_0)
return mpu_dpll_params_1600mhz[sysclk_ind];
else
-   return mpu_dpll_params_1840mhz[sysclk_ind];
+   return mpu_dpll_params_1400mhz[sysclk_ind];
 }
 
 const struct dpll_params *get_core_dpll_params(void)
@@ -280,7 +280,7 @@ void scale_vcores(void)
omap_rev = omap_revision();
/* TPS - supplies vdd_mpu on 4460 */
if (omap_rev = OMAP4460_ES1_0) {
-   volt = 1313;
+   volt = 1203;
do_scale_tps62361(TPS62361_REG_ADDR_SET1, volt);
}
 
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6?

[Aneesh V]

On Tuesday 07 February 2012 04:11 AM, Graeme Russ wrote:

Hi Wolfgang,

On Tue, Feb 7, 2012 at 9:27 AM, Wolfgang Denkw...@denx.de  wrote:

Dear Albert ARIBAUD,

In message4f304463.1050...@aribaud.net  you wrote:



In my experience, the offset is consistent on a given platform so once
you do the dance once to figure out where it'll be placed you can just
start off debugging post-relocation.


That's for a given platform *and* a given U-Boot build, since the U-Boot


...and for a given set of configured options and environment settings.

Change the size of the PRAM area, or change the resolution of your
graphics controller (and thus the size of the frame buffer), or change


The graphics controller memory may not be in main memory - It could be
in the PCI address space, in which case it may not affect the relocation
address


the size of the log buffer, or ...

There is a _plenty_ of reasons why the relocation address may change,
even for a given binary image and a given piece of hardware.


Note that x86's E820 address map tells the kernel which physical pages of
memory are reserved for system use - Paging takes care of defragmenting
the physical address space to provide the kernel and user mode code a
virtual linear address space. Technically, U-Boot does not need to be
relocated for x86 at all, even if we want to keep it in RAM - We just tell
the kernel that the physical address space that U-Boot resides in is
reserved

There are a lot of other arches besides PPC ;) And a lot of boards which
will be shipped with an extremely static configuration (lots of consumer
devices like set-top boxes etc only have one physical configuration)


I agree. Even on some platforms that are not fully static (such as having
variants with different memory sizes) the minimum available memory is
more than enough to allocate big enough partitions for each need at
U-Boot level. And my guess (or rather speculation) is that platforms
that do not have any real dynamic needs are in the majority. I sincerely 
believe that platforms should be allowed to enable/disable

relocation based on their needs.

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: Add option to disable code relocation

[Aneesh V]

On Monday 06 February 2012 08:19 PM, Tom Rini wrote:

On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russgraeme.r...@gmail.com  wrote:

Hi Wolfgang,

On 02/06/2012 06:51 PM, Wolfgang Denk wrote:

Dear Graeme Russ,

In messageCALButC+==qgs5eaahtqqu4zejqvg-3187ewaqu-fv3dwp5q...@mail.gmail.com  
you wrote:


I think the immediate focus should be on centralising the init sequence
processing into /common/init.c and then bringing the new'initcall'
architecture online


Agreed.


Once these have been done, any board can just specific:

SKIP_INIT(RELOC)


I will probably object to his, too - for the same reasons.


Considering this is a 'free' artefact of how the init sequence functions,
and that it is board specific and totally non-invasive for anyone else
(i.e. no ugly ifdef's anywhere else in the code) I'm surprised you would
object...


To pick up Wolfgang's argument, but why do we want to skip relocation?
  You can debug through it, it's documented (official wiki has GDB,
over in TI-land, the wiki page for CCS has the bits for doing it in
that Eclipse-based env, other debuggers I'm sure have a similar now
add symbols at this offset from link option) and the end result makes
it very easy for end-users to break their world (default kernel load
addrs being where U-Boot would be).


Why do all that circus if it's not adding any value for a given
platform. Also, in the previous thread on this I had pointed out a
specific case where this was hurting us. On a slow FPGA platform the
delay due to the relocation was getting magnified and un-necessarily
wasting our time.

best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 1/4] ARM: enable Thumb build

[Aneesh V]

On Tuesday 07 February 2012 12:15 AM, Tom Rini wrote:

On Mon, Feb 6, 2012 at 4:37 AM, Aneesh Vane...@ti.com  wrote:

Enable Thumb build and ARM-Thumb interworking based on the new
config flag CONFIG_SYS_THUMB_BUILD

Signed-off-by: Aneesh Vane...@ti.com

[snip]

-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
-PF_CPPFLAGS_ARM := $(call cc-option,-marm,)
+# Choose between ARM/Thumb instruction sets
+ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
+PF_CPPFLAGS_ARM += $(call cc-option, -mthumb -mthumb-interwork, \
+   -marm -mno-thumb-interwork)
+else
+PF_CPPFLAGS_ARM += $(call cc-option, -marm -mno-thumb-interwork)
+endif


We need the ':=' syntax to evaluate this once rather than for every
file we build.  Same with the rest of the changes here.



Oops! In my initial patch it was affecting PLATFORM_CPPFLAGS. When I
rebased it I didn't notice that PF_CPPFLAGS_ARM was defined for the
first time here. I will fix it.

Thanks,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 2/4] OMAP3+: fix issues with Thumb build

[Aneesh V]

On Tuesday 07 February 2012 02:36 AM, Albert ARIBAUD wrote:

Le 06/02/2012 12:37, Aneesh V a écrit :

When U-Boot/SPL is built using the Thumb instruction set the
toolchain has a potential issue with weakly linked symbols.
If a function has a weakly linked default implementation in C
and a real implementation in assembly GCC is confused about the
instruction set of the assembly implementation. As a result
the assembly function that is built in ARM is executed as
if it is Thumb. This results in a crash.

We need to investigate further to see if this is a toolchain
issue or an issue with our usage of it. In the meanwhile, we
can workaround the issue by having both the weakly linked alias
and the real implementation in C.


I would tend to NAK a patch submission where an issue is known and
investigation is considered but is actually bypassed by a workaround.
These tend to turn from 'temporary fix' to 'old crust' with time,
because there is no incentive for a better solution when the quick fix
works, after all.


Fair enough. I did actually report this to Linaro a long time back and
they had started looking into it. But then I couldn't support it
further due to some other activities that pre-empted it. I plan to
revive that thread now and I shall copy you on that. But in case the
issue is root-caused and the problem is indeed with the tool-chain,
then I hope you will accept this patch at least in the interest of
backward compatibility.

Also, I hope you don't object to taking the first patch, after fixing
the comments?

Thanks,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6?

[Aneesh V]

Hi Dirk,

On Friday 03 February 2012 12:55 PM, Dirk Behme wrote:

Hi,

on i.MX6 devices, e.g. ARM2 or SabreLite, the ROM boot loader copies the
U-Boot image from the boot device, e.g. the SD card, to the main memory.
This does mean that U-Boot is started in RAM.

With this, one might wonder why any relocation RAM - RAM is done anyway
and if this could be skipped?

Looking into the details shows that board_init_f() in
arch/arm/lib/board.c and relocate_code() in arch/arm/cpu/armv7/start.S
[1] are involved in this.

In board_init_f() the relocation destination address 'addr' is
calculated. This is basically at the end of the available RAM (- some
space for various stuff like TLB tables etc.). At SabreLite this results
in 0x4FF8D000.

By the boot loader, the U-Boot is loaded to

CONFIG_SYS_TEXT_BASE 0x1780

This results in relocate_code() copying U-Boot from RAM 0x1780 to
RAM 0x4FF8D000.

Setting CONFIG_SYS_TEXT_BASE to the relocation destination address
0x4FF8D000 does avoid the (unnecessary?) copy by

cmp r0, r6
moveq r9, #0 /* no relocation. relocation offset(r9) = 0 */
beq clear_bss /* skip relocation */

in relocate_code().

But:

1) The resulting image still runs without the relocation
(CONFIG_SYS_TEXT_BASE 0x4FF8D000). But e.g. the U-Boot command line
doesn't work properly any more. Most probably this is because not only
the copy is skipped by the 'beq clear_bss', but the whole 'fix .rel.dyn
relocations' is skipped too.

2) It's hard to set CONFIG_SYS_TEXT_BASE at compile time to the
relocation address calculated at runtime in board_init_f() due to the
amount of #ifdef and runtime calculation done there. So finding a
generic approach which could easily defined in the config files to avoid
the relocation seems difficult.


I haven't really completely read your mail. But here is an
implementation I had provided long time back for ARM. But Wolfgang
didn't want to take it. You can see the patch and the following
discussion in this thread:

http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/96352

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6?

[Aneesh V]

On Saturday 04 February 2012 04:30 PM, Albert ARIBAUD wrote:

Le 04/02/2012 10:15, Aneesh V a écrit :

Hi Dirk,

On Friday 03 February 2012 12:55 PM, Dirk Behme wrote:

Hi,

on i.MX6 devices, e.g. ARM2 or SabreLite, the ROM boot loader copies the
U-Boot image from the boot device, e.g. the SD card, to the main memory.
This does mean that U-Boot is started in RAM.

With this, one might wonder why any relocation RAM - RAM is done anyway
and if this could be skipped?

Looking into the details shows that board_init_f() in
arch/arm/lib/board.c and relocate_code() in arch/arm/cpu/armv7/start.S
[1] are involved in this.

In board_init_f() the relocation destination address 'addr' is
calculated. This is basically at the end of the available RAM (- some
space for various stuff like TLB tables etc.). At SabreLite this results
in 0x4FF8D000.

By the boot loader, the U-Boot is loaded to

CONFIG_SYS_TEXT_BASE 0x1780

This results in relocate_code() copying U-Boot from RAM 0x1780 to
RAM 0x4FF8D000.

Setting CONFIG_SYS_TEXT_BASE to the relocation destination address
0x4FF8D000 does avoid the (unnecessary?) copy by

cmp r0, r6
moveq r9, #0 /* no relocation. relocation offset(r9) = 0 */
beq clear_bss /* skip relocation */

in relocate_code().

But:

1) The resulting image still runs without the relocation
(CONFIG_SYS_TEXT_BASE 0x4FF8D000). But e.g. the U-Boot command line
doesn't work properly any more. Most probably this is because not only
the copy is skipped by the 'beq clear_bss', but the whole 'fix .rel.dyn
relocations' is skipped too.

2) It's hard to set CONFIG_SYS_TEXT_BASE at compile time to the
relocation address calculated at runtime in board_init_f() due to the
amount of #ifdef and runtime calculation done there. So finding a
generic approach which could easily defined in the config files to avoid
the relocation seems difficult.


I haven't really completely read your mail. But here is an
implementation I had provided long time back for ARM. But Wolfgang
didn't want to take it. You can see the patch and the following
discussion in this thread:

http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/96352


Recently there was an reminder by Wolfgang that debugging can be done
even with relocation, provided the symbols are dropped and reloaded in
gdb upon hitting the end of the relocate loop where the jump to (the new
location of) board_init_f happens --see
http://www.denx.de/wiki/view/DULG/WrongDebugSymbolsAfterRelocation.

I am not a specialist of gdb but I think it might be automated, too, so
that if you want to debug u-boot past relocation then you would just
have to enter a single command in gdb, or a script name when invoking
gdb, to load u-boot in low RAM , set a breakpoint at the pivot point
after relocation, run to that breakpoint, drop current symbols and
reload symbols with the adequate offset, possibly computed from some
accessible global.

Anyone itching enough to do some research and experiments on this?


I employ a different method using my JTAG debugger.

1. Look at the content of gd using the address from r8. Lauterbach
allows you to cast that address to a (structglobal_data *) and view
the contents.

2. Get reloc_off from gd and use that to relocate the symbols in
Trace32.

The advantage is that I can do all this after booting completely. No
breakpoint needed.

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] i.MX5/6 U-Boot: Cache enabling

[Aneesh V]

Hi Dirk,

On Saturday 04 February 2012 02:08 PM, Dirk Behme wrote:


Let's discuss how to enable the i.MX5/6 caches in U-Boot:

On 03.02.2012 12:00, Stefano Babic wrote:

On 03/02/2012 11:18, Dirk Behme wrote:

...

As your concerns are surely related to speed up the boot process, IMHO
we can focus efforts to add cache support for MX5 / MX6.


Ok, sounds good. Any idea what has to be done for this? Or what would be
the steps for this?


As armv7 architecture, the MX can profit of the work already done for
other SOCs. Functions for enabling / disabling / invalidate caches are
already provided, in arch/arm/lib and arch/arm/cpu/armv7/cache_v7.c. So
at least for MX5/MX6.

But we should change MXC drivers to be cache-aware. At least the FEC
driver and MMC driver are known to not work when dcache is on.


Marek, Troy, Fabio: What do you think is needed to make the i.MX5/6 FEC
driver cache-aware?

Jason, Stefano: And what do you think would be needed for the MMC driver?


Three is a generic README for ARM at doc/README.arm-caches

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] image: add support for Android's boot image format

[Aneesh V]

Dear Wolfgang,

On Tuesday 17 January 2012 02:46 PM, Aneesh V wrote:

Dear Wolfgang,

On Wednesday 23 November 2011 03:33 PM, Sebastian Andrzej Siewior wrote:

* Wolfgang Denk | 2011-11-22 20:04:47 [+0100]:


Dear Sebastian Andrzej Siewior,

In message2022123007.ga5...@linutronix.de you wrote:



+ * Redistribution and use in source and binary forms, with or
without
+ * modification, are permitted provided that the following
conditions
+ * are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above
copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.


Sorry, but this is not GPL compatible.


Ehm. Is this the All rights reserved issue? If so then I assumed that I
cleared up things in


No, it's the Redistributions in binary form must reproduce...
clause.


How so? If you distribute it as source nothing changes. I don't see much
difference in binary form either: section 1 of the GPL says

|.. keep intact all the notices that refer to this License and to the
|absence of any warranty; and give any other recipients of the Program a
|copy of this License along with the Program.

and this is no different. It does not mention whether the software has
to be passed in source or binary form. The BSD part does not push any
restrictions on the GPL, it wants the same thing. Section 6 of the GPL
says that by redistributing the receiptient should receive a copy of
this license. The section you mentioed is no different. If you
distribute GPL in binary code you have let the receiptient know, that he
is using GPL code. A note in the documentation is enough as far as I
know [if remeber correctly Harald went after a few companies which were
using Linux and were not letting the customers know about it].

If you look at the fresh released Quake3 source [0] you see that there
is a readme file which points out that it is GPL code and enumerates
various other licenses.

So right now, I don't see why those two should not be compatible. Plus
the FSF claims that they are [1].

[0] https://github.com/TTimo/doom3.gpl
[1] http://www.gnu.org/licenses/license-list.html#FreeBSD


What is your final call on this? The above arguments sound convincing
to me, but I have to admit that I am no legal expert. Either way, it
will be great to have a closure on this. Lack of fastboot support was
the greatest impediment to adoption of mainline U-Boot in our previous
platforms. It will be really unfortunate if the same happens to OMAP5
that has just arrived.


Ping.

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] arm: mmc: omap: spl size reduction by removing write/erase ops

[Aneesh V]

Tom,

On Thursday 02 February 2012 10:02 PM, Tom Rini wrote:

On Thu, Feb 2, 2012 at 6:04 AM, Balaji T Kbalaj...@ti.com  wrote:

spl for OMAP4 does not use mmc read/write.
Add CONFIG_MMC_NO_ERASE, CONFIG_MMC_NO_WRITE to platforms where mmc
write/erase operation is not needed in spl.
Use these CONFIGS to remove write/erase code in mmc.c and omap_hsmmc.c
This reduces the spl size by ~1128 Bytes


Are you running into a size limitation again?  If not, I think we want


We are always on the border. Minor fluctuations are affecting us. And
our EMU boards(secure devices) are permanently broken due to this. I am
not sure if this one helps EMU devices though.


to wait until we sort out how SPL includes/excludes stuff moving
forward as this shows there's probably a lot of other unused code
being pulled in.



We use -ffunction-sections -fdata-sections and --gc-sections while
building SPL. So, un-necessary stuff will not be included unless the
function pointers are set in some structures and not used. I think that
is what is happening in this case. Other than that I am not expecting
much scope for improvement.

One key experiment I want to do is Thumb mode build. I have some old
patches that I may cleanup and post sometime soon. But Thumb mode had
some tool-chain related issues last time I tried.

br,
Aneesh
___
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.

[Aneesh V]

Sughosh,

On Friday 20 January 2012 12:58 PM, Christian Riesch wrote:

On Thu, Jan 19, 2012 at 12:54 PM, Aneesh Vane...@ti.com  wrote:

On Thursday 19 January 2012 05:00 PM, Christian Riesch wrote:

On Thu, Jan 19, 2012 at 11:17 AM, Aneesh Vane...@ti.comwrote:

On Thursday 19 January 2012 12:23 PM, Sughosh Ganu wrote:

   Tried a few things on my end.
   * Read the D-cache value in the spl, and confirmed that the data
 cache is indeed not enabled.


What is the value of the B bit in CP15 SCR register? I wonder if RBL is
doing all the IMB operations required after copying the SPL image and
before executing it. IMB is required for consistency between data and
instruction sides.


Only if caches are used, right? Or also without caches?
Tom wrote that RBL does not turn on cache.
Regards, Christian


Only D-cache seems to be disabled in this case. I-cache and Write
buffer are likely to be enabled. If so, all the IMB operations except
the data-cache flushing are still relevant.


Tom, when you wrote that RBL does not turn on caches, did you mean it
never turns it on or it turns some of them on and turns them off
before exit?
Christian


Can you send the value of SCR you found at SPL entry? This will clarify
what's enabled and what's not.
___
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.

[Aneesh V]

On Friday 20 January 2012 02:51 PM, Christian Riesch wrote:

Hi Aneesh,

On Fri, Jan 20, 2012 at 9:52 AM, Aneesh Vane...@ti.com  wrote:

Sughosh,

[...]

Can you send the value of SCR you found at SPL entry? This will clarify
what's enabled and what's not.


I would like to try that on my board as well for comparison. Could you
please tell me how this register can be read? In the ARM manuals SCR
seems to have several meanings... Thank you!
Regards, Christian


If you have a JTAG based debugger that has the capability of displaying
CP15 registers, look for CP15 System Control Register. Otherwise you
will have to read it using an assembly instruction like below:

mrc p15, 0, r0, c1, c0, 0

After this instruction r0 will contain the SCR value. arm926ejs/start.S
has this instruction at line #367. You can put a breakpoint after this
and look at r0.

br,
Aneesh
___
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.

[Aneesh V]

Hi Christian,

On Friday 20 January 2012 06:18 PM, Christian Riesch wrote:

Hi Aneesh,

On Fri, Jan 20, 2012 at 1:13 PM, Aneesh Vane...@ti.com  wrote:

On Friday 20 January 2012 02:51 PM, Christian Riesch wrote:

On Fri, Jan 20, 2012 at 9:52 AM, Aneesh Vane...@ti.comwrote:

Sughosh,


[...]


Can you send the value of SCR you found at SPL entry? This will clarify
what's enabled and what's not.


I would like to try that on my board as well for comparison. Could you
please tell me how this register can be read? In the ARM manuals SCR
seems to have several meanings... Thank you!
Regards, Christian


If you have a JTAG based debugger that has the capability of displaying
CP15 registers, look for CP15 System Control Register. Otherwise you
will have to read it using an assembly instruction like below:


mrc p15, 0, r0, c1, c0, 0

After this instruction r0 will contain the SCR value. arm926ejs/start.S
has this instruction at line #367. You can put a breakpoint after this
and look at r0.


Thank you!

I don't have a JTAG debugger so I stored it in a register, pushed it
later to the stack and then read it with md.l from the memory. I tried
it on my custom board (AM1808 SoC, direct boot from NOR flash) and on
both the da850evm (with AM1808 SoC, AIS boot from SPI flash). The
result was the same for both cases, 0x00052078. So DCache and ICache
are disabled after the RBL.
Regards, Christian


Hmm.. That's different from the OMAP processors I have seen. At least
OMAP4, that I verified again now, leaves the I-cache enabled
(0x00C51878)

So, Sughosh's problem still remains a mystery:)

br,
Aneesh
___
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.

[Aneesh V]

Hi Sughosh,

On Thursday 19 January 2012 12:23 PM, Sughosh Ganu wrote:

On Tue Jan 17, 2012 at 08:27:58AM -0700, Tom Rini wrote:

On Mon, Jan 16, 2012 at 11:46 PM, Sughosh Ganuurwithsugh...@gmail.com  wrote:



Hmm.. how did u-boot work on such boards? How can u-boot work with D-Cache
enabled, if u-boot is not initializing it? (And I think, on davinci SoC
we have a none working uboot ethernet driver if d-cache is enabled too).
There must be a page_table in DRAM for using D-Cache in U-Boot, if u-boot
don't initialize it, it maybe overrides it ... or miss I something?


  Well, there is some data in the cache, which if not flushed creates
  problems on my board. I get the board to boot just by commenting out
  cpu_init_crit call. My hypothesis that the D-cache is enabled is
  simply because cache invalidation followed by cache disabling breaks
  the board, while flushing it prior to disabling gets it to boot
  fine. This(invalidation) would not have been a problem if the cache
  was in the disabled state.


Putting my TI hat on, I've confirmed with the RBL folks that they
aren't turning on ICACHE/DCACHE.


  Well, i'm not sure then why does the cache invalidation cause a
  problem on my platform. Btw, will this patch be
  accepted. Irrespective of the cache state on my board, it is not a
  wrong fix, and moreover results in the booting of my board.

  I haven't yet tried out reading the cache bit state in the spl. Will
  try out this experiment in a day or two, and share the results.


I think someone needs to look over this init code very carefully.  If
I can summarize from memory quickly, when we enable the
CP_CRITICAL_INITS code for everyone that exposed a problem on the
hawkboard that _looks_like_ DCACHE is enabled by RBL as changing the
code from doing an invalidate to a flush+invalidate fixes a problem.
But the manual says we should be doing flush+invalidate anyhow and the
RBL code is not turning on DCACHE.  Maybe we've got something else
being done not as the manual says and that's tickling another issue?


   Tried a few things on my end.
   * Read the D-cache value in the spl, and confirmed that the data
 cache is indeed not enabled.


What is the value of the B bit in CP15 SCR register? I wonder if RBL is
doing all the IMB operations required after copying the SPL image and
before executing it. IMB is required for consistency between data and
instruction sides. For instance after copying the SPL, the memory and
instruction cache could be incoherent. So, instruction cache needs to
be invalidated. In fact more needs to be done and there is an entire
chapter in the ARM926EJS TRM that discusses this (Chapter 9 -
Instruction Memory Barrier). Here is the key excerpt:

9.2 IMB operation
To ensure consistency between data and instruction sides, you must take
the following
steps:
1. Clean the DCache
2. Drain the write buffer
3. Synchronize data and instruction streams in level two AHB subsystems
4. Invalidate the ICache on page 9-4
5. Flush the prefetch buffer on page 9-4.

Ideally RBL should be doing all this before jumping to SPL. But, I
wonder if anything is missing in RBL and was getting done as a
side-effect of your flush.

Just a thought. Do you care to try 2-5 in SPL and see if it makes any
difference?(and avoid 1. in fact 1 seems to be the least useful thing
in our case!)



   * Enabled the data cache explicitly in cpu_init_crit, and booted
 u-boot. u-boot comes up fine, and trying a ping switches off the
 data cache with the warning message.


How are you enabling D-cache. Please note that just setting C bit
doesn't enable D-cache. MMU needs to be enabled (M bit) for D-cache to
be enabled. MMU in turn needs page-table. I wonder if you are doing all
this in cpu_init_crit()?

br,
Aneesh
___
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.

[Aneesh V]

On Thursday 19 January 2012 05:00 PM, Christian Riesch wrote:

Hi Aneesh,

On Thu, Jan 19, 2012 at 11:17 AM, Aneesh Vane...@ti.com  wrote:

On Thursday 19 January 2012 12:23 PM, Sughosh Ganu wrote:

   Tried a few things on my end.
   * Read the D-cache value in the spl, and confirmed that the data
 cache is indeed not enabled.

What is the value of the B bit in CP15 SCR register? I wonder if RBL is
doing all the IMB operations required after copying the SPL image and
before executing it. IMB is required for consistency between data and
instruction sides.


Only if caches are used, right? Or also without caches?
Tom wrote that RBL does not turn on cache.
Regards, Christian


Only D-cache seems to be disabled in this case. I-cache and Write
buffer are likely to be enabled. If so, all the IMB operations except
the data-cache flushing are still relevant.

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] image: add support for Android's boot image format

[Aneesh V]

Dear Wolfgang,

On Wednesday 23 November 2011 03:33 PM, Sebastian Andrzej Siewior wrote:

* Wolfgang Denk | 2011-11-22 20:04:47 [+0100]:


Dear Sebastian Andrzej Siewior,

In message2022123007.ga5...@linutronix.de  you wrote:



+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *  * Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ *  * Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in
+ *the documentation and/or other materials provided with the
+ *distribution.


Sorry, but this is not GPL compatible.


Ehm. Is this the All rights reserved issue? If so then I assumed that I
cleared up things in


No, it's the Redistributions in binary form must reproduce...
clause.


How so? If you distribute it as source nothing changes. I don't see much
difference in binary form either: section 1 of the GPL says

|.. keep intact all the notices that refer to this License and to the
|absence of any warranty; and give any other recipients of the Program a
|copy of this License along with the Program.

and this is no different. It does not mention whether the software has
to be passed in source or binary form. The BSD part does not push any
restrictions on the GPL, it wants the same thing. Section 6 of the GPL
says that by redistributing the receiptient should receive a copy of
this license. The section you mentioed is no different. If you
distribute GPL in binary code you have let the receiptient know, that he
is using GPL code. A note in the documentation is enough as far as I
know [if remeber correctly Harald went after a few companies which were
using Linux and were not letting the customers know about it].

If you look at the fresh released Quake3 source [0] you see that there
is a readme file which points out that it is GPL code and enumerates
various other licenses.

So right now, I don't see why those two should not be compatible. Plus
the FSF claims that they are [1].

[0] https://github.com/TTimo/doom3.gpl
[1] http://www.gnu.org/licenses/license-list.html#FreeBSD


What is your final call on this? The above arguments sound convincing
to me, but I have to admit that I am no legal expert. Either way, it
will be great to have a closure on this. Lack of fastboot support was
the greatest impediment to adoption of mainline U-Boot in our previous
platforms. It will be really unfortunate if the same happens to OMAP5
that has just arrived.

best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] OMAP3 performance regression in 2011.12

[Aneesh V]

Hi Joe,

On Monday 09 January 2012 09:18 PM, Joe Woodward wrote:

snip



(apologies for previous top posting, wasn't paying attention to what I was 
doing!)

I'm fairly certain...

If I take the 2011.12 uBoot release the kernel takes about twice the time to 
boot (compared to 2011.09), and the device is noticably slower.

Then if I comment out the v7_out_cache_disable() line in cpu.c and rebuild 
uBoot then everything speeds up again.

I thought the kernel would turn on the cache again too...

Is there any easy way from userspace to determine if the cache is on?


It won't be easy I believe, unless you have a debugger that allows you
to see CP15 registers.



I did a bit of Googling and found:
http://www.spinics.net/lists/arm-kernel/msg50064.html
http://www.spinics.net/lists/arm-kernel/msg50083.html

It may be that the kernel is re-enabling the L1 cache, but expecting L2 to be 
on?


Ideally kernel should be enabling L2 too. But looks like L2 was enabled
by ROM code itself in OMAP3, but D-cache disabled globally. So, it gets
enabled as soon as the D-cache is enabled globally.

L2$ in OMAP3 is a bit tricky. The cache is known to ARM but
enabling/disabling it and affecting secure entries needs ROM
assistance. So, while ARMv7 generic code can flush L2, we need OMAP
specific code to enable/disable it.

So, before my patch and before cache-support came to U-boot L2$ always
remained enabled. Since de-compressor's flush indeed flushed L2$ we
didn't get into any coherency problems.

Let the discussion in l-o conclude. I think fixing it in kernel is the
right thing to do. But if that's not possible, we can have a patch in
U-boot to work around it.

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] OMAP3 performance regression in 2011.12

[Aneesh V]

On Tuesday 17 January 2012 08:21 PM, Måns Rullgård wrote:

Aneesh Vane...@ti.com  writes:


Hi Joe,

On Monday 09 January 2012 09:18 PM, Joe Woodward wrote:


If I take the 2011.12 uBoot release the kernel takes about twice the
time to boot (compared to 2011.09), and the device is noticably
slower.

Then if I comment out the v7_out_cache_disable() line in cpu.c and
rebuild uBoot then everything speeds up again.

I thought the kernel would turn on the cache again too...
[...]
I did a bit of Googling and found:
http://www.spinics.net/lists/arm-kernel/msg50064.html
http://www.spinics.net/lists/arm-kernel/msg50083.html

It may be that the kernel is re-enabling the L1 cache, but expecting
L2 to be on?


Ideally kernel should be enabling L2 too. But looks like L2 was enabled
by ROM code itself in OMAP3, but D-cache disabled globally. So, it gets
enabled as soon as the D-cache is enabled globally.

L2$ in OMAP3 is a bit tricky. The cache is known to ARM but
enabling/disabling it and affecting secure entries needs ROM
assistance. So, while ARMv7 generic code can flush L2, we need OMAP
specific code to enable/disable it.


On OMAP3 ES2 and later, the L2EN bit in the auxiliary control register
is banked between secure and non-secure modes, so there is no need for
ROM calls to enable/disable the L2$ on these chips.


Yes, but IIRC, there was an erratum around it in some ARM revisions (I
think 3430 ES2 was affected) and the workaround was to keep both the
banked bits at the same value always. So, to keep things simple and
working for all revisions, I try to change both together. In the U-Boot
code where this is done I have added a comment on this.
___
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.

[Aneesh V]

On Friday 13 January 2012 11:08 PM, Sughosh Ganu wrote:

hi Heiko,

On Fri Jan 13, 2012 at 04:29:29PM +0100, Heiko Schocher wrote:

Hello Sugosh,

Sughosh Ganu wrote:

hi Christian,

On Fri Jan 13, 2012 at 09:06:26AM +0100, Christian Riesch wrote:

Hi Sughosh,
I had a look at the patch and I tried to understand what's going on
here (I must confess that I didn't know anything about this cache
stuff).


   Ok, thanks for taking time off to understand this issue.


On Tue, Jan 10, 2012 at 7:12 PM, Sughosh Ganuurwithsugh...@gmail.com  wrote:

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.


Hmm.. how did u-boot work on such boards? How can u-boot work with D-Cache
enabled, if u-boot is not initializing it? (And I think, on davinci SoC
we have a none working uboot ethernet driver if d-cache is enabled too).
There must be a page_table in DRAM for using D-Cache in U-Boot, if u-boot
don't initialize it, it maybe overrides it ... or miss I something?


   Well, there is some data in the cache, which if not flushed creates
   problems on my board. I get the board to boot just by commenting out
   cpu_init_crit call. My hypothesis that the D-cache is enabled is
   simply because cache invalidation followed by cache disabling breaks
   the board, while flushing it prior to disabling gets it to boot
   fine. This(invalidation) would not have been a problem if the cache
   was in the disabled state.


It would have affected if the state of dirty bits and valid bits are
not guaranteed at reset. But looks like cache entries are guaranteed to
be invalidated on reset in ARM926ejs per the spec (which is not the
case in ARMv7). In this case, I agree that flush shouldn't harm
anything ideally.





Are you sure, the RBL enables the D-Cache on your board? Nevertheless,
I think, we must disable the D-Cache here with cleaning it (as your
patch did) instead only invalidating it, as current code did.


   I am not sure, this is just my guess. By default, the caches are
   disabled on reset, so the only possible source is the rbl. But I
   don't have access to the rbl code to say for sure. Unfortunately i
   also don't have JTAG or any other debugger to dig more into


I will be surprised too if D-cache is enabled by ROM code. But I agree
that your problem and the solution seems to indicate something like
that. To be sure can you check the value of CP15 System control
register on SPL entry? You are already reading it. Can you save it
somewhere and spit it out later?


   this. But yes, like you mention, we must be cleaning the cache
   before disabling it, so this fix is correct.


I think it will be good to add an invalidate of I-cache too. You have
replaced an invalidate of I  D cache with a flush of only D-cache.

br,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V12 08/14] Add cache functions to SPL for armv7

[Aneesh V]

Hi Stefano,

On Wednesday 04 January 2012 09:25 AM, Stefano Babic wrote:

Signed-off-by: Stefano Babicsba...@denx.de
CC: Tom Rinitom.r...@gmail.com
CC: Wolfgang Denkw...@denx.de
CC: Simon Schwarzsimonschwarz...@gmail.com
---

Changes since V11:

- enable cache files in Makefile after checking build for OMAP4/5


How are you allocating memory for the page-tables(gd-tlb_addr)? Also
we need to take care of the complexities when u-boot runs after SPL.
Please have a look at this.

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/100012/match=spl+cache



  arch/arm/cpu/armv7/Makefile |2 --
  arch/arm/cpu/armv7/cpu.c|2 ++
  arch/arm/lib/Makefile   |5 +++--
  3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index f97fa3d..6b2addc 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -27,9 +27,7 @@ LIB   = $(obj)lib$(CPU).o

  START := start.o

-ifndef CONFIG_SPL_BUILD
  COBJS += cache_v7.o
-endif

  COBJS += cpu.o
  COBJS += syslib.o
diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index 662c496..c6fa8ef 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -52,7 +52,9 @@ int cleanup_before_linux(void)
 *
 * we turn off caches etc ...
 */
+#ifndef CONFIG_SPL_BUILD
disable_interrupts();
+#endif

/*
 * Turn off I-cache and invalidate it
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 300c8fa..39a9550 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -39,8 +39,6 @@ GLCOBJS   += div0.o

  COBJS-y   += board.o
  COBJS-y   += bootm.o
-COBJS-y+= cache.o
-COBJS-y+= cache-cp15.o
  COBJS-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
  COBJS-y   += interrupts.o
  COBJS-y   += reset.o
@@ -48,6 +46,9 @@ SOBJS-$(CONFIG_USE_ARCH_MEMSET) += memset.o
  SOBJS-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
  endif

+COBJS-y+= cache.o
+COBJS-y+= cache-cp15.o
+
  SRCS  := $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \
   $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
  OBJS  := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot