| Message ID | 1355467767-29575-47-git-send-email-sjg@chromium.org |
|---|---|
| State | Accepted, archived |
| Delegated to: | Tom Rini |
| Headers | show |
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
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/14/2013 11:11 AM, Andreas Biemann 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 Biemann >> <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-----
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 Biemann 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 Biemann >>> <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
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")
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(-)