Re: [U-Boot] ARM Pull Request
Jean-Christophe PLAGNIOL-VILLARD wrote: > On 07:37 Sat 05 Sep , Dirk Behme wrote: >> Dear Jean-Christophe, >> >> Jean-Christophe PLAGNIOL-VILLARD wrote: >>> Hi, >>> >>> Please pull >>> The following changes since commit 3aa8b68d80dbcb6829af60485c1e388b39af793d: >>> Wolfgang Denk (1): >>>Merge branch 'next' of ../next >>> >>> are available in the git repository at: >>> >>> git://git.denx.de/u-boot-arm.git master >>> >>> Albin Tonnerre (3): >>> at91sam9260/afeb9260: Fix SPI initialization >>> Add support for the Calao SBC35-A9G20 board >>> Support for the Calao TNY-A9260/TNY-A9G20 boards >>> >>> Frederik Kriewitz (1): >>> Add support for the DevKit8000 board >> I'd like to have the omap3_devkit8000.h version of that patch, instead. > this one is fine no need not the omap3_devkit8000 version Jean-Christophe: In http://lists.denx.de/pipermail/u-boot/2009-August/059087.html we agreed on omap3_devkit8000. >> Additionally, >> >> http://lists.denx.de/pipermail/u-boot/2009-August/058492.html > as I said now more than 10 times Jean-Christophe: I doubt that you mentioned this more than 10 times ;) > on omap3 we can use the generic ARMV7 cache > code as on Samsung Jean-Christophe: Unfortunately, this is not the topic we are talking about here. At the moment we are talking about a) Moving the existing code to an OMAP3 specific directory so that others can go on. Not stalling them any longer. b) By doing (a), making sure not changing/breaking any existing code/functionality c) http://lists.denx.de/pipermail/u-boot/2009-August/058543.html And if you insist on your "we don't need this code", please re-read http://lists.denx.de/pipermail/u-boot/2009-August/059026.html All: The main topic here is (a). So somebody with commit rights: Please apply http://lists.denx.de/pipermail/u-boot/2009-August/058492.html so that others, mainly Samsung, can go on and isn't stalled further. OMAP3 specific discussion can go on in an other thread, then. Many thanks and best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Warning in omap3_mmc.c
Recent U-Boot head gives (e.g. for omap3_beagle_config)
omap3_mmc.c: In function 'mmc_detect_card':
omap3_mmc.c:279: warning: dereferencing type-punned pointer will break
strict-aliasing rules
omap3_mmc.c:292: warning: dereferencing type-punned pointer will break
strict-aliasing rules
omap3_mmc.c:336: warning: dereferencing type-punned pointer will break
strict-aliasing rules
omap3_mmc.c: In function 'configure_mmc':
omap3_mmc.c:460: warning: dereferencing type-punned pointer will break
strict-aliasing rules
omap3_mmc.c:461: warning: dereferencing type-punned pointer will break
strict-aliasing rules
omap3_mmc.c:462: warning: dereferencing type-punned pointer will break
strict-aliasing rules
omap3_mmc.c:463: warning: dereferencing type-punned pointer will break
strict-aliasing rules
This is from e.g.
279: ocr_recvd = ((mmc_resp_r3 *) resp)->ocr;
336: mmc_card_cur->RCA = ((mmc_resp_r6 *) resp)->newpublishedrca;
with
unsigned int resp[4];
and
typedef struct {
unsigned int ocr;
} mmc_resp_r3;
typedef struct {
unsigned short cardstatus;
unsigned short newpublishedrca;
} mmc_resp_r6;
Any idea how to fix this?
Many thanks
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v1] mpc8260: move FDT memory node fixup into common CPU code.
Hello Marcel, Marcel ziswiler wrote: > Move the memory node fixup of the MPC8260ADS, ids8247 and muas3001 boards into > common mpc8260 CPU code. > Remove Ethernet node fixup from muas3001 board and modify its config for the > common mpc8260 code to use generic Ethernet fixup. Thanks for cleaning up, but ... > Signed-off-by: Marcel Ziswiler > --- > board/freescale/mpc8260ads/mpc8260ads.c | 13 > board/ids8247/ids8247.c | 16 -- > board/muas3001/muas3001.c | 51 +- > cpu/mpc8260/cpu.c |1 + > include/configs/muas3001.h |1 + > 5 files changed, 4 insertions(+), 78 deletions(-) ... I couldn;t apply your patch, because your patch is line wrapped. Can you fix your mailer? Also, there is one more 826x based board (mgcoge) with should be fixed too, can you add this board to your patch? TIA, bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Reset i2c slave devices during init on mpc5xxx cpus
Hello Eric, Eric Millbrandt wrote: > Reset any i2c devices that may have been interrupted during a system reset. > Normally this would be accomplished by clocking the line until SCL and SDA > are released and then sending a start condtiion (From an Atmel datasheet). > There is no direct access to the i2c pins so instead create start commands > through the i2c interface. Send a start command then delay for the SDA Hold > time, repeat this by disabling/enabling the bus a total of 9 times. > > Signed-off-by: Eric Millbrandt > --- > > changes since v1 > - Fixed compiler warning Applied to u-boot-i2c.git Thanks for your work, bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_i2c: increase I2C timeout values and make them configurable
Hello Timur, Timur Tabi wrote: > The value of I2C_TIMEOUT in fsl_i2c.c has several problems. First, it is > defined as CONFIG_HZ/4, but it is used as a count of microseconds, so it makes > no sense to derive it from a clock rate. Second, the current value (250) is > too low for some boards, so it needs to be increased. Third, the timeout > necessary for multiple-master arbitration is larger than the timeout for basic > read/write operations, so we shouldn't have a single constant for both > timeouts. > Finally, it would be nice if we could override these values on a per-board > basis. > > Signed-off-by: Timur Tabi > --- > drivers/i2c/fsl_i2c.c | 24 > 1 files changed, 20 insertions(+), 4 deletions(-) Applied to u-boot-i2c.git Thanks for your work, bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
Hello Wolfgang, The following changes since commit 9f23ca42b3ba19b24e66fade572f2b86d929b6e8: Wolfgang Denk (1): ARM: Update mach-types are available in the git repository at: git://git.denx.de/u-boot-i2c.git master Eric Millbrandt (1): Reset i2c slave devices during init on mpc5xxx cpus Timur Tabi (1): fsl_i2c: increase I2C timeout values and make them configurable README |7 ++ cpu/mpc5xxx/i2c.c| 49 ++ drivers/i2c/fsl_i2c.c| 24 +--- include/configs/galaxy5200.h |1 + 4 files changed, 77 insertions(+), 4 deletions(-) -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
Hello Wolfgang, Sorry, wrong subject ... should be [U-Boot] i2c Pull Request ... No idea, how this happend ... (seems, i digged actually to long in an error on an arm plattform ;-) Heiko Schocher wrote: > Hello Wolfgang, > > The following changes since commit 9f23ca42b3ba19b24e66fade572f2b86d929b6e8: > Wolfgang Denk (1): > ARM: Update mach-types > > are available in the git repository at: > > git://git.denx.de/u-boot-i2c.git master > > Eric Millbrandt (1): > Reset i2c slave devices during init on mpc5xxx cpus > > Timur Tabi (1): > fsl_i2c: increase I2C timeout values and make them configurable > > README |7 ++ > cpu/mpc5xxx/i2c.c| 49 > ++ > drivers/i2c/fsl_i2c.c| 24 +--- > include/configs/galaxy5200.h |1 + > 4 files changed, 77 insertions(+), 4 deletions(-) > > bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
Wolfgang, Dirk, I can take responsibility for TI DaVinci SOCs. Thanks, Sandeep From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] On Behalf Of Dirk Behme [dirk.be...@googlemail.com] Sent: Saturday, September 05, 2009 3:39 AM To: Wolfgang Denk Cc: Tom Rix; Kyungmin Park; u-boot@lists.denx.de; Magnus Lilja; Minkyu Kang Subject: Re: [U-Boot] RFC: split ARM repo and distribute workload Dear Wolfgang, Wolfgang Denk wrote: > Texas Instruments (OMAP): Dirk Behme? > Or are there any volunteers at TI? I really like to see someone from TI here, instead. Looking at some past discussions, I think somebody from TI would be the best. E.g.: - While discussing the board/vendor directory change, we were unsure who might be the vendor of which board. Somebody from TI would know best. - While discussing the OMAP3 cache move, we were unsure what's about the ROM code calling and where/when this is necessary. Someone from TI would know best, too. - etc, etc. Best regards Dirk ___ 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 2/8] USB add macros for debugging usb device setup.
Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 15:12 Fri 04 Sep , Tom Rix wrote:
>
>> When developing usb device features, it is useful to print out
>> common usb structures.
>>
>> Signed-off-by: Tom Rix
>> ---
>> include/usbdescriptors.h | 31 +
>> include/usbdevice.h | 105
>> ++
>> 2 files changed, 136 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/usbdescriptors.h b/include/usbdescriptors.h
>> index ea05672..f4e33b6 100644
>> --- a/include/usbdescriptors.h
>> +++ b/include/usbdescriptors.h
>> @@ -510,4 +510,35 @@ struct usb_class_descriptor {
>>
>> } __attribute__ ((packed));
>>
>> +#ifdef DEBUG
>> +#define PRINT_DEVICE_DESCRIPTOR(d) \
>>
> inline will be better
>
Yes. I agree.
Tom
> Best Regards,
> J.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] OMAP3 zoom2 Use usbtty if the debug board is not connected.
Jean-Christophe PLAGNIOL-VILLARD wrote: > On 15:12 Fri 04 Sep , Tom Rix wrote: > >> The preferred serial output comes from the debug board. >> When the debug board is disconnected, fall back on using >> usbtty from the usb connector on the Zoom2 board. >> >> This shows up as /dev/ttyACM0 in a linux host. >> >> Signed-off-by: Tom Rix >> --- >> board/omap3/zoom2/zoom2_serial.c | 16 >> include/configs/omap3_zoom2.h| 17 + >> 2 files changed, 33 insertions(+), 0 deletions(-) >> >> diff --git a/board/omap3/zoom2/zoom2_serial.c >> b/board/omap3/zoom2/zoom2_serial.c >> index a3d777d..434696a 100644 >> --- a/board/omap3/zoom2/zoom2_serial.c >> +++ b/board/omap3/zoom2/zoom2_serial.c >> @@ -87,6 +87,10 @@ void quad_putc_dev (unsigned long base, const char c) >> >> NS16550_putc ((NS16550_t) base, c); >> } >> +#ifdef CONFIG_USB_TTY >> > why not do this > #ifndef CONFIG_USB_TTY > #define usbtty_putc(c) > #define usbtty_puts(s) > #define usbtty_getc() 0 > #define usbtty_tstc() 0 > #endif > > and then avoid the ifdef > > Yes I agree. I will add stubs to the declarations in serial.h Tom > Best Regards, > J. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
On 09:12 Sun 06 Sep , Dirk Behme wrote: > Jean-Christophe PLAGNIOL-VILLARD wrote: > >On 07:37 Sat 05 Sep , Dirk Behme wrote: > >>Dear Jean-Christophe, > >> > >>Jean-Christophe PLAGNIOL-VILLARD wrote: > >>>Hi, > >>> > >>>Please pull > >>>The following changes since commit > >>>3aa8b68d80dbcb6829af60485c1e388b39af793d: > >>> Wolfgang Denk (1): > >>> Merge branch 'next' of ../next > >>> > >>>are available in the git repository at: > >>> > >>> git://git.denx.de/u-boot-arm.git master > >>> > >>>Albin Tonnerre (3): > >>> at91sam9260/afeb9260: Fix SPI initialization > >>> Add support for the Calao SBC35-A9G20 board > >>> Support for the Calao TNY-A9260/TNY-A9G20 boards > >>> > >>>Frederik Kriewitz (1): > >>> Add support for the DevKit8000 board > >>I'd like to have the omap3_devkit8000.h version of that patch, instead. > >this one is fine no need not the omap3_devkit8000 version > > Jean-Christophe: In > > http://lists.denx.de/pipermail/u-boot/2009-August/059087.html > > we agreed on omap3_devkit8000. in v4 the author prefer it devkit8000 so I respect it > >on omap3 we can use the generic ARMV7 cache > >code as on Samsung > > Jean-Christophe: Unfortunately, this is not the topic we are talking > about here. yes it's, as intead of fix the code we just move it > > At the moment we are talking about > > a) Moving the existing code to an OMAP3 specific directory so that > others can go on. Not stalling them any longer. > > b) By doing (a), making sure not changing/breaking any existing > code/functionality > > c) http://lists.denx.de/pipermail/u-boot/2009-August/058543.html > > And if you insist on your "we don't need this code", please re-read > > http://lists.denx.de/pipermail/u-boot/2009-August/059026.html Yes I insist to remove the code and use a generic code as much we can for the l2_cache I'm fine to move to omap3 as it's really omap3 specific but I do want to have the generic v7_flush_dcache_all use for omap3 too > > > All: The main topic here is (a). So somebody with commit rights: No the topic here is to do the right thing move code which need to be re-write is incorrect as Samsung will re-introduce the v7_flush_dcache_all for their soc so where they will store it? in cpu/arm_cortexa8/samsung/cache.S and if we add a new soc which will need the code we will duplicate it agains no we clearly need to clean the omap3 and not force other soc to duplicate code just because on soc Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Warning in omap3_mmc.c
On 09:55 Sun 06 Sep , Dirk Behme wrote:
>
> Recent U-Boot head gives (e.g. for omap3_beagle_config)
>
> omap3_mmc.c: In function 'mmc_detect_card':
>
> omap3_mmc.c:279: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> omap3_mmc.c:292: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> omap3_mmc.c:336: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> omap3_mmc.c: In function 'configure_mmc':
>
> omap3_mmc.c:460: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> omap3_mmc.c:461: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> omap3_mmc.c:462: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> omap3_mmc.c:463: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
>
> This is from e.g.
>
> 279: ocr_recvd = ((mmc_resp_r3 *) resp)->ocr;
> 336: mmc_card_cur->RCA = ((mmc_resp_r6 *) resp)->newpublishedrca;
>
> with
>
> unsigned int resp[4];
>
> and
>
> typedef struct {
> unsigned int ocr;
> } mmc_resp_r3;
>
> typedef struct {
> unsigned short cardstatus;
> unsigned short newpublishedrca;
> } mmc_resp_r6;
>
> Any idea how to fix this?
try to create a union
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for Eukrea CPU9260/CPU9G20 SBC
On 18:15 Sat 05 Sep , Eric Benard wrote: > these boards are built around Atmel's AT91SAM9260/9G20 and have > up to 64MB of NOR flash, up to 128MB of SDRAM, up to 2GB of NAND > and include a 10/100 Ethernet PHY in RMII mode. > > Signed-off-by: Eric Benard > --- > MAINTAINERS|5 + > MAKEALL|2 + > Makefile |8 + > board/eukrea/cpu9260/Makefile | 59 + > board/eukrea/cpu9260/config.mk |1 + > board/eukrea/cpu9260/cpu9260.c | 218 + > board/eukrea/cpu9260/led.c | 153 > cpu/arm926ejs/at91/lowlevel_init.S |3 +- > include/configs/cpu9260.h | 453 > > 9 files changed, 901 insertions(+), 1 deletions(-) > create mode 100644 board/eukrea/cpu9260/Makefile > create mode 100644 board/eukrea/cpu9260/config.mk > create mode 100644 board/eukrea/cpu9260/cpu9260.c > create mode 100644 board/eukrea/cpu9260/led.c > create mode 100644 include/configs/cpu9260.h > it's looks fine Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] OMAP3 Add usb device support
Jean-Christophe PLAGNIOL-VILLARD wrote:
> Hi,
>
> please be carefull you have a lot's of ligne which exceed 80 chars
> limit
>
>
Yes I saw these from check_patch.
I will try to reduce these.
>> +
>> +/* Define MUSB_DEBUG before including this file to get debug macros */
>> +#ifdef MUSB_DEBUG
>> +
>> +static inline void MUSB_PRINT_PWR(u8 b)
>>
> please lowercase
>
OK
>> +{
>> +serial_printf("\tpower 0x%2.2x\n", b);
>>
> maybe a macro will simplify the code
> #define MUSB_FLAGS_PRINT(x, y)\
> if (b & MUSB_##x_##y) \
> serial_printf("\t\t"#y"\n");
>
> static inline void musb_print_pwr(u8 b)
> {
> serial_printf("\tpower 0x%2.2x\n", b);
> MUSB_FLAGS_PRINT(POWER, ISOUPDATE);
> MUSB_FLAGS_PRINT(POWER, SOFTCONN);
> MUSB_FLAGS_PRINT(POWER, HSENAB);
> MUSB_FLAGS_PRINT(POWER, HSMODE);
> MUSB_FLAGS_PRINT(POWER, RESET);
> MUSB_FLAGS_PRINT(POWER, RESUME);
> MUSB_FLAGS_PRINT(POWER, SUSPENDM);
> MUSB_FLAGS_PRINT(POWER, ENSUSPEND);
> }
> and so on
>
Thanks.
I will give this a try.
>> +
>> +static inline void MUSB_PRINT_CSR0(u16 w)
>>
> please lowercase and so on
>
>> +{
>> +serial_printf("\tcsr00x%4.4x\n", w);
>> +if (w & MUSB_CSR0_FLUSHFIFO)
>> +serial_printf("\t\tFLUSHFIFO\n");
>> +if (w & MUSB_CSR0_P_SVDSETUPEND)
>> +serial_printf("\t\tSERV_SETUPEND\n");
>> +if (w & MUSB_CSR0_P_SVDRXPKTRDY)
>> +serial_printf("\t\tSERV_RXPKTRDY\n");
>> +if (w & MUSB_CSR0_P_SENDSTALL)
>> +serial_printf("\t\tSENDSTALL\n");
>> +if (w & MUSB_CSR0_P_SETUPEND)
>> +serial_printf("\t\tSETUPEND\n");
>> +if (w & MUSB_CSR0_P_DATAEND)
>> +serial_printf("\t\tDATAEND\n");
>> +if (w & MUSB_CSR0_P_SENTSTALL)
>> +serial_printf("\t\tSENTSTALL\n");
>> +if (w & MUSB_CSR0_TXPKTRDY)
>> +serial_printf("\t\tTXPKTRDY\n");
>> +if (w & MUSB_CSR0_RXPKTRDY)
>> +serial_printf("\t\tRXPKTRDY\n");
>> +}
>> +
>>
>
>
>> +
>> +#define MAX_ENDPOINT 15
>>
> maybe we can put it configurable
>
I will see
>> +
>> +#define GET_ENDPOINT(dev,ep)
>> \
>> +(((struct usb_device_instance *)(dev))->bus->endpoint_array + ep)
>> +
>> +#define SET_EP0_STATE(s)\
>> +do {
>> \
>> +if ((0 <= (s)) && (SET_ADDRESS >= (s))) { \
>> +if ((s) != ep0_state) { \
>> +if ((debug_setup) && (debug_level > 1)) \
>> +serial_printf("INFO : Changing state from %s to
>> %s in %s at line %d\n", ep0_state_strings[ep0_state], ep0_state_strings[s],
>> __PRETTY_FUNCTION__, __LINE__); \
>>
> too long please split
>
>> +ep0_state = s; \
>> +} \
>> +} else {\
>> +if (debug_level > 0)\
>> +serial_printf("Error at %s %d with setting state %d is
>> invalid\n", __PRETTY_FUNCTION__, __LINE__, s); \
>>
> too long please split
>
Ok.
>> +} \
>> +} while (0)
>> +
>> +/* static implies these initialized to 0 or NULL */
>> +static int debug_setup;
>> +static int debug_level;
>> +static struct musb_epinfo epinfo[MAX_ENDPOINT * 2];
>> +static enum ep0_state_enum { IDLE = 0, TX, RX, SET_ADDRESS } ep0_state =
>> IDLE;
>>
> this will be better
> static enum ep0_state_enum {
> IDLE = 0,
> TX,
> RX,
> SET_ADDRESS
> } ep0_state = IDLE;
>
ok
>> +static char *ep0_state_strings[4] = {
>> +"IDLE",
>> +"TX",
>> +"RX",
>> +"SET_ADDRESS",
>> +};
>> +
>> +static struct urb *ep0_urb;
>> +struct usb_endpoint_instance *ep0_endpoint;
>> +static struct usb_device_instance *udc_device;
>> +static int enabled;
>> +
>> +#ifdef MUSB_DEBUG
>> +static void musb_db_regs(void)
>> +{
>> +u8 b;
>> +u16 w;
>> +
>> +b = readb(&musbr->faddr);
>> +serial_printf("\tfaddr 0x%2.2x\n", b);
>> +
>> +b = readb(&musbr->power);
>> +MUSB_PRINT_PWR(b);
>> +
>> +w = readw(&musbr->ep[0].ep0.csr0);
>> +MUSB_PRINT_CSR0(w);
>> +
>> +b = readb(&musbr->devctl);
>> +MUSB_PRINT_DEVCTL(b);
>> +
>> +b = readb(&musbr->ep[0].ep0.configdata);
>> +MUSB_PRINT_CONFIG(b);
>> +
>> +w = readw(&musbr->frame);
>> +serial_printf("\tframe 0x%4.4x\n", w);
>> +
>> +b = readb(&musbr->index);
>> +serial_printf("\tindex 0x%2.2x\n", b);
>> +
>> +w = readw(&musbr->ep[1].epN.rxmaxp);
>> +MUSB_PRINT_RXMAXP(w);
>> +
>> +w = readw(&musbr->ep[1].epN.rxcsr);
>> +MUSB
Re: [U-Boot] [PATCH 3/8] TWL4030 Add usb PHY support
Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 15:12 Fri 04 Sep , Tom Rix wrote:
>
>>
> please add an empty line
>
I will take care of all the empty lines.
>> +if (ret == 0)
>> +ret = data;
>> +else
>> +printf("TWL4030:USB:Read[0x%x] Error %d\n", address, ret);
>> +
>> +return ret;
>>
> why not this and avoid the copy of data
> if (ret != 0) {
> printf("TWL4030:USB:Read[0x%x] Error %d\n", address, ret);
> return ret;
> }
>
> return data;
> }
>
>
In general I rather have only one exit point from a function.
This makes tracing execution easier.
>> +/* Check if the PHY DPLL is locked */
>> +sts = twl4030_usb_read(TWL4030_USB_PHY_CLK_CTRL_STS);
>> +while (!(sts & PHY_DPLL_CLK) && 0 < timeout) {
>> +udelay(10);
>> +sts = twl4030_usb_read(TWL4030_USB_PHY_CLK_CTRL_STS);
>> +timeout -= 10;
>> +}
>>
> why not set time to 100 * 1000
> and just decrease by 1
>
Yes.
> make some enums by group of function will be better as it simplify the code
>
>> +#define TWL4030_USB_VENDOR_ID_LO0x00
>> +#define TWL4030_USB_VENDOR_ID_HI0x01
>>
I see your point, but this is how they are defined in a twl4030 spec.
This way makes it easy to look up #define in the spec.
Just remove the prefix.
>> +#define TWL4030_USB_PRODUCT_ID_LO 0x02
>> +#define TWL4030_USB_PRODUCT_ID_HI 0x03
>>
Tom
>
> Best Regards,
> J.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
Paulraj, Sandeep wrote: > Wolfgang, Dirk, > > I can take responsibility for TI DaVinci SOCs. > > This means an omap/davinci split ? u-boot-arm-omap u-boot-arm-davinci This is ok with me Tom > Thanks, > Sandeep > > From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] On Behalf > Of Dirk Behme [dirk.be...@googlemail.com] > Sent: Saturday, September 05, 2009 3:39 AM > To: Wolfgang Denk > Cc: Tom Rix; Kyungmin Park; u-boot@lists.denx.de; Magnus Lilja; Minkyu Kang > Subject: Re: [U-Boot] RFC: split ARM repo and distribute workload > > Dear Wolfgang, > > Wolfgang Denk wrote: > >> Texas Instruments (OMAP): Dirk Behme? >> Or are there any volunteers at TI? >> > > I really like to see someone from TI here, instead. > > Looking at some past discussions, I think somebody from TI would be > the best. E.g.: > > - While discussing the board/vendor directory change, we were unsure > who might be the vendor of which board. Somebody from TI would know best. > > - While discussing the OMAP3 cache move, we were unsure what's about > the ROM code calling and where/when this is necessary. Someone from TI > would know best, too. > > - etc, etc. > > Best regards > > Dirk > ___ > 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 4/8] OMAP3 Add usb device support
> >>+ }
> >>+
> >>+ if (debug_setup && (debug_level > 1))
> >>+ musb_db_regs();
> >>+}
> >>+
> >>+static void musb_peri_reset(void)
> >>+{
> >>+ if ((debug_setup) && (debug_level > 1))
> >>+ serial_printf("INFO : %s reset\n", __PRETTY_FUNCTION__);
> >what do you mean y __PRETTY_FUNCTION__?
> This a gcc compiler macro for printing out the function of the calling
> routine. It is useful in the macro's like the state machine changer
> to show which function did the change instead of the usual
> __LINE__ + __FILE__ + eyeball time. It is a non-standard cpp macro
> and would bite us when compiling without gcc. Does u-boot build
> with non-gcc ?
no only gcc but I think it will not be impossible to use an other toolchains
but ok
> >>+
> >>+ /* the device address is reset by the event */
> >>diff --git a/include/usb.h b/include/usb.h
> >>index 378a23b..198d5bb 100644
> >>--- a/include/usb.h
> >>+++ b/include/usb.h
> >>@@ -131,7 +131,8 @@ struct usb_device {
> >> #if defined(CONFIG_USB_UHCI) || defined(CONFIG_USB_OHCI) || \
> >>defined(CONFIG_USB_EHCI) || defined(CONFIG_USB_OHCI_NEW) || \
> >>defined(CONFIG_USB_SL811HS) || defined(CONFIG_USB_ISP116X_HCD) || \
> >>- defined(CONFIG_USB_R8A66597_HCD) || defined(CONFIG_USB_DAVINCI)
> >>+ defined(CONFIG_USB_R8A66597_HCD) || defined(CONFIG_USB_DAVINCI) || \
> >>+ defined(CONFIG_USB_OMAP3)
> >a simple CONFIG will be better
> Can this be a follow-on ?
ofcource
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
Tom, This is also what we have been discussing internally within TI to have an omap/davinci split. BTW there are SOC's which have an OMAP part number but are actually very similar to DaVinci's. Since i am quite familiar with the RBLs of all these devices and i have all the EVMs for the various SOC's with me i could help in maintaining the repository. Lets hope this split is OK with the others as well. Thanks, Sandeep From: Tom [tom@windriver.com] Sent: Sunday, September 06, 2009 9:54 AM To: Paulraj, Sandeep Cc: Dirk Behme; Wolfgang Denk; Kyungmin Park; u-boot@lists.denx.de; Magnus Lilja; Minkyu Kang Subject: Re: [U-Boot] RFC: split ARM repo and distribute workload Paulraj, Sandeep wrote: > Wolfgang, Dirk, > > I can take responsibility for TI DaVinci SOCs. > > This means an omap/davinci split ? u-boot-arm-omap u-boot-arm-davinci This is ok with me Tom > Thanks, > Sandeep > > From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] On Behalf > Of Dirk Behme [dirk.be...@googlemail.com] > Sent: Saturday, September 05, 2009 3:39 AM > To: Wolfgang Denk > Cc: Tom Rix; Kyungmin Park; u-boot@lists.denx.de; Magnus Lilja; Minkyu Kang > Subject: Re: [U-Boot] RFC: split ARM repo and distribute workload > > Dear Wolfgang, > > Wolfgang Denk wrote: > >> Texas Instruments (OMAP): Dirk Behme? >> Or are there any volunteers at TI? >> > > I really like to see someone from TI here, instead. > > Looking at some past discussions, I think somebody from TI would be > the best. E.g.: > > - While discussing the board/vendor directory change, we were unsure > who might be the vendor of which board. Somebody from TI would know best. > > - While discussing the OMAP3 cache move, we were unsure what's about > the ROM code calling and where/when this is necessary. Someone from TI > would know best, too. > > - etc, etc. > > Best regards > > Dirk > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] TWL4030 Add usb PHY support
On 08:46 Sun 06 Sep , Tom wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote:
> >On 15:12 Fri 04 Sep , Tom Rix wrote:
>
> >please add an empty line
> I will take care of all the empty lines.
>
> >>+ if (ret == 0)
> >>+ ret = data;
> >>+ else
> >>+ printf("TWL4030:USB:Read[0x%x] Error %d\n", address, ret);
> >>+
> >>+ return ret;
> >why not this and avoid the copy of data
> > if (ret != 0) {
> > printf("TWL4030:USB:Read[0x%x] Error %d\n", address, ret);
> > return ret;
> > }
> >
> > return data;
> >}
> >
> In general I rather have only one exit point from a function.
> This makes tracing execution easier.
ok
>
> >>+ /* Check if the PHY DPLL is locked */
> >>+ sts = twl4030_usb_read(TWL4030_USB_PHY_CLK_CTRL_STS);
> >>+ while (!(sts & PHY_DPLL_CLK) && 0 < timeout) {
> >>+ udelay(10);
> >>+ sts = twl4030_usb_read(TWL4030_USB_PHY_CLK_CTRL_STS);
> >>+ timeout -= 10;
> >>+ }
> >why not set time to 100 * 1000
> > and just decrease by 1
> Yes.
>
> >make some enums by group of function will be better as it simplify the code
> >>+#define TWL4030_USB_VENDOR_ID_LO 0x00
> >>+#define TWL4030_USB_VENDOR_ID_HI 0x01
> I see your point, but this is how they are defined in a twl4030 spec.
> This way makes it easy to look up #define in the spec.
> Just remove the prefix.
> >>+#define TWL4030_USB_PRODUCT_ID_LO 0x02
> >>+#define TWL4030_USB_PRODUCT_ID_HI 0x03
ok fine
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/4]: arm: Define test_and_set_bit and test_and_clear bit for ARM
On 17:27 Fri 04 Sep , Justin Waters wrote:
> Simon,
>
> I found a slight problem with this section of the patch:
>
> On Mon, 2009-08-24 at 03:10 -0400, Simon Kagstrom wrote:
> > diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
> > index 854e225..3c7b00c 100644
> > --- a/include/asm-arm/bitops.h
> > +++ b/include/asm-arm/bitops.h
> > @@ -17,6 +17,8 @@
> >
> > #ifdef __KERNEL__
> >
> > +#include
> > +
>
> It causes a compiler error on the arm926ejs platform:
>
> In file included from cpu.c:34:
> /home/justin/git/u-boot/include/asm/system.h: At top level:
> /home/justin/git/u-boot/include/asm/system.h:71: error: expected
> identifier or '(' before 'asm'
>
> I did some digging, and it looks like set_cr() is implemented by both
> asm-arm/system.h and asm-arm/proc-armv/system.h. One implements the
> function as a macro, while the other uses a standard C function, hence
> the weird error message. The conflict occurs in cpu/arm926ejs/cpu.c.
>
> * cpu.c includes both common.h and asm/system.h
> * common.h includes asm/bitops.h, which now includes asm/proc/system.h
>
> There are a few other values that are defined in both files, although
> they don't seem to cause any problems.
>
> If I comment out one of the two implementations, the code compiles fine.
> However, I'm not really sure what the correct fix would be. I just
> wanted to let you know.
It's corrent and Simon already send the cleanup which is part of the pending
arm pull request
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
And of course the omap / davinci repos should be sync-ed up regularly so they do not drift too much. Tom Paulraj, Sandeep wrote: > Tom, > > This is also what we have been discussing internally within TI to have an > omap/davinci split. > > BTW there are SOC's which have an OMAP part number but are actually very > similar to DaVinci's. > > Since i am quite familiar with the RBLs of all these devices and i have all > the EVMs for the various > SOC's with me i could help in maintaining the repository. > > Lets hope this split is OK with the others as well. > > Thanks, > Sandeep > > From: Tom [tom@windriver.com] > Sent: Sunday, September 06, 2009 9:54 AM > To: Paulraj, Sandeep > Cc: Dirk Behme; Wolfgang Denk; Kyungmin Park; u-boot@lists.denx.de; Magnus > Lilja; Minkyu Kang > Subject: Re: [U-Boot] RFC: split ARM repo and distribute workload > > Paulraj, Sandeep wrote: > >> Wolfgang, Dirk, >> >> I can take responsibility for TI DaVinci SOCs. >> >> >> > This means an omap/davinci split ? > u-boot-arm-omap > u-boot-arm-davinci > > This is ok with me > Tom > > >> Thanks, >> Sandeep >> >> From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] On Behalf >> Of Dirk Behme [dirk.be...@googlemail.com] >> Sent: Saturday, September 05, 2009 3:39 AM >> To: Wolfgang Denk >> Cc: Tom Rix; Kyungmin Park; u-boot@lists.denx.de; Magnus Lilja; Minkyu Kang >> Subject: Re: [U-Boot] RFC: split ARM repo and distribute workload >> >> Dear Wolfgang, >> >> Wolfgang Denk wrote: >> >> >>> Texas Instruments (OMAP): Dirk Behme? >>> Or are there any volunteers at TI? >>> >>> >> I really like to see someone from TI here, instead. >> >> Looking at some past discussions, I think somebody from TI would be >> the best. E.g.: >> >> - While discussing the board/vendor directory change, we were unsure >> who might be the vendor of which board. Somebody from TI would know best. >> >> - While discussing the OMAP3 cache move, we were unsure what's about >> the ROM code calling and where/when this is necessary. Someone from TI >> would know best, too. >> >> - etc, etc. >> >> Best regards >> >> Dirk >> ___ >> 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] ARM Pull Request
Jean-Christophe PLAGNIOL-VILLARD wrote: > On 09:12 Sun 06 Sep , Dirk Behme wrote: >> Jean-Christophe PLAGNIOL-VILLARD wrote: >>> On 07:37 Sat 05 Sep , Dirk Behme wrote: Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: > Hi, > > Please pull > The following changes since commit > 3aa8b68d80dbcb6829af60485c1e388b39af793d: > Wolfgang Denk (1): > Merge branch 'next' of ../next > > are available in the git repository at: > > git://git.denx.de/u-boot-arm.git master > > Albin Tonnerre (3): > at91sam9260/afeb9260: Fix SPI initialization > Add support for the Calao SBC35-A9G20 board > Support for the Calao TNY-A9260/TNY-A9G20 boards > > Frederik Kriewitz (1): > Add support for the DevKit8000 board I'd like to have the omap3_devkit8000.h version of that patch, instead. >>> this one is fine no need not the omap3_devkit8000 version >> Jean-Christophe: In >> >> http://lists.denx.de/pipermail/u-boot/2009-August/059087.html >> >> we agreed on omap3_devkit8000. > in v4 the author prefer it devkit8000 so I respect it You missed v5 and v6, no? > for the l2_cache I'm fine to move to omap3 as it's really omap3 specific Again, you confuse people. From your previous mail: "as I said now more than 10 times on omap3 we can use the generic ARMV7 cache code" > we clearly need to clean the omap3 and not force other soc to duplicate code With http://lists.denx.de/pipermail/u-boot/2009-August/059087.html we just try to do the opposite: Move the custom code away so that Samsung can use its own (generic?) implementation. Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
On Sun, 2009-09-06 at 19:59 +0200, Dirk Behme wrote: > Jean-Christophe PLAGNIOL-VILLARD wrote: > > On 09:12 Sun 06 Sep , Dirk Behme wrote: > >> Jean-Christophe PLAGNIOL-VILLARD wrote: > >>> On 07:37 Sat 05 Sep , Dirk Behme wrote: > Dear Jean-Christophe, > > Jean-Christophe PLAGNIOL-VILLARD wrote: > > Hi, > > > > Please pull > > The following changes since commit > > 3aa8b68d80dbcb6829af60485c1e388b39af793d: > > Wolfgang Denk (1): > > Merge branch 'next' of ../next > > > > are available in the git repository at: > > > > git://git.denx.de/u-boot-arm.git master > > > > Albin Tonnerre (3): > > at91sam9260/afeb9260: Fix SPI initialization > > Add support for the Calao SBC35-A9G20 board > > Support for the Calao TNY-A9260/TNY-A9G20 boards > > > > Frederik Kriewitz (1): > > Add support for the DevKit8000 board > I'd like to have the omap3_devkit8000.h version of that patch, instead. > >>> this one is fine no need not the omap3_devkit8000 version > >> Jean-Christophe: In > >> > >> http://lists.denx.de/pipermail/u-boot/2009-August/059087.html > >> > >> we agreed on omap3_devkit8000. > > in v4 the author prefer it devkit8000 so I respect it > > You missed v5 and v6, no? My vote is for keeping the board config file named devkit8000.h - that's U-Boot's current, standard naming convention and it matches up with the board name under board/. This appears to be the patch version that Jean-Christophe picked, and v6 was "dirty" (added the same file 2x) as well. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
Peter Tyser wrote: > On Sun, 2009-09-06 at 19:59 +0200, Dirk Behme wrote: >> Jean-Christophe PLAGNIOL-VILLARD wrote: >>> On 09:12 Sun 06 Sep , Dirk Behme wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: > On 07:37 Sat 05 Sep , Dirk Behme wrote: >> Dear Jean-Christophe, >> >> Jean-Christophe PLAGNIOL-VILLARD wrote: >>> Hi, >>> >>> Please pull >>> The following changes since commit >>> 3aa8b68d80dbcb6829af60485c1e388b39af793d: >>> Wolfgang Denk (1): >>> Merge branch 'next' of ../next >>> >>> are available in the git repository at: >>> >>> git://git.denx.de/u-boot-arm.git master >>> >>> Albin Tonnerre (3): >>> at91sam9260/afeb9260: Fix SPI initialization >>> Add support for the Calao SBC35-A9G20 board >>> Support for the Calao TNY-A9260/TNY-A9G20 boards >>> >>> Frederik Kriewitz (1): >>> Add support for the DevKit8000 board >> I'd like to have the omap3_devkit8000.h version of that patch, instead. > this one is fine no need not the omap3_devkit8000 version Jean-Christophe: In http://lists.denx.de/pipermail/u-boot/2009-August/059087.html we agreed on omap3_devkit8000. >>> in v4 the author prefer it devkit8000 so I respect it >> You missed v5 and v6, no? > > My vote is for keeping the board config file named devkit8000.h - that's > U-Boot's current, standard naming convention and it matches up with the > board name under board/. And I vote (as agreed like mentioned above) for omap3_devkit8000.h as this is the current, standard OMAP3 config file naming convention which matches with all other OMAP3 configs. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
On Sun, 2009-09-06 at 20:40 +0200, Dirk Behme wrote: > Peter Tyser wrote: > > On Sun, 2009-09-06 at 19:59 +0200, Dirk Behme wrote: > >> Jean-Christophe PLAGNIOL-VILLARD wrote: > >>> On 09:12 Sun 06 Sep , Dirk Behme wrote: > Jean-Christophe PLAGNIOL-VILLARD wrote: > > On 07:37 Sat 05 Sep , Dirk Behme wrote: > >> Dear Jean-Christophe, > >> > >> Jean-Christophe PLAGNIOL-VILLARD wrote: > >>> Hi, > >>> > >>> Please pull > >>> The following changes since commit > >>> 3aa8b68d80dbcb6829af60485c1e388b39af793d: > >>> Wolfgang Denk (1): > >>> Merge branch 'next' of ../next > >>> > >>> are available in the git repository at: > >>> > >>> git://git.denx.de/u-boot-arm.git master > >>> > >>> Albin Tonnerre (3): > >>> at91sam9260/afeb9260: Fix SPI initialization > >>> Add support for the Calao SBC35-A9G20 board > >>> Support for the Calao TNY-A9260/TNY-A9G20 boards > >>> > >>> Frederik Kriewitz (1): > >>> Add support for the DevKit8000 board > >> I'd like to have the omap3_devkit8000.h version of that patch, instead. > > this one is fine no need not the omap3_devkit8000 version > Jean-Christophe: In > > http://lists.denx.de/pipermail/u-boot/2009-August/059087.html > > we agreed on omap3_devkit8000. > >>> in v4 the author prefer it devkit8000 so I respect it > >> You missed v5 and v6, no? > > > > My vote is for keeping the board config file named devkit8000.h - that's > > U-Boot's current, standard naming convention and it matches up with the > > board name under board/. > > And I vote (as agreed like mentioned above) for omap3_devkit8000.h as > this is the current, standard OMAP3 config file naming convention > which matches with all other OMAP3 configs. I consider the current board omap3_* config file names incorrect. Naming the devkit8000 omap3_devkit8000 might be consistent with some other misnamed boards, but its wrong in my opinion. We should just get rid of the omap3_ prefix on those few config files if we want to be consistent. eg rename: omap3_beagle.h to beagle.h omap3_evm.h to evm.h ... This will be consistent with the board name in board/, as well as follow the convention of every other board in U-Boot. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
Dirk Behme wrote: > Peter Tyser wrote: > >> On Sun, 2009-09-06 at 19:59 +0200, Dirk Behme wrote: >> >>> Jean-Christophe PLAGNIOL-VILLARD wrote: >>> On 09:12 Sun 06 Sep , Dirk Behme wrote: > Jean-Christophe PLAGNIOL-VILLARD wrote: > >> On 07:37 Sat 05 Sep , Dirk Behme wrote: >> >>> Dear Jean-Christophe, >>> >>> Jean-Christophe PLAGNIOL-VILLARD wrote: >>> Hi, Please pull The following changes since commit 3aa8b68d80dbcb6829af60485c1e388b39af793d: Wolfgang Denk (1): Merge branch 'next' of ../next are available in the git repository at: git://git.denx.de/u-boot-arm.git master Albin Tonnerre (3): at91sam9260/afeb9260: Fix SPI initialization Add support for the Calao SBC35-A9G20 board Support for the Calao TNY-A9260/TNY-A9G20 boards Frederik Kriewitz (1): Add support for the DevKit8000 board >>> I'd like to have the omap3_devkit8000.h version of that patch, instead. >>> >> this one is fine no need not the omap3_devkit8000 version >> > Jean-Christophe: In > > http://lists.denx.de/pipermail/u-boot/2009-August/059087.html > > we agreed on omap3_devkit8000. > in v4 the author prefer it devkit8000 so I respect it >>> You missed v5 and v6, no? >>> >> My vote is for keeping the board config file named devkit8000.h - that's >> U-Boot's current, standard naming convention and it matches up with the >> board name under board/. >> > > And I vote (as agreed like mentioned above) for omap3_devkit8000.h as > this is the current, standard OMAP3 config file naming convention > which matches with all other OMAP3 configs. > > Best regards > > Dirk > > I know i may be muddying this up but.. The devkit8000 looks a lot like the beagle. Have you already thought of just rolling devkit8000 into beagle? My opinion on naming is to keep omap3_ prefix consistent. People used to building with their favorite omap3_* config should continue. For now, new omap3 boards to use the omap3_ prefix. If we want to break the config names, we should do it after a release. A good time for that will be when the omap4 versions come in and we have to figure out how to put them in. Tom > ___ > 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] ARM Pull Request
> >>Jean-Christophe: In > >> > >>http://lists.denx.de/pipermail/u-boot/2009-August/059087.html > >> > >>we agreed on omap3_devkit8000. > >in v4 the author prefer it devkit8000 so I respect it > > You missed v5 and v6, no? no I did not as Frederik Kriewitz said this 'Oh yes, do we really need a v7? Or is v4 (with timll vendor directory) ok' so I applied this one as the patch is ok > > >for the l2_cache I'm fine to move to omap3 as it's really omap3 specific > > Again, you confuse people. From your previous mail: > > "as I said now more than 10 times on omap3 we can use the generic > ARMV7 cache code" > > >we clearly need to clean the omap3 and not force other soc to duplicate code > > With > > http://lists.denx.de/pipermail/u-boot/2009-August/059087.html ??? > > we just try to do the opposite: Move the custom code away so that > Samsung can use its own (generic?) implementation. When I've said we do not need the custom code for omap3 either so omap3 and Samsung can use the same code the generic one Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4]: bitops cleanup and fixes
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <20090905113728.gn30...@game.jcrosoft.org> you wrote: > > > > Sorry to ping you all, but are there any more comments on work to be > > > done before this patch series can be accepted? The patches were these: > > > > > >[PATCH v4 1/4]: Move __set/clear_bit from ubifs.h to bitops.h > > >[PATCH v4 2/4]: arm: Make arm bitops endianness-independent > > >[PATCH v4 3/4]: Define ffs/fls for all architectures > > >[PATCH v4 4/4]: arm: Define test_and_set_bit and test_and_clear bit > > > for ARM > > > > I think we're just waiting for an ARM custodian to pick this up. > I've already ack the patches at the V2 version so I wait other arch Maintainer > comment as it will impact everyone Just waiting is a reliable way to delay things forever, expecially when you wait without telling that you are waiting, and without actively pinging the parties you exect answers from. Forget it. I'll take this directly. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de No more blah, blah, blah! -- Kirk, "Miri", stardate 2713.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
Dear Sandeep, In message <0554bef07d437848af01b9c9b5f0bc5d91e07...@dlee01.ent.ti.com> you wrote: > > This is also what we have been discussing internally within TI to have an > omap/davinci split. I'm not happy about the idea. If there really is need (or reason) to split these, I would prefer to do this in a seciond step, after the general ARM split has been completed and a stable work flow been established. > BTW there are SOC's which have an OMAP part number but are actually very > similar to DaVinci's. > > Since i am quite familiar with the RBLs of all these devices and i have all > the EVMs for the various > SOC's with me i could help in maintaining the repository. > > Lets hope this split is OK with the others as well. Maybe we can at least postpone it? Would you also take responsibility as custodian for all TI, i. e. OMAP + DaVinci, at least for the time being? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Most people would like to be delivered from temptation but would like it to keep in touch." - Robert Orben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
Dear Dirk Behme, In message <4aa4020c.8080...@googlemail.com> you wrote: > > > My vote is for keeping the board config file named devkit8000.h - that's > > U-Boot's current, standard naming convention and it matches up with the > > board name under board/. ACK. > And I vote (as agreed like mentioned above) for omap3_devkit8000.h as > this is the current, standard OMAP3 config file naming convention > which matches with all other OMAP3 configs. I hear your vote, but in this case you are alone against eveybody else. This "standard OMAP3 config file naming convention" is something that needs to and will be cleaned up. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de This all sounds complicated, but it mostly does excatly what you ex- pect. It's just difficult for us to explain what you expect... - L. Wall & R. L. Schwartz, _Programming Perl_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
Dear Tom, In message <4aa419d7.2010...@windriver.com> you wrote: > > I know i may be muddying this up but.. > The devkit8000 looks a lot like the beagle. > Have you already thought of just rolling devkit8000 into beagle? That's actually a good idea, if possible. > My opinion on naming is to keep omap3_ prefix consistent. > People used to building with their favorite omap3_* config should continue. > For now, new omap3 boards to use the omap3_ prefix. NAK. This violates the current naming scheme. > If we want to break the config names, we should do it after a release. This what he have now: merge window time. Time for restructuring. > A good time for that will be when the omap4 versions come in and we > have to figure out how to put them in. NAK. Rather do it immediately, before that grows even further. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A person who is more than casually interested in computers should be well schooled in machine language, since it is a fundamental part of a computer. -- Donald Knuth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
Dear Tom, In message <4aa3bf2f.3080...@windriver.com> you wrote: > > This means an omap/davinci split ? > u-boot-arm-omap > u-boot-arm-davinci > > This is ok with me I would like to avoid this, at least for now. Let's do a first step now (split into vendor based sub-repos), and stabilize that. Then we can decide if we hant to or have to implement further splits. Now it is too early to make such a decision. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de How many seconds are there in a year? If I tell you there are 3.155 x 10^7, you won't even try to remember it. On the other hand, who could forget that, to within half a percent, pi seconds is a nanocentury. -- Tom Duff, Bell Labs ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] omap: move TI's boards to board/ti/
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <1251037960-17063-1-git-send-email-plagn...@jcrosoft.com> you wrote: > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD > --- Sorry for the late comment, but I hust notice that this patch (and the two following ones) moves the board names to the right directories, but it fails to also rename the Make target names and the board config files. For example, moving board/omap3/beagle/ => board/ti/beagle/ is a perfectly corrrect thing to do, but we should also use this opportunity and fix the make target name (omap3_beagle_config => beagle_config) and the board config file name (include/configs/omap3_beagle.h => include/configs/beagle.h) Do you see a chance to update your patches once more, so we can do this in one step? I'd prefer to do this at once rather that doing the rename in another patch. Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you think the problem is bad now, just wait until we've solved it. Epstein's Law ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] reloacting uboot
Wolfgang Denk skrev: > Dear E Robertson, > > In message <200908251428.55255.e.robertson@gmail.com> you wrote: >>> In message <200908251403.20809.e.robertson@gmail.com> you wrote: I am using the at91sam9263 device from which the bootstrap code load u-boot to the desired ram address. However, I would like to re-relocate this at the different address based on memory availability. Can / or should this be done? >>> Yes, it can be done, and it should be done. The fact that we don't do >>> it so far is due to the fact that the guys who did the original ARM >>> code found this too complicated (even though they had a working >>> example in the PowerPC code) and not worth the effort. We're suffering >>> since from this misconception. >>> >>> But there is no reason why you would have to copy the code again - >>> just copy it to the correct address right from the beginning, like we >>> do in PowerPC. >> I don't follow: Yes, but no reason to do so? > > You wrote: "re-relocate". This is bogus. Just relocate it once, to the > correct address. > >> On the 9263, it's copied once to ram at boot. Are you saying their is no >> reason to copy it again? If so, yes, in most cases that would be true but I >> would like to move it again after that initial relocation. Since I've >> already >> specified my start address, I wasn't sure about. > > Fix the ARM relocating scheme such that it works like in PowerPC: link > the image not for a RAM address, but for the address in flash. Then, > after determining the RAM size, copy & relocate the code once to RAM. > Only one copy. Not two. > > Best regards, > > Wolfgang Denk > Very few boards based on the SAM9263 store u-boot in parallel flash and if they are stored in SPI dataflash or in NAND flash it makes little sense to link the u-boot to the flash address. Fix at91bootstrap to load where you want it to load. BR Ulf Samuelsson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
Wolfgang Denk wrote: > Dear Tom, > > In message <4aa419d7.2010...@windriver.com> you wrote: > >> I know i may be muddying this up but.. >> The devkit8000 looks a lot like the beagle. >> Have you already thought of just rolling devkit8000 into beagle? >> > > That's actually a good idea, if possible. > > >> My opinion on naming is to keep omap3_ prefix consistent. >> People used to building with their favorite omap3_* config should continue. >> For now, new omap3 boards to use the omap3_ prefix. >> > > NAK. This violates the current naming scheme. > > >> If we want to break the config names, we should do it after a release. >> > > This what he have now: merge window time. Time for restructuring. > > >> A good time for that will be when the omap4 versions come in and we >> have to figure out how to put them in. >> > > NAK. Rather do it immediately, before that grows even further. > > Best regards, > > Wolfgang Denk > > Ok I will take care of making the changes if they don't already exist. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] omap: move TI's boards to board/ti/
On 23:43 Sun 06 Sep , Wolfgang Denk wrote: > Dear Jean-Christophe PLAGNIOL-VILLARD, > > In message <1251037960-17063-1-git-send-email-plagn...@jcrosoft.com> you > wrote: > > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD > > --- > > Sorry for the late comment, but I hust notice that this patch (and > the two following ones) moves the board names to the right > directories, but it fails to also rename the Make target names and > the board config files. > > For example, moving board/omap3/beagle/ => board/ti/beagle/ is a > perfectly corrrect thing to do, but we should also use this > opportunity and fix the make target name (omap3_beagle_config => > beagle_config) and the board config file name > (include/configs/omap3_beagle.h => include/configs/beagle.h) > > > Do you see a chance to update your patches once more, so we can do > this in one step? I'd prefer to do this at once rather that doing the > rename in another patch. I'll prefer to do it in two step as we will face a problem for evm boards as they exist for multiple soc not only TI's. So for evm I think we need to keep the omap3_evm as we have also as example a dvevm for davinci too This patch series move vendors to the corrent area the next one will fix the board config and header Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4]: bitops cleanup and fixes
On 22:50 Sun 06 Sep , Wolfgang Denk wrote: > Dear Jean-Christophe PLAGNIOL-VILLARD, > > In message <20090905113728.gn30...@game.jcrosoft.org> you wrote: > > > > > > Sorry to ping you all, but are there any more comments on work to be > > > > done before this patch series can be accepted? The patches were these: > > > > > > > >[PATCH v4 1/4]: Move __set/clear_bit from ubifs.h to bitops.h > > > >[PATCH v4 2/4]: arm: Make arm bitops endianness-independent > > > >[PATCH v4 3/4]: Define ffs/fls for all architectures > > > >[PATCH v4 4/4]: arm: Define test_and_set_bit and test_and_clear bit > > > > for ARM > > > > > > I think we're just waiting for an ARM custodian to pick this up. > > I've already ack the patches at the V2 version so I wait other arch > > Maintainer > > comment as it will impact everyone > > Just waiting is a reliable way to delay things forever, expecially > when you wait without telling that you are waiting, and without > actively pinging the parties you exect answers from. ?? I'm not supposed to apply patches that update all arch except if I receive ack for it or most of at least so I've gave the ack for the arm part and Mike did a comment and no other Maintainer did a comment so how can I applied to patch? Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH-ARM 4/4] Clean-up of s3c24x0 nand driver
This patch re-formats the arm920t s3c24x0 nand driver in preparation for changes
to add support for the Embest SBC2440-II Board.
The changes are as follows:
- re-indent the code using Lindent
- make sure register layouts are defined using a C struct
- replace the upper-case typedef'ed C struct names with lower case
non-typedef'ed ones
- make sure registers are accessed using the proper accessor functions
- run checkpatch.pl and fix any error reports
It assumes the following patch has been applied first:
- [U-Boot][PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards, 05/09/2009
- patches 1/4, 2/4 and 3/4 of this series
Tested on an Embest SBC2440-II Board with local u-boot patches as I don't have
any s3c2400 or s3c2410 boards but need this patch applying before I can submit
patches for the SBC2440-II Board. Also, temporarily modified sbc2410x, smdk2400,
smdk2410 and trab configs to use the mtd nand driver (which isn't used by any
board at the moment), ran MAKEALL for all ARM9 targets and no new warnings or
errors were found.
Signed-off-by: Kevin Morfitt
---
drivers/mtd/nand/s3c2410_nand.c | 62 +++---
1 files changed, 25 insertions(+), 37 deletions(-)
diff --git a/drivers/mtd/nand/s3c2410_nand.c b/drivers/mtd/nand/s3c2410_nand.c
index d27a625..f2f3e72 100644
--- a/drivers/mtd/nand/s3c2410_nand.c
+++ b/drivers/mtd/nand/s3c2410_nand.c
@@ -20,29 +20,10 @@
#include
-#if 0
-#define DEBUGN printf
-#else
-#define DEBUGN(x, args ...) {}
-#endif
-
#include
#include
#include
-#define __REGb(x) (*(volatile unsigned char *)(x))
-#define __REGi(x) (*(volatile unsigned int *)(x))
-
-#defineNF_BASE 0x4e00
-#defineNFCONF __REGi(NF_BASE + 0x0)
-#defineNFCMD __REGb(NF_BASE + 0x4)
-#defineNFADDR __REGb(NF_BASE + 0x8)
-#defineNFDATA __REGb(NF_BASE + 0xc)
-#defineNFSTAT __REGb(NF_BASE + 0x10)
-#define NFECC0 __REGb(NF_BASE + 0x14)
-#define NFECC1 __REGb(NF_BASE + 0x15)
-#define NFECC2 __REGb(NF_BASE + 0x16)
-
#define S3C2410_NFCONF_EN (1<<15)
#define S3C2410_NFCONF_512BYTE (1<<14)
#define S3C2410_NFCONF_4STEP (1<<13)
@@ -58,11 +39,12 @@
static void s3c2410_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
struct nand_chip *chip = mtd->priv;
+ struct s3c2410_nand *nand = s3c2410_get_base_nand();
- DEBUGN("hwcontrol(): 0x%02x 0x%02x\n", cmd, ctrl);
+ debugX(1, "hwcontrol(): 0x%02x 0x%02x\n", cmd, ctrl);
if (ctrl & NAND_CTRL_CHANGE) {
- ulong IO_ADDR_W = NF_BASE;
+ ulong IO_ADDR_W = (ulong)nand;
if (!(ctrl & NAND_CLE))
IO_ADDR_W |= S3C2410_ADDR_NCLE;
@@ -72,9 +54,11 @@ static void s3c2410_hwcontrol(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
chip->IO_ADDR_W = (void *)IO_ADDR_W;
if (ctrl & NAND_NCE)
- NFCONF &= ~S3C2410_NFCONF_nFCE;
+ writel(readl(&nand->NFCONF) & ~S3C2410_NFCONF_nFCE,
+ &nand->NFCONF);
else
- NFCONF |= S3C2410_NFCONF_nFCE;
+ writel(readl(&nand->NFCONF) | S3C2410_NFCONF_nFCE,
+ &nand->NFCONF);
}
if (cmd != NAND_CMD_NONE)
@@ -83,15 +67,17 @@ static void s3c2410_hwcontrol(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
static int s3c2410_dev_ready(struct mtd_info *mtd)
{
- DEBUGN("dev_ready\n");
- return (NFSTAT & 0x01);
+ struct s3c2410_nand *nand = s3c2410_get_base_nand();
+ debugX(1, "dev_ready\n");
+ return readl(&nand->NFSTAT) & 0x01;
}
#ifdef CONFIG_S3C2410_NAND_HWECC
void s3c2410_nand_enable_hwecc(struct mtd_info *mtd, int mode)
{
- DEBUGN("s3c2410_nand_enable_hwecc(%p, %d)\n", mtd, mode);
- NFCONF |= S3C2410_NFCONF_INITECC;
+ struct s3c2410_nand *nand = s3c2410_get_base_nand();
+ debugX(1, "s3c2410_nand_enable_hwecc(%p, %d)\n", mtd, mode);
+ writel(readl(&nand->NFCONF) | S3C2410_NFCONF_INITECC, &nand->NFCONF);
}
static int s3c2410_nand_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
@@ -100,8 +86,8 @@ static int s3c2410_nand_calculate_ecc(struct mtd_info *mtd,
const u_char *dat,
ecc_code[0] = NFECC0;
ecc_code[1] = NFECC1;
ecc_code[2] = NFECC2;
- DEBUGN("s3c2410_nand_calculate_hwecc(%p,): 0x%02x 0x%02x 0x%02x\n",
- mtd , ecc_code[0], ecc_code[1], ecc_code[2]);
+ debugX(1, "s3c2410_nand_calculate_hwecc(%p,): 0x%02x 0x%02x 0x%02x\n",
+ mtd , ecc_code[0], ecc_code[1], ecc_code[2]);
return 0;
}
@@ -123,24 +109,26 @@ int board_nand_init(struct nand_chip *nand)
{
u_int32_t cfg;
u_int8_t tacls, twrph0, twrph1;
- S3C24X0_CLOCK_POWER * const clk_power = S3C24X0_GetBase_CLOCK_POWER();
+ struct s3
Re: [U-Boot] RFC: split ARM repo and distribute workload
On Sat, Sep 5, 2009 at 6:57 AM, Wolfgang Denk wrote: > Hello everybody, > > ARM has always been one of the architectures that generated a big > number of different processors and SoCs, but recently the activitiy in > this area is literally exploding. This is partially due to the fact > that ARM is currently used in many designs, so many new ARM based > processors and SoCs and even more new ARM boards show up, but another > and at least as important change is that some silicon and board > vendors have started to actively pushing their products into the > U-Boot (and Linux) mainline source trees (and *welcome* they all > are!). > > It has become evident that this growing complexity has become way too > massive to be shouldered by a single custodian, even a very active one > like Jean-Christophe. > > I think we have no other choice but to add more manpower to this task, > i. e. split the ARM respository and distribute the workload across a > few more custodians. > > Unline with the Power architecture, where the split can be easily > defined by processor lines, with ARM it seems more logical to me to > differentiate by silicon vendors. > > After much thinking I therefor suggest to implement the following > change for the ARM architecture: > > > master ARM repository: Tom Rix > > Atmel (AT91): Jean-Christophe Plagniol-Villard > > Freescale (i.MX) Magnus Lilja? > Or are there any volunteers at Freescale? > > Marvell (PXA + IXP): Jean-Christophe Plagniol-Villard > > Marvell (all other): Prafulla Wadaskar > > Samsung (s3c, s5pc): Are there any volunteers at Samsung? > I recommended the Minky Kang. He's working for several years for u-boot from pxa, omap3, s3c6410 and s5pc1xx series. But with our internal security policy it's hard to use ssh on u-boot git. so we want to use u-boot-arm as base. Thank you, Kyungmin Park ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc
Dear Dirk,
2009/9/5 Dirk Behme
> Minkyu Kang wrote:
>
>> Dear, Dirk
>>
>> 2009/9/4 Dirk Behme
>>
>> Kyungmin Park wrote:
>>>
On Fri, Sep 4, 2009 at 7:45 PM, Dirk Behme
>>> wrote:
>>>
Kyungmin Park wrote:
>
...
>>>
+ if (get_device_type() != 0xC100) {
>>> Hmm, what is this "0xC100" ?
>>>
>> Now we got two cpu, s5pc100 and s5pc110. In case of s5pc100 we don't
>> need to turn off l2 cache. but s5pc110 needs it.
>> So first check the device type, actually cpu type. then determine turn
>> off l2 cache or not.
>>
> "0xC100" is the device type of s5pc100 then? So it should be
>
> if (get_device_type() != S5PC100_DEVICE)
>
> ? I hear some people crying "please use macro" ;)
>
Agreed. DONT_NEED_CACHE_FLUSH?
But I don't like this selection here. When we get additional similar
>
SoCs,
>>>
we will end with something like
>
> if (get_device_type() != 0xC100) ||
> (get_device_type() != FOO) ||
> (get_device_type() != BAR)) ||
> ... {
>
> modifying each time cpu/arm_cortexa8/cpu.c.
>
> I would like more that we are able to compile the functionality based
> on
>
the
>>>
config file we use for compilation. E.g. provide emtpy
>
l2_cache_disable();
>>>
function for SoCs that don't need it, but have functionality behind it
>
where
>>>
needed.
>
> With above patch, this would then become something like
>
> cpu/arm_cortexa8/s5pcxxx/dcache.S
>
> -> Implements invalidate_dcache() (or implement a Cortex A8 generic one
>
in
>>>
cpu/arm_cortexa8/cache.S)
>
> cpu/arm_cortexa8/s5pcxxx/cache_110.S
>
> -> Implements l2_cache_enable()/disable()
>
> cpu/arm_cortexa8/s5pcxxx/cache_100.S
>
> -> Implements *empty* l2_cache_enable()/disable()
>
> In cpu/arm_cortexa8/s5pcxxx/Makefile you then could have
>
> SOBJS-y += dcache.o
> SOBJS-$(CONFIG_S5PC100) += cache_100.o
> SOBJS-$(CONFIG_S5PC110) += cache_110.o
>
> What do you think about this?
>
> Basically agreed, of course we can think weak attribute but now we
have to support both cpu simultaneously.
with this reason. we check the device_type at here.
>>> What's about having this check in SoC specific code instead of Cortex
>>> A8 generic code, then?
>>>
>>> E.g apply patch
>>>
>>> http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
>>>
>>> and then create
>>>
>>> cpu/arm_cortexa8/s5pcxxx/cache.S
>>>
>>> with
>>>
>>> invalidate_dcache() {
>>> if (get_device_type() == S5PC100_DEVICE)
>>>return();
>>> ...
>>>
>>> l2_cache_enable() {
>>> if (get_device_type() == S5PC100_DEVICE)
>>>return();
>>> ...
>>>
>>> etc.
>>>
>>> That is, have the SoC dependent part in SoC specific directory/file.
>>>
>>> Best regards
>>>
>>> Dirk
>>>
>>>
>>>
>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>
>>>
>> I know about the discussion of this issue between you and Jean-Christophe.
>> but it is gone without resolving.
>> So, I want to make issue again.
>> anyway,,
>>
>> Actually, we don't need the function of get_device_type()
>> I think that function is omap specific function.. isn't it?
>> but.. because of current code already use that function, I had to use that
>> function
>> If you have plan to move the cache routines into SoC,
>> I think you can remove the argument for device_type. (check device type in
>> omap3's cache routines)
>>
>> And I want to remove CONFIG_L2_OFF also.
>> We can know this through device type or soc type.
>> How about make new function?
>> e.g l2_off() or need_cache_flush() etc,
>>
>> Please rework for removing dependency of omap3 soc first.
>>
>
> Just to clarify: It's my understanding that this is already done by
>
> http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
>
> Do you agree? That is, when this patch is applied, then Samsung can go on.
> Correct?
>
> If not correct, what is missing in above patch?
>
> Best regards
>
> Dirk
>
>
>
I have two request.
1. I want to replace CONFIG_L2_OFF define to other function
for example..
if (need_cache_flush()) { /* or !l2_off() */
/* turn off L2 cache */
l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
i = 0;
/* mem barrier to sync up things */
asm("mcr p15, 0, %0, c7, c10, 4": :"r"(i));
l2_cache_enable();
}
2. I don't want to use get_device_type() function
(just call like this: v7_flush_decahe_all() )
How you think?
thanks
Minkyu Kang
--
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Kyungmin Park > Sent: Monday, September 07, 2009 6:36 AM > To: Wolfgang Denk > Cc: u-boot@lists.denx.de; Magnus Lilja; Minkyu Kang > Subject: Re: [U-Boot] RFC: split ARM repo and distribute workload > > On Sat, Sep 5, 2009 at 6:57 AM, Wolfgang Denk wrote: > > Hello everybody, > > > > ARM has always been one of the architectures that generated a big > > number of different processors and SoCs, but recently the > activitiy in > > this area is literally exploding. This is partially due to the fact > > that ARM is currently used in many designs, so many new ARM based > > processors and SoCs and even more new ARM boards show up, > but another > > and at least as important change is that some silicon and board > > vendors have started to actively pushing their products into the > > U-Boot (and Linux) mainline source trees (and *welcome* they all > > are!). > > > > It has become evident that this growing complexity has > become way too > > massive to be shouldered by a single custodian, even a very > active one > > like Jean-Christophe. > > > > I think we have no other choice but to add more manpower to > this task, > > i. e. split the ARM respository and distribute the workload across a > > few more custodians. > > > > Unline with the Power architecture, where the split can be easily > > defined by processor lines, with ARM it seems more logical to me to > > differentiate by silicon vendors. > > > > After much thinking I therefor suggest to implement the following > > change for the ARM architecture: > > > > > > master ARM repository: Tom Rix > > > > Atmel (AT91): Jean-Christophe Plagniol-Villard > > > > Freescale (i.MX) Magnus Lilja? > > Or are there any volunteers > at Freescale? > > > > Marvell (PXA + IXP): Jean-Christophe Plagniol-Villard > > > > Marvell (all other): Prafulla Wadaskar Hi Wolfgang/Jean Thanks for this responsibility. I acknowledge to accept this opportunity. I suggest to create u-boot-mrvl.git to manage all other Marvell support including current Kirkwood. Thanks and regards.. Prafulla . . > > > > Samsung (s3c, s5pc): Are there any volunteers at Samsung? > > > > I recommended the Minky Kang. He's working for several years for > u-boot from pxa, omap3, s3c6410 and s5pc1xx series. > > But with our internal security policy it's hard to use ssh on u-boot > git. so we want to use u-boot-arm as base. > > Thank you, > Kyungmin Park > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] tools: mkimage: Include default/fit_image.o in the build dependency calculations
This makes sure it gets rebuilt if any of the headers it includes are modified Signed-off-by: Prafulla Wadaskar Acked-by: Ron Lee --- tools/Makefile |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index 858b0e8..d5c23fd 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -93,7 +93,9 @@ EXT_OBJ_FILES-y += lib_generic/sha1.o # Source files located in the tools directory OBJ_FILES-$(CONFIG_LCD_LOGO) += bmp_logo.o OBJ_FILES-$(CONFIG_VIDEO_LOGO) += bmp_logo.o +OBJ_FILES-y += default_image.o OBJ_FILES-$(CONFIG_ENV_IS_EMBEDDED) += envcrc.o +OBJ_FILES-y += fit_image.o OBJ_FILES-$(CONFIG_CMD_NET) += gen_eth_addr.o OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o OBJ_FILES-$(CONFIG_INCA_IP) += inca-swap-bytes.o -- 1.5.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5][repost] tools: mkimage: Making table_entry code global
1. get_table_entry_id API made global
2. get_table_entry_name API made global
3. struct table_entry moved to image.h
Currently it is used by image.c only
These APIs are very usefull and can be used by other part of code
This patch makes these APIs and struct global
Signed-off-by: Prafulla Wadaskar
Acked-by: Ron Lee
---
common/image.c | 10 ++
include/image.h | 26 ++
2 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/common/image.c b/common/image.c
index ca8205c..e8ecfa5 100644
--- a/common/image.c
+++ b/common/image.c
@@ -74,12 +74,6 @@ static const image_header_t* image_get_ramdisk (ulong
rd_addr, uint8_t arch,
#include
#endif /* !USE_HOSTCC*/
-typedef struct table_entry {
- int id; /* as defined in image.h*/
- char*sname; /* short (input) name */
- char*lname; /* long (output) name */
-} table_entry_t;
-
static table_entry_t uimage_arch[] = {
{ IH_ARCH_INVALID,NULL, "Invalid ARCH", },
{ IH_ARCH_ALPHA, "alpha","Alpha",},
@@ -514,7 +508,7 @@ static void genimg_print_time (time_t timestamp)
* long entry name if translation succeeds
* msg otherwise
*/
-static char *get_table_entry_name (table_entry_t *table, char *msg, int id)
+char *get_table_entry_name (table_entry_t *table, char *msg, int id)
{
for (; table->id >= 0; ++table) {
if (table->id == id)
@@ -561,7 +555,7 @@ const char *genimg_get_comp_name (uint8_t comp)
* entry id if translation succeeds
* -1 otherwise
*/
-static int get_table_entry_id (table_entry_t *table,
+int get_table_entry_id (table_entry_t *table,
const char *table_name, const char *name)
{
table_entry_t *t;
diff --git a/include/image.h b/include/image.h
index 4a7bf78..58f13f9 100644
--- a/include/image.h
+++ b/include/image.h
@@ -284,6 +284,32 @@ typedef struct bootm_headers {
#define uimage_to_cpu(x) be32_to_cpu(x)
#define cpu_to_uimage(x) cpu_to_be32(x)
+/*
+ * Translation table for entries of a specific type
+ * This structue is used by the global functions get_table_entry_id,
+ * get_table_entry_name and these functions and this structure can also be
+ * referred by other part of code
+ */
+typedef struct table_entry {
+ int id;
+ char*sname; /* name used to find table entry */
+ char*lname; /* name used to print for messages */
+} table_entry_t;
+
+/*
+ * get_table_entry_id() will go over translation table trying to find
+ * entry that matches given short name. If matching entry is found,
+ * its id returned to the caller.
+ */
+int get_table_entry_id (table_entry_t *table,
+ const char *table_name, const char *name);
+/*
+ * get_table_entry_name() will go over translation table trying to find
+ * entry that matches given id. If matching entry is found, its long
+ * name is returned to the caller.
+ */
+char *get_table_entry_name (table_entry_t *table, char *msg, int id);
+
const char *genimg_get_os_name (uint8_t os);
const char *genimg_get_arch_name (uint8_t arch);
const char *genimg_get_type_name (uint8_t type);
--
1.5.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] Kirkwood: Sheevaplug: kwimage configuration
Signed-off-by: Prafulla Wadaskar --- board/Marvell/sheevaplug/config.mk|3 + board/Marvell/sheevaplug/kwbimage.cfg | 162 + 2 files changed, 165 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/sheevaplug/kwbimage.cfg diff --git a/board/Marvell/sheevaplug/config.mk b/board/Marvell/sheevaplug/config.mk index a4ea769..2bd9f79 100644 --- a/board/Marvell/sheevaplug/config.mk +++ b/board/Marvell/sheevaplug/config.mk @@ -23,3 +23,6 @@ # TEXT_BASE = 0x0060 + +# Kirkwood Boot Image configuration file +KWD_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/kwbimage.cfg diff --git a/board/Marvell/sheevaplug/kwbimage.cfg b/board/Marvell/sheevaplug/kwbimage.cfg new file mode 100644 index 000..6c47d62 --- /dev/null +++ b/board/Marvell/sheevaplug/kwbimage.cfg @@ -0,0 +1,162 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor +# Written-by: Prafulla Wadaskar +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# +# Refer docs/README.kwimage for more details about how-to configure +# and create kirkwood boot image +# + +# Boot Media configurations +BOOT_FROM nand +NAND_ECC_MODE default +NAND_PAGE_SIZE 0x0800 + +# SOC registers configuration using bootrom header extension +# Maximum KWBIMAGE_MAX_CONFIG configurations allowed + +# Configure RGMII-0 interface pad voltage to 1.8V +DATA 0xFFD100e0 0x1b1b1b9b + +#Dram initalization for SINGLE x16 CL=5 @ 400MHz +DATA 0xFFD01400 0x43000c30 # DDR Configuration register +# bit13-0: 0xc30 (3120 DDR2 clks refresh rate) +# bit23-14: zero +# bit24: 1= enable exit self refresh mode on DDR access +# bit25: 1 required +# bit29-26: zero +# bit31-30: 01 + +DATA 0xFFD01404 0x37543000 # DDR Controller Control Low +# bit 4:0=addr/cmd in smame cycle +# bit 5:0=clk is driven during self refresh, we don't care for APX +# bit 6:0=use recommended falling edge of clk for addr/cmd +# bit14:0=input buffer always powered up +# bit18:1=cpu lock transaction enabled +# bit23-20: 5=recommended value for CL=5 and STARTBURST_DEL disabled bit31=0 +# bit27-24: 7= CL+2, STARTBURST sample stages, for freqs 400MHz, unbuffered DIMM +# bit30-28: 3 required +# bit31:0=no additional STARTBURST delay + +DATA 0xFFD01408 0x22125451 # DDR Timing (Low) (active cycles value +1) +# bit3-0: TRAS lsbs +# bit7-4: TRCD +# bit11- 8: TRP +# bit15-12: TWR +# bit19-16: TWTR +# bit20:TRAS msb +# bit23-21: 0x0 +# bit27-24: TRRD +# bit31-28: TRTP + +DATA 0xFFD0140C 0x0a33 # DDR Timing (High) +# bit6-0: TRFC +# bit8-7: TR2R +# bit10-9: TR2W +# bit12-11: TW2W +# bit31-13: zero required + +DATA 0xFFD01410 0x0099 # DDR Address Control +# bit1-0: 01, Cs0width=x16 +# bit3-2: 10, Cs0size=512Mb +# bit5-4: 01, Cs1width=x16 +# bit7-6: 10, Cs1size=512Mb +# bit9-8: 00, Cs2width=nonexistent +# bit11-10: 00, Cs2size =nonexistent +# bit13-12: 00, Cs3width=nonexistent +# bit15-14: 00, Cs3size =nonexistent +# bit16:0, Cs0AddrSel +# bit17:0, Cs1AddrSel +# bit18:0, Cs2AddrSel +# bit19:0, Cs3AddrSel +# bit31-20: 0 required + +DATA 0xFFD01414 0x # DDR Open Pages Control +# bit0:0, OpenPage enabled +# bit31-1: 0 required + +DATA 0xFFD01418 0x # DDR Operation +# bit3-0: 0x0, DDR cmd +# bit31-4: 0 required + +DATA 0xFFD0141C 0x0C52 # DDR Mode +# bit2-0: 2, BurstLen=2 required +# bit3: 0, BurstType=0 required +# bit6-4: 4, CL=5 +# bit7: 0, TestMode=0 normal +# bit8: 0, DLL reset=0 normal +# bit11-9: 6, auto-precharge write recovery +# bit12:0, PD must be zero +# bit31-13: 0 required + +DATA 0xFFD01420 0x0040 # DDR Extended Mode +# bit0:0, DDR DLL enabled +# bit1:0, DDR drive strenght normal +# bit2:0, DDR ODT control lsd (disabled) +# bit5-3: 000, required +# bit6:1, DDR ODT control msb, (disabled) +# bit9-7: 000, required +# bit10: 0, differential DQS enabled +# bit11: 0, required +# bit12: 0, DDR output buffer enabled +# bit31-13: 0 required + +DATA 0xFFD01424 0xF17F # DDR Controller Control High +# bit2-0: 111, required +# bit3 : 1 , MBUS Burst Chop disabled +# bit6-4: 111, required +# bit7 : 0 +# bit8 : 1 , add writepath sampl
[U-Boot] [PATCH 2/5][repost] tools: mkimage: Making genimg_print_size API global
Currently it is used by image.c only
This API can be used by additional mkimage types supports
for ex. kwbimage, to use it the API is made global
Signed-off-by: Prafulla Wadaskar
---
common/image.c |3 +--
include/image.h |1 +
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/image.c b/common/image.c
index f3dd647..ca8205c 100644
--- a/common/image.c
+++ b/common/image.c
@@ -158,7 +158,6 @@ static table_entry_t uimage_comp[] = {
uint32_t crc32 (uint32_t, const unsigned char *, uint);
uint32_t crc32_wd (uint32_t, const unsigned char *, uint, uint);
-static void genimg_print_size (uint32_t size);
#if defined(CONFIG_TIMESTAMP) || defined(CONFIG_CMD_DATE) ||
defined(USE_HOSTCC)
static void genimg_print_time (time_t timestamp);
#endif
@@ -473,7 +472,7 @@ void memmove_wd (void *to, void *from, size_t len, ulong
chunksz)
}
#endif /* !USE_HOSTCC */
-static void genimg_print_size (uint32_t size)
+void genimg_print_size (uint32_t size)
{
#ifndef USE_HOSTCC
printf ("%d Bytes = ", size);
diff --git a/include/image.h b/include/image.h
index a62669f..4a7bf78 100644
--- a/include/image.h
+++ b/include/image.h
@@ -292,6 +292,7 @@ int genimg_get_os_id (const char *name);
int genimg_get_arch_id (const char *name);
int genimg_get_type_id (const char *name);
int genimg_get_comp_id (const char *name);
+void genimg_print_size (uint32_t size);
#ifndef USE_HOSTCC
/* Image format types, returned by _get_format() routine */
--
1.5.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 5/5] tools: mkimage: Add: Kirkwood Boot Image support (kwbimage)
This patch adds type kwbimabe support for new mkimage core
For more details refer docs/README.kwbimage
This patch is tested with Sheevaplug board
Signed-off-by: Prafulla Wadaskar
Acked-by: Ron Lee
Signed-off-by: Prafulla Wadaskar
---
v2: updated as per review comments for v1
added len checks in checksum functions
added printable strings for each valid table entry
use of sccanf not changed since it offers return value for failure
v3: resolved merge issues on mkimage branch
v4: added warning fix on amd64
Use an intermediate type as large as the pointers we do simple arithmetic
with.
Use a format string type that suits the sizeof type from
KWBIMAGE_MAX_CONFIG.
The compiler warns about both of these on amd64.
included kwbimage.o in the build dependency calculations
_GNU_SOURCE defined to obtain getline prototype from stdio.h
most of these changes suggested by Ron Lee (in cc list)
Makefile|5 +
common/image.c |1 +
doc/README.kwbimage | 93
include/image.h |1 +
tools/Makefile |5 +
tools/kwbimage.c| 405 +++
tools/kwbimage.h| 106 +
tools/mkimage.c |2 +
tools/mkimage.h |1 +
9 files changed, 619 insertions(+), 0 deletions(-)
create mode 100644 doc/README.kwbimage
create mode 100644 tools/kwbimage.c
create mode 100644 tools/kwbimage.h
diff --git a/Makefile b/Makefile
index 329e0f5..7d7637a 100644
--- a/Makefile
+++ b/Makefile
@@ -314,6 +314,10 @@ $(obj)u-boot.img: $(obj)u-boot.bin
sed -e 's/"[ ]*$$/ for $(BOARD) board"/') \
-d $< $@
+$(obj)u-boot.kwb: $(obj)u-boot.bin
+ $(obj)tools/mkimage -n $(KWD_CONFIG) -T kwbimage \
+ -a $(TEXT_BASE) -e $(TEXT_BASE) -d $< $@
+
$(obj)u-boot.sha1: $(obj)u-boot.bin
$(obj)tools/ubsha1 $(obj)u-boot.bin
@@ -3671,6 +3675,7 @@ clobber: clean
@rm -f $(OBJS) $(obj)*.bak $(obj)ctags $(obj)etags $(obj)TAGS \
$(obj)cscope.* $(obj)*.*~
@rm -f $(obj)u-boot $(obj)u-boot.map $(obj)u-boot.hex $(ALL)
+ @rm -f $(obj)u-boot.kwb
@rm -f $(obj)tools/{env/crc32.c,inca-swap-bytes}
@rm -f $(obj)cpu/mpc824x/bedbug_603e.c
@rm -f $(obj)include/asm/proc $(obj)include/asm/arch $(obj)include/asm
diff --git a/common/image.c b/common/image.c
index e8ecfa5..d0f169d 100644
--- a/common/image.c
+++ b/common/image.c
@@ -139,6 +139,7 @@ static table_entry_t uimage_type[] = {
{ IH_TYPE_SCRIPT, "script", "Script", },
{ IH_TYPE_STANDALONE, "standalone", "Standalone Program", },
{ IH_TYPE_FLATDT, "flat_dt","Flat Device Tree", },
+ { IH_TYPE_KWBIMAGE, "kwbimage", "Kirkwood Boot Image",},
{ -1, "", "", },
};
diff --git a/doc/README.kwbimage b/doc/README.kwbimage
new file mode 100644
index 000..2a5b3b3
--- /dev/null
+++ b/doc/README.kwbimage
@@ -0,0 +1,93 @@
+-
+Kirkwood Boot Image generation using mkimage
+-
+
+This document describes the U-Boot feature as it
+is implemented for the Kirkwood family of SoCs.
+
+The Kirkwood SoC's can boot directly from NAND FLASH,
+SPI FLASH, SATA etc. using its internal bootRom support.
+
+for more details refer section 24.2 of Kirkwood functional specifications.
+ref: www.marvell.com/products/embedded.../kirkwood/index.jsp
+
+Command syntax:
+--
+./tools/mkimage -l
+ to list the kwb image file details
+
+./tools/mkimage -n \
+-T kwbimage -a -e \
+ -d
+
+for ex.
+./tools/mkimage -n ./board/Marvell/openrd_base/kwbimage.cfg \
+-T kwbimage -a 0x0060 -e 0x0060 \
+ -d u-boot.bin u-boot.kwb
+
+kwimage support available with mkimage utility will generate kirkwood boot
+image that can be flashed on the board NAND/SPI flash
+
+Board specific configuration file specifications:
+
+1. This file must present in the $(BOARDDIR) and the name should be
+ kwbimage.cfg (since this is used in Makefile)
+2. This file can have empty lines and lines starting with "#" as first
+ character to put comments
+3. This file can have configuration command lines as mentioned below,
+ any other information in this file is treated as invalid.
+
+Configuration command line syntax:
+-
+1. Each command line is must have two strings, first one command or address
+ and second one data string
+2. Following are the valid command strings and associated data strings:-
+ Command string data string
+ -- ---
+ BOOT_FROM nand/spi/sata
+ NAND_ECC_MODE default/rs/hamming/disabled
[U-Boot] [PATCH v4 5/5][repost] tools: mkimage: Add: Kirkwood Boot Image support (kwbimage)
This patch adds type kwbimage support for new mkimage core
For more details refer docs/README.kwbimage
This patch is tested with Sheevaplug board
Signed-off-by: Prafulla Wadaskar
Acked-by: Ron Lee
Signed-off-by: Prafulla Wadaskar
---
v2: updated as per review comments for v1
added len checks in checksum functions
added printable strings for each valid table entry
use of sccanf not changed since it offers return value for failure
v3: resolved merge issues on mkimage branch
v4: added warning fix on amd64
Use an intermediate type as large as the pointers we do simple arithmetic
with.
Use a format string type that suits the sizeof type from
KWBIMAGE_MAX_CONFIG.
The compiler warns about both of these on amd64.
included kwbimage.o in the build dependency calculations
_GNU_SOURCE defined to obtain getline prototype from stdio.h
most of these changes suggested by Ron Lee (in cc list)
v4 repost: typos corrected in commit message
Makefile|5 +
common/image.c |1 +
doc/README.kwbimage | 93
include/image.h |1 +
tools/Makefile |5 +
tools/kwbimage.c| 405 +++
tools/kwbimage.h| 106 +
tools/mkimage.c |2 +
tools/mkimage.h |1 +
9 files changed, 619 insertions(+), 0 deletions(-)
create mode 100644 doc/README.kwbimage
create mode 100644 tools/kwbimage.c
create mode 100644 tools/kwbimage.h
diff --git a/Makefile b/Makefile
index 329e0f5..7d7637a 100644
--- a/Makefile
+++ b/Makefile
@@ -314,6 +314,10 @@ $(obj)u-boot.img: $(obj)u-boot.bin
sed -e 's/"[ ]*$$/ for $(BOARD) board"/') \
-d $< $@
+$(obj)u-boot.kwb: $(obj)u-boot.bin
+ $(obj)tools/mkimage -n $(KWD_CONFIG) -T kwbimage \
+ -a $(TEXT_BASE) -e $(TEXT_BASE) -d $< $@
+
$(obj)u-boot.sha1: $(obj)u-boot.bin
$(obj)tools/ubsha1 $(obj)u-boot.bin
@@ -3671,6 +3675,7 @@ clobber: clean
@rm -f $(OBJS) $(obj)*.bak $(obj)ctags $(obj)etags $(obj)TAGS \
$(obj)cscope.* $(obj)*.*~
@rm -f $(obj)u-boot $(obj)u-boot.map $(obj)u-boot.hex $(ALL)
+ @rm -f $(obj)u-boot.kwb
@rm -f $(obj)tools/{env/crc32.c,inca-swap-bytes}
@rm -f $(obj)cpu/mpc824x/bedbug_603e.c
@rm -f $(obj)include/asm/proc $(obj)include/asm/arch $(obj)include/asm
diff --git a/common/image.c b/common/image.c
index e8ecfa5..d0f169d 100644
--- a/common/image.c
+++ b/common/image.c
@@ -139,6 +139,7 @@ static table_entry_t uimage_type[] = {
{ IH_TYPE_SCRIPT, "script", "Script", },
{ IH_TYPE_STANDALONE, "standalone", "Standalone Program", },
{ IH_TYPE_FLATDT, "flat_dt","Flat Device Tree", },
+ { IH_TYPE_KWBIMAGE, "kwbimage", "Kirkwood Boot Image",},
{ -1, "", "", },
};
diff --git a/doc/README.kwbimage b/doc/README.kwbimage
new file mode 100644
index 000..2a5b3b3
--- /dev/null
+++ b/doc/README.kwbimage
@@ -0,0 +1,93 @@
+-
+Kirkwood Boot Image generation using mkimage
+-
+
+This document describes the U-Boot feature as it
+is implemented for the Kirkwood family of SoCs.
+
+The Kirkwood SoC's can boot directly from NAND FLASH,
+SPI FLASH, SATA etc. using its internal bootRom support.
+
+for more details refer section 24.2 of Kirkwood functional specifications.
+ref: www.marvell.com/products/embedded.../kirkwood/index.jsp
+
+Command syntax:
+--
+./tools/mkimage -l
+ to list the kwb image file details
+
+./tools/mkimage -n \
+-T kwbimage -a -e \
+ -d
+
+for ex.
+./tools/mkimage -n ./board/Marvell/openrd_base/kwbimage.cfg \
+-T kwbimage -a 0x0060 -e 0x0060 \
+ -d u-boot.bin u-boot.kwb
+
+kwimage support available with mkimage utility will generate kirkwood boot
+image that can be flashed on the board NAND/SPI flash
+
+Board specific configuration file specifications:
+
+1. This file must present in the $(BOARDDIR) and the name should be
+ kwbimage.cfg (since this is used in Makefile)
+2. This file can have empty lines and lines starting with "#" as first
+ character to put comments
+3. This file can have configuration command lines as mentioned below,
+ any other information in this file is treated as invalid.
+
+Configuration command line syntax:
+-
+1. Each command line is must have two strings, first one command or address
+ and second one data string
+2. Following are the valid command strings and associated data strings:-
+ Command string data string
+ -- ---
+ BOOT_FROM nand/spi/sata
+ NAND
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
On Fri, 04 Sep 2009 22:05:45 +0200 Wolfgang Denk wrote: > > nand_bbt: Can't scan flash and build the RAM-based BBT > > Net: egiga0 > > 88E1116 Initialized on egiga0 > > Hit any key to stop autoboot: 0 > > Marvell>> > > > > The 4.1 version just hangs on the NAND printout. I've tested both with > > USE_PRIVATE_LIBGCC=yes and USE_PRIVATE_LIBGCC unset, and get the same > > results. > > Did you make any progress an analyzing the cause of the issue? Well, I sent a patch "[PATCH, RFC] Make arm926ejs use -march=armv5t to avoid problems with EABI", which corrects this for me, although I'd like some input on if it really makes any sense. The main difference I see between the two binaries is the use of ldrd/strd instructions, which comes with the "e"-version of armv5t. Obviously, that shouldn't by itself produce broken binaries, so something is still fishy here. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/4]: arm: Define test_and_set_bit and test_and_clear bit for ARM
Hi Justin!
On Fri, 4 Sep 2009 17:27:59 -0400
Justin Waters wrote:
> I found a slight problem with this section of the patch:
>
> On Mon, 2009-08-24 at 03:10 -0400, Simon Kagstrom wrote:
> > diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
> > index 854e225..3c7b00c 100644
> > --- a/include/asm-arm/bitops.h
> > +++ b/include/asm-arm/bitops.h
> > @@ -17,6 +17,8 @@
> >
> > #ifdef __KERNEL__
> >
> > +#include
> > +
>
> It causes a compiler error on the arm926ejs platform:
>
> In file included from cpu.c:34:
> /home/justin/git/u-boot/include/asm/system.h: At top level:
> /home/justin/git/u-boot/include/asm/system.h:71: error: expected
> identifier or '(' before 'asm'
>
> I did some digging, and it looks like set_cr() is implemented by both
> asm-arm/system.h and asm-arm/proc-armv/system.h. One implements the
> function as a macro, while the other uses a standard C function, hence
> the weird error message. The conflict occurs in cpu/arm926ejs/cpu.c.
You are right, but I believe this was fixed an earlier patch, "[PATCH]
Remove duplicate set_cr" [1], which is in the ARM tree. I guess that
one hasn't shown up in Wolfgangs repository yet, so this series must be
applied to the ARM tree for now.
Thanks for testing!
// Simon
[1]
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=f3d4f8870e69e0fd177397778d97d0751bbd020a
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
> -Original Message- > From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] > Sent: Saturday, September 05, 2009 4:48 AM > To: Wolfgang Denk > Cc: u-boot@lists.denx.de; Tom Rix; Magnus Lilja; Prafulla > Wadaskar; Dirk Behme; Minkyu Kang; Kyungmin Park; Harald Welte > Subject: Re: RFC: split ARM repo and distribute workload > > On 23:57 Fri 04 Sep , Wolfgang Denk wrote: > > Hello everybody, > > > > ARM has always been one of the architectures that generated a big > > number of different processors and SoCs, but recently the > activitiy in > > this area is literally exploding. This is partially due to the fact > > that ARM is currently used in many designs, so many new ARM based > > processors and SoCs and even more new ARM boards show up, > but another > > and at least as important change is that some silicon and board > > vendors have started to actively pushing their products into the > > U-Boot (and Linux) mainline source trees (and *welcome* they all > > are!). > > > > It has become evident that this growing complexity has > become way too > > massive to be shouldered by a single custodian, even a very > active one > > like Jean-Christophe. > > > > I think we have no other choice but to add more manpower to > this task, > > i. e. split the ARM respository and distribute the workload across a > > few more custodians. > > > > Unline with the Power architecture, where the split can be easily > > defined by processor lines, with ARM it seems more logical to me to > > differentiate by silicon vendors. > > > > After much thinking I therefor suggest to implement the following > > change for the ARM architecture: > > > > > > I think this will be better > > master ARM repository : Jean-Christophe Plagniol-Villard > > Freescale (i.MX) Magnus Lilja? > Or are there any volunteers at > Freescale? > > Marvell Prafulla Wadaskar This makes more sense for u-boot-mrvl.git (proposed) to go entire Marvell specific patches through it Regards.. Prafulla . . > > Samsung (s3c, s5pc): Are there any volunteers at Samsung? > > Texas Instruments (OMAP): Tom Rix > > Best Regards, > J. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
