[U-Boot] [PATCH 1/2] qe: transform parameter to compatible type
when using printf, the parameter type need to be compatible
type, so transform them to compatible type
Signed-off-by: Zhao Qiang
---
drivers/qe/qe.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/qe/qe.c b/drivers/qe/qe.c
index 84e1433..f1df0a4 100644
--- a/drivers/qe/qe.c
+++ b/drivers/qe/qe.c
@@ -313,9 +313,10 @@ static void qe_upload_microcode(const void *base,
if (ucode->major || ucode->minor || ucode->revision)
printf("QE: uploading microcode '%s' version %u.%u.%u\n",
- ucode->id, ucode->major, ucode->minor, ucode->revision);
+ (char *)ucode->id, (u16)ucode->major, (u16)ucode->minor,
+ (u16)ucode->revision);
else
- printf("QE: uploading microcode '%s'\n", ucode->id);
+ printf("QE: uploading microcode '%s'\n", (char *)ucode->id);
/* Use auto-increment */
out_be32(&qe_immr->iram.iadd, be32_to_cpu(ucode->iram_offset) |
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add spi nand support in u-boot
On 4 May 2015 at 06:19, Peter Pan 潘栋 (peterpandong) wrote: > Hi All, > > I’d like to add spi nand support in u-boot. But I don’t know where should > the spi nand drivers put in and how to define the architecture. > > I find that currently spi_flash in u-boot means spi nor flash. Should I create > a struct spi_nand_flash or make spi_flash compatible? You have asked this again! check this[1] [1] https://www.mail-archive.com/u-boot@lists.denx.de/msg171066.html thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] qe: use strncpy instead of strcpy
strncpy is safer than strcpy, use it to instead of strcpy. Signed-off-by: Zhao Qiang --- drivers/qe/qe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/qe/qe.c b/drivers/qe/qe.c index f1df0a4..08620b2 100644 --- a/drivers/qe/qe.c +++ b/drivers/qe/qe.c @@ -435,7 +435,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware) * saved microcode information and put in the new. */ memset(&qe_firmware_info, 0, sizeof(qe_firmware_info)); - strcpy(qe_firmware_info.id, (char *)firmware->id); + strncpy(qe_firmware_info.id, (char *)firmware->id, 62); qe_firmware_info.extended_modes = firmware->extended_modes; memcpy(qe_firmware_info.vtraps, firmware->vtraps, sizeof(firmware->vtraps)); -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] net: Remove all calls to net_random_ethaddr()
Hi Joe,
Am 2015-05-04 21:55, schrieb Joe Hershberger:
diff --git a/board/buffalo/lsxl/lsxl.c b/board/buffalo/lsxl/lsxl.c
index 487875c..45dd788 100644
--- a/board/buffalo/lsxl/lsxl.c
+++ b/board/buffalo/lsxl/lsxl.c
@@ -230,16 +230,6 @@ static void rescue_mode(void)
uchar enetaddr[6];
printf("Entering rescue mode..\n");
-#ifdef CONFIG_RANDOM_MACADDR
- if (!eth_getenv_enetaddr("ethaddr", enetaddr)) {
- net_random_ethaddr(enetaddr);
- if (eth_setenv_enetaddr("ethaddr", enetaddr)) {
- printf("Failed to set ethernet address\n");
- set_led(LED_ALARM_BLINKING);
- return;
- }
- }
-#endif
setenv("bootsource", "rescue");
}
NAK.
You removed the "set_led(LED_ALARM_BLINKING)". (Mh, I've just
discovered, that there is an indentation error). This is very important
for this board, because there is no other feedback to the user than the
LED. Remember, there is no serial console by default for this board.
Please provide some kind of callback where you can move the sed_led()
call to.
-michael
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] qe: use strncpy instead of strcpy
Hi On Tue, May 5, 2015 at 3:53 PM, Zhao Qiang wrote: > strncpy is safer than strcpy, use it to instead of strcpy. > > Signed-off-by: Zhao Qiang > --- > drivers/qe/qe.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/qe/qe.c b/drivers/qe/qe.c > index f1df0a4..08620b2 100644 > --- a/drivers/qe/qe.c > +++ b/drivers/qe/qe.c > @@ -435,7 +435,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware) > * saved microcode information and put in the new. > */ > memset(&qe_firmware_info, 0, sizeof(qe_firmware_info)); > - strcpy(qe_firmware_info.id, (char *)firmware->id); > + strncpy(qe_firmware_info.id, (char *)firmware->id, 62); is 62 somenthing that can be calculated? > qe_firmware_info.extended_modes = firmware->extended_modes; > memcpy(qe_firmware_info.vtraps, firmware->vtraps, > sizeof(firmware->vtraps)); > -- > 2.1.0.27.g96db324 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] mmc: Fix typo in MMC type checking macro
Hi Andrew, > On Mar 19, 2015, at 14:44 , Andrew Gabbasov > wrote: > > The version flag constant name used in IS_MMC macro is incorrect/undefined. > > Signed-off-by: Andrew Gabbasov > --- > include/mmc.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/mmc.h b/include/mmc.h > index 2ad0f19..a251531 100644 > --- a/include/mmc.h > +++ b/include/mmc.h > @@ -61,7 +61,7 @@ > #define SD_DATA_4BIT 0x0004 > > #define IS_SD(x) ((x)->version & SD_VERSION_SD) > -#define IS_MMC(x)((x)->version & SD_VERSION_MMC) > +#define IS_MMC(x)((x)->version & MMC_VERSION_MMC) > > #define MMC_DATA_READ 1 > #define MMC_DATA_WRITE2 > -- > 2.1.0 > Thanks, applied. BTW, please make sure you CC me personally when sending patches since this slipped out of my attention. Regards — Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] mmc: Avoid extra duplicate entry in mmc device structure
Hi Andrw,
> On Mar 19, 2015, at 14:44 , Andrew Gabbasov
> wrote:
>
> The 'op_cond_response' field in mmc structure contains the response
> from the last SEND_OP_COND MMC command while making iterational
> polling of the card. Later it is copied to 'ocr' field, designed
> to contain the OCR register value, which is actually the same
> response from the same command. So, these fields have actually
> the same data, just in different time periods. It's easier to use
> the same 'ocr' field in both cases at once, without temporary using
> of the 'op_cond_response' field.
>
> Signed-off-by: Andrew Gabbasov
> ---
> drivers/mmc/mmc.c | 13 +++--
> include/mmc.h | 1 -
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index a13769e..fe00a19 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -362,8 +362,8 @@ static int mmc_send_op_cond_iter(struct mmc *mmc, struct
> mmc_cmd *cmd,
> if (use_arg && !mmc_host_is_spi(mmc)) {
> cmd->cmdarg =
> (mmc->cfg->voltages &
> - (mmc->op_cond_response & OCR_VOLTAGE_MASK)) |
> - (mmc->op_cond_response & OCR_ACCESS_MODE);
> + (mmc->ocr & OCR_VOLTAGE_MASK)) |
> + (mmc->ocr & OCR_ACCESS_MODE);
>
> if (mmc->cfg->host_caps & MMC_MODE_HC)
> cmd->cmdarg |= OCR_HCS;
> @@ -371,7 +371,7 @@ static int mmc_send_op_cond_iter(struct mmc *mmc, struct
> mmc_cmd *cmd,
> err = mmc_send_cmd(mmc, cmd, NULL);
> if (err)
> return err;
> - mmc->op_cond_response = cmd->response[0];
> + mmc->ocr = cmd->response[0];
> return 0;
> }
>
> @@ -391,7 +391,7 @@ static int mmc_send_op_cond(struct mmc *mmc)
> return err;
>
> /* exit if not busy (flag seems to be inverted) */
> - if (mmc->op_cond_response & OCR_BUSY)
> + if (mmc->ocr & OCR_BUSY)
> return 0;
> }
> return IN_PROGRESS;
> @@ -413,7 +413,7 @@ static int mmc_complete_op_cond(struct mmc *mmc)
> if (get_timer(start) > timeout)
> return UNUSABLE_ERR;
> udelay(100);
> - } while (!(mmc->op_cond_response & OCR_BUSY));
> + } while (!(mmc->ocr & OCR_BUSY));
>
> if (mmc_host_is_spi(mmc)) { /* read OCR for spi */
> cmd.cmdidx = MMC_CMD_SPI_READ_OCR;
> @@ -424,10 +424,11 @@ static int mmc_complete_op_cond(struct mmc *mmc)
>
> if (err)
> return err;
> +
> + mmc->ocr = cmd.response[0];
> }
>
> mmc->version = MMC_VERSION_UNKNOWN;
> - mmc->ocr = cmd.response[0];
>
> mmc->high_capacity = ((mmc->ocr & OCR_HCS) == OCR_HCS);
> mmc->rca = 1;
> diff --git a/include/mmc.h b/include/mmc.h
> index a251531..644e3fa 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -356,7 +356,6 @@ struct mmc {
> char op_cond_pending; /* 1 if we are waiting on an op_cond command */
> char init_in_progress; /* 1 if we have done mmc_start_init() */
> char preinit; /* start init as early as possible */
> - uint op_cond_response; /* the response byte from the last op_cond */
> int ddr_mode;
> };
>
> --
> 2.1.0
Thanks, applied.
Regards
— Pantelis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] mmc: Do not pass external mmc_cmd structure to mmc_send_op_cond_iter()
Hi Andrew,
> On Mar 19, 2015, at 14:44 , Andrew Gabbasov
> wrote:
>
> The previous change to use 'ocr' structure field for storing send_op_cond
> command response also stopped using command response directly
> outside of mmc_send_op_cond_iter(). Now it becomes possible to use
> command structure in mmc_send_op_cond_iter() locally, removing a necessity
> to pass it as an argument from the caller.
>
> Signed-off-by: Andrew Gabbasov
> ---
> drivers/mmc/mmc.c | 24 +++-
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index fe00a19..d073d79 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -350,34 +350,32 @@ static int sd_send_op_cond(struct mmc *mmc)
> return 0;
> }
>
> -/* We pass in the cmd since otherwise the init seems to fail */
> -static int mmc_send_op_cond_iter(struct mmc *mmc, struct mmc_cmd *cmd,
> - int use_arg)
> +static int mmc_send_op_cond_iter(struct mmc *mmc, int use_arg)
> {
> + struct mmc_cmd cmd;
> int err;
>
> - cmd->cmdidx = MMC_CMD_SEND_OP_COND;
> - cmd->resp_type = MMC_RSP_R3;
> - cmd->cmdarg = 0;
> + cmd.cmdidx = MMC_CMD_SEND_OP_COND;
> + cmd.resp_type = MMC_RSP_R3;
> + cmd.cmdarg = 0;
> if (use_arg && !mmc_host_is_spi(mmc)) {
> - cmd->cmdarg =
> + cmd.cmdarg =
> (mmc->cfg->voltages &
> (mmc->ocr & OCR_VOLTAGE_MASK)) |
> (mmc->ocr & OCR_ACCESS_MODE);
>
> if (mmc->cfg->host_caps & MMC_MODE_HC)
> - cmd->cmdarg |= OCR_HCS;
> + cmd.cmdarg |= OCR_HCS;
> }
> - err = mmc_send_cmd(mmc, cmd, NULL);
> + err = mmc_send_cmd(mmc, &cmd, NULL);
> if (err)
> return err;
> - mmc->ocr = cmd->response[0];
> + mmc->ocr = cmd.response[0];
> return 0;
> }
>
> static int mmc_send_op_cond(struct mmc *mmc)
> {
> - struct mmc_cmd cmd;
> int err, i;
>
> /* Some cards seem to need this */
> @@ -386,7 +384,7 @@ static int mmc_send_op_cond(struct mmc *mmc)
> /* Asking to the card its capabilities */
> mmc->op_cond_pending = 1;
> for (i = 0; i < 2; i++) {
> - err = mmc_send_op_cond_iter(mmc, &cmd, i != 0);
> + err = mmc_send_op_cond_iter(mmc, i != 0);
> if (err)
> return err;
>
> @@ -407,7 +405,7 @@ static int mmc_complete_op_cond(struct mmc *mmc)
> mmc->op_cond_pending = 0;
> start = get_timer(0);
> do {
> - err = mmc_send_op_cond_iter(mmc, &cmd, 1);
> + err = mmc_send_op_cond_iter(mmc, 1);
> if (err)
> return err;
> if (get_timer(start) > timeout)
> --
> 2.1.0
Thanks, Applied.
— Pantelis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] nand: sunxi: change BLOCK_SIZE in mksunxiboot to match NAND block size
Ian Campbell writes:
> On Wed, 2015-04-29 at 17:02 +0200, Daniel Kochmański wrote:
>> This change is necessary to calculate correct checksum for NAND
>> boot. Works both for MMC and NAND. Without it BROM rejects boot image
>> as invalid (bad checksum). (Changes block size from 0x200 to 0x2000).
>
> I'm inferring here that for MMC boot this checksum is ignored by the
> BROM? If that is the case then I think it should be explicitly
> mentioned.
It isn't ignored, just larger block is taken into checksum and put in
header (which is read by BROM). I think, that in NAND case BROM just
ignores length field in header, and calculates checksum for whole page
(8KB), while on MMC it respects this field, hence 0x2000 works for
both.
I've tried to put garbage into checksum field, and MMC doesn't boot if
checksum isn't correct.
>
> As well as the checksum this also changes the header's length field,
> FWIW.
>
Yes, this is true. Should I change it to set block size conditionally
depending on defines - if it's SPL NAND boot, then use 0x2000, in other
occasion use 0x200? Whole `u-boot-sunxi-with-spl.bin` size doesn't
increase tough (probably because of space between spl and proper
u-boot).
>
>> Signed-off-by: Daniel Kochmański
>> Cc: Ian Campbell
>> Cc: Hans De Goede
>> ---
>>
>> tools/mksunxiboot.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
>> index 0035f6e..bef0c79 100644
>> --- a/tools/mksunxiboot.c
>> +++ b/tools/mksunxiboot.c
>> @@ -65,7 +65,7 @@ int gen_check_sum(struct boot_file_head *head_p)
>>
>> #define SUN4I_SRAM_SIZE 0x7600 /* 0x7748+ is used by BROM */
>> #define SRAM_LOAD_MAX_SIZE (SUN4I_SRAM_SIZE - sizeof(struct boot_file_head))
>> -#define BLOCK_SIZE 512
>> +#define BLOCK_SIZE 0x2000
>>
>> struct boot_img {
>> struct boot_file_head header;
--
Daniel Kochmański | Poznań, Poland
;; aka jackdaniel
"Be the change that you wish to see in the world." - Mahatma Gandhi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready
Hi Andrew, > On Mar 24, 2015, at 21:02 , Andrew Gabbasov > wrote: > >> From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] >> Sent: Tuesday, March 24, 2015 9:03 PM >> To: Gabbasov, Andrew; peng@freescale.com; u-boot@lists.denx.de >> Cc: Eric Nelson >> Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR >> only if it is still not ready >> >> On 3/24/2015 9:33 AM, Andrew Gabbasov wrote: >>> Hi Troy, >>> From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] Sent: Monday, March 23, 2015 11:09 PM To: Gabbasov, Andrew; peng@freescale.com; u-boot@lists.denx.de Cc: Eric Nelson Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready On 3/23/2015 12:38 AM, Andrew Gabbasov wrote: > Hi Troy, > >> From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] >> Sent: Friday, March 20, 2015 9:39 PM >> To: peng@freescale.com; Gabbasov, Andrew; u-boot@lists.denx.de >> Cc: Eric Nelson >> Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card >> for OCR only if it is still not ready >> >> [skipped] >> >> Here's another patch that solves the problem a little earlier. It >> has this disadvantage of being slightly bigger, though it makes the >> code look > better. >> >> https://github.com/boundarydevices/u-boot-imx6/commit/c0260ca >> > > I have a couple of doubts regarding that patch. > > First, my personal taste objects to such duplicating of the code (I > mean setting of version, ocr, rca, etc fields of mmc structure). > If we'll have to change or add anything to these settings, we'll > have to make the same change in 2 different place, which is > error-prone and extremely inconvenient from maintenance point of view. > > Second, what about SPI mode? Doesn't this patch skip retrieving of > OCR register with a special command for SPI host case (thus setting > ocr field incorrectly), if the card comes to ready state with the > first attempt? That's a good argument for a subroutine to be doing that work instead of >>> in two places. >>> >>> In some sense the second function of these two >>> (mmc_complete_op_cond()) is exactly such subroutine ;-) It is doing >>> this work of final settings and actions after making OCR polling. >>> Although completing the polling itself in some cases too. >>> Actually, it seems that introducing of one more service function would >>> make the code a little too "chopped" into too small pieces, and also >>> further less similar to SD (as opposed to MMC) case. >>> >>> Thanks. >>> >> >> I've already said that I'm fine with any patch that fixes the problem, so > there is >> no need to convince me of anything. I just wanted to show that setting the >> pending flag, when the command is actually complete, does not make a lot > of >> sense. > > I absolutely agree. In fact, this flag in current implementation just > indicates > the branch that the MMC card case is being processed. If the version field, > differing SD and MMC cases, would be set a little earlier, for example, > directly in mmc_start_init(), we could just use !IS_SD() instead of this > pending flag. And thinking further, it's not quite clear why the splitting > of OCR polling was done for MMC case only, but not for SD too. > So, there is still the room for further improving the code, may be even > some reorganizing, but I had to stop somewhere, unless there is > the direct necessity ;-) > Your patch fixes the current problem nicely. There is a lot of cruft around, we’ll get around looking it at some point in the future (yeah, maybe) :) Thanks for the good work, it’s fine as it is right now. > Thanks. > > Best regards, > Andrew > Regards — Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready
Hi Andrew,
> On Mar 19, 2015, at 14:44 , Andrew Gabbasov
> wrote:
>
> Some MMC cards come to ready state quite quickly, so that the respective
> flag appears to be set in mmc_send_op_cond already. In this case trying
> to continue polling the card with CMD1 in mmc_complete_op_cond is incorrect
> and may lead to unpredictable results. So check the flag before polling
> and skip it appropriately.
>
> Signed-off-by: Andrew Gabbasov
> ---
> drivers/mmc/mmc.c | 20 +++-
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index d073d79..42af47c 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -403,15 +403,17 @@ static int mmc_complete_op_cond(struct mmc *mmc)
> int err;
>
> mmc->op_cond_pending = 0;
> - start = get_timer(0);
> - do {
> - err = mmc_send_op_cond_iter(mmc, 1);
> - if (err)
> - return err;
> - if (get_timer(start) > timeout)
> - return UNUSABLE_ERR;
> - udelay(100);
> - } while (!(mmc->ocr & OCR_BUSY));
> + if (!(mmc->ocr & OCR_BUSY)) {
> + start = get_timer(0);
> + do {
> + err = mmc_send_op_cond_iter(mmc, 1);
> + if (err)
> + return err;
> + if (get_timer(start) > timeout)
> + return UNUSABLE_ERR;
> + udelay(100);
> + } while (!(mmc->ocr & OCR_BUSY));
> + }
>
> if (mmc_host_is_spi(mmc)) { /* read OCR for spi */
> cmd.cmdidx = MMC_CMD_SPI_READ_OCR;
> --
> 2.1.0
>
Thanks, Applied.
— Pantelis
PS. Peng, I’m picking up this instead of your patch.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] mmc: Restructure polling loops to avoid extra delays
Hi Andrew,
> On Mar 19, 2015, at 14:44 , Andrew Gabbasov
> wrote:
>
> The polling loops in sd_send_op_cond and mmc_complete_op_cond functions
> check the ready flag state at the end of the loop, that is after executing
> a delay inside the loop, which, in case of exiting with no error,
> is not needed. Also, one of these loops, as well as the loop
> in mmc_send_status, have the delay just before exiting on timeout
> conditions.
>
> Restructure all these loops to check the respective conditions before making
> a delay for the next loop pass, and to appropriately exit without the delay.
>
> Signed-off-by: Andrew Gabbasov
> ---
> drivers/mmc/mmc.c | 27 +--
> 1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 42af47c..b81533c 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -118,7 +118,7 @@ int mmc_send_status(struct mmc *mmc, int timeout)
> if (!mmc_host_is_spi(mmc))
> cmd.cmdarg = mmc->rca << 16;
>
> - do {
> + while (1) {
> err = mmc_send_cmd(mmc, &cmd, NULL);
> if (!err) {
> if ((cmd.response[0] & MMC_STATUS_RDY_FOR_DATA) &&
> @@ -135,9 +135,11 @@ int mmc_send_status(struct mmc *mmc, int timeout)
> } else if (--retries < 0)
> return err;
>
> - udelay(1000);
> + if (timeout-- <= 0)
> + break;
>
> - } while (timeout--);
> + udelay(1000);
> + }
>
> #ifdef CONFIG_MMC_TRACE
> status = (cmd.response[0] & MMC_STATUS_CURR_STATE) >> 9;
> @@ -291,7 +293,7 @@ static int sd_send_op_cond(struct mmc *mmc)
> int err;
> struct mmc_cmd cmd;
>
> - do {
> + while (1) {
> cmd.cmdidx = MMC_CMD_APP_CMD;
> cmd.resp_type = MMC_RSP_R1;
> cmd.cmdarg = 0;
> @@ -322,11 +324,14 @@ static int sd_send_op_cond(struct mmc *mmc)
> if (err)
> return err;
>
> - udelay(1000);
> - } while ((!(cmd.response[0] & OCR_BUSY)) && timeout--);
> + if (cmd.response[0] & OCR_BUSY)
> + break;
>
> - if (timeout <= 0)
> - return UNUSABLE_ERR;
> + if (timeout-- <= 0)
> + return UNUSABLE_ERR;
> +
> + udelay(1000);
> + }
>
> if (mmc->version != SD_VERSION_2)
> mmc->version = SD_VERSION_1_0;
> @@ -405,14 +410,16 @@ static int mmc_complete_op_cond(struct mmc *mmc)
> mmc->op_cond_pending = 0;
> if (!(mmc->ocr & OCR_BUSY)) {
> start = get_timer(0);
> - do {
> + while (1) {
> err = mmc_send_op_cond_iter(mmc, 1);
> if (err)
> return err;
> + if (mmc->ocr & OCR_BUSY)
> + break;
> if (get_timer(start) > timeout)
> return UNUSABLE_ERR;
> udelay(100);
> - } while (!(mmc->ocr & OCR_BUSY));
> + }
> }
>
> if (mmc_host_is_spi(mmc)) { /* read OCR for spi */
> --
> 2.1.0
Thanks, Applied.
— Pantelis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fix OCR Polling
Hi Peng, > On Mar 19, 2015, at 10:22 , Peng Fan wrote: > > If in mmc_send_op_cond, OCR_BUSY is set in CMD1's response, then > state is transfered to Ready state, and there is no need to send > CMD1 again. Otherwise following CMD1 will recieve no response, or > timeour error from driver such as fsl_esdhc.c. > > If not into Ready state in previous CMD1, then continue CMD1 command. > > In mmc_complete_op_cond, we use the value mmc->op_cond_response > from mmc_send_op_cond, since there should be no CMD1 command between > mmc_send_op_cond and mmc_complete_op_cond > > Before fixing this, uboot log shows: > " > CMD_SEND:0 >ARG 0x >MMC_RSP_NONE > CMD_SEND:8 >ARG 0x01AA >MMC_RSP_R1,5,6,7 0x18EC1504 > CMD_SEND:55 >ARG 0x >MMC_RSP_R1,5,6,7 0x18EC1504 > CMD_SEND:0 >ARG 0x >MMC_RSP_NONE > CMD_SEND:1 >ARG 0x >MMC_RSP_R3,4 0x00FF8080 > CMD_SEND:1 >ARG 0x4030 >MMC_RSP_R3,4 0xC0FF8080 --> Already OCR_BUSY set > CMD_SEND:1 >ARG 0x4030 >MMC_RSP_R3,4 0x0096850A --> Failed CMD1 > MMC init failed > " > > Using this patch, this issue is fixed, emmc can be detected correctly. > > > Signed-off-by: Peng Fan > --- > drivers/mmc/mmc.c | 13 +++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > Thanks for the patch, but Andrew’s patchset is more complete. I’ll pick up his fix instead. Regards — Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] mmc: Fix splitting device initialization
Hi Andrew,
> On Mar 19, 2015, at 14:44 , Andrew Gabbasov
> wrote:
>
> Starting part of device initialization sets the init_in_progress flag
> only if the MMC card did not yet come to ready state and needs to continue
> polling. If the card is SD or if the MMC card became ready quickly,
> the flag is not set and (if using pre-initialization) the starting
> phase will be re-executed from mmc_init function.
>
> Set the init_in_progress flag in all non-error cases. Also, move flags
> setting statements around so that the flags are not set in error paths.
> Also, IN_PROGRESS return status becomes unnecessary, so get rid of it.
>
> Signed-off-by: Andrew Gabbasov
> ---
> drivers/mmc/mmc.c | 16
> include/mmc.h | 3 +--
> 2 files changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index b81533c..31f8647 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -387,7 +387,6 @@ static int mmc_send_op_cond(struct mmc *mmc)
> mmc_go_idle(mmc);
>
> /* Asking to the card its capabilities */
> - mmc->op_cond_pending = 1;
> for (i = 0; i < 2; i++) {
> err = mmc_send_op_cond_iter(mmc, i != 0);
> if (err)
> @@ -395,9 +394,10 @@ static int mmc_send_op_cond(struct mmc *mmc)
>
> /* exit if not busy (flag seems to be inverted) */
> if (mmc->ocr & OCR_BUSY)
> - return 0;
> + break;
> }
> - return IN_PROGRESS;
> + mmc->op_cond_pending = 1;
> + return 0;
> }
>
> static int mmc_complete_op_cond(struct mmc *mmc)
> @@ -1627,7 +1627,7 @@ int mmc_start_init(struct mmc *mmc)
> if (err == TIMEOUT) {
> err = mmc_send_op_cond(mmc);
>
> - if (err && err != IN_PROGRESS) {
> + if (err) {
> #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
> printf("Card did not respond to voltage select!\n");
> #endif
> @@ -1635,7 +1635,7 @@ int mmc_start_init(struct mmc *mmc)
> }
> }
>
> - if (err == IN_PROGRESS)
> + if (!err)
> mmc->init_in_progress = 1;
>
> return err;
> @@ -1645,6 +1645,7 @@ static int mmc_complete_init(struct mmc *mmc)
> {
> int err = 0;
>
> + mmc->init_in_progress = 0;
> if (mmc->op_cond_pending)
> err = mmc_complete_op_cond(mmc);
>
> @@ -1654,13 +1655,12 @@ static int mmc_complete_init(struct mmc *mmc)
> mmc->has_init = 0;
> else
> mmc->has_init = 1;
> - mmc->init_in_progress = 0;
> return err;
> }
>
> int mmc_init(struct mmc *mmc)
> {
> - int err = IN_PROGRESS;
> + int err = 0;
> unsigned start;
>
> if (mmc->has_init)
> @@ -1671,7 +1671,7 @@ int mmc_init(struct mmc *mmc)
> if (!mmc->init_in_progress)
> err = mmc_start_init(mmc);
>
> - if (!err || err == IN_PROGRESS)
> + if (!err)
> err = mmc_complete_init(mmc);
> debug("%s: %d, time %lu\n", __func__, err, get_timer(start));
> return err;
> diff --git a/include/mmc.h b/include/mmc.h
> index 644e3fa..fbcbe35 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -70,8 +70,7 @@
> #define UNUSABLE_ERR -17 /* Unusable Card */
> #define COMM_ERR -18 /* Communications Error */
> #define TIMEOUT -19
> -#define IN_PROGRESS -20 /* operation is in progress */
> -#define SWITCH_ERR -21 /* Card reports failure to switch mode */
> +#define SWITCH_ERR -20 /* Card reports failure to switch mode */
>
> #define MMC_CMD_GO_IDLE_STATE 0
> #define MMC_CMD_SEND_OP_COND 1
> --
> 2.1.0
Thanks, Applied.
— Pantelis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] qe: use strncpy instead of strcpy
On Tue, May 5, 2015 at 4:33 PM, Michael Trimarchi wrote: > -Original Message- > From: Michael Trimarchi [mailto:mich...@amarulasolutions.com] > Sent: Tuesday, May 05, 2015 4:33 PM > To: Zhao Qiang-B45475 > Cc: u-boot@lists.denx.de; Sun York-R58495 > Subject: Re: [U-Boot] [PATCH 2/2] qe: use strncpy instead of strcpy > > Hi > > On Tue, May 5, 2015 at 3:53 PM, Zhao Qiang wrote: > > strncpy is safer than strcpy, use it to instead of strcpy. > > > > Signed-off-by: Zhao Qiang > > --- > > drivers/qe/qe.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/qe/qe.c b/drivers/qe/qe.c index f1df0a4..08620b2 > > 100644 > > --- a/drivers/qe/qe.c > > +++ b/drivers/qe/qe.c > > @@ -435,7 +435,7 @@ int qe_upload_firmware(const struct qe_firmware > *firmware) > > * saved microcode information and put in the new. > > */ > > memset(&qe_firmware_info, 0, sizeof(qe_firmware_info)); > > - strcpy(qe_firmware_info.id, (char *)firmware->id); > > + strncpy(qe_firmware_info.id, (char *)firmware->id, 62); > > is 62 somenthing that can be calculated? The fireware->id is defined 62 bytes in the struct. > > > qe_firmware_info.extended_modes = firmware->extended_modes; > > memcpy(qe_firmware_info.vtraps, firmware->vtraps, > > sizeof(firmware->vtraps)); > > -- > > 2.1.0.27.g96db324 > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot Best Regards Zhao Qiang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] nand: sunxi: And a20_nandread command utilizing spl nand read driver
Hans de Goede writes:
> Hi,
>
> On 05/02/2015 04:26 PM, Ian Campbell wrote:
>> On Wed, 2015-04-29 at 17:03 +0200, Daniel Kochmański wrote:
>>> This patch adds a20_nandread command. It is simple function utilizing
>>> function from SPL nand driver `nand_spl_load_image`.
>>>
>>> Usage: a20_nandread
>>
>> This stuff should really be integrated with cmd_nand.c rather than
>> adding an adhoc SoC specific interface.
>
> I want to go even further and I see that this really needs to be integrated
> with the blkdev code so that one can just do:
>
> ls nand 0:1
>
> And things will just work, these way we can also just have the standard
> boot cmds from config_distro_bootcmd.h work rather then needing special
> nand boot commands.
>
> Regards,
>
> Hans
>
It was more a convenient function then proper integration. I'll look
into that, but it may take time - I'm quite unfamiliar with U-Boot nand
interface.
>
>
>>
>>>
>>> Signed-off-by: Daniel Kochmański
>>> Cc: Ian Campbell
>>> Cc: Hans De Goede
>>> ---
>>>
>>> common/Kconfig| 7 +++
>>> common/Makefile | 1 +
>>> common/cmd_a20_nandread.c | 27 +++
>>> 3 files changed, 35 insertions(+)
>>> create mode 100644 common/cmd_a20_nandread.c
>>>
>>> diff --git a/common/Kconfig b/common/Kconfig
>>> index 5d7e48a..8edabb6 100644
>>> --- a/common/Kconfig
>>> +++ b/common/Kconfig
>>> @@ -204,6 +204,13 @@ config CMD_NAND
>>> help
>>> NAND support.
>>>
>>> +config CMD_A20_NANDREAD
>>> + depends on SPL_NAND_SUPPORT
>>> + bool "a20_nandread"
>>> + help
>>> + NAND read support for A20 SoC. Depends on SPL driver.
>>> + Usage: a20_nandread
>>> +
>>> config CMD_SPI
>>> bool "sspi"
>>> help
>>> diff --git a/common/Makefile b/common/Makefile
>>> index fba3830..9286518 100644
>>> --- a/common/Makefile
>>> +++ b/common/Makefile
>>> @@ -138,6 +138,7 @@ obj-$(CONFIG_CMD_MMC) += cmd_mmc.o
>>> obj-$(CONFIG_CMD_MMC_SPI) += cmd_mmc_spi.o
>>> obj-$(CONFIG_MP) += cmd_mp.o
>>> obj-$(CONFIG_CMD_MTDPARTS) += cmd_mtdparts.o
>>> +obj-$(CONFIG_CMD_A20_NANDREAD) += cmd_a20_nandread.o
>>> obj-$(CONFIG_CMD_NAND) += cmd_nand.o
>>> obj-$(CONFIG_CMD_NET) += cmd_net.o
>>> obj-$(CONFIG_CMD_ONENAND) += cmd_onenand.o
>>> diff --git a/common/cmd_a20_nandread.c b/common/cmd_a20_nandread.c
>>> new file mode 100644
>>> index 000..7361be7
>>> --- /dev/null
>>> +++ b/common/cmd_a20_nandread.c
>>> @@ -0,0 +1,27 @@
>>> +#include
>>> +#include
>>> +
>>> +int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest);
>>> +
>>> +static int do_a20_nandread(cmd_tbl_t *cmdtp, int flag,
>>> + int argc, char *const argv[])
>>> +{
>>> + if (argc != 4) {
>>> + printf("usage: a20_nandread \n");
>>> + return 1;
>>> + }
>>> +
>>> + uint32_t dst = simple_strtoul(argv[1], NULL, 16);
>>> + uint32_t src = simple_strtoul(argv[2], NULL, 16);
>>> + uint32_t cnt = simple_strtoul(argv[3], NULL, 16);
>>> + printf("Loading 0x%08XB @ 0x%08X -> 0x%08X...\n", cnt, src, dst);
>>> + nand_spl_load_image(src, cnt, (void *)dst);
>>> + return 0;
>>> +}
>>> +
>>> +U_BOOT_CMD(
>>> + a20_nandread, CONFIG_SYS_MAXARGS, 3, do_a20_nandread,
>>> + "a20_nandread",
>>> + "[offset size bytes]\n"
>>> + " "
>>> +);
>>
>>
--
Daniel Kochmański | Poznań, Poland
;; aka jackdaniel
"Be the change that you wish to see in the world." - Mahatma Gandhi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] nand: sunxi: Add support for booting from internal NAND memory
(sorry for resending, used wrong mail here - not sure how mailing list
will handle that).
Ian Campbell writes:
> On Wed, 2015-04-29 at 17:02 +0200, Daniel Kochmański wrote:
>> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
>> index 88e3358..1a30684 100644
>> --- a/board/sunxi/Kconfig
>> +++ b/board/sunxi/Kconfig
>> @@ -239,6 +239,18 @@ config MMC_SUNXI_SLOT_EXTRA
>> slot or emmc on mmc1 - mmc3. Setting this to 1, 2 or 3 will enable
>> support for this.
>>
>> +config SPL_NAND_SUPPORT
>> +bool "SPL/NAND mode support"
>> +depends on SPL
>> +default n
>> +---help---
>> + This enables support for booting from NAND internal
>> + memory. U-Boot SPL doesn't detect where is it load from,
>> + therefore this option is needed to properly load image from
>> + flash. Option also disables MMC functionality on U-Boot due to
>> + initialization errors encountered, when both controllers are
>> + enabled.
>
> Is this last bit a bug in the s/w or a hardware thing? Does this mean
> that MMC is not available in the main u-boot image too when NAND support
> is enabled?
>
I'm not sure what is a reason, but controller can't initialize MMC when
SPL is loaded. MMC works in main u-boot allowing to boot from it and
perform any other option (rescan, part, info, etc.). It is only SPL
relevant.
>> +
>> config USB0_VBUS_PIN
>> string "Vbus enable pin for usb0 (otg)"
>> default ""
>> diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
>> index 43766e0..7ad7412 100644
>> --- a/board/sunxi/Makefile
>> +++ b/board/sunxi/Makefile
>> @@ -9,6 +9,7 @@
>> # SPDX-License-Identifier: GPL-2.0+
>> #
>> obj-y += board.o
>> +obj-$(CONFIG_NAND_SUNXI)+= nand.o
>
> CONFIG_SUNXI_NAND would be more consistent with the rest I think.
>
OK.
>> obj-$(CONFIG_SUNXI_GMAC)+= gmac.o
>> obj-$(CONFIG_SUNXI_AHCI)+= ahci.o
>
>> +void nand_set_clocks(void)
>> +{
>> +W32(PORTC_BASE + 0x48, 0x);
>
> u-boot style is to declare a struct which matches the register layout
> and to do something like:
> struct nand_ctrl_foo *mcf = (void *)NANCFLASHC_BASE;
>
> And use writel, set_bits, setclr_bits and friends.
OK, I'll read about it and try to adjust driver.
>
> Please also try and give sensible names to all the magic numbers, or at
> least include a comment explaining that these are magic numbers derived
> from $SOMEWHERE and we don't know what they mean (if that is the case).
>
> Both of these apply to several bits of the code too.
This work is mainly based on register guess-work from here:
http://rhombus-tech.net/allwinner_a10/A10_register_guide/A10_NAND/ - so
I can gather names from there and put them in source.
>
>> +W32(PORTC_BASE + 0x4C, 0x);
>> +W32(PORTC_BASE + 0x50, 0x222);
>> +W32(PORTC_BASE + 0x54, 0x2);
>> +W32(PORTC_BASE + 0x5C, 0x);
>> +W32(PORTC_BASE + 0x60, 0x1);
>> +W32(PORTC_BASE + 0x64, 0x5140);
>> +W32(PORTC_BASE + 0x68, 0x4016);
>> +
>> +uint32_t val = R32(CCMU_BASE + 0x60);
>> +W32(CCMU_BASE + 0x60, 0x2000 | val);
>> +val = R32(CCMU_BASE + 0x80);
>> +W32(CCMU_BASE + 0x80, val | 0x8000 | 0x1);
>> +}
>> +
>> +int initialized = 0;
>> +void nand_init(void)
>> +{
>> +initialized = 1;
>
> Please call this from somewhere during init e.g. board.c rather than
> from nand_read with a latch.
>
Sure.
>> +uint32_t val;
>> +nand_set_clocks();
>> +val = R32(NANDFLASHC_BASE + 0x00);
>> +/* CTL = (1<<0 <-EN1<<1 RESET) */
>> +W32(NANDFLASHC_BASE + 0x00, val | 0x3); /* enable and reset CTL */
>> +do {
>> +val = R32(NANDFLASHC_BASE + 0x00);
>> +if (val & (1<<1))
>> +break;
>> +} while (1);
>
> Potentially infinite loop?
>
> There were some similar instances below which had a t/o. Perhaps combine
> them all into a helper similar to the dram code's
> mctl_await_completion()?
>
Ok, I'll look into that.
>> +uint32_t ecc_errors = 0;
>> +
>> +/* read 0x400 bytes from real_addr to temp_buf */
>> +void nand_read_block(unsigned int real_addr, int syndrome)
>> +{
>> +uint32_t val;
>> +if (!initialized)
>> +nand_init();
>> +
>> +memset((void *)temp_buf, 0, 0x400); /* clear temp_buf */
>
> Can we not avoid going via this global temp_buf by setting DMAC_BASE +
> 0x308 to the correct address on each read?
>
I'll check this, I think I had problems with that, but if it works w/o
temp_buf on both SPL and main U-Boot builds, then I'll get rid of it.
> Ian.
--
Daniel Kochmański | Poznań, Poland
;; aka jackdaniel
"Be the change that you wish to see in the world." - Mahatma Gandhi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-arm/master
Hello Tom, The following changes since commit ace97d26176a3ebc9ec07738450de93eea35975c: Merge branch 'zynq' of git://www.denx.de/git/u-boot-microblaze (2015-04-29 06:46:33 -0400) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to b939689c7b87773c44275a578ffc8674a867e39d: Merge branch 'u-boot/master' into 'u-boot-arm/master' (2015-05-05 10:09:06 +0200) Albert ARIBAUD (1): Merge branch 'u-boot/master' into 'u-boot-arm/master' Alexander Merkle (2): fix ARM DCC support for ARMv7 based cores (e.g. CortexA) fix ARM DCC support for ARMv7 based cores (e.g. CortexA) Bryan Brinsko (1): ARMv7 TLB: Fixed TTBR0 and Table Descriptors to allow caching David Feng (1): Armv8: Initializing CNTVOFF_EL2 Valentine Barshak (1): ARM: cpu: Add ARMv7 barrier operations support Vitaly Andrianov (1): arm: implement find_next_zero_bit function arch/arm/cpu/armv7/cache_v7.c | 14 +++--- arch/arm/include/asm/armv7.h | 10 ++ arch/arm/include/asm/bitops.h | 43 --- arch/arm/include/asm/macro.h | 3 +++ arch/arm/include/asm/system.h | 37 + arch/arm/lib/cache-cp15.c | 14 ++ drivers/serial/arm_dcc.c | 4 ++-- include/configs/zynq-common.h | 1 - 8 files changed, 113 insertions(+), 13 deletions(-) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/9] PSCI v0.2 framework for ARMv8
Hi Albert, > -Original Message- > From: Arnab Basu [mailto:arnab_b...@rocketmail.com] > Apologies for the long delay, this is v2 of the series of patches that > creates a generic PSCI v0.2 framework for ARMv8. > > The first 3 patches refactor existing code so that ARMv7 PSCI, > ARMv8 spin-table and ARMv8 PSCI can coexist. > > The 4th patch modifies the spin table implementation for the ARMv8 > foundation model to create per cpu release addresses > > The next 5 patches create a generic framework for PSCI v0.2 in ARMv8. > > The implementation is modelled on the pre-existing PSCI v0.1 support in > ARMv7. > > PSCI support patches for the ARMv8 Foundation model that implement the > mandatory PSCI functions and enable PCSI will follow very soon. It's been long since Arnab posted this series. This works fine for me on ARMv8 foundation model and also with minor modifications on Freescale's LS2085A platform. Can this be merged to the u-boot tree or are we waiting for a v3 to be spun-out by Arnab. > > Arnab Basu (9): > ARM: PSCI: Update psci.h for psci v0.2 > ARM: PSCI: Alow arch specific DT patching > ARMv8/fsl-lsch3: Refactor spin-table code > vexpress_aemv8a: Add spin table handling with per cpu release > addresses > ARMv8: PSCI: Add linker section to hold PSCI code > ARMv8: PCSI: Add generic ARMv8 PSCI code > ARMv8: PSCI: Fixup the device tree for PSCI v0.2 > ARMv8: PSCI: Setup ARMv8 PSCI > ARMv8: PSCI: Enable SMC > > arch/arm/config.mk | 2 +- > arch/arm/cpu/armv7/virt-dt.c | 7 +- > arch/arm/cpu/armv8/Makefile| 4 +- > arch/arm/cpu/armv8/cpu-dt.c| 189 > + > arch/arm/cpu/armv8/cpu.c | 136 ++ > arch/arm/cpu/armv8/fsl-lsch3/fdt.c | 48 -- > arch/arm/cpu/armv8/psci.S | 168 > + > arch/arm/cpu/armv8/start.S | 141 --- > arch/arm/cpu/armv8/u-boot.lds | 30 ++ > arch/arm/include/asm/armv8/esr.h | 12 +++ > arch/arm/include/asm/armv8/mp.h| 36 +++ > arch/arm/include/asm/config.h | 1 + > arch/arm/include/asm/macro.h | 5 + > arch/arm/include/asm/psci.h| 42 - > arch/arm/include/asm/system.h | 7 ++ > arch/arm/lib/bootm-fdt.c | 11 ++- > arch/arm/lib/bootm.c | 3 + > include/configs/vexpress_aemv8a.h | 2 + > 18 files changed, 772 insertions(+), 72 deletions(-) create mode 100644 > arch/arm/cpu/armv8/cpu-dt.c create mode 100644 arch/arm/cpu/armv8/psci.S > create mode 100644 arch/arm/include/asm/armv8/esr.h create mode 100644 > arch/arm/include/asm/armv8/mp.h > > -- > 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: remove the MMC_MODE_HC flag
Hi Rob,
> On Mar 24, 2015, at 00:56 , Rob Herring wrote:
>
> High capacity support is not a host capability, but a device capability
> that is queried via the OCR. The flag in the operating conditions
> request argument can just be set unconditionally. This matches the Linux
> implementation.
>
> Signed-off-by: Rob Herring
> Cc: Pantelis Antoniou
> ---
> drivers/mmc/dw_mmc.c | 2 +-
> drivers/mmc/fsl_esdhc.c | 2 +-
> drivers/mmc/kona_sdhci.c | 1 -
> drivers/mmc/mmc.c| 7 ++-
> drivers/mmc/mvebu_mmc.c | 2 +-
> drivers/mmc/mxsmmc.c | 3 +--
> drivers/mmc/omap_hsmmc.c | 3 +--
> drivers/mmc/s3c_sdi.c| 2 +-
> drivers/mmc/s5p_sdhci.c | 1 -
> drivers/mmc/sh_mmcif.c | 2 +-
> drivers/mmc/sunxi_mmc.c | 2 +-
> drivers/mmc/tegra_mmc.c | 2 +-
> drivers/mmc/zynq_sdhci.c | 2 --
> include/mmc.h| 1 -
> 14 files changed, 11 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index 76fa0b0..53a8aca 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -388,7 +388,7 @@ int add_dwmci(struct dwmci_host *host, u32 max_clk, u32
> min_clk)
> host->cfg.host_caps |= MMC_MODE_4BIT;
> host->cfg.host_caps &= ~MMC_MODE_8BIT;
> }
> - host->cfg.host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz | MMC_MODE_HC;
> + host->cfg.host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
>
> host->cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
>
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index db4d251..f99ad47 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -620,7 +620,7 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg
> *cfg)
> return -1;
> }
>
> - cfg->cfg.host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT | MMC_MODE_HC;
> + cfg->cfg.host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT;
> #ifdef CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
> cfg->cfg.host_caps |= MMC_MODE_DDR_52MHz;
> #endif
> diff --git a/drivers/mmc/kona_sdhci.c b/drivers/mmc/kona_sdhci.c
> index f804f4c..3653d00 100644
> --- a/drivers/mmc/kona_sdhci.c
> +++ b/drivers/mmc/kona_sdhci.c
> @@ -121,7 +121,6 @@ int kona_sdhci_init(int dev_index, u32 min_clk, u32
> quirks)
> host->name = "kona-sdhci";
> host->ioaddr = reg_base;
> host->quirks = quirks;
> - host->host_caps = MMC_MODE_HC;
>
> if (init_kona_mmc_core(host)) {
> free(host);
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index a13769e..ea00753 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -359,15 +359,12 @@ static int mmc_send_op_cond_iter(struct mmc *mmc,
> struct mmc_cmd *cmd,
> cmd->cmdidx = MMC_CMD_SEND_OP_COND;
> cmd->resp_type = MMC_RSP_R3;
> cmd->cmdarg = 0;
> - if (use_arg && !mmc_host_is_spi(mmc)) {
> - cmd->cmdarg =
> + if (use_arg && !mmc_host_is_spi(mmc))
> + cmd->cmdarg = OCR_HCS |
> (mmc->cfg->voltages &
> (mmc->op_cond_response & OCR_VOLTAGE_MASK)) |
> (mmc->op_cond_response & OCR_ACCESS_MODE);
>
> - if (mmc->cfg->host_caps & MMC_MODE_HC)
> - cmd->cmdarg |= OCR_HCS;
> - }
> err = mmc_send_cmd(mmc, cmd, NULL);
> if (err)
> return err;
> diff --git a/drivers/mmc/mvebu_mmc.c b/drivers/mmc/mvebu_mmc.c
> index 8ca0904..056aef5 100644
> --- a/drivers/mmc/mvebu_mmc.c
> +++ b/drivers/mmc/mvebu_mmc.c
> @@ -418,7 +418,7 @@ static struct mmc_config mvebu_mmc_cfg = {
> .f_min = MVEBU_MMC_BASE_FAST_CLOCK / MVEBU_MMC_BASE_DIV_MAX,
> .f_max = MVEBU_MMC_CLOCKRATE_MAX,
> .voltages = MMC_VDD_32_33 | MMC_VDD_33_34,
> - .host_caps = MMC_MODE_4BIT | MMC_MODE_HS | MMC_MODE_HC |
> + .host_caps = MMC_MODE_4BIT | MMC_MODE_HS |
> MMC_MODE_HS_52MHz,
> .part_type = PART_TYPE_DOS,
> .b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
> diff --git a/drivers/mmc/mxsmmc.c b/drivers/mmc/mxsmmc.c
> index 2fa4eee..31fb3ab 100644
> --- a/drivers/mmc/mxsmmc.c
> +++ b/drivers/mmc/mxsmmc.c
> @@ -405,8 +405,7 @@ int mxsmmc_initialize(bd_t *bis, int id, int (*wp)(int),
> int (*cd)(int))
> priv->cfg.voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
>
> priv->cfg.host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT |
> - MMC_MODE_HS_52MHz | MMC_MODE_HS |
> - MMC_MODE_HC;
> + MMC_MODE_HS_52MHz | MMC_MODE_HS;
>
> /*
>* SSPCLK = 480 * 18 / 29 / 1 = 297.731 MHz
> diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
> index dc725cb..8238a7e 100644
> --- a/drivers/mmc/omap_hsmmc.c
> +++ b/drivers/mmc/omap_hsmmc.c
> @@ -651,8 +651,7 @@ int omap_mmc_init(int dev_index, uint host_caps_mask,
> uint f_max, int cd_gpio,
> if (priv_data == NULL)
> return -1;
>
> - host_caps_val = MMC_MODE_4BIT | MMC_MODE_HS_52MHz |
Re: [U-Boot] [PATCH] mmc: sdhci: add timeout setting for response busy command
Hi Rob,
> On Mar 24, 2015, at 00:57 , Rob Herring wrote:
>
> From: Kevin Liu
>
> Timeout interrupt also work for response busy command(R1b) like
> cmd38/cmd6. So need to set it accordingly. Current code only
> set timeout for data command.
>
> Signed-off-by: Kevin Liu
> Signed-off-by: Rob Herring
> Cc: Pantelis Antoniou
> ---
> drivers/mmc/sdhci.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index 78e958e..8faeca3 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -213,6 +213,8 @@ static int sdhci_send_command(struct mmc *mmc, struct
> mmc_cmd *cmd,
> SDHCI_BLOCK_SIZE);
> sdhci_writew(host, data->blocks, SDHCI_BLOCK_COUNT);
> sdhci_writew(host, mode, SDHCI_TRANSFER_MODE);
> + } else if (cmd->resp_type & MMC_RSP_BUSY) {
> + sdhci_writeb(host, 0xe, SDHCI_TIMEOUT_CONTROL);
> }
>
> sdhci_writel(host, cmd->cmdarg, SDHCI_ARGUMENT);
> --
> 2.1.0
>
Thanks, Applied.
— Pantelis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: mx6: tqma6: Fix USB and add other filesystems
Hi Stefano, On 12.03.2015 13:34, Stefan Roese wrote: This patch fixes the USB EHCI support on the TQMa6 SoM. Additionally some filesystems are added, included the generic FS commands (e.g. ls...). Signed-off-by: Stefan Roese Cc: Markus Niebel Cc: Stefano Babic --- include/configs/tqma6.h | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/include/configs/tqma6.h b/include/configs/tqma6.h index a099687..9022550 100644 --- a/include/configs/tqma6.h +++ b/include/configs/tqma6.h @@ -125,16 +125,19 @@ #define CONFIG_USB_STORAGE #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_SMSC95XX -#define CONFIG_MXC_USB_PORT1 #define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW) -#define CONFIG_MXC_USB_FLAGS 0 +#define CONFIG_USB_MAX_CONTROLLER_COUNT2 +#define CONFIG_EHCI_HCD_INIT_AFTER_RESET /* For OTG port */ /* Fuses */ #define CONFIG_MXC_OCOTP #define CONFIG_CMD_FUSE #define CONFIG_CMD_EXT2 +#define CONFIG_CMD_EXT4 +#define CONFIG_CMD_EXT4_WRITE #define CONFIG_CMD_FAT +#define CONFIG_CMD_FS_GENERIC #define CONFIG_DOS_PARTITION #define CONFIG_CMD_PING Ping on this patch. Markus has Ack'ed it. Could you please push it to Tom? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fsl_esdhc: update eMMC44 adapter card erase timeout
Hi Yango,
> On Apr 15, 2015, at 05:13 , Yangbo Lu wrote:
>
> Freescale eMMC44 adapter card uses Micron N2M400FDB311A3CF eMMC
> memory. According to the silicon datasheet, secure erase timeout
> is 600ms. So increase erase timeout value from 250ms to 600ms.
>
> Signed-off-by: Yangbo Lu
> Cc: York Sun
> ---
> drivers/mmc/fsl_esdhc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index f5d2ccb..e879fc0 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -344,9 +344,9 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
> struct mmc_data *data)
>
> /* Workaround for ESDHC errata ENGcm03648 */
> if (!data && (cmd->resp_type & MMC_RSP_BUSY)) {
> - int timeout = 2500;
> + int timeout = 6000;
>
> - /* Poll on DATA0 line for cmd with busy signal for 250 ms */
> + /* Poll on DATA0 line for cmd with busy signal for 600 ms */
> while (timeout > 0 && !(esdhc_read32(®s->prsstat) &
> PRSSTAT_DAT0)) {
> udelay(100);
> --
> 2.1.0.27.g96db324
Applied, Thanks.
— Pantelis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] mmc: bcm2835_sdhci: Use calloc to allocate bcm2835_sdhci_host
Hi Alexander,
> On Apr 17, 2015, at 18:33 , Alexander Stein wrote:
>
> We need to clear the allocated memory explicitly as the included
> struct sdhci_host has function pointers. Those are compared to NULL to
> test if this (optional) feature is supported. Leaving them undefined let
> u-boot jump to arbitrary memory.
>
> Signed-off-by: Alexander Stein
> ---
> drivers/mmc/bcm2835_sdhci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c
> index 92f7d89..127dbe3 100644
> --- a/drivers/mmc/bcm2835_sdhci.c
> +++ b/drivers/mmc/bcm2835_sdhci.c
> @@ -154,9 +154,9 @@ int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq)
> struct bcm2835_sdhci_host *bcm_host;
> struct sdhci_host *host;
>
> - bcm_host = malloc(sizeof(*bcm_host));
> + bcm_host = calloc(1, sizeof(*bcm_host));
> if (!bcm_host) {
> - printf("sdhci_host malloc fail!\n");
> + printf("sdhci_host calloc fail!\n");
> return 1;
> }
>
> --
> 2.3.5
>
Applied, Thanks.
— Pantelis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 23/24] tegra: mmc: Set the removable flag correctly
Hi Simon,
> On May 4, 2015, at 20:31 , Simon Glass wrote:
>
> If the mmc device is non-removable (as indicated by the device tree), set
> the flag so that users of the device know.
>
> Signed-off-by: Simon Glass
> ---
>
> drivers/mmc/tegra_mmc.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
> index 2cd8cf1..5c9c54a 100644
> --- a/drivers/mmc/tegra_mmc.c
> +++ b/drivers/mmc/tegra_mmc.c
> @@ -528,7 +528,7 @@ static const struct mmc_ops tegra_mmc_ops = {
> .getcd = tegra_mmc_getcd,
> };
>
> -static int do_mmc_init(int dev_index)
> +static int do_mmc_init(int dev_index, bool removable)
> {
> struct mmc_host *host;
> struct mmc *mmc;
> @@ -573,6 +573,7 @@ static int do_mmc_init(int dev_index)
> host->cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
>
> mmc = mmc_create(&host->cfg, host);
> + mmc->block_dev.removable = removable;
> if (mmc == NULL)
> return -1;
>
> @@ -586,7 +587,8 @@ static int do_mmc_init(int dev_index)
> * @param nodeDevice index (0-3)
> * @param hostStructure to fill in (reg, width, mmc_id)
> */
> -static int mmc_get_config(const void *blob, int node, struct mmc_host *host)
> +static int mmc_get_config(const void *blob, int node, struct mmc_host *host,
> + bool *removablep)
> {
> debug("%s: node = %d\n", __func__, node);
>
> @@ -619,6 +621,7 @@ static int mmc_get_config(const void *blob, int node,
> struct mmc_host *host)
> GPIOD_IS_IN);
> gpio_request_by_name_nodev(blob, node, "power-gpios", 0,
> &host->pwr_gpio, GPIOD_IS_OUT);
> + *removablep = !fdtdec_get_bool(blob, node, "non-removable");
>
> debug("%s: found controller at %p, width = %d, periph_id = %d\n",
> __func__, host->reg, host->width, host->mmc_id);
> @@ -636,6 +639,7 @@ static int mmc_get_config(const void *blob, int node,
> struct mmc_host *host)
> static int process_nodes(const void *blob, int node_list[], int count)
> {
> struct mmc_host *host;
> + bool removable;
> int i, node;
>
> debug("%s: count = %d\n", __func__, count);
> @@ -649,11 +653,11 @@ static int process_nodes(const void *blob, int
> node_list[], int count)
> host = &mmc_host[i];
> host->id = i;
>
> - if (mmc_get_config(blob, node, host)) {
> + if (mmc_get_config(blob, node, host, &removable)) {
> printf("%s: failed to decode dev %d\n", __func__, i);
> return -1;
> }
> - do_mmc_init(i);
> + do_mmc_init(i, removable);
> }
> return 0;
> }
> --
> 2.2.0.rc0.207.ga3a616c
>
Applied, thanks.
— Pantelis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: display: Align end of memory to work around a linux-4.0 bug
On Mon, May 04, 2015 at 10:36:43AM +0100, Ian Campbell wrote: > On Mon, 2015-05-04 at 10:51 +0200, Hans de Goede wrote: > > Hi, > > > > On 02-05-15 15:21, Ian Campbell wrote: > > > On Fri, 2015-04-24 at 20:39 +0200, Hans de Goede wrote: > > >> Linux-4.0 as shipped has a bug causing it to not boot if the end of > > >> memory > > >> is not aligned to a multiple of 2 MiB. For details see the linux-arm > > >> mailing list post titled: > > >> "Memory size unaligned to section boundary" > > >> http://www.spinics.net/lists/arm-kernel/msg413811.html > > >> > > >> This is something which specifically hits the sunxi display driver > > >> because > > >> we carve out the exact needed framebuffer size at the top of mem, this > > >> commit works around this issue by aligning the carve out. > > > > > > I'm afraid I don't like this, we shouldn't be working around Linux bugs > > > in the firmware, especially when both are Free software. Lets just fix > > > Linux and get the fix into the appropriate stable trees and in the > > > meantime tell people to avoid this buggy kernel. > > > > > > The problem with this sort of thing is that it is very hard to get rid > > > of these workarounds, even once the underlying issue is fixed and we no > > > longer care about the versions with the bug OS authors (including > > > non-Linux OSes) can inadvertently come to rely on the quirky behaviour, > > > (i.e. the work around masks other bugs). Hence we end up in a > > > quirks-race as everyone works around the other parties last workaround. > > > > > > If there is to be a workaround instead of a fix then it should be for > > > Linux to align memory to 2MB boundaries if that is what it requires. > > > > I can understand where you're coming from, the problem is that despite > > various mails to the arm kernel mailing list no one from the upstream > > kernel seems to be looking into this, > > Mark, do you think you could find some cycles (not necessarily your own) > to look at this, or perhaps you know the appropriate maintainers to > ping? I'll have another look and see if I can come up with a kernel patch. Perhaps proposing something (even if slightly wrong) will provoke people to respond. > I'd really like to avoid having to hack around kernel bugs in the > firmware. Likewise. Mark. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] qe: use strncpy instead of strcpy
Hi On Tue, May 5, 2015 at 5:15 PM, qiang.z...@freescale.com wrote: > On Tue, May 5, 2015 at 4:33 PM, Michael Trimarchi wrote: >> -Original Message- >> From: Michael Trimarchi [mailto:mich...@amarulasolutions.com] >> Sent: Tuesday, May 05, 2015 4:33 PM >> To: Zhao Qiang-B45475 >> Cc: u-boot@lists.denx.de; Sun York-R58495 >> Subject: Re: [U-Boot] [PATCH 2/2] qe: use strncpy instead of strcpy >> >> Hi >> >> On Tue, May 5, 2015 at 3:53 PM, Zhao Qiang wrote: >> > strncpy is safer than strcpy, use it to instead of strcpy. >> > >> > Signed-off-by: Zhao Qiang >> > --- >> > drivers/qe/qe.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/drivers/qe/qe.c b/drivers/qe/qe.c index f1df0a4..08620b2 >> > 100644 >> > --- a/drivers/qe/qe.c >> > +++ b/drivers/qe/qe.c >> > @@ -435,7 +435,7 @@ int qe_upload_firmware(const struct qe_firmware >> *firmware) >> > * saved microcode information and put in the new. >> > */ >> > memset(&qe_firmware_info, 0, sizeof(qe_firmware_info)); >> > - strcpy(qe_firmware_info.id, (char *)firmware->id); >> > + strncpy(qe_firmware_info.id, (char *)firmware->id, 62); >> >> is 62 somenthing that can be calculated? > > The fireware->id is defined 62 bytes in the struct. > and you don't like sizeof Michael > >> >> > qe_firmware_info.extended_modes = firmware->extended_modes; >> > memcpy(qe_firmware_info.vtraps, firmware->vtraps, >> > sizeof(firmware->vtraps)); >> > -- >> > 2.1.0.27.g96db324 >> > >> > ___ >> > U-Boot mailing list >> > U-Boot@lists.denx.de >> > http://lists.denx.de/mailman/listinfo/u-boot > Best Regards > Zhao Qiang -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ARM: mmc: bcm283x: Remove get_timer_us() from mmc driver
Hi Marek, > On May 4, 2015, at 23:54 , Marek Vasut wrote: > > The get_timer_us() function is something which is no longer > existing in case we use generic timer framework, so replace > it with get_timer(). > > Signed-off-by: Marek Vasut > Cc: Stephen Warren > Cc: Tyler Baker > --- > drivers/mmc/bcm2835_sdhci.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c > index 4ec2968..0f81add 100644 > --- a/drivers/mmc/bcm2835_sdhci.c > +++ b/drivers/mmc/bcm2835_sdhci.c > @@ -69,11 +69,11 @@ static inline void bcm2835_sdhci_raw_writel(struct > sdhci_host *host, u32 val, >* (Which is just as well - otherwise we'd have to nobble the DMA engine >* too) >*/ > - while (get_timer_us(bcm_host->last_write) < bcm_host->twoticks_delay) > + while (get_timer(bcm_host->last_write) < bcm_host->twoticks_delay) > ; > > writel(val, host->ioaddr + reg); > - bcm_host->last_write = get_timer_us(0); > + bcm_host->last_write = get_timer(0); > } > > static inline u32 bcm2835_sdhci_raw_readl(struct sdhci_host *host, int reg) > -- > 2.1.4 Applied, thanks. — Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] arm: mx6: tqma6: Update to optionally configure an alternative SPI setup
Hi Stefano,
On 12.03.2015 13:34, Stefan Roese wrote:
By making the tqma6_iomuxc_spi() weak, this patch adds the possibility to
add a different function for this SPI configuration. This can be used
by other baseboards, that might have a different SPI setup.
This patch will be used by the upcoming WRU-IV board support which also
uses the TQMa6 SoM.
Signed-off-by: Stefan Roese
---
board/tqc/tqma6/tqma6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c
index c9e163e..29db838 100644
--- a/board/tqc/tqma6/tqma6.c
+++ b/board/tqc/tqma6/tqma6.c
@@ -145,7 +145,7 @@ static unsigned const tqma6_ecspi1_cs[] = {
TQMA6_SF_CS_GPIO,
};
-static void tqma6_iomuxc_spi(void)
+__weak void tqma6_iomuxc_spi(void)
{
unsigned i;
Ping on this patch. Markus has Ack'ed it. Could you please push it to Tom?
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-mmc 05052015
Hi Tom, The following changes since commit ace97d26176a3ebc9ec07738450de93eea35975c: Merge branch 'zynq' of git://www.denx.de/git/u-boot-microblaze (2015-04-29 06:46:33 -0400) are available in the git repository at: git://git.denx.de/u-boot-mmc.git master for you to fetch changes up to 33fe2fb8df01647f97a7bce96a1c7781a7f6d253: ARM: mmc: bcm283x: Remove get_timer_us() from mmc driver (2015-05-05 12:29:42 +0300) Alexander Stein (1): mmc: bcm2835_sdhci: Use calloc to allocate bcm2835_sdhci_host Andrew Gabbasov (6): mmc: Fix typo in MMC type checking macro mmc: Avoid extra duplicate entry in mmc device structure mmc: Do not pass external mmc_cmd structure to mmc_send_op_cond_iter() mmc: Continue polling MMC card for OCR only if it is still not ready mmc: Restructure polling loops to avoid extra delays mmc: Fix splitting device initialization Kevin Liu (1): mmc: sdhci: add timeout setting for response busy command Marek Vasut (1): ARM: mmc: bcm283x: Remove get_timer_us() from mmc driver Rob Herring (1): mmc: remove the MMC_MODE_HC flag Simon Glass (1): tegra: mmc: Set the removable flag correctly Yangbo Lu (1): mmc: fsl_esdhc: update eMMC44 adapter card erase timeout drivers/mmc/bcm2835_sdhci.c | 8 drivers/mmc/dw_mmc.c| 2 +- drivers/mmc/fsl_esdhc.c | 6 +++--- drivers/mmc/kona_sdhci.c| 1 - drivers/mmc/mmc.c | 93 + drivers/mmc/mvebu_mmc.c | 2 +- drivers/mmc/mxsmmc.c| 3 +-- drivers/mmc/omap_hsmmc.c| 3 +-- drivers/mmc/s3c_sdi.c | 2 +- drivers/mmc/s5p_sdhci.c | 1 - drivers/mmc/sdhci.c | 2 ++ drivers/mmc/sh_mmcif.c | 2 +- drivers/mmc/sunxi_mmc.c | 2 +- drivers/mmc/tegra_mmc.c | 14 +- drivers/mmc/zynq_sdhci.c| 2 -- include/mmc.h | 9 +++-- 16 files changed, 77 insertions(+), 75 deletions(-) Regards — Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] misc: led: Add PCA9551 LED driver
Hi Tom, On 12.03.2015 12:50, Fabio Estevam wrote: On Thu, Mar 12, 2015 at 7:22 AM, Stefan Roese wrote: This patch adds a driver for the PCA9551 LED controller. Originated-by: Timo Herbrecher Signed-off-by: Stefan Roese Reviewed-by: Tom Rini Cc: Fabio Estevam Reviewed-by: Fabio Estevam Gentle ping on this patch. Could you please pull this one for the next release? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] nand: sunxi: And a20_nandread command utilizing spl nand read driver
Hi, On 05-05-15 11:17, Daniel Kochmański wrote: Hans de Goede writes: Hi, On 05/02/2015 04:26 PM, Ian Campbell wrote: On Wed, 2015-04-29 at 17:03 +0200, Daniel Kochmański wrote: This patch adds a20_nandread command. It is simple function utilizing function from SPL nand driver `nand_spl_load_image`. Usage: a20_nandread This stuff should really be integrated with cmd_nand.c rather than adding an adhoc SoC specific interface. I want to go even further and I see that this really needs to be integrated with the blkdev code so that one can just do: ls nand 0:1 And things will just work, these way we can also just have the standard boot cmds from config_distro_bootcmd.h work rather then needing special nand boot commands. Regards, Hans It was more a convenient function then proper integration. I understand but for upstream nand support we really want a proper solution, note that I'm find with having the nand support being read only, but it should really be integrated enough that things like: ls nand 0:1 Will work. I'll look into that, but it may take time - I'm quite unfamiliar with U-Boot nand interface. Thanks! Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] dm: usb: Copy over usb_device values from usb_scan_device() to final usb_device
Hi,
On 04-05-15 23:35, Simon Glass wrote:
On 4 May 2015 at 15:35, Simon Glass wrote:
Hi Hans,
On 4 May 2015 at 14:28, Simon Glass wrote:
On 4 May 2015 at 11:19, Hans de Goede wrote:
Currently we copy over a number of usb_device values stored in the on stack
struct usb_device probed in usb_scan_device() to the final driver-model managed
struct usb_device in usb_child_pre_probe() through usb_device_platdata, and
then call usb_select_config() to fill in the rest.
There are 3 problems with this approach:
1) It does not fill in enough fields before calling usb_select_config(),
specifically it does not fill in ep0's maxpacketsize causing a div by zero
exception in the ehci driver.
2) It unnecessarily redoes a number of usb requests making usb probing slower
3) Calling usb_select_config() a second time fails on some usb-1 devices
plugged into usb-2 hubs, causing u-boot to not recognize these devices.
This commit fixes these issues by removing the usb_select_config() call from
usb_child_pre_probe(), and instead of copying over things field by field
through usb_device_platdata, store a pointer to the in stack usb_device
(which is still valid when usb_child_pre_probe() gets called) and copy
over the entire struct.
Signed-off-by: Hans de Goede
Acked-by: Simon Glass
But sadly this fails with sandbox. Please do run the driver model tests.
Output:
02: dm: usb: Copy over usb_device values from usb_scan_device() to
final usb_device
sandbox: + sandbox
+../drivers/usb/emul/usb-emul-uclass.c: In function ‘usb_emul_find’:
+../drivers/usb/emul/usb-emul-uclass.c:125:11: error: ‘struct
usb_dev_platdata’ has no member named ‘devnum’
+ if (udev->devnum == devnum) {
+ ^
+In file included from ../drivers/usb/emul/usb-emul-uclass.c:8:0:
+../drivers/usb/emul/usb-emul-uclass.c:127:25: error: ‘struct
usb_dev_platdata’ has no member named ‘devnum’
+ dev->name, udev->devnum);
+ ^
+../include/common.h:109:26: note: in definition of macro ‘debug_cond’
+printf(pr_fmt(fmt), ##args); \
+ ^
+../drivers/usb/emul/usb-emul-uclass.c:126:4: note: in expansion of
macro ‘debug’
+debug("%s: Found emulator '%s', addr %d\n", __func__,
+^
+../drivers/usb/emul/usb-emul-uclass.c: In function ‘usb_emul_control’:
+../drivers/usb/emul/usb-emul-uclass.c:168:8: error: ‘struct
usb_dev_platdata’ has no member named ‘devnum’
+plat->devnum = setup->value;
+^
+../drivers/usb/emul/usb-emul-uclass.c: In function ‘usb_emul_reset’:
+../drivers/usb/emul/usb-emul-uclass.c:253:6: error: ‘struct
usb_dev_platdata’ has no member named ‘devnum’
+ plat->devnum = 0;
+ ^
Oops sorry about that, I'll try to learn myself to always run dm-test.sh
after making dm related changes.
Fixing this was a bit trickier then I would have liked, but I've it fixed
now. I also had to reshuffle the order of some patches for this, so I'm
going to post a v4 of the entire set. I've also added some extra comments
(but no functional changes) to the sunxi ehci dm patch as request by Ian,
so please take all patches from the v4 posting when merging.
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/9] dm: usb: Make usb_get_bus easier to use for callers
Make usb_get_bus easier to use for callers, by directly returning the bus
rather then returning it via a pass-by-ref argument.
This also removes the error checking from the current callers, as
we already have an assert() for bus not being NULL in usb_get_bus().
Signed-off-by: Hans de Goede
Acked-by: Simon Glass
---
Changes in v2:
-New patch in v2 of this patch-set
Changes in v4:
-Moved this patch to be the first of the patch-set so that it can be used in
"dm: usb: Copy over usb_device values from usb_scan_device() to final
usb_device"
---
drivers/usb/host/usb-uclass.c | 17 -
include/usb.h | 7 +++
2 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index 8dc1823..ba7d32a 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -476,9 +476,7 @@ int usb_scan_device(struct udevice *parent, int port,
*devp = NULL;
memset(udev, '\0', sizeof(*udev));
- ret = usb_get_bus(parent, &udev->controller_dev);
- if (ret)
- return ret;
+ udev->controller_dev = usb_get_bus(parent);
priv = dev_get_uclass_priv(udev->controller_dev);
/*
@@ -578,35 +576,28 @@ int usb_child_post_bind(struct udevice *dev)
return 0;
}
-int usb_get_bus(struct udevice *dev, struct udevice **busp)
+struct udevice *usb_get_bus(struct udevice *dev)
{
struct udevice *bus;
- *busp = NULL;
for (bus = dev; bus && device_get_uclass_id(bus) != UCLASS_USB; )
bus = bus->parent;
if (!bus) {
/* By design this cannot happen */
assert(bus);
debug("USB HUB '%s' does not have a controller\n", dev->name);
- return -EXDEV;
}
- *busp = bus;
- return 0;
+ return bus;
}
int usb_child_pre_probe(struct udevice *dev)
{
- struct udevice *bus;
struct usb_device *udev = dev_get_parentdata(dev);
struct usb_dev_platdata *plat = dev_get_parent_platdata(dev);
int ret;
- ret = usb_get_bus(dev, &bus);
- if (ret)
- return ret;
- udev->controller_dev = bus;
+ udev->controller_dev = usb_get_bus(dev);
udev->dev = dev;
udev->devnum = plat->devnum;
udev->slot_id = plat->slot_id;
diff --git a/include/usb.h b/include/usb.h
index 1984e8f..6207d36 100644
--- a/include/usb.h
+++ b/include/usb.h
@@ -742,11 +742,10 @@ int usb_scan_device(struct udevice *parent, int port,
* will be a device with uclass UCLASS_USB.
*
* @dev: Device to check
- * @busp: Returns bus, or NULL if not found
- * @return 0 if OK, -EXDEV is somehow this bus does not have a controller (this
- * indicates a critical error in the USB stack
+ * @return The bus, or NULL if not found (this indicates a critical error in
+ * the USB stack
*/
-int usb_get_bus(struct udevice *dev, struct udevice **busp);
+struct udevice *usb_get_bus(struct udevice *dev);
/**
* usb_select_config() - Set up a device ready for use
--
2.3.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/9] dm: usb: Copy over usb_device values from usb_scan_device() to final usb_device
Currently we copy over a number of usb_device values stored in the on stack
struct usb_device probed in usb_scan_device() to the final driver-model managed
struct usb_device in usb_child_pre_probe() through usb_device_platdata, and
then call usb_select_config() to fill in the rest.
There are 3 problems with this approach:
1) It does not fill in enough fields before calling usb_select_config(),
specifically it does not fill in ep0's maxpacketsize causing a div by zero
exception in the ehci driver.
2) It unnecessarily redoes a number of usb requests making usb probing slower
3) Calling usb_select_config() a second time fails on some usb-1 devices
plugged into usb-2 hubs, causing u-boot to not recognize these devices.
This commit fixes these issues by removing (*) the usb_select_config() call
from usb_child_pre_probe(), and instead of copying over things field by field
through usb_device_platdata, store a pointer to the in stack usb_device
(which is still valid when usb_child_pre_probe() gets called) and copy
over the entire struct.
*) Except for devices which are explictly instantiated through device-tree
rather then discovered through usb_scan_device() such as emulated usb devices
in the sandbox.
Signed-off-by: Hans de Goede
---
Changes in v3:
-Add a big fat comment to warn that plat->udev is for usb-uclass.c internal
use only
Changes in v4:
-Fix sandbox emul usb device breakage
---
drivers/usb/host/usb-uclass.c | 43 ---
include/usb.h | 17 ++---
2 files changed, 38 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index ba7d32a..c5ece58 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -533,11 +533,7 @@ int usb_scan_device(struct udevice *parent, int port,
plat = dev_get_parent_platdata(dev);
debug("%s: Probing '%s', plat=%p\n", __func__, dev->name, plat);
plat->devnum = udev->devnum;
- plat->speed = udev->speed;
- plat->slot_id = udev->slot_id;
- plat->portnr = port;
- debug("** device '%s': stashing slot_id=%d\n", dev->name,
- plat->slot_id);
+ plat->udev = udev;
priv->next_addr++;
ret = device_probe(dev);
if (ret) {
@@ -597,17 +593,34 @@ int usb_child_pre_probe(struct udevice *dev)
struct usb_dev_platdata *plat = dev_get_parent_platdata(dev);
int ret;
- udev->controller_dev = usb_get_bus(dev);
- udev->dev = dev;
- udev->devnum = plat->devnum;
- udev->slot_id = plat->slot_id;
- udev->portnr = plat->portnr;
- udev->speed = plat->speed;
- debug("** device '%s': getting slot_id=%d\n", dev->name, plat->slot_id);
+ if (plat->udev) {
+ /*
+* Copy over all the values set in the on stack struct
+* usb_device in usb_scan_device() to our final struct
+* usb_device for this dev.
+*/
+ *udev = *(plat->udev);
+ /* And clear plat->udev as it will not be valid for long */
+ plat->udev = NULL;
+ udev->dev = dev;
+ } else {
+ /*
+* This happens with devices which are explicitly bound
+* instead of being discovered through usb_scan_device()
+* such as sandbox emul devices.
+*/
+ udev->dev = dev;
+ udev->controller_dev = usb_get_bus(dev);
+ udev->devnum = plat->devnum;
- ret = usb_select_config(udev);
- if (ret)
- return ret;
+ /*
+* udev did not go through usb_scan_device(), so we need to
+* select the config and read the config descriptors.
+*/
+ ret = usb_select_config(udev);
+ if (ret)
+ return ret;
+ }
return 0;
}
diff --git a/include/usb.h b/include/usb.h
index 6207d36..4c21050 100644
--- a/include/usb.h
+++ b/include/usb.h
@@ -571,20 +571,23 @@ struct usb_platdata {
* This is used by sandbox to provide emulation data also.
*
* @id:ID used to match this device
- * @speed: Stores the speed associated with a USB device
* @devnum:Device address on the USB bus
- * @slot_id: USB3 slot ID, which is separate from the device address
- * @portnr:Port number of this device on its parent hub, numbered from 1
- * (0 mean this device is the root hub)
+ * @udev: usb-uclass internal use only do NOT use
* @strings: List of descriptor strings (for sandbox emulation purposes)
* @desc_list: List of descriptors (for sandbox emulation purposes)
*/
struct usb_dev_platdata {
struct usb_device_id id;
- enum usb_device_speed speed;
int devnum;
- int slot_id;
- int portnr; /* Hub port number, 1..n */
+ /*
+
[U-Boot] [PATCH v4 3/9] dm: usb: Use usb_get_bus in dm ehci code
Use usb_get_bus in dm ehci code rather then re-implementing it.
Signed-off-by: Hans de Goede
Acked-by: Simon Glass
---
Changes in v2:
-New patch in v2 of this patch-set
---
drivers/usb/host/ehci-hcd.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index bd9861d..85adbf4 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -125,14 +125,7 @@ static struct descriptor {
static struct ehci_ctrl *ehci_get_ctrl(struct usb_device *udev)
{
#ifdef CONFIG_DM_USB
- struct udevice *dev;
-
- /* Find the USB controller */
- for (dev = udev->dev;
-device_get_uclass_id(dev) != UCLASS_USB;
-dev = dev->parent)
- ;
- return dev_get_priv(dev);
+ return dev_get_priv(usb_get_bus(udev->dev));
#else
return udev->controller;
#endif
--
2.3.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/9] dm usb fixes + sunxi dm ehci support
Hi Simon, et al, Here is v4 of my dm usb + driver-model support for the sunxi-ehci code set. New since v2 (v3 for one patch) is that this now no longer breaks sandbox usb emul devices. I had to reshuffle the order of 2 patches to fix this cleanly, and I've also added some extra comments to the last patch of the set as requested by Ian. So please take all patches from this v4 posting when merging. Thanks & Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 7/9] dm: usb: Prefix ehci interrupt-queue functions with _ehci_
This is a preparation patch for adding interrupt-queue support to the
ehci dm code.
Signed-off-by: Hans de Goede
Acked-by: Simon Glass
---
drivers/usb/host/ehci-hcd.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 46d01d4..363ce38 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1252,9 +1252,9 @@ disable_periodic(struct ehci_ctrl *ctrl)
return 0;
}
-struct int_queue *
-create_int_queue(struct usb_device *dev, unsigned long pipe, int queuesize,
-int elementsize, void *buffer, int interval)
+static struct int_queue *_ehci_create_int_queue(struct usb_device *dev,
+ unsigned long pipe, int queuesize, int elementsize,
+ void *buffer, int interval)
{
struct ehci_ctrl *ctrl = ehci_get_ctrl(dev);
struct int_queue *result = NULL;
@@ -1410,7 +1410,8 @@ fail1:
return NULL;
}
-void *poll_int_queue(struct usb_device *dev, struct int_queue *queue)
+static void *_ehci_poll_int_queue(struct usb_device *dev,
+ struct int_queue *queue)
{
struct QH *cur = queue->current;
struct qTD *cur_td;
@@ -1445,8 +1446,8 @@ void *poll_int_queue(struct usb_device *dev, struct
int_queue *queue)
}
/* Do not free buffers associated with QHs, they're owned by someone else */
-int
-destroy_int_queue(struct usb_device *dev, struct int_queue *queue)
+static int _ehci_destroy_int_queue(struct usb_device *dev,
+ struct int_queue *queue)
{
struct ehci_ctrl *ctrl = ehci_get_ctrl(dev);
int result = -1;
@@ -1547,6 +1548,24 @@ int submit_int_msg(struct usb_device *dev, unsigned long
pipe,
{
return _ehci_submit_int_msg(dev, pipe, buffer, length, interval);
}
+
+struct int_queue *create_int_queue(struct usb_device *dev,
+ unsigned long pipe, int queuesize, int elementsize,
+ void *buffer, int interval)
+{
+ return _ehci_create_int_queue(dev, pipe, queuesize, elementsize,
+ buffer, interval);
+}
+
+void *poll_int_queue(struct usb_device *dev, struct int_queue *queue)
+{
+ return _ehci_poll_int_queue(dev, queue);
+}
+
+int destroy_int_queue(struct usb_device *dev, struct int_queue *queue)
+{
+ return _ehci_destroy_int_queue(dev, queue);
+}
#endif
#ifdef CONFIG_DM_USB
--
2.3.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 5/9] dm: usb: Set desc_before_addr from ehci dm code
Without this usb-1 device descriptors do not get read properly.
Signed-off-by: Hans de Goede
Acked-by: Simon Glass
---
drivers/usb/host/ehci-hcd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 9471bcb..46d01d4 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1579,12 +1579,15 @@ int ehci_register(struct udevice *dev, struct ehci_hccr
*hccr,
struct ehci_hcor *hcor, const struct ehci_ops *ops,
uint tweaks, enum usb_init_type init)
{
+ struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
struct ehci_ctrl *ctrl = dev_get_priv(dev);
int ret;
debug("%s: dev='%s', ctrl=%p, hccr=%p, hcor=%p, init=%d\n", __func__,
dev->name, ctrl, hccr, hcor, init);
+ priv->desc_before_addr = true;
+
ehci_setup_ops(ctrl, ops);
ctrl->hccr = hccr;
ctrl->hcor = hcor;
--
2.3.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 8/9] dm: usb: Add support for interrupt queues to the dm ehci code
Add support for interrupt queues to the dm ehci code.
Signed-off-by: Hans de Goede
Acked-by: Simon Glass
---
drivers/usb/host/ehci-hcd.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 363ce38..0e84265 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1594,6 +1594,29 @@ static int ehci_submit_int_msg(struct udevice *dev,
struct usb_device *udev,
return _ehci_submit_int_msg(udev, pipe, buffer, length, interval);
}
+static struct int_queue *ehci_create_int_queue(struct udevice *dev,
+ struct usb_device *udev, unsigned long pipe, int queuesize,
+ int elementsize, void *buffer, int interval)
+{
+ debug("%s: dev='%s', udev=%p\n", __func__, dev->name, udev);
+ return _ehci_create_int_queue(udev, pipe, queuesize, elementsize,
+ buffer, interval);
+}
+
+static void *ehci_poll_int_queue(struct udevice *dev, struct usb_device *udev,
+struct int_queue *queue)
+{
+ debug("%s: dev='%s', udev=%p\n", __func__, dev->name, udev);
+ return _ehci_poll_int_queue(udev, queue);
+}
+
+static int ehci_destroy_int_queue(struct udevice *dev, struct usb_device *udev,
+ struct int_queue *queue)
+{
+ debug("%s: dev='%s', udev=%p\n", __func__, dev->name, udev);
+ return _ehci_destroy_int_queue(udev, queue);
+}
+
int ehci_register(struct udevice *dev, struct ehci_hccr *hccr,
struct ehci_hcor *hcor, const struct ehci_ops *ops,
uint tweaks, enum usb_init_type init)
@@ -1642,6 +1665,9 @@ struct dm_usb_ops ehci_usb_ops = {
.control = ehci_submit_control_msg,
.bulk = ehci_submit_bulk_msg,
.interrupt = ehci_submit_int_msg,
+ .create_int_queue = ehci_create_int_queue,
+ .poll_int_queue = ehci_poll_int_queue,
+ .destroy_int_queue = ehci_destroy_int_queue,
};
#endif
--
2.3.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 6/9] dm: usb: Add support for interrupt queues to the dm usb code
Interrupt endpoints typically are polled for a long time by the usb
controller before they return anything, so calls to submit_int_msg() can
take a long time to complete this.
To avoid this the u-boot code has the an interrupt queue mechanism / API,
add support for this to the driver-model usb code.
See the added doc comments for more details.
Signed-off-by: Hans de Goede
Acked-by: Simon Glass
---
drivers/usb/host/usb-uclass.c | 36
include/usb.h | 48 ++-
2 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index c5ece58..9ee25ed 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -65,6 +65,42 @@ int submit_bulk_msg(struct usb_device *udev, unsigned long
pipe, void *buffer,
return ops->bulk(bus, udev, pipe, buffer, length);
}
+struct int_queue *create_int_queue(struct usb_device *udev,
+ unsigned long pipe, int queuesize, int elementsize,
+ void *buffer, int interval)
+{
+ struct udevice *bus = udev->controller_dev;
+ struct dm_usb_ops *ops = usb_get_ops(bus);
+
+ if (!ops->create_int_queue)
+ return NULL;
+
+ return ops->create_int_queue(bus, udev, pipe, queuesize, elementsize,
+buffer, interval);
+}
+
+void *poll_int_queue(struct usb_device *udev, struct int_queue *queue)
+{
+ struct udevice *bus = udev->controller_dev;
+ struct dm_usb_ops *ops = usb_get_ops(bus);
+
+ if (!ops->poll_int_queue)
+ return NULL;
+
+ return ops->poll_int_queue(bus, udev, queue);
+}
+
+int destroy_int_queue(struct usb_device *udev, struct int_queue *queue)
+{
+ struct udevice *bus = udev->controller_dev;
+ struct dm_usb_ops *ops = usb_get_ops(bus);
+
+ if (!ops->destroy_int_queue)
+ return -ENOSYS;
+
+ return ops->destroy_int_queue(bus, udev, queue);
+}
+
int usb_alloc_device(struct usb_device *udev)
{
struct udevice *bus = udev->controller_dev;
diff --git a/include/usb.h b/include/usb.h
index 4c21050..7b55844 100644
--- a/include/usb.h
+++ b/include/usb.h
@@ -198,7 +198,7 @@ int submit_control_msg(struct usb_device *dev, unsigned
long pipe, void *buffer,
int submit_int_msg(struct usb_device *dev, unsigned long pipe, void *buffer,
int transfer_len, int interval);
-#if defined CONFIG_USB_EHCI || defined CONFIG_MUSB_HOST
+#if defined CONFIG_USB_EHCI || defined CONFIG_MUSB_HOST ||
defined(CONFIG_DM_USB)
struct int_queue *create_int_queue(struct usb_device *dev, unsigned long pipe,
int queuesize, int elementsize, void *buffer, int interval);
int destroy_int_queue(struct usb_device *dev, struct int_queue *queue);
@@ -660,6 +660,52 @@ struct dm_usb_ops {
int (*interrupt)(struct udevice *bus, struct usb_device *udev,
unsigned long pipe, void *buffer, int length,
int interval);
+
+ /**
+* create_int_queue() - Create and queue interrupt packets
+*
+* Create and queue @queuesize number of interrupt usb packets of
+* @elementsize bytes each. @buffer must be atleast @queuesize *
+* @elementsize bytes.
+*
+* Note some controllers only support a queuesize of 1.
+*
+* @interval: Interrupt interval
+*
+* @return A pointer to the created interrupt queue or NULL on error
+*/
+ struct int_queue *(*create_int_queue)(struct udevice *bus,
+ struct usb_device *udev, unsigned long pipe,
+ int queuesize, int elementsize, void *buffer,
+ int interval);
+
+ /**
+* poll_int_queue() - Poll an interrupt queue for completed packets
+*
+* Poll an interrupt queue for completed packets. The return value
+* points to the part of the buffer passed to create_int_queue()
+* corresponding to the completed packet.
+*
+* @queue: queue to poll
+*
+* @return Pointer to the data of the first completed packet, or
+* NULL if no packets are ready
+*/
+ void *(*poll_int_queue)(struct udevice *bus, struct usb_device *udev,
+ struct int_queue *queue);
+
+ /**
+* destroy_int_queue() - Destroy an interrupt queue
+*
+* Destroy an interrupt queue created by create_int_queue().
+*
+* @queue: queue to poll
+*
+* @return 0 if OK, -ve on error
+*/
+ int (*destroy_int_queue)(struct udevice *bus, struct usb_device *udev,
+struct int_queue *queue);
+
/**
* alloc_device() - Allocate a new device context (XHCI)
*
--
2.3.6
__
[U-Boot] [PATCH v4 9/9] sunxi: ehci: Convert to the driver-model
Convert sunxi-boards which use the sunxi-ehci code to the driver-model.
Signed-off-by: Hans de Goede
Acked-by: Simon Glass
---
Changes in v4:
-Add a comment to document the setting of some priv-data members based on
the controller base-address
---
board/sunxi/Kconfig | 3 ++
drivers/usb/host/ehci-sunxi.c | 93 +--
2 files changed, 67 insertions(+), 29 deletions(-)
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index a60d028..4ca1ac1 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -555,4 +555,7 @@ config DM_ETH
config DM_SERIAL
default y
+config DM_USB
+ default y if !USB_MUSB_SUNXI
+
endif
diff --git a/drivers/usb/host/ehci-sunxi.c b/drivers/usb/host/ehci-sunxi.c
index 0edb643..34130f8 100644
--- a/drivers/usb/host/ehci-sunxi.c
+++ b/drivers/usb/host/ehci-sunxi.c
@@ -14,53 +14,88 @@
#include
#include
#include
+#include
#include "ehci.h"
-int ehci_hcd_init(int index, enum usb_init_type init, struct ehci_hccr **hccr,
- struct ehci_hcor **hcor)
+struct ehci_sunxi_priv {
+ struct ehci_ctrl ehci;
+ int ahb_gate_mask; /* Mask of ahb_gate0 clk gate bits for this hcd */
+ int phy_index; /* Index of the usb-phy attached to this hcd */
+};
+
+static int ehci_usb_probe(struct udevice *dev)
{
struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
- int ahb_gate_offset;
+ struct usb_platdata *plat = dev_get_platdata(dev);
+ struct ehci_sunxi_priv *priv = dev_get_priv(dev);
+ struct ehci_hccr *hccr = (struct ehci_hccr *)dev_get_addr(dev);
+ struct ehci_hcor *hcor;
+
+ /*
+* This should go away once we've moved to the driver model for
+* clocks resp. phys.
+*/
+ if (hccr == (void *)SUNXI_USB1_BASE) {
+ priv->ahb_gate_mask = 1 << AHB_GATE_OFFSET_USB_EHCI0;
+ priv->phy_index = 1;
+ } else {
+ priv->ahb_gate_mask = 1 << AHB_GATE_OFFSET_USB_EHCI1;
+ priv->phy_index = 2;
+ }
- ahb_gate_offset = index ? AHB_GATE_OFFSET_USB_EHCI1 :
- AHB_GATE_OFFSET_USB_EHCI0;
- setbits_le32(&ccm->ahb_gate0, 1 << ahb_gate_offset);
+ setbits_le32(&ccm->ahb_gate0, priv->ahb_gate_mask);
#ifdef CONFIG_SUNXI_GEN_SUN6I
- setbits_le32(&ccm->ahb_reset0_cfg, 1 << ahb_gate_offset);
+ setbits_le32(&ccm->ahb_reset0_cfg, priv->ahb_gate_mask);
#endif
- sunxi_usb_phy_init(index + 1);
- sunxi_usb_phy_power_on(index + 1);
-
- if (index == 0)
- *hccr = (void *)SUNXI_USB1_BASE;
- else
- *hccr = (void *)SUNXI_USB2_BASE;
-
- *hcor = (struct ehci_hcor *)((uint32_t) *hccr
- + HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));
+ sunxi_usb_phy_init(priv->phy_index);
+ sunxi_usb_phy_power_on(priv->phy_index);
- debug("sunxi-ehci: init hccr %x and hcor %x hc_length %d\n",
- (uint32_t)*hccr, (uint32_t)*hcor,
- (uint32_t)HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));
+ hcor = (struct ehci_hcor *)((uint32_t)hccr +
+ HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
- return 0;
+ return ehci_register(dev, hccr, hcor, NULL, 0, plat->init_type);
}
-int ehci_hcd_stop(int index)
+static int ehci_usb_remove(struct udevice *dev)
{
struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
- int ahb_gate_offset;
+ struct ehci_sunxi_priv *priv = dev_get_priv(dev);
+ int ret;
+
+ ret = ehci_deregister(dev);
+ if (ret)
+ return ret;
- sunxi_usb_phy_power_off(index + 1);
- sunxi_usb_phy_exit(index + 1);
+ sunxi_usb_phy_power_off(priv->phy_index);
+ sunxi_usb_phy_exit(priv->phy_index);
- ahb_gate_offset = index ? AHB_GATE_OFFSET_USB_EHCI1 :
- AHB_GATE_OFFSET_USB_EHCI0;
#ifdef CONFIG_SUNXI_GEN_SUN6I
- clrbits_le32(&ccm->ahb_reset0_cfg, 1 << ahb_gate_offset);
+ clrbits_le32(&ccm->ahb_reset0_cfg, priv->ahb_gate_mask);
#endif
- clrbits_le32(&ccm->ahb_gate0, 1 << ahb_gate_offset);
+ clrbits_le32(&ccm->ahb_gate0, priv->ahb_gate_mask);
return 0;
}
+
+static const struct udevice_id ehci_usb_ids[] = {
+ { .compatible = "allwinner,sun4i-a10-ehci", },
+ { .compatible = "allwinner,sun5i-a13-ehci", },
+ { .compatible = "allwinner,sun6i-a31-ehci", },
+ { .compatible = "allwinner,sun7i-a20-ehci", },
+ { .compatible = "allwinner,sun8i-a23-ehci", },
+ { .compatible = "allwinner,sun9i-a80-ehci", },
+ { }
+};
+
+U_BOOT_DRIVER(usb_ehci) = {
+ .name = "ehci_sunxi",
+ .id = UCLASS_USB,
+ .of_match = ehci_usb_ids,
+ .probe = ehci_usb_probe,
+ .remove = ehci_usb_remove,
+ .ops= &ehci_usb_ops,
+ .platdata_auto_alloc_size = s
[U-Boot] [PATCH v4 4/9] dm: usb: Fix finding of first upstream usb-2 hub in the ehci dm code
The ehci driver model code for finding the first upstream usb-2 hub before
this commit has a number of issues:
1) "if (!ttdev->speed != USB_SPEED_HIGH)" does not work because the '!'
takes presedence over the '!=' this should simply be
"if (ttdev->speed == USB_SPEED_HIGH)"
2) It makes ttdev point to the first upstream usb-2 hub, but ttdev should
point to the last usb-1 device before the first usb-2 hub (when going
upstream from the device), as ttdev is used to find the port of the
first usb-2 hub to which the the last usb-1 device is connected.
3) parent_devnum however should be set to the devnum of the first usb-2
hub, so we need to keep pointers around to both usb_device structs.
To complicate things further during enumeration usb_device.dev will point
to the parent udevice, where as during normal use it will point to
the actual udevice, we must handle both cases correctly.
This commit fixes all this making usb-1 devices attached to usb-2 hubs,
including usb-1 devices attached to usb-1 hubs attached to usb-2 hubs, work.
Signed-off-by: Hans de Goede
Acked-by: Simon Glass
---
Changes in v2:
-Rewrote the fix to use driver-model logic to find the first upstream usb-2
hub rather then using the deprecated usb_device->parent pointer
---
drivers/usb/host/ehci-hcd.c | 34 ++
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 85adbf4..9471bcb 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -303,23 +303,33 @@ static void ehci_update_endpt2_dev_n_port(struct
usb_device *udev,
* in the tree before that one!
*/
#ifdef CONFIG_DM_USB
+ /*
+* When called from usb-uclass.c: usb_scan_device() udev->dev points
+* to the parent udevice, not the actual udevice belonging to the
+* udev as the device is not instantiated yet. So when searching
+* for the first usb-2 parent start with udev->dev not
+* udev->dev->parent .
+*/
struct udevice *parent;
+ struct usb_device *uparent;
+
+ ttdev = udev;
+ parent = udev->dev;
+ uparent = dev_get_parentdata(parent);
- for (ttdev = udev; ; ) {
- struct udevice *dev = ttdev->dev;
+ while (uparent->speed != USB_SPEED_HIGH) {
+ struct udevice *dev = parent;
- if (dev->parent &&
- device_get_uclass_id(dev->parent) == UCLASS_USB_HUB)
- parent = dev->parent;
- else
- parent = NULL;
- if (!parent)
+ if (device_get_uclass_id(dev->parent) != UCLASS_USB_HUB) {
+ printf("ehci: Error cannot find high speed parent of
usb-1 device\n");
return;
- ttdev = dev_get_parentdata(parent);
- if (!ttdev->speed != USB_SPEED_HIGH)
- break;
+ }
+
+ ttdev = dev_get_parentdata(dev);
+ parent = dev->parent;
+ uparent = dev_get_parentdata(parent);
}
- parent_devnum = ttdev->devnum;
+ parent_devnum = uparent->devnum;
#else
ttdev = udev;
while (ttdev->parent && ttdev->parent->speed != USB_SPEED_HIGH)
--
2.3.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: mx6: tqma6: Fix USB and add other filesystems
On 05/05/2015 11:36, Stefan Roese wrote: > Hi Stefano, > > On 12.03.2015 13:34, Stefan Roese wrote: >> This patch fixes the USB EHCI support on the TQMa6 SoM. Additionally >> some filesystems are added, included the generic FS commands (e.g. >> ls...). >> >> Signed-off-by: Stefan Roese >> Cc: Markus Niebel >> Cc: Stefano Babic >> --- >> include/configs/tqma6.h | 7 +-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/include/configs/tqma6.h b/include/configs/tqma6.h >> index a099687..9022550 100644 >> --- a/include/configs/tqma6.h >> +++ b/include/configs/tqma6.h >> @@ -125,16 +125,19 @@ >> #define CONFIG_USB_STORAGE >> #define CONFIG_USB_HOST_ETHER >> #define CONFIG_USB_ETHER_SMSC95XX >> -#define CONFIG_MXC_USB_PORT1 >> #define CONFIG_MXC_USB_PORTSC(PORT_PTS_UTMI | PORT_PTS_PTW) >> -#define CONFIG_MXC_USB_FLAGS0 >> +#define CONFIG_USB_MAX_CONTROLLER_COUNT2 >> +#define CONFIG_EHCI_HCD_INIT_AFTER_RESET/* For OTG port */ >> >> /* Fuses */ >> #define CONFIG_MXC_OCOTP >> #define CONFIG_CMD_FUSE >> >> #define CONFIG_CMD_EXT2 >> +#define CONFIG_CMD_EXT4 >> +#define CONFIG_CMD_EXT4_WRITE >> #define CONFIG_CMD_FAT >> +#define CONFIG_CMD_FS_GENERIC >> #define CONFIG_DOS_PARTITION >> >> #define CONFIG_CMD_PING > > Ping on this patch. Markus has Ack'ed it. Could you please push it to Tom? > Sorry, I confuse these ones with the patches to split tqma code and I was convinced I have already applied. I'll do it. Best regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk 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 2/3] net: Remove all references to CONFIG_ETHADDR and friends
Bonjour Simon, Le Mon, 4 May 2015 15:37:22 -0600, Simon Glass a écrit : > On 4 May 2015 at 13:55, Joe Hershberger wrote: > > We really don't want boards defining fixed MAC addresses in their config > > so we just remove the option to set it in a fixed way. If you must have > > a MAC address that was not provisioned, then use the random MAC address > > functionality. > > > > Signed-off-by: Joe Hershberger > > --- > > Reviewed-by: Simon Glass As much as I support the idea that one should not hard-code MAC addresses, I also support the idea that changes should not break previous behavior. And regarding the WORK board which I submitted, its configuration header file had this address encoded in the in-house U-Boot which the customer was using before; removing this address might lead to the customer provisioning scripts failing. Cordialement, Albert ARIBAUD 3ADEV ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] net: Remove all references to CONFIG_ETHADDR and friends
On 4 May 2015 at 13:55, Joe Hershberger wrote: > We really don't want boards defining fixed MAC addresses in their config > so we just remove the option to set it in a fixed way. If you must have > a MAC address that was not provisioned, then use the random MAC address > functionality. > > Signed-off-by: Joe Hershberger > --- Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bugfix i.mx6 pwm: prevent overflow of period_c * duty_ns by casting duty_ns to ull first. This bug came up when trying to create a 200 Hz PWM.
Hi Heiko, We didn't need the 200 Hz PWM in Linux, so I didn't test it right away. I did now, and the problem isn't present there, which I found weird given the fact that it is indeed similar code. So I dug into the kernel: The devil is in the details. :) Kernel: c = (unsigned long long)period_cycles * duty_ns; U-boot: c = (unsigned long long)(*period_c * duty_ns); The braces cause the casting to be performed after the (truncated) multiplication, while without braces, the casting is done upfront. Thank you for your reply and giving attention to this small bug. Kind regards, Brecht -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: dinsdag 28 april 2015 7:32 To: NEYRINCK Brecht Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] bugfix i.mx6 pwm: prevent overflow of period_c * duty_ns by casting duty_ns to ull first. This bug came up when trying to create a 200 Hz PWM. Hello Brecht Neyrinck, Am 27.04.2015 14:11, schrieb Brecht Neyrinck: > --- > drivers/pwm/pwm-imx-util.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > mode change 100644 => 100755 drivers/pwm/pwm-imx-util.c > > diff --git a/drivers/pwm/pwm-imx-util.c b/drivers/pwm/pwm-imx-util.c > index f1d0b35..777a8bf 100644 > --- a/drivers/pwm/pwm-imx-util.c > +++ b/drivers/pwm/pwm-imx-util.c > @@ -56,7 +56,7 @@ int pwm_imx_get_parms(int period_ns, int duty_ns, unsigned > long *period_c, > *prescale = *period_c / 0x1 + 1; > > *period_c /= *prescale; > - c = (unsigned long long)(*period_c * duty_ns); > + c = *period_c * (unsigned long long) duty_ns; Thanks for this ... Hmm... this code is directly from linux drivers/pwm/pwm-imx.c ... Do you have running a linux on your hw? Could you verify this in linux too? Thanks! Acked-by: Heiko Schocher bye, Heiko > do_div(c, period_ns); > *duty_c = c; > > -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany DISCLAIMER The contents of this e-mail are intended for the named addressee only. It contains information which may be confidential and which may also be privileged. Unless you are the named addressee (or authorised to receive for the addressee) you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Further, we make every effort to keep our network free from viruses. However, you do need to verify that this email and any attachments are free of viruses as we can take no responsibility for any computer virus which might be transferred by way of this e-mail. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] nand: sunxi: Add support for booting from internal NAND memory
Ian Campbell writes:
> On Wed, 2015-04-29 at 17:02 +0200, Daniel Kochmański wrote:
>> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
>> index 88e3358..1a30684 100644
>> --- a/board/sunxi/Kconfig
>> +++ b/board/sunxi/Kconfig
>> @@ -239,6 +239,18 @@ config MMC_SUNXI_SLOT_EXTRA
>> slot or emmc on mmc1 - mmc3. Setting this to 1, 2 or 3 will enable
>> support for this.
>>
>> +config SPL_NAND_SUPPORT
>> +bool "SPL/NAND mode support"
>> +depends on SPL
>> +default n
>> +---help---
>> + This enables support for booting from NAND internal
>> + memory. U-Boot SPL doesn't detect where is it load from,
>> + therefore this option is needed to properly load image from
>> + flash. Option also disables MMC functionality on U-Boot due to
>> + initialization errors encountered, when both controllers are
>> + enabled.
>
> Is this last bit a bug in the s/w or a hardware thing? Does this mean
> that MMC is not available in the main u-boot image too when NAND support
> is enabled?
>
I'm not sure what is a reason, but controller can't initialize MMC when
SPL is loaded. MMC works in main u-boot allowing to boot from it and
perform any other option (rescan, part, info, etc.). It is only SPL
relevant.
>> +
>> config USB0_VBUS_PIN
>> string "Vbus enable pin for usb0 (otg)"
>> default ""
>> diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
>> index 43766e0..7ad7412 100644
>> --- a/board/sunxi/Makefile
>> +++ b/board/sunxi/Makefile
>> @@ -9,6 +9,7 @@
>> # SPDX-License-Identifier: GPL-2.0+
>> #
>> obj-y += board.o
>> +obj-$(CONFIG_NAND_SUNXI)+= nand.o
>
> CONFIG_SUNXI_NAND would be more consistent with the rest I think.
>
OK.
>> obj-$(CONFIG_SUNXI_GMAC)+= gmac.o
>> obj-$(CONFIG_SUNXI_AHCI)+= ahci.o
>
>> +void nand_set_clocks(void)
>> +{
>> +W32(PORTC_BASE + 0x48, 0x);
>
> u-boot style is to declare a struct which matches the register layout
> and to do something like:
> struct nand_ctrl_foo *mcf = (void *)NANCFLASHC_BASE;
>
> And use writel, set_bits, setclr_bits and friends.
OK, I'll read about it and try to adjust driver.
>
> Please also try and give sensible names to all the magic numbers, or at
> least include a comment explaining that these are magic numbers derived
> from $SOMEWHERE and we don't know what they mean (if that is the case).
>
> Both of these apply to several bits of the code too.
This work is mainly based on register guess-work from here:
http://rhombus-tech.net/allwinner_a10/A10_register_guide/A10_NAND/ - so
I can gather names from there and put them in source.
>
>> +W32(PORTC_BASE + 0x4C, 0x);
>> +W32(PORTC_BASE + 0x50, 0x222);
>> +W32(PORTC_BASE + 0x54, 0x2);
>> +W32(PORTC_BASE + 0x5C, 0x);
>> +W32(PORTC_BASE + 0x60, 0x1);
>> +W32(PORTC_BASE + 0x64, 0x5140);
>> +W32(PORTC_BASE + 0x68, 0x4016);
>> +
>> +uint32_t val = R32(CCMU_BASE + 0x60);
>> +W32(CCMU_BASE + 0x60, 0x2000 | val);
>> +val = R32(CCMU_BASE + 0x80);
>> +W32(CCMU_BASE + 0x80, val | 0x8000 | 0x1);
>> +}
>> +
>> +int initialized = 0;
>> +void nand_init(void)
>> +{
>> +initialized = 1;
>
> Please call this from somewhere during init e.g. board.c rather than
> from nand_read with a latch.
>
Sure.
>> +uint32_t val;
>> +nand_set_clocks();
>> +val = R32(NANDFLASHC_BASE + 0x00);
>> +/* CTL = (1<<0 <-EN1<<1 RESET) */
>> +W32(NANDFLASHC_BASE + 0x00, val | 0x3); /* enable and reset CTL */
>> +do {
>> +val = R32(NANDFLASHC_BASE + 0x00);
>> +if (val & (1<<1))
>> +break;
>> +} while (1);
>
> Potentially infinite loop?
>
> There were some similar instances below which had a t/o. Perhaps combine
> them all into a helper similar to the dram code's
> mctl_await_completion()?
>
Ok, I'll look into that.
>> +uint32_t ecc_errors = 0;
>> +
>> +/* read 0x400 bytes from real_addr to temp_buf */
>> +void nand_read_block(unsigned int real_addr, int syndrome)
>> +{
>> +uint32_t val;
>> +if (!initialized)
>> +nand_init();
>> +
>> +memset((void *)temp_buf, 0, 0x400); /* clear temp_buf */
>
> Can we not avoid going via this global temp_buf by setting DMAC_BASE +
> 0x308 to the correct address on each read?
>
I'll check this, I think I had problems with that, but if it works w/o
temp_buf on both SPL and main U-Boot builds, then I'll get rid of it.
> Ian.
--
Daniel Kochmański | Poznań, Poland
;; aka jackdaniel
"Be the change that you wish to see in the world." - Mahatma Gandhi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Debugging U-Boot on iMX6 with BDI3000
Hello, I'm trying to debug U-Boot (version: imx_v2014.04_3.14.28_1.0.0_ga) for a custom board with a BDI3000. So far I can connect to the target and I see the U-Boot code at the correct location, but after reset the PC is at 0x1ffa870c which is somewhere outside of U-Boot. Here the state after powering up th board with the BDI attached: IMX6#0>info Core number : 0 Core state: debug mode (ARM) Debug entry cause : Debug Request Current PC: 0x1ffa870c Current CPSR : 0x61d3 (Supervisor) I need to debug from the very first assembler instruction which gets loaded at address 0x1780 but I don't know how to configure the BDI to achieve this. Does someone would have a BDI configuration file to share? Armand ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] switching to single .config configuration issues
Hi Simon > -Original Message- > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass > Sent: Tuesday, May 05, 2015 6:28 > To: Yehuda Yitschak > Cc: Masahiro Yamada; Hanna Hawa; u-boot@lists.denx.de > Subject: Re: [U-Boot] switching to single .config configuration issues > > Hi, > > On 4 May 2015 at 05:34, Yehuda Yitschak wrote: > > Hey Simon > > > >> -Original Message- > >> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon > Glass > >> Sent: Sunday, May 03, 2015 21:55 > >> To: Yehuda Yitschak > >> Cc: Masahiro Yamada; Hanna Hawa; u-boot@lists.denx.de > >> Subject: Re: [U-Boot] switching to single .config configuration > >> issues > >> > >> Hi Yehuda, > >> > >> On 30 April 2015 at 01:21, Yehuda Yitschak > wrote: > >> > Hey Masahiro > >> > > >> >> -Original Message- > >> >> From: Masahiro Yamada [mailto:yamada.masah...@socionext.com] > >> >> Sent: Thursday, April 30, 2015 4:46 > >> >> To: Yehuda Yitschak > >> >> Cc: Simon Glass; Hanna Hawa; u-boot@lists.denx.de > >> >> Subject: Re: [U-Boot] switching to single .config configuration > >> >> issues > >> >> > >> >> Hi Yehuda, > >> >> > >> >> > >> >> 2015-04-29 14:23 GMT+09:00 Yehuda Yitschak > : > >> >> > Hey Simon, Masahiro > >> >> > > >> >> > May I suggest an alternative solution to this issue. > >> >> > > >> >> > What if each Kconfigs option could be set as "y" (compile for > >> >> > u-boot only )or "s" (compile for u-boot and SPL) Just as the > >> >> > kernel can set Kconfig > >> >> to "y" or "m". > >> >> > > >> >> > With minor modifications to the Makefile, SPL target will compile > "obj-s" > >> >> and u-boot target will compile "obj-s" and "obj-y" > >> >> > > >> >> > What do you think ? > >> >> > >> >> > >> >> Interesting. > >> >> > >> >> A little comments. > >> >> > >> >> - Is there any possibility that some files should be compiled for SPL > only? > >> >>(I do not think we have much.) > >> >> > >> >>Perhaps, obj-y : for U-boot only > >> >> obj-s : for SPL only > >> >> oby-ys: for both > >> >> I am not sure.. > >> > > >> > How about "a" (as in all targets) instead of "sy". It will look > >> > better in the menuconfig square brackets Maybe TPL should also be > added as "t" > >> option. > >> > > >> >> > >> >> - This idea is only applicable for bool options. > >> >> We still have to keep duplication for int/hex options such as > >> >> CONFIG_SPL_TEXT_BASE. > >> >> > >> >> But, this idea will help clean up much because most of configs > >> >> are > >> boolean. > >> > >> I am still not sure what sorts of things are getting compiled int > >> SPL, and thus causing problems. Can you please provide a few details? > > > > We are looking for a very small SPL image that will fit into internal SRAM. > > Therefore we want to compile the minimal set of drivers into the SPL. > > We have added all our drivers to Kconfig infrastructure (not mainlined > > yet) and so each driver We add to u-boot (like PCIe) will be added to > > SPL and would require manual removal using the dedicated H file > > I see. Let's see what Masahiro thinks about this. One good thing with this > proposal is that we would still only have a single config source file > (.config), > but I cannot see how it could be implemented without having multiple > output autoconf.h files. Linux actually uses a single autoconf.h file by suffixing module configs with _MODULE. Then all the other build scripts somehow take advantage of that > > How many options do you need to add for manual removal? I don’t have the exact count but somewhere around 10-20. However I think the number itself is not the issue. The thing is that you have to update this list every time you modify your defconfig otherwise your SPL start bloating. That is a bit of a nuisance considering defconfig changes may be frequent during development and ramp-up time > > Regards, > Simon > > > > >> > >> >> > >> >> > >> >> Best Regards > >> >> Masahiro Yamada > >> >> > >> >> > >> >> >> -Original Message- > >> >> >> From: s...@google.com [mailto:s...@google.com] On Behalf Of > Simon > >> >> Glass > >> >> >> Sent: Wednesday, April 29, 2015 6:06 > >> >> >> To: Hanna Hawa > >> >> >> Cc: u-boot@lists.denx.de; Yehuda Yitschak; Masahiro Yamada > >> >> >> Subject: Re: switching to single .config configuration issues > >> >> >> > >> >> >> +Masahiro (new address) > >> >> >> > >> >> >> Hi Hanna, > >> >> >> > >> >> >> On 27 April 2015 at 07:43, Hanna Hawa > wrote: > >> >> >> > Hi everyone, > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > I’m working on the latest u-boot 2015.04 trying to rebase my > >> >> >> > repository to latest code. > >> >> >> > >> >> >> I would suggest going with upstream/master (targeting 2015.07) > >> >> >> since there are several driver model changes since 2015.04 > >> >> >> (USB, PCI, Ethernet). There are still patches going in but the > >> >> >> bulk of it should be > >> >> there. > >> >> >> > >> >> >>
[U-Boot] [PATCH 1/2] sunxi: Set SYS_MALLOC_CLEAR_ON_INIT to n
We don't need this on sunxi, and not having is shaves some time of out boot time. Signed-off-by: Hans de Goede --- board/sunxi/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index bd1e988..940b6c7 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -549,6 +549,9 @@ config GMAC_TX_DELAY ---help--- Set the GMAC Transmit Clock Delay Chain value. +config SYS_MALLOC_CLEAR_ON_INIT + default n + config NET default y -- 2.3.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] console: Fix pre-console flushing via cfb_console being very slow
On my A10 OlinuxIno Lime I noticed a huge (5+ seconds) delay coming from
console_init_r. This turns out to be caused by the preconsole buffer flushing
to the cfb_console. The Lime only has a 16 bit memory bus and that is already
heavy used to scan out the 1920x1080 framebuffer.
The problem is that print_pre_console_buffer() was printing the buffer once
character at a time and the cfb_console code then ends up doing a cache-flush
for touched display lines for each character.
This commit fixes this by first building a 0 terminated buffer and then
printing it in one puts() call, avoiding unnecessary cache flushes.
This changes the time for the flush from 5+ seconds to not noticable.
The downside of this approach is that the pre-console buffer needs to fit
on the stack, this is not that much to ask since we are talking about plain
text here. This commit also adjusts the sunxi CONFIG_PRE_CON_BUF_SZ to
actually fit on the stack. Sunxi currently is the only user of the pre-console
code so no other boards need to be adjusted.
Signed-off-by: Hans de Goede
---
README | 3 +++
common/console.c | 40 ++--
include/configs/sunxi-common.h | 2 +-
3 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/README b/README
index ee65fdb..4e67c93 100644
--- a/README
+++ b/README
@@ -948,6 +948,9 @@ The following options need to be configured:
bytes are output before the console is initialised, the
earlier bytes are discarded.
+ Note that when printing the buffer a copy is made on the
+ stack so CONFIG_PRE_CON_BUF_SZ must fit on the stack.
+
'Sane' compilers will generate smaller code if
CONFIG_PRE_CON_BUF_SZ is a power of 2
diff --git a/common/console.c b/common/console.c
index 3f25e76..0058222 100644
--- a/common/console.c
+++ b/common/console.c
@@ -200,15 +200,15 @@ static void console_putc(int file, const char c)
}
#ifdef CONFIG_PRE_CONSOLE_BUFFER
-static void console_putc_noserial(int file, const char c)
+static void console_puts_noserial(int file, const char *s)
{
int i;
struct stdio_dev *dev;
for (i = 0; i < cd_count[file]; i++) {
dev = console_devices[file][i];
- if (dev->putc != NULL && strcmp(dev->name, "serial") != 0)
- dev->putc(dev, c);
+ if (dev->puts != NULL && strcmp(dev->name, "serial") != 0)
+ dev->puts(dev, s);
}
}
#endif
@@ -251,10 +251,10 @@ static inline void console_putc(int file, const char c)
}
#ifdef CONFIG_PRE_CONSOLE_BUFFER
-static inline void console_putc_noserial(int file, const char c)
+static inline void console_puts_noserial(int file, const char *s)
{
if (strcmp(stdio_devices[file]->name, "serial") != 0)
- stdio_devices[file]->putc(stdio_devices[file], c);
+ stdio_devices[file]->puts(stdio_devices[file], s);
}
#endif
@@ -425,22 +425,26 @@ static void pre_console_puts(const char *s)
static void print_pre_console_buffer(int flushpoint)
{
- unsigned long i = 0;
- char *buffer = (char *)CONFIG_PRE_CON_BUF_ADDR;
+ unsigned long in = 0, out = 0;
+ char *buf_in = (char *)CONFIG_PRE_CON_BUF_ADDR;
+ char buf_out[CONFIG_PRE_CON_BUF_SZ + 1];
if (gd->precon_buf_idx > CONFIG_PRE_CON_BUF_SZ)
- i = gd->precon_buf_idx - CONFIG_PRE_CON_BUF_SZ;
+ in = gd->precon_buf_idx - CONFIG_PRE_CON_BUF_SZ;
- while (i < gd->precon_buf_idx)
- switch (flushpoint) {
- case PRE_CONSOLE_FLUSHPOINT1_SERIAL:
- putc(buffer[CIRC_BUF_IDX(i++)]);
- break;
- case PRE_CONSOLE_FLUSHPOINT2_EVERYTHING_BUT_SERIAL:
- console_putc_noserial(stdout,
- buffer[CIRC_BUF_IDX(i++)]);
- break;
- }
+ while (in < gd->precon_buf_idx)
+ buf_out[out++] = buf_in[CIRC_BUF_IDX(in++)];
+
+ buf_out[out] = 0;
+
+ switch (flushpoint) {
+ case PRE_CONSOLE_FLUSHPOINT1_SERIAL:
+ puts(buf_out);
+ break;
+ case PRE_CONSOLE_FLUSHPOINT2_EVERYTHING_BUT_SERIAL:
+ console_puts_noserial(stdout, buf_out);
+ break;
+ }
}
#else
static inline void pre_console_putc(const char c) {}
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index c78141e..5d77e71 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -402,7 +402,7 @@ extern int soft_i2c_gpio_scl;
/* Enable pre-console buffer to get complete log on the VGA console */
#define CONFIG_PRE_CONSOLE_BUFFER
-#define CONFIG_PRE_CON_BUF_SZ (1024 * 1024)
+#define CONFIG_PRE_CON_BUF_SZ 4096 /* Aprox 2 80*25 screens */
#ifdef CONFIG_M
[U-Boot] [PATCH v3] dm: sf: Add Atmel DataFlash spi flash driver
Atmel DataFlash chips have commands different from common spi
flash commands.
Atmel DataFlash also have special page-size.
This driver add support for accessing Atmel DataFlash.
It is based on the Driver Model.
Signed-off-by: Haikun Wang
---
Verified with AT45DB021B.
Changes in v3:
- 1. Rename file spi_dataflash.c to sf_dataflash.c
- 2. Add comment for array "dataflash_data"
Changes in v2:
- 1. Correct comment style
- 2. Use get_timer in dataflash_waitready to check whether timeout
- 3. Remove struct spi_flash * in struct dataflash, and get it from
udevice->uclass_priv
- 4. Replace spi_flash_write_common with spi_flash_cmd_write
- 5. Replace spi_flash_read with spi_flash_cmd_read
- 6. Change type of varible "status" form char to u8 in dataflash_status
- 7. Change add_dataflash's argument type due to
- 8. Add claim_bus and release_bus in erase/write/read due to
Changes in v1: None
drivers/mtd/spi/Makefile | 1 +
drivers/mtd/spi/sf_dataflash.c | 711 +
2 files changed, 712 insertions(+)
create mode 100644 drivers/mtd/spi/sf_dataflash.c
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index c61b784..8adec3d 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -15,6 +15,7 @@ endif
#ifndef CONFIG_DM_SPI
obj-$(CONFIG_SPI_FLASH) += sf_probe.o
#endif
+obj-$(CONFIG_DM_SF_DATAFLASH) += sf_dataflash.o
obj-$(CONFIG_CMD_SF) += sf.o
obj-$(CONFIG_SPI_FLASH) += sf_ops.o sf_params.o
obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o
diff --git a/drivers/mtd/spi/sf_dataflash.c b/drivers/mtd/spi/sf_dataflash.c
new file mode 100644
index 000..817a9be
--- /dev/null
+++ b/drivers/mtd/spi/sf_dataflash.c
@@ -0,0 +1,711 @@
+/*
+ *
+ * Atmel DataFlash probing
+ *
+ * Copyright (C) 2004-2009, 2015 Freescale Semiconductor, Inc.
+ * Haikun Wang (haikun.w...@freescale.com)
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+*/
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sf_internal.h"
+
+/*
+ * DataFlash is a kind of SPI flash. Most AT45 chips have two buffers in
+ * each chip, which may be used for double buffered I/O; but this driver
+ * doesn't (yet) use these for any kind of i/o overlap or prefetching.
+ *
+ * Sometimes DataFlash is packaged in MMC-format cards, although the
+ * MMC stack can't (yet?) distinguish between MMC and DataFlash
+ * protocols during enumeration.
+ */
+
+/* reads can bypass the buffers */
+#define OP_READ_CONTINUOUS 0xE8
+#define OP_READ_PAGE 0xD2
+
+/* group B requests can run even while status reports "busy" */
+#define OP_READ_STATUS 0xD7/* group B */
+
+/* move data between host and buffer */
+#define OP_READ_BUFFER10xD4/* group B */
+#define OP_READ_BUFFER20xD6/* group B */
+#define OP_WRITE_BUFFER1 0x84/* group B */
+#define OP_WRITE_BUFFER2 0x87/* group B */
+
+/* erasing flash */
+#define OP_ERASE_PAGE 0x81
+#define OP_ERASE_BLOCK 0x50
+
+/* move data between buffer and flash */
+#define OP_TRANSFER_BUF1 0x53
+#define OP_TRANSFER_BUF2 0x55
+#define OP_MREAD_BUFFER1 0xD4
+#define OP_MREAD_BUFFER2 0xD6
+#define OP_MWERASE_BUFFER1 0x83
+#define OP_MWERASE_BUFFER2 0x86
+#define OP_MWRITE_BUFFER1 0x88/* sector must be pre-erased */
+#define OP_MWRITE_BUFFER2 0x89/* sector must be pre-erased */
+
+/* write to buffer, then write-erase to flash */
+#define OP_PROGRAM_VIA_BUF10x82
+#define OP_PROGRAM_VIA_BUF20x85
+
+/* compare buffer to flash */
+#define OP_COMPARE_BUF10x60
+#define OP_COMPARE_BUF20x61
+
+/* read flash to buffer, then write-erase to flash */
+#define OP_REWRITE_VIA_BUF10x58
+#define OP_REWRITE_VIA_BUF20x59
+
+/*
+ * newer chips report JEDEC manufacturer and device IDs; chip
+ * serial number and OTP bits; and per-sector writeprotect.
+ */
+#define OP_READ_ID 0x9F
+#define OP_READ_SECURITY 0x77
+#define OP_WRITE_SECURITY_REVC 0x9A
+#define OP_WRITE_SECURITY 0x9B/* revision D */
+
+
+struct dataflash {
+ uint8_t command[16];
+ unsigned short page_offset;/* offset in flash address */
+};
+
+/*
+ * Return the status of the DataFlash device.
+ */
+static inline int dataflash_status(struct spi_slave *spi)
+{
+ int ret;
+ u8 status;
+ /*
+* NOTE: at45db321c over 25 MHz wants to write
+* a dummy byte after the opcode...
+*/
+ ret = spi_flash_cmd(spi, OP_READ_STATUS, &status, 1);
+ return ret ? -EIO : status;
+}
+
+/*
+ * Poll the DataFlash device until it is READY.
+ * This usually takes 5-20 msec or so; more for sector erase.
+ * ready: return > 0
+ */
+static int dataflash_waitready(struct spi_slave *spi)
+{
+ int status;
+ int timeout = 2 * CONFIG_SYS_HZ;
+ int timebase;
+
+ timebase = get_time
Re: [U-Boot] [PATCH v1 1/2] cmd_sf: Add command "sf info" to show current device info
On 5/1/2015 9:54 AM, Simon Glass wrote:
> Hi,
>
> On 29 April 2015 at 04:40, Haikun Wang wrote:
>> Add command "sf info" to show the information of the current SPI flash
>> device.
>>
>> Signed-off-by: Haikun Wang
>> ---
>> In current sf driver, we show the debug information during the flash probe
>> period.
>>
>> In case of without DM SPI, we need to run command "sf probe" to get the debug
>> information of the current SPI flash device. "sf probe" will re-identify the
>> device every time and it reduce the efficiency. We can get the debug
>> information
>> without any re-identify process using "sf info".
>>
>> In case of using DM SPI, if we disable CONFIG_DM_DEVICE_REMOVE "sf probe"
>> will
>> only call the flash driver's probe function the first time you run it and no
>> information will show after the first. It is recommended that only call the
>> flash driver's probe function once during u-boot period. You can get the
>> debug
>> information using "sf info" in this case.
>>
>> Changes in v1: None.
>>
>> common/cmd_sf.c | 43 ++-
>> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> I wonder if you should enable this command only when driver model is used?
You mean I should only enable it when driver model is used?
I think it is also useful in NO-DM model.
We can get the device information without data transfer using this command.
Best regards,
Wang Haikun
>
>>
>> diff --git a/common/cmd_sf.c b/common/cmd_sf.c
>> index 6aabf39..38841fa 100644
>> --- a/common/cmd_sf.c
>> +++ b/common/cmd_sf.c
>> @@ -503,6 +503,44 @@ static int do_spi_flash_test(int argc, char * const
>> argv[])
>> }
>> #endif /* CONFIG_CMD_SF_TEST */
>>
>> +static int do_spi_flash_info(struct spi_flash *flash, bool dm_column_style)
>> +{
>> + if (dm_column_style) {
>> + struct udevice *bus;
>> + struct udevice *dev;
>> + struct dm_spi_slave_platdata *plat;
>> +
>> + dev = flash->dev;
>> + bus = dev->parent;
>> + plat = dev_get_parent_platdata(dev);
>> +
>> + printf("Device: %s\n", dev->name);
>> + printf("Chipselect: %d\n", plat->cs);
>> + printf("Bind Driver: %s\n", dev->driver->name);
>> + printf("SPI bus: %s\n", bus->name);
>> + printf("SPI bus number: %d\n", bus->seq);
>> + printf("Flash type: %s\n", flash->name);
>> + printf("Page size: ");
>> + print_size(flash->page_size, "\n");
>> + printf("Erase size: ");
>> + print_size(flash->erase_size, "\n");
>> + printf("Total size: ");
>> + print_size(flash->size, "\n");
>> + if (flash->memory_map)
>> + printf("Mapped at %p\n", flash->memory_map);
>> + } else {
>> + printf("SF: Detected %s with page size ", flash->name);
>> + print_size(flash->page_size, ", erase size ");
>> + print_size(flash->erase_size, ", total ");
>> + print_size(flash->size, "");
>> + if (flash->memory_map)
>> + printf(", mapped at %p", flash->memory_map);
>> + puts("\n");
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static int do_spi_flash(cmd_tbl_t *cmdtp, int flag, int argc,
>> char * const argv[])
>> {
>> @@ -537,6 +575,8 @@ static int do_spi_flash(cmd_tbl_t *cmdtp, int flag, int
>> argc,
>> else if (!strcmp(cmd, "test"))
>> ret = do_spi_flash_test(argc, argv);
>> #endif
>> + else if (!strcmp(cmd, "info"))
>> + ret = do_spi_flash_info(flash,
>> IS_ENABLED(CONFIG_DM_SPI_FLASH));
>> else
>> ret = -1;
>>
>> @@ -567,6 +607,7 @@ U_BOOT_CMD(
>> "sf erase offset [+]len - erase `len' bytes from `offset'\n"
>> " `+len' round up `len' to block
>> size\n"
>> "sf update addr offset len - erase and write `len' bytes from
>> memory\n"
>> - " at `addr' to flash at `offset'"
>> + " at `addr' to flash at `offset'\n"
>> + "sf info - display info of the current SPI Flash device\n"
>> SF_TEST_HELP
>> );
>> --
>> 2.1.0.27.g96db324
>>
>
> Regards,
> Simon
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fw_env.h: include autoconf.h
On Thu, 2015-04-16 at 13:20 -0400, Tom Rini wrote: > I'll let Masahiro comment on if this is the best way to fix the compile > problem. What's the status on this one? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [REGRESSION] commit 3ef46a9 "Fix hash verification" breaks crc32 verify
U-Boot SPL 2015.04-00631-gace97d2 (May 05 2015 - 13:32:44) U-Boot 2015.04-00631-gace97d2 (May 05 2015 - 13:32:44) TEGRA30 Model: Toradex Colibri T30 DRAM: 1 GiB iC: Tegra SD/MMC: 0, Tegra SD/MMC: 1 In:serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 Colibri T30 # crc32 0x8000 0x100 crc32 for 8000 ... 80ff ==> 9eb4f5ca Colibri T30 # crc32 -v 0x8000 0x100 c9a057b3 crc32 for 8000 ... 80ff ==> 9eb4f5ca != ** ERROR ** Colibri T30 # crc32 -v 0x8000 0x100 9eb4f5ca crc32 for 8000 ... 80ff ==> 9eb4f5ca != 301eeead ** ERROR ** WTF is going on? Git bisection revealed the following: 3ef46a998a2f2c52e227246ac0438ca048ddfd09 is the first bad commit commit 3ef46a998a2f2c52e227246ac0438ca048ddfd09 Author: Nikolay Dimitrov Date: Fri Dec 12 20:01:23 2014 +0200 Fix hash verification Fix issue in parse_verify_sum() which swaps handling of env-var and *address. Move hash_command() argc check earlier. Cosmetic change on do_hash() variable declaration. Improved help message for "hash" command. Signed-off-by: Nikolay Dimitrov Reviewed-by: Simon Glass :04 04 631448e48e845fa9a5c33600e02c7f5b8ea886b0 1a75a34d961c61729a10babb9e875ac8e66f03dc M common git revert 3ef46a998a2f2c52e227246ac0438ca048ddfd09 Colibri T30 # crc32 0x8000 0x100 crc32 for 8000 ... 80ff ==> 9eb4f5ca Colibri T30 # crc32 -v 0x8000 0x100 c9a057b3 crc32 for 8000 ... 80ff ==> 9eb4f5ca != c9a057b3 ** ERROR ** Colibri T30 # crc32 -v 0x8000 0x100 9eb4f5ca Ah, that looks much better! I will cook up a proper patch shortly... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common: hash: fix crc32 verify
From: Marcel Ziswiler
did not work:
Colibri T30 # crc32 0x8000 0x100
crc32 for 8000 ... 80ff ==> 9eb4f5ca
Colibri T30 # crc32 -v 0x8000 0x100 c9a057b3
crc32 for 8000 ... 80ff ==> 9eb4f5ca != ** ERROR **
Colibri T30 # crc32 -v 0x8000 0x100 9eb4f5ca
crc32 for 8000 ... 80ff ==> 9eb4f5ca != 301eeead ** ERROR **
now works again:
Colibri T30 # crc32 0x8000 0x100
crc32 for 8000 ... 80ff ==> 9eb4f5ca
Colibri T30 # crc32 -v 0x8000 0x100 c9a057b3
crc32 for 8000 ... 80ff ==> 9eb4f5ca != c9a057b3 ** ERROR **
Colibri T30 # crc32 -v 0x8000 0x100 9eb4f5ca
Signed-off-by: Marcel Ziswiler
---
common/hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/hash.c b/common/hash.c
index c94c98b..7ae7c2f 100644
--- a/common/hash.c
+++ b/common/hash.c
@@ -307,7 +307,7 @@ static int parse_verify_sum(struct hash_algo *algo, char
*verify_str,
env_var = 1;
}
- if (!env_var) {
+ if (env_var) {
ulong addr;
void *buf;
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-marvell master
Hi Tom,
please pull from marvell/master. The changes include Stefan's Armada 38x
series which reached v3 on the mailing list and two more Marvell Armada
related fixes.
The following changes since commit ace97d26176a3ebc9ec07738450de93eea35975c:
Merge branch 'zynq' of git://www.denx.de/git/u-boot-microblaze (2015-04-29
06:46:33 -0400)
are available in the git repository at:
git://git.denx.de/u-boot-marvell.git
for you to fetch changes up to 2083db7a75792d317a8e726e8be72abea8941d03:
arm: mvebu: Remove "u-boot.kwb" CONFIG_BUILD_TARGET for non-SPL targets
(2015-05-05 14:32:05 +0200)
Stefan Roese (15):
arm: armada-xp: Move SoC sources to mach-mvebu
arm: armada-xp: Move SoC headers to mach-mvebu/include/mach
arm: mvebu: Move mvebu-common into mach-mvebu
arm: mvebu: Change header macros from ARMADA_XP to MVEBU
arm: mvebu: Remove unreferenced define
arm: mvebu: Only define MV88F78X60 for Armada XP
arm: mvebu: Move CONFIG_SPL_LDSCRIPT to common header
arm: mvebu: Add basic Armada 38x support
arm: mvebu: Change network init code to allow a more flexible setup
arm: mvebu: Remove coherency configuration
arm: mvebu: mv-common.h: Add CONFIG_PREBOOT
arm: mvebu: Add d-cache invalidate before enabling the d-cache
arm: mvebu: Add Armada A38x DB-88F6820-GP board support
arm: mvebu: db-mv784mp-gp: Fix ECC I2C address
arm: mvebu: Remove "u-boot.kwb" CONFIG_BUILD_TARGET for non-SPL targets
arch/arm/Kconfig | 6 ++
arch/arm/Makefile | 5 +-
arch/arm/cpu/armv7/Makefile| 1 -
arch/arm/cpu/armv7/armada-xp/Makefile | 9 --
arch/arm/mach-mvebu/Makefile | 24 +
arch/arm/{cpu/armv7/armada-xp => mach-mvebu}/cpu.c | 96 +++
arch/arm/{mvebu-common => mach-mvebu}/dram.c | 0
arch/arm/{mvebu-common => mach-mvebu}/gpio.c | 0
.../include/mach}/config.h | 17 ++--
.../include/mach}/cpu.h| 13 ++-
.../include/mach}/soc.h| 20 ++--
.../armv7/armada-xp => mach-mvebu}/lowlevel_spl.S | 0
arch/arm/{mvebu-common => mach-mvebu}/mbus.c | 3 -
.../{mvebu-common => mach-mvebu}/serdes/Makefile | 0
.../serdes/board_env_spec.h| 0
.../serdes/high_speed_env_lib.c| 0
.../serdes/high_speed_env_spec.c | 0
.../serdes/high_speed_env_spec.h | 0
arch/arm/{cpu/armv7/armada-xp => mach-mvebu}/spl.c | 0
arch/arm/{mvebu-common => mach-mvebu}/timer.c | 0
.../{mvebu-common => mach-mvebu}/u-boot-spl.lds| 0
board/Marvell/db-88f6820-gp/Kconfig| 15 +++
board/Marvell/db-88f6820-gp/Makefile | 7 ++
board/Marvell/db-88f6820-gp/binary.0 | 16
board/Marvell/db-88f6820-gp/db-88f6820-gp.c| 103 +
board/Marvell/db-88f6820-gp/kwbimage.cfg | 12 +++
board/Marvell/db-mv784mp-gp/Kconfig| 2 +-
board/Marvell/db-mv784mp-gp/db-mv784mp-gp.c| 3 +-
board/maxbcm/Kconfig | 2 +-
board/maxbcm/maxbcm.c | 2 +-
configs/db-88f6820-gp_defconfig| 2 +
drivers/ddr/mvebu/ddr3_axp.h | 2 +-
include/configs/db-88f6820-gp.h| 72 ++
include/configs/db-mv784mp-gp.h| 3 +-
include/configs/maxbcm.h | 3 +-
include/configs/mv-common.h| 1 +
36 files changed, 379 insertions(+), 60 deletions(-)
delete mode 100644 arch/arm/cpu/armv7/armada-xp/Makefile
create mode 100644 arch/arm/mach-mvebu/Makefile
rename arch/arm/{cpu/armv7/armada-xp => mach-mvebu}/cpu.c (71%)
rename arch/arm/{mvebu-common => mach-mvebu}/dram.c (100%)
rename arch/arm/{mvebu-common => mach-mvebu}/gpio.c (100%)
rename arch/arm/{include/asm/arch-armada-xp =>
mach-mvebu/include/mach}/config.h (86%)
rename arch/arm/{include/asm/arch-armada-xp => mach-mvebu/include/mach}/cpu.h
(93%)
rename arch/arm/{include/asm/arch-armada-xp => mach-mvebu/include/mach}/soc.h
(81%)
rename arch/arm/{cpu/armv7/armada-xp => mach-mvebu}/lowlevel_spl.S (100%)
rename arch/arm/{mvebu-common => mach-mvebu}/mbus.c (99%)
rename arch/arm/{mvebu-common => mach-mvebu}/serdes/Makefile (100%)
rename arch/arm/{mvebu-common => mach-mvebu}/serdes/board_env_spec.h (100%)
rename arch/arm/{mvebu-common => mach-mvebu}/serdes/high_speed_env_lib.c (100%)
rename arch/arm/{mvebu-common => mach-mvebu}/serdes/high_speed_env_spec.c
(100%)
rename arch/arm/{mvebu-common => mach-mvebu}/serdes/high_speed_env_spec.h
(100%)
rename arch/arm/{cpu/armv7/armada-xp => mach-mvebu}/spl.c (100%)
rename arch/arm
[U-Boot] [PATCH 0/5] dm: usb: Add companion controller support + ehci fixes
Hi Simon, Marek, I'm making steady progress with adding ohci / companion controller support to the sunxi usb code. Things are progressing a bit slower then I would have liked as I've been hitting bugs in the usb-core, ehci and ohci code, but I've things mostly working now I just need to do some more polishing. Patches 1-3 add a (primitive) notion of companion controllers to the dm-usb code. Patch 4 contains a bug-fix for the ehci companion related code Patch 5 adds integration with the dm-usb companion code to the ehci driver Since patch 5 depends on patches 3 and 4 I believe it would be best for this entire series to go upstream through the dm tree (Marek, we will need your ack for patch 4 and 5 for this). This series sits on top of my previous dm-usb fixes + sunxi ehci dm support series. I hope to be able to post yet another series sitting on top of this one tonight which will add the actual ohci support, that one will make a lot of ohci driver changes as well as some usb core changes and thus should go upstream through Marek's tree once this series has landed. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] dm: usb: Do not scan companion busses if no devices where handed over
USB scanning is slow, and there is no need to scan the companion busses
if no usb devices where handed over to the companinon controllers by any
of the main controllers.
This saves e.g. 2 seconds when booting a A10 OLinuxIno Lime with no USB-1
devices plugged into the root usb ports.
The use of a global variable for the companion handover counting is somewhat
unfortunate, but we do not have the necessary info to link companions and
main controllers together in devicetree, and since this is just an
optimization adding a custom devicetree extenstion for this seems undesirable.
Signed-off-by: Hans de Goede
---
common/usb.c | 2 ++
drivers/usb/host/usb-uclass.c | 12 +++-
include/usb.h | 3 +++
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/common/usb.c b/common/usb.c
index 1b26bfa..4a09583 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -44,6 +44,8 @@
static int asynch_allowed;
char usb_started; /* flag for the started/stopped USB status */
+/* Tracks how much devices were handed over to companion controllers */
+int usb_companion_device_count;
#ifndef CONFIG_DM_USB
static struct usb_device usb_dev[USB_MAX_DEVICE];
diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index d745c1c..877d307 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -219,12 +219,14 @@ int usb_init(void)
/*
* Now that the primary controllers have been scanned and have handed
* over any devices they do not understand to their companions, scan
-* the companions.
+* the companions if necessary.
*/
- uclass_foreach_dev(bus, uc) {
- priv = dev_get_uclass_priv(bus);
- if (priv->companion)
- usb_scan_bus(bus, true);
+ if (usb_companion_device_count) {
+ uclass_foreach_dev(bus, uc) {
+ priv = dev_get_uclass_priv(bus);
+ if (priv->companion)
+ usb_scan_bus(bus, true);
+ }
}
debug("scan end\n");
diff --git a/include/usb.h b/include/usb.h
index b81e796..d4c9f44 100644
--- a/include/usb.h
+++ b/include/usb.h
@@ -171,6 +171,9 @@ enum usb_init_type {
* this is how the lowlevel part communicate with the outer world
*/
+/* Tracks how much devices were handed over to companion controllers */
+extern int usb_companion_device_count;
+
#if defined(CONFIG_USB_UHCI) || defined(CONFIG_USB_OHCI) || \
defined(CONFIG_USB_EHCI) || defined(CONFIG_USB_OHCI_NEW) || \
defined(CONFIG_USB_SL811HS) || defined(CONFIG_USB_ISP116X_HCD) || \
--
2.3.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] dm: usb: Move printing of usb scan status to usb_scan_bus()
Move printing of usb scan status to usb_scan_bus().
This is a preparation patch for adding companion controller support to the
usb uclass.
Signed-off-by: Hans de Goede
---
drivers/usb/host/usb-uclass.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index 9ee25ed..ad778b4 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -147,7 +147,7 @@ int usb_stop(void)
return err;
}
-static int usb_scan_bus(struct udevice *bus, bool recurse)
+static void usb_scan_bus(struct udevice *bus, bool recurse)
{
struct usb_bus_priv *priv;
struct udevice *dev;
@@ -157,11 +157,15 @@ static int usb_scan_bus(struct udevice *bus, bool recurse)
assert(recurse);/* TODO: Support non-recusive */
+ printf("scanning bus %d for devices... ", bus->seq);
+ debug("\n");
ret = usb_scan_device(bus, 0, USB_SPEED_FULL, &dev);
if (ret)
- return ret;
-
- return priv->next_addr;
+ printf("failed, error %d\n", ret);
+ else if (priv->next_addr == 0)
+ printf("No USB Device found\n");
+ else
+ printf("%d USB Device(s) found\n", priv->next_addr);
}
int usb_init(void)
@@ -199,15 +203,7 @@ int usb_init(void)
* i.e. search HUBs and configure them
*/
controllers_initialized++;
- printf("scanning bus %d for devices... ", bus->seq);
- debug("\n");
- ret = usb_scan_bus(bus, true);
- if (ret < 0)
- printf("failed, error %d\n", ret);
- else if (!ret)
- printf("No USB Device found\n");
- else
- printf("%d USB Device(s) found\n", ret);
+ usb_scan_bus(bus, true);
usb_started = true;
}
--
2.3.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] usb: ehci: Increase usb_companion_device_count when handing over devices
Increase usb_companion_device_count when handing over devices to the ehci's
companion controller. usb_init() will use this to short-circuit companion
bus scanning when no devices were handed over at all.
Signed-off-by: Hans de Goede
---
drivers/usb/host/ehci-hcd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 25981ef..40d6dc1 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -873,6 +873,7 @@ static int ehci_submit_root(struct usb_device *dev,
unsigned long pipe,
/* Low speed device, give up ownership. */
debug("port %d low speed --> companion\n",
port - 1);
+ usb_companion_device_count++;
reg |= EHCI_PS_PO;
ehci_writel(status_reg, reg);
break;
@@ -902,6 +903,7 @@ static int ehci_submit_root(struct usb_device *dev,
unsigned long pipe,
if ((reg & (EHCI_PS_PE | EHCI_PS_CS))
== EHCI_PS_CS && !ehci_is_TDI()) {
debug("port %d full speed -->
companion\n", port - 1);
+ usb_companion_device_count++;
reg &= ~EHCI_PS_CLEAR;
reg |= EHCI_PS_PO;
ehci_writel(status_reg, reg);
--
2.3.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] usb: ehci: Fix handover of full-speed devices to companion
When after a reset the port status connection bit is still set and the enable
bit is not then we're dealing with a full-speed device and should hand it over
to the companion controller.
Signed-off-by: Hans de Goede
---
drivers/usb/host/ehci-hcd.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 0e84265..25981ef 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -897,11 +897,21 @@ static int ehci_submit_root(struct usb_device *dev,
unsigned long pipe,
*/
ret = handshake(status_reg, EHCI_PS_PR, 0,
2 * 1000);
- if (!ret)
- ctrl->portreset |= 1 << port;
- else
+ if (!ret) {
+ reg = ehci_readl(status_reg);
+ if ((reg & (EHCI_PS_PE | EHCI_PS_CS))
+ == EHCI_PS_CS && !ehci_is_TDI()) {
+ debug("port %d full speed -->
companion\n", port - 1);
+ reg &= ~EHCI_PS_CLEAR;
+ reg |= EHCI_PS_PO;
+ ehci_writel(status_reg, reg);
+ } else {
+ ctrl->portreset |= 1 << port;
+ }
+ } else {
printf("port(%d) reset error\n",
port - 1);
+ }
}
break;
case USB_PORT_FEAT_TEST:
--
2.3.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] dm: usb: Add support for companion controllers
USB companion controllers must be scanned after the main controller has
been scanned, so that any devices which the main controller which to hand
over to the companion have actually been handed over before we scan the
companion.
As there are no guarantees that this will magically happen in the right
order, split the scanning of the busses in 2 phases, first main controllers,
and then companion controllers.
Signed-off-by: Hans de Goede
---
drivers/usb/host/usb-uclass.c | 30 +-
include/usb.h | 2 ++
2 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index ad778b4..d745c1c 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -157,6 +157,9 @@ static void usb_scan_bus(struct udevice *bus, bool recurse)
assert(recurse);/* TODO: Support non-recusive */
+ if (!device_active(bus))
+ return;
+
printf("scanning bus %d for devices... ", bus->seq);
debug("\n");
ret = usb_scan_device(bus, 0, USB_SPEED_FULL, &dev);
@@ -171,6 +174,7 @@ static void usb_scan_bus(struct udevice *bus, bool recurse)
int usb_init(void)
{
int controllers_initialized = 0;
+ struct usb_bus_priv *priv;
struct udevice *bus;
struct uclass *uc;
int count = 0;
@@ -198,15 +202,31 @@ int usb_init(void)
printf("probe failed, error %d\n", ret);
continue;
}
- /*
-* lowlevel init is OK, now scan the bus for devices
-* i.e. search HUBs and configure them
-*/
controllers_initialized++;
- usb_scan_bus(bus, true);
usb_started = true;
}
+ /*
+* lowlevel init done, now scan the bus for devices i.e. search HUBs
+* and configure them, first scan primary controllers.
+*/
+ uclass_foreach_dev(bus, uc) {
+ priv = dev_get_uclass_priv(bus);
+ if (!priv->companion)
+ usb_scan_bus(bus, true);
+ }
+
+ /*
+* Now that the primary controllers have been scanned and have handed
+* over any devices they do not understand to their companions, scan
+* the companions.
+*/
+ uclass_foreach_dev(bus, uc) {
+ priv = dev_get_uclass_priv(bus);
+ if (priv->companion)
+ usb_scan_bus(bus, true);
+ }
+
debug("scan end\n");
/* if we were not able to find at least one working bus, bail out */
if (!count)
diff --git a/include/usb.h b/include/usb.h
index 7b55844..b81e796 100644
--- a/include/usb.h
+++ b/include/usb.h
@@ -608,10 +608,12 @@ struct usb_dev_platdata {
* @desc_before_addr: true if we can read a device descriptor before it
* has been assigned an address. For XHCI this is not possible
* so this will be false.
+ * @companion: True if this is a companion controler to another USB controller
*/
struct usb_bus_priv {
int next_addr;
bool desc_before_addr;
+ bool companion;
};
/**
--
2.3.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bugfix i.mx6 pwm: prevent overflow of period_c * duty_ns by casting duty_ns to ull first. This bug came up when trying to create a 200 Hz PWM.
Hi Brecht, On Mon, Apr 27, 2015 at 9:11 AM, Brecht Neyrinck wrote: > --- > drivers/pwm/pwm-imx-util.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > mode change 100644 => 100755 drivers/pwm/pwm-imx-util.c > > diff --git a/drivers/pwm/pwm-imx-util.c b/drivers/pwm/pwm-imx-util.c > index f1d0b35..777a8bf 100644 > --- a/drivers/pwm/pwm-imx-util.c > +++ b/drivers/pwm/pwm-imx-util.c > @@ -56,7 +56,7 @@ int pwm_imx_get_parms(int period_ns, int duty_ns, unsigned > long *period_c, > *prescale = *period_c / 0x1 + 1; > > *period_c /= *prescale; > - c = (unsigned long long)(*period_c * duty_ns); > + c = *period_c * (unsigned long long) duty_ns; > do_div(c, period_ns); > *duty_c = c; Your fix looks good, but your patch misses a Signed-off-by. Also the commit log seems to be mixed with the subject. Please check: http://www.denx.de/wiki/U-Boot/Patches You can also send it to the list using git send-email. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] loading environment from SATA
Hi Ben,
On Thu, Apr 30, 2015 at 9:57 AM, Ben Hewson wrote:
> booting from SATA works very well on my iMX6 based board, however if I do
>
>
> #define CONFIG_ENV_IS_IN_FAT
>
> #if defined(CONFIG_ENV_IS_IN_FAT)
> #define CONFIG_FAT_WRITE
> #define FAT_ENV_INTERFACE "sata"
> #define FAT_ENV_DEVICE_AND_PART "0:1"
> #define FAT_ENV_FILE"u-boot.env"
> #endif
>
>
> nothing is loaded as the SATA has not been initialised.
>
> Looking at board_r.c I can see lots of inits, for mmc, nand and other stuff,
> but not sata.
>
> Following the format I have added a function
>
> #ifdef CONFIG_CMD_SATA
> static int initr_sata(void)
> {
> puts("SATA: ");
> sata_initialize();
> return 0;
> }
> #endif
>
> and inside init_fnc_t init_sequence_r[] = { after
>
> #ifdef CONFIG_GENERIC_MMC
> initr_mmc,
> #endif
>
> I have added
>
> #ifdef CONFIG_CMD_SATA
> initr_sata,
> #endif
>
>
> So this compiled and booted and to my surprise worked.
Could you please send a formal patch to the list?
Process is described here: http://www.denx.de/wiki/U-Boot/Patches
Thanks,
Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] nand: sunxi: Add secondary U-Boot offset on second syndrome partition
On Wed, Apr 29, 2015 at 8:02 AM, Daniel Kochmański
wrote:
> Introduces CONFIG_SYS_NAND_U_BOOT_BACKUP_OFFS, pointing to backup
> U-Boot instance in nand memory. In case if first header doesn't match,
> tries to load bootloader from this offset. In case of both failing,
> hang() is called.
>
> Additionally define offset of backup U-boot for sunxi at start of
> second syndrome partition.
>
> Signed-off-by: Daniel Kochmański
> Cc: Ian Campbell
> Cc: Hans De Goede
> ---
>
> README | 4
> common/spl/spl_nand.c | 28 +---
> include/configs/sunxi-common.h | 1 +
> 3 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/README b/README
> index ee65fdb..4ccf3cb 100644
> --- a/README
> +++ b/README
> @@ -3722,6 +3722,10 @@ FIT uImage format:
> CONFIG_SYS_NAND_U_BOOT_OFFS
> Location in NAND to read U-Boot from
>
> + CONFIG_SYS_NAND_U_BOOT_BACKUP_OFFS
> + Location in NAND to read backup U-Boot from, if first
> + location doesn't contain valid image.
> +
> CONFIG_SYS_NAND_U_BOOT_DST
> Location in memory to load U-Boot to
>
> diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
> index 9d59fbb..7c44de1 100644
> --- a/common/spl/spl_nand.c
> +++ b/common/spl/spl_nand.c
> @@ -2,6 +2,9 @@
> * Copyright (C) 2011
> * Corscience GmbH & Co. KG - Simon Schwarz
> *
> + * Copyright (C) 2015
> + * Turtle Solutions - Daniel Kochmański
> + *
> * SPDX-License-Identifier:GPL-2.0+
> */
> #include
> @@ -90,9 +93,28 @@ void spl_nand_load_image(void)
> nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
> sizeof(*header), (void *)header);
> spl_parse_image_header(header);
> - nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
> - spl_image.size,
> - (void *)(unsigned long)spl_image.load_addr);
> + if (header->ih_os == IH_OS_U_BOOT) {
> + nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
> + spl_image.size,
> + (void *)(unsigned
> long)spl_image.load_addr);
> + nand_deselect();
> + return;
> + }
> + puts("U-boot header didn't match.\n");
> +#ifdef CONFIG_SYS_NAND_U_BOOT_BACKUP_OFFS
> + puts("Trying to start backup u-boot now...\n");
> + nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_BACKUP_OFFS,
> + sizeof(*header), (void *)header);
> + spl_parse_image_header(header);
> + if (header->ih_os == IH_OS_U_BOOT) {
> + nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_BACKUP_OFFS,
> + spl_image.size,
> + (void *)(unsigned
> long)spl_image.load_addr);
> + nand_deselect();
> + return;
> + }
> +#endif
> + puts("No valid u-boot image found.\n");
> nand_deselect();
> }
> #endif
Daniel,
Under what circumstances would header->ih_os not be IH_OS_U_BOOT? It
seems to me only if CONFIG_SYS_NAND_U_BOOT_OFFS pointed to the wrong
place but wouldn't this be a board configuration error?
Are you trying to put some redundancy in for detecting a corrupted
image? It seems to me that you would want to do more than check the
header type in that case.
Tim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] autoboot.c: Add feature to stop autobooting via SHA256 encrypted password
Hi Simon,
On 23.03.2015 21:28, Simon Glass wrote:
> Hi Stefan,
>
> On 13 March 2015 at 01:15, Stefan Roese wrote:
>> Hi Simon,
>>
>> On 13.03.2015 03:48, Simon Glass wrote:
>
> This patch adds the feature to only stop the autobooting, and therefor
> boot into the U-Boot prompt, when the input string / password matches
> a values that is encypted via a SHA256 hash and saved in the
> environment.
>
> This feature is enabled by defined these config options:
>CONFIG_AUTOBOOT_KEYED
>CONFIG_AUTOBOOT_STOP_STR_SHA256
>
> Signed-off-by: Stefan Roese
This is certainly interesting but I think brings us back to a point
Simon made a long while back about needing to factor out this code
better. Especially since this adds big long #if-#else-#endif blocks.
Can we re-do this so at least have some functions be called out instead?
Thanks!
>>>
>>> Also if these CONFIG options are in Kconfig (as they should be) then we
>>> can use
>>>
>>> if (IS_ENABLED(CONFIG_AUTOBOOT_STOP_STR_SHA256))
>>>
>>> instead of #ifdef which may improve the code.
>>
>>
>> Right. I also thought about this. But the resulting code has all the
>> functionality extracted into 2 functions:
>>
>> #if defined(CONFIG_AUTOBOOT_STOP_STR_SHA256)
>> static int passwd_abort(uint64_t etime)
>> {
>> const char *sha_env_str = getenv("bootstopkeysha256");
>> ...
>> }
>> #else
>> static int passwd_abort(uint64_t etime)
>> {
>> int abort = 0;
>> ...
>> }
>> #endif
>>
>> And this function is now called unconditionally:
>>
>> ...
>> abort = passwd_abort(etime);
>>
>> So there is nothing here that could be simplified by using IS_ENABLED().
>>
>> I could of course just add this new config option to Kconfig. But with all
>> the other related options not in Kconfig (CONFIG_AUTOBOOT_KEYED,
>> CONFIG_AUTOBOOT_DELAY_STR...), this doesn't make much sense. So at some
>> point all those config options should be moved to Kconfig. Unfortunately I
>> don't have the time for this right now. But I'll add it to my list to do
>> this at a later time.
>
> Well rather than adding more options, perhaps we should wait until we
> get this moved to Kconfig? It's not going to get any easier :-)
Right. And now I'm finally back at this task. To get this encrypted
password support into mainline. With Kconfig support of course this
time. ;)
Unfortunately I'm hitting a problem while moving some of the "old"
macros to Kconfig. Especially some strings like CONFIG_AUTOBOOT_PROMPT.
Here how this looks in some config headers:
#define CONFIG_AUTOBOOT_PROMPT "autoboot in %d seconds\n", bootdelay
This does not work, as Kconfig truncates the string after the 2nd
'"'. Escaping this '"' using '\' also doesn't seem to work. Do you
or Masahiro have some experience with this kind of Kconfig macro
transition?
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] autoboot.c: Add feature to stop autobooting via SHA256 encrypted password
Hi Stefan,
On 5 May 2015 at 09:06, Stefan Roese wrote:
> Hi Simon,
>
> On 23.03.2015 21:28, Simon Glass wrote:
>> Hi Stefan,
>>
>> On 13 March 2015 at 01:15, Stefan Roese wrote:
>>> Hi Simon,
>>>
>>> On 13.03.2015 03:48, Simon Glass wrote:
>>
>> This patch adds the feature to only stop the autobooting, and therefor
>> boot into the U-Boot prompt, when the input string / password matches
>> a values that is encypted via a SHA256 hash and saved in the
>> environment.
>>
>> This feature is enabled by defined these config options:
>>CONFIG_AUTOBOOT_KEYED
>>CONFIG_AUTOBOOT_STOP_STR_SHA256
>>
>> Signed-off-by: Stefan Roese
>
>
> This is certainly interesting but I think brings us back to a point
> Simon made a long while back about needing to factor out this code
> better. Especially since this adds big long #if-#else-#endif blocks.
> Can we re-do this so at least have some functions be called out instead?
> Thanks!
>
Also if these CONFIG options are in Kconfig (as they should be) then we
can use
if (IS_ENABLED(CONFIG_AUTOBOOT_STOP_STR_SHA256))
instead of #ifdef which may improve the code.
>>>
>>>
>>> Right. I also thought about this. But the resulting code has all the
>>> functionality extracted into 2 functions:
>>>
>>> #if defined(CONFIG_AUTOBOOT_STOP_STR_SHA256)
>>> static int passwd_abort(uint64_t etime)
>>> {
>>> const char *sha_env_str = getenv("bootstopkeysha256");
>>> ...
>>> }
>>> #else
>>> static int passwd_abort(uint64_t etime)
>>> {
>>> int abort = 0;
>>> ...
>>> }
>>> #endif
>>>
>>> And this function is now called unconditionally:
>>>
>>> ...
>>> abort = passwd_abort(etime);
>>>
>>> So there is nothing here that could be simplified by using IS_ENABLED().
>>>
>>> I could of course just add this new config option to Kconfig. But with all
>>> the other related options not in Kconfig (CONFIG_AUTOBOOT_KEYED,
>>> CONFIG_AUTOBOOT_DELAY_STR...), this doesn't make much sense. So at some
>>> point all those config options should be moved to Kconfig. Unfortunately I
>>> don't have the time for this right now. But I'll add it to my list to do
>>> this at a later time.
>>
>> Well rather than adding more options, perhaps we should wait until we
>> get this moved to Kconfig? It's not going to get any easier :-)
>
> Right. And now I'm finally back at this task. To get this encrypted
> password support into mainline. With Kconfig support of course this
> time. ;)
>
> Unfortunately I'm hitting a problem while moving some of the "old"
> macros to Kconfig. Especially some strings like CONFIG_AUTOBOOT_PROMPT.
> Here how this looks in some config headers:
>
> #define CONFIG_AUTOBOOT_PROMPT "autoboot in %d seconds\n", bootdelay
>
> This does not work, as Kconfig truncates the string after the 2nd
> '"'. Escaping this '"' using '\' also doesn't seem to work. Do you
> or Masahiro have some experience with this kind of Kconfig macro
> transition?
Not me. I noticed this when refactoring the code. IMO it is broken -
we should not be doing things like that.
>From what I can see we only ever pass bootdelay as a parameter. So
perhaps you can drop the ", bootdelay" part and adjust the code in
from common/autoboot.c from:
printf(CONFIG_AUTOBOOT_PROMPT);
to:
printf(CONFIG_AUTOBOOT_PROMPT, bootdelay);
Of course that will create printf() warnings for a few boards but it
should be possible to turn them off at that call site.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] arm: mx6: tqma6: Update to optionally configure an alternative SPI setup
On 05/05/2015 11:37, Stefan Roese wrote:
> Hi Stefano,
>
> On 12.03.2015 13:34, Stefan Roese wrote:
>> By making the tqma6_iomuxc_spi() weak, this patch adds the possibility to
>> add a different function for this SPI configuration. This can be used
>> by other baseboards, that might have a different SPI setup.
>>
>> This patch will be used by the upcoming WRU-IV board support which also
>> uses the TQMa6 SoM.
>>
>> Signed-off-by: Stefan Roese
>> ---
>> board/tqc/tqma6/tqma6.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c
>> index c9e163e..29db838 100644
>> --- a/board/tqc/tqma6/tqma6.c
>> +++ b/board/tqc/tqma6/tqma6.c
>> @@ -145,7 +145,7 @@ static unsigned const tqma6_ecspi1_cs[] = {
>> TQMA6_SF_CS_GPIO,
>> };
>>
>> -static void tqma6_iomuxc_spi(void)
>> +__weak void tqma6_iomuxc_spi(void)
>> {
>> unsigned i;
>>
>>
>
> Ping on this patch. Markus has Ack'ed it. Could you please push it to Tom?
>
Applied to u-boot-imx, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
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 1/3] arm: mx6: tqma6: Fix USB and add other filesystems
On 12/03/2015 13:34, Stefan Roese wrote: > This patch fixes the USB EHCI support on the TQMa6 SoM. Additionally > some filesystems are added, included the generic FS commands (e.g. > ls...). > > Signed-off-by: Stefan Roese > Cc: Markus Niebel > Cc: Stefano Babic > --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk 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 1/5] x86: Support QEMU x86 targets
This commit introduces the initial U-Boot support for QEMU x86 targets. U-Boot can boot from coreboot as a payload, or directly without coreboot. Signed-off-by: Bin Meng --- arch/x86/Kconfig | 5 +++ arch/x86/cpu/Makefile | 1 + arch/x86/cpu/qemu/Kconfig | 21 + arch/x86/cpu/qemu/Makefile| 8 + arch/x86/cpu/qemu/car.S | 26 arch/x86/cpu/qemu/dram.c | 46 arch/x86/cpu/qemu/pci.c | 49 ++ arch/x86/cpu/qemu/qemu.c | 37 +++ arch/x86/dts/Makefile | 3 +- arch/x86/dts/qemu-x86.dts | 34 + arch/x86/include/asm/arch-qemu/gpio.h | 13 arch/x86/include/asm/arch-qemu/qemu.h | 17 +++ board/emulation/Kconfig | 25 +++ board/emulation/qemu-x86/Kconfig | 24 +++ board/emulation/qemu-x86/MAINTAINERS | 6 board/emulation/qemu-x86/Makefile | 7 + board/emulation/qemu-x86/qemu-x86.c | 13 board/emulation/qemu-x86/start.S | 9 ++ configs/qemu-x86_defconfig| 6 include/configs/qemu-x86.h| 57 +++ 20 files changed, 406 insertions(+), 1 deletion(-) create mode 100644 arch/x86/cpu/qemu/Kconfig create mode 100644 arch/x86/cpu/qemu/Makefile create mode 100644 arch/x86/cpu/qemu/car.S create mode 100644 arch/x86/cpu/qemu/dram.c create mode 100644 arch/x86/cpu/qemu/pci.c create mode 100644 arch/x86/cpu/qemu/qemu.c create mode 100644 arch/x86/dts/qemu-x86.dts create mode 100644 arch/x86/include/asm/arch-qemu/gpio.h create mode 100644 arch/x86/include/asm/arch-qemu/qemu.h create mode 100644 board/emulation/Kconfig create mode 100644 board/emulation/qemu-x86/Kconfig create mode 100644 board/emulation/qemu-x86/MAINTAINERS create mode 100644 board/emulation/qemu-x86/Makefile create mode 100644 board/emulation/qemu-x86/qemu-x86.c create mode 100644 board/emulation/qemu-x86/start.S create mode 100644 configs/qemu-x86_defconfig create mode 100644 include/configs/qemu-x86.h diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 8e734fd..3d02620 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -17,6 +17,9 @@ choice config VENDOR_COREBOOT bool "coreboot" +config VENDOR_EMULATION + bool "emulation" + config VENDOR_GOOGLE bool "Google" @@ -27,6 +30,7 @@ endchoice # board-specific options below source "board/coreboot/Kconfig" +source "board/emulation/Kconfig" source "board/google/Kconfig" source "board/intel/Kconfig" @@ -34,6 +38,7 @@ source "board/intel/Kconfig" source "arch/x86/cpu/baytrail/Kconfig" source "arch/x86/cpu/coreboot/Kconfig" source "arch/x86/cpu/ivybridge/Kconfig" +source "arch/x86/cpu/qemu/Kconfig" source "arch/x86/cpu/quark/Kconfig" source "arch/x86/cpu/queensbay/Kconfig" diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile index 043bea2..307545a 100644 --- a/arch/x86/cpu/Makefile +++ b/arch/x86/cpu/Makefile @@ -14,6 +14,7 @@ obj-y += interrupts.o cpu.o call64.o obj-$(CONFIG_INTEL_BAYTRAIL) += baytrail/ obj-$(CONFIG_SYS_COREBOOT) += coreboot/ +obj-$(CONFIG_QEMU) += qemu/ obj-$(CONFIG_NORTHBRIDGE_INTEL_SANDYBRIDGE) += ivybridge/ obj-$(CONFIG_NORTHBRIDGE_INTEL_IVYBRIDGE) += ivybridge/ obj-$(CONFIG_INTEL_QUARK) += quark/ diff --git a/arch/x86/cpu/qemu/Kconfig b/arch/x86/cpu/qemu/Kconfig new file mode 100644 index 000..fb775d7 --- /dev/null +++ b/arch/x86/cpu/qemu/Kconfig @@ -0,0 +1,21 @@ +# +# Copyright (C) 2015, Bin Meng +# +# SPDX-License-Identifier: GPL-2.0+ +# + +config QEMU + bool + select TSC_CALIBRATION_BYPASS + +if QEMU + +config SYS_CAR_ADDR + hex + default 0xd + +config SYS_CAR_SIZE + hex + default 0x1 + +endif diff --git a/arch/x86/cpu/qemu/Makefile b/arch/x86/cpu/qemu/Makefile new file mode 100644 index 000..be79723 --- /dev/null +++ b/arch/x86/cpu/qemu/Makefile @@ -0,0 +1,8 @@ +# +# Copyright (C) 2015, Bin Meng +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y += car.o dram.o qemu.o +obj-$(CONFIG_PCI) += pci.o diff --git a/arch/x86/cpu/qemu/car.S b/arch/x86/cpu/qemu/car.S new file mode 100644 index 000..13b3aea --- /dev/null +++ b/arch/x86/cpu/qemu/car.S @@ -0,0 +1,26 @@ +/* + * Copyright (C) 2015, Bin Meng + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include + +.globl car_init +car_init: + /* Save the BIST result */ + movl%eax, %ebp + + post_code(POST_CAR_START) + + /* +* Since we know we are running inside emulator, +* we can do nothing here for CAR initialization. +*/ + + /* Restore the BIST result */ + movl%ebp, %eax + + post_code(POST_CAR_CPU_CACHE) + jmp car_init_ret diff --git a/arch/x86/cpu/qemu/dram.c b/arch/x86/cpu/qemu/dram.c n
[U-Boot] [PATCH 2/5] x86: Make QEMU the default vendor
Now that we have QEMU support, make it the default vendor in the 'make menuconfig' screen. Signed-off-by: Bin Meng --- arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 3d02620..0b78f10 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -12,7 +12,7 @@ config SYS_VSNPRINTF choice prompt "Mainboard vendor" - default VENDOR_COREBOOT + default VENDOR_EMULATION config VENDOR_COREBOOT bool "coreboot" -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] x86: qemu: Wrap E1000 driver only when DM_PCI is not used
E1000 driver has not been converted to driver model, so wrap it only when DM_PCI is not used. Signed-off-by: Bin Meng --- include/configs/qemu-x86.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/qemu-x86.h b/include/configs/qemu-x86.h index 463620d..281aaa5 100644 --- a/include/configs/qemu-x86.h +++ b/include/configs/qemu-x86.h @@ -32,7 +32,9 @@ #define CONFIG_PCI_IO_SIZE 0xe000 #define CONFIG_PCI_PNP +#ifndef CONFIG_DM_PCI #define CONFIG_E1000 +#endif #define CONFIG_STD_DEVICES_SETTINGS"stdin=serial\0" \ "stdout=serial\0" \ -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] x86: Update README.x86 for QEMU support
Document how to build and test U-Boot with QEMU. Signed-off-by: Bin Meng --- doc/README.x86 | 65 +++--- 1 file changed, 48 insertions(+), 17 deletions(-) diff --git a/doc/README.x86 b/doc/README.x86 index ef13fb4..4a30f68 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -14,12 +14,13 @@ including supported boards, build instructions, todo list, etc. Status -- U-Boot supports running as a coreboot [1] payload on x86. So far only Link -(Chromebook Pixel) has been tested, but it should work with minimal adjustments -on other x86 boards since coreboot deals with most of the low-level details. +(Chromebook Pixel) and QEMU [2] x86 targets have been tested, but it should +work with minimal adjustments on other x86 boards since coreboot deals with +most of the low-level details. U-Boot also supports booting directly from x86 reset vector without coreboot, -aka raw support or bare support. Currently Link, Intel Crown Bay, Intel -Minnowboard Max and Intel Galileo support running U-Boot 'bare metal'. +aka raw support or bare support. Currently Link, QEMU x86 targets and all +Intel boards support running U-Boot 'bare metal'. As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit Linux kernel as part of a FIT image. It also supports a compressed zImage. @@ -32,15 +33,15 @@ on other architectures, like below: $ make coreboot-x86_defconfig $ make all -Note this default configuration will build a U-Boot payload for the Link board. +Note this default configuration will build a U-Boot payload for the QEMU board. To build a coreboot payload against another board, you can change the build configuration during the 'make menuconfig' process. x86 architecture ---> ... - (chromebook_link) Board configuration file - (chromebook_link) Board Device Tree Source (dts) file - (0x1920) Board specific Cache-As-RAM (CAR) address + (qemu-x86) Board configuration file + (qemu-x86) Board Device Tree Source (dts) file + (0x0192) Board specific Cache-As-RAM (CAR) address (0x4000) Board specific Cache-As-RAM (CAR) size Change the 'Board configuration file' and 'Board Device Tree Source (dts) file' @@ -78,7 +79,7 @@ Find the following files: * ./northbridge/intel/sandybridge/systemagent-r6.bin The 3rd one should be renamed to mrc.bin. -As for the video ROM, you can get it here [2]. +As for the video ROM, you can get it here [3]. Make sure all these binary blobs are put in the board directory. Now you can build U-Boot and obtain u-boot.rom: @@ -88,8 +89,8 @@ $ make all Intel Crown Bay specific instructions: -U-Boot support of Intel Crown Bay board [3] relies on a binary blob called -Firmware Support Package [4] to perform all the necessary initialization steps +U-Boot support of Intel Crown Bay board [4] relies on a binary blob called +Firmware Support Package [5] to perform all the necessary initialization steps as documented in the BIOS Writer Guide, including initialization of the CPU, memory controller, chipset and certain bus interfaces. @@ -178,6 +179,13 @@ Now you can build U-Boot and obtain u-boot.rom $ make galileo_defconfig $ make all +QEMU x86 target instructions: + +To build u-boot.rom for QEMU x86 targets, just simply run + +$ make qemu-x86_defconfig +$ make all + Test with coreboot -- For testing U-Boot as the coreboot payload, there are things that need be paid @@ -207,10 +215,33 @@ At present it seems that for Minnowboard Max, coreboot does not pass through the video information correctly (it always says the resolution is 0x0). This works correctly for link though. +Test with QEMU +-- +QEMU is a fancy emulator that can enable us to test U-Boot without access to +a real x86 board. To launch QEMU with u-boot.rom, call QEMU as follows: + +$ qemu-system-i386 -nographic -bios path/to/u-boot.rom + +This will instantiate an emulated x86 board with i440FX and PIIX chipset. QEMU +also supports emulating an x86 board with Q35 and ICH9 based chipset, which is +also supported by U-Boot. To instantiate such a machine, call QEMU with: + +$ qemu-system-i386 -nographic -bios path/to/u-boot.rom -M q35 + +Note by default QEMU instantiated boards only have 128 MiB system memory. But +it is enough to have U-Boot boot and function correctly. You can increase the +system memory by pass '-m' parameter to QEMU if you want more memory: + +$ qemu-system-i386 -nographic -bios path/to/u-boot.rom -m 1024 + +This creates a board with 1 GiB system memory. Currently U-Boot for QEMU only +supports 3 GiB maximum system memory and reserves the last 1 GiB address space +for PCI device memory-mapped I/O and other stuff, so the maximum value of '-m' +would be 3072. CPU Microcode - -Modern CPUs usually require a special bit stream called microcode [5] to be +Modern CPUs usually require a special bit stream called microcode [6] to be
[U-Boot] [PATCH 4/5] x86: Change coreboot default build configuration to QEMU
QEMU is much easier for us test booting U-Boot as a coreboot payload than having a real board like chromebook_link. Signed-off-by: Bin Meng --- board/coreboot/coreboot/Kconfig | 6 +++--- configs/coreboot-x86_defconfig | 1 + 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/board/coreboot/coreboot/Kconfig b/board/coreboot/coreboot/Kconfig index 6a04158..69e3437 100644 --- a/board/coreboot/coreboot/Kconfig +++ b/board/coreboot/coreboot/Kconfig @@ -16,21 +16,21 @@ comment "coreboot-specific options" config SYS_CONFIG_NAME string "Board configuration file" - default "chromebook_link" + default "qemu-x86" help This option selects the board configuration file in include/configs/ directory to be used to build U-Boot for coreboot. config DEFAULT_DEVICE_TREE string "Board Device Tree Source (dts) file" - default "chromebook_link" + default "qemu-x86" help This option selects the board Device Tree Source (dts) file in arch/x86/dts/ directory to be used to build U-Boot for coreboot. config SYS_CAR_ADDR hex "Board specific Cache-As-RAM (CAR) address" - default 0x1920 + default 0x0192 help This option specifies the board specific Cache-As-RAM (CAR) address. diff --git a/configs/coreboot-x86_defconfig b/configs/coreboot-x86_defconfig index 799853f..4af38f5 100644 --- a/configs/coreboot-x86_defconfig +++ b/configs/coreboot-x86_defconfig @@ -3,3 +3,4 @@ CONFIG_VENDOR_COREBOOT=y CONFIG_TARGET_COREBOOT=y CONFIG_OF_CONTROL=y CONFIG_DM_PCI=y +CONFIG_TSC_CALIBRATION_BYPASS=y -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] bringing up u-boot on qemu-x86
Hi Saket, On Tue, May 5, 2015 at 2:05 AM, Saket Sinha wrote: > Hi Bin, > > I am one of the students working on adding ACPI support to u-boot for > Minnowboard as a part of GSOC-2015. > Good to know you will be working on U-Boot ACPI support! > In this endeavor, I have been trying to bring up u-boot on qemu-x86. > > I request you to guide me as to how this can be done. > I've spent a couple of hours today to enable the QEMU support for U-Boot and here you go: http://patchwork.ozlabs.org/patch/468145/ http://patchwork.ozlabs.org/patch/468149/ Note this is preliminary but should be able to enable you to run U-Boot on QEMU, either bare or as a coreboot payload. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/9] dm: usb: Copy over usb_device values from usb_scan_device() to final usb_device
On 5 May 2015 at 03:54, Hans de Goede wrote: > Currently we copy over a number of usb_device values stored in the on stack > struct usb_device probed in usb_scan_device() to the final driver-model > managed > struct usb_device in usb_child_pre_probe() through usb_device_platdata, and > then call usb_select_config() to fill in the rest. > > There are 3 problems with this approach: > > 1) It does not fill in enough fields before calling usb_select_config(), > specifically it does not fill in ep0's maxpacketsize causing a div by zero > exception in the ehci driver. > > 2) It unnecessarily redoes a number of usb requests making usb probing slower > > 3) Calling usb_select_config() a second time fails on some usb-1 devices > plugged into usb-2 hubs, causing u-boot to not recognize these devices. > > This commit fixes these issues by removing (*) the usb_select_config() call > from usb_child_pre_probe(), and instead of copying over things field by field > through usb_device_platdata, store a pointer to the in stack usb_device > (which is still valid when usb_child_pre_probe() gets called) and copy > over the entire struct. > > *) Except for devices which are explictly instantiated through device-tree > rather then discovered through usb_scan_device() such as emulated usb devices > in the sandbox. > > Signed-off-by: Hans de Goede > --- > Changes in v3: > -Add a big fat comment to warn that plat->udev is for usb-uclass.c internal > use only > Changes in v4: > -Fix sandbox emul usb device breakage > --- > drivers/usb/host/usb-uclass.c | 43 > --- > include/usb.h | 17 ++--- > 2 files changed, 38 insertions(+), 22 deletions(-) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] x86: qemu: Wrap E1000 driver only when DM_PCI is not used
Hi Simon, On Tue, May 5, 2015 at 11:24 PM, Bin Meng wrote: > E1000 driver has not been converted to driver model, so wrap it > only when DM_PCI is not used. > > Signed-off-by: Bin Meng > --- > > include/configs/qemu-x86.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/configs/qemu-x86.h b/include/configs/qemu-x86.h > index 463620d..281aaa5 100644 > --- a/include/configs/qemu-x86.h > +++ b/include/configs/qemu-x86.h > @@ -32,7 +32,9 @@ > #define CONFIG_PCI_IO_SIZE 0xe000 > > #define CONFIG_PCI_PNP > +#ifndef CONFIG_DM_PCI > #define CONFIG_E1000 This is because E1000 driver is using pci_hose_phys_to_bus() API which DM_PCI does not provide. Do you plan to fix this? > +#endif > > #define CONFIG_STD_DEVICES_SETTINGS"stdin=serial\0" \ > "stdout=serial\0" \ > -- Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] x86: qemu: Wrap E1000 driver only when DM_PCI is not used
Hi Bin, On 5 May 2015 at 09:35, Bin Meng wrote: > Hi Simon, > > On Tue, May 5, 2015 at 11:24 PM, Bin Meng wrote: >> E1000 driver has not been converted to driver model, so wrap it >> only when DM_PCI is not used. >> >> Signed-off-by: Bin Meng >> --- >> >> include/configs/qemu-x86.h | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/include/configs/qemu-x86.h b/include/configs/qemu-x86.h >> index 463620d..281aaa5 100644 >> --- a/include/configs/qemu-x86.h >> +++ b/include/configs/qemu-x86.h >> @@ -32,7 +32,9 @@ >> #define CONFIG_PCI_IO_SIZE 0xe000 >> >> #define CONFIG_PCI_PNP >> +#ifndef CONFIG_DM_PCI >> #define CONFIG_E1000 > > This is because E1000 driver is using pci_hose_phys_to_bus() API which > DM_PCI does not provide. Do you plan to fix this? That function can be moved to pci_compat.c to get things building. However I believe it does not work and I don't have hardware to test it. Do you have time to take a look? > >> +#endif >> >> #define CONFIG_STD_DEVICES_SETTINGS"stdin=serial\0" \ >> "stdout=serial\0" \ >> -- Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 21/24] tegra124: Implement spl_was_boot_source()
On 05/04/2015 11:31 AM, Simon Glass wrote:
Add an implementation of this function for Tegra.
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
+#ifndef CONFIG_SPL_BUILD
+void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
+{
+ from_spl = r0 != SPL_RUNNING_FROM_UBOOT;
+ save_boot_params_ret();
+}
+#endif
(Using terminology from:
https://patchwork.ozlabs.org/patch/467771/
arm: spl: Enable detecting when U-Boot is started from SPL
)
That doesn't look right. Surely (at least on Tegra), if the r/o U-Boot
chain-loads to the r/w U-Boot, then the chain-loaded U-Boot has no SPL
and is just the main CPU build of U-Boot.
Hence, "SPL_RUNNING_FROM_UBOOT" seems incorrectly named, since the r/o
U-Boot doesn't chain to SPL but rather to U-Boot.
This approach sounds a little brittle; what happens if r0 just happens
to have that value. Won't the code get confused?
Why does U-Boot care whether it's been chain-loaded? Shouldn't it always
behave identically in all cases, so it's independent of what caused it
to run?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 24/24] tegra124: Expand SPL space by 8KB
On 05/04/2015 11:31 AM, Simon Glass wrote: We are getting very close to running out of space in SPL, and with the currently Chrome OS gcc 4.9 we exceed the limit. Add a litle more space. 8K is quite a bump given we only had 24K allocated before. Why is gcc-4.9 less efficient that earlier compilers I wonder? Were we extremely close to the limit ebfore? Still, I guess this is fine. Did you validate whether tegra-uboot-flasher still works with this change? I think it will since it only cares about the SPL TEXT_BASE and not the main U-Boot TEXT_BASE, but double-checking would be nice. You forgot to CC Tom Warren on this Tegra patch. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 24/24] tegra124: Expand SPL space by 8KB
Hi Stephen, On 5 May 2015 at 09:59, Stephen Warren wrote: > On 05/04/2015 11:31 AM, Simon Glass wrote: >> >> We are getting very close to running out of space in SPL, and with the >> currently Chrome OS gcc 4.9 we exceed the limit. Add a litle more space. > > > 8K is quite a bump given we only had 24K allocated before. Why is gcc-4.9 > less efficient that earlier compilers I wonder? Were we extremely close to > the limit ebfore? Still, I guess this is fine. > > Did you validate whether tegra-uboot-flasher still works with this change? I > think it will since it only cares about the SPL TEXT_BASE and not the main > U-Boot TEXT_BASE, but double-checking would be nice. I tested this with USB A-A (tegrarcm). Is that what you mean? > > You forgot to CC Tom Warren on this Tegra patch. Ooops, I should have used a 'tegra' tag. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 21/24] tegra124: Implement spl_was_boot_source()
Hi Stephen,
On 5 May 2015 at 09:54, Stephen Warren wrote:
> On 05/04/2015 11:31 AM, Simon Glass wrote:
>>
>> Add an implementation of this function for Tegra.
>
>
>> diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
>
>
>> +#ifndef CONFIG_SPL_BUILD
>> +void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
>> +{
>> + from_spl = r0 != SPL_RUNNING_FROM_UBOOT;
>> + save_boot_params_ret();
>> +}
>> +#endif
>
>
> (Using terminology from:
> https://patchwork.ozlabs.org/patch/467771/
> arm: spl: Enable detecting when U-Boot is started from SPL
> )
>
> That doesn't look right. Surely (at least on Tegra), if the r/o U-Boot
> chain-loads to the r/w U-Boot, then the chain-loaded U-Boot has no SPL and
> is just the main CPU build of U-Boot.
>
> Hence, "SPL_RUNNING_FROM_UBOOT" seems incorrectly named, since the r/o
> U-Boot doesn't chain to SPL but rather to U-Boot.
What name do you suggest? I was trying to add a prefix indicating that
it relates to non-SPL start-up of U-Boot.
>
> This approach sounds a little brittle; what happens if r0 just happens to
> have that value. Won't the code get confused?
Yes, but SPL does not set that value in r0, and we have control over this.
>
> Why does U-Boot care whether it's been chain-loaded? Shouldn't it always
> behave identically in all cases, so it's independent of what caused it to
> run?
In the case of read-only U-Boot it must find the read-write one to
jump to. In the case of read-write U-Boot it must boot a kernel.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 24/24] tegra124: Expand SPL space by 8KB
+Tom Warren On 4 May 2015 at 11:31, Simon Glass wrote: > We are getting very close to running out of space in SPL, and with the > currently Chrome OS gcc 4.9 we exceed the limit. Add a litle more space. > > Signed-off-by: Simon Glass > --- > > include/configs/tegra124-common.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/configs/tegra124-common.h > b/include/configs/tegra124-common.h > index f2b3774..0347132 100644 > --- a/include/configs/tegra124-common.h > +++ b/include/configs/tegra124-common.h > @@ -30,7 +30,7 @@ > /*--- > * Physical Memory Map > */ > -#define CONFIG_SYS_TEXT_BASE 0x8010E000 > +#define CONFIG_SYS_TEXT_BASE 0x8011 > > /* > * Memory layout for where various images get loaded by boot scripts: > -- > 2.2.0.rc0.207.ga3a616c > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 21/24] tegra124: Implement spl_was_boot_source()
On 05/05/2015 10:02 AM, Simon Glass wrote:
Hi Stephen,
On 5 May 2015 at 09:54, Stephen Warren wrote:
On 05/04/2015 11:31 AM, Simon Glass wrote:
Add an implementation of this function for Tegra.
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
+#ifndef CONFIG_SPL_BUILD
+void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
+{
+ from_spl = r0 != SPL_RUNNING_FROM_UBOOT;
+ save_boot_params_ret();
+}
+#endif
(Using terminology from:
https://patchwork.ozlabs.org/patch/467771/
arm: spl: Enable detecting when U-Boot is started from SPL
)
That doesn't look right. Surely (at least on Tegra), if the r/o U-Boot
chain-loads to the r/w U-Boot, then the chain-loaded U-Boot has no SPL and
is just the main CPU build of U-Boot.
Hence, "SPL_RUNNING_FROM_UBOOT" seems incorrectly named, since the r/o
U-Boot doesn't chain to SPL but rather to U-Boot.
What name do you suggest? I was trying to add a prefix indicating that
it relates to non-SPL start-up of U-Boot.
Well, that name specifically states that it's SPL that's running,
whereas the exact opposite is true.
Perhaps UBOOT_CHAIN_LOADED_FROM_UBOOT?
This approach sounds a little brittle; what happens if r0 just happens to
have that value. Won't the code get confused?
Yes, but SPL does not set that value in r0, and we have control over this.
Why does U-Boot care whether it's been chain-loaded? Shouldn't it always
behave identically in all cases, so it's independent of what caused it to
run?
In the case of read-only U-Boot it must find the read-write one to
jump to. In the case of read-write U-Boot it must boot a kernel.
Surely that should be taken care of by placing the correct boot scripts
into the U-Boot environment, rather than hard-coding specific boot
behaviour into the U-Boot binary?
This feature seems really use-case-specific; I wonder if it's
useful/generic-enough to upstream even?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 24/24] tegra124: Expand SPL space by 8KB
On 05/05/2015 10:03 AM, Simon Glass wrote: Hi Stephen, On 5 May 2015 at 09:59, Stephen Warren wrote: On 05/04/2015 11:31 AM, Simon Glass wrote: We are getting very close to running out of space in SPL, and with the currently Chrome OS gcc 4.9 we exceed the limit. Add a litle more space. 8K is quite a bump given we only had 24K allocated before. Why is gcc-4.9 less efficient that earlier compilers I wonder? Were we extremely close to the limit ebfore? Still, I guess this is fine. Did you validate whether tegra-uboot-flasher still works with this change? I think it will since it only cares about the SPL TEXT_BASE and not the main U-Boot TEXT_BASE, but double-checking would be nice. I tested this with USB A-A (tegrarcm). Is that what you mean? Did you just use tegrarcm, or tegra-uboot-flasher? The latter is a wrapper on top of tegrarcm, and is a bit more involved. See the various READMEs at https://github.com/NVIDIA/tegra-uboot-flasher-scripts. This doesn't support any nyan-derived boards yet, but does support Jetson TK1 which I think you have? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 24/24] tegra124: Expand SPL space by 8KB
LGTM, but it s/b 'Add a _little_ more space' in the commit msg. Should we change the TEXT_BASE for the CPU portion in all Tegra builds? > -Original Message- > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass > Sent: Tuesday, May 05, 2015 9:04 AM > To: U-Boot Mailing List > Cc: Simon Glass; Heiko Schocher; Tom Rini; Tom Warren > Subject: Re: [PATCH 24/24] tegra124: Expand SPL space by 8KB > > +Tom Warren > > On 4 May 2015 at 11:31, Simon Glass wrote: > > We are getting very close to running out of space in SPL, and with the > > currently Chrome OS gcc 4.9 we exceed the limit. Add a litle more space. > > > > Signed-off-by: Simon Glass > > --- > > > > include/configs/tegra124-common.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/include/configs/tegra124-common.h > > b/include/configs/tegra124-common.h > > index f2b3774..0347132 100644 > > --- a/include/configs/tegra124-common.h > > +++ b/include/configs/tegra124-common.h > > @@ -30,7 +30,7 @@ > > /*--- > > * Physical Memory Map > > */ > > -#define CONFIG_SYS_TEXT_BASE 0x8010E000 > > +#define CONFIG_SYS_TEXT_BASE 0x8011 > > > > /* > > * Memory layout for where various images get loaded by boot scripts: > > -- > > 2.2.0.rc0.207.ga3a616c > > --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 21/24] tegra124: Implement spl_was_boot_source()
Hi Stephen,
On 5 May 2015 at 10:10, Stephen Warren wrote:
> On 05/05/2015 10:02 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 5 May 2015 at 09:54, Stephen Warren wrote:
>>>
>>> On 05/04/2015 11:31 AM, Simon Glass wrote:
Add an implementation of this function for Tegra.
>>>
>>>
>>>
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
>>>
>>>
>>>
+#ifndef CONFIG_SPL_BUILD
+void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
+{
+ from_spl = r0 != SPL_RUNNING_FROM_UBOOT;
+ save_boot_params_ret();
+}
+#endif
>>>
>>>
>>>
>>> (Using terminology from:
>>> https://patchwork.ozlabs.org/patch/467771/
>>> arm: spl: Enable detecting when U-Boot is started from SPL
>>> )
>>>
>>> That doesn't look right. Surely (at least on Tegra), if the r/o U-Boot
>>> chain-loads to the r/w U-Boot, then the chain-loaded U-Boot has no SPL
>>> and
>>> is just the main CPU build of U-Boot.
>>>
>>> Hence, "SPL_RUNNING_FROM_UBOOT" seems incorrectly named, since the r/o
>>> U-Boot doesn't chain to SPL but rather to U-Boot.
>>
>>
>> What name do you suggest? I was trying to add a prefix indicating that
>> it relates to non-SPL start-up of U-Boot.
>
>
> Well, that name specifically states that it's SPL that's running, whereas
> the exact opposite is true.
>
> Perhaps UBOOT_CHAIN_LOADED_FROM_UBOOT?
I really want to say that it is not chain-loaded from SPL. Maybe
UBOOT_NOT_LOADED_FROM_SPL?
>
>>> This approach sounds a little brittle; what happens if r0 just happens to
>>> have that value. Won't the code get confused?
>>
>>
>> Yes, but SPL does not set that value in r0, and we have control over this.
>>
>>> Why does U-Boot care whether it's been chain-loaded? Shouldn't it always
>>> behave identically in all cases, so it's independent of what caused it to
>>> run?
>>
>>
>> In the case of read-only U-Boot it must find the read-write one to
>> jump to. In the case of read-write U-Boot it must boot a kernel.
>
>
> Surely that should be taken care of by placing the correct boot scripts into
> the U-Boot environment, rather than hard-coding specific boot behaviour into
> the U-Boot binary?
Two problems here:
1. The two U-Boot will use the same environment (as they are identical
after all)
2. Loading the environment is a security risk (since anyone can change
it in Linux, for example) so cannot be loaded.
> This feature seems really use-case-specific; I wonder if it's
> useful/generic-enough to upstream even?
I am keen to upstream this use case (upgrading U-Boot in a secure way)
as I think it has wide application.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx: Use GOT when loading IVORs post-relocation
On 04/23/2015 08:48 PM, Xie Shaohui-B21989 wrote:
>> -Original Message-
>> From: Wood Scott-B07421
>> Sent: Friday, April 24, 2015 9:02 AM
>> To: u-boot@lists.denx.de; Sun York-R58495
>> Cc: Wood Scott-B07421; Alexander Graf; Xie Shaohui-B21989
>> Subject: [PATCH] powerpc/mpc85xx: Use GOT when loading IVORs post-
>> relocation
>>
>> Commit 96d2bb952bb ("powerpc/mpc85xx: Don't relocate exception vectors")
>> simplified IVOR initialization a bit too much, failing to use the post-
>> relocation offset. This doesn't cause a problem with normal NOR boot, in
>> which both the pre-relocation and post-relocation addresses are 64 KiB
>> aligned. However, if TEXT_BASE is only 4 KiB aligned, such as for
>> NAND/SD/etc. boot on some targets, as well as the QEMU target, the post-
>> relocation address will not be the same in the lower 16 bits, as
>> reserve_uboot() ensures that the relocation address is always 64 KiB
>> aligned even if the pre-relocation address was not.
>>
>> Use the GOT to get the proper post-relocation offsets.
>>
>> Fixes: 96d2bb952bb ("powerpc/mpc85xx: Don't relocate exception vectors")
>> Signed-off-by: Scott Wood
>> Cc: Alexander Graf
>> Cc: Shaohui Xie
>> ---
>> arch/powerpc/cpu/mpc85xx/start.S | 35 --
>> -
>> 1 file changed, 20 insertions(+), 15 deletions(-)
>>
>
> Tested-by: Shaohui Xie
>
Applied to u-boot-mpc85xx master branch. Awaiting upstream.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 24/24] tegra124: Expand SPL space by 8KB
Hi Stephen, On 5 May 2015 at 10:12, Stephen Warren wrote: > On 05/05/2015 10:03 AM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 5 May 2015 at 09:59, Stephen Warren wrote: >>> >>> On 05/04/2015 11:31 AM, Simon Glass wrote: We are getting very close to running out of space in SPL, and with the currently Chrome OS gcc 4.9 we exceed the limit. Add a litle more space. >>> >>> >>> >>> 8K is quite a bump given we only had 24K allocated before. Why is gcc-4.9 >>> less efficient that earlier compilers I wonder? Were we extremely close >>> to >>> the limit ebfore? Still, I guess this is fine. We were about 1KB away, mostly due to the gcc garbage collection bug I think. The cros compiler seems even worse, not sure why. >>> >>> Did you validate whether tegra-uboot-flasher still works with this >>> change? I >>> think it will since it only cares about the SPL TEXT_BASE and not the >>> main >>> U-Boot TEXT_BASE, but double-checking would be nice. >> >> >> I tested this with USB A-A (tegrarcm). Is that what you mean? > > > Did you just use tegrarcm, or tegra-uboot-flasher? The latter is a wrapper > on top of tegrarcm, and is a bit more involved. See the various READMEs at > https://github.com/NVIDIA/tegra-uboot-flasher-scripts. This doesn't support > any nyan-derived boards yet, but does support Jetson TK1 which I think you > have? Ah, OK. The script at: https://github.com/NVIDIA/tegra-uboot-flasher-scripts/blob/master/tegra-uboot-flasher looks OK to me. It does not have anything hard-coded that I can see. But I have not used it myself. It's kind-of painful that we have all this out-of-tree Tegra stuff (pin mux also) that might break when we change U-Boot. Is there any way to improve this? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx/T4240EMU: Remove T4240EMU board
On 04/21/2015 10:09 AM, York Sun wrote: > T4240 SoC has been available for a long time. Emulator support > is no longer needed. > > Signed-off-by: York Sun > --- Applied to u-boot-mpc85xx master. Awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: usb: fsl: Workaround for Erratum A004477
On 04/23/2015 08:54 PM, Badola Nikhil-B46172 wrote: > > IP team has agreed to change previous workaround to the 1us delay workaround > > Applied to u-boot-mpc85xx master. Awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] T2080QDS/PCIe: Soft Reset PCIe on T2080QDS for down-training issue
On 03/26/2015 01:13 AM, Zhao Qiang wrote: > T2080QDS PEX1/Slot#1 will down-train from x4 to x2, > with SRDS_PRTCL_S1 = 0x66 and SRDS_PRTCL_S2 = 0x15. > Soft reset PCIe can fix this issue. > > Signed-off-by: Zhao Qiang > --- > changes for v2 > - modify the commit message > changes for v3 > - use CONFIG_FSL_PCIE_RESET instead of CONFIG_FSL_PCIE_T2080QDS_RESET > Applied to u-boot-mpc85xx master. Awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/t4rdb: Add SD boot support for T4240RDB board
On 03/20/2015 02:08 AM, Chunhe Lan wrote: > This patch adds SD boot support for T4240RDB board. SPL > framework is used. PBL initializes the internal RAM and > copies SPL to it. Then SPL initializes DDR using SPD and > copies u-boot from SD card to DDR, finally SPL transfers > control to u-boot. > > Signed-off-by: Chunhe Lan > --- > arch/powerpc/cpu/mpc85xx/Kconfig |1 + > board/freescale/t4rdb/MAINTAINERS |1 + > board/freescale/t4rdb/Makefile|6 ++- > board/freescale/t4rdb/ddr.c |6 ++- > board/freescale/t4rdb/spl.c | 95 > + > board/freescale/t4rdb/t4_pbi.cfg |3 - > board/freescale/t4rdb/t4_rcw.cfg |6 +- > board/freescale/t4rdb/tlb.c |8 +++ > configs/T4240RDB_SDCARD_defconfig |5 ++ > include/configs/T4240RDB.h| 71 --- Fixed defconfig file. Applied to u-boot-mpc85xx master. Awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl/pci: Set CFG_READY for PCIe v3.0 and later
On 03/26/2015 10:24 PM, Minghuan Lian wrote: > Freescale PCIe controllers v3.0 and later need to set bit > CFG_READY to allow all inbound configuration transactions > to be processed normally when in EP mode. However, bit > CFG_READY has been moved from PCIe configuration space to > CCSR PCIe configuration register comparing previous version. > The patch is to set this bit according to PCIe version. > > Signed-off-by: Ed Swarthout > Signed-off-by: Roy Zang > Signed-off-by: Minghuan Lian > --- Applied to u-boot-mpc85xx master. Awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] powerpc/t1023rdb: Add T1023 RDB board support
On 03/27/2015 12:48 AM, Shengzhou Liu wrote: > T1023RDB is a Freescale Reference Design Board that hosts the T1023 SoC. > > T1023RDB board Overview > --- > - T1023 SoC integrating two 64-bit e5500 cores up to 1.4GHz > - CoreNet fabric supporting coherent and noncoherent transactions with > prioritization and bandwidth allocation > - Memory: 2GB Micron MT40A512M8HX unbuffered 32-bit fixed DDR4 without ECC > - Accelerator: DPAA components consist of FMan, BMan, QMan, DCE and SEC > - Ethernet interfaces: > - one 1G RGMII port on-board(RTL8211F PHY) > - one 1G SGMII port on-board(RTL8211F PHY) > - one 2.5G SGMII port on-board(AQR105 PHY) > - PCIe: Two Mini-PCIe connectors on-board. > - SerDes: 4 lanes up to 10.3125GHz > - NOR: 128MB S29GL01GS110TFIV10 Spansion NOR Flash > - NAND: 512MB S34MS04G200BFI000 Spansion NAND Flash > - eSPI: 64MB S25FL512SAGMFI010 Spansion SPI flash. > - USB: one Type-A USB 2.0 port with internal PHY > - eSDHC: support SD/MMC card and eMMC on-board > - 256Kbit M24256 I2C EEPROM > - RTC: Real-time clock DS1339 on I2C bus > - UART: one serial port on-board with RJ45 connector > - Debugging: JTAG/COP for T1023 debugging > > As well updated T1024RDB to add T1023RDB. > > Signed-off-by: Shengzhou Liu > --- > v4: squashed ddr patch to this one. > v3: updated readme. > v2: updated the printout of serdes refclk. > Applied to u-boot-mpc85xx master. Awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, RFC] powerpc: add 2 common dcache assembly functions
On 03/27/2015 08:07 AM, Valentin Longchamp wrote: > This patch defines the 2 flush_dcache_range and invalidate_dcache_range > functions for all the powerpc architecture. Their implementation is > borrowed from the kernel's misc_32.S file and replace the ones from > mpc86xx and ppc4xx since they were equivalent. > > This is a fix for the problem introduced by this patch: > http://patchwork.ozlabs.org/patch/448849/ > > Signed-off-by: Valentin Longchamp > Reviewed-by: Tom Rini > --- Applied to u-boot-mpc85xx master. Awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/t102x: use fdt_setprop_string instead of fdt_setprop
On 04/14/2015 02:56 AM, Shengzhou Liu wrote: > Use fdt_setprop_string instead of fdt_setprop to fix string length. > > Signed-off-by: Shengzhou Liu > --- > board/freescale/t102xqds/eth_t102xqds.c | 9 + > board/freescale/t102xrdb/eth_t102xrdb.c | 4 ++-- > 2 files changed, 7 insertions(+), 6 deletions(-) > Applied to u-boot-mpc85xx master. Awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx: Don't deref NULL if qman portal lacks cell-index
On 04/17/2015 04:10 PM, Scott Wood wrote: > Signed-off-by: Scott Wood > Cc: Madalin-Cristian Bucur > --- Applied to u-boot-mpc85xx master. Awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
