Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A add flag status check during SPI Flash write
-Original Message-
From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
Sent: Wednesday, June 05, 2013 2:00 AM
To: Insop Song
Cc: u-boot@lists.denx.de; york...@freescale.com
Subject: Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A add flag
status check during SPI Flash write
And how about this? can we add flag_status_check flag somewhere, and
if the device is needed then we set the flag during device discovery.
Then call the flag check function if the flag is set.
I think this way might be more generic then what you did in your patch.
What do you think?
Thank you,
Can u just send pseudo code about your logic, i couldn't get u exactly sorry.
Here is what I think, it is similar with your patch in the sense that do the
different status check for different device.
However, the difference is that your patch checks based on device type at the
status checking function.
Mine is proposing to add the information to the devices' struct (spi_flash)
instead, so each device can have a flexibility to call flag status check. In
this way if new device use this flag_status check, you can just hide the
setting in devices' probe function, and not worrying about updating generic
function call (spi_flash_cmd_poll_bit() as in your patch)
I am not so happy to add flag_status in struct spi_flash; so I am open to
your idea.
Please see below and let me know what you think?
// 1. adding flag status
struct spi_flash {
struct spi_slave *spi;
const char *name;
/* Total flash size */
u32 size;
/* Write (page) size */
u32 page_size;
/* Erase (sector) size */
u32 sector_size;
/* if flag_status is use or not */
u8 flag_status;
int (*read)(struct spi_flash *flash, u32 offset,
size_t len, void *buf);
int (*write)(struct spi_flash *flash, u32 offset,
size_t len, const void *buf);
int (*erase)(struct spi_flash *flash, u32 offset,
size_t len);
};
// 2. in probe function, set the flag_status per vendor
struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 * idcode)
{
flash-spi = spi;
flash-name = params-name;
flash-write = spi_flash_cmd_write_multi;
flash-erase = spi_flash_cmd_erase;
flash-read = spi_flash_cmd_read_fast;
flash-page_size = 256;
flash-sector_size = 256 * params-pages_per_sector;
flash-size = flash-sector_size * params-nr_sectors;
// we do this for Micron, and will do the same if any other device
needs this
flash-flag_status = 1;
return flash;
}
// 3. call flag status check if flash-flag_status is set
int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long timeout)
{
if (flash-flag_status)
return spi_flash_cmd_poll_bit(flash, timeout,
CMD_READ_FLAG_STATUS, STATUS_PEC, STATUS_PEC);
else
return spi_flash_cmd_poll_bit(flash, timeout,
CMD_READ_STATUS, STATUS_WIP, 0);
}
Thank you,
IS
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A add flag status check during SPI Flash write
Thank you very much for your interest on this.
What do you think?
Thank you,
Can u just send pseudo code about your logic, i couldn't get u exactly sorry.
Here is what I think, it is similar with your patch in the sense that do the
different status check for different device.
However, the difference is that your patch checks based on device type at the
status checking function.
Mine is proposing to add the information to the devices' struct (spi_flash)
instead, so each device can have a flexibility to call flag status check. In
this way if new device use this flag_status check, you can just hide the
setting in devices' probe function, and not worrying about updating generic
function call (spi_flash_cmd_poll_bit() as in your patch)
Your idea seems to be clean and reasonable, but
I am not so happy to add flag_status in struct spi_flash; so I am open to
your idea.
Please see below and let me know what you think?
// 1. adding flag status
struct spi_flash {
struct spi_slave *spi;
const char *name;
/* Total flash size */
u32 size;
/* Write (page) size */
u32 page_size;
/* Erase (sector) size */
u32 sector_size;
/* if flag_status is use or not */
u8 flag_status;
int (*read)(struct spi_flash *flash, u32 offset,
size_t len, void *buf);
int (*write)(struct spi_flash *flash, u32 offset,
size_t len, const void *buf);
int (*erase)(struct spi_flash *flash, u32 offset,
size_t len);
};
// 2. in probe function, set the flag_status per vendor
struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 * idcode)
{
flash-spi = spi;
flash-name = params-name;
flash-write = spi_flash_cmd_write_multi;
flash-erase = spi_flash_cmd_erase;
flash-read = spi_flash_cmd_read_fast;
flash-page_size = 256;
flash-sector_size = 256 * params-pages_per_sector;
flash-size = flash-sector_size * params-nr_sectors;
// we do this for Micron, and will do the same if any other device
needs this
flash-flag_status = 1;
return flash;
}
// 3. call flag status check if flash-flag_status is set
int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long timeout)
{
if (flash-flag_status)
return spi_flash_cmd_poll_bit(flash, timeout,
CMD_READ_FLAG_STATUS, STATUS_PEC, STATUS_PEC);
else
return spi_flash_cmd_poll_bit(flash, timeout,
CMD_READ_STATUS, STATUS_WIP, 0);
}
APAIK. flag status required only for stmicro flashes which has = 512MB flashes.
And as this is specific to a particular flash with particular size, i
don't see any reason to add extra variable in spi_flash
and then initialized at probe.
Your idea seems to be reasonable if we have more numbers of flash
vendors require this with respective sizes.
ie, the reason I have gave a condition for the particular state like
+ if ((flash-idcode0 == 0x20)
+ (flash-size = SPI_FLASH_512MB_STMIC))
And I have removed spi_flash_cmd_poll_bit as these is no separate
caller for this except the spi_flash_cmd_wait_ready()
and did everything on spi_flash_cmd_wait_ready().
Comments.
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/16] sf: Update sf framework to support all sizes of flashes
Request for comments. -- Thanks, Jagan. On Fri, May 31, 2013 at 6:22 PM, Jagannadha Sutradharudu Teki jagannadha.sutradharudu-t...@xilinx.com wrote: This series is v2 for the patch series sent few weeks back with a head sf: Accessing 16MBytes flashes in existing 3-byte addr mode. The current implementation in sf supports 3-byte address mode due to this up to 16MB amount of flash is able to access for those flashes which has an actual size of 16MB. This series of patches is more detailed/meatured changes w.r.t the current sf framework in addition to changes related to support all sizes using bank/exnt register addr accessing support. With these new updates on sf framework, the flashes which has 16MB are not effected as per as performance is concern and but the u-boot.bin size incrased ~600 bytes. sf update(for first 16MBytes), Changes before: U-Boot sf update 0x100 0x0 0x100 - N25Q256 16777216 bytes written, 0 bytes skipped in 199.72s, speed 86480 B/s - W25Q128BV 16777216 bytes written, 0 bytes skipped in 351.739s, speed 48913 B/s - S25FL256S_64K 16777216 bytes written, 0 bytes skipped in 65.659s, speed 262144 B/s sf update(for first 16MBytes), Changes after: U-Boot sf update 0x100 0x0 0x100 - N25Q256 16777216 bytes written, 0 bytes skipped in 198.953s, speed 86480 B/s - W25Q128BV 16777216 bytes written, 0 bytes skipped in 350.90s, speed 49200 B/s - S25FL256S_64K 16777216 bytes written, 0 bytes skipped in 66.521s, speed 262144 B/s The main aim of these changes is to not effect the current framework and at the same time to support the 16Mbyte flashes, becuase of this I involved few flash vendor people in CC [thought that they may/mayn't be a mailing list members] to know their views. REQUEST FOR ALL SPI CODE CONTRIBUTORS/USERS, PLEASE TEST THESE CHANGES W.R.T YOUR HW IF POSSIBLE. Please let me know for any issues/concerns/questions. Thanks, Jagan. Jagannadha Sutradharudu Teki (16): sf: Add bank address register writing support sf: Add bank address register reading support sf: Add extended addr write support for winbond|stmicro sf: Add extended addr read support for winbond|stmicro sf: read flash bank addr register at probe time sf: Update sf to support all sizes of flashes sf: Update sf read to support all sizes of flashes sf: Use spi_flash_addr() in write call sf: stmicro: Add support for N25Q512 sf: stmicro: Add support for N25Q512A sf: stmicro: Add support for N25Q1024 sf: stmicro: Add support for N25Q1024A sf: spansion: Add support for S25FL512S_256K sf: Use spi_flash_read_common() in write status poll sf: Remove spi_flash_cmd_poll_bit() sf: Add Flag status register polling support drivers/mtd/spi/spansion.c | 7 ++ drivers/mtd/spi/spi_flash.c | 192 +++ drivers/mtd/spi/spi_flash_internal.h | 21 +++- drivers/mtd/spi/stmicro.c| 24 + include/spi_flash.h | 4 + 5 files changed, 203 insertions(+), 45 deletions(-) -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A add flag status check during SPI Flash write
Hi Jagan,
Thank you for your feedback,
-Original Message-
From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
Sent: Wednesday, June 05, 2013 11:34 PM
To: Insop Song
Cc: u-boot@lists.denx.de; york...@freescale.com
Subject: Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A add flag
status check during SPI Flash write
Thank you very much for your interest on this.
What do you think?
Thank you,
Can u just send pseudo code about your logic, i couldn't get u exactly
sorry.
Here is what I think, it is similar with your patch in the sense that do
the
different status check for different device.
However, the difference is that your patch checks based on device type at
the status checking function.
Mine is proposing to add the information to the devices' struct
(spi_flash) instead, so each device can have a flexibility to call
flag status check. In this way if new device use this flag_status
check, you can just hide the setting in devices' probe function, and
not worrying about updating generic function call
(spi_flash_cmd_poll_bit() as in your patch)
Your idea seems to be clean and reasonable, but
I am not so happy to add flag_status in struct spi_flash; so I am open to
your idea.
Please see below and let me know what you think?
// 1. adding flag status
struct spi_flash {
struct spi_slave *spi;
const char *name;
/* Total flash size */
u32 size;
/* Write (page) size */
u32 page_size;
/* Erase (sector) size */
u32 sector_size;
/* if flag_status is use or not */
u8 flag_status;
int (*read)(struct spi_flash *flash, u32 offset,
size_t len, void *buf);
int (*write)(struct spi_flash *flash, u32 offset,
size_t len, const void *buf);
int (*erase)(struct spi_flash *flash, u32 offset,
size_t len); };
// 2. in probe function, set the flag_status per vendor
struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 *
idcode) {
flash-spi = spi;
flash-name = params-name;
flash-write = spi_flash_cmd_write_multi;
flash-erase = spi_flash_cmd_erase;
flash-read = spi_flash_cmd_read_fast;
flash-page_size = 256;
flash-sector_size = 256 * params-pages_per_sector;
flash-size = flash-sector_size * params-nr_sectors;
// we do this for Micron, and will do the same if any other device
needs
this
flash-flag_status = 1;
return flash;
}
// 3. call flag status check if flash-flag_status is set
int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long
timeout) {
if (flash-flag_status)
return spi_flash_cmd_poll_bit(flash, timeout,
CMD_READ_FLAG_STATUS, STATUS_PEC, STATUS_PEC);
else
return spi_flash_cmd_poll_bit(flash, timeout,
CMD_READ_STATUS, STATUS_WIP, 0); }
APAIK. flag status required only for stmicro flashes which has = 512MB
flashes.
And as this is specific to a particular flash with particular size, i don't
see any
reason to add extra variable in spi_flash and then initialized at probe.
Agree with you, that's why I also was not so happy to put flag_status to a
generic struct.
Your idea seems to be reasonable if we have more numbers of flash vendors
require this with respective sizes.
ie, the reason I have gave a condition for the particular state like
+ if ((flash-idcode0 == 0x20)
+ (flash-size = SPI_FLASH_512MB_STMIC))
And I have removed spi_flash_cmd_poll_bit as these is no separate caller for
this except the spi_flash_cmd_wait_ready() and did everything on
spi_flash_cmd_wait_ready().
Sounds good. I think your updated patch is coming on line now, so I will take a
look at your v2 patch and I will comment on that thread directly.
I think we could close this discussion here.
Thank you.
Insop
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
Hi Tom, On 05/06/13 16:45, Tom Rini wrote: On Wed, Jun 05, 2013 at 11:03:26AM +0300, Lubomir Popov wrote: Hi Tom, On 05/06/13 00:06, Tom Rini wrote: On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote: Hi Lokesh, Hi Lubomir, On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote: Hi Lokesh, On 30/05/13 16:19, Lokesh Vutla wrote: From: Balaji T K balaj...@ti.com add dra mmc pbias support and ldo1 power on Signed-off-by: Balaji T K balaj...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- arch/arm/include/asm/arch-omap5/omap.h |3 ++- drivers/mmc/omap_hsmmc.c | 26 ++ drivers/power/palmas.c | 25 - include/configs/omap5_common.h |4 include/configs/omap5_uevm.h |5 - include/palmas.h |6 +- 6 files changed, 49 insertions(+), 20 deletions(-) [snip] + /* set LDO9 TWL6035 to 3V */ LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above. Ok ll add the comment. + val = 0x2b; /* (3 - 0.9) * 20 + 1 */ Why not use definitions for the voltage? You could take them from http://patchwork.ozlabs.org/patch/244103/ where some values are defined. Yes, Ill rebase this patch on top of your patch and use those defines. Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline. Tom, your opinion? OK, so at the time it was nothing will really use this code except test functions. Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants. Well, I'm not quite sure that this LDO9 function would be the only one used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is set to 'Forced PWM' mode in order to reduce board noise - there sure has been a reason to do so and sacrifice converter efficiency. Therefore I added similar functionality in my patch to the Palmas driver (and am explicitly calling it in my board init). The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory as well, if hardware is designed such that the SD card socket has a separate fixed 3.3 V supply which also powers the LDO9 input (the uEVM for example). On the DRA7xx+TPS659038 board the power scheme is different and this does not apply. OK, lets see. That so lets keep your patch as-is, since we've now got -ffunction-sections/-fdata-sections/--gc-sections on ARM for main U-Boot, these small things won't hurt like they used to. OK, but then I would like to do some cleanup first - remove the audio power stuff (shall have it in my board file), as well as either sort out the function naming: - Those functions that are specific to a SoC+PMIC combination are named e.g. twl603x_... or tps659038_... so that they explicitly indicate the hardware that they are working with (actually almost all functions are such). This is however sort of regression, and requires fixes in the files calling these functions; or, alternatively: - Introduce generic functions with fixed names, palmas_bla_bla(), sort of wrappers, which in their bodies perform the appropriate action based on the #ifdefs defining the platform hardware (where we could also define the particular LDO which for example a palmas_mmc1_poweron_ldo() generic function would manipulate). Drawback: again #ifdefs. Advantage: single place where this stuff is located, and where other PMIC/LDO combinations can be added without affecting other code. And this generic palmas_mmc1_poweron_ldo() function would be called by another generic function, e.g. omap_sdmmc_poweron(), located in the board file, only if needed by the particular hardware. omap_sdmmc_poweron(), on its hand, is the function that is to be called from within the pbias routines in omap_hsmmc.c, and not the hardware- dependant functions directly. So we get the abstraction. What do you think? Lokesh, your opinion? Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A add flag status check during SPI Flash write
On Thu, Jun 6, 2013 at 12:18 PM, Insop Song insop.s...@cohere.net wrote:
Hi Jagan,
Thank you for your feedback,
-Original Message-
From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
Sent: Wednesday, June 05, 2013 11:34 PM
To: Insop Song
Cc: u-boot@lists.denx.de; york...@freescale.com
Subject: Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A add flag
status check during SPI Flash write
Thank you very much for your interest on this.
What do you think?
Thank you,
Can u just send pseudo code about your logic, i couldn't get u exactly
sorry.
Here is what I think, it is similar with your patch in the sense that do
the
different status check for different device.
However, the difference is that your patch checks based on device type at
the status checking function.
Mine is proposing to add the information to the devices' struct
(spi_flash) instead, so each device can have a flexibility to call
flag status check. In this way if new device use this flag_status
check, you can just hide the setting in devices' probe function, and
not worrying about updating generic function call
(spi_flash_cmd_poll_bit() as in your patch)
Your idea seems to be clean and reasonable, but
I am not so happy to add flag_status in struct spi_flash; so I am open to
your idea.
Please see below and let me know what you think?
// 1. adding flag status
struct spi_flash {
struct spi_slave *spi;
const char *name;
/* Total flash size */
u32 size;
/* Write (page) size */
u32 page_size;
/* Erase (sector) size */
u32 sector_size;
/* if flag_status is use or not */
u8 flag_status;
int (*read)(struct spi_flash *flash, u32 offset,
size_t len, void *buf);
int (*write)(struct spi_flash *flash, u32 offset,
size_t len, const void *buf);
int (*erase)(struct spi_flash *flash, u32 offset,
size_t len); };
// 2. in probe function, set the flag_status per vendor
struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 *
idcode) {
flash-spi = spi;
flash-name = params-name;
flash-write = spi_flash_cmd_write_multi;
flash-erase = spi_flash_cmd_erase;
flash-read = spi_flash_cmd_read_fast;
flash-page_size = 256;
flash-sector_size = 256 * params-pages_per_sector;
flash-size = flash-sector_size * params-nr_sectors;
// we do this for Micron, and will do the same if any other device
needs
this
flash-flag_status = 1;
return flash;
}
// 3. call flag status check if flash-flag_status is set
int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long
timeout) {
if (flash-flag_status)
return spi_flash_cmd_poll_bit(flash, timeout,
CMD_READ_FLAG_STATUS, STATUS_PEC, STATUS_PEC);
else
return spi_flash_cmd_poll_bit(flash, timeout,
CMD_READ_STATUS, STATUS_WIP, 0); }
APAIK. flag status required only for stmicro flashes which has = 512MB
flashes.
And as this is specific to a particular flash with particular size, i don't
see any
reason to add extra variable in spi_flash and then initialized at probe.
Agree with you, that's why I also was not so happy to put flag_status to a
generic struct.
Your idea seems to be reasonable if we have more numbers of flash vendors
require this with respective sizes.
ie, the reason I have gave a condition for the particular state like
+ if ((flash-idcode0 == 0x20)
+ (flash-size = SPI_FLASH_512MB_STMIC))
And I have removed spi_flash_cmd_poll_bit as these is no separate caller for
this except the spi_flash_cmd_wait_ready() and did everything on
spi_flash_cmd_wait_ready().
Sounds good. I think your updated patch is coming on line now, so I will take
a look at your v2 patch and I will comment on that thread directly.
I think we could close this discussion here.
Thank you.
Insop
Thank you, if possible please test with new sf framework updates.
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] imx: nitrogen6x: Enabled data cache
Hi Robert, On 06/06/2013 00:02, Robert Winkler wrote: Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com --- include/configs/nitrogen6x.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index aea91bc..07f39e9 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -276,7 +276,7 @@ #define CONFIG_OF_LIBFDT #define CONFIG_CMD_BOOTZ -#define CONFIG_SYS_DCACHE_OFF +/* #define CONFIG_SYS_DCACHE_OFF */ CONFIG_SYS_DCACHE_OFF is well documented. Do not add dead code, simply drop the line. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] vf610twr: Drop unneeded 'status' variable
On 05/06/2013 23:34, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com No need to use the 'status' variable, so just remove it. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v1: - Drop status variable board/freescale/vf610twr/vf610twr.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/board/freescale/vf610twr/vf610twr.c b/board/freescale/vf610twr/vf610twr.c index 04fa882..f14df8b 100644 --- a/board/freescale/vf610twr/vf610twr.c +++ b/board/freescale/vf610twr/vf610twr.c @@ -301,16 +301,13 @@ int board_mmc_init(bd_t *bis) NEW_PAD_CTRL(VF610_PAD_PTA28__ESDHC1_DAT2, ESDHC_PAD_CTRL), NEW_PAD_CTRL(VF610_PAD_PTA29__ESDHC1_DAT3, ESDHC_PAD_CTRL), }; - s32 status = 0; esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK); imx_iomux_v3_setup_multiple_pads( esdhc1_pads, ARRAY_SIZE(esdhc1_pads)); - status |= fsl_esdhc_initialize(bis, esdhc_cfg[0]); - - return status; + return fsl_esdhc_initialize(bis, esdhc_cfg[0]); } #endif Acked-by : Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cfi_flash: Add prototypes of overridable functions
This commit adds some prototypes into include/mtd/cfi_flash.h. These functions are defined with a weak attribute in drivers/mtd/cfi_flash.c. This means they can be overrided by board-specific ones if necessary. When defining such functions under board/ directory or somewhere, cfi_flash.h should be included. This makes sure that board-specfic cfi functions are defined in a correct prototype. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- include/mtd/cfi_flash.h | 14 ++ 1 file changed, 14 insertions(+) diff --git a/include/mtd/cfi_flash.h b/include/mtd/cfi_flash.h index b644b91..f97cf66 100644 --- a/include/mtd/cfi_flash.h +++ b/include/mtd/cfi_flash.h @@ -184,5 +184,19 @@ extern int cfi_flash_num_flash_banks; void flash_write_cmd(flash_info_t * info, flash_sect_t sect, uint offset, u32 cmd); +phys_addr_t cfi_flash_bank_addr(int i); +unsigned long cfi_flash_bank_size(int i); +void flash_cmd_reset(flash_info_t *info); + +#ifdef CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS +void flash_write8(u8 value, void *addr); +void flash_write16(u16 value, void *addr); +void flash_write32(u32 value, void *addr); +void flash_write64(u64 value, void *addr); +u8 flash_read8(void *addr); +u16 flash_read16(void *addr); +u32 flash_read32(void *addr); +u64 flash_read64(void *addr); +#endif #endif /* __CFI_FLASH_H__ */ -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] Makefile: move the common makefile line to public area
Hi, Tom, this patch has not merged to upstream? -Original Message- From: Tom Rini [mailto:tom.r...@gmail.com] On Behalf Of Tom Rini Sent: Saturday, May 25, 2013 12:05 AM To: Zhang Ying-B40530 Cc: u-boot@lists.denx.de; Wood Scott-B07421; aflem...@gmail.com; Xie Xiaobo-R63061; Zhang Ying-B40530 Subject: Re: [U-Boot] [PATCH 4/6] Makefile: move the common makefile line to public area On Mon, May 20, 2013 at 02:07:26PM +0800, ying.zh...@freescale.com wrote: From: Ying Zhang b40...@freescale.com Move the common makefile line shared by the SPL and non-SPL to the public area, so that we can avoid excessive SPL symbols. Some of them will be used by the SPL later. This patch is on top of the patch common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL. Signed-off-by: Ying Zhang b40...@freescale.com Provided that you've at least build-tested MAKEALL -a arm: Acked-by: Tom Rini tr...@ti.com -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] OMAP5: Fix bug in omap5_es1_prcm struct
Hi Tom,
On 26/05/13 23:03, Lubomir Popov wrote:
The newly introduced function setup_warmreset_time(), called
from within prcm_init(), tries to write to the prm_rsttime
OMAP5 register. The struct member holding this register's
address is however initialized for OMAP5 ES2.0 only. On ES1.0
devices this uninitialized value causes a second (warm) reset
at startup.
Add .prm_rsttime address init to the ES1.0 struct.
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V2 gives the correct prm_rsttime reg address for ES1.0. Copy-paste
from ES2.0 in V1, sorry.
arch/arm/cpu/armv7/omap5/prcm-regs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index e9f6a32..f29ac77 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -298,6 +298,7 @@ struct prcm_regs const omap5_es1_prcm = {
.cm_wkupaon_io_srcomp_clkctrl = 0x4ae07898,
.prm_rstctrl = 0x4ae07b00,
.prm_rstst = 0x4ae07b04,
+ .prm_rsttime = 0x4ae07b08,
.prm_vc_val_bypass = 0x4ae07ba0,
.prm_vc_cfg_i2c_mode = 0x4ae07bb4,
.prm_vc_cfg_i2c_clk = 0x4ae07bb8,
Could you please apply http://patchwork.ozlabs.org/patch/246454/
to the ti tree? This is the only obstacle for my board to boot
normally with a clean u-boot-ti in respect to the OMAP5 common
stuff.
Thanks,
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ASM code for UART initialization
Hi, could someone support me with developing ASM code for initializing UART interface on OMAP4460 to send some bytes over the wire at a very early stage of booting x-loader? The code needs to be executed in start.S. Is it possible to use existing C code and use the generated assembly from gcc as the actual code or does it need major modifications to be executed in start.S? Thanks in advance. Regards, André ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cfi_flash: Add prototypes of overridable functions
Dear Masahiro Yamada, In message 1370505244-5015-1-git-send-email-yamad...@jp.panasonic.com you wrote: This commit adds some prototypes into include/mtd/cfi_flash.h. These functions are defined with a weak attribute in drivers/mtd/cfi_flash.c. This means they can be overrided by board-specific ones if necessary. When defining such functions under board/ directory or somewhere, cfi_flash.h should be included. This makes sure that board-specfic cfi functions are defined in a correct prototype. As is, this would just add dead code. Please resubmit this with any patch that would actually make use of this feature. this would also allow us to understand why this approch is needed at all. +#ifdef CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS When resubmitting, please keep in mind that new CONFIG_* options like this must be documented in the README. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Here is an Appalachian version of management's answer to those who are concerned with the fate of the project: Don't worry about the mule. Just load the wagon. - Mike Dennison's hillbilly uncle ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] power: exynos-tmu: fix warnings and clean up code
On 23 April 2013 08:08, Simon Glass s...@chromium.org wrote: On Fri, Apr 12, 2013 at 9:43 PM, Naveen Krishna Ch naveenkrishna...@gmail.com wrote: On 6 April 2013 03:51, Naveen Krishna Chatradhi naveenkrishna...@gmail.com wrote: From: Naveen Krishna Chatradhi ch.nav...@samsung.com This patch does the folowing 1. change the data types for unsigned int variable to unsigned 2. change the tmu_base type to struct exynos5_tmu_reg * 3. Add timer functionality for get_cur_temp() 4. error handling in the get_tmu_fdt_values() 5. Add check for curr_temp reading 6. some cosmotic changes. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Reviewed-by: Vadim Bendebury vben...@google.com Acked-by: Simon Glass s...@chromium.org Hello Minkyu, Are you waiting for any review comments on this. Do i need to rebase this patch ?? -- Shine bright, (: Nav :) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Micron eMMC problem on sabre SD like card
Hi, On Sat, May 25, 2013 at 8:32 AM, jean-francois simon j...@themis.com wrote: We have a new design that is based on Freescale SABRE SD card. We see that accesses made to the eMMC (Micron MTFC64GJVDN-4M ) are not working. We have placed the eMMC on SD3 (SD4 on Sabre SD). We want to use it in 8bit bus width, DDR, fast speed. The very first command sent to the device hangs. The hang happens in this function, when the mmc driver is waiting for an interrupt to occur: Still stuck on this. A naive question: Does u-boot mmc driver support dual data rate? I am not sure looking at the code. I see mentions of version 4.4 and higher, but nothing about DDR. I am very ignorant of MMC stuff and even looking at the jedec 4.4 spec, I am not sure if 4.4 support means DDR is mandatory. I saw this u-boot thread: http://www.mail-archive.com/u-boot@lists.denx.de/msg78023.html and I wonder it is still the same situation? If we hack the Freescale 2009 u-boot to make it run on our design, the eMMC works just fine. What should I do? start from Freescale driver and try to port it to u-boot? I am kind in the dark here , looking which way to go. Thanks for any help, -jfs ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ASM code for UART initialization
Dear André Schaller, In message 51b05614.8070...@googlemail.com you wrote: could someone support me with developing ASM code for initializing UART interface on OMAP4460 to send some bytes over the wire at a very early stage of booting x-loader? The code needs to be executed in start.S. Why would you not just use C code? Is it possible to use existing C code and use the generated assembly from gcc as the actual code or does it need major modifications to be executed in start.S? It should be possible - but you should ask yourself what you then prevents from using C code instead? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de They weren't that important. They were merely at the top. The people who really run organizations are usually found several levels down, where it's still possible to get things done. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx: Vybrid VF610 mac address issue
Hi Alison, On Thursday, June 6, 2013 5:36:23 AM, Wang Huan-B18965 wrote: Hi, Benoit, -Original Message- From: Benoît Thébaudeau [mailto:benoit.thebaud...@advansee.com] Sent: Thursday, June 06, 2013 5:46 AM To: Fabio Estevam Cc: Andy Voltz; u-boot@lists.denx.de; Stefano Babic; Wang Huan-B18965 Subject: Re: [U-Boot] imx: Vybrid VF610 mac address issue On Wednesday, June 5, 2013 11:16:17 PM, Benoît Thébaudeau wrote: Hi Andy, Fabio, On Wednesday, June 5, 2013 11:13:52 PM, Fabio Estevam wrote: Hi Andy, On Wed, Jun 5, 2013 at 5:54 PM, Andy Voltz andy.vo...@timesys.com wrote: I recently tried booting the VF610 support on the Tower board, but the mac address is reversed in Linux userspace. DHCP/BOOTP seems to work properly in u-boot. I'm booting this kernel: https://github.com/Timesys/linux-timesys/ ref: 2c4ead2dd6da019f5052a69b12c8f5b6b71f8dca I haven't yet seen how the address is passed to the kernel, but our previous u-boot support does not have this issue with the same kernel. That u-boot branch is also on our github. The MAC address is read in the imx_get_mac_from_fuse() function in arch/arm/cpu/armv7/vf610/generic.c Try printing all the elements of mac[] array in this function and check if the logic is correct there. You probably had programmed the fuses with a MAC address on your board, and then replaced the existing U-Boot with the mainline version. These 2 U-Boot-s may interpret the MAC fuses in a different way. Especially, note that VF610 interprets the MAC fuses with reversed endianness compared to i.MX6 in mainline U-Boot. This is documented in doc/README.SoC. There may be the same difference between VF610 in mainline U-Boot and the other version of U-Boot that you used first. But if there is such a difference between U-Boot editions, it might be worth considering to make mainline U-Boot more consistent with Freescale's or others' before it is too much widespread. It is especially important if people change the U-Boot edition on their board. Stefano, Alison, what do you think? Alison, have you checked if your implementation in mainline is consistent with Freescale's? There may be a difference both for which fuse word is used for high/low parts of the MAC address (i.e. word- level endianness that I was talking about above), and for the byte- level endianness inside each fuse word. [Alison Wang] Thanks for your comments. In Vybrid's RM, there is no specific descriptions about how to program the mac address in the OTP Bank4 Word2(OCOTP_MAC0) and OTP Bank4 Word3(OCOTP_MAC1). So I think it is not formulary which fuse word is used for high/low parts of the MAC address (i.e. word-level endianness), and for the byte-level endianness inside each fuse word. Through reading the doc/README.vf610, I think the user could program the fuses correctly. I agree. I only had a concern if Freescale had released a VF610 BSP requiring the MAC fuses to be programmed in a different way. According to what you said in your previous e-mail, this is not the case, so everything is fine in mainline. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cfi_flash: Add prototypes of overridable functions
Hello, Wolfgang Denk. As is, this would just add dead code. Please resubmit this with any patch that would actually make use of this feature. this would also allow us to understand why this approch is needed at all. I'm not sure this is the best approach, but these overrides are actually used by some boards. I don't know very much about other companies, but I can explain how this override is being used for our boards in my company. (Our board is not public. Only used inside Panasonic for LSI debug. The board specific code is not posted yet.) Our boards have very flexible memory slots. We can use both SRAM and NOR flash for this slots and change base address easily. So we probe NOR flash and configure base address at boot time, not compile time. For this purpose, we override cfi_flash_bank_addr function with our own. When I see board/lwmon5/lwmon5.c, this feature seems to be used for similar purpose. +#ifdef CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS When resubmitting, please keep in mind that new CONFIG_* options like this must be documented in the README. CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS seems to be introduced by the following commit. I added Stefan in CC. commit 45aa5a7f4d5bcb79927ddfc896c1d7c4326e235d Author: Stefan Roese s...@denx.de Date: Mon Nov 17 14:45:22 2008 +0100 cfi_flash: Make all flash access functions weak This patch defines all flash access functions as weak so that they can be overridden by board specific versions. This will be used by the upcoming VCTH board support where the NOR FLASH unfortunately can't be accessed memory-mapped. Special accessor functions are needed here. To enable this weak functions you need to define CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS in your board config header. Otherwise the old default functions will be used resulting in smaller code. Signed-off-by: Stefan Roese s...@denx.de Acked-by: Haavard Skinnemoen haavard.skinnem...@atmel.com Best Regards Masahiro Yamada On Thu, 06 Jun 2013 12:02:56 +0200 Wolfgang Denk w...@denx.de wrote: Dear Masahiro Yamada, In message 1370505244-5015-1-git-send-email-yamad...@jp.panasonic.com you wrote: This commit adds some prototypes into include/mtd/cfi_flash.h. These functions are defined with a weak attribute in drivers/mtd/cfi_flash.c. This means they can be overrided by board-specific ones if necessary. When defining such functions under board/ directory or somewhere, cfi_flash.h should be included. This makes sure that board-specfic cfi functions are defined in a correct prototype. As is, this would just add dead code. Please resubmit this with any patch that would actually make use of this feature. this would also allow us to understand why this approch is needed at all. +#ifdef CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS When resubmitting, please keep in mind that new CONFIG_* options like this must be documented in the README. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Here is an Appalachian version of management's answer to those who are concerned with the fate of the project: Don't worry about the mule. Just load the wagon. - Mike Dennison's hillbilly uncle -- パナソニック（株） システムLSIビジネスユニット 第二事業ディビジョン 開発グループ 第三開発チーム 山田 真弘 yamad...@jp.panasonic.com 〒617-8520 京都府長岡京市神足焼町1番地 外線 : 050-3783-5420 内線 : 7-664-2813, 社内ポスト: 664-772 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
Hi Lubomir, On Thursday 06 June 2013 12:55 PM, Lubomir Popov wrote: Hi Tom, On 05/06/13 16:45, Tom Rini wrote: On Wed, Jun 05, 2013 at 11:03:26AM +0300, Lubomir Popov wrote: Hi Tom, On 05/06/13 00:06, Tom Rini wrote: On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote: Hi Lokesh, Hi Lubomir, On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote: Hi Lokesh, On 30/05/13 16:19, Lokesh Vutla wrote: From: Balaji T K balaj...@ti.com add dra mmc pbias support and ldo1 power on Signed-off-by: Balaji T K balaj...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- arch/arm/include/asm/arch-omap5/omap.h |3 ++- drivers/mmc/omap_hsmmc.c | 26 ++ drivers/power/palmas.c | 25 - include/configs/omap5_common.h |4 include/configs/omap5_uevm.h |5 - include/palmas.h |6 +- 6 files changed, 49 insertions(+), 20 deletions(-) [snip] + /* set LDO9 TWL6035 to 3V */ LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above. Ok ll add the comment. + val = 0x2b; /* (3 - 0.9) * 20 + 1 */ Why not use definitions for the voltage? You could take them from http://patchwork.ozlabs.org/patch/244103/ where some values are defined. Yes, Ill rebase this patch on top of your patch and use those defines. Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline. Tom, your opinion? OK, so at the time it was nothing will really use this code except test functions. Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants. Well, I'm not quite sure that this LDO9 function would be the only one used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is set to 'Forced PWM' mode in order to reduce board noise - there sure has been a reason to do so and sacrifice converter efficiency. Therefore I added similar functionality in my patch to the Palmas driver (and am explicitly calling it in my board init). The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory as well, if hardware is designed such that the SD card socket has a separate fixed 3.3 V supply which also powers the LDO9 input (the uEVM for example). On the DRA7xx+TPS659038 board the power scheme is different and this does not apply. OK, lets see. That so lets keep your patch as-is, since we've now got -ffunction-sections/-fdata-sections/--gc-sections on ARM for main U-Boot, these small things won't hurt like they used to. OK, but then I would like to do some cleanup first - remove the audio power stuff (shall have it in my board file), as well as either sort out the function naming: - Those functions that are specific to a SoC+PMIC combination are named e.g. twl603x_... or tps659038_... so that they explicitly indicate the hardware that they are working with (actually almost all functions are such). This is however sort of regression, and requires fixes in the files calling these functions; or, alternatively: - Introduce generic functions with fixed names, palmas_bla_bla(), sort of wrappers, which in their bodies perform the appropriate action based on the #ifdefs defining the platform hardware (where we could also define the particular LDO which for example a palmas_mmc1_poweron_ldo() generic function would manipulate). Drawback: again #ifdefs. Advantage: single place where this stuff is located, and where other PMIC/LDO combinations can be added without affecting other code. I think, we can have function pointers for and can populate data in the beginning or from board file based on Soc, similarly what we did for prcm structure. Regards, Lokesh And this generic palmas_mmc1_poweron_ldo() function would be called by another generic function, e.g. omap_sdmmc_poweron(), located in the board file, only if needed by the particular hardware. omap_sdmmc_poweron(), on its hand, is the function that is to be called from within the pbias routines in omap_hsmmc.c, and not the hardware- dependant functions directly. So we get the abstraction. What do you think? Lokesh, your opinion? Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 00/12] ARM: DRA7xx: Update support for DRA7xx Soc's
Hi Tom, On Thursday 30 May 2013 06:49 PM, Lokesh Vutla wrote: This series update support for DRA7xx family Socs and the data for DRA752 ES1.0 soc. This is on top of my recent Misc cleanup series: http://u-boot.10912.n7.nabble.com/PATCH-V2-0-4-ARM-OMAP2-Misc-Cleanup-tt155949.html Do you have any further comments on this series ? Thanks and regards, Lokesh Testing: Boot tested on DRA752 ES1.0, OMAP5432 ES2.0, OMAP4460 PANDA Verified MAKEALL for armv7 and omap boards. Changes from v1: * Addressed comments from Tom Rini Balaji T K (1): mmc: omap_hsmmc: add mmc1 pbias, ldo1 Lokesh Vutla (6): ARM: DRA7xx: Add control id code for DRA7xx ARM: DRA7xx: power Add support for tps659038 PMIC ARM: DRA7xx: clocks: Fixing i2c_init for PMIC ARM: DRA7xx: Do not enable srcomp for DRA7xx Soc's ARM: DRA7xx: Update pinmux data ARM: DRA7xx: clocks: Update PLL values Nishanth Menon (1): ARM: OMAP5: DRA7xx: support class 0 optimized voltages Sricharan R (4): ARM: DRA7xx: Change the Debug UART to UART1 ARM: DRA7xx: Correct the SYS_CLK to 20MHZ ARM: DRA7xx: Correct SRAM END address ARM: DRA7xx: EMIF: Change settings required for EVM board arch/arm/cpu/armv7/omap-common/clocks-common.c | 86 +--- arch/arm/cpu/armv7/omap-common/emif-common.c | 26 +++- arch/arm/cpu/armv7/omap-common/hwinit-common.c |2 - arch/arm/cpu/armv7/omap-common/timer.c |1 + arch/arm/cpu/armv7/omap5/hw_data.c | 156 -- arch/arm/cpu/armv7/omap5/hwinit.c | 22 ++- arch/arm/cpu/armv7/omap5/prcm-regs.c |2 + arch/arm/cpu/armv7/omap5/sdram.c | 170 ++-- arch/arm/include/asm/arch-omap4/clock.h|6 +- arch/arm/include/asm/arch-omap4/sys_proto.h|1 + arch/arm/include/asm/arch-omap5/clock.h| 61 - arch/arm/include/asm/arch-omap5/mux_dra7xx.h |7 +- arch/arm/include/asm/arch-omap5/omap.h | 26 ++-- arch/arm/include/asm/arch-omap5/sys_proto.h|1 + arch/arm/include/asm/emif.h| 12 +- arch/arm/include/asm/omap_common.h | 26 +++- board/ti/dra7xx/mux_data.h | 38 -- drivers/mmc/omap_hsmmc.c | 26 ++-- drivers/power/palmas.c | 25 +++- include/configs/dra7xx_evm.h |8 +- include/configs/omap4_common.h |4 - include/configs/omap5_common.h | 12 +- include/configs/omap5_uevm.h |7 +- include/palmas.h |6 +- 24 files changed, 590 insertions(+), 141 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
Hi Lokesh, On 06/06/13 14:26, Lokesh Vutla wrote: Hi Lubomir, On Thursday 06 June 2013 12:55 PM, Lubomir Popov wrote: Hi Tom, On 05/06/13 16:45, Tom Rini wrote: On Wed, Jun 05, 2013 at 11:03:26AM +0300, Lubomir Popov wrote: [snip] OK, lets see. That so lets keep your patch as-is, since we've now got -ffunction-sections/-fdata-sections/--gc-sections on ARM for main U-Boot, these small things won't hurt like they used to. OK, but then I would like to do some cleanup first - remove the audio power stuff (shall have it in my board file), as well as either sort out the function naming: - Those functions that are specific to a SoC+PMIC combination are named e.g. twl603x_... or tps659038_... so that they explicitly indicate the hardware that they are working with (actually almost all functions are such). This is however sort of regression, and requires fixes in the files calling these functions; or, alternatively: - Introduce generic functions with fixed names, palmas_bla_bla(), sort of wrappers, which in their bodies perform the appropriate action based on the #ifdefs defining the platform hardware (where we could also define the particular LDO which for example a palmas_mmc1_poweron_ldo() generic function would manipulate). Drawback: again #ifdefs. Advantage: single place where this stuff is located, and where other PMIC/LDO combinations can be added without affecting other code. I think, we can have function pointers for and can populate data in the beginning or from board file based on Soc, similarly what we did for prcm structure. Regards, Lokesh OK, sounds reasonable. I think this should be done in a future release however, after careful investigation and planning. At present, I guess, we are staying with the current situation. Today I shall submit an updated version of my patch to the palmas driver - sort of compromise between clean code and ease of use. I have included your stuff there, so should work out of the box on the dra7xx_evm. Please note that now we have a semi-generic function to power on the appropriate SDMMC LDO: the old palmas_mmc1_poweron_ldo(), which you shall have to call in omap_hsmmc. Differentiation of which particular LDO to control within which PMIC is done in driver, based on the board #ifdefs. If Tom approves this patch and applies it, we shall all be happy with working boards, although the code may not be perfect. I would also like to ask you to send me a Register Manual of the TPS659038/9, if possible. If you have any NDA concerns, then just check if the LDO1 control register has a BYPASS option and tell me. Thanks. Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3] ARM: OMAP5: Power: Add more functionality to Palmas driver
Add some useful functions, and the corresponding definitions.
Add support for powering on the dra7xx_evm SD/MMC LDO
(courtesy Lokesh Vutla lokeshvu...@ti.com).
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V3 does some cleanup and adds support for the dra7xx_evm
board (power on LDO1 used for the SD/MMC interface).
V2 aligns to changed PMIC name (and file names accordingly)
from twl6035 to Palmas and is based on current u-boot-ti
master.
drivers/power/palmas.c | 130 +++-
include/palmas.h | 90 ++---
2 files changed, 201 insertions(+), 19 deletions(-)
diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c
index 09c832d..6c60b5f 100644
--- a/drivers/power/palmas.c
+++ b/drivers/power/palmas.c
@@ -25,28 +25,134 @@
void palmas_init_settings(void)
{
- return;
+#ifdef CONFIG_PALMAS_SMPS7_FPWM
+ int err;
+ /*
+* Set SMPS7 (1.8 V I/O supply on platforms with TWL6035/37) to
+* forced PWM mode. This reduces noise (but affects efficiency).
+*/
+ u8 val = SMPS_MODE_SLP_FPWM | SMPS_MODE_ACT_FPWM;
+ if ((err = palmas_i2c_write_u8(TWL603X_CHIP_P1, SMPS7_CTRL, val)))
+ printf(palmas: could not force PWM for SMPS7: err = %d\n,
+ err);
+#endif
}
int palmas_mmc1_poweron_ldo(void)
{
u8 val = 0;
- /* set LDO9 TWL6035 to 3V */
- val = 0x2b; /* (3 -.9)*28 +1 */
-
- if (palmas_i2c_write_u8(0x48, LDO9_VOLTAGE, val)) {
- printf(twl6035: could not set LDO9 voltage.\n);
+#if defined(CONFIG_DRA7XX)
+ /*
+* Currently valid for the dra7xx_evm board:
+* Set TPS659038 LDO1 to 3.0 V
+*/
+ val = LDO_VOLT_3V0;
+ if (palmas_i2c_write_u8(TPS65903X_CHIP_P1, LDO1_VOLTAGE, val)) {
+ printf(tps65903x: could not set LDO1 voltage.\n);
+ return 1;
+ }
+ /* TURN ON LDO1 */
+ val = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ if (palmas_i2c_write_u8(TPS65903X_CHIP_P1, LDO1_CTRL, val)) {
+ printf(tps65903x: could not turn on LDO1.\n);
return 1;
}
+ return 0;
+#else
+ /*
+* We assume that this is a OMAP543X + TWL603X board:
+* Set TWL6035/37 LDO9 to 3.0 V
+*/
+ val = LDO_VOLT_3V0;
+ return twl603x_mmc1_set_ldo9(val);
+#endif
+}
- /* TURN ON LDO9 */
- val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
+/*
+ * On some OMAP5 + TWL603X hardware the SD card socket and LDO9_IN are
+ * powered by an external 3.3 V regulator, while the output of LDO9
+ * supplies VDDS_SDCARD for the OMAP5 interface only. This implies that
+ * LDO9 could be set to 'bypass' mode when required (e.g. for 3.3 V cards).
+ */
+int twl603x_mmc1_set_ldo9(u8 vsel)
+{
+ u8 cval=0, vval=0; /* Off by default */
+ int err;
- if (palmas_i2c_write_u8(0x48, LDO9_CTRL, val)) {
- printf(twl6035: could not turn on LDO9.\n);
- return 1;
+ if (vsel) {
+ /* Turn on */
+ if (vsel LDO_VOLT_3V3) {
+ /* Put LDO9 in bypass */
+ cval = LDO9_BYP_EN | RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ vval = LDO_VOLT_3V3;
+ }
+ else {
+ cval = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ vval = vsel 0x3f;
+ }
+ }
+ if ((err = palmas_i2c_write_u8(TWL603X_CHIP_P1, LDO9_VOLTAGE, vval))) {
+ printf(twl603x: could not set LDO9 %s: err = %d\n,
+ vsel LDO_VOLT_3V3 ? bypass : voltage, err);
+ return err;
}
+ if ((err = palmas_i2c_write_u8(TWL603X_CHIP_P1, LDO9_CTRL, cval)))
+ printf(twl603x: could not turn %s LDO9: err = %d\n,
+ cval ? on : off, err);
+ return err;
+}
- return 0;
+#ifdef CONFIG_PALMAS_AUDPWR
+/*
+ * Turn audio codec power and 32 kHz clock on/off. Use for
+ * testing OMAP543X + TWL603X + TWL604X boards only.
+ */
+int twl603x_audio_power(u8 on)
+{
+ u8 cval=0, vval=0, c32k=0;
+ int err;
+
+ if (on) {
+ vval = SMPS_VOLT_2V1;
+ cval = SMPS_MODE_SLP_AUTO | SMPS_MODE_ACT_AUTO;
+ c32k = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ }
+ /* Set SMPS9 to 2.1 V (for TWL604x), or to 0 (off) */
+ if ((err = palmas_i2c_write_u8(TWL603X_CHIP_P1, SMPS9_VOLTAGE,
+ vval))) {
+ printf(twl603x: could not set SMPS9 voltage: err = %d\n,
+ err);
+ return err;
+ }
+ /* Turn on or off SMPS9 */
+ if ((err = palmas_i2c_write_u8(TWL603X_CHIP_P1, SMPS9_CTRL, cval))) {
+ printf(twl603x: could not turn SMPS9 %s: err = %d\n,
+ cval ? on : off, err);
+
[U-Boot] [PATCH] am33xx/omap4+: Move SRAM_SCRATCH_SPACE_ADDR to asm/arch/omap.h
The location of valid scratch space is dependent on SoC, so move that
there. On OMAP4+ we continue to use SRAM_SCRATCH_SPACE_ADDR. On
am33xx/ti814x we want to use what the ROM defines as public stack
which is the area after our defined download image space. Correct the
comment about and location of CONFIG_SPL_TEXT_BASE.
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/include/asm/arch-am33xx/omap.h |2 ++
arch/arm/include/asm/arch-omap4/omap.h |1 +
arch/arm/include/asm/arch-omap5/omap.h |1 +
arch/arm/include/asm/omap_common.h |1 -
include/configs/am335x_evm.h|5 ++---
include/configs/igep0033.h |5 ++---
include/configs/pcm051.h|5 ++---
7 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/include/asm/arch-am33xx/omap.h
b/arch/arm/include/asm/arch-am33xx/omap.h
index db15159..e7576c1 100644
--- a/arch/arm/include/asm/arch-am33xx/omap.h
+++ b/arch/arm/include/asm/arch-am33xx/omap.h
@@ -31,8 +31,10 @@
#ifdef CONFIG_AM33XX
#define NON_SECURE_SRAM_START 0x402F0400
#define NON_SECURE_SRAM_END0x4031
+#define SRAM_SCRATCH_SPACE_ADDR0x4030C000
#elif defined(CONFIG_TI814X)
#define NON_SECURE_SRAM_START 0x4030
#define NON_SECURE_SRAM_END0x4032
+#define SRAM_SCRATCH_SPACE_ADDR0x4031B800
#endif
#endif
diff --git a/arch/arm/include/asm/arch-omap4/omap.h
b/arch/arm/include/asm/arch-omap4/omap.h
index e9a6ffe..44353a4 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -141,6 +141,7 @@ struct s32ktimer {
*/
#define NON_SECURE_SRAM_START 0x40304000
#define NON_SECURE_SRAM_END0x4030E000 /* Not inclusive */
+#define SRAM_SCRATCH_SPACE_ADDRNON_SECURE_SRAM_START
/* base address for indirect vectors (internal boot mode) */
#define SRAM_ROM_VECT_BASE 0x4030D000
#endif
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 4f43a90..04af227 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -188,6 +188,7 @@ struct s32ktimer {
*/
#define NON_SECURE_SRAM_START 0x4030
#define NON_SECURE_SRAM_END0x4032 /* Not inclusive */
+#define SRAM_SCRATCH_SPACE_ADDRNON_SECURE_SRAM_START
/* base address for indirect vectors (internal boot mode) */
#define SRAM_ROM_VECT_BASE 0x4031F000
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index ee7b188..baeef4e 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -591,7 +591,6 @@ static inline u32 omap_revision(void)
/*
* SRAM scratch space entries
*/
-#define SRAM_SCRATCH_SPACE_ADDRNON_SECURE_SRAM_START
#define OMAP_SRAM_SCRATCH_OMAP_REV SRAM_SCRATCH_SPACE_ADDR
#define OMAP_SRAM_SCRATCH_EMIF_SIZE(SRAM_SCRATCH_SPACE_ADDR + 0x4)
#define OMAP_SRAM_SCRATCH_EMIF_T_NUM (SRAM_SCRATCH_SPACE_ADDR + 0xC)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index b286ffc..cd2c078 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -306,12 +306,11 @@
#define CONFIG_SPL
#define CONFIG_SPL_FRAMEWORK
/*
- * Place the image at the start of the ROM defined image space and leave
- * space for SRAM scratch entries (see arch/arm/include/omap_common.h).
+ * Place the image at the start of the ROM defined image space.
* We limit our size to the ROM-defined downloaded image area, and use the
* rest of the space for stack.
*/
-#define CONFIG_SPL_TEXT_BASE 0x402F0500
+#define CONFIG_SPL_TEXT_BASE 0x402F0400
#define CONFIG_SPL_MAX_SIZE(0x4030C000 - CONFIG_SPL_TEXT_BASE)
#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
diff --git a/include/configs/igep0033.h b/include/configs/igep0033.h
index afbd549..12f28f8 100644
--- a/include/configs/igep0033.h
+++ b/include/configs/igep0033.h
@@ -215,12 +215,11 @@
#define CONFIG_SPL
#define CONFIG_SPL_FRAMEWORK
/*
- * Place the image at the start of the ROM defined image space and leave
- * space for SRAM scratch entries (see arch/arm/include/omap_common.h).
+ * Place the image at the start of the ROM defined image space.
* We limit our size to the ROM-defined downloaded image area, and use the
* rest of the space for stack.
*/
-#define CONFIG_SPL_TEXT_BASE 0x402F0500
+#define CONFIG_SPL_TEXT_BASE 0x402F0400
#define CONFIG_SPL_MAX_SIZE(0x4030C000 - CONFIG_SPL_TEXT_BASE)
#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h
index 3480302..2ecd105 100644
--- a/include/configs/pcm051.h
+++ b/include/configs/pcm051.h
@@ -205,12 +205,11 @@
#define CONFIG_SPL
#define CONFIG_SPL_FRAMEWORK
/*
- * Place the image at the start of the ROM defined image space and leave
- * space for SRAM scratch entries (see
Re: [U-Boot] [PATCH V2 00/12] ARM: DRA7xx: Update support for DRA7xx Soc's
On Thu, Jun 06, 2013 at 04:58:44PM +0530, Lokesh Vutla wrote: Hi Tom, On Thursday 30 May 2013 06:49 PM, Lokesh Vutla wrote: This series update support for DRA7xx family Socs and the data for DRA752 ES1.0 soc. This is on top of my recent Misc cleanup series: http://u-boot.10912.n7.nabble.com/PATCH-V2-0-4-ARM-OMAP2-Misc-Cleanup-tt155949.html Do you have any further comments on this series ? Sorry, everything looks good, and I think Lubomir's patch for MMC stuff (which means we drop 9/12 here, right?) should settle everything else out. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] checkpatch.pl: Add 'printf' to logFunctions
Signed-off-by: Tom Rini tr...@ti.com
---
tools/checkpatch.pl |1 +
1 file changed, 1 insertion(+)
diff --git a/tools/checkpatch.pl b/tools/checkpatch.pl
index 9f23901..896e2bc 100755
--- a/tools/checkpatch.pl
+++ b/tools/checkpatch.pl
@@ -273,6 +273,7 @@ our $logFunctions = qr{(?x:
WARN(?:_RATELIMIT|_ONCE|)|
panic|
debug|
+ printf|
MODULE_[A-Z_]+
)};
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] ARM: OMAP5: Power: Add more functionality to Palmas driver
On Thu, Jun 06, 2013 at 04:11:32PM +0300, Lubomir Popov wrote: Add some useful functions, and the corresponding definitions. Add support for powering on the dra7xx_evm SD/MMC LDO (courtesy Lokesh Vutla lokeshvu...@ti.com). Signed-off-by: Lubomir Popov lpo...@mm-sol.com After patching checkpatch.pl to know that printf is a logFunction for us, I see: total: 13 errors, 0 warnings, 1 checks, 251 lines checked Including some serious looking ones about doing if ((err = fn())) which while I think you have the parens right such that err is tested, not the assignment of err by fn(), is still not a good thing to do. Functionality wise, I'm happy with it, and we can review where further abstractions are needed once we have a 3rd example. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Micron eMMC problem on sabre SD like card
Hi Jean-Francois, On 25/05/2013 17:32, jean-francois simon wrote: Hi, We have a new design that is based on Freescale SABRE SD card. We see that accesses made to the eMMC (Micron MTFC64GJVDN-4M ) are not working. We have placed the eMMC on SD3 (SD4 on Sabre SD). We want to use it in 8bit bus width, DDR, fast speed. The very first command sent to the device hangs. The hang happens in this function, when the mmc driver is waiting for an interrupt to occur: drivers/mmc/fsl_esdhc.c::esdhc_send_cmd() ..snip /* Send the command */ esdhc_write32(regs-cmdarg, cmd-cmdarg); #if defined(CONFIG_FSL_USDHC) esdhc_write32(regs-mixctrl, (esdhc_read32(regs-mixctrl) 0xFF80) | (xfertyp 0x7F)); esdhc_write32(regs-xfertyp, xfertyp 0x); #else esdhc_write32(regs-xfertyp, xfertyp); #endif /* Mask all irqs */ esdhc_write32(regs-irqsigen, 0); /* Wait for the command to complete */ while (!(esdhc_read32(regs-irqstat) (IRQSTAT_CC | IRQSTAT_CTOE)))HANGS HERE Could be the same as the issue reported by Fabio at http://patchwork.ozlabs.org/patch/246928/ ? Patch is not yet mainline, so I assume that it does not work. You could make a test using u-boot-imx (git.denx.de/u-boot-imx) instead of u-boot TOT. Due to this issue I have not yet merged back the mainline tree. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 00/12] ARM: DRA7xx: Update support for DRA7xx Soc's
Hi Tom, On 06/06/13 16:26, Tom Rini wrote: On Thu, Jun 06, 2013 at 04:58:44PM +0530, Lokesh Vutla wrote: Hi Tom, On Thursday 30 May 2013 06:49 PM, Lokesh Vutla wrote: This series update support for DRA7xx family Socs and the data for DRA752 ES1.0 soc. This is on top of my recent Misc cleanup series: http://u-boot.10912.n7.nabble.com/PATCH-V2-0-4-ARM-OMAP2-Misc-Cleanup-tt155949.html Do you have any further comments on this series ? Sorry, everything looks good, and I think Lubomir's patch for MMC stuff (which means we drop 9/12 here, right?) should settle everything else out. Please be aware that my patch (latest in http://patchwork.ozlabs.org/patch/249405/) fixes the two palmas.* files only, while Lokesh's patch 9/12 affected 6 files in total (including these two). Lokesh, unfortunately you shall have to repost 9/12 after rebasing over my stuff, if it is applied. Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Micron eMMC problem on sabre SD like card
Hi Jean-Francois, On Thu, Jun 6, 2013 at 10:34 AM, Stefano Babic sba...@denx.de wrote: Could be the same as the issue reported by Fabio at http://patchwork.ozlabs.org/patch/246928/ ? Yes, please apply this one and also: http://patchwork.ozlabs.org/patch/248877/ With both patches applied SD functionality works well on mx6qsabresd. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] Makefile: move the common makefile line to public area
On Thu, Jun 06, 2013 at 08:51:34AM +, Zhang Ying-B40530 wrote: Hi, Tom, this patch has not merged to upstream? I assume that, so long as ARM has been build tested, it will come via one of the powerpc trees along with the rest of the series. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] ARM: imx: Fix incorrect usage of CONFIG_SYS_MMC_ENV_PART
On 05/06/2013 03:05, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com When running the save command several times on a mx6qsabresd we see: U-Boot save Saving Environment to MMC... Writing to MMC(1)... done U-Boot save Saving Environment to MMC... MMC partition switch failed U-Boot save Saving Environment to MMC... Writing to MMC(1)... done U-Boot save Saving Environment to MMC... MMC partition switch failed U-Boot save Saving Environment to MMC... Writing to MMC(1)... done U-Boot save Saving Environment to MMC... MMC partition switch failed This issue is caused by the incorrect usage of CONFIG_SYS_MMC_ENV_PART. CONFIG_SYS_MMC_ENV_PART should be used to specify the mmc partition that stores the environment variables. On some imx boards it is been incorrectly used to pass the partition of kernel and dtb files for the 'mmcpart' script variable. Remove the CONFIG_SYS_MMC_ENV_PART usage and configure the 'mmcpart' variable directly. Reported-by: Jason Liu r64...@freescale.com Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 00/12] ARM: DRA7xx: Update support for DRA7xx Soc's
Hi, On Thursday 06 June 2013 07:07 PM, Lubomir Popov wrote: Hi Tom, On 06/06/13 16:26, Tom Rini wrote: On Thu, Jun 06, 2013 at 04:58:44PM +0530, Lokesh Vutla wrote: Hi Tom, On Thursday 30 May 2013 06:49 PM, Lokesh Vutla wrote: This series update support for DRA7xx family Socs and the data for DRA752 ES1.0 soc. This is on top of my recent Misc cleanup series: http://u-boot.10912.n7.nabble.com/PATCH-V2-0-4-ARM-OMAP2-Misc-Cleanup-tt155949.html Do you have any further comments on this series ? Sorry, everything looks good, and I think Lubomir's patch for MMC stuff (which means we drop 9/12 here, right?) should settle everything else out. Please be aware that my patch (latest in http://patchwork.ozlabs.org/patch/249405/) fixes the two palmas.* files only, while Lokesh's patch 9/12 affected 6 files in total (including these two). Yes Lubomir, you are correct. The patch 9/12 from Balaji , also includes a programming sequence update for pbias for OMAP5 ES2.0+ Soc's. Ill have that sequence alone and send a patch. Thanks and regards, Lokesh Lokesh, unfortunately you shall have to repost 9/12 after rebasing over my stuff, if it is applied. Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4] ARM: OMAP5: Power: Add more functionality to Palmas driver
Add some useful functions, and the corresponding definitions.
Add support for powering on the dra7xx_evm SD/MMC LDO
(courtesy Lokesh Vutla lokeshvu...@ti.com).
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V4 checkpatch-clean (except for one long printf string).
V3 does some cleanup and adds support for the dra7xx_evm
board (power on LDO1 used for the SD/MMC interface).
V2 aligns to changed PMIC name (and file names accordingly)
from twl6035 to Palmas and is based on current u-boot-ti
master.
drivers/power/palmas.c | 134 +++-
include/palmas.h | 90 +---
2 files changed, 205 insertions(+), 19 deletions(-)
diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c
index 09c832d..07b9815 100644
--- a/drivers/power/palmas.c
+++ b/drivers/power/palmas.c
@@ -25,28 +25,138 @@
void palmas_init_settings(void)
{
- return;
+#ifdef CONFIG_PALMAS_SMPS7_FPWM
+ int err;
+ /*
+* Set SMPS7 (1.8 V I/O supply on platforms with TWL6035/37) to
+* forced PWM mode. This reduces noise (but affects efficiency).
+*/
+ u8 val = SMPS_MODE_SLP_FPWM | SMPS_MODE_ACT_FPWM;
+ err = palmas_i2c_write_u8(TWL603X_CHIP_P1, SMPS7_CTRL, val);
+ if (err)
+ printf(palmas: could not force PWM for SMPS7: err = %d\n,
+ err);
+#endif
}
int palmas_mmc1_poweron_ldo(void)
{
u8 val = 0;
- /* set LDO9 TWL6035 to 3V */
- val = 0x2b; /* (3 -.9)*28 +1 */
-
- if (palmas_i2c_write_u8(0x48, LDO9_VOLTAGE, val)) {
- printf(twl6035: could not set LDO9 voltage.\n);
+#if defined(CONFIG_DRA7XX)
+ /*
+* Currently valid for the dra7xx_evm board:
+* Set TPS659038 LDO1 to 3.0 V
+*/
+ val = LDO_VOLT_3V0;
+ if (palmas_i2c_write_u8(TPS65903X_CHIP_P1, LDO1_VOLTAGE, val)) {
+ printf(tps65903x: could not set LDO1 voltage.\n);
+ return 1;
+ }
+ /* TURN ON LDO1 */
+ val = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ if (palmas_i2c_write_u8(TPS65903X_CHIP_P1, LDO1_CTRL, val)) {
+ printf(tps65903x: could not turn on LDO1.\n);
return 1;
}
+ return 0;
+#else
+ /*
+* We assume that this is a OMAP543X + TWL603X board:
+* Set TWL6035/37 LDO9 to 3.0 V
+*/
+ val = LDO_VOLT_3V0;
+ return twl603x_mmc1_set_ldo9(val);
+#endif
+}
- /* TURN ON LDO9 */
- val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
+/*
+ * On some OMAP5 + TWL603X hardware the SD card socket and LDO9_IN are
+ * powered by an external 3.3 V regulator, while the output of LDO9
+ * supplies VDDS_SDCARD for the OMAP5 interface only. This implies that
+ * LDO9 could be set to 'bypass' mode when required (e.g. for 3.3 V cards).
+ */
+int twl603x_mmc1_set_ldo9(u8 vsel)
+{
+ u8 cval = 0, vval = 0; /* Off by default */
+ int err;
- if (palmas_i2c_write_u8(0x48, LDO9_CTRL, val)) {
- printf(twl6035: could not turn on LDO9.\n);
- return 1;
+ if (vsel) {
+ /* Turn on */
+ if (vsel LDO_VOLT_3V3) {
+ /* Put LDO9 in bypass */
+ cval = LDO9_BYP_EN | RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ vval = LDO_VOLT_3V3;
+ } else {
+ cval = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ vval = vsel 0x3f;
+ }
+ }
+ err = palmas_i2c_write_u8(TWL603X_CHIP_P1, LDO9_VOLTAGE, vval);
+ if (err) {
+ printf(twl603x: could not set LDO9 %s: err = %d\n,
+ vsel LDO_VOLT_3V3 ? bypass : voltage, err);
+ return err;
}
+ err = palmas_i2c_write_u8(TWL603X_CHIP_P1, LDO9_CTRL, cval);
+ if (err)
+ printf(twl603x: could not turn %s LDO9: err = %d\n,
+ cval ? on : off, err);
+ return err;
+}
- return 0;
+#ifdef CONFIG_PALMAS_AUDPWR
+/*
+ * Turn audio codec power and 32 kHz clock on/off. Use for
+ * testing OMAP543X + TWL603X + TWL604X boards only.
+ */
+int twl603x_audio_power(u8 on)
+{
+ u8 cval = 0, vval = 0, c32k = 0;
+ int err;
+
+ if (on) {
+ vval = SMPS_VOLT_2V1;
+ cval = SMPS_MODE_SLP_AUTO | SMPS_MODE_ACT_AUTO;
+ c32k = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ }
+ /* Set SMPS9 to 2.1 V (for TWL604x), or to 0 (off) */
+ err = palmas_i2c_write_u8(TWL603X_CHIP_P1, SMPS9_VOLTAGE, vval);
+ if (err) {
+ printf(twl603x: could not set SMPS9 voltage: err = %d\n,
+ err);
+ return err;
+ }
+ /* Turn on or off SMPS9 */
+ err = palmas_i2c_write_u8(TWL603X_CHIP_P1, SMPS9_CTRL, cval);
+ if (err) {
+ printf(twl603x: could not turn SMPS9 %s: err = %d\n,
+
Re: [U-Boot] patches never reviewed
Dear Scott, please be sure before replying to verify the history of the threads. This patch is around for more than one year. 1) i was quite sure that last patch body was ok. Please let me know eventually what are these issues, if any, with a feedback. 2) in most of the cases i always included Mr, Jason Jim in CC, that in most of the cases never reply. Maybe could be the case to verify this and clarify with him. 3) this subject is in this form because is not the 1st but the second reminder to review the patches, and not a patch. You told me board: add support for amcore board is not correct, but of course you can check the patchwork site and see other title like that passed. And in case i fix this, someone will say the m68k in the title is wrong, becouse is a board patch. To the community, i fixed several and several things on this patch over more than one year, following several and several feedbacks from many of you. I was expecting a minimal of flexibility and a final approval, since i contributed also for bug fixing sometime, and since some other boards has been approved wthout too many troubles. I have seen this is depending much from the cpu/arch tree maintainer or custodian. And the custodian of Coldfire tree from Freescale seems is not partecipating to much in this patch. The result is that there is no way to have the board nor m5307 cpu patch accepted becouse again, for the 100th time, there is something not correct. I am not stupid, and understanding now that whatever would be my changes, patch will still be stopped and stopped from a different guy. I don't want to accuse anyone of any form of discrimination, but i stop to contribute for now, almost for m68k branch. With Best Regards, Angelo Dureghello On Tue, Jun 04, 2013 at 12:54:31PM -0500, Scott Wood wrote: On 06/04/2013 12:47:47 PM, Scott Wood wrote: On 06/03/2013 03:51:48 PM, Angelo Dureghello wrote: Dear All, i worked hardly through v6 for approval of this AMCORE Coldfire board support. Waited patiently for review of this patches: http://patchwork.ozlabs.org/patch/215904/ http://patchwork.ozlabs.org/patch/214686/ then asked again later for the review: http://marc.info/?l=u-bootm=136059580219228w=2 still, at today, i had no feedbacks. Unfortunately (i can be wrong) but i have the impression at freescale no-one have time to spend for following this board addition. Jason Jin is the Coldfire custodian. I've added him on CC here; please be sure to put him on CC when you send Coldfire patches or inquiries. Sigh, and of course the list ate the CC. So for all I know maybe you had him on CC to begin with... Another thing that can help is using better subject lines. patches review isn't going to let people know what sort of patches they are and if it's their responsibility or not. Likewise, board: add support for amcore board doesn't have m68k or coldfire in the title (whereas board: is redundant). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] patches never reviewed
On Thu, Jun 6, 2013 at 11:20 AM, Angelo Dureghello sysa...@gmail.comwrote: ... I don't want to accuse anyone of any form of discrimination, but i stop to contribute for now, almost for m68k branch. I understand your disappointment and I agree in most of your complains. At same time, I also think we should turn the page and start over. May you reconsider and do a last try? * fix the board addition as already pointed out * check your other patches to see if you spot something wrong * send it again. Please also ensure you add (again) the maintainer in Cc so you'll have your side done and the duty of review and check it will be in the custodian side. Friendly, -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] ARM: OMAP5: Power: Add more functionality to Palmas driver
On Thu, Jun 06, 2013 at 05:16:40PM +0300, Lubomir Popov wrote: Add some useful functions, and the corresponding definitions. Add support for powering on the dra7xx_evm SD/MMC LDO (courtesy Lokesh Vutla lokeshvu...@ti.com). Signed-off-by: Lubomir Popov lpo...@mm-sol.com Reviewed-by: Tom Rini tr...@ti.com -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] input: fix unaligned access in key_matrix_decode_fdt()
On Wed, Jun 05, 2013 at 08:34:20AM -0400, Tom Rini wrote: On Wed, May 22, 2013 at 08:48:18AM -, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Initialized character arrays on the stack can cause gcc to emit code that performs unaligned accessess. Make the data static to avoid this. Note that the unaligned accesses are made when copying data to prefix[] on the stack from .rodata. By making the data static, the copy is completely avoided. All explicitly written code treats the data as u8[], so will never cause any unaligned accesses. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! Bah! I see I applied v1 and not v2, I shall post and apply the delta between them momentarily. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] input: Finish simplifing key_matrix_decode_fdt()
From: Stephen Warren swar...@nvidia.com
[trini: Applied v1 of the series rather than v2, this commit is the
delta from v1 to v2]
Signed-off-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Tom Rini tr...@ti.com
---
drivers/input/key_matrix.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/input/key_matrix.c b/drivers/input/key_matrix.c
index ea05c77..c900e45 100644
--- a/drivers/input/key_matrix.c
+++ b/drivers/input/key_matrix.c
@@ -162,8 +162,10 @@ int key_matrix_decode_fdt(struct key_matrix *config, const
void *blob, int node)
prop = fdt_get_property(blob, node, linux,keymap, proplen);
/* Basic keymap is required */
- if (!prop)
+ if (!prop) {
+ debug(%s: cannot find keycode-plain map\n, __func__);
return -1;
+ }
plain_keycode = create_keymap(config, (u32 *)prop-data,
proplen, KEY_FN, config-fn_pos);
@@ -180,7 +182,7 @@ int key_matrix_decode_fdt(struct key_matrix *config, const
void *blob, int node)
config-fn_keycode = create_keymap(config, (u32 *)prop-data,
proplen, -1, NULL);
/* Conversion error - fail */
- if (!config-plain_keycode) {
+ if (!config-fn_keycode) {
free(plain_keycode);
return -1;
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] usb: omap: ulpi: fix ulpi transceiver access
This patch fix the omap access to the transceiver
configuration registers using the ulpi bus. As reported by
the documentation the bit31 is used only to check if the
transaction is done or still running and the reading and
writing operation have different offset and have different
values. What we need to do at the end of a transaction is
leave the bus in done state. Anyway an error using the ulpi
omap register is not recoverable so any error give out the
usage of this interface.
Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com
Reviewed-by: Igor Grinberg grinb...@compulab.co.il
---
- changes for V3
Fix patch subject
- changes for V2
Fix commit message
---
drivers/usb/ulpi/omap-ulpi-viewport.c | 40 +++--
1 file changed, 8 insertions(+), 32 deletions(-)
diff --git a/drivers/usb/ulpi/omap-ulpi-viewport.c
b/drivers/usb/ulpi/omap-ulpi-viewport.c
index 3c1ea1a..2a42033 100644
--- a/drivers/usb/ulpi/omap-ulpi-viewport.c
+++ b/drivers/usb/ulpi/omap-ulpi-viewport.c
@@ -22,18 +22,19 @@
#include asm/io.h
#include usb/ulpi.h
-#define OMAP_ULPI_WR_OPSEL (3 21)
-#define OMAP_ULPI_ACCESS (1 31)
+#define OMAP_ULPI_WR_OPSEL (2 22)
+#define OMAP_ULPI_RD_OPSEL (3 22)
+#define OMAP_ULPI_START(1 31)
/*
- * Wait for the ULPI Access to complete
+ * Wait for having ulpi in done state
*/
static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask)
{
int timeout = CONFIG_USB_ULPI_TIMEOUT;
while (--timeout) {
- if ((readl(ulpi_vp-viewport_addr) mask))
+ if (!(readl(ulpi_vp-viewport_addr) mask))
return 0;
udelay(1);
@@ -43,40 +44,15 @@ static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32
mask)
}
/*
- * Wake the ULPI PHY up for communication
- *
- * returns 0 on success.
- */
-static int ulpi_wakeup(struct ulpi_viewport *ulpi_vp)
-{
- int err;
-
- if (readl(ulpi_vp-viewport_addr) OMAP_ULPI_ACCESS)
- return 0; /* already awake */
-
- writel(OMAP_ULPI_ACCESS, ulpi_vp-viewport_addr);
-
- err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS);
- if (err)
- debug(ULPI wakeup timed out\n);
-
- return err;
-}
-
-/*
* Issue a ULPI read/write request
*/
static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value)
{
int err;
- err = ulpi_wakeup(ulpi_vp);
- if (err)
- return err;
-
writel(value, ulpi_vp-viewport_addr);
- err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS);
+ err = ulpi_wait(ulpi_vp, OMAP_ULPI_START);
if (err)
debug(ULPI request timed out\n);
@@ -85,7 +61,7 @@ static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32
value)
int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value)
{
- u32 val = ((ulpi_vp-port_num 0xf) 24) |
+ u32 val = (OMAP_ULPI_START | (ulpi_vp-port_num 0xf) 24) |
OMAP_ULPI_WR_OPSEL | ((u32)reg 16) | (value 0xff);
return ulpi_request(ulpi_vp, val);
@@ -95,7 +71,7 @@ u32 ulpi_read(struct ulpi_viewport *ulpi_vp, u8 *reg)
{
int err;
u32 val = ((ulpi_vp-port_num 0xf) 24) |
-OMAP_ULPI_WR_OPSEL | ((u32)reg 16);
+OMAP_ULPI_RD_OPSEL | ((u32)reg 16);
err = ulpi_request(ulpi_vp, val);
if (err)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Micron eMMC problem on sabre SD like card
Hi, Stefano, Fabio,
On Thu, Jun 6, 2013 at 6:39 AM, Fabio Estevam feste...@gmail.com wrote:
On Thu, Jun 6, 2013 at 10:34 AM, Stefano Babic sba...@denx.de wrote:
Could be the same as the issue reported by Fabio at
http://patchwork.ozlabs.org/patch/246928/ ?
Yes, please apply this one and also:
http://patchwork.ozlabs.org/patch/248877/
With both patches applied SD functionality works well on mx6qsabresd.
Will do.
Also, I was looking around and came across this VSELECT bit in the
VEND_SPEC register (219_80C0 Vendor Specific Register
(uSDHC3_VEND_SPEC) )
It is used to generate low voltage, like 1.8V (n bus SD3 here) which I
think is needed for DDR mode?
The Freescale code is using it here:
/* Switch voltage to 1.8V if CMD11 succeeded */
if (cmd-cmdidx == SD_CMD_SWITCH_UHS18V) {
/* Set SD_VSELECT to switch to 1.8V */
u32 reg;
reg = readl(regs-vendorspec);
reg |= VENDORSPEC_VSELECT;
writel(reg, regs-vendorspec);
/* Sleep for 5 ms - max time for card to switch to 1.8V */
udelay(5000);
/* Turn on SD clock */
writel(reg | VENDORSPEC_FRC_SDCLK_ON, regs-vendorspec);
while (!(readl(regs-prsstat) PRSSTAT_DAT0))
;
/* restore SD clock status */
writel(reg, regs-vendorspec);
}
drivers/mmc/imx_esdhc.c 714 lines --31%--
-jfs
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Tomorrows updates, today!
Hey all, I feel it's getting a bit opaque as to what I'm going to merge / when. As a general rule, I'm trying to have a week go by between posting and merging, to give everyone a chance to review things (but this isn't a hard and fast rule). To that end, here's the bundles I'm looking at merging and build / boot testing tomorrow: u-boot-ti/master: http://patchwork.ozlabs.org/bundle/trini/2013-06-07-u-boot-ti-master-imports/ u-boot/master: http://patchwork.ozlabs.org/bundle/trini/2013-06-07-u-boot-master-imports/ If you have a patch that you think should be there, and isn't, or one that is and shouldn't, please speak up! Thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5 09/12] mmc: omap_hsmmc: Update pbias programming
From: Balaji T K balaj...@ti.com
Update pbias programming sequence for OMAP5 ES2.0/DRA7
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
Changes since V4:
* Rebased on top of http://patchwork.ozlabs.org/patch/249430/
arch/arm/include/asm/arch-omap5/omap.h |2 +-
drivers/mmc/omap_hsmmc.c | 20 +---
include/configs/omap5_common.h |4
include/configs/omap5_uevm.h |5 -
4 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 9010666..abf6837 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -106,9 +106,9 @@
/* CONTROL_EFUSE_2 */
#define CONTROL_EFUSE_2_NMOS_PMOS_PTV_CODE_1 0x00ffc000
+#define SDCARD_BIAS_PWRDNZ (1 27)
#define SDCARD_PWRDNZ (1 26)
#define SDCARD_BIAS_HIZ_MODE (1 25)
-#define SDCARD_BIAS_PWRDNZ (1 22)
#define SDCARD_PBIASLITE_VMODE (1 21)
#ifndef __ASSEMBLY__
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index afdfa88..975b2c5 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -113,23 +113,21 @@ static void omap5_pbias_config(struct mmc *mmc)
u32 value = 0;
value = readl((*ctrl)-control_pbias);
- value = ~(SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ);
- value |= SDCARD_BIAS_HIZ_MODE;
+ value = ~SDCARD_PWRDNZ;
+ writel(value, (*ctrl)-control_pbias);
+ udelay(10); /* wait 10 us */
+ value = ~SDCARD_BIAS_PWRDNZ;
writel(value, (*ctrl)-control_pbias);
palmas_mmc1_poweron_ldo();
value = readl((*ctrl)-control_pbias);
- value = ~SDCARD_BIAS_HIZ_MODE;
- value |= SDCARD_PBIASLITE_VMODE | SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ;
+ value |= SDCARD_BIAS_PWRDNZ;
writel(value, (*ctrl)-control_pbias);
-
- value = readl((*ctrl)-control_pbias);
- if (value (1 23)) {
- value = ~(SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ);
- value |= SDCARD_BIAS_HIZ_MODE;
- writel(value, (*ctrl)-control_pbias);
- }
+ udelay(150); /* wait 150 us */
+ value |= SDCARD_PWRDNZ;
+ writel(value, (*ctrl)-control_pbias);
+ udelay(150); /* wait 150 us */
}
#endif
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 83b91d1..ddf2ad4 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -238,6 +238,10 @@
#define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
#endif
+#ifndef CONFIG_SPL_BUILD
+#define CONFIG_PALMAS_POWER
+#endif
+
/* Defines for SPL */
#define CONFIG_SPL
#define CONFIG_SPL_FRAMEWORK
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index ba81e30..f4a2d31 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -39,11 +39,6 @@
#define CONFIG_SYS_NS16550_COM3UART3_BASE
#define CONFIG_BAUDRATE115200
-/* TWL6035 */
-#ifndef CONFIG_SPL_BUILD
-#define CONFIG_PALMAS_POWER
-#endif
-
/* MMC ENV related defines */
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_SYS_MMC_ENV_DEV 1 /* SLOT2: eMMC(1) */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: dra7xx: Update the EXTRA_ENV_SETTINGS
On Wed, Jun 05, 2013 at 09:39:47AM -0500, Dan Murphy wrote:
Update the EXTRA_ENV_SETTING for the dra7xx.
The console needs to be set to ttyO0 and the
findfdt needs to be updated to load the
dra7xx-evm.dtb file.
Signed-off-by: Dan Murphy dmur...@ti.com
Did you run-time test this? I'm a little concerned about the include
order, but that might turn out alright. But I think:
+ if test -z ${fdtfile}; then \
Really needs to be:
if test -z ${fdtfile}; then...
So that it doesn't become:
if test -z; then
when fdtfile isn't set and we get a parse error there.
Thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, am335x: make mpu pll config configurable
On Wed, Jun 05, 2013 at 07:26:45AM +0200, Heiko Schocher wrote: Hello Tom, Am 04.06.2013 23:29, schrieb Tom Rini: On Tue, Jun 04, 2013 at 11:01:06AM +0200, Heiko Schocher wrote: upcoming support for siemens boards switches mpu pll clk in board code. So make this configurable. Signed-off-by: Heiko Schocher h...@denx.de Cc: Tom Rini tr...@ti.com Wait, didn't we already something like this posted? Hmm.. did not found something like that, but maybe I missed it. I guess we'll chalk it up to never got posted. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] vf610twr: Drop unneeded 'status' variable
On 06/06/2013 09:50, Stefano Babic wrote: On 05/06/2013 23:34, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com No need to use the 'status' variable, so just remove it. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] : Please pull u-boot-imx
Hi Albert, please pull from u-boot-imx, thanks. The following changes since commit cac423a730d3506154744485af1bbc1cd3a1e6a8: Merge branch 'u-boot-ti/master' into 'u-boot-arm/master' (2013-05-11 22:24:28 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master for you to fetch changes up to 4a1c7b13ae104d4526d3176793b7f6b06694df15: vf610twr: Drop unneeded 'status' variable (2013-06-06 17:52:08 +0200) Alison Wang (7): arm: vf610: Add IOMUX support for Vybrid VF610 arm: vf610: Add Vybrid VF610 CPU support net: fec_mxc: Add support for Vybrid VF610 arm: vf610: Add watchdog support for Vybrid VF610 arm: vf610: Add uart support for Vybrid VF610 arm: vf610: Add Vybrid VF610 to mxc_ocotp document arm: vf610: Add basic support for Vybrid VF610TWR board Andrew Gabbasov (1): mx6: mx6qsabrelite/nitrogen6x: Remove incorrect setting of gpio CS signal Benoît Thébaudeau (1): imx: spl: Merge libimx-common make rules Fabio Estevam (7): mx28evk: Add splash screen support mx23evk: Add splash screen support video: mxsfb: Add an entry for mx23evk/mx28vk video modes mx6slevk: Allow booting a device tree kernel wandboard: Enable HDMI splashscreen ARM: imx: Fix incorrect usage of CONFIG_SYS_MMC_ENV_PART vf610twr: Drop unneeded 'status' variable Luka Perkov (1): wandboard: fix typo in README Marek Vasut (1): arm: mxs: Fix vectoring table crafting Otavio Salvador (2): build: Use generic boot logo matching wandboard: Add Boot Splash image with Wandboard logo Renato Frias (2): mx6qsabreauto: Add i2c to mx6qsabreauto board mx6qsabreauto: Add Port Expander reset SARTRE Leo (1): Add support for Congatec Conga-QEVAl board MAINTAINERS |8 + Makefile |2 +- arch/arm/cpu/arm926ejs/mxs/mxs.c | 25 +- arch/arm/cpu/armv7/vf610/Makefile | 42 +++ arch/arm/cpu/armv7/vf610/generic.c| 324 +++ arch/arm/cpu/armv7/vf610/timer.c | 103 ++ arch/arm/imx-common/Makefile |2 +- arch/arm/imx-common/iomux-v3.c|6 + arch/arm/include/asm/arch-vf610/clock.h | 39 +++ arch/arm/include/asm/arch-vf610/crm_regs.h| 225 + arch/arm/include/asm/arch-vf610/imx-regs.h| 419 + arch/arm/include/asm/arch-vf610/iomux-vf610.h | 101 ++ arch/arm/include/asm/imx-common/iomux-v3.h| 18 ++ board/boundary/nitrogen6x/nitrogen6x.c|1 - board/congatec/cgtqmx6eval/Makefile | 42 +++ board/congatec/cgtqmx6eval/README | 29 ++ board/congatec/cgtqmx6eval/cgtqmx6eval.c | 167 ++ board/freescale/mx23evk/mx23evk.c |6 + board/freescale/mx23evk/spl_boot.c| 32 ++ board/freescale/mx28evk/iomux.c | 33 ++ board/freescale/mx28evk/mx28evk.c |6 + board/freescale/mx6qsabreauto/mx6qsabreauto.c | 57 board/freescale/mx6qsabrelite/mx6qsabrelite.c |1 - board/freescale/vf610twr/Makefile | 39 +++ board/freescale/vf610twr/imximage.cfg | 33 ++ board/freescale/vf610twr/vf610twr.c | 407 board/wandboard/README|4 +- board/wandboard/wandboard.c | 98 ++ boards.cfg|2 + doc/README.mxc_ocotp |1 + doc/README.vf610 | 10 + drivers/net/fec_mxc.c |4 +- drivers/serial/Makefile |1 + drivers/serial/serial_lpuart.c| 132 drivers/video/mxsfb.c |5 + drivers/watchdog/Makefile |2 +- include/configs/cgtqmx6eval.h | 194 include/configs/mx23evk.h | 17 + include/configs/mx28evk.h | 17 + include/configs/mx53ard.h |3 +- include/configs/mx6qsabre_common.h|2 +- include/configs/mx6qsabreauto.h |7 +- include/configs/mx6qsabresd.h |1 - include/configs/mx6slevk.h|2 +- include/configs/vf610twr.h| 140 + include/configs/wandboard.h | 20 +- spl/Makefile |6 +- tools/Makefile| 27 +- tools/logos/wandboard.bmp | Bin 0 - 22390 bytes 49 files changed, 2818 insertions(+), 44 deletions(-) create mode 100644 arch/arm/cpu/armv7/vf610/Makefile create mode 100644 arch/arm/cpu/armv7/vf610/generic.c create mode 100644
Re: [U-Boot] dfu: make data buffer size configurable
On Wed, Jun 05, 2013 at 04:04:46PM +0200, Heiko Schocher wrote:
[snip]
In current code CONFIG_SYS_DFU_MAX_FILE_SIZE is not used in dfu_nand.c,
Nor anywhere else. As I said in the DFU + UBI thread, there's a bug
here :)
CONFIG_SYS_DFU_MAX_FILE_SIZE is used in ./drivers/dfu/dfu_mmc.c ...
Ah yes, right.
as if buffer is full, it is immediately flushed to nand.
Also default value from CONFIG_SYS_DFU_MAX_FILE_SIZE is smaller (4MiB)
as default value of CONFIG_SYS_DFU_DATA_BUF_SIZE (8MiB) ...
Right, and the commit that did it was about increasing the size of the
kernel that could be sent over.
Hmm.. the CONFIG_SYS_DFU_DATA_BUF_SIZE limits not the size of
a file that could be loaded into a partition. It specifies
only the size of one chunk, that get burned into the raw nand ...
And this should be a configurable size ...
Or a saner, smaller size? I think we've got a few things being done in
a confusing and/or incorrect manner, see below.
I used on my upcoming board port a CONFIG_SYS_DFU_DATA_BUF_SIZE from
1MiB and that worked perfectly, when transferring a file 200MB.
The default value from 8MiB sometimes caused an error on the host:
[]# date;dfu-util -a rootfs -D
dxr2-org/dxr2.xx-release-image-UNKNOWN-dxr2.ubi;date
Di 28. Mai 14:20:44 CEST 2013
dfu-util 0.5
[...]
Copying data from PC to DFU device
Starting download:
[#dfu_download:
libusb_control_transfer returned -7
Error during download
Why we have a buffersize from 8MiB for raw writes, but a max file size
from 4MiB only?
Then we need to poke around the code here a bit more and see what's
going on, and fix things so that we can both do larger (say, 8MiB)
filesystem transfers and not have dfu-util get mad sometimes.
Timeout in libusb_control_transfer while the target writes
the 8MiB into the nand ... ?
I try to find out something ...
Well, it ought to be fine, but we're pushing some boundaries here, and
I don't know if we have a good reason for it. We aren't changing the
size of the chunks being passed along.
-#define DFU_DATA_BUF_SIZE (1024*1024*8) /* 8 MiB */
+#ifndef CONFIG_SYS_DFU_DATA_BUF_SIZE
+#define CONFIG_SYS_DFU_DATA_BUF_SIZE(1024*1024*8) /* 8
MiB */
+#endif
#ifndef CONFIG_SYS_DFU_MAX_FILE_SIZE
#define CONFIG_SYS_DFU_MAX_FILE_SIZE(4 20) /* 4 MiB */
#endif
We use one variable for both spots. Or is there some case I'm missing
where we need to buffer 8MiB at a time for raw writes? In which case we
still need to make CONFIG_SYS_DFU_MAX_FILE_SIZE be used :)
I do not really know, why we have 2 defines here!
File size vs buffer size? I'm not quite certain it was the right way to
go either.
Yeah, but why is the file size buffer size as default?
A bug, I'm pretty sure. The change that made buffer file was with the
comment to allow for bigger files. I think it might not have been
completely tested :)
In dfu_mmc:
If raw partition, if dfu_buf (size of CONFIG_SYS_DFU_DATA_BUF_SIZE)
full - write it to the mmc. Same for nand.
Right. Since we want to buffer up some amount of data, flush, repeat
until done.
If FAT or EXT4 partition (mmc only), write the dfu_buffer through
mmc_file_buffer() to dfu_file_buf[CONFIG_SYS_DFU_MAX_FILE_SIZE] ...
this seems buggy to me, but maybe I oversee something, I could not
try it ... and if the hole file is transfered, the dfu_file_buf
gets flushed to the partition ...
The need here is that since we can't append to files, transfer the whole
file, then write. We will not be told the filesize ahead of time, so we
have to transfer up to the buffer and if we would exceed, error out at
that point, otherwise continue. Now I'm pretty sure, but not 100% sure
that there's a reason we can't use dfu_buf in both places. That needs
re-checking.
The CONFIG_SYS_DFU_MAX_FILE_SIZE is only needed as we can only
write a complete image to FAT, EXT4 (also UBI) partitions, I think.
It'll be needed for any file write, rather than block write. The
question is, can it ever be valid for MAX_FILE_SIZE to be smaller than
BUF_SIZE ? Maybe.
So we have in the dfu subsystem following problems:
a) we have no common API to add image types. Currently
all dfu_{device_type} has to program it.
We also have no common image types.
b) we have no possibility to write image types (FAT, EXT4 or
UBI) in chunks - CONFIG_SYS_DFU_MAX_FILE_SIZE introduced
Correct.
c) CONFIG_SYS_DFU_DATA_BUF_SIZE CONFIG_SYS_DFU_MAX_FILE_SIZE
which is in my eyes buggy ...
Or at least very odd, given the current defaults for both.
d) sporadic problems with CONFIG_SYS_DFU_DATA_BUF_SIZE = 8MiB
Currently i get always an error ... try to find out why ...
Maybe we don't need to go so large for the buffer.
If you've got a beaglebone (and I know there's one in denx :)) or am335x
gp evm, you can test filesystem writes on SD cards
Re: [U-Boot] [PATCH v3] arm: dra7xx: Update the EXTRA_ENV_SETTINGS
On 06/06/2013 10:31 AM, Tom Rini wrote:
On Wed, Jun 05, 2013 at 09:39:47AM -0500, Dan Murphy wrote:
Update the EXTRA_ENV_SETTING for the dra7xx.
The console needs to be set to ttyO0 and the
findfdt needs to be updated to load the
dra7xx-evm.dtb file.
Signed-off-by: Dan Murphy dmur...@ti.com
Did you run-time test this? I'm a little concerned about the include
order, but that might turn out alright. But I think:
I compile and boot tested this on OMAP5.
+if test -z ${fdtfile}; then \
Really needs to be:
if test -z ${fdtfile}; then...
So that it doesn't become:
if test -z; then
when fdtfile isn't set and we get a parse error there.
Thanks!
OK I will update again once I get other comments. Although I am not sure why
we really need to protect someone putting the wrong uBoot on their device unless
we have a single uboot for all devices. I think we are being over protective
here.
--
--
Dan Murphy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: dra7xx: Update the EXTRA_ENV_SETTINGS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/06/2013 12:18 PM, Dan Murphy wrote:
On 06/06/2013 10:31 AM, Tom Rini wrote:
On Wed, Jun 05, 2013 at 09:39:47AM -0500, Dan Murphy wrote:
Update the EXTRA_ENV_SETTING for the dra7xx. The console needs
to be set to ttyO0 and the findfdt needs to be updated to load
the dra7xx-evm.dtb file.
Signed-off-by: Dan Murphy dmur...@ti.com
Did you run-time test this? I'm a little concerned about the
include order, but that might turn out alright. But I think:
I compile and boot tested this on OMAP5.
OK, thanks.
+ if test -z ${fdtfile}; then \
Really needs to be: if test -z ${fdtfile}; then...
So that it doesn't become: if test -z; then when fdtfile isn't
set and we get a parse error there.
Thanks!
OK I will update again once I get other comments. Although I am
not sure why we really need to protect someone putting the wrong
uBoot on their device unless we have a single uboot for all
devices. I think we are being over protective here.
This is omap5_common.h tho. You ran into the problem of findfdt ran,
didn't set an fdtfile, then we tried to bootz ${loadaddr} - ${fdtaddr}
which complained about not having a valid device tree. This should
make it clearer on the next omap5_common.h using board where to fix
things so that their fdt is set right, automatically.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRsLbgAAoJENk4IS6UOR1Wmj0P/jt1CPAtkqTImYnL1077CyC0
yR4sUcSodiSwR5TlXiEiOJveOYvYjVpcLvH4byH/0Yv9yVnVdoG4+j82QUV7I8zU
YjkuusbfGP5rQNlUcE0bWdUGalTUMrlTbnxMJ13q2dDIr4naqMPGLetO3wdpWYKJ
fdHBRz0phr1k2+OvbAoWEtsjxCj8XBv32yqRj+zZX3ErNcZWsBslRz7QUyDLQU1E
FGBRUAzb7tw0N0VbR+mwg9nuqu2/cBM5hprpsiZ6NfrtuLMP89ucIh61xsXf97K5
T4VFWKZhBHU2Fa2udLBHizJOLlW6NLwNpGD8ac7j9aVC2TKxdgHMtFeho6br/8sA
YkWvL5h/1E4i/qzO3MxuuAakTjhf0P4KU2U7UolH2A707sIKeII2L8ppSiT4cF6w
zB+uN9WgFDTZYYmTxXneD4fy/YWWooZtmCUvDS/7fOCvxGhJKehnwrO18LoCSrYZ
iIMpzB59dfWlYBg64zw6dbmQxgsYUUW7s7xpLi4m+8JnVdJCeArrRAq/9x69Dp18
OywMxiZuPNnDGC9XB5wAimyW3ygvXr4HG4WD4Uv/sw7Uhp6cxz04mzyAVlWeKeGO
0aoUra34tutMQjyqtomqpA7EegwXG0UvAM2XEZi5o8DzeMVwnkZXMxwe/lPE4g8u
hJklyBClfW1nvEIsYgAV
=HAAX
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: dra7xx: Update the EXTRA_ENV_SETTINGS
On 06/06/2013 11:20 AM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/06/2013 12:18 PM, Dan Murphy wrote:
On 06/06/2013 10:31 AM, Tom Rini wrote:
On Wed, Jun 05, 2013 at 09:39:47AM -0500, Dan Murphy wrote:
Update the EXTRA_ENV_SETTING for the dra7xx. The console needs
to be set to ttyO0 and the findfdt needs to be updated to load
the dra7xx-evm.dtb file.
Signed-off-by: Dan Murphy dmur...@ti.com
Did you run-time test this? I'm a little concerned about the
include order, but that might turn out alright. But I think:
I compile and boot tested this on OMAP5.
OK, thanks.
+ if test -z ${fdtfile}; then \
Really needs to be: if test -z ${fdtfile}; then...
So that it doesn't become: if test -z; then when fdtfile isn't
set and we get a parse error there.
Thanks!
OK I will update again once I get other comments. Although I am
not sure why we really need to protect someone putting the wrong
uBoot on their device unless we have a single uboot for all
devices. I think we are being over protective here.
This is omap5_common.h tho. You ran into the problem of findfdt ran,
didn't set an fdtfile, then we tried to bootz ${loadaddr} - ${fdtaddr}
which complained about not having a valid device tree. This should
make it clearer on the next omap5_common.h using board where to fix
things so that their fdt is set right, automatically.
- --
Tom
OK sounds sane to me.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRsLbgAAoJENk4IS6UOR1Wmj0P/jt1CPAtkqTImYnL1077CyC0
yR4sUcSodiSwR5TlXiEiOJveOYvYjVpcLvH4byH/0Yv9yVnVdoG4+j82QUV7I8zU
YjkuusbfGP5rQNlUcE0bWdUGalTUMrlTbnxMJ13q2dDIr4naqMPGLetO3wdpWYKJ
fdHBRz0phr1k2+OvbAoWEtsjxCj8XBv32yqRj+zZX3ErNcZWsBslRz7QUyDLQU1E
FGBRUAzb7tw0N0VbR+mwg9nuqu2/cBM5hprpsiZ6NfrtuLMP89ucIh61xsXf97K5
T4VFWKZhBHU2Fa2udLBHizJOLlW6NLwNpGD8ac7j9aVC2TKxdgHMtFeho6br/8sA
YkWvL5h/1E4i/qzO3MxuuAakTjhf0P4KU2U7UolH2A707sIKeII2L8ppSiT4cF6w
zB+uN9WgFDTZYYmTxXneD4fy/YWWooZtmCUvDS/7fOCvxGhJKehnwrO18LoCSrYZ
iIMpzB59dfWlYBg64zw6dbmQxgsYUUW7s7xpLi4m+8JnVdJCeArrRAq/9x69Dp18
OywMxiZuPNnDGC9XB5wAimyW3ygvXr4HG4WD4Uv/sw7Uhp6cxz04mzyAVlWeKeGO
0aoUra34tutMQjyqtomqpA7EegwXG0UvAM2XEZi5o8DzeMVwnkZXMxwe/lPE4g8u
hJklyBClfW1nvEIsYgAV
=HAAX
-END PGP SIGNATURE-
--
--
Dan Murphy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: nand flash
The following changes since commit d6639d10dbfa42dc888f8917012550b632a88959: Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2013-05-31 18:28:47 -0400) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master for you to fetch changes up to 4bfd0002b653dfc9f9ddd8e9a4ce0acd40bde3ac: bug, nand, am33xx: nand-ecc.strength not set in board_nand_init() (2013-06-04 11:50:04 -0500) Sergey Lapin (1): bug, nand, am33xx: nand-ecc.strength not set in board_nand_init() drivers/mtd/nand/omap_gpmc.c |2 ++ 1 file changed, 2 insertions(+) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] pull request for u-boot-tegra/master into ARM/master
Albert, Please pull u-boot-tegra/master into ARM/master. Thanks! ./MAKEALL -s tegra AOK, checkpatch.pl is clean. The following changes since commit 4596dcc1d4ea5763e0f92cf5becd9fc7d4c6e674: am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c (2013-06-05 08:46:49 -0400) are available in the git repository at: git://git.denx.de/u-boot-tegra master for you to fetch changes up to dbc000bfb51eb30d786521e6b8e29048c36cbefa: ARM: tegra: only enable SCU on Tegra20 (2013-06-06 09:12:32 -0700) Tom Warren (1): ARM: tegra: only enable SCU on Tegra20 arch/arm/cpu/tegra-common/ap.c | 4 1 file changed, 4 insertions(+) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Micron eMMC problem on sabre SD like card
On Thu, Jun 6, 2013 at 11:58 AM, jean-francois simon j...@themis.com wrote: Will do. Also, I was looking around and came across this VSELECT bit in the VEND_SPEC register (219_80C0 Vendor Specific Register (uSDHC3_VEND_SPEC) ) It is used to generate low voltage, like 1.8V (n bus SD3 here) which I think is needed for DDR mode? The Freescale code is using it here: Yes, please send a patch for this and add Andy Fleming on Cc. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] imx: nitrogen6x: Enable raw initrd
Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com --- include/configs/nitrogen6x.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index c5118d1..01c3f13 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -286,5 +286,6 @@ #define CONFIG_SYS_ALT_MEMTEST #define CONFIG_CMD_BOOTZ +#define CONFIG_SUPPORT_RAW_INITRD #endif/* __CONFIG_H */ -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/4] imx: nitrogen6x: Config changes
These are just some config changes for nitrogen6x. RAW_INITRD, BOOTZ, FS_GENERIC are being used by this project http://www.eewiki.net/display/linuxonarm/i.MX6x+SABRE+Lite DCACHE can finally be enabled because some related bugs have been fixed. Robert Winkler (4): imx: nitrogen6x: Enabled data cache imx: nitrogen6x: Enable bootz imx: nitrogen6x: Enable raw initrd imx: nitrogen6x: Enable filesystem generic commands include/configs/nitrogen6x.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] imx: nitrogen6x: Enabled data cache
Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com --- Changes for v2: removed dead code include/configs/nitrogen6x.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index aea91bc..039085e 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -276,8 +276,6 @@ #define CONFIG_OF_LIBFDT #define CONFIG_CMD_BOOTZ -#define CONFIG_SYS_DCACHE_OFF - #ifndef CONFIG_SYS_DCACHE_OFF #define CONFIG_CMD_CACHE #endif -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] imx: nitrogen6x: Enable filesystem generic commands
Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com --- include/configs/nitrogen6x.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index 01c3f13..74df66c 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -287,5 +287,6 @@ #define CONFIG_CMD_BOOTZ #define CONFIG_SUPPORT_RAW_INITRD +#define CONFIG_CMD_FS_GENERIC #endif/* __CONFIG_H */ -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] imx: nitrogen6x: Enable bootz
Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com --- include/configs/nitrogen6x.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index 039085e..c5118d1 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -285,4 +285,6 @@ #define CONFIG_CMD_TIME #define CONFIG_SYS_ALT_MEMTEST +#define CONFIG_CMD_BOOTZ + #endif/* __CONFIG_H */ -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] bmp: Respect splashpos if it is defined
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
common/cmd_bmp.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/common/cmd_bmp.c b/common/cmd_bmp.c
index 5a52edd..48e045e 100644
--- a/common/cmd_bmp.c
+++ b/common/cmd_bmp.c
@@ -33,6 +33,10 @@
#include malloc.h
#include video.h
+#ifdef CONFIG_SPLASH_SCREEN_ALIGN
+#define BMP_ALIGN_CENTER 0x7FFF
+#endif
+
static int bmp_info (ulong addr);
/*
@@ -112,6 +116,25 @@ static int do_bmp_display(cmd_tbl_t * cmdtp, int flag, int
argc, char * const ar
{
ulong addr;
int x = 0, y = 0;
+ __maybe_unused char *s;
+
+#ifdef CONFIG_SPLASH_SCREEN_ALIGN
+ s = getenv(splashpos);
+ if (s != NULL) {
+ if (s[0] == 'm')
+ x = BMP_ALIGN_CENTER;
+ else
+ x = simple_strtol(s, NULL, 0);
+
+ s = strchr(s + 1, ',');
+ if (s != NULL) {
+ if (s[1] == 'm')
+ y = BMP_ALIGN_CENTER;
+ else
+ y = simple_strtol(s + 1, NULL, 0);
+ }
+ }
+#endif /* CONFIG_SPLASH_SCREEN_ALIGN */
switch (argc) {
case 1: /* use load_addr as default address */
--
1.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: dra7xx: Update the EXTRA_ENV_SETTINGS
Tom
On 06/06/2013 11:24 AM, Dan Murphy wrote:
On 06/06/2013 11:20 AM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/06/2013 12:18 PM, Dan Murphy wrote:
On 06/06/2013 10:31 AM, Tom Rini wrote:
On Wed, Jun 05, 2013 at 09:39:47AM -0500, Dan Murphy wrote:
Update the EXTRA_ENV_SETTING for the dra7xx. The console needs
to be set to ttyO0 and the findfdt needs to be updated to load
the dra7xx-evm.dtb file.
Signed-off-by: Dan Murphy dmur...@ti.com
Did you run-time test this? I'm a little concerned about the
include order, but that might turn out alright. But I think:
I compile and boot tested this on OMAP5.
OK, thanks.
+ if test -z ${fdtfile}; then \
Really needs to be: if test -z ${fdtfile}; then...
So that it doesn't become: if test -z; then when fdtfile isn't
set and we get a parse error there.
Thanks!
OK I will update again once I get other comments. Although I am
not sure why we really need to protect someone putting the wrong
uBoot on their device unless we have a single uboot for all
devices. I think we are being over protective here.
This is omap5_common.h tho. You ran into the problem of findfdt ran,
didn't set an fdtfile, then we tried to bootz ${loadaddr} - ${fdtaddr}
which complained about not having a valid device tree. This should
make it clearer on the next omap5_common.h using board where to fix
things so that their fdt is set right, automatically.
- --
Tom
OK sounds sane to me.
So this check does not work at all. I could never get the -z to show that the
arg was not defined.
Even if I defined fdtfile=\0 the variable indicates that is is still undefined.
And I cannot add in the because the compiler bonks thinking the macro line
is completed.
So what I am going to do is pull this out of this patch completely because this
has no impact on the intent of the patch.
I will then go ahead and fix the omap4_common, omap5_common and the am335
common in a separate patch.
Thoughts?
Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRsLbgAAoJENk4IS6UOR1Wmj0P/jt1CPAtkqTImYnL1077CyC0
yR4sUcSodiSwR5TlXiEiOJveOYvYjVpcLvH4byH/0Yv9yVnVdoG4+j82QUV7I8zU
YjkuusbfGP5rQNlUcE0bWdUGalTUMrlTbnxMJ13q2dDIr4naqMPGLetO3wdpWYKJ
fdHBRz0phr1k2+OvbAoWEtsjxCj8XBv32yqRj+zZX3ErNcZWsBslRz7QUyDLQU1E
FGBRUAzb7tw0N0VbR+mwg9nuqu2/cBM5hprpsiZ6NfrtuLMP89ucIh61xsXf97K5
T4VFWKZhBHU2Fa2udLBHizJOLlW6NLwNpGD8ac7j9aVC2TKxdgHMtFeho6br/8sA
YkWvL5h/1E4i/qzO3MxuuAakTjhf0P4KU2U7UolH2A707sIKeII2L8ppSiT4cF6w
zB+uN9WgFDTZYYmTxXneD4fy/YWWooZtmCUvDS/7fOCvxGhJKehnwrO18LoCSrYZ
iIMpzB59dfWlYBg64zw6dbmQxgsYUUW7s7xpLi4m+8JnVdJCeArrRAq/9x69Dp18
OywMxiZuPNnDGC9XB5wAimyW3ygvXr4HG4WD4Uv/sw7Uhp6cxz04mzyAVlWeKeGO
0aoUra34tutMQjyqtomqpA7EegwXG0UvAM2XEZi5o8DzeMVwnkZXMxwe/lPE4g8u
hJklyBClfW1nvEIsYgAV
=HAAX
-END PGP SIGNATURE-
--
--
Dan Murphy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bmp: Respect splashpos if it is defined
Dear Anatolij, On Thu, Jun 6, 2013 at 2:57 PM, Otavio Salvador ota...@ossystems.com.brwrote: Signed-off-by: Otavio Salvador ota...@ossystems.com.br I forgot to add you in Cc; sorry. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: dra7xx: Update the EXTRA_ENV_SETTINGS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/06/2013 02:02 PM, Dan Murphy wrote: So what I am going to do is pull this out of this patch completely because this has no impact on the intent of the patch. I will then go ahead and fix the omap4_common, omap5_common and the am335 common in a separate patch. Alright, lets go that way, thanks. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRsNRZAAoJENk4IS6UOR1Wx2IP/ihq7GITzEtcEORldDBfenlI NQAwQUilibSyxW465OShdUXLhQBMhA96G85MhozDBOL6aoQXO0Zir7B7DiImOkYA bcZMgdett+tQTwnAtfSnUYeIjfREG8G6A40C4YBk7Yw0vc6VT8xuaBjHE7Entewn UAjZrTQ2/ltzTHrHkJxKZq7QlH0VEj+hL/b66xngZNJ1BuAHgIsqisGxG+YBfwp3 yrH1rVYCmDI5adx9cpVjHFHvDmEezIeyG28miYJGbvTki5D0Xcf35v0BFU7MLLNh 46oeF65PFc46UctggxwSzTBuE57quGKMCdwg9W6LZsOxncEfnUW0eW5O3syvfJ/f qaY2Kk0iJD4h6TnV1Pn4bPwrDQ46JWw4wR98SYoHkAPhxD6qdllgxQ43JNEFV4bC GzvrGw2ytAOsNRUSauE0HP4oqETXnGvpgzWt8HyLNbjBOKILoSTQt2zS4BioIGij 9AjGSeXXrAGPiyNLnxarkNBGbaoCeMrQUfCVo9jLSiCAJ/PPAYLRKnPeo2nGXC6p ntf8wBoIqZ0AnqbwzPL5kafqIUd8krzKjtwNxdNIh27g/DG345+PiL+DCLJVs4Y/ KQsYLSqzV9G7TY8iCTtsZoB3yABKnyQcf0vRDeavNo/vqAub2UxhH+IG1xQ2+t7e 1BiR4TOqDr7QTfseKckR =S/7s -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: omap: Add check for fdtfile in the findfdt macro
In the omap4, omap5 and am335x common files add a check to ensure that the
fdtfile is
defined after the findfdt macro has run. If the file is not defined then warn
the user that the
dtb file is not defined.
Signed-off-by: Dan Murphy dmur...@ti.com
---
include/configs/am335x_evm.h |7 ---
include/configs/omap4_common.h |5 -
include/configs/omap5_common.h |5 -
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index f019134..7771c3f 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -60,7 +60,7 @@
rdaddr=0x8100\0 \
bootdir=/boot\0 \
bootfile=uImage\0 \
- fdtfile=\0 \
+ fdtfile=undefined\0 \
console=ttyO0,115200n8\0 \
optargs=\0 \
mtdids= MTDIDS_DEFAULT \0 \
@@ -145,8 +145,9 @@
if test $board_name = A33515BB; then \
setenv fdtfile am335x-evm.dtb; fi; \
if test $board_name = A335X_SK; then \
- setenv fdtfile am335x-evmsk.dtb; fi\0 \
-
+ setenv fdtfile am335x-evmsk.dtb; fi \
+ if test $fdtfile = undefined; then \
+ echo WARNING: Could not determine device tree to use;
fi; \0
#endif
#define CONFIG_BOOTCOMMAND \
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index d6448b0..b3e8705 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -154,6 +154,7 @@
console=ttyO2,115200n8\0 \
fdt_high=0x\0 \
fdtaddr=0x80f8\0 \
+ fdtfile=undefined\0 \
bootpart=0:2\0 \
bootdir=/boot\0 \
bootfile=zImage\0 \
@@ -182,7 +183,9 @@
if test $board_name = panda; then \
setenv fdtfile omap4-panda.dtb; fi; \
if test $board_name = panda-es; then \
- setenv fdtfile omap4-panda-es.dtb; fi; \0 \
+ setenv fdtfile omap4-panda-es.dtb; fi; \
+ if test $fdtfile = undefined; then \
+ echo WARNING: Could not determine device tree to use;
fi; \0 \
loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0 \
#define CONFIG_BOOTCOMMAND \
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index deb5e9f..205de8c 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -147,6 +147,7 @@
console=ttyO2,115200n8\0 \
fdt_high=0x\0 \
fdtaddr=0x80f8\0 \
+ fdtfile=undefined\0 \
bootpart=0:2\0 \
bootdir=/boot\0 \
bootfile=zImage\0 \
@@ -174,7 +175,9 @@
bootz ${loadaddr} - ${fdtaddr}\0 \
findfdt=\
if test $board_name = omap5_uevm; then \
- setenv fdtfile omap5-uevm.dtb; fi;\0 \
+ setenv fdtfile omap5-uevm.dtb; fi; \
+ if test $fdtfile = undefined; then \
+ echo WARNING: Could not determine device tree to use;
fi; \0 \
loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0 \
#define CONFIG_BOOTCOMMAND \
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] arm: dra7xx: Update the EXTRA_ENV_SETTINGS
Update the EXTRA_ENV_SETTING for the dra7xx.
The console needs to be set to ttyO0 and the
findfdt needs to be updated to load the
dra7xx-evm.dtb file.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v4 - Remove check for undefined fdtfile and save for another patch -
http://patchwork.ozlabs.org/patch/249084/
v3 - Updated based on comments - http://patchwork.ozlabs.org/patch/248687/
v2 - Updated with side bar maintainer comments.
include/configs/dra7xx_evm.h |2 ++
include/configs/omap5_common.h |6 --
include/configs/omap5_uevm.h |1 +
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 28a306b..2db0fbd 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -35,4 +35,6 @@
#define CONFIG_DRA7XX /* in a TI DRA7XX core */
#define CONFIG_SYS_PROMPT DRA752 EVM #
+#define CONSOLEDEV ttyO0
+
#endif /* __CONFIG_DRA7XX_EVM_H */
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index deb5e9f..f160648 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -144,7 +144,7 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8200\0 \
- console=ttyO2,115200n8\0 \
+ console= CONSOLEDEV ,115200n8\0 \
fdt_high=0x\0 \
fdtaddr=0x80f8\0 \
bootpart=0:2\0 \
@@ -174,7 +174,9 @@
bootz ${loadaddr} - ${fdtaddr}\0 \
findfdt=\
if test $board_name = omap5_uevm; then \
- setenv fdtfile omap5-uevm.dtb; fi;\0 \
+ setenv fdtfile omap5-uevm.dtb; fi; \
+ if test $board_name = dra7xx; then \
+ setenv fdtfile dra7-evm.dtb; fi; \
loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0 \
#define CONFIG_BOOTCOMMAND \
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 9e0339b..f2cbb02 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -55,6 +55,7 @@
#define CONFIG_CMD_PART
#define CONFIG_SYS_PROMPT OMAP5430 EVM #
+#define CONSOLEDEV ttyO2
#define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC 16296
#endif /* __CONFIG_OMAP5_EVM_H */
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] video:lcd:cfb_console: cm_t35: Add CONFIG_SPLASH_SCREEN_PREPARE support to CONFIG_VIDEO
Hi All,
On Wed, Jun 5, 2013 at 1:31 AM, Igor Grinberg grinb...@compulab.co.il wrote:
Hi Robert,
On 06/04/13 21:11, Robert Winkler wrote:
Adding Anatolij to the CC list.
On Tue, Jun 4, 2013 at 8:10 AM, Robert Winkler
robert.wink...@boundarydevices.com wrote:
Hi Igor,
On Mon, Jun 3, 2013 at 11:10 PM, Igor Grinberg grinb...@compulab.co.il
wrote:
Hi Robert,
On 06/03/13 20:20, Robert Winkler wrote:
Also change splash_screen_prepare to a weak function.
You should be able to make a commit message a bit better.
Also, personally, I see here two functional changes and it would be better
to separate them into two patches:
1) Make the splash_screen_prepare() weak (I don't like this approach,
explanation below)
2) Add CONFIG_SPLASH_SCREEN_PREPARE support to CONFIG_VIDEO
We have considered making the splash_screen_prepare() function weak
in the past, but decided to make it a config option instead.
This way it is documented in the README and is selectable in the
board config.
Once you change it to be weak, there is no point in the config option
anymore... Personally, I don't like this approach.
Wolfgang said as long as I was fixing the bug of SPLASH_SCREEN_PREPARE
not working
for CONFIG_VIDEO I should change it to a weak function so that's what I did.
See the email here:
http://lists.denx.de/pipermail/u-boot/2013-May/155478.html
Ok.
The major benefit of the construct (which Wolfgang wants to remove) is
clear code with no #ifdefs inside functions.
I don't have any special feelings for that construct, but I'd like to
keep #ifdefs out of any functions (the benefit).
I agree with you about the pointlessness of the CONFIG option and I
too like having
it documented in the README. That's the only reason I left the
#ifdefs in at all because
I didn't want to/didn't think I should remove the CONFIG altogether.
I'm not sure what the solution is.
...
some thoughts below...
Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com
---
board/compulab/cm_t35/cm_t35.c | 2 +-
common/lcd.c | 10 --
drivers/video/cfb_console.c| 14 ++
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/board/compulab/cm_t35/cm_t35.c
b/board/compulab/cm_t35/cm_t35.c
index b0b80e5..95098af 100644
--- a/board/compulab/cm_t35/cm_t35.c
+++ b/board/compulab/cm_t35/cm_t35.c
@@ -120,7 +120,7 @@ static inline int splash_load_from_nand(void)
}
#endif /* CONFIG_CMD_NAND */
-int board_splash_screen_prepare(void)
+int splash_screen_prepare(void)
{
char *env_splashimage_value;
u32 bmp_load_addr;
diff --git a/common/lcd.c b/common/lcd.c
index edae835..90f1143 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -1069,15 +1069,13 @@ int lcd_display_bitmap(ulong bmp_image, int x,
int y)
#endif
#ifdef CONFIG_SPLASH_SCREEN_PREPARE
-static inline int splash_screen_prepare(void)
-{
- return board_splash_screen_prepare();
-}
-#else
-static inline int splash_screen_prepare(void)
+int __splash_screen_prepare(void)
{
return 0;
}
+
+int splash_screen_prepare(void)
+ __attribute__ ((weak, alias(__splash_screen_prepare)));
#endif
You remove the #else statement, apparently you break the compilation for
!CONFIG_SPLASH_SCREEN_PREPARE, as the below lcd_logo() function references
the splash_screen_prepare() function.
Also, this means you force the code to have the ugly #ifdefs inside
functions - that is not really nice.
static void *lcd_logo(void)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 0793f07..9180998 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -1966,6 +1966,16 @@ static void plot_logo_or_black(void *screen, int
width, int x, int y, int black)
#endif
}
+#ifdef CONFIG_SPLASH_SCREEN_PREPARE
+int __splash_screen_prepare(void)
+{
+ return 0;
+}
+
+int splash_screen_prepare(void)
+ __attribute__ ((weak, alias(__splash_screen_prepare)));
+#endif
Why duplicate the above?
Probably, just place it in a common location?
I asked Wolfgang about this in the original thread but haven't heard
back so I just submitted it
like this with the thought that CONFIG_VIDEO and CONFIG_LCD are never
used simultaneously and are
designed not to be (I could easily be wrong about that).
+
static void *video_logo(void)
{
char info[128];
@@ -1996,6 +2006,10 @@ static void *video_logo(void)
s = getenv(splashimage);
if (s != NULL) {
+#ifdef CONFIG_SPLASH_SCREEN_PREPARE
+ splash_screen_prepare();
+#endif
These are the ugly #ifdefs, I was talking about...
Agreed
I would recommend to just move the splash_screen_prepare() function
definition
to a common location and add the above function call (with no #ifdef
around).
And keep the meaningless CONFIG?
While I was writing the above, I meant to keep the #ifdef ... #else ... #endif
construct.
So
Re: [U-Boot] [PATCH v4] arm: dra7xx: Update the EXTRA_ENV_SETTINGS
Hi Dan, Update the EXTRA_ENV_SETTING for the dra7xx. The console needs to be set to ttyO0 and the findfdt needs to be updated to load the dra7xx-evm.dtb file. Signed-off-by: Dan Murphy dmur...@ti.com --- v4 - Remove check for undefined fdtfile and save for another patch - http://patchwork.ozlabs.org/patch/249084/ v3 - Updated based on comments - http://patchwork.ozlabs.org/patch/248687/ v2 - Updated with side bar maintainer comments. include/configs/dra7xx_evm.h |2 ++ include/configs/omap5_common.h |6 -- include/configs/omap5_uevm.h |1 + 3 files changed, 7 insertions(+), 2 deletions(-) [snip] #define CONFIG_SYS_PROMPTOMAP5430 EVM # Minor notice/question: why not take the opportunity and change the uEVM prompt to 'OMAP5432 EVM #'? It's not a 5430 actually... For the dra7xx board, for example, you are giving the particular DRA752 type. Best regards Lubomir ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: mx6qsabrelite: fsl_esdhc: Define maximum bus width supported by SabreLite board
Hi Abbas, On 03/25/2013 04:02 AM, Abbas Raza wrote: Hi, On 03/21/2013 09:17 PM, Eric Nelson wrote: Thanks Abbas, Tested-by: Eric Nelson eric.nel...@boundarydevices.com Note that the board settings also apply to nitrogen6x and wandboard if you want to expand the patch a bit: http://git.denx.de/u-boot.git/?p=u-boot/u-boot-imx.git;a=blob;f=board/boundary/nitrogen6x/nitrogen6x.c;h=229c2378396d43a365d6682af35c0e519ccd69d4;hb=HEAD#l304 http://git.denx.de/u-boot.git/?p=u-boot/u-boot-imx.git;a=blob;f=board/wandboard/wandboard.c;h=d95189f77de4c3573ec30c53e04fe1b083c1d2b5;hb=HEAD#l107 I would like to expand the patch but i cannot test it for boards you mentioned above. Are you sure these boards have 4-bit mmc buses? I'm certain about the Nitrogen6x. Less so about Wandboard. I think I looked it up, but can't recall precisely. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] arm: dra7xx: Update the EXTRA_ENV_SETTINGS
On 06/06/2013 03:31 PM, Lubomir Popov wrote: Hi Dan, Update the EXTRA_ENV_SETTING for the dra7xx. The console needs to be set to ttyO0 and the findfdt needs to be updated to load the dra7xx-evm.dtb file. Signed-off-by: Dan Murphy dmur...@ti.com --- v4 - Remove check for undefined fdtfile and save for another patch - http://patchwork.ozlabs.org/patch/249084/ v3 - Updated based on comments - http://patchwork.ozlabs.org/patch/248687/ v2 - Updated with side bar maintainer comments. include/configs/dra7xx_evm.h |2 ++ include/configs/omap5_common.h |6 -- include/configs/omap5_uevm.h |1 + 3 files changed, 7 insertions(+), 2 deletions(-) [snip] #define CONFIG_SYS_PROMPT OMAP5430 EVM # Minor notice/question: why not take the opportunity and change the uEVM prompt to 'OMAP5432 EVM #'? It's not a 5430 actually... For the dra7xx board, for example, you are giving the particular DRA752 type. Best regards Lubomir This is a patch for dra7xx. I can submit a new patch for the console change. Dan -- -- Dan Murphy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: omap5_uevm: Correct the console sys prompt for 5432
Correct the console sys prompt to display the correct processor and the corrent board Signed-off-by: Dan Murphy dmur...@ti.com Reported-by: Lubomir Popov lpo...@mm-sol.com --- include/configs/omap5_uevm.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h index 9e0339b..a333c79 100644 --- a/include/configs/omap5_uevm.h +++ b/include/configs/omap5_uevm.h @@ -54,7 +54,7 @@ #define CONFIG_PARTITION_UUIDS #define CONFIG_CMD_PART -#define CONFIG_SYS_PROMPT OMAP5430 EVM # +#define CONFIG_SYS_PROMPT OMAP5432 uEVM # #define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC 16296 #endif /* __CONFIG_OMAP5_EVM_H */ -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: mx6qsabrelite: fsl_esdhc: Define maximum bus width supported by SabreLite board
On Thu, Jun 6, 2013 at 5:25 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Hi Abbas, On 03/25/2013 04:02 AM, Abbas Raza wrote: Hi, On 03/21/2013 09:17 PM, Eric Nelson wrote: Thanks Abbas, Tested-by: Eric Nelson eric.nelson@boundarydevices.**comeric.nel...@boundarydevices.com Note that the board settings also apply to nitrogen6x and wandboard if you want to expand the patch a bit: http://git.denx.de/u-boot.git/**?p=u-boot/u-boot-imx.git;a=** blob;f=board/boundary/**nitrogen6x/nitrogen6x.c;h=** 229c2378396d43a365d6682af35c0e**519ccd69d4;hb=HEAD#l304http://git.denx.de/u-boot.git/?p=u-boot/u-boot-imx.git;a=blob;f=board/boundary/nitrogen6x/nitrogen6x.c;h=229c2378396d43a365d6682af35c0e519ccd69d4;hb=HEAD#l304 http://git.denx.de/u-boot.git/**?p=u-boot/u-boot-imx.git;a=** blob;f=board/wandboard/**wandboard.c;h=**d95189f77de4c3573ec30c53e04fe1* *b083c1d2b5;hb=HEAD#l107http://git.denx.de/u-boot.git/?p=u-boot/u-boot-imx.git;a=blob;f=board/wandboard/wandboard.c;h=d95189f77de4c3573ec30c53e04fe1b083c1d2b5;hb=HEAD#l107 I would like to expand the patch but i cannot test it for boards you mentioned above. Are you sure these boards have 4-bit mmc buses? I'm certain about the Nitrogen6x. Less so about Wandboard. I think I looked it up, but can't recall precisely. I can test a patch for Wandboard :) -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mx28evk: Convert to PHYLIB
From: Fabio Estevam fabio.este...@freescale.com
Phylib framework is more appropriate for handling the PHYs, so let's use it
on mx28evk.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx28evk/mx28evk.c | 7 +++
include/configs/mx28evk.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/board/freescale/mx28evk/mx28evk.c
b/board/freescale/mx28evk/mx28evk.c
index 4edd9f4..fc204fc 100644
--- a/board/freescale/mx28evk/mx28evk.c
+++ b/board/freescale/mx28evk/mx28evk.c
@@ -105,6 +105,13 @@ int board_mmc_init(bd_t *bis)
#endif
#ifdef CONFIG_CMD_NET
+int board_phy_config(struct phy_device *phydev)
+{
+ if (phydev-drv-config)
+ phydev-drv-config(phydev);
+
+ return 0;
+}
int board_eth_init(bd_t *bis)
{
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index de69182..a3e2c0e 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -176,6 +176,8 @@
#define CONFIG_MII
#define CONFIG_FEC_XCV_TYPERMII
#define CONFIG_MX28_FEC_MAC_IN_OCOTP
+#define CONFIG_PHYLIB
+#define CONFIG_PHY_SMSC
#endif
/* RTC */
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] phy: smsc: LAN8710/8720 are not Gbit PHYs
From: Fabio Estevam fabio.este...@freescale.com
LAN8710/8720 are 10/100 Mbps PHYs, so fix the '.features' field.
Cc: Joe Hershberger joe.hershber...@ni.com
Cc: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/net/phy/smsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index 6dee8eb..0c658f4 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -76,7 +76,7 @@ static struct phy_driver lan8710_driver = {
.name = SMSC LAN8710/LAN8720,
.uid = 0x0007c0f0,
.mask = 0x0,
- .features = PHY_GBIT_FEATURES,
+ .features = PHY_BASIC_FEATURES,
.config = genphy_config_aneg,
.startup = smsc_startup,
.shutdown = genphy_shutdown,
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Hi Ruud, On Fri, May 31, 2013 at 3:56 AM, Ruud Commandeur rcommand...@clb.nl wrote: Hi everyone, I have been testing for a while now on the i.mx28 evk, and I noticed that almost all tftp transfers take some time before they actually start. It will show a 'T' as first character, then followed by '#' Besides the initial timeout you mentioned, I also see some timeouts during the kernel transfer. I have just sent two patches converting mx28evk to use phylib, but I still see the timeouts there. I see that in the kernel there is a workaround for LAN8270 low por mode and I will try it when I have a chance. Please let me know if you make any progress on this. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx28evk: Convert to PHYLIB
Hi Stefano, On Thu, Jun 6, 2013 at 9:04 PM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com Phylib framework is more appropriate for handling the PHYs, so let's use it on mx28evk. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Please discard this one for now. I found an issue with this one. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Dear Fabio Estevam, Hi Ruud, On Fri, May 31, 2013 at 3:56 AM, Ruud Commandeur rcommand...@clb.nl wrote: Hi everyone, I have been testing for a while now on the i.mx28 evk, and I noticed that almost all tftp transfers take some time before they actually start. It will show a 'T' as first character, then followed by '#' Besides the initial timeout you mentioned, I also see some timeouts during the kernel transfer. I have just sent two patches converting mx28evk to use phylib, but I still see the timeouts there. I see that in the kernel there is a workaround for LAN8270 low por mode and I will try it when I have a chance. Please let me know if you make any progress on this. I'm also having issues when pulling stuff from my main system via TFTP sometimes. This is manifesting by _lots_ of timeouts. The problem in this case is some weirdness in e1000e in my system, after I force-switch the main system to 100baseT (using ethtool -s eth0 speed 100 duplex full), I no longer get timeouts (even after I force-switch it back to 1000baseT later). But I suspect this is some network issue on my end. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RESEND] video: exynos: change mipi dsi write function parameters correctly
The previous patches is broken, so I send again.
This patch have changed mipi dsi write functions' parameters correctly.
- exynos_mipi_dsi_wr_data()'s 3rd parameter is changed to
'const unsigned char' type.
- exynos_mipi_dsi_wr_tx_header()'s 3rd and 4th parameters were changed
to 'const unsigned char' type.
- s6e8ax0 panel driver does not use type cast operations to write
mipi dsi commands anymore.
- mipi dsi payload is composed with array of panel commands to improve
readability.
- removes unused variable of exynos_mipi_dsi_wr_data()
Signed-off-by: Donghwa Lee dh09@samsung.com
---
arch/arm/include/asm/arch-exynos/mipi_dsim.h |2 +-
drivers/video/exynos_mipi_dsi_common.c | 62
--
drivers/video/exynos_mipi_dsi_common.h |2 +-
drivers/video/exynos_mipi_dsi_lowlevel.c |2 +-
drivers/video/exynos_mipi_dsi_lowlevel.h |2 +-
drivers/video/s6e8ax0.c | 59
+---
6 files changed, 66 insertions(+), 63 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
index b73263d..afe7c08 100644
--- a/arch/arm/include/asm/arch-exynos/mipi_dsim.h
+++ b/arch/arm/include/asm/arch-exynos/mipi_dsim.h
@@ -304,7 +304,7 @@ struct exynos_platform_mipi_dsim {
*/
struct mipi_dsim_master_ops {
int (*cmd_write)(struct mipi_dsim_device *dsim, unsigned int data_id,
-unsigned int data0, unsigned int data1);
+const unsigned char *data0, unsigned int data1);
int (*cmd_read)(struct mipi_dsim_device *dsim, unsigned int data_id,
unsigned int data0, unsigned int data1);
int (*get_dsim_frame_done)(struct mipi_dsim_device *dsim);
diff --git a/drivers/video/exynos_mipi_dsi_common.c
b/drivers/video/exynos_mipi_dsi_common.c
index 6eeb464..1fc6102 100644
--- a/drivers/video/exynos_mipi_dsi_common.c
+++ b/drivers/video/exynos_mipi_dsi_common.c
@@ -63,7 +63,7 @@ static unsigned int dpll_table[15] = {
};
static void exynos_mipi_dsi_long_data_wr(struct mipi_dsim_device *dsim,
-unsigned int data0, unsigned int data1)
+const unsigned char *data0, unsigned int data1)
{
unsigned int data_cnt = 0, payload = 0;
@@ -75,42 +75,40 @@ static void exynos_mipi_dsi_long_data_wr(struct
mipi_dsim_device *dsim,
*/
if ((data1 - data_cnt) 4) {
if ((data1 - data_cnt) == 3) {
-payload = *(u8 *)(data0 + data_cnt) |
-(*(u8 *)(data0 + (data_cnt + 1))) 8 |
-(*(u8 *)(data0 + (data_cnt + 2))) 16;
+payload = data0[data_cnt] |
+data0[data_cnt + 1] 8 |
+data0[data_cnt + 2] 16;
debug(count = 3 payload = %x, %x %x %x\n,
-payload, *(u8 *)(data0 + data_cnt),
-*(u8 *)(data0 + (data_cnt + 1)),
-*(u8 *)(data0 + (data_cnt + 2)));
+payload, data0[data_cnt],
+data0[data_cnt + 1],
+data0[data_cnt + 2]);
} else if ((data1 - data_cnt) == 2) {
-payload = *(u8 *)(data0 + data_cnt) |
-(*(u8 *)(data0 + (data_cnt + 1))) 8;
+payload = data0[data_cnt] |
+data0[data_cnt + 1] 8;
debug(count = 2 payload = %x, %x %x\n, payload,
-*(u8 *)(data0 + data_cnt),
-*(u8 *)(data0 + (data_cnt + 1)));
+data0[data_cnt], data0[data_cnt + 1]);
} else if ((data1 - data_cnt) == 1) {
-payload = *(u8 *)(data0 + data_cnt);
+payload = data0[data_cnt];
}
} else {
/* send 4bytes per one time. */
-payload = *(u8 *)(data0 + data_cnt) |
-(*(u8 *)(data0 + (data_cnt + 1))) 8 |
-(*(u8 *)(data0 + (data_cnt + 2))) 16 |
-(*(u8 *)(data0 + (data_cnt + 3))) 24;
+payload = data0[data_cnt] |
+data0[data_cnt + 1] 8 |
+data0[data_cnt + 2] 16 |
+data0[data_cnt + 3] 24;
debug(count = 4 payload = %x, %x %x %x %x\n,
payload, *(u8 *)(data0 + data_cnt),
-*(u8 *)(data0 + (data_cnt + 1)),
-*(u8 *)(data0 + (data_cnt + 2)),
-*(u8 *)(data0 + (data_cnt + 3)));
-
+data0[data_cnt + 1],
+data0[data_cnt + 2],
+data0[data_cnt + 3]);
}
exynos_mipi_dsi_wr_tx_data(dsim, payload);
}
}
int exynos_mipi_dsi_wr_data(struct mipi_dsim_device *dsim, unsigned
int data_id,
-unsigned int data0, unsigned int data1)
+const unsigned char *data0, unsigned int data1)
{
unsigned int timeout = TRY_GET_FIFO_TIMEOUT;
unsigned long delay_val, delay;
@@ -149,8 +147,8 @@ int exynos_mipi_dsi_wr_data(struct mipi_dsim_device
*dsim, unsigned int data_id,
case
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Hi Marek, On Thu, Jun 6, 2013 at 10:25 PM, Marek Vasut ma...@denx.de wrote: I'm also having issues when pulling stuff from my main system via TFTP sometimes. This is manifesting by _lots_ of timeouts. The problem in this case is some weirdness in e1000e in my system, after I force-switch the main system to 100baseT (using ethtool -s eth0 speed 100 duplex full), I no longer get timeouts (even after I force-switch it back to 1000baseT later). But I suspect this is some network issue on my end. Does this only happen when you use mx28 board or with any board? In my case I get the timeouts only on mx28. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Dear Fabio Estevam, Hi Marek, On Thu, Jun 6, 2013 at 10:25 PM, Marek Vasut ma...@denx.de wrote: I'm also having issues when pulling stuff from my main system via TFTP sometimes. This is manifesting by _lots_ of timeouts. The problem in this case is some weirdness in e1000e in my system, after I force-switch the main system to 100baseT (using ethtool -s eth0 speed 100 duplex full), I no longer get timeouts (even after I force-switch it back to 1000baseT later). But I suspect this is some network issue on my end. Does this only happen when you use mx28 board or with any board? In my case I get the timeouts only on mx28. Most of the boards have this issue ... at least all of those that use 100baseT ethernet. Those 10baseT (I have such boards!) don't have this problem I think, but that might be because they're usually catching dust ;-D Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] README: Document support for Plan 9
Signed-off-by: Steven Stallion sstall...@gmail.com --- README |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/README b/README index b1b3e17..9782bb8 100644 --- a/README +++ b/README @@ -4636,9 +4636,9 @@ details; basically, the header defines the following image properties: * Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD, 4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, - LynxOS, pSOS, QNX, RTEMS, INTEGRITY; + LynxOS, pSOS, QNX, RTEMS, INTEGRITY, Plan 9 from Bell Labs; Currently supported: Linux, NetBSD, VxWorks, QNX, RTEMS, LynxOS, - INTEGRITY). + INTEGRITY, Plan 9 from Bell Labs). * Target CPU Architecture (Provisions for Alpha, ARM, AVR32, Intel x86, IA64, MIPS, NDS32, Nios II, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit; Currently supported: ARM, AVR32, Intel x86, MIPS, NDS32, Nios II, PowerPC). -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] uboot ERROR nfs: Cannot umount error
Hi, Recently, after successfully adding my ethernet driver to u-boot-2011.09, I tried to use u-boot's tftpboot and nfs command to test my driver, with tftpboot command, no matter how many times to test, there's no problem. But, with nfs command, if I did not add the board's ip address to nfs server(Ubuntu linux PC)'s /etc/hosts, there was always a Cannot umount error, although the data loading was right. With the help of wireshark, I found that if didn't add board's ip to /etc/hosts, after the umount call from board, nfs server(Ubuntu linux PC) tried to start a mDNS processing(something like query x.x.167.10.in-addr.arpa), but there is not xDNS server in my network enviroment, so it fails, and during these time, umount call timeout happened twice. And after the failing of mDNS, the nfs server replied board's umount call, but with a wrong rpc id number, because the last rpc id holded by u-boot was added(because of the timeout of umount call), but nfs server didn't. I can fix it by adding board's ip to nfs server PC's /etc/hosts. But the problem is: if there is a Cannot umount error(NetState = NETLOOP_FAIL), the net core does not call the halt function of the driver, that means the ethernet driver is still working. But before the loading(starting) of linux image, all DMA devices(my NIC is one of them) should be quieted. I wanted to know, Why we do not call ethernet driver's halt function if there was a Cannot umount error? (I am so sorry that I do not know whether I send this mail to the right mail address, I couldn't find net or nfs's maintainer from u-boot/MAINTAINERS, it seems only boards' maintainers are there, so this mail to mail addresses contains in nfs.c and net.c. If it is wrong, and anyone knows the right ones, please give me a help, I will fix it. Thanks) Best regards ShiJinghui ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9
This patch introduces support for command line arguments to Plan 9.
Plan 9 generally dedicates a small region of kernel memory (known
as CONFADDR) for runtime configuration. A new environment variable
named confaddr was introduced to indicate this location when copying
arguments.
Signed-off-by: Steven Stallion sstall...@gmail.com
---
common/cmd_bootm.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 05130b6..5c62271 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1533,6 +1533,7 @@ static int do_bootm_plan9(int flag, int argc, char *
const argv[],
bootm_headers_t *images)
{
void (*entry_point)(void);
+ char *s;
if ((flag != 0) (flag != BOOTM_STATE_OS_GO))
return 1;
@@ -1544,6 +1545,24 @@ static int do_bootm_plan9(int flag, int argc, char *
const argv[],
}
#endif
+ if ((s = getenv(confaddr)) != NULL) {
+ char *confaddr = (char *)simple_strtoul(s, NULL, 16);
+
+ if (argc 2) {
+ int i;
+
+ s = confaddr;
+ for (i = 2; i argc; i++) {
+ if (i 2)
+ *s++ = '\n';
+ strcpy(s, argv[i]);
+ s += strlen(argv[i]);
+ }
+ } else if ((s = getenv(bootargs)) != NULL) {
+ strcpy(confaddr, s);
+ }
+ }
+
entry_point = (void (*)(void))images-ep;
printf(## Transferring control to Plan 9 (at address %08lx) ...\n,
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
