Patchwork [U-Boot,v2,46/58] avr32: Use generic global_data

login
register
mail settings
Submitter Simon Glass
Date Dec. 14, 2012, 6:49 a.m.
Message ID <1355467767-29575-47-git-send-email-sjg@chromium.org>
Download mbox | patch
Permalink /patch/206352/
State Accepted, archived
Delegated to: Tom Rini
Headers show

Comments

Simon Glass - Dec. 14, 2012, 6:49 a.m.
Move avr32 over to use generic global_data.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None

 arch/avr32/include/asm/global_data.h |   29 +----------------------------
 1 files changed, 1 insertions(+), 28 deletions(-)
Andreas Bießmann - Feb. 14, 2013, 10:29 a.m.
Dear Simon Glass,

On 12/14/2012 07:49 AM, Simon Glass wrote:
> Move avr32 over to use generic global_data.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

this one produces compile warning in board.c for mimc200, I will try to
fix it but can not test it on real hardware (cc'ing board maintainer).

Best regards

Andreas Bießmann
Simon Glass - Feb. 14, 2013, 2:25 p.m.
Hi Andreas,

On Thu, Feb 14, 2013 at 2:29 AM, Andreas Bießmann
<andreas.devel@googlemail.com> wrote:
> Dear Simon Glass,
>
> On 12/14/2012 07:49 AM, Simon Glass wrote:
>> Move avr32 over to use generic global_data.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>
> this one produces compile warning in board.c for mimc200, I will try to
> fix it but can not test it on real hardware (cc'ing board maintainer).

Actually these boards failed for be even before the patch:

         avr32:   + hammerhead  + atngw100mkii  + grasshopper  + favr-32-ezkit
    + atstk1006  + atstk1004  + atstk1003  + atstk1002  + atngw100  + mimc200

It might be my toolchain - can you suggest an avr32 toolchain to use?

>
> Best regards
>
> Andreas Bießmann

Regards,
Simon
Andreas Bießmann - Feb. 14, 2013, 4:11 p.m.
Hi Simon,

On 02/14/2013 03:25 PM, Simon Glass wrote:
> Hi Andreas,
> 
> On Thu, Feb 14, 2013 at 2:29 AM, Andreas Bießmann
> <andreas.devel@googlemail.com> wrote:
>> Dear Simon Glass,
>>
>> On 12/14/2012 07:49 AM, Simon Glass wrote:
>>> Move avr32 over to use generic global_data.
>>>
>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>
>> this one produces compile warning in board.c for mimc200, I will try to
>> fix it but can not test it on real hardware (cc'ing board maintainer).
> 
> Actually these boards failed for be even before the patch:
> 
>          avr32:   + hammerhead  + atngw100mkii  + grasshopper  + favr-32-ezkit
>     + atstk1006  + atstk1004  + atstk1003  + atstk1002  + atngw100  + mimc200
> 
> It might be my toolchain - can you suggest an avr32 toolchain to use?

Not currently, I use a self patched OSELAS toolchain which is not yet
mainline. Maybe I should try to add avr32 toolchain to ELDK for reference?

Which errors do you see? Is it like this:

---8<---
avr32-ld:built in linker script:15: warning: memory region `FLASH' not
declared
avr32-ld:built in linker script:69: warning: memory region `CPUSRAM' not
declared
...
--->8---

Unfortunately the avr32-newlib toolchains currently _not_ supported in
u-boot (I've seen a strange runtime error with the atmel provided newlib
toolchain before), you will need avr32-uclibc toolchain instead.

Best regards

Andreas Bießmann
Tom Rini - Feb. 14, 2013, 4:15 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/14/2013 11:11 AM, Andreas Bie￟mann wrote:
> Hi Simon,
> 
> On 02/14/2013 03:25 PM, Simon Glass wrote:
>> Hi Andreas,
>> 
>> On Thu, Feb 14, 2013 at 2:29 AM, Andreas Bie￟mann 
>> <andreas.devel@googlemail.com> wrote:
>>> Dear Simon Glass,
>>> 
>>> On 12/14/2012 07:49 AM, Simon Glass wrote:
>>>> Move avr32 over to use generic global_data.
>>>> 
>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>> 
>>> this one produces compile warning in board.c for mimc200, I
>>> will try to fix it but can not test it on real hardware (cc'ing
>>> board maintainer).
>> 
>> Actually these boards failed for be even before the patch:
>> 
>> avr32:   + hammerhead  + atngw100mkii  + grasshopper  +
>> favr-32-ezkit + atstk1006  + atstk1004  + atstk1003  + atstk1002
>> + atngw100  + mimc200
>> 
>> It might be my toolchain - can you suggest an avr32 toolchain to
>> use?
> 
> Not currently, I use a self patched OSELAS toolchain which is not
> yet mainline. Maybe I should try to add avr32 toolchain to ELDK for
> reference?

The "short" answer is that if OpenEmbedded supports avr32 (and I'm a
little rusty, but I see general avr32 bits and pieces) then yes,
taking ELDK and building for AVR32 should be doable, or at least
provide an interesting failure :)

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRHQ2OAAoJENk4IS6UOR1Wui0P/A3ca4yl3IQ+oaqdUsl0rdR1
nYue7uOw2tOarTh3AACs04vE38gg0q9UHsUHYT+nEaKMiql6IiStab4J8Xz4wDOt
KAqctaZtgaO3OHDAuESXy3S6hJQx90o/y3dsNoy1aQtPwdedfxnixcFPYdJYndG+
Y9HgJszxQpLsOZPakFvb36TUlQeATpACJqvnpPsQ16gu6YiaNHZecGJLX6EQg7hc
e5hKFpHikA0n5Fy+SbrPpUQh8AXnJcLXU/8muTacSUoiuO+IgauAbPJQeDZ7uxaY
75Gbhqczlb3wtn/2KQf7UdE5n7frkVmy+fkJK/SC0MJtCqS/HVAuWc5x5NfZCUgz
eYFtxDp7DHQ4OZxTx5nvW6G2ZYsJAKUO6568w2pV14ZZbtAX/dM9H9LaDvTuz6r7
iYyPfslEcvM+pLvFWkOxnJiaYBfuHzZ+mDl7wTw/H0aXFiO5ZDk/uzO9ZANtY1I1
5xRZ3Cugi+QubpbSaQ4h96qALVD2ie7BU0nuhTj47tlk8eAM3IzWJJH2B3Tv7HB+
12vZ5wh1T2ARAY633FvUcqTNWhjAKMpE1xpeUzjZWXcE94nIDtHZfUChyTwfx4CA
1NS+GezjA/y0z6bDGPOWKKqfdCweDIRg2tIctjbl6anAhnNopUfJlZjKu5jHcQSm
MAifg/0XYkPdFq2nVPBC
=Rktw
-----END PGP SIGNATURE-----
Simon Glass - Feb. 28, 2013, 1:22 a.m.
Hi,

On Thu, Feb 14, 2013 at 8:15 AM, Tom Rini <trini@ti.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/14/2013 11:11 AM, Andreas Bie￟mann wrote:
>> Hi Simon,
>>
>> On 02/14/2013 03:25 PM, Simon Glass wrote:
>>> Hi Andreas,
>>>
>>> On Thu, Feb 14, 2013 at 2:29 AM, Andreas Bie￟mann
>>> <andreas.devel@googlemail.com> wrote:
>>>> Dear Simon Glass,
>>>>
>>>> On 12/14/2012 07:49 AM, Simon Glass wrote:
>>>>> Move avr32 over to use generic global_data.
>>>>>
>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>
>>>> this one produces compile warning in board.c for mimc200, I
>>>> will try to fix it but can not test it on real hardware (cc'ing
>>>> board maintainer).
>>>
>>> Actually these boards failed for be even before the patch:
>>>
>>> avr32:   + hammerhead  + atngw100mkii  + grasshopper  +
>>> favr-32-ezkit + atstk1006  + atstk1004  + atstk1003  + atstk1002
>>> + atngw100  + mimc200
>>>
>>> It might be my toolchain - can you suggest an avr32 toolchain to
>>> use?
>>
>> Not currently, I use a self patched OSELAS toolchain which is not
>> yet mainline. Maybe I should try to add avr32 toolchain to ELDK for
>> reference?
>
> The "short" answer is that if OpenEmbedded supports avr32 (and I'm a
> little rusty, but I see general avr32 bits and pieces) then yes,
> taking ELDK and building for AVR32 should be doable, or at least
> provide an interesting failure :)

Well if someone can point me to a binary or a build script I would
very much like to get an avr32 toolchain that fully works.

Thanks,
Simon

Patch

diff --git a/arch/avr32/include/asm/global_data.h b/arch/avr32/include/asm/global_data.h
index aeb6605..a71f199 100644
--- a/arch/avr32/include/asm/global_data.h
+++ b/arch/avr32/include/asm/global_data.h
@@ -28,34 +28,7 @@  struct arch_global_data {
 	unsigned long cpu_hz;		/* cpu core clock frequency */
 };
 
-/*
- * The following data structure is placed in some memory wich is
- * available very early after boot (like DPRAM on MPC8xx/MPC82xx, or
- * some locked parts of the data cache) to allow for a minimum set of
- * global variables during system initialization (until we have set
- * up the memory controller so that we can use RAM).
- */
-
-typedef	struct	global_data {
-	bd_t		*bd;
-	unsigned long	flags;
-	unsigned int	baudrate;
-	unsigned long	have_console;	/* serial_init() was called */
-#ifdef CONFIG_PRE_CONSOLE_BUFFER
-	unsigned long	precon_buf_idx;	/* Pre-Console buffer index */
-#endif
-	unsigned long	reloc_off;	/* Relocation Offset */
-	unsigned long	env_addr;	/* Address of env struct */
-	unsigned long	env_valid;	/* Checksum of env valid? */
-#if defined(CONFIG_LCD)
-	void		*fb_base;	/* framebuffer address */
-#endif
-	void		**jt;		/* jump table */
-	char		env_buf[32];	/* buffer for getenv() before reloc. */
-	struct arch_global_data arch;	/* architecture-specific data */
-} gd_t;
-
-#include <asm-generic/global_data_flags.h>
+#include <asm-generic/global_data.h>
 
 #define DECLARE_GLOBAL_DATA_PTR register gd_t *gd asm("r5")