| Message ID | 51599458.1000505@mm-sol.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Tom Rini |
| Headers | show |
On Mon, Apr 01, 2013 at 05:06:16PM +0300, Lubomir Popov wrote: > Signed-off-by: Lubomir Popov <lpopov@mm-sol.com> Thought I had reviewed this already, sorry. > > --- > > The som5_evb is an evaluation board for the APM-5 - a OMAP5430-based SOM (system > On a Module) designed by MMS and manufactured under license by Jorjin Technologies. Above the '---' so it's in the changelog. > diff --git a/arch/arm/include/asm/mach-types.h b/arch/arm/include/asm/mach-types.h > index a676b6d..236fa17 100644 > --- a/arch/arm/include/asm/mach-types.h > +++ b/arch/arm/include/asm/mach-types.h > @@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type; > #define MACH_TYPE_OMAP5_SEVM 3777 > #define MACH_TYPE_ARMADILLO_800EVA 3863 > #define MACH_TYPE_KZM9G 4140 > +#define MACH_TYPE_SOM5_EVB 4545 Don't touch this file and instead add just this define to your config, and then #define CONFIG_MACH_TYPE MACH_... If you can't just support DT-only. [snip] > +const struct pad_conf_entry core_padconf_array_non_essential[] = { > +#if 0 Remove #if 0'd code. > + gd->bd->bi_arch_number = MACH_TYPE_SOM5_EVB; CONFIG_MACH_TYPE in your config and you don't need this line > +#ifdef CONFIG_TWL6035_AUDPWR > + /* Useful for measuring voltages around the codec. > + * Works with a TWL604x only. > + */ /* * Like this */ > +#ifdef CONFIG_I2C_INTERNAL_PULLUPS > + /* Enable internal I2C-compatible pullups on all buses > + * TODO: Replace this ugly hardcoding with proper defines (omap.h) > + * control_smart3io_padconf_0, control_i2c_0 Do please, thanks. > +#define USB_HOST_HS_CLKCTRL_MASK 0x0100D7C0 /* CM_L3INIT_USB_HOST_HS_CLKCTRL */ > +#define USB_TLL_HS_CLKCTRL_MASK 0x00000700 /* CM_L3INIT_USB_TLL_HS_CLKCTRL */ Some header please. > + * TODO: Replace this ugly hardcoding with proper defines > + */ > + writel(0x0100, 0x4ae0a310); Again, do please. > +#define CONFIG_OMAP5430 /* which is in a 5430 */ > +#define CONFIG_SOM5EVB /* working with the SOM5 EVB */ Unused. > +/* Machine type for Linux */ > +#define CONFIG_MACH_TYPE MACH_TYPE_SOM5_EVB Ah, since you do have this part already, just update the rest as I had said. > +/* Enable all clocks: */ > +/*#define CONFIG_SYS_CLOCKS_ENABLE_ALL*/ > + > +#define CONFIG_SYS_ENABLE_PADS_ALL /* Enable all PADS for now */ Not allowed. > +#define CONFIG_SYS_CA15_VECTOR_BASE SRAM_ROM_VECT_BASE Introduced in the USB patches? > +#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, \ > + 57600, 115200} Please use the fallback table. > +/* MMC ENV related defines */ > +#define CONFIG_ENV_IS_NOWHERE > +#ifdef CONFIG_ENV_IS_IN_MMC > +#define CONFIG_SYS_MMC_ENV_DEV 1 /* SLOT2: eMMC(1) */ > +#define CONFIG_ENV_OFFSET 0xE0000 > +#define CONFIG_CMD_SAVEENV > +#endif This is a little un-clear. If MMC will be in mmc like the uEVM, just do so, and if no storage of env, leave it as NOWHERE. > +#define CONFIG_CMD_PING /* PING support */ space not tab, fix globally. > +#define CONFIG_NET_MULTI Unused. > + "usbethaddr=9e:77:39:1b:c4:2d\0" \ Not allowed. > +/* > + * memtest setup > + */ > +#define CONFIG_SYS_MEMTEST_START 0xb8000000 > +#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + (256 << 20)) > +/* Undef following two for simple mtest */ > +#define CONFIG_SYS_ALT_MEMTEST > +#define CONFIG_SYS_MEMTEST_SCRATCH 0x81000000 Please see doc/README.memory-test and update as mtest is no longer a default command. Thanks!
Hi Tom, On 25/04/13 22:01, Tom Rini wrote: > On Mon, Apr 01, 2013 at 05:06:16PM +0300, Lubomir Popov wrote: > >> Signed-off-by: Lubomir Popov <lpopov@mm-sol.com> > > Thought I had reviewed this already, sorry. Thanks for your review. During the past month U-Boot has changed; I have tried to follow as well (although I'm engaged with other stuff) and some of your remarks have been already fixed. Please see my comments inline below. Anyway, I guess that a V2 patch shall have to be referenced against the current master. Or against u-boot-ti/next? Please note that for this board to work with the defined configuration, the following patches are also required (unfortunately some are already quite old and might cause conflicts): - Power: http://patchwork.ozlabs.org/patch/232732/. Potential conflict with Nishanth Menon's series of March 26, applied to u-boot-ti/next. - For I2C support: * The patch series of Apr. 8 that enables I2C4 and I2C5 (applied to u-boot-ti/next; affects all OMAP5 boards). * The modified i2c driver: http://patchwork.ozlabs.org/patch/233823/ (useful for all OMAP3/4/5 boards). - For USB support: * http://patchwork.ozlabs.org/patch/235684/ (affects all OMAP5 boards) * http://patchwork.ozlabs.org/patch/232742/ (affects all OMAP5 boards) > >> >> --- >> >> The som5_evb is an evaluation board for the APM-5 - a OMAP5430-based SOM (system >> On a Module) designed by MMS and manufactured under license by Jorjin Technologies. > > Above the '---' so it's in the changelog. OK, sure, my fault > >> diff --git a/arch/arm/include/asm/mach-types.h b/arch/arm/include/asm/mach-types.h >> index a676b6d..236fa17 100644 >> --- a/arch/arm/include/asm/mach-types.h >> +++ b/arch/arm/include/asm/mach-types.h >> @@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type; >> #define MACH_TYPE_OMAP5_SEVM 3777 >> #define MACH_TYPE_ARMADILLO_800EVA 3863 >> #define MACH_TYPE_KZM9G 4140 >> +#define MACH_TYPE_SOM5_EVB 4545 > > Don't touch this file and instead add just this define to your config, > and then #define CONFIG_MACH_TYPE MACH_... If you can't just support > DT-only. OK > > [snip] >> +const struct pad_conf_entry core_padconf_array_non_essential[] = { >> +#if 0 > > Remove #if 0'd code. Done >> + gd->bd->bi_arch_number = MACH_TYPE_SOM5_EVB; > > CONFIG_MACH_TYPE in your config and you don't need this line All OMAP boards currently have it. Stay as is. > >> +#ifdef CONFIG_TWL6035_AUDPWR >> + /* Useful for measuring voltages around the codec. >> + * Works with a TWL604x only. >> + */ > > /* > * Like this > */ Fixed > >> +#ifdef CONFIG_I2C_INTERNAL_PULLUPS >> + /* Enable internal I2C-compatible pullups on all buses >> + * TODO: Replace this ugly hardcoding with proper defines (omap.h) >> + * control_smart3io_padconf_0, control_i2c_0 > > Do please, thanks. Was already done. > >> +#define USB_HOST_HS_CLKCTRL_MASK 0x0100D7C0 /* CM_L3INIT_USB_HOST_HS_CLKCTRL */ >> +#define USB_TLL_HS_CLKCTRL_MASK 0x00000700 /* CM_L3INIT_USB_TLL_HS_CLKCTRL */ > > Some header please. Currently moved to board header. I wondered if a common OMAP header wouldn't be more suitable, but having in mind that the utilized USB ports (and thus the clocks that should be enabled) vary from board to board, perhaps this (i.e. board header) is the best place. > >> + * TODO: Replace this ugly hardcoding with proper defines >> + */ >> + writel(0x0100, 0x4ae0a310); > > Again, do please. This should be (*scrm)->auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? > >> +#define CONFIG_OMAP5430 /* which is in a 5430 */ >> +#define CONFIG_SOM5EVB /* working with the SOM5 EVB */ > > Unused. Long gone. BTW, board config now includes omap5_common.h. > >> +/* Machine type for Linux */ >> +#define CONFIG_MACH_TYPE MACH_TYPE_SOM5_EVB > > Ah, since you do have this part already, just update the rest as I had > said. /* Machine type for Linux */ #ifndef MACH_TYPE_SOM5_EVB #define MACH_TYPE_SOM5_EVB 4545 #endif #define CONFIG_MACH_TYPE MACH_TYPE_SOM5_EVB Is this OK? > >> +/* Enable all clocks: */ >> +/*#define CONFIG_SYS_CLOCKS_ENABLE_ALL*/ >> + >> +#define CONFIG_SYS_ENABLE_PADS_ALL /* Enable all PADS for now */ > > Not allowed. Shall see to it. What if one needs to test pins and connections during board bring-up, e.g. via gpio commands? > >> +#define CONFIG_SYS_CA15_VECTOR_BASE SRAM_ROM_VECT_BASE > > Introduced in the USB patches? Not used and removed a while ago. > >> +#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, \ >> + 57600, 115200} > > Please use the fallback table. Already done. > >> +/* MMC ENV related defines */ >> +#define CONFIG_ENV_IS_NOWHERE >> +#ifdef CONFIG_ENV_IS_IN_MMC >> +#define CONFIG_SYS_MMC_ENV_DEV 1 /* SLOT2: eMMC(1) */ >> +#define CONFIG_ENV_OFFSET 0xE0000 >> +#define CONFIG_CMD_SAVEENV >> +#endif > > This is a little un-clear. If MMC will be in mmc like the uEVM, just do > so, and if no storage of env, leave it as NOWHERE. Cerrently looks like this: /* MMC ENV related defines */ #undef CONFIG_ENV_IS_IN_MMC #undef CONFIG_SYS_MMC_ENV_DEV #undef CONFIG_ENV_OFFSET #define CONFIG_ENV_IS_NOWHERE > >> +#define CONFIG_CMD_PING /* PING support */ > > space not tab, fix globally. Done. > >> +#define CONFIG_NET_MULTI > > Unused. Removed. > >> + "usbethaddr=9e:77:39:1b:c4:2d\0" \ > > Not allowed. Gone. > >> +/* >> + * memtest setup >> + */ >> +#define CONFIG_SYS_MEMTEST_START 0xb8000000 >> +#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + (256 << 20)) >> +/* Undef following two for simple mtest */ >> +#define CONFIG_SYS_ALT_MEMTEST >> +#define CONFIG_SYS_MEMTEST_SCRATCH 0x81000000 > > Please see doc/README.memory-test and update as mtest is no longer a > default command. Now the config tail looks like this: /* Undef/remove after bring-up: */ #define CONFIG_CMD_MEMTEST /* Disabled commands */ #undef CONFIG_CMD_SAVEENV /* Prompt */ #define CONFIG_SYS_PROMPT "SOM5_EVB # " #ifdef CONFIG_CMD_MEMTEST /* Undef following two for simple mtest */ #define CONFIG_SYS_ALT_MEMTEST #define CONFIG_SYS_MEMTEST_SCRATCH 0xb7fffff0 #ifdef CONFIG_SYS_ALT_MEMTEST #undef CONFIG_SYS_MEMTEST_START #define CONFIG_SYS_MEMTEST_START 0xb8000000 #undef CONFIG_SYS_MEMTEST_END #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + (256 << 20)) #endif #endif /* CONFIG_CMD_MEMTEST */ > > Thanks! >
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/26/2013 11:59 AM, Lubomir Popov wrote: > Hi Tom, > > On 25/04/13 22:01, Tom Rini wrote: >> On Mon, Apr 01, 2013 at 05:06:16PM +0300, Lubomir Popov wrote: >> >>> Signed-off-by: Lubomir Popov <lpopov@mm-sol.com> >> >> Thought I had reviewed this already, sorry. > Thanks for your review. During the past month U-Boot has changed; I > have tried to follow as well (although I'm engaged with other > stuff) and some of your remarks have been already fixed. Please see > my comments inline below. > > Anyway, I guess that a V2 patch shall have to be referenced against > the current master. Or against u-boot-ti/next? OK, sorry for the late reply again. Now that u-boot-arm has resynced with master, I've also resynced and gotten a pull done. You can use either u-boot-arm/master or u-boot-ti/master. > > Please note that for this board to work with the defined > configuration, the following patches are also required > (unfortunately some are already quite old and might cause > conflicts): > > - Power: http://patchwork.ozlabs.org/patch/232732/. Potential > conflict with Nishanth Menon's series of March 26, applied to > u-boot-ti/next. - For I2C support: * The patch series of Apr. 8 > that enables I2C4 and I2C5 (applied to u-boot-ti/next; affects all > OMAP5 boards). * The modified i2c driver: > http://patchwork.ozlabs.org/patch/233823/ (useful for all OMAP3/4/5 > boards). - For USB support: * > http://patchwork.ozlabs.org/patch/235684/ (affects all OMAP5 > boards) * http://patchwork.ozlabs.org/patch/232742/ (affects all > OMAP5 boards) OK. Please make sure these still apply and if not update and re-send. I think I've already grabbed a few of these. [snip] >>> +#define USB_HOST_HS_CLKCTRL_MASK 0x0100D7C0 /* >>> CM_L3INIT_USB_HOST_HS_CLKCTRL */ +#define >>> USB_TLL_HS_CLKCTRL_MASK 0x00000700 /* >>> CM_L3INIT_USB_TLL_HS_CLKCTRL */ >> >> Some header please. > Currently moved to board header. I wondered if a common OMAP header > wouldn't be more suitable, but having in mind that the utilized USB > ports (and thus the clocks that should be enabled) vary from board > to board, perhaps this (i.e. board header) is the best place. The masks won't change tho, yes? Common header somewhere. >> >>> + * TODO: Replace this ugly hardcoding with proper defines + >>> */ + writel(0x0100, 0x4ae0a310); >> >> Again, do please. > This should be (*scrm)->auxclk0. The problem is that the > omap5_scrm_regs struct (holding the auxclk0 member) has to be > defined somewhere in the common OMAP5 headers. Sricharan? Or should > I hack around? Add it to the most likely struct in the headers. [snip] >> Ah, since you do have this part already, just update the rest as >> I had said. > /* Machine type for Linux */ #ifndef MACH_TYPE_SOM5_EVB #define > MACH_TYPE_SOM5_EVB 4545 #endif #define CONFIG_MACH_TYPE > MACH_TYPE_SOM5_EVB > > Is this OK? I think we'd decided in general to not do ifndef and just always define it. >>> +/* Enable all clocks: */ +/*#define >>> CONFIG_SYS_CLOCKS_ENABLE_ALL*/ + +#define >>> CONFIG_SYS_ENABLE_PADS_ALL /* Enable all PADS for now */ >> >> Not allowed. > Shall see to it. What if one needs to test pins and connections > during board bring-up, e.g. via gpio commands? Then code in what you need at the time, drop later. [snip] >> This is a little un-clear. If MMC will be in mmc like the uEVM, >> just do so, and if no storage of env, leave it as NOWHERE. > Cerrently looks like this: /* MMC ENV related defines */ #undef > CONFIG_ENV_IS_IN_MMC #undef CONFIG_SYS_MMC_ENV_DEV #undef > CONFIG_ENV_OFFSET #define CONFIG_ENV_IS_NOWHERE Shouldn't need that now, omap5_common is common and the env bits got moved to omap5_uevm.h [snip] >>> +/* + * memtest setup + */ +#define CONFIG_SYS_MEMTEST_START >>> 0xb8000000 +#define CONFIG_SYS_MEMTEST_END >>> (CONFIG_SYS_MEMTEST_START + (256 << 20)) +/* Undef following >>> two for simple mtest */ +#define CONFIG_SYS_ALT_MEMTEST >>> +#define CONFIG_SYS_MEMTEST_SCRATCH 0x81000000 >> >> Please see doc/README.memory-test and update as mtest is no >> longer a default command. > Now the config tail looks like this: > > /* Undef/remove after bring-up: */ #define CONFIG_CMD_MEMTEST > > /* Disabled commands */ #undef CONFIG_CMD_SAVEENV > > /* Prompt */ #define CONFIG_SYS_PROMPT "SOM5_EVB # " > > #ifdef CONFIG_CMD_MEMTEST /* Undef following two for simple mtest > */ #define CONFIG_SYS_ALT_MEMTEST #define > CONFIG_SYS_MEMTEST_SCRATCH 0xb7fffff0 #ifdef > CONFIG_SYS_ALT_MEMTEST #undef CONFIG_SYS_MEMTEST_START #define > CONFIG_SYS_MEMTEST_START 0xb8000000 #undef CONFIG_SYS_MEMTEST_END > #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + (256 << > 20)) #endif #endif /* CONFIG_CMD_MEMTEST */ OK. - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRkUEQAAoJENk4IS6UOR1WtscP/0RApAXEgttNem+eho1kFJMZ FSi3UgiO0+XqGbETTyYuG/r6RTz9grDcbtSs9np6/9H3wrc2FjCtlqXygJmQgbmr 2idPh4fyHerFvkZTZexJ3Lr+GC/1cJJyJliPvhj281OujbL/iDICkI/SLsnS3rtA hDC8MmrWWoDITtLzVNCbzkUk6gZVjFG/49dgjNMrRL9E8ctYp3NXtPK8VA4MpFnz WWM7qXQAHdBOuPRmixU4XuxHgG7/PAAzXH8Ac5dqFjnas+H8PEHqO90LPJm8tsFS 8dgb2ieQKlLl7yRLyRoQNvLy/B5EKUu+LKp6Yr3UI0oLm1iUnLdplEnKBbxpNHLS T+gQ7ScVCd/fFrx9oiF2tNurd6dhKTvAm8v7R9cfBAM/PjqZmoZGMAla8nvdw4XY g41Q1inBVn5w5/QbIzJCDZsWl9CHfoLMUHvGOKXV11NFbhjhY/9eDXwBzQmsKUXr 3dQYnzlCi3MxaZfsnDV9uKNSJ5sn84uBK4t9TanqGMsshen3CN5UU+bKPZKC3yty OQoxVTTAFnDlyJ+cQL77TmA/zkqDrL61qCrPBwZStX1f9lze1Ht7jcHwIthK3UzD wORqMKYFs/1DV5N7x7Un298qPGuCq9nPObl9JcCP5QWuhX6RTBn+g8ULYolQTSY0 xWeTauEupQWcZNDUldwK =D5d3 -----END PGP SIGNATURE-----
Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. Please see some more comments inline below. On 13/05/13 22:37, Tom Rini wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/26/2013 11:59 AM, Lubomir Popov wrote: >> Hi Tom, >> >> On 25/04/13 22:01, Tom Rini wrote: >>> On Mon, Apr 01, 2013 at 05:06:16PM +0300, Lubomir Popov wrote: >>> >>>> Signed-off-by: Lubomir Popov <lpopov@mm-sol.com> >>> >>> Thought I had reviewed this already, sorry. >> Thanks for your review. During the past month U-Boot has changed; I >> have tried to follow as well (although I'm engaged with other >> stuff) and some of your remarks have been already fixed. Please see >> my comments inline below. >> >> Anyway, I guess that a V2 patch shall have to be referenced against >> the current master. Or against u-boot-ti/next? > > OK, sorry for the late reply again. Now that u-boot-arm has resynced > with master, I've also resynced and gotten a pull done. You can use > either u-boot-arm/master or u-boot-ti/master. > >> >> Please note that for this board to work with the defined >> configuration, the following patches are also required >> (unfortunately some are already quite old and might cause >> conflicts): >> >> - Power: http://patchwork.ozlabs.org/patch/232732/. Potential >> conflict with Nishanth Menon's series of March 26, applied to >> u-boot-ti/next. - For I2C support: * The patch series of Apr. 8 >> that enables I2C4 and I2C5 (applied to u-boot-ti/next; affects all >> OMAP5 boards). * The modified i2c driver: >> http://patchwork.ozlabs.org/patch/233823/ (useful for all OMAP3/4/5 >> boards). - For USB support: * >> http://patchwork.ozlabs.org/patch/235684/ (affects all OMAP5 >> boards) * http://patchwork.ozlabs.org/patch/232742/ (affects all >> OMAP5 boards) > > OK. Please make sure these still apply and if not update and re-send. > I think I've already grabbed a few of these. > > [snip] >>>> +#define USB_HOST_HS_CLKCTRL_MASK 0x0100D7C0 /* >>>> CM_L3INIT_USB_HOST_HS_CLKCTRL */ +#define >>>> USB_TLL_HS_CLKCTRL_MASK 0x00000700 /* >>>> CM_L3INIT_USB_TLL_HS_CLKCTRL */ >>> >>> Some header please. >> Currently moved to board header. I wondered if a common OMAP header >> wouldn't be more suitable, but having in mind that the utilized USB >> ports (and thus the clocks that should be enabled) vary from board >> to board, perhaps this (i.e. board header) is the best place. > > The masks won't change tho, yes? Common header somewhere. These are in fact not masks, but enable bits (sort of confusing terminology found throughout TI headers). Now renamed to ..._CLKCTRL_EN; staying in board header. > >>> >>>> + * TODO: Replace this ugly hardcoding with proper defines + >>>> */ + writel(0x0100, 0x4ae0a310); >>> >>> Again, do please. >> This should be (*scrm)->auxclk0. The problem is that the >> omap5_scrm_regs struct (holding the auxclk0 member) has to be >> defined somewhere in the common OMAP5 headers. Sricharan? Or should >> I hack around? > > Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. > > [snip] >>> Ah, since you do have this part already, just update the rest as >>> I had said. >> /* Machine type for Linux */ #ifndef MACH_TYPE_SOM5_EVB #define >> MACH_TYPE_SOM5_EVB 4545 #endif #define CONFIG_MACH_TYPE >> MACH_TYPE_SOM5_EVB >> >> Is this OK? > > I think we'd decided in general to not do ifndef and just always > define it. > >>>> +/* Enable all clocks: */ +/*#define >>>> CONFIG_SYS_CLOCKS_ENABLE_ALL*/ + +#define >>>> CONFIG_SYS_ENABLE_PADS_ALL /* Enable all PADS for now */ >>> >>> Not allowed. >> Shall see to it. What if one needs to test pins and connections >> during board bring-up, e.g. via gpio commands? > > Then code in what you need at the time, drop later. > > [snip] >>> This is a little un-clear. If MMC will be in mmc like the uEVM, >>> just do so, and if no storage of env, leave it as NOWHERE. >> Cerrently looks like this: /* MMC ENV related defines */ #undef >> CONFIG_ENV_IS_IN_MMC #undef CONFIG_SYS_MMC_ENV_DEV #undef >> CONFIG_ENV_OFFSET #define CONFIG_ENV_IS_NOWHERE > > Shouldn't need that now, omap5_common is common and the env bits got > moved to omap5_uevm.h > > [snip] >>>> +/* + * memtest setup + */ +#define CONFIG_SYS_MEMTEST_START >>>> 0xb8000000 +#define CONFIG_SYS_MEMTEST_END >>>> (CONFIG_SYS_MEMTEST_START + (256 << 20)) +/* Undef following >>>> two for simple mtest */ +#define CONFIG_SYS_ALT_MEMTEST >>>> +#define CONFIG_SYS_MEMTEST_SCRATCH 0x81000000 >>> >>> Please see doc/README.memory-test and update as mtest is no >>> longer a default command. >> Now the config tail looks like this: >> >> /* Undef/remove after bring-up: */ #define CONFIG_CMD_MEMTEST >> >> /* Disabled commands */ #undef CONFIG_CMD_SAVEENV >> >> /* Prompt */ #define CONFIG_SYS_PROMPT "SOM5_EVB # " >> >> #ifdef CONFIG_CMD_MEMTEST /* Undef following two for simple mtest >> */ #define CONFIG_SYS_ALT_MEMTEST #define >> CONFIG_SYS_MEMTEST_SCRATCH 0xb7fffff0 #ifdef >> CONFIG_SYS_ALT_MEMTEST #undef CONFIG_SYS_MEMTEST_START #define >> CONFIG_SYS_MEMTEST_START 0xb8000000 #undef CONFIG_SYS_MEMTEST_END >> #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + (256 << >> 20)) #endif #endif /* CONFIG_CMD_MEMTEST */ > > OK. > > - -- > Tom > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRkUEQAAoJENk4IS6UOR1WtscP/0RApAXEgttNem+eho1kFJMZ > FSi3UgiO0+XqGbETTyYuG/r6RTz9grDcbtSs9np6/9H3wrc2FjCtlqXygJmQgbmr > 2idPh4fyHerFvkZTZexJ3Lr+GC/1cJJyJliPvhj281OujbL/iDICkI/SLsnS3rtA > hDC8MmrWWoDITtLzVNCbzkUk6gZVjFG/49dgjNMrRL9E8ctYp3NXtPK8VA4MpFnz > WWM7qXQAHdBOuPRmixU4XuxHgG7/PAAzXH8Ac5dqFjnas+H8PEHqO90LPJm8tsFS > 8dgb2ieQKlLl7yRLyRoQNvLy/B5EKUu+LKp6Yr3UI0oLm1iUnLdplEnKBbxpNHLS > T+gQ7ScVCd/fFrx9oiF2tNurd6dhKTvAm8v7R9cfBAM/PjqZmoZGMAla8nvdw4XY > g41Q1inBVn5w5/QbIzJCDZsWl9CHfoLMUHvGOKXV11NFbhjhY/9eDXwBzQmsKUXr > 3dQYnzlCi3MxaZfsnDV9uKNSJ5sn84uBK4t9TanqGMsshen3CN5UU+bKPZKC3yty > OQoxVTTAFnDlyJ+cQL77TmA/zkqDrL61qCrPBwZStX1f9lze1Ht7jcHwIthK3UzD > wORqMKYFs/1DV5N7x7Un298qPGuCq9nPObl9JcCP5QWuhX6RTBn+g8ULYolQTSY0 > xWeTauEupQWcZNDUldwK > =D5d3 > -----END PGP SIGNATURE----- > Best regards, Lubo
On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: > Hi Tom, > > I'm currently busy with other work; on the other hand, careful > rebasing shall require some time, especially the Palmas stuff. > What would be the deadline for a V2 submission? > > Meanwhile could you please have a look at the (already old) > http://patchwork.ozlabs.org/patch/232743/? A simple patch, > shall be needed if we enable USB (for the uEVM along with > our board). In general, what are your plans regarding USB > (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? > And again on I2C (.../patch/233823/): what is you final > opinion? I'm confident that this patch is a major improvement > for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. [snip] > >>>> + * TODO: Replace this ugly hardcoding with proper defines + > >>>> */ + writel(0x0100, 0x4ae0a310); > >>> > >>> Again, do please. > >> This should be (*scrm)->auxclk0. The problem is that the > >> omap5_scrm_regs struct (holding the auxclk0 member) has to be > >> defined somewhere in the common OMAP5 headers. Sricharan? Or should > >> I hack around? > > > > Add it to the most likely struct in the headers. > The entire struct (I call it omap5_scrm_regs in theory, similar to the > corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of > course I could define only the member that I need, but I guess it is > a (responsible) TI job to define hardware descriptors. Or I'm wrong? > Please advise. If I have time, I could do it myself - it's some 27 > registers, almost identical to the OMAP4, and should go into > arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to <asm/omap_common.h>. Thanks!
Hi Tom, On 14/05/13 17:52, Tom Rini wrote: > On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: >> Hi Tom, >> >> I'm currently busy with other work; on the other hand, careful >> rebasing shall require some time, especially the Palmas stuff. >> What would be the deadline for a V2 submission? >> >> Meanwhile could you please have a look at the (already old) >> http://patchwork.ozlabs.org/patch/232743/? A simple patch, >> shall be needed if we enable USB (for the uEVM along with >> our board). In general, what are your plans regarding USB >> (.../patch/232742/)? > > Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do > you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. > >> And again on I2C (.../patch/233823/): what is you final >> opinion? I'm confident that this patch is a major improvement >> for OMAP4/5 at least. > > I'm inclined to go with it, just need to mentally unswap the i2c notes > in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. > > [snip] >>>>>> + * TODO: Replace this ugly hardcoding with proper defines + >>>>>> */ + writel(0x0100, 0x4ae0a310); >>>>> >>>>> Again, do please. >>>> This should be (*scrm)->auxclk0. The problem is that the >>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be >>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should >>>> I hack around? >>> >>> Add it to the most likely struct in the headers. >> The entire struct (I call it omap5_scrm_regs in theory, similar to the >> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of >> course I could define only the member that I need, but I guess it is >> a (responsible) TI job to define hardware descriptors. Or I'm wrong? >> Please advise. If I have time, I could do it myself - it's some 27 >> registers, almost identical to the OMAP4, and should go into >> arch/arm/include/asm/arch-omap5/clocks.h. > > Whomever uses / needs it should do it. I gave the TRM a quick read and > I don't see any conflicts per-se just some reserved areas being named > and vice versa. So rename it to omap_scrm_regs and move to > <asm/omap_common.h>. Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Otherwise (a struct in omap_common.h) we shall need new scrm-regs.c files for every OMAP flavor. Which way to go? Regards, Lubo
On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: > Hi Tom, > > On 14/05/13 17:52, Tom Rini wrote: > > On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: > >> Hi Tom, > >> > >> I'm currently busy with other work; on the other hand, careful > >> rebasing shall require some time, especially the Palmas stuff. > >> What would be the deadline for a V2 submission? > >> > >> Meanwhile could you please have a look at the (already old) > >> http://patchwork.ozlabs.org/patch/232743/? A simple patch, > >> shall be needed if we enable USB (for the uEVM along with > >> our board). In general, what are your plans regarding USB > >> (.../patch/232742/)? > > > > Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do > > you have a patch around for uEVM still? > Not yet (didn't have the opportunity to test, although some uEVMs should > be around at MMS). As you know, a patch shall be needed in the uEVM board > file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. > >> And again on I2C (.../patch/233823/): what is you final > >> opinion? I'm confident that this patch is a major improvement > >> for OMAP4/5 at least. > > > > I'm inclined to go with it, just need to mentally unswap the i2c notes > > in my brain and think it over one more time. > Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. > > [snip] > >>>>>> + * TODO: Replace this ugly hardcoding with proper defines + > >>>>>> */ + writel(0x0100, 0x4ae0a310); > >>>>> > >>>>> Again, do please. > >>>> This should be (*scrm)->auxclk0. The problem is that the > >>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be > >>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should > >>>> I hack around? > >>> > >>> Add it to the most likely struct in the headers. > >> The entire struct (I call it omap5_scrm_regs in theory, similar to the > >> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of > >> course I could define only the member that I need, but I guess it is > >> a (responsible) TI job to define hardware descriptors. Or I'm wrong? > >> Please advise. If I have time, I could do it myself - it's some 27 > >> registers, almost identical to the OMAP4, and should go into > >> arch/arm/include/asm/arch-omap5/clocks.h. > > > > Whomever uses / needs it should do it. I gave the TRM a quick read and > > I don't see any conflicts per-se just some reserved areas being named > > and vice versa. So rename it to omap_scrm_regs and move to > > <asm/omap_common.h>. Thanks! > I would argue that this is not very appropriate. Those regs that are > reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; > on the other hand the OMAP5 has some modem clock regs that are reserved > on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 > and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. > Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h > file and I have already done the same for OMAP5 by analogy. I must admit > however that this approach does not correspond to the latest way by which > groups of OMAP hardware regs are defined, prcm in particular - a struct in > omap_common.h, holding only the required regs, no padding and such garbage, > and an init with the physical addresses in a .c file for the particular SoC > (prcm-regs.c). But still the Panda board, for example, uses the old way for > scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and > lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c.
Hi Tom, Just a couple of things to clarify below. > On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: >> Hi Tom, >> >> On 14/05/13 17:52, Tom Rini wrote: >> > On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: >> >> Hi Tom, >> >> >> >> I'm currently busy with other work; on the other hand, careful >> >> rebasing shall require some time, especially the Palmas stuff. >> >> What would be the deadline for a V2 submission? >> >> >> >> Meanwhile could you please have a look at the (already old) >> >> http://patchwork.ozlabs.org/patch/232743/? A simple patch, >> >> shall be needed if we enable USB (for the uEVM along with >> >> our board). In general, what are your plans regarding USB >> >> (.../patch/232742/)? >> > >> > Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but >> do >> > you have a patch around for uEVM still? >> Not yet (didn't have the opportunity to test, although some uEVMs should >> be around at MMS). As you know, a patch shall be needed in the uEVM >> board >> file along with the common USB stuff. > > Yeah, I can test it as well if you write it up, and may find the time if > you point me in the right direction. OK, shall do it. > >> >> And again on I2C (.../patch/233823/): what is you final >> >> opinion? I'm confident that this patch is a major improvement >> >> for OMAP4/5 at least. >> > >> > I'm inclined to go with it, just need to mentally unswap the i2c notes >> > in my brain and think it over one more time. >> Just applied 233823 to current u-boot-ti master. Works fine. > > OK, thanks. Just to avoid confusion: I applied it and tested on a locally cloned version of u-boot-ti, not upstream (don't laugh please; just want to clarify for those who don't know that it is your job). > >> > [snip] >> Currently the scrm struct is defined for OMAP4 in the >> asm/arch-omap4/clocks.h >> file and I have already done the same for OMAP5 by analogy. I must admit >> however that this approach does not correspond to the latest way by >> which >> groups of OMAP hardware regs are defined, prcm in particular - a struct >> in >> omap_common.h, holding only the required regs, no padding and such >> garbage, >> and an init with the physical addresses in a .c file for the particular >> SoC >> (prcm-regs.c). But still the Panda board, for example, uses the old way >> for >> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old >> and >> lazy ;) ). > > Yes, I'm OK starting off with moving things into omap_common.h as-is and > then updating them a bit later ala pcrm-regs.c. Who is starting off, me or you? ;) > > -- > Tom > BR, Lubo
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/14/2013 03:42 PM, Lubomir Popov wrote: > Hi Tom, > > Just a couple of things to clarify below. > >> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: >>> Hi Tom, >>> >>> On 14/05/13 17:52, Tom Rini wrote: >>>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov >>>> wrote: >>>>> Hi Tom, >>>>> >>>>> I'm currently busy with other work; on the other hand, >>>>> careful rebasing shall require some time, especially the >>>>> Palmas stuff. What would be the deadline for a V2 >>>>> submission? >>>>> >>>>> Meanwhile could you please have a look at the (already old) >>>>> http://patchwork.ozlabs.org/patch/232743/? A simple patch, >>>>> shall be needed if we enable USB (for the uEVM along with >>>>> our board). In general, what are your plans regarding USB >>>>> (.../patch/232742/)? >>>> >>>> Thanks for the reminder, I'll grab 232743 soon. 232742 >>>> looks OK, but >>> do >>>> you have a patch around for uEVM still? >>> Not yet (didn't have the opportunity to test, although some >>> uEVMs should be around at MMS). As you know, a patch shall be >>> needed in the uEVM board file along with the common USB stuff. >> >> Yeah, I can test it as well if you write it up, and may find the >> time if you point me in the right direction. > OK, shall do it. Thanks! [snip] >>>> [snip] >>> Currently the scrm struct is defined for OMAP4 in the >>> asm/arch-omap4/clocks.h file and I have already done the same >>> for OMAP5 by analogy. I must admit however that this approach >>> does not correspond to the latest way by which groups of OMAP >>> hardware regs are defined, prcm in particular - a struct in >>> omap_common.h, holding only the required regs, no padding and >>> such garbage, and an init with the physical addresses in a .c >>> file for the particular SoC (prcm-regs.c). But still the Panda >>> board, for example, uses the old way for scrm. Therefore I did >>> it the same for OMAP5, which was easier (I'm old and lazy ;) >>> ). >> >> Yes, I'm OK starting off with moving things into omap_common.h >> as-is and then updating them a bit later ala pcrm-regs.c. > Who is starting off, me or you? ;) Since your series needs it (so we aren't writing to magic locations which isn't allowed), you please. Thanks! - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRkqBgAAoJENk4IS6UOR1WFVcQAIo9DgrABUaAwOTfYFXVlGQ6 /MFyQvtwFYtEwW1xtDZ8RWuv1zGI26IIw4XH+xhspj50w7ma9lji575U/tyQCtrN G6xMW8bH/8Cxj+kFUcgeNXSqAF0OLOz8Rvow9dSW2RpnOu3yOPKnvgxjV974x595 IfBK26Xo5ldR6qX12EIwAfHZVRow97Kk25LOBoqR+qxTBrtKPWzywXyvTi94qY/b jcy9L17AQQvNWQofps7noDsFM+acWlQxsTkjbdkynDu8gIQC0JZ8cEUPZ9XsYg+D 8SvXeY5ntCEOwxvB2TZ2GNC9/J5fVXMmewrexH1AdjsO1d0529ZjCX0995whV2pJ xCYi0FAtXKW0fm1gitMXZ0J/pHzNdsr1s+rV0iUtppbhh9mQ+NQplXVPevB0UrWH 1UHHxe1Hsc5ZJHJRvvFyVAo9ySdZ85zrS6+TlMwfjK1LWtQmPJ0DA1Cddz8m/BI+ 6ebQ36qgJuO990YhQ9GlfOV1rjp3RhrCmb+JKwjMN0OahnfAEvp4osCvbMClDXqT VL83+gP1lKJ47B2VfuyqXW+ETBV6hhLprItj8wx+0sJx0rNKc98Q61pO8XSPZwoE 8hWzqeY7Dmlp2QxQ3ZyD5w5+DECGbj7ihCICkjquwHSB5v1R4R1XIwlV/3cd/Mm4 SMnFtv8rUQsfzi48bGt4 =lJAv -----END PGP SIGNATURE-----
Hi, On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: > On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: >> Hi Tom, >> >> On 14/05/13 17:52, Tom Rini wrote: >>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: >>>> Hi Tom, >>>> >>>> I'm currently busy with other work; on the other hand, careful >>>> rebasing shall require some time, especially the Palmas stuff. >>>> What would be the deadline for a V2 submission? >>>> >>>> Meanwhile could you please have a look at the (already old) >>>> http://patchwork.ozlabs.org/patch/232743/? A simple patch, >>>> shall be needed if we enable USB (for the uEVM along with >>>> our board). In general, what are your plans regarding USB >>>> (.../patch/232742/)? >>> Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do >>> you have a patch around for uEVM still? >> Not yet (didn't have the opportunity to test, although some uEVMs should >> be around at MMS). As you know, a patch shall be needed in the uEVM board >> file along with the common USB stuff. > Yeah, I can test it as well if you write it up, and may find the time if > you point me in the right direction. > >>>> And again on I2C (.../patch/233823/): what is you final >>>> opinion? I'm confident that this patch is a major improvement >>>> for OMAP4/5 at least. >>> I'm inclined to go with it, just need to mentally unswap the i2c notes >>> in my brain and think it over one more time. >> Just applied 233823 to current u-boot-ti master. Works fine. > OK, thanks. > >>> [snip] >>>>>>>> + * TODO: Replace this ugly hardcoding with proper defines + >>>>>>>> */ + writel(0x0100, 0x4ae0a310); >>>>>>> Again, do please. >>>>>> This should be (*scrm)->auxclk0. The problem is that the >>>>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be >>>>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should >>>>>> I hack around? >>>>> Add it to the most likely struct in the headers. >>>> The entire struct (I call it omap5_scrm_regs in theory, similar to the >>>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of >>>> course I could define only the member that I need, but I guess it is >>>> a (responsible) TI job to define hardware descriptors. Or I'm wrong? >>>> Please advise. If I have time, I could do it myself - it's some 27 >>>> registers, almost identical to the OMAP4, and should go into >>>> arch/arm/include/asm/arch-omap5/clocks.h. >>> Whomever uses / needs it should do it. I gave the TRM a quick read and >>> I don't see any conflicts per-se just some reserved areas being named >>> and vice versa. So rename it to omap_scrm_regs and move to >>> <asm/omap_common.h>. Thanks! >> I would argue that this is not very appropriate. Those regs that are >> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; >> on the other hand the OMAP5 has some modem clock regs that are reserved >> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 >> and below? > We don't need to use ifdefs since there's no conflicts, things are > either reserved in one case and used in the other. And we can make sure > we don't try and use the omap5 bits on omap4 and vice versa. I don't > see scrm in the first omap3 TRM I pulled up, so we don't need to worry > there. > >> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h >> file and I have already done the same for OMAP5 by analogy. I must admit >> however that this approach does not correspond to the latest way by which >> groups of OMAP hardware regs are defined, prcm in particular - a struct in >> omap_common.h, holding only the required regs, no padding and such garbage, >> and an init with the physical addresses in a .c file for the particular SoC >> (prcm-regs.c). But still the Panda board, for example, uses the old way for >> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and >> lazy ;) ). > Yes, I'm OK starting off with moving things into omap_common.h as-is and > then updating them a bit later ala pcrm-regs.c. > > I am sorry for the very late response on this. Now then, why not add this register in to omap5_es2_prcm ??. That is how the TRM sees it as well.. Of course, this is cleanup stuff for OMAP4 panda as you pointed out.. Regards, Sricharan > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
Hi Sricharan, On 15/05/13 08:11, Sricharan R wrote: > Hi, > On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: >> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: >>> Hi Tom, >>> >>> On 14/05/13 17:52, Tom Rini wrote: >>>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: >>>>> Hi Tom, >>>>> >>>>> I'm currently busy with other work; on the other hand, careful >>>>> rebasing shall require some time, especially the Palmas stuff. >>>>> What would be the deadline for a V2 submission? >>>>> >>>>> Meanwhile could you please have a look at the (already old) >>>>> http://patchwork.ozlabs.org/patch/232743/? A simple patch, >>>>> shall be needed if we enable USB (for the uEVM along with >>>>> our board). In general, what are your plans regarding USB >>>>> (.../patch/232742/)? >>>> Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do >>>> you have a patch around for uEVM still? >>> Not yet (didn't have the opportunity to test, although some uEVMs should >>> be around at MMS). As you know, a patch shall be needed in the uEVM board >>> file along with the common USB stuff. >> Yeah, I can test it as well if you write it up, and may find the time if >> you point me in the right direction. >> >>>>> And again on I2C (.../patch/233823/): what is you final >>>>> opinion? I'm confident that this patch is a major improvement >>>>> for OMAP4/5 at least. >>>> I'm inclined to go with it, just need to mentally unswap the i2c notes >>>> in my brain and think it over one more time. >>> Just applied 233823 to current u-boot-ti master. Works fine. >> OK, thanks. >> >>>> [snip] >>>>>>>>> + * TODO: Replace this ugly hardcoding with proper defines + >>>>>>>>> */ + writel(0x0100, 0x4ae0a310); >>>>>>>> Again, do please. >>>>>>> This should be (*scrm)->auxclk0. The problem is that the >>>>>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be >>>>>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should >>>>>>> I hack around? >>>>>> Add it to the most likely struct in the headers. >>>>> The entire struct (I call it omap5_scrm_regs in theory, similar to the >>>>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of >>>>> course I could define only the member that I need, but I guess it is >>>>> a (responsible) TI job to define hardware descriptors. Or I'm wrong? >>>>> Please advise. If I have time, I could do it myself - it's some 27 >>>>> registers, almost identical to the OMAP4, and should go into >>>>> arch/arm/include/asm/arch-omap5/clocks.h. >>>> Whomever uses / needs it should do it. I gave the TRM a quick read and >>>> I don't see any conflicts per-se just some reserved areas being named >>>> and vice versa. So rename it to omap_scrm_regs and move to >>>> <asm/omap_common.h>. Thanks! >>> I would argue that this is not very appropriate. Those regs that are >>> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; >>> on the other hand the OMAP5 has some modem clock regs that are reserved >>> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 >>> and below? >> We don't need to use ifdefs since there's no conflicts, things are >> either reserved in one case and used in the other. And we can make sure >> we don't try and use the omap5 bits on omap4 and vice versa. I don't >> see scrm in the first omap3 TRM I pulled up, so we don't need to worry >> there. >> >>> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h >>> file and I have already done the same for OMAP5 by analogy. I must admit >>> however that this approach does not correspond to the latest way by which >>> groups of OMAP hardware regs are defined, prcm in particular - a struct in >>> omap_common.h, holding only the required regs, no padding and such garbage, >>> and an init with the physical addresses in a .c file for the particular SoC >>> (prcm-regs.c). But still the Panda board, for example, uses the old way for >>> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and >>> lazy ;) ). >> Yes, I'm OK starting off with moving things into omap_common.h as-is and >> then updating them a bit later ala pcrm-regs.c. >> >> > I am sorry for the very late response on this. > Now then, why not add this register in to omap5_es2_prcm > ??. That is how the TRM sees it as well.. Of course, this is cleanup > stuff for OMAP4 panda as you pointed out.. Yes, you are right in respect to fluent software integration and consistency with current implementation. My only concern is that from architectural point of view the SCRM, although related to the PRCM, is a separate module (described correspondingly as such in the TRM). If we go this way, the SCRM regs shall have to be referenced via the prcm pointer: (*prcm)->xxxxx, and this might be confusing. I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) to the prcm_regs declaration in omap_common.h, and the required init to the appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h, start with a scrm_ prefix. Alternatively, a new scrm_regs struct could be declared in omap_common.h, along with the appropriate pointers, and the corresponding definitions/inits added as new structs in prcm-regs.c for every SoC. But then the file name prcm-regs shall be a bit confusing. What do you say? > > Regards, > Sricharan > > >> >> _______________________________________________ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot > Best regards, Lubo
Hi, On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote: > Hi Sricharan, > > On 15/05/13 08:11, Sricharan R wrote: >> Hi, >> On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: >>> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: >>>> Hi Tom, >>>> >>>> On 14/05/13 17:52, Tom Rini wrote: >>>>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: >>>>>> Hi Tom, >>>>>> >>>>>> I'm currently busy with other work; on the other hand, careful >>>>>> rebasing shall require some time, especially the Palmas stuff. >>>>>> What would be the deadline for a V2 submission? >>>>>> >>>>>> Meanwhile could you please have a look at the (already old) >>>>>> http://patchwork.ozlabs.org/patch/232743/? A simple patch, >>>>>> shall be needed if we enable USB (for the uEVM along with >>>>>> our board). In general, what are your plans regarding USB >>>>>> (.../patch/232742/)? >>>>> Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do >>>>> you have a patch around for uEVM still? >>>> Not yet (didn't have the opportunity to test, although some uEVMs should >>>> be around at MMS). As you know, a patch shall be needed in the uEVM board >>>> file along with the common USB stuff. >>> Yeah, I can test it as well if you write it up, and may find the time if >>> you point me in the right direction. >>> >>>>>> And again on I2C (.../patch/233823/): what is you final >>>>>> opinion? I'm confident that this patch is a major improvement >>>>>> for OMAP4/5 at least. >>>>> I'm inclined to go with it, just need to mentally unswap the i2c notes >>>>> in my brain and think it over one more time. >>>> Just applied 233823 to current u-boot-ti master. Works fine. >>> OK, thanks. >>> >>>>> [snip] >>>>>>>>>> + * TODO: Replace this ugly hardcoding with proper defines + >>>>>>>>>> */ + writel(0x0100, 0x4ae0a310); >>>>>>>>> Again, do please. >>>>>>>> This should be (*scrm)->auxclk0. The problem is that the >>>>>>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be >>>>>>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should >>>>>>>> I hack around? >>>>>>> Add it to the most likely struct in the headers. >>>>>> The entire struct (I call it omap5_scrm_regs in theory, similar to the >>>>>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of >>>>>> course I could define only the member that I need, but I guess it is >>>>>> a (responsible) TI job to define hardware descriptors. Or I'm wrong? >>>>>> Please advise. If I have time, I could do it myself - it's some 27 >>>>>> registers, almost identical to the OMAP4, and should go into >>>>>> arch/arm/include/asm/arch-omap5/clocks.h. >>>>> Whomever uses / needs it should do it. I gave the TRM a quick read and >>>>> I don't see any conflicts per-se just some reserved areas being named >>>>> and vice versa. So rename it to omap_scrm_regs and move to >>>>> <asm/omap_common.h>. Thanks! >>>> I would argue that this is not very appropriate. Those regs that are >>>> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; >>>> on the other hand the OMAP5 has some modem clock regs that are reserved >>>> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 >>>> and below? >>> We don't need to use ifdefs since there's no conflicts, things are >>> either reserved in one case and used in the other. And we can make sure >>> we don't try and use the omap5 bits on omap4 and vice versa. I don't >>> see scrm in the first omap3 TRM I pulled up, so we don't need to worry >>> there. >>> >>>> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h >>>> file and I have already done the same for OMAP5 by analogy. I must admit >>>> however that this approach does not correspond to the latest way by which >>>> groups of OMAP hardware regs are defined, prcm in particular - a struct in >>>> omap_common.h, holding only the required regs, no padding and such garbage, >>>> and an init with the physical addresses in a .c file for the particular SoC >>>> (prcm-regs.c). But still the Panda board, for example, uses the old way for >>>> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and >>>> lazy ;) ). >>> Yes, I'm OK starting off with moving things into omap_common.h as-is and >>> then updating them a bit later ala pcrm-regs.c. >>> >>> >> I am sorry for the very late response on this. >> Now then, why not add this register in to omap5_es2_prcm >> ??. That is how the TRM sees it as well.. Of course, this is cleanup >> stuff for OMAP4 panda as you pointed out.. > Yes, you are right in respect to fluent software integration and consistency > with current implementation. My only concern is that from architectural point > of view the SCRM, although related to the PRCM, is a separate module (described > correspondingly as such in the TRM). If we go this way, the SCRM regs shall > have to be referenced via the prcm pointer: (*prcm)->xxxxx, and this might be > confusing. > > I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) > to the prcm_regs declaration in omap_common.h, and the required init to the > appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved > clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h, > start with a scrm_ prefix. > > Alternatively, a new scrm_regs struct could be declared in omap_common.h, along > with the appropriate pointers, and the corresponding definitions/inits added as > new structs in prcm-regs.c for every SoC. But then the file name prcm-regs shall > be a bit confusing. > > What do you say? At this point , i think just adding only the registers that you need in to the prcm structure should be ok. Regards, Sricharan
Hi Sricharan, On 15/05/13 12:04, Sricharan R wrote: > Hi, > > On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote: >> Hi Sricharan, >> >> On 15/05/13 08:11, Sricharan R wrote: >>> Hi, >>> On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: >>>> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: >>>>> Hi Tom, >>>>> >>>>> On 14/05/13 17:52, Tom Rini wrote: >>>>>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: >>>>>>> Hi Tom, >>>>>>> >>>>>>> I'm currently busy with other work; on the other hand, careful >>>>>>> rebasing shall require some time, especially the Palmas stuff. >>>>>>> What would be the deadline for a V2 submission? >>>>>>> >>>>>>> Meanwhile could you please have a look at the (already old) >>>>>>> http://patchwork.ozlabs.org/patch/232743/? A simple patch, >>>>>>> shall be needed if we enable USB (for the uEVM along with >>>>>>> our board). In general, what are your plans regarding USB >>>>>>> (.../patch/232742/)? >>>>>> Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do >>>>>> you have a patch around for uEVM still? >>>>> Not yet (didn't have the opportunity to test, although some uEVMs should >>>>> be around at MMS). As you know, a patch shall be needed in the uEVM board >>>>> file along with the common USB stuff. >>>> Yeah, I can test it as well if you write it up, and may find the time if >>>> you point me in the right direction. >>>> >>>>>>> And again on I2C (.../patch/233823/): what is you final >>>>>>> opinion? I'm confident that this patch is a major improvement >>>>>>> for OMAP4/5 at least. >>>>>> I'm inclined to go with it, just need to mentally unswap the i2c notes >>>>>> in my brain and think it over one more time. >>>>> Just applied 233823 to current u-boot-ti master. Works fine. >>>> OK, thanks. >>>> >>>>>> [snip] >>>>>>>>>>> + * TODO: Replace this ugly hardcoding with proper defines + >>>>>>>>>>> */ + writel(0x0100, 0x4ae0a310); >>>>>>>>>> Again, do please. >>>>>>>>> This should be (*scrm)->auxclk0. The problem is that the >>>>>>>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be >>>>>>>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should >>>>>>>>> I hack around? >>>>>>>> Add it to the most likely struct in the headers. >>>>>>> The entire struct (I call it omap5_scrm_regs in theory, similar to the >>>>>>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of >>>>>>> course I could define only the member that I need, but I guess it is >>>>>>> a (responsible) TI job to define hardware descriptors. Or I'm wrong? >>>>>>> Please advise. If I have time, I could do it myself - it's some 27 >>>>>>> registers, almost identical to the OMAP4, and should go into >>>>>>> arch/arm/include/asm/arch-omap5/clocks.h. >>>>>> Whomever uses / needs it should do it. I gave the TRM a quick read and >>>>>> I don't see any conflicts per-se just some reserved areas being named >>>>>> and vice versa. So rename it to omap_scrm_regs and move to >>>>>> <asm/omap_common.h>. Thanks! >>>>> I would argue that this is not very appropriate. Those regs that are >>>>> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; >>>>> on the other hand the OMAP5 has some modem clock regs that are reserved >>>>> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 >>>>> and below? >>>> We don't need to use ifdefs since there's no conflicts, things are >>>> either reserved in one case and used in the other. And we can make sure >>>> we don't try and use the omap5 bits on omap4 and vice versa. I don't >>>> see scrm in the first omap3 TRM I pulled up, so we don't need to worry >>>> there. >>>> >>>>> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h >>>>> file and I have already done the same for OMAP5 by analogy. I must admit >>>>> however that this approach does not correspond to the latest way by which >>>>> groups of OMAP hardware regs are defined, prcm in particular - a struct in >>>>> omap_common.h, holding only the required regs, no padding and such garbage, >>>>> and an init with the physical addresses in a .c file for the particular SoC >>>>> (prcm-regs.c). But still the Panda board, for example, uses the old way for >>>>> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and >>>>> lazy ;) ). >>>> Yes, I'm OK starting off with moving things into omap_common.h as-is and >>>> then updating them a bit later ala pcrm-regs.c. >>>> >>>> >>> I am sorry for the very late response on this. >>> Now then, why not add this register in to omap5_es2_prcm >>> ??. That is how the TRM sees it as well.. Of course, this is cleanup >>> stuff for OMAP4 panda as you pointed out.. >> Yes, you are right in respect to fluent software integration and consistency >> with current implementation. My only concern is that from architectural point >> of view the SCRM, although related to the PRCM, is a separate module (described >> correspondingly as such in the TRM). If we go this way, the SCRM regs shall >> have to be referenced via the prcm pointer: (*prcm)->xxxxx, and this might be >> confusing. >> >> I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) >> to the prcm_regs declaration in omap_common.h, and the required init to the >> appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved >> clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h, >> start with a scrm_ prefix. >> >> Alternatively, a new scrm_regs struct could be declared in omap_common.h, along >> with the appropriate pointers, and the corresponding definitions/inits added as >> new structs in prcm-regs.c for every SoC. But then the file name prcm-regs shall >> be a bit confusing. >> >> What do you say? > At this point , i think just adding only the registers that you need in to the > prcm structure should be ok. OK, I just tend to add all registers, it shall be easier for later rework. > > Regards, > Sricharan > BR, Lubo
On Wednesday 15 May 2013 04:16 PM, Lubomir Popov wrote: > Hi Sricharan, > > On 15/05/13 12:04, Sricharan R wrote: >> Hi, >> >> On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote: >>> Hi Sricharan, >>> >>> On 15/05/13 08:11, Sricharan R wrote: >>>> Hi, >>>> On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: >>>>> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: >>>>>> Hi Tom, >>>>>> >>>>>> On 14/05/13 17:52, Tom Rini wrote: >>>>>>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: >>>>>>>> Hi Tom, >>>>>>>> >>>>>>>> I'm currently busy with other work; on the other hand, careful >>>>>>>> rebasing shall require some time, especially the Palmas stuff. >>>>>>>> What would be the deadline for a V2 submission? >>>>>>>> >>>>>>>> Meanwhile could you please have a look at the (already old) >>>>>>>> http://patchwork.ozlabs.org/patch/232743/? A simple patch, >>>>>>>> shall be needed if we enable USB (for the uEVM along with >>>>>>>> our board). In general, what are your plans regarding USB >>>>>>>> (.../patch/232742/)? >>>>>>> Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do >>>>>>> you have a patch around for uEVM still? >>>>>> Not yet (didn't have the opportunity to test, although some uEVMs should >>>>>> be around at MMS). As you know, a patch shall be needed in the uEVM board >>>>>> file along with the common USB stuff. >>>>> Yeah, I can test it as well if you write it up, and may find the time if >>>>> you point me in the right direction. >>>>> >>>>>>>> And again on I2C (.../patch/233823/): what is you final >>>>>>>> opinion? I'm confident that this patch is a major improvement >>>>>>>> for OMAP4/5 at least. >>>>>>> I'm inclined to go with it, just need to mentally unswap the i2c notes >>>>>>> in my brain and think it over one more time. >>>>>> Just applied 233823 to current u-boot-ti master. Works fine. >>>>> OK, thanks. >>>>> >>>>>>> [snip] >>>>>>>>>>>> + * TODO: Replace this ugly hardcoding with proper defines + >>>>>>>>>>>> */ + writel(0x0100, 0x4ae0a310); >>>>>>>>>>> Again, do please. >>>>>>>>>> This should be (*scrm)->auxclk0. The problem is that the >>>>>>>>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be >>>>>>>>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should >>>>>>>>>> I hack around? >>>>>>>>> Add it to the most likely struct in the headers. >>>>>>>> The entire struct (I call it omap5_scrm_regs in theory, similar to the >>>>>>>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of >>>>>>>> course I could define only the member that I need, but I guess it is >>>>>>>> a (responsible) TI job to define hardware descriptors. Or I'm wrong? >>>>>>>> Please advise. If I have time, I could do it myself - it's some 27 >>>>>>>> registers, almost identical to the OMAP4, and should go into >>>>>>>> arch/arm/include/asm/arch-omap5/clocks.h. >>>>>>> Whomever uses / needs it should do it. I gave the TRM a quick read and >>>>>>> I don't see any conflicts per-se just some reserved areas being named >>>>>>> and vice versa. So rename it to omap_scrm_regs and move to >>>>>>> <asm/omap_common.h>. Thanks! >>>>>> I would argue that this is not very appropriate. Those regs that are >>>>>> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; >>>>>> on the other hand the OMAP5 has some modem clock regs that are reserved >>>>>> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 >>>>>> and below? >>>>> We don't need to use ifdefs since there's no conflicts, things are >>>>> either reserved in one case and used in the other. And we can make sure >>>>> we don't try and use the omap5 bits on omap4 and vice versa. I don't >>>>> see scrm in the first omap3 TRM I pulled up, so we don't need to worry >>>>> there. >>>>> >>>>>> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h >>>>>> file and I have already done the same for OMAP5 by analogy. I must admit >>>>>> however that this approach does not correspond to the latest way by which >>>>>> groups of OMAP hardware regs are defined, prcm in particular - a struct in >>>>>> omap_common.h, holding only the required regs, no padding and such garbage, >>>>>> and an init with the physical addresses in a .c file for the particular SoC >>>>>> (prcm-regs.c). But still the Panda board, for example, uses the old way for >>>>>> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and >>>>>> lazy ;) ). >>>>> Yes, I'm OK starting off with moving things into omap_common.h as-is and >>>>> then updating them a bit later ala pcrm-regs.c. >>>>> >>>>> >>>> I am sorry for the very late response on this. >>>> Now then, why not add this register in to omap5_es2_prcm >>>> ??. That is how the TRM sees it as well.. Of course, this is cleanup >>>> stuff for OMAP4 panda as you pointed out.. >>> Yes, you are right in respect to fluent software integration and consistency >>> with current implementation. My only concern is that from architectural point >>> of view the SCRM, although related to the PRCM, is a separate module (described >>> correspondingly as such in the TRM). If we go this way, the SCRM regs shall >>> have to be referenced via the prcm pointer: (*prcm)->xxxxx, and this might be >>> confusing. >>> >>> I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) >>> to the prcm_regs declaration in omap_common.h, and the required init to the >>> appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved >>> clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h, >>> start with a scrm_ prefix. >>> >>> Alternatively, a new scrm_regs struct could be declared in omap_common.h, along >>> with the appropriate pointers, and the corresponding definitions/inits added as >>> new structs in prcm-regs.c for every SoC. But then the file name prcm-regs shall >>> be a bit confusing. >>> >>> What do you say? >> At this point , i think just adding only the registers that you need in to the >> prcm structure should be ok. > OK, I just tend to add all registers, it shall be easier for later rework. Actually no :). When were are not using them no good in adding. Especially those SCRM registers very less we will use all of them in bootloader. Regards, Sricharan
Hi Sricharan, Tom, On 15/05/13 14:25, Sricharan R wrote: > On Wednesday 15 May 2013 04:16 PM, Lubomir Popov wrote: >> Hi Sricharan, >> >> On 15/05/13 12:04, Sricharan R wrote: >>> Hi, >>> >>> On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote: >>>> Hi Sricharan, >>>> >>>> On 15/05/13 08:11, Sricharan R wrote: >>>>> Hi, >>>>> On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: >>>>>> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: >>>>>>> Hi Tom, >>>>>>> >>>>>>> On 14/05/13 17:52, Tom Rini wrote: >>>>>>>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: >>>>>>>>> Hi Tom, >>>>>>>>> >>>>>>>>> I'm currently busy with other work; on the other hand, careful >>>>>>>>> rebasing shall require some time, especially the Palmas stuff. >>>>>>>>> What would be the deadline for a V2 submission? >>>>>>>>> >>>>>>>>> Meanwhile could you please have a look at the (already old) >>>>>>>>> http://patchwork.ozlabs.org/patch/232743/? A simple patch, >>>>>>>>> shall be needed if we enable USB (for the uEVM along with >>>>>>>>> our board). In general, what are your plans regarding USB >>>>>>>>> (.../patch/232742/)? >>>>>>>> Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do >>>>>>>> you have a patch around for uEVM still? >>>>>>> Not yet (didn't have the opportunity to test, although some uEVMs should >>>>>>> be around at MMS). As you know, a patch shall be needed in the uEVM board >>>>>>> file along with the common USB stuff. >>>>>> Yeah, I can test it as well if you write it up, and may find the time if >>>>>> you point me in the right direction. >>>>>> >>>>>>>>> And again on I2C (.../patch/233823/): what is you final >>>>>>>>> opinion? I'm confident that this patch is a major improvement >>>>>>>>> for OMAP4/5 at least. >>>>>>>> I'm inclined to go with it, just need to mentally unswap the i2c notes >>>>>>>> in my brain and think it over one more time. >>>>>>> Just applied 233823 to current u-boot-ti master. Works fine. >>>>>> OK, thanks. >>>>>> >>>>>>>> [snip] >>>>>>>>>>>>> + * TODO: Replace this ugly hardcoding with proper defines + >>>>>>>>>>>>> */ + writel(0x0100, 0x4ae0a310); >>>>>>>>>>>> Again, do please. >>>>>>>>>>> This should be (*scrm)->auxclk0. The problem is that the >>>>>>>>>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be >>>>>>>>>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should >>>>>>>>>>> I hack around? >>>>>>>>>> Add it to the most likely struct in the headers. >>>>>>>>> The entire struct (I call it omap5_scrm_regs in theory, similar to the >>>>>>>>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of >>>>>>>>> course I could define only the member that I need, but I guess it is >>>>>>>>> a (responsible) TI job to define hardware descriptors. Or I'm wrong? >>>>>>>>> Please advise. If I have time, I could do it myself - it's some 27 >>>>>>>>> registers, almost identical to the OMAP4, and should go into >>>>>>>>> arch/arm/include/asm/arch-omap5/clocks.h. >>>>>>>> Whomever uses / needs it should do it. I gave the TRM a quick read and >>>>>>>> I don't see any conflicts per-se just some reserved areas being named >>>>>>>> and vice versa. So rename it to omap_scrm_regs and move to >>>>>>>> <asm/omap_common.h>. Thanks! >>>>>>> I would argue that this is not very appropriate. Those regs that are >>>>>>> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; >>>>>>> on the other hand the OMAP5 has some modem clock regs that are reserved >>>>>>> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 >>>>>>> and below? >>>>>> We don't need to use ifdefs since there's no conflicts, things are >>>>>> either reserved in one case and used in the other. And we can make sure >>>>>> we don't try and use the omap5 bits on omap4 and vice versa. I don't >>>>>> see scrm in the first omap3 TRM I pulled up, so we don't need to worry >>>>>> there. >>>>>> >>>>>>> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h >>>>>>> file and I have already done the same for OMAP5 by analogy. I must admit >>>>>>> however that this approach does not correspond to the latest way by which >>>>>>> groups of OMAP hardware regs are defined, prcm in particular - a struct in >>>>>>> omap_common.h, holding only the required regs, no padding and such garbage, >>>>>>> and an init with the physical addresses in a .c file for the particular SoC >>>>>>> (prcm-regs.c). But still the Panda board, for example, uses the old way for >>>>>>> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and >>>>>>> lazy ;) ). >>>>>> Yes, I'm OK starting off with moving things into omap_common.h as-is and >>>>>> then updating them a bit later ala pcrm-regs.c. >>>>>> >>>>>> >>>>> I am sorry for the very late response on this. >>>>> Now then, why not add this register in to omap5_es2_prcm >>>>> ??. That is how the TRM sees it as well.. Of course, this is cleanup >>>>> stuff for OMAP4 panda as you pointed out.. >>>> Yes, you are right in respect to fluent software integration and consistency >>>> with current implementation. My only concern is that from architectural point >>>> of view the SCRM, although related to the PRCM, is a separate module (described >>>> correspondingly as such in the TRM). If we go this way, the SCRM regs shall >>>> have to be referenced via the prcm pointer: (*prcm)->xxxxx, and this might be >>>> confusing. >>>> >>>> I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) >>>> to the prcm_regs declaration in omap_common.h, and the required init to the >>>> appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved >>>> clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h, >>>> start with a scrm_ prefix. >>>> >>>> Alternatively, a new scrm_regs struct could be declared in omap_common.h, along >>>> with the appropriate pointers, and the corresponding definitions/inits added as >>>> new structs in prcm-regs.c for every SoC. But then the file name prcm-regs shall >>>> be a bit confusing. >>>> >>>> What do you say? >>> At this point , i think just adding only the registers that you need in to the >>> prcm structure should be ok. >> OK, I just tend to add all registers, it shall be easier for later rework. > Actually no :). When were are not using them no good in adding. Especially > those SCRM registers very less we will use all of them in bootloader. OK, agree. Done. Now on USB in general: u-boot-ti master lags behind mainline master in respect to drivers/usb/host/ehci-hcd.c (the other TI-specific files are OK). My old .../patch/232742 applies to u-boot-ti correctly. Should we keep it (and then Tom does the merge of ehci-hcd.c), or I rebase on mainline with a V2? Tom? > > Regards, > Sricharan > Regards, Lubo
On Wed, May 15, 2013 at 04:10:46PM +0300, Lubomir Popov wrote: > Hi Sricharan, Tom, [snip] > Now on USB in general: u-boot-ti master lags behind mainline master in respect to > drivers/usb/host/ehci-hcd.c (the other TI-specific files are OK). My old > .../patch/232742 applies to u-boot-ti correctly. Should we keep it (and then Tom > does the merge of ehci-hcd.c), or I rebase on mainline with a V2? Tom? The patch still git am's fine on master (just checked), so it's OK as-is.
OK, thanks. On 15/05/13 16:43, Tom Rini wrote: > On Wed, May 15, 2013 at 04:10:46PM +0300, Lubomir Popov wrote: >> Hi Sricharan, Tom, > [snip] >> Now on USB in general: u-boot-ti master lags behind mainline master in respect to >> drivers/usb/host/ehci-hcd.c (the other TI-specific files are OK). My old >> .../patch/232742 applies to u-boot-ti correctly. Should we keep it (and then Tom >> does the merge of ehci-hcd.c), or I rebase on mainline with a V2? Tom? > > The patch still git am's fine on master (just checked), so it's OK > as-is. > Lubo
diff --git a/arch/arm/include/asm/mach-types.h b/arch/arm/include/asm/mach-types.h index a676b6d..236fa17 100644 --- a/arch/arm/include/asm/mach-types.h +++ b/arch/arm/include/asm/mach-types.h @@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_OMAP5_SEVM 3777 #define MACH_TYPE_ARMADILLO_800EVA 3863 #define MACH_TYPE_KZM9G 4140 +#define MACH_TYPE_SOM5_EVB 4545 #ifdef CONFIG_ARCH_EBSA110 # ifdef machine_arch_type @@ -14248,6 +14249,18 @@ extern unsigned int __machine_arch_type; # define machine_is_kzm9g() (0) #endif +#ifdef CONFIG_MACH_SOM5_EVB +# ifdef machine_arch_type +# undef machine_arch_type +# define machine_arch_type __machine_arch_type +# else +# define machine_arch_type MACH_TYPE_SOM5_EVB +# endif +# define machine_is_som5_evb() (machine_arch_type == MACH_TYPE_SOM5_EVB) +#else +# define machine_is_som5_evb() (0) +#endif + /* * These have not yet been registered */ diff --git a/board/mms/som5_evb/Makefile b/board/mms/som5_evb/Makefile new file mode 100644 index 0000000..248e5cc --- /dev/null +++ b/board/mms/som5_evb/Makefile @@ -0,0 +1,49 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, wd@denx.de. +# +# 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., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).o + +COBJS := som5_evb.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB): $(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +clean: + rm -f $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +######################################################################### + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +######################################################################### diff --git a/board/mms/som5_evb/s5evb_mux_data.h b/board/mms/som5_evb/s5evb_mux_data.h new file mode 100644 index 0000000..791a4ad --- /dev/null +++ b/board/mms/som5_evb/s5evb_mux_data.h @@ -0,0 +1,376 @@ +/* + * Copyright (C) 2013 MM Solutions AD, <www.mm-sol.com> + * + * Lubomir Popov <lpopov@mm-sol.com> <l-popov@ti.com> + * + * 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., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ +#ifndef _SOM5_EVB_MUX_DATA_H +#define _SOM5_EVB_MUX_DATA_H + +#include <asm/arch/mux_omap5.h> + +const struct pad_conf_entry core_padconf_array_essential[] = { + + {EMMC_CLK, (PTU | IEN | M0)}, /* EMMC_CLK */ + {EMMC_CMD, (PTU | IEN | M0)}, /* EMMC_CMD */ + {EMMC_DATA0, (PTU | IEN | M0)}, /* EMMC_DATA0 */ + {EMMC_DATA1, (PTU | IEN | M0)}, /* EMMC_DATA1 */ + {EMMC_DATA2, (PTU | IEN | M0)}, /* EMMC_DATA2 */ + {EMMC_DATA3, (PTU | IEN | M0)}, /* EMMC_DATA3 */ + {EMMC_DATA4, (PTU | IEN | M0)}, /* EMMC_DATA4 */ + {EMMC_DATA5, (PTU | IEN | M0)}, /* EMMC_DATA5 */ + {EMMC_DATA6, (PTU | IEN | M0)}, /* EMMC_DATA6 */ + {EMMC_DATA7, (PTU | IEN | M0)}, /* EMMC_DATA7 */ + + {SDCARD_CLK, (PTU | IEN | M0)}, /* SDCARD_CLK */ + {SDCARD_CMD, (PTU | IEN | M0)}, /* SDCARD_CMD */ + {SDCARD_DATA0, (PTU | IEN | M0)}, /* SDCARD_DATA0 */ + {SDCARD_DATA1, (PTU | IEN | M0)}, /* SDCARD_DATA1 */ + {SDCARD_DATA2, (PTU | IEN | M0)}, /* SDCARD_DATA2 */ + {SDCARD_DATA3, (PTU | IEN | M0)}, /* SDCARD_DATA3 */ + + {UART3_RX_IRRX, (PTU | IEN | M0)},/* UART3_RX_IRRX */ + {UART3_TX_IRTX, (M0)}, /* UART3_TX_IRTX */ + + {HSI2_CAREADY, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)}, /* USBB1_ULPIPHY_CLK */ + {HSI2_ACREADY, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)}, /* USBB1_ULPIPHY_NXT */ + {HSI2_CAWAKE, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)}, /* USBB1_ULPIPHY_DIR */ + {HSI2_ACWAKE, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)}, /* USBB1_ULPIPHY_STP */ + {HSI2_CAFLAG, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)}, /* USBB1_ULPIPHY_DATA0 */ + {HSI2_CADATA, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)}, /* USBB1_ULPIPHY_DATA1 */ + {HSI2_ACFLAG, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)}, /* USBB1_ULPIPHY_DATA2 */ + {HSI2_ACDATA, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)}, /* USBB1_ULPIPHY_DATA3 */ + {UART2_RTS, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)}, /* USBB1_ULPIPHY_DATA4 */ + {UART2_CTS, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)}, /* USBB1_ULPIPHY_DATA5 */ + {UART2_RX, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)}, /* USBB1_ULPIPHY_DATA6 */ + {UART2_TX, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)}, /* USBB1_ULPIPHY_DATA7 */ + + {USBB2_HSIC_STROBE, (PTU | IEN | M0)}, /* USBB2_HSIC_STROBE */ + {USBB2_HSIC_DATA, (PTU | IEN | M0)}, /* USBB2_HSIC_DATA */ + + {USBB3_HSIC_STROBE, (PTU | IEN | M0)}, /* USBB3_HSIC_STROBE */ + {USBB3_HSIC_DATA, (PTU | IEN | M0)}, /* USBB3_HSIC_DATA */ + + {USBD0_HS_DP, (IEN | M0)}, /* USBD0_HS_DP */ + {USBD0_HS_DM, (IEN | M0)}, /* USBD0_HS_DM */ + {USBD0_SS_RX, (IEN | M0)}, /* USBD0_SS_RX (LP: WTF is this for?) */ + +}; + +const struct pad_conf_entry wkup_padconf_array_essential[] = { + + {SR_PMIC_SCL, (PTU | IEN | M0)}, /* SR_PMIC_SCL */ + {SR_PMIC_SDA, (PTU | IEN | M0)}, /* SR_PMIC_SDA */ + + {SYS_32K, (IEN | M0)}, /* SYS_32K */ + +}; + +const struct pad_conf_entry core_padconf_array_non_essential[] = { +#if 0 +/* GPMC is actually not useable directly as we don't have + the GPMC_NOE_NRE signal available, and some external logic + shall be needed. Anyway, M4 is the reset default. +*/ + {C2C_DATAIN0, (IEN | M4)}, /* GPMC_AD0 */ + {C2C_DATAIN1, (IEN | M4)}, /* GPMC_AD1 */ + {C2C_DATAIN2, (IEN | M4)}, /* GPMC_AD2 */ + {C2C_DATAIN3, (IEN | M4)}, /* GPMC_AD3 */ + {C2C_DATAIN4, (IEN | M4)}, /* GPMC_AD4 */ + {C2C_DATAIN5, (IEN | M4)}, /* GPMC_AD5 */ + {C2C_DATAIN6, (IEN | M4)}, /* GPMC_AD6 */ + {C2C_DATAIN7, (IEN | M4)}, /* GPMC_AD7 */ + {C2C_CLKIN1, (IEN | M4)}, /* GPMC_CLK */ + {C2C_CLKIN0, (M5)}, /* GPMC_NBE1 */ + {C2C_CLKOUT0, (M4)}, /* GPMC_NADV_ALE */ + {C2C_CLKOUT1, (M4)}, /* GPMC_NBE0_CLE */ + {C2C_DATAOUT0, (IEN | M4)}, /* GPMC_AD8 */ + {C2C_DATAOUT1, (IEN | M4)}, /* GPMC_AD9 */ + {C2C_DATAOUT2, (IEN | M4)}, /* GPMC_AD10 */ + {C2C_DATAOUT3, (IEN | M4)}, /* GPMC_AD11 */ + {C2C_DATAOUT4, (IEN | M4)}, /* GPMC_AD12 */ + {C2C_DATAOUT5, (IEN | M4)}, /* GPMC_AD13 */ + {C2C_DATAOUT6, (IEN | M4)}, /* GPMC_AD14 */ + {C2C_DATAOUT7, (IEN | M4)}, /* GPMC_AD15 */ + {C2C_DATA8, (M4)}, /* GPMC_A16 */ + {C2C_DATA9, (M4)}, /* GPMC_A17 */ + {C2C_DATA10, (M4)}, /* GPMC_A18 */ + {C2C_DATA11, (M4)}, /* GPMC_A19 */ + {C2C_DATA12, (M4)}, /* GPMC_A20 */ + {C2C_DATA13, (M4)}, /* GPMC_A21 */ + {C2C_DATA14, (M4)}, /* GPMC_A22 */ + {C2C_DATA15, (M4)}, /* GPMC_A23 */ + {LLIA_WAKEREQOUT, (PTU | IEN | M4)}, /* GPMC_WAIT0 */ + {UART1_RTS, (M4)}, /* GPMC_NCS7 */ +#else +/* Test in GPIO mode. Convention: left (odd) pins on connector are + outputs (initialized to PD), right (even) pins are inputs with PU. +*/ + {C2C_DATAIN0, (IEN | PTU | M6)}, /* GPIO2_37 In J201:06 */ + {C2C_DATAIN1, (IEN | PTU | M6)}, /* GPIO2_38 In J201:04 */ + {C2C_DATAIN2, (IEN | PTU | M6)}, /* GPIO2_39 In J201:10 */ + {C2C_DATAIN3, (IEN | PTU | M6)}, /* GPIO2_40 In J201:08 */ + {C2C_DATAIN4, (IEN | PTU | M6)}, /* GPIO2_41 In J201:16 */ + {C2C_DATAIN5, (IEN | PTU | M6)}, /* GPIO2_42 In J201:12 */ + {C2C_DATAIN6, (IEN | PTU | M6)}, /* GPIO2_43 In J201:20 */ + {C2C_DATAIN7, (IEN | PTU | M6)}, /* GPIO2_44 In J201:18 */ + {C2C_CLKIN1, (PTD | M6)}, /* GPIO2_36 Out J201:03 */ + {C2C_CLKIN0, (PTD | M6)}, /* GPIO2_35 Out J201:11 */ + {C2C_CLKOUT0, (PTD | M6)}, /* GPIO2_33 Out J201:17 */ + {C2C_CLKOUT1, (PTD | M6)}, /* GPIO2_34 Out J201:09 */ + {C2C_DATAOUT0, (PTD | M6)}, /* GPIO2_56 Out J201:31 */ + {C2C_DATAOUT1, (PTD | M6)}, /* GPIO2_57 Out J201:23 */ + {C2C_DATAOUT2, (PTD | M6)}, /* GPIO2_58 Out J201:25 */ + {C2C_DATAOUT3, (PTD | M6)}, /* GPIO2_59 Out J201:15 */ + {C2C_DATAOUT4, (PTD | M6)}, /* GPIO2_60 Out J201:29 */ + {C2C_DATAOUT5, (PTD | M6)}, /* GPIO2_61 Out J201:21 */ + {C2C_DATAOUT6, (IEN | PTU | M6)}, /* GPIO2_62 In J201:22 */ + {C2C_DATAOUT7, (IEN | PTU | M6)}, /* GPIO2_63 In J201:24 */ + {C2C_DATA8, (IEN | PTU | M6)}, /* GPIO4_113 In J201:32 */ + {C2C_DATA9, (IEN | PTU | M6)}, /* GPIO4_114 In J201:30 */ + {C2C_DATA10, (IEN | PTU | M6)}, /* GPIO4_115 In J201:36 */ + {C2C_DATA11, (IEN | PTU | M6)}, /* GPIO4_116 In J201:26 */ + {C2C_DATA12, (PTD | M6)}, /* GPIO4_117 Out J201:35 */ + {C2C_DATA13, (PTD | M6)}, /* GPIO4_118 Out J201:33 */ + {C2C_DATA14, (IEN | PTU | M6)}, /* GPIO4_119 In J201:38 */ + {C2C_DATA15, (IEN | PTU | M6)}, /* GPIO4_120 In J201:34 */ + {LLIA_WAKEREQOUT, (PTD | M6)}, /* GPIO2_45 Out J201:07 */ + {UART1_RTS, (PTD | M6)}, /* GPIO3_75 Out J201:37 */ +#endif + {LLIB_WAKEREQOUT, (PTU | IEN | M6)}, /* GPIO2_32 In I/O Exp Int */ + + {HSI1_ACREADY, (PTD | M6)}, /* GPIO3_64 Out J701:28 */ + {HSI1_CAREADY, (PTD | M6)}, /* GPIO3_65 Out J701:26 */ + {HSI1_ACWAKE, (PTD | M6)}, /* GPIO3_66 Out J801:25 */ + {HSI1_CAWAKE, (PTU | IEN | M6)}, /* GPIO3_67 In SDcard:CD */ + {HSI1_ACFLAG, (PTU | IEN | M6)}, /* GPIO3_68 In J801:22 */ + {HSI1_ACDATA, (PTD | M6)}, /* GPIO3_69 Out J801:21 */ + {HSI1_CAFLAG, (PTU | IEN | M6)}, /* GPIO3_70 In J801:32 */ + {HSI1_CADATA, (PTD | M6)}, /* GPIO3_71 Out J801:29 */ + {UART1_TX, (PTU | IEN | M6)}, /* GPIO3_72 In J801:26 */ + {UART1_CTS, (PTD | M6)}, /* GPIO3_73 Out J801:31 */ + {UART1_RX, (PTU | IEN | M6)}, /* GPIO3_74 In J801:30 */ + + {USBB1_HSIC_STROBE, (PTU | IEN | M6)}, /* GPIO3_92 In NU */ + {USBB1_HSIC_DATA, (PTU | IEN | M6)}, /* GPIO3_93 In NU */ + + {TIMER10_PWM_EVT, (PTD | M6)}, /* GPIO6_188 Out J802:11 */ + {DSIPORTA_TE0, (PTU | IEN | M6)}, /* GPIO6_189 In J802:26 */ + {DSIPORTA_LANE0X, (IEN | M0)}, /* DSIPORTA_LANE0X J704 */ + {DSIPORTA_LANE0Y, (IEN | M0)}, /* DSIPORTA_LANE0Y J704 */ + {DSIPORTA_LANE1X, (IEN | M0)}, /* DSIPORTA_LANE1X J704 */ + {DSIPORTA_LANE1Y, (IEN | M0)}, /* DSIPORTA_LANE1Y J704 */ + {DSIPORTA_LANE2X, (IEN | M0)}, /* DSIPORTA_LANE2X J704 */ + {DSIPORTA_LANE2Y, (IEN | M0)}, /* DSIPORTA_LANE2Y J704 */ + {DSIPORTA_LANE3X, (IEN | M0)}, /* DSIPORTA_LANE3X J704 */ + {DSIPORTA_LANE3Y, (IEN | M0)}, /* DSIPORTA_LANE3Y J704 */ + {DSIPORTA_LANE4X, (IEN | M0)}, /* DSIPORTA_LANE4X J704 */ + {DSIPORTA_LANE4Y, (IEN | M0)}, /* DSIPORTA_LANE4Y J704 */ + + {TIMER9_PWM_EVT, (PTU | IEN | M6)}, /* GPIO6_190 In J802:12 */ + {DSIPORTC_TE0, (PTD | M6)}, /* GPIO6_191 Out J802:15 */ + {DSIPORTC_LANE0X, (IEN | M0)}, /* DSIPORTC_LANE0X J702 */ + {DSIPORTC_LANE0Y, (IEN | M0)}, /* DSIPORTC_LANE0Y J702 */ + {DSIPORTC_LANE1X, (IEN | M0)}, /* DSIPORTC_LANE1X J702 */ + {DSIPORTC_LANE1Y, (IEN | M0)}, /* DSIPORTC_LANE1Y J702 */ + {DSIPORTC_LANE2X, (IEN | M0)}, /* DSIPORTC_LANE2X J702 */ + {DSIPORTC_LANE2Y, (IEN | M0)}, /* DSIPORTC_LANE2Y J702 */ + {DSIPORTC_LANE3X, (IEN | M0)}, /* DSIPORTC_LANE3X J702 */ + {DSIPORTC_LANE3Y, (IEN | M0)}, /* DSIPORTC_LANE3Y J702 */ + {DSIPORTC_LANE4X, (IEN | M0)}, /* DSIPORTC_LANE4X J702 */ + {DSIPORTC_LANE4Y, (IEN | M0)}, /* DSIPORTC_LANE4Y J702 */ + + {RFBI_HSYNC0, (M4)}, /* KBD_COL5 (Out) HOME */ + {RFBI_TE_VSYNC0, (PTD | M6)}, /* GPIO6_161 Out J704:24 3D_MODE_EN */ + {RFBI_WE, (PTD | M5)}, /* DRM_EMU2 (Out) */ + {RFBI_CS0, (PTD | M5)}, /* DRM_EMU3 (Out) */ + {RFBI_RE, (M4)}, /* KBD_COL4 (Out) SEND */ + {RFBI_A0, (PTU | IEN | M6)}, /* GPIO6_165 In SH2_SENS_INT */ + {RFBI_DATA0, (PTD | M5)}, /* DRM_EMU4 (Out) */ + {RFBI_DATA1, (PTD | M5)}, /* DRM_EMU5 (Out) */ + {RFBI_DATA2, (PTD | M5)}, /* DRM_EMU6 (Out) */ + {RFBI_DATA3, (PTD | M6)}, /* GPIO6_169 Out J704:22 3D_LCD_BANK_SEL */ + {RFBI_DATA4, (PTU | IEN | M6)}, /* GPIO6_170 In TEMP_ALERT on SOM (OD) */ + {RFBI_DATA5, (PTU | IEN | M6)}, /* GPIO6_171 In J802:30 */ + {RFBI_DATA6, (PTD | M6)}, /* GPIO6_172 Out LAN9730 nRESET */ + {RFBI_DATA7, (PTD | M6)}, /* GPIO6_173 Out USB4640 nRESET */ + {RFBI_DATA8, (M4)}, /* KBD_COL3 (Out) VOL- */ + {RFBI_DATA9, (PTD | M6)}, /* GPIO6_175 Out MCLK_1E */ + {RFBI_DATA10, (PTD | M6)}, /* GPIO6_176 Out MCLK_2E */ + {RFBI_DATA11, (PTD | M6)}, /* GPIO6_177 Out MCLK_3E */ + {RFBI_DATA12, (PTD | M6)}, /* GPIO6_178 Out J703:25 CAM_SUBPM_EN */ + {RFBI_DATA13, (PTU | IEN | M6)}, /* GPIO6_179 In J704:27 TSCR_INT (OD) */ + {RFBI_DATA14, (M4)}, /* KBD_COL7 (Out) SEARCH */ + {RFBI_DATA15, (M4)}, /* KBD_COL6 (Out) END */ + + {GPIO6_182, (PTU | IEN | M6)}, /* GPIO6_182 In J802:28 */ + {GPIO6_183, (PTD | M6)}, /* GPIO6_183 Out J704:25 nLCD_RESET */ + {GPIO6_184, (M4)}, /* KBD_COL2 (Out) VOL+ */ + {GPIO6_185, (PTU | IEN | M6)}, /* GPIO6_185 In J802:32 */ + {GPIO6_186, (PTD | M6)}, /* GPIO6_186 Out J802:25 */ + {GPIO6_187, (PTU | IEN | M4)}, /* KBD_ROW2 (In) All btns*/ +#if 0 + {MCSPI2_CS0, (M0)}, /* MCSPI2_CS0 J802:31 */ + {MCSPI2_CLK, (IEN | M0)}, /* MCSPI2_CLK J802:23 */ + {MCSPI2_SIMO, (IEN | M0)}, /* MCSPI2_SIMO J802:29 */ + {MCSPI2_SOMI, (PTU | IEN | M0)}, /* MCSPI2_SOMI J802:18 */ +#else + {MCSPI2_CS0, (PTD | M6)}, /* GPIO7_196 Out J802:31 */ + {MCSPI2_CLK, (PTD | M6)}, /* GPIO7_197 Out J802:23 */ + {MCSPI2_SIMO, (PTD | M6)}, /* GPIO7_198 Out J802:29 */ + {MCSPI2_SOMI, (PTU | IEN | M6)}, /* GPIO7_199 In J802:18 */ +#endif + {I2C4_SCL, (IEN | PTU | M0)}, /* I2C4_SCL */ + {I2C4_SDA, (IEN | PTU | M0)}, /* I2C4_SDA */ + + {HDMI_CEC, (IEN | M0)}, /* HDMI_CEC */ + {HDMI_HPD, (PTD | IEN | M0)}, /* HDMI_HPD */ + {HDMI_DDC_SCL, (IEN | M0)}, /* HDMI_DDC_SCL */ + {HDMI_DDC_SDA, (IEN | M0)}, /* HDMI_DDC_SDA */ + + {CSIPORTA_LANE0X, (IEN | M0)}, /* CSIPORTA_LANE0X */ + {CSIPORTA_LANE0Y, (IEN | M0)}, /* CSIPORTA_LANE0Y */ + {CSIPORTA_LANE1Y, (IEN | M0)}, /* CSIPORTA_LANE1Y */ + {CSIPORTA_LANE1X, (IEN | M0)}, /* CSIPORTA_LANE1X */ + {CSIPORTA_LANE2Y, (IEN | M0)}, /* CSIPORTA_LANE2Y */ + {CSIPORTA_LANE2X, (IEN | M0)}, /* CSIPORTA_LANE2X */ + {CSIPORTA_LANE3X, (IEN | M0)}, /* CSIPORTA_LANE3X */ + {CSIPORTA_LANE3Y, (IEN | M0)}, /* CSIPORTA_LANE3Y */ + {CSIPORTA_LANE4X, (IEN | M0)}, /* CSIPORTA_LANE4X */ + {CSIPORTA_LANE4Y, (IEN | M0)}, /* CSIPORTA_LANE4Y */ + + {CSIPORTB_LANE0X, (IEN | M0)}, /* CSIPORTB_LANE0X */ + {CSIPORTB_LANE0Y, (IEN | M0)}, /* CSIPORTB_LANE0Y */ + {CSIPORTB_LANE1Y, (IEN | M0)}, /* CSIPORTB_LANE1Y */ + {CSIPORTB_LANE1X, (IEN | M0)}, /* CSIPORTB_LANE1X */ + {CSIPORTB_LANE2Y, (IEN | M0)}, /* CSIPORTB_LANE2Y */ + {CSIPORTB_LANE2X, (IEN | M0)}, /* CSIPORTB_LANE2X */ + + {CSIPORTC_LANE0Y, (IEN | M0)}, /* CSIPORTC_LANE0Y */ + {CSIPORTC_LANE0X, (IEN | M0)}, /* CSIPORTC_LANE0X */ + {CSIPORTC_LANE1Y, (IEN | M0)}, /* CSIPORTC_LANE1Y */ + {CSIPORTC_LANE1X, (IEN | M0)}, /* CSIPORTC_LANE1X */ + + {CAM_SHUTTER, (M0)}, /* CAM_SHUTTER/224 J701:22 */ + {CAM_STROBE, (M0)}, /* CAM_STROBE/225 J701:24 */ + {CAM_GLOBALRESET, (IEN | M0)}, /* CAM_GLOBALRESET/226 J701:20 */ + {TIMER11_PWM_EVT, (PTD | M6)}, /* GPIO8_227 Out J703:26 PRIMARY_5M_RESET_N */ + {TIMER5_PWM_EVT, (PTD | M6)}, /* GPIO8_228 Out J703:28 SECONDARY_5M_RESET_N */ + {TIMER6_PWM_EVT, (PTD | M6)}, /* GPIO8_229 Out J701:18 */ + {TIMER8_PWM_EVT, (PTD | M6)}, /* GPIO8_230 Out J701:16 */ + + {I2C3_SCL, (IEN | PTU | M0)}, /* I2C3_SCL */ + {I2C3_SDA, (IEN | PTU | M0)}, /* I2C3_SDA */ + + {GPIO8_233, (PTD | M6)}, /* GPIO8_233 Out J701:25 */ + + {ABE_CLKS, (IEN | M0)}, /* ABE_CLKS */ + {ABEDMIC_DIN1, (PTD | M6)}, /* GPIO4_97 Out J801:13 */ + {ABEDMIC_DIN2, (PTU | IEN | M6)}, /* GPIO4_98 In J801:12 */ + {ABEDMIC_DIN3, (PTD | M6)}, /* GPIO4_99 Out J801:11 */ + {ABEDMIC_CLK1, (PTU | IEN | M6)}, /* GPIO4_100 In J801:14 */ + + {ABEDMIC_CLK2, (IEN | M1)}, /* ABEMCBSP1_FSX BT Aud */ + {ABEDMIC_CLK3, (M1)}, /* ABEMCBSP1_DX BT Aud */ + {ABESLIMBUS1_CLOCK, (IEN | M1)}, /* ABEMCBSP1_CLKX BT Aud */ + {ABESLIMBUS1_DATA, (IEN | M1)}, /* ABEMCBSP1_DR BT Aud */ + + {ABEMCBSP2_DR, (IEN | M0)}, /* ABEMCBSP2_DR FM Aud */ + {ABEMCBSP2_DX, (M0)}, /* ABEMCBSP2_DX FM Aud */ + {ABEMCBSP2_FSX, (IEN | M0)}, /* ABEMCBSP2_FSX FM Aud */ + {ABEMCBSP2_CLKX, (IEN | M0)}, /* ABEMCBSP2_CLKX FM Aud */ + + {ABEMCPDM_UL_DATA, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M0)}, /* ABEMCPDM_UL_DATA */ + {ABEMCPDM_DL_DATA, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M0)}, /* ABEMCPDM_DL_DATA */ + {ABEMCPDM_FRAME, (PTU | IEN | OFF_EN | OFF_PD | OFF_IN | M0)}, /* ABEMCPDM_FRAME */ + {ABEMCPDM_LB_CLK, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M0)}, /* ABEMCPDM_LB_CLK */ + + {WLSDIO_CLK, (PTU | IEN | M0)}, /* WLSDIO_CLK */ + {WLSDIO_CMD, (PTU | IEN | M0)}, /* WLSDIO_CMD */ + {WLSDIO_DATA0, (PTU | IEN | M0)}, /* WLSDIO_DATA0 */ + {WLSDIO_DATA1, (PTU | IEN | M0)}, /* WLSDIO_DATA1 */ + {WLSDIO_DATA2, (PTU | IEN | M0)}, /* WLSDIO_DATA2 */ + {WLSDIO_DATA3, (PTU | IEN | M0)}, /* WLSDIO_DATA3 */ + + {UART5_RX, (PTU | IEN | M0)}, /* UART5_RX BT HCI */ + {UART5_TX, (M0)}, /* UART5_TX BT HCI */ + {UART5_CTS, (PTU | IEN | M0)}, /* UART5_CTS BT HCI */ + {UART5_RTS, (M0)}, /* UART5_RTS BT HCI */ + + {I2C2_SCL, (IEN | M0)}, /* I2C2_SCL */ + {I2C2_SDA, (IEN | M0)}, /* I2C2_SDA */ + + {MCSPI1_CLK, (PTD | M6)}, /* GPIO5_140 Out WLAN EN */ + {MCSPI1_SOMI, (PTD | M6)}, /* GPIO5_141 Out J802:17 */ + {MCSPI1_SIMO, (PTD | M6)}, /* GPIO5_142 Out BT EN */ + {MCSPI1_CS0, (PTD | M6)}, /* GPIO5_143 Out BT Wkup */ + {MCSPI1_CS1, (PTD | IEN | M6)}, /* GPIO5_144 In Host WU */ + + {I2C5_SCL, (IEN | PTU | M0)}, /* I2C5_SCL */ + {I2C5_SDA, (IEN | PTU | M0)}, /* I2C5_SDA */ + + {PERSLIMBUS2_CLOCK, (PTD | M6)}, /* GPIO5_145 Out AUDPWRON*/ + {PERSLIMBUS2_DATA, (PTD | M6)}, /* GPIO5_146 Out J802:27 */ + {UART6_TX, (PTD | M6)}, /* GPIO5_149 Out J802:13 */ + {UART6_RX, (PTU | IEN | M6)}, /* GPIO5_150 In J802:20 */ + {UART6_CTS, (PTU | IEN | M6)}, /* GPIO5_151 In J802:21 EXCEPTION TO RULE, SHORT WITH PIN 23 */ + {UART6_RTS, (PTD | M6)}, /* GPIO5_152 Out J802:19 */ + {UART3_CTS_RCTX, (PTD | IEN | M6)}, /* GPIO5_153 In J802:14 or SATA_ACTLED Out (M1). PTD! */ + {UART3_RTS_IRSD, (PTU | IEN | M6)}, /* GPIO5_154 In J802:16 */ + + {I2C1_PMIC_SCL, (PTU | IEN | M0)}, /* I2C1_PMIC_SCL */ + {I2C1_PMIC_SDA, (PTU | IEN | M0)}, /* I2C1_PMIC_SDA */ + +}; + +const struct pad_conf_entry wkup_padconf_array_non_essential[] = { + + {LLIA_WAKEREQIN, (PTU | IEN | M6)}, /* GPIO1_WK14 In J201:19 */ + {LLIB_WAKEREQIN, (PTU | IEN | M6)}, /* GPIO1_WK15 In J801:18 */ + {DRM_EMU0, (PTU | IEN | M0)}, /* DRM_EMU0 */ + {DRM_EMU1, (PTU | IEN | M0)}, /* DRM_EMU1 */ + {JTAG_NTRST, (IEN | M0)}, /* JTAG_NTRST */ + {JTAG_TCK, (IEN | M0)}, /* JTAG_TCK */ + {JTAG_RTCK, (M0)}, /* JTAG_RTCK */ + {JTAG_TMSC, (IEN | M0)}, /* JTAG_TMSC */ + {JTAG_TDI, (IEN | M0)}, /* JTAG_TDI */ + {JTAG_TDO, (M0)}, /* JTAG_TDO */ + {FREF_CLK_IOREQ, (PTU | IEN | M6)}, /* GPIO1_WK13 In ETH_WAKE */ + {FREF_CLK0_OUT, (M0)}, /* FREF_CLK0_OUT */ + {FREF_CLK1_OUT, (M0)}, /* FREF_CLK1_OUT */ + {FREF_CLK2_OUT, (M0)}, /* FREF_CLK2_OUT */ + {FREF_CLK2_REQ, (PTU | IEN | M6)}, /* GPIO1_WK9 In WiLink Int */ + {FREF_CLK1_REQ, (PTU | IEN | M6)}, /* GPIO1_WK8 In SH2_MSP_INT */ + {SYS_NRESPWRON, (IEN | M0)}, /* SYS_NRESPWRON */ + {SYS_NRESWARM, (PTU | IEN | M0)}, /* SYS_NRESWARM */ + {SYS_PWR_REQ, (M0)}, /* SYS_PWR_REQ */ + {SYS_NIRQ1, (PTU | IEN | M0)}, /* SYS_NIRQ1 */ + {SYS_NIRQ2, (PTU | IEN | M0)}, /* SYS_NIRQ2 */ + {SYS_BOOT0, (IEN | M0)}, /* SYS_BOOT0 */ + {SYS_BOOT1, (IEN | M0)}, /* SYS_BOOT1 */ + {SYS_BOOT2, (IEN | M0)}, /* SYS_BOOT2 */ + {SYS_BOOT3, (IEN | M0)}, /* SYS_BOOT3 */ + {SYS_BOOT4, (IEN | M0)}, /* SYS_BOOT4 */ + {SYS_BOOT5, (IEN | M0)}, /* SYS_BOOT5 */ + +}; + +#endif /* _SOM5_EVB_MUX_DATA_H */ + diff --git a/board/mms/som5_evb/som5_evb.c b/board/mms/som5_evb/som5_evb.c new file mode 100644 index 0000000..a84672e --- /dev/null +++ b/board/mms/som5_evb/som5_evb.c @@ -0,0 +1,200 @@ +/* + * Copyright (C) 2013 MM Solutions AD, <www.mm-sol.com> + * + * 02/2013 Derived from OMAP5 EVM and modified for the SOM5 EVB + * by Lubomir Popov <lpopov@mm-sol.com> <l-popov@ti.com> + * + * 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., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ +#include <common.h> +#include <twl6035.h> +#include <asm/arch/sys_proto.h> +#include <asm/arch/mmc_host_def.h> +#include <asm/gpio.h> +#include <asm/omap_common.h> + +#include "s5evb_mux_data.h" + +#ifdef CONFIG_USB_EHCI +#include <usb.h> +#include <asm/arch/ehci.h> +#include <asm/ehci-omap.h> +#endif + +DECLARE_GLOBAL_DATA_PTR; + +const struct omap_sysinfo sysinfo = { + "Board: MM Solutions SOM5 EVB\n" +}; + +/** + * @brief board_init + * + * @return 0 + */ +int board_init(void) +{ + gpmc_init(); + gd->bd->bi_arch_number = MACH_TYPE_SOM5_EVB; + gd->bd->bi_boot_params = (0x80000000 + 0x100); /* boot param addr */ + + return 0; +} + +int board_eth_init(bd_t *bis) +{ + return 0; +} + +/** + * @brief misc_init_r - Configure SOM5 EVB board specific features + * such as power configurations, ethernet initialization as phase2 + * of boot sequence + * + * @return 0 + */ +int misc_init_r(void) +{ +#ifdef CONFIG_TWL6035_POWER + twl6035_init_settings(); +#ifdef CONFIG_TWL6035_AUDPWR + /* Useful for measuring voltages around the codec. + * Works with a TWL604x only. + */ + twl6035_audio_power(1); /* Power on 2.1 V SMPS, enable 32 kHz */ + udelay(1000); /* Allow ramp-up */ + /* Start TWL6040 internal power on sequence: */ + gpio_request(CONFIG_OMAP_AUDPWRON_GPIO, "AUDPWRON"); + gpio_direction_output(CONFIG_OMAP_AUDPWRON_GPIO, 1); +#endif +#ifdef CONFIG_BB_CHRG + /* Board has a 3 V super-cap for BB */ + twl6035_enable_bb_charge(BB_HIGH_ICHRG | BB_VSEL_3V0 | BB_CHRG_EN); +#endif +#endif /* CONFIG_TWL6035_POWER */ +#ifdef CONFIG_SYSCLK_OUT_EN + /* Enable FREF_XTAL_CLK output (19.2 MHz). + * Used as Audio MCLK; for measurement only. + * TODO: Use proper defines + * control_ckobuffer + */ + writel(0x10000000, 0x4ae0cdb4); +#endif + return 0; +} + +void set_muxconf_regs_essential(void) +{ + do_set_mux(CONTROL_PADCONF_CORE, core_padconf_array_essential, + sizeof(core_padconf_array_essential) / + sizeof(struct pad_conf_entry)); + + do_set_mux(CONTROL_PADCONF_WKUP, wkup_padconf_array_essential, + sizeof(wkup_padconf_array_essential) / + sizeof(struct pad_conf_entry)); + + /* Set the MSECURE Mode for GPIO234 pin */ + if (get_device_type() == DEVICE_GP) { + u32 msecure_pad = CONTROL_PADCONF_CORE + GPIO8_234; + writew((readw(msecure_pad) & ~M7) | M1, msecure_pad); + } +#ifdef CONFIG_I2C_INTERNAL_PULLUPS + /* Enable internal I2C-compatible pullups on all buses + * TODO: Replace this ugly hardcoding with proper defines (omap.h) + * control_smart3io_padconf_0, control_i2c_0 + */ + writel(0x00554000, 0x4a002dc0); /* First set drive strength */ + writel(0, 0x4a002e04); /* Now enable pull-ups */ +#endif +} + +void set_muxconf_regs_non_essential(void) +{ + do_set_mux(CONTROL_PADCONF_CORE, core_padconf_array_non_essential, + sizeof(core_padconf_array_non_essential) / + sizeof(struct pad_conf_entry)); + + do_set_mux(CONTROL_PADCONF_WKUP, wkup_padconf_array_non_essential, + sizeof(wkup_padconf_array_non_essential) / + sizeof(struct pad_conf_entry)); +} + +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC) +int board_mmc_init(bd_t *bis) +{ + omap_mmc_init(0, 0, 0, -1, -1); + omap_mmc_init(1, 0, 0, -1, -1); + return 0; +} +#endif + +#ifdef CONFIG_USB_EHCI + +#define USB_HOST_HS_CLKCTRL_MASK 0x0100D7C0 /* CM_L3INIT_USB_HOST_HS_CLKCTRL */ +#define USB_TLL_HS_CLKCTRL_MASK 0x00000700 /* CM_L3INIT_USB_TLL_HS_CLKCTRL */ + +static struct omap_usbhs_board_data usbhs_bdata = { + .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY, /* USBB1: ULPI PHY TUSB1210 */ + .port_mode[1] = OMAP_EHCI_PORT_MODE_HSIC, /* USBB2: HSIC USB4640 hub */ + .port_mode[2] = OMAP_EHCI_PORT_MODE_HSIC, /* USBB3: HSIC LAN9730 Ethernet ctrl */ +}; + +int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor) +{ + int ret; + + /* Enbale all 3 USB ports UHH, UTMI and HSIC clocks */ + setbits_le32((*prcm)->cm_l3init_hsusbhost_clkctrl, + USB_HOST_HS_CLKCTRL_MASK); + + /* Enbale all 3 USB host ports TLL clocks */ + setbits_le32((*prcm)->cm_l3init_hsusbtll_clkctrl, + USB_TLL_HS_CLKCTRL_MASK); + + /* USBB1 ULPI PHY uses OMAP FREF_CLK0_OUT. Must turn it on. + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); + udelay(1000); /* Let PHY PLL lock */ + + ret = omap_ehci_hcd_init(&usbhs_bdata, hccr, hcor); + if (ret < 0) + return ret; + + return 0; +} + +int ehci_hcd_stop(void) +{ + int ret; + + ret = omap_ehci_hcd_stop(); + + clrbits_le32((*prcm)->cm_l3init_hsusbhost_clkctrl, + USB_HOST_HS_CLKCTRL_MASK); + clrbits_le32((*prcm)->cm_l3init_hsusbtll_clkctrl, + USB_TLL_HS_CLKCTRL_MASK); + + /* TODO: Replace this ugly hardcoding with proper defines + */ + writel(0, 0x4ae0a310); /* Stop FREF_CLK0_OUT */ + return ret; +} +#endif /* CONFIG_USB_EHCI */ + diff --git a/boards.cfg b/boards.cfg index 5fc70be..337dc42 100644 --- a/boards.cfg +++ b/boards.cfg @@ -292,6 +292,7 @@ twister arm armv7 twister technex nokia_rx51 arm armv7 rx51 nokia omap3 omap4_panda arm armv7 panda ti omap4 omap4_sdp4430 arm armv7 sdp4430 ti omap4 +omap5_som5_evb arm armv7 som5_evb mms omap5 omap5_evm arm armv7 omap5_evm ti omap5 dra7xx_evm arm armv7 dra7xx ti omap5 s5p_goni arm armv7 goni samsung s5pc1xx diff --git a/include/configs/omap5_som5_evb.h b/include/configs/omap5_som5_evb.h new file mode 100644 index 0000000..46a9c0c --- /dev/null +++ b/include/configs/omap5_som5_evb.h @@ -0,0 +1,336 @@ +/* + * Copyright (C) 2013 MM Solutions AD, <www.mm-sol.com> + * + * 02/2013 Derived from OMAP5 EVM and modified for the SOM5 EVB + * by Lubomir Popov <lpopov@mm-sol.com> <l-popov@ti.com> + * + * Configuration settings for the MMS SOM5 (APM-5) Evaluation Board. + * + * 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., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef __CONFIG_H +#define __CONFIG_H + +/* + * High Level Configuration Options + */ +#define CONFIG_ARMV7 /* This is an ARM V7 CPU core */ +#define CONFIG_OMAP /* in a TI OMAP core */ +#define CONFIG_OMAP54XX /* which is a 54XX */ +#define CONFIG_OMAP5430 /* which is in a 5430 */ +#define CONFIG_SOM5EVB /* working with the SOM5 EVB */ +/* Machine type for Linux */ +#define CONFIG_MACH_TYPE MACH_TYPE_SOM5_EVB + +#define CONFIG_OMAP_GPIO + +/* Get CPU defs */ +#include <asm/arch/cpu.h> +#include <asm/arch/omap.h> + +/* Display CPU and Board Info */ +#define CONFIG_DISPLAY_CPUINFO +#define CONFIG_DISPLAY_BOARDINFO + +/* Clock Defines */ +#define V_OSCK 19200000 /* Clock output from T2 */ +#define V_SCLK V_OSCK +/* Enable all clocks: */ +/*#define CONFIG_SYS_CLOCKS_ENABLE_ALL*/ + +#define CONFIG_SYS_ENABLE_PADS_ALL /* Enable all PADS for now */ + +#define CONFIG_MISC_INIT_R + +#define CONFIG_OF_LIBFDT +#define CONFIG_CMD_BOOTZ + +#define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */ +#define CONFIG_SETUP_MEMORY_TAGS +#define CONFIG_INITRD_TAG + +/* + * Size of malloc() pool + * Total Size Environment - 128k + * Malloc - add 256k + */ +#define CONFIG_ENV_SIZE (128 << 10) +#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (256 << 10)) +/* Vector Base */ +#define CONFIG_SYS_CA15_VECTOR_BASE SRAM_ROM_VECT_BASE + +/* + * Hardware drivers + */ + +/* + * serial port - NS16550 compatible + */ +#define V_NS16550_CLK 48000000 + +#define CONFIG_SYS_NS16550 +#define CONFIG_SYS_NS16550_SERIAL +#define CONFIG_SYS_NS16550_REG_SIZE (-4) +#define CONFIG_SYS_NS16550_CLK V_NS16550_CLK +#define CONFIG_CONS_INDEX 3 +#define CONFIG_SYS_NS16550_COM3 UART3_BASE + +#define CONFIG_BAUDRATE 115200 +#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, \ + 57600, 115200} + +/* I2C */ +#define CONFIG_HARD_I2C +#define CONFIG_SYS_I2C_SPEED 100000 +#define CONFIG_SYS_I2C_SLAVE 0x00 /* Own slave addr */ +#define CONFIG_DRIVER_OMAP54XX_I2C +#define CONFIG_I2C_MULTI_BUS +/* MUST be defined if external pullups are not populated: */ +#define CONFIG_I2C_INTERNAL_PULLUPS +/* Define to use Repeated Start by i2c_read (otherwise Stop-Start + * shall be used between the address and data phases): + */ +#undef CONFIG_I2C_REPEATED_START +/* Used by i2c mm/mw; needed for correct write to EEPROM: */ +#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS 10 + +/* TWL6035 */ +#ifndef CONFIG_SPL_BUILD +#define CONFIG_TWL6035_POWER +/* Undef to disable forced PWM mode for the 1.8 V SMPS: */ +#define CONFIG_TWL6035_SMPS7_FPWM +/* Following define enables testing of the TWL6040 audio codec power + * supply environment: the PMIC 2.1 V SMPS, and the codec's internal + * REF, NCP and HS/LS LDOs. Undef to disable powering up codec. */ +#define CONFIG_TWL6035_AUDPWR + +#ifdef CONFIG_TWL6035_AUDPWR +#define CONFIG_OMAP_AUDPWRON_GPIO 145 +#endif +/* Undef to disable BB (super-cap) charging: */ +#define CONFIG_BB_CHRG +#endif /* CONFIG_SPL_BUILD */ + +/* For Audio MCLK test/measurement only; enables the + * OMAP5 FREF_XTAL_CLK output: */ +#define CONFIG_SYSCLK_OUT_EN + +/* MMC */ +#define CONFIG_GENERIC_MMC +#define CONFIG_MMC +#define CONFIG_OMAP_HSMMC +#define CONFIG_DOS_PARTITION + +/* MMC ENV related defines */ +#define CONFIG_ENV_IS_NOWHERE +#ifdef CONFIG_ENV_IS_IN_MMC +#define CONFIG_SYS_MMC_ENV_DEV 1 /* SLOT2: eMMC(1) */ +#define CONFIG_ENV_OFFSET 0xE0000 +#define CONFIG_CMD_SAVEENV +#endif + +#define CONFIG_SYS_CONSOLE_IS_IN_ENV + +/* Flash */ +#define CONFIG_SYS_NO_FLASH + +/* Cache */ +#define CONFIG_SYS_CACHELINE_SIZE 64 +#define CONFIG_SYS_CACHELINE_SHIFT 6 + +/* USB UHH support options */ +#define CONFIG_CMD_USB +#define CONFIG_USB_HOST +#define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_OMAP +#define CONFIG_USB_ULPI +#define CONFIG_USB_ULPI_VIEWPORT_OMAP +#define CONFIG_USB_STORAGE +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 + +/* No signals to reset external PHYs on this board: */ +/*#define CONFIG_OMAP_EHCI_PHY1_RESET_GPIO xxx */ + +/* Due to HSIC connect ussues, device reset is required upon + * applying port power. A GPIO is needed per HSIC device: + */ +#define CONFIG_OMAP_HSIC_PORT2_RESET_GPIO 173 /* Combo hub */ +#define CONFIG_OMAP_HSIC_PORT3_RESET_GPIO 172 /* Ethernet Ctrlr */ + +/* USB Networking options */ + +#define CONFIG_USB_HOST_ETHER +#define CONFIG_USB_ETHER_SMSC95XX + +/* Commands to include */ +#include <config_cmd_default.h> + +/* Enabled commands */ +#define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot */ +#define CONFIG_CMD_NFS /* NFS support */ +#define CONFIG_CMD_DHCP /* DHCP support */ +#define CONFIG_CMD_PING /* PING support */ +#define CONFIG_NET_MULTI + +#define CONFIG_CMD_EXT2 /* EXT2 support */ +#define CONFIG_CMD_FAT /* FAT support */ +#define CONFIG_CMD_I2C /* I2C serial bus support */ +#define CONFIG_CMD_MMC /* MMC support */ +#define CONFIG_CMD_GPIO /* GPIO support */ + +/* Disabled commands */ +#undef CONFIG_CMD_FPGA /* FPGA configuration Support */ +#undef CONFIG_CMD_IMLS /* List all found images */ + +/* + * Environment setup + */ +#define CONFIG_BOOTDELAY 3 + +#define CONFIG_ENV_OVERWRITE + +#define CONFIG_EXTRA_ENV_SETTINGS \ + "usbethaddr=9e:77:39:1b:c4:2d\0" \ + "loadaddr=0x82000000\0" \ + "console=ttyO2,115200n8\0" \ + "usbtty=cdc_acm\0" \ + "vram=16M\0" \ + "mmcdev=0\0" \ + "mmcroot=/dev/mmcblk0p2 rw\0" \ + "mmcrootfstype=ext3 rootwait\0" \ + "mmcargs=setenv bootargs console=${console} " \ + "vram=${vram} " \ + "root=${mmcroot} " \ + "rootfstype=${mmcrootfstype}\0" \ + "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \ + "bootscript=echo Running bootscript from mmc${mmcdev} ...; " \ + "source ${loadaddr}\0" \ + "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \ + "mmcboot=echo Booting from mmc${mmcdev} ...; " \ + "run mmcargs; " \ + "bootm ${loadaddr}\0" \ + +#define CONFIG_BOOTCOMMAND \ + "mmc dev ${mmcdev}; " \ + "if mmc rescan ; then " \ + "if run loadbootscript; then " \ + "run bootscript; " \ + "else " \ + "if run loaduimage; then " \ + "run mmcboot; " \ + "fi; " \ + "fi; " \ + "fi " + +#define CONFIG_AUTO_COMPLETE 1 + +/* + * Miscellaneous configurable options + */ + +#define CONFIG_SYS_PROMPT "SOM5_EVB # " + +#define CONFIG_SYS_LONGHELP /* undef to save memory */ +#define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ +#define CONFIG_SYS_CBSIZE 256 +/* Print Buffer Size */ +#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ + sizeof(CONFIG_SYS_PROMPT) + 16) +#define CONFIG_SYS_MAXARGS 16 +/* Boot Argument Buffer Size */ +#define CONFIG_SYS_BARGSIZE (CONFIG_SYS_CBSIZE) + +/* + * memtest setup + */ +#define CONFIG_SYS_MEMTEST_START 0xb8000000 +#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + (256 << 20)) +/* Undef following two for simple mtest */ +#define CONFIG_SYS_ALT_MEMTEST +#define CONFIG_SYS_MEMTEST_SCRATCH 0x81000000 + +/* Default load address */ +#define CONFIG_SYS_LOAD_ADDR 0x80000000 + +/* Use General purpose timer 1 */ +#define CONFIG_SYS_TIMERBASE GPT2_BASE +#define CONFIG_SYS_PTV 2 /* Divisor: 2^(PTV+1) => 8 */ +#define CONFIG_SYS_HZ 1000 + +/* + * SDRAM Memory Map + * Even though we use two CS all the memory + * is mapped to one contiguous block + */ +#define CONFIG_NR_DRAM_BANKS 1 + +#define CONFIG_SYS_SDRAM_BASE 0x80000000 + +#define CONFIG_SYS_INIT_SP_ADDR (NON_SECURE_SRAM_END - \ + GENERATED_GBL_DATA_SIZE) + +#define CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS + +/* Defines for SDRAM init */ +#ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS +#define CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION +#define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS +#endif + +/* Defines for SPL */ +#define CONFIG_SPL +#define CONFIG_SPL_FRAMEWORK +#define CONFIG_SPL_TEXT_BASE 0x40300350 +#define CONFIG_SPL_MAX_SIZE 0x19000 /* 100K */ +#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR +#define CONFIG_SPL_DISPLAY_PRINT + +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x300 /* address 0x60000 */ +#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x200 /* 256 KB */ +#define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION 1 +#define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "u-boot.img" + +#define CONFIG_SPL_LIBCOMMON_SUPPORT +#define CONFIG_SPL_LIBDISK_SUPPORT +#define CONFIG_SPL_I2C_SUPPORT +#define CONFIG_SPL_MMC_SUPPORT +#define CONFIG_SPL_FAT_SUPPORT +#define CONFIG_SPL_LIBGENERIC_SUPPORT +#define CONFIG_SPL_SERIAL_SUPPORT +#define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds" + +/* + * 64 bytes before this address should be set aside for u-boot.img's + * header. That is 0x80E7FFC0--0x80E80000 should not be used for any + * other needs. + */ +#define CONFIG_SYS_TEXT_BASE 0x80E80000 + +/* + * BSS and malloc area 64MB into memory to allow enough + * space for the kernel at the beginning of memory + */ +#define CONFIG_SPL_BSS_START_ADDR 0x84000000 +#define CONFIG_SPL_BSS_MAX_SIZE 0x100000 /* 1 MB */ +#define CONFIG_SYS_SPL_MALLOC_START 0x84100000 +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x100000 /* 1 MB */ +#define CONFIG_SPL_GPIO_SUPPORT + +#endif /* __CONFIG_H */
Signed-off-by: Lubomir Popov <lpopov@mm-sol.com> --- The som5_evb is an evaluation board for the APM-5 - a OMAP5430-based SOM (system On a Module) designed by MMS and manufactured under license by Jorjin Technologies. arch/arm/include/asm/mach-types.h | 13 ++ board/mms/som5_evb/Makefile | 49 +++++ board/mms/som5_evb/s5evb_mux_data.h | 376 +++++++++++++++++++++++++++++++++++ board/mms/som5_evb/som5_evb.c | 200 +++++++++++++++++++ boards.cfg | 1 + include/configs/omap5_som5_evb.h | 336 +++++++++++++++++++++++++++++++ 6 files changed, 975 insertions(+) create mode 100644 board/mms/som5_evb/Makefile create mode 100644 board/mms/som5_evb/s5evb_mux_data.h create mode 100644 board/mms/som5_evb/som5_evb.c create mode 100644 include/configs/omap5_som5_evb.h