[U-Boot] Standalone application issue.
Hi, I am trying to load and execute the hello world standalone app on the arndale exynos 5250. I created an image using the mkimage tool and then used the bootm to load and execute the image. However, the applications does not print anything on the terminal and all what I can see is the following: Image Type: ARM U-Boot Standalone Program (uncompressed) Data Size:594 Bytes = 594 Bytes Load Address: 7020 Entry Point: 7020 Verifying Checksum ... OK XIP Standalone Program ... OK XIP Standalone Program ... OK OK ARNDALE5250 # Could you please help me with that issue. Mnay thanks. -- View this message in context: http://u-boot.10912.n7.nabble.com/Standalone-application-issue-tp180515.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: postponed needless timer initialization
Hi Mateusz,
On Apr 29, 2014, at 9:15 PM, Mateusz Zalega wrote:
> mmc_init() doesn't call get_timer() anymore if MMC is already
> initialized.
>
> Signed-off-by: Mateusz Zalega
> Cc: Pantelis Antoniou
> ---
> Detached from earlier "DFU, MMC, Gadget, Goni, misc." series because of lack
> of relevance to other patches.
>
> v2:
> - deleted change-id line from commit message, sorry!
> ---
> drivers/mmc/mmc.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 16051e5..c93dc24 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1310,15 +1310,18 @@ static int mmc_complete_init(struct mmc *mmc)
> int mmc_init(struct mmc *mmc)
> {
> int err = IN_PROGRESS;
> - unsigned start = get_timer(0);
> + unsigned start;
>
> if (mmc->has_init)
> return 0;
> +
> + start = get_timer(0);
> +
> if (!mmc->init_in_progress)
> err = mmc_start_init(mmc);
> -
> if (!err || err == IN_PROGRESS)
> err = mmc_complete_init(mmc);
> +
^ some extra formatting here that's not needed; I'll fix it and apply.
I am curious what the problem was the problem with getting the timer?
> debug("%s: %d, time %lu\n", __func__, err, get_timer(start));
> return err;
> }
> --
> 1.9.0
>
Applied
Thanks
-- Pantelis
Acked-by: Pantelis Antoniou
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add board_mmc_init(...) function for init mmc1 only
Hi Hannes,
On Apr 8, 2014, at 9:39 AM, Hannes Petermaier wrote:
> Since B&R boards uses only MMC-Controller #1, it only
> wastes time if we initialize #0 first to see that there is nothing.
>
> Cc:
> Signed-off-by: Hannes Petermaier
> ---
> board/BuR/common/common.c |7 +++
> include/configs/kwb.h |2 +-
> include/configs/tseries.h |2 +-
> 3 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/board/BuR/common/common.c b/board/BuR/common/common.c
> index 4c926ce..25cbe62 100644
> --- a/board/BuR/common/common.c
> +++ b/board/BuR/common/common.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -214,3 +215,9 @@ int board_eth_init(bd_t *bis)
> return rv;
> }
> #endif /* CONFIG_DRIVER_TI_CPSW */
> +#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
> +int board_mmc_init(bd_t *bis)
> +{
> + return omap_mmc_init(1, 0, 0, -1, -1);
> +}
> +#endif
> diff --git a/include/configs/kwb.h b/include/configs/kwb.h
> index 0f631c0..0860434 100644
> --- a/include/configs/kwb.h
> +++ b/include/configs/kwb.h
> @@ -109,7 +109,7 @@
>
> #undef CONFIG_ENV_IS_NOWHERE
> #define CONFIG_ENV_IS_IN_MMC
> -#define CONFIG_SYS_MMC_ENV_DEV 1
> +#define CONFIG_SYS_MMC_ENV_DEV 0
> #define CONFIG_SYS_MMC_ENV_PART 2
> #define CONFIG_ENV_OFFSET 0x4 /* TODO: Adresse definieren */
> #define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
> diff --git a/include/configs/tseries.h b/include/configs/tseries.h
> index 8fb87ac..e550afa 100644
> --- a/include/configs/tseries.h
> +++ b/include/configs/tseries.h
> @@ -237,7 +237,7 @@
> #elif defined(CONFIG_EMMC_BOOT)
> #undef CONFIG_ENV_IS_NOWHERE
> #define CONFIG_ENV_IS_IN_MMC
> -#define CONFIG_SYS_MMC_ENV_DEV 1
> +#define CONFIG_SYS_MMC_ENV_DEV 0
> #define CONFIG_SYS_MMC_ENV_PART 2
> #define CONFIG_ENV_OFFSET 0x4 /* TODO: Adresse definieren */
> #define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
> --
> 1.7.9.5
>
Applied
Thanks
-- Pantelis
Acked-by: Pantelis Antoniou
> ___
> 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/1] Read mmc device memory capacity from EXT_CSD if memory is addressed by sector
Hi Frank, On Apr 11, 2014, at 6:35 PM, Frank Bormann wrote: > Hi Pantos, hi Tom, > > I sent this a couple of months ago to the mailing list, never really received > a response. We are testing 2014.04-rc3 right now and the issue is still > there. Would you still consider bringing this fix in for the upcoming release? > > This is for an eMMC chip with an initial memory size > 2GB whose memory size > drops below 2GB when turning enhanced (pseudo-SLC) mode on for the user > partition. u-boot would then fail memory size detection and assume memory > size if zero. You'd see error messages like: > > MMC: block number 0x1 exceeds max(0x0) > MMC: block number 0x800 exceeds max(0x0) > MMC: block number 0x900 exceeds max(0x0) > > Thanks, > Frank > Your patch is corrupted; can you please resend and make sure it applies using git am? > panto@sles11esa:~/u-boot-mmc.git (master)$ git am -3 > U-Boot-RFC-1-1-Read-mmc-device-memory-capacity-from-EXT_CSD-if-memory-is-addressed-by-sector.patch > > Applying: Read mmc device memory capacity from EXT_CSD if memory is addressed > by sector > fatal: corrupt patch at line 50 > Repository lacks necessary blobs to fall back on 3-way merge. > Cannot fall back to three-way merge. > Patch failed at 0001 Read mmc device memory capacity from EXT_CSD if memory > is addressed by sector > The copy of the patch that failed is found in: >/home/panto/ti/u-boots/u-boot-mmc.git/.git/rebase-apply/patch > When you have resolved this problem, run "git am --resolved". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > Regards -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: Handle switch error status bit in MMC card status
Hi Andrew, On Apr 3, 2014, at 12:34 PM, Andrew Gabbasov wrote: > MMC switch command for unsupported feature (e.g. bus width) sets a switch > error bit in card status. This bit should be checked, and, if it's set, > no access with new controller settings should be performed. > > Signed-off-by: Andrew Gabbasov > --- > drivers/mmc/mmc.c |4 +++- > include/mmc.h |2 ++ > 2 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c > index 16051e5..a850085 100644 > --- a/drivers/mmc/mmc.c > +++ b/drivers/mmc/mmc.c > @@ -150,6 +150,8 @@ int mmc_send_status(struct mmc *mmc, int timeout) > #endif > return TIMEOUT; > } > + if (cmd.response[0] & MMC_STATUS_SWITCH_ERROR) > + return SWITCH_ERR; > > return 0; > } > @@ -501,7 +503,7 @@ static int mmc_change_freq(struct mmc *mmc) > err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 1); > > if (err) > - return err; > + return err == SWITCH_ERR ? 0 : err; > > /* Now check to see that it worked */ > err = mmc_send_ext_csd(mmc, ext_csd); > diff --git a/include/mmc.h b/include/mmc.h > index c0a1d9e..213c112 100644 > --- a/include/mmc.h > +++ b/include/mmc.h > @@ -53,6 +53,7 @@ > #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 MMC_CMD_GO_IDLE_STATE 0 > #define MMC_CMD_SEND_OP_COND 1 > @@ -108,6 +109,7 @@ > #define SECURE_ERASE 0x8000 > > #define MMC_STATUS_MASK (~0x0206BF7F) > +#define MMC_STATUS_SWITCH_ERROR (1 << 7) > #define MMC_STATUS_RDY_FOR_DATA (1 << 8) > #define MMC_STATUS_CURR_STATE (0xf << 9) > #define MMC_STATUS_ERROR (1 << 19) > -- > 1.7.10.4 > Applied, Thanks --Pantelis Acked-by: Pantelis Antoniou ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 1/3] eMMC: add support for operations in RPMB partition
Hi Pierre,
On Apr 24, 2014, at 11:30 AM, Pierre Aubert wrote:
> This patch adds functions for read, write and authentication
> key programming for the Replay Protected Memory Block partition
> in the eMMC.
>
> Signed-off-by: Pierre Aubert
> CC: Pantelis Antoniou
> ---
> Changes in V5:
> - move changelog to the right place
> - change lib/Makefile for adding sha256 when CONFIG_SUPPORT_EMMC_RPMB is
> defined
>
> V3, V4: no changes
>
> Changes in V2:
> - use ALLOC_CACHE_ALIGN_BUFFER in rpmb.c instead of a static buffer for the
> RPMB frames.
>
> drivers/mmc/Makefile |1 +
> drivers/mmc/rpmb.c | 323 ++
> include/mmc.h| 10 ++-
> lib/Makefile |1 +
> 4 files changed, 334 insertions(+), 1 deletions(-)
> create mode 100644 drivers/mmc/rpmb.c
>
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 931922b..4c6ab9e 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_DWMMC) += dw_mmc.o
> obj-$(CONFIG_EXYNOS_DWMMC) += exynos_dw_mmc.o
> obj-$(CONFIG_ZYNQ_SDHCI) += zynq_sdhci.o
> obj-$(CONFIG_SOCFPGA_DWMMC) += socfpga_dw_mmc.o
> +obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o
> ifdef CONFIG_SPL_BUILD
> obj-$(CONFIG_SPL_MMC_BOOT) += fsl_esdhc_spl.o
> else
> diff --git a/drivers/mmc/rpmb.c b/drivers/mmc/rpmb.c
> new file mode 100644
> index 000..05936f5
> --- /dev/null
> +++ b/drivers/mmc/rpmb.c
> @@ -0,0 +1,323 @@
> +/*
> + * Copyright 2014, Staubli Faverges
> + * Pierre Aubert
> + *
> + * eMMC- Replay Protected Memory Block
> + * According to JEDEC Standard No. 84-A441
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include "mmc_private.h"
> +
> +/* Request codes */
> +#define RPMB_REQ_KEY 1
> +#define RPMB_REQ_WCOUNTER2
> +#define RPMB_REQ_WRITE_DATA 3
> +#define RPMB_REQ_READ_DATA 4
> +#define RPMB_REQ_STATUS 5
> +
> +/* Response code */
> +#define RPMB_RESP_KEY0x0100
> +#define RPMB_RESP_WCOUNTER 0x0200
> +#define RPMB_RESP_WRITE_DATA 0x0300
> +#define RPMB_RESP_READ_DATA 0x0400
> +
> +/* Error codes */
> +#define RPMB_OK 0
> +#define RPMB_ERR_GENERAL 1
> +#define RPMB_ERR_AUTH2
> +#define RPMB_ERR_COUNTER 3
> +#define RPMB_ERR_ADDRESS 4
> +#define RPMB_ERR_WRITE 5
> +#define RPMB_ERR_READ6
> +#define RPMB_ERR_KEY 7
> +#define RPMB_ERR_CNT_EXPIRED 0x80
> +#define RPMB_ERR_MSK 0x7
> +
> +/* Sizes of RPMB data frame */
> +#define RPMB_SZ_STUFF196
> +#define RPMB_SZ_MAC 32
> +#define RPMB_SZ_DATA 256
> +#define RPMB_SZ_NONCE16
> +
> +#define SHA256_BLOCK_SIZE64
> +
> +/* Error messages */
> +static const char * const rpmb_err_msg[] = {
> + "",
> + "General failure",
> + "Authentication failure",
> + "Counter failure",
> + "Address failure",
> + "Write failure",
> + "Read failure",
> + "Authentication key not yet programmed",
> +};
> +
> +
> +/* Structure of RPMB data frame. */
> +struct s_rpmb {
> + unsigned char stuff[RPMB_SZ_STUFF];
> + unsigned char mac[RPMB_SZ_MAC];
> + unsigned char data[RPMB_SZ_DATA];
> + unsigned char nonce[RPMB_SZ_NONCE];
> + unsigned long write_counter;
> + unsigned short address;
> + unsigned short block_count;
> + unsigned short result;
> + unsigned short request;
> +};
> +
> +static int mmc_set_blockcount(struct mmc *mmc, unsigned int blockcount,
> + bool is_rel_write)
> +{
> + struct mmc_cmd cmd = {0};
> +
> + cmd.cmdidx = MMC_CMD_SET_BLOCK_COUNT;
> + cmd.cmdarg = blockcount & 0x;
> + if (is_rel_write)
> + cmd.cmdarg |= 1 << 31;
> + cmd.resp_type = MMC_RSP_R1;
> +
> + return mmc_send_cmd(mmc, &cmd, NULL);
> +}
> +static int mmc_rpmb_request(struct mmc *mmc, const struct s_rpmb *s,
> + unsigned int count, bool is_rel_write)
> +{
> + struct mmc_cmd cmd = {0};
> + struct mmc_data data;
> + int ret;
> +
> + ret = mmc_set_blockcount(mmc, count, is_rel_write);
> + if (ret) {
> +#ifdef CONFIG_MMC_RPMB_TRACE
> + printf("%s:mmc_set_blockcount-> %d\n", __func__, ret);
> +#endif
> + return 1;
> + }
> +
> + cmd.cmdidx = MMC_CMD_WRITE_MULTIPLE_BLOCK;
> + cmd.cmdarg = 0;
> + cmd.resp_type = MMC_RSP_R1b;
> +
> + data.src = (const char *)s;
> + data.blocks = 1;
> + data.blocksize = MMC_MAX_BLOCK_LEN;
> + data.flags = MMC_DATA_WRITE;
> +
> + ret = mmc_send_cmd(mmc, &cmd, &data);
> + if (ret) {
> +#ifdef CONFIG_MMC_RPMB_TRACE
> + printf("%s:mmc_send_cmd-> %d\n", __func__, ret);
> +#endif
> + return 1;
> + }
> + return 0;
> +}
> +static int mmc_rpmb_response(struct mmc *mmc, struct s_rpmb *s,
> + unsigned short expected)
>
Re: [U-Boot] [PATCH V5 2/3] Add the function 'confirm_yesno' for interactive
Hi Pierre,
On Apr 24, 2014, at 11:30 AM, Pierre Aubert wrote:
> User's confirmation is asked in different commands. This commit adds a
> function for such confirmation.
>
> Signed-off-by: Pierre Aubert
> ---
>
> V3, V4, V5: no changes
>
> Patch added in V2
>
> common/cmd_fuse.c | 11 ++-
> common/cmd_nand.c | 16 +---
> common/cmd_otp.c | 18 +++---
> common/console.c | 28 +++-
> include/common.h |2 +-
> 5 files changed, 38 insertions(+), 37 deletions(-)
>
> diff --git a/common/cmd_fuse.c b/common/cmd_fuse.c
> index 0df57db..abab978 100644
> --- a/common/cmd_fuse.c
> +++ b/common/cmd_fuse.c
> @@ -33,15 +33,8 @@ static int confirm_prog(void)
> "what you are doing!\n"
> "\nReally perform this fuse programming? \n");
>
> - if (getc() == 'y') {
> - int c;
> -
> - putc('y');
> - c = getc();
> - putc('\n');
> - if (c == '\r')
> - return 1;
> - }
> + if (confirm_yesno())
> + return 1;
>
> puts("Fuse programming aborted\n");
> return 0;
> diff --git a/common/cmd_nand.c b/common/cmd_nand.c
> index 04ab0f1..a84f7dc 100644
> --- a/common/cmd_nand.c
> +++ b/common/cmd_nand.c
> @@ -605,22 +605,16 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> opts.spread = spread;
>
> if (scrub) {
> - if (!scrub_yes)
> - puts(scrub_warn);
> -
> - if (scrub_yes)
> + if (scrub_yes) {
> opts.scrub = 1;
> - else if (getc() == 'y') {
> - puts("y");
> - if (getc() == '\r')
> + } else {
> + puts(scrub_warn);
> + if (confirm_yesno()) {
> opts.scrub = 1;
> - else {
> + } else {
> puts("scrub aborted\n");
> return 1;
> }
> - } else {
> - puts("scrub aborted\n");
> - return 1;
> }
> }
> ret = nand_erase_opts(nand, &opts);
> diff --git a/common/cmd_otp.c b/common/cmd_otp.c
> index 67808aa..593bb8c 100644
> --- a/common/cmd_otp.c
> +++ b/common/cmd_otp.c
> @@ -158,21 +158,9 @@ int do_otp(cmd_tbl_t *cmdtp, int flag, int argc, char *
> const argv[])
> lowup(half + count - 1), page + (half + count - 1) / 2,
> half + count
> );
> -
> - i = 0;
> - while (1) {
> - if (tstc()) {
> - const char exp_ans[] = "YES\r";
> - char c;
> - putc(c = getc());
> - if (exp_ans[i++] != c) {
> - printf(" Aborting\n");
> - return 1;
> - } else if (!exp_ans[i]) {
> - puts("\n");
> - break;
> - }
> - }
> + if (!confirm_yesno()) {
> + printf(" Aborting\n");
> + return 1;
> }
> }
>
> diff --git a/common/console.c b/common/console.c
> index 2dfb788..5453726 100644
> --- a/common/console.c
> +++ b/common/console.c
> @@ -537,7 +537,33 @@ int ctrlc(void)
> }
> return 0;
> }
> -
> +/* Reads user's confirmation.
> + Returns 1 if user's input is "y", "Y", "yes" or "YES"
> +*/
> +int confirm_yesno(void)
> +{
> + int i;
> + char str_input[5];
> +
> + /* Flush input */
> + while (tstc())
> + getc();
> + i = 0;
> + while (i < sizeof(str_input)) {
> + str_input[i] = getc();
> + putc(str_input[i]);
> + if (str_input[i] == '\r')
> + break;
> + i++;
> + }
> + putc('\n');
> + if (strncmp(str_input, "y\r", 2) == 0 ||
> + strncmp(str_input, "Y\r", 2) == 0 ||
> + strncmp(str_input, "yes\r", 4) == 0 ||
> + strncmp(str_input, "YES\r", 4) == 0)
> + return 1;
I guess you could convert to upper/lower case and reduce the comparisons but I'd
let it pass.
Maybe follow up later with a patch just for that.
> + return 0;
> +}
> /* pass 1 to disable ctrlc() checking, 0 to enable.
> * returns previous state
> */
> diff --git a/include/common.h b/include/common.h
> index baf361b..1d922b9 100644
> --- a/include/common.h
> +++ b/include/com
Re: [U-Boot] [PATCH 1/4] cmd_part: fix type in part command help text
Hi Stephen, On May 7, 2014, at 9:19 PM, Stephen Warren wrote: > From: Stephen Warren > > All the sub-commands start with the main command anme, but it was anme=name > missing from one of the help texts. > > Signed-off-by: Stephen Warren > --- > common/cmd_part.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/common/cmd_part.c b/common/cmd_part.c > index 14248548d9fe..c84bc27b4042 100644 > --- a/common/cmd_part.c > +++ b/common/cmd_part.c > @@ -82,7 +82,7 @@ int do_part(cmd_tbl_t *cmdtp, int flag, int argc, char * > const argv[]) > U_BOOT_CMD( > part, 5, 1, do_part, > "disk partition related commands", > - "uuid :\n" > + "part uuid :\n" > "- print partition UUID\n" > "part uuid : \n" > "- set environment variable to partition UUID\n" > -- > 1.8.1.5 > Fixed typos and applied. Thanks -- Pantelis Acked-by: Pantelis Antoniou ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] disk: support devices with HW partitions
Hi Stephen,
On May 7, 2014, at 9:19 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> Some device types (e.g. eMMC) have hardware-level partitions (for eMMC,
> separate boot and user data partitions). This change allows the user to
> specify the HW partition they wish to access when passing a device ID to
> U-Boot Commands such as part, ls, load, ums, etc.
>
> The syntax allows an optional ".$hwpartid" to be appended to the device
> name string for those commands.
>
> Existing syntax, for MMC device 0, default HW partition ID, SW partition
> ID 1:
>
> ls mmc 0:1 /
>
> New syntax, for MMC device 0, HW partition ID 1 (boot0), SW partition
> ID 2:
>
> ls mmc 0.1:2 /
>
> For my purposes, this is most useful for the ums (USB mass storage
> gadget) command, but there's no reason not to allow the new syntax
> globally.
>
> This patch adds the core support infra-structure. The next patch will
> provide the implementation for MMC.
>
> Signed-off-by: Stephen Warren
> ---
> disk/part.c | 74 -
> 1 file changed, 64 insertions(+), 10 deletions(-)
>
> diff --git a/disk/part.c b/disk/part.c
> index b8c6aac80162..5e10cae015e5 100644
> --- a/disk/part.c
> +++ b/disk/part.c
> @@ -22,6 +22,7 @@
> struct block_drvr {
> char *name;
> block_dev_desc_t* (*get_dev)(int dev);
> + int (*select_hwpart)(int dev_num, int hwpart);
> };
>
> static const struct block_drvr block_drvr[] = {
> @@ -52,11 +53,13 @@ static const struct block_drvr block_drvr[] = {
> DECLARE_GLOBAL_DATA_PTR;
>
> #ifdef HAVE_BLOCK_DEVICE
> -block_dev_desc_t *get_dev(const char *ifname, int dev)
> +block_dev_desc_t *get_dev_hwpart(const char *ifname, int dev, int hwpart)
> {
> const struct block_drvr *drvr = block_drvr;
> block_dev_desc_t* (*reloc_get_dev)(int dev);
> + int (*select_hwpart)(int dev_num, int hwpart);
> char *name;
> + int ret;
>
> if (!ifname)
> return NULL;
> @@ -68,17 +71,41 @@ block_dev_desc_t *get_dev(const char *ifname, int dev)
> while (drvr->name) {
> name = drvr->name;
> reloc_get_dev = drvr->get_dev;
> + select_hwpart = drvr->select_hwpart;
> #ifdef CONFIG_NEEDS_MANUAL_RELOC
> name += gd->reloc_off;
> reloc_get_dev += gd->reloc_off;
> -#endif
> - if (strncmp(ifname, name, strlen(name)) == 0)
> - return reloc_get_dev(dev);
> + if (select_hwpart)
> + select_hwpart += gd->reloc_off;
> +#endif
> + if (strncmp(ifname, name, strlen(name)) == 0) {
> + block_dev_desc_t *dev_desc = reloc_get_dev(dev);
> + if (!dev_desc)
> + return NULL;
> + if (hwpart == -1)
> + return dev_desc;
> + if (!select_hwpart)
> + return NULL;
> + ret = select_hwpart(dev_desc->dev, hwpart);
> + if (ret < 0)
> + return NULL;
> + return dev_desc;
> + }
> drvr++;
> }
> return NULL;
> }
> +
> +block_dev_desc_t *get_dev(const char *ifname, int dev)
> +{
> + return get_dev_hwpart(ifname, dev, -1);
> +}
> #else
> +block_dev_desc_t *get_dev_hwpart(const char *ifname, int dev, int hwpart)
> +{
> + return NULL;
> +}
> +
> block_dev_desc_t *get_dev(const char *ifname, int dev)
> {
> return NULL;
> @@ -413,25 +440,52 @@ int get_partition_info(block_dev_desc_t *dev_desc, int
> part
> return -1;
> }
>
> -int get_device(const char *ifname, const char *dev_str,
> +int get_device(const char *ifname, const char *dev_hwpart_str,
> block_dev_desc_t **dev_desc)
> {
> char *ep;
> - int dev;
> + char *dup_str = NULL;
> + const char *dev_str, *hwpart_str;
> + int dev, hwpart;
> +
> + hwpart_str = strchr(dev_hwpart_str, '.');
> + if (hwpart_str) {
> + dup_str = strdup(dev_hwpart_str);
> + dup_str[hwpart_str - dev_hwpart_str] = 0;
> + dev_str = dup_str;
> + hwpart_str++;
> + } else {
> + dev_str = dev_hwpart_str;
> + hwpart = -1;
> + }
>
> dev = simple_strtoul(dev_str, &ep, 16);
> if (*ep) {
> printf("** Bad device specification %s %s **\n",
> ifname, dev_str);
> - return -1;
> + dev = -1;
> + goto cleanup;
> + }
> +
> + if (hwpart_str) {
> + hwpart = simple_strtoul(hwpart_str, &ep, 16);
> + if (*ep) {
> + printf("** Bad HW partition specification %s %s **\n",
> + ifname, hwpart_str);
> + dev = -1;
> + goto cleanup;
> + }
> }
>
> - *dev_desc = get_dev(ifname, dev);
>
Re: [U-Boot] [PATCH 3/4] mmc: provide a select_hwpart implementation for get_device()
Hi Stephen,
On May 7, 2014, at 9:19 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> This enables specifying which eMMC HW partition to target for any U-Boot
> command that uses the generic get_partition() function to parse its
> command-line arguments.
>
> Signed-off-by: Stephen Warren
> ---
> disk/part.c | 6 +-
> drivers/mmc/mmc.c | 26 ++
> include/part.h| 2 ++
> 3 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/disk/part.c b/disk/part.c
> index 5e10cae015e5..2827089d8d5f 100644
> --- a/disk/part.c
> +++ b/disk/part.c
> @@ -39,7 +39,11 @@ static const struct block_drvr block_drvr[] = {
> { .name = "usb", .get_dev = usb_stor_get_dev, },
> #endif
> #if defined(CONFIG_MMC)
> - { .name = "mmc", .get_dev = mmc_get_dev, },
> + {
> + .name = "mmc",
> + .get_dev = mmc_get_dev,
> + .select_hwpart = mmc_select_hwpart,
> + },
> #endif
> #if defined(CONFIG_SYSTEMACE)
> { .name = "ace", .get_dev = systemace_get_dev, },
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 16051e52ff16..3089d8d807a8 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -550,6 +550,32 @@ static int mmc_set_capacity(struct mmc *mmc, int
> part_num)
> return 0;
> }
>
> +int mmc_select_hwpart(int dev_num, int hwpart)
> +{
> + struct mmc *mmc = find_mmc_device(dev_num);
> + int ret;
> +
> + if (!mmc)
> + return -1;
> +
> + if (mmc->part_num == hwpart)
> + return 0;
> +
> + if (mmc->part_config == MMCPART_NOAVAILABLE) {
> + printf("Card doesn't support part_switch\n");
> + return -1;
> + }
> +
> + ret = mmc_switch_part(dev_num, hwpart);
> + if (ret)
> + return -1;
> +
> + mmc->part_num = hwpart;
> +
> + return 0;
> +}
> +
> +
> int mmc_switch_part(int dev_num, unsigned int part_num)
> {
> struct mmc *mmc = find_mmc_device(dev_num);
> diff --git a/include/part.h b/include/part.h
> index 53532dcd6120..f2c8c641faa8 100644
> --- a/include/part.h
> +++ b/include/part.h
> @@ -103,6 +103,7 @@ block_dev_desc_t* sata_get_dev(int dev);
> block_dev_desc_t* scsi_get_dev(int dev);
> block_dev_desc_t* usb_stor_get_dev(int dev);
> block_dev_desc_t* mmc_get_dev(int dev);
> +int mmc_select_hwpart(int dev_num, int hwpart);
> block_dev_desc_t* systemace_get_dev(int dev);
> block_dev_desc_t* mg_disk_get_dev(int dev);
> block_dev_desc_t *host_get_dev(int dev);
> @@ -126,6 +127,7 @@ static inline block_dev_desc_t* sata_get_dev(int dev) {
> return NULL; }
> static inline block_dev_desc_t* scsi_get_dev(int dev) { return NULL; }
> static inline block_dev_desc_t* usb_stor_get_dev(int dev) { return NULL; }
> static inline block_dev_desc_t* mmc_get_dev(int dev) { return NULL; }
> +static inline int mmc_select_hwpart(int dev_num, int hwpart) { return -1; }
> static inline block_dev_desc_t* systemace_get_dev(int dev) { return NULL; }
> static inline block_dev_desc_t* mg_disk_get_dev(int dev) { return NULL; }
> static inline block_dev_desc_t *host_get_dev(int dev) { return NULL; }
> --
> 1.8.1.5
>
Applied, but expect a follow up patch for returning something else than -1.
Thanks
-- Pantelis
Acked-by: Pantelis Antoniou
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] cmd_mmc: use new mmc_select_hwpart() function
Hi Stephen,
On May 7, 2014, at 9:19 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> The implementation of mmc_select_hwpart() was cribbed from do_mmcops().
> Update do_mmcops() to call mmc_select_hwpart() to avoid duplication.
>
> Signed-off-by: Stephen Warren
> ---
> common/cmd_mmc.c | 19 +--
> 1 file changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
> index c1916c9b56a6..572aa895fa1c 100644
> --- a/common/cmd_mmc.c
> +++ b/common/cmd_mmc.c
> @@ -193,7 +193,7 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> print_mmc_devices('\n');
> return 0;
> } else if (strcmp(argv[1], "dev") == 0) {
> - int dev, part = -1;
> + int dev, part = -1, ret;
> struct mmc *mmc;
>
> if (argc == 2)
> @@ -219,20 +219,11 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
>
> mmc_init(mmc);
> if (part != -1) {
> - int ret;
> - if (mmc->part_config == MMCPART_NOAVAILABLE) {
> - printf("Card doesn't support part_switch\n");
> + ret = mmc_select_hwpart(dev, part);
> + printf("switch to partitions #%d, %s\n",
> +part, (!ret) ? "OK" : "ERROR");
> + if (ret)
> return 1;
> - }
> -
> - if (part != mmc->part_num) {
> - ret = mmc_switch_part(dev, part);
> - if (!ret)
> - mmc->part_num = part;
> -
> - printf("switch to partitions #%d, %s\n",
> - part, (!ret) ? "OK" : "ERROR");
> - }
> }
> curr_device = dev;
> if (mmc->part_config == MMCPART_NOAVAILABLE)
> --
> 1.8.1.5
>
Due to patch order mangling, I've applied but with some manual placement.
Please verify that
it works properly on your end after the patches land at u-boot-mmc.
Thanks
-- Pantelis
Acked-by: Pantelis Antoniou
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-mmc 23052014
Hi Tom, The following changes since commit d7782d06534fe4fa47a49fa7c106de5ba85a9687: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-05-16 18:30: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 df348d8245922adbb03a3a979429c5e70342973c: cmd_mmc: use new mmc_select_hwpart() function (2014-05-23 12:23:28 +0300) Andrew Gabbasov (1): mmc: Handle switch error status bit in MMC card status Hannes Petermaier (1): Add board_mmc_init(...) function for init mmc1 only Mateusz Zalega (1): mmc: postponed needless timer initialization Pierre Aubert (3): eMMC: add support for operations in RPMB partition Add the function 'confirm_yesno' for interactive eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command Stephen Warren (4): cmd_part: fix typo in part command help text disk: support devices with HW partitions mmc: provide a select_hwpart implementation for get_device() cmd_mmc: use new mmc_select_hwpart() function Ye.Li (1): esdhc/usdhc: Fix PIO mode bug in fsl_esdhc driver README| 10 ++ board/BuR/common/common.c | 7 + common/cmd_fuse.c | 11 +- common/cmd_mmc.c | 799 +--- common/cmd_nand.c | 16 +-- common/cmd_otp.c | 18 +-- common/cmd_part.c | 2 +- common/console.c | 28 +++- disk/part.c | 80 +-- drivers/mmc/Makefile | 1 + drivers/mmc/fsl_esdhc.c | 23 ++- drivers/mmc/mmc.c | 35 - drivers/mmc/rpmb.c| 323 ++ include/common.h | 2 +- include/configs/kwb.h | 2 +- include/configs/tseries.h | 2 +- include/mmc.h | 12 +- include/part.h| 2 + lib/Makefile | 1 + 19 files changed, 1009 insertions(+), 365 deletions(-) create mode 100644 drivers/mmc/rpmb.c Regards -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Uboot-standalone-kernel.
Is it possible to load a bare-metal standalone application by using uboot, and let the standalone app load a kernel and FS, could you please propose a hint on how to it? Many thanks. -- View this message in context: http://u-boot.10912.n7.nabble.com/Uboot-standalone-kernel-tp180527.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: Add support for semihosting for armv8 fastmodel targets.
Hi Darwin, > -Original Message- > From: Darwin Rambo [mailto:dra...@broadcom.com] > Sent: Tuesday, March 25, 2014 12:46 AM > To: u-boot@lists.denx.de > Cc: Darwin Rambo; Albert Aribaud; Tom Rini; feng...@phytium.com.cn; > Sharma Bhupesh-B45370 > Subject: [PATCH v3] arm: Add support for semihosting for armv8 fastmodel > targets. > > The reason for this change is to be able to use the ARM Trusted Firmware > (ATF) to load the various ATF images, plus u-boot, which can then load > the kernel/ramdisk/dtb with calls to an external host from a standard > fastmodel armv8 board file using semihosting, and then launch the kernel > without a bootwrapper. This gives us a more realistic boot sequence. > > There are two main ARM virtual Fixed Virtual Platform (FVP) models, > Versatile Express (VE) FVP and BASE FVP (See > http://www.arm.com/products/tools/models/fast-models/foundation- > model.php) > The initial vexpress64 u-boot board created here runs on the VE virtual > platform using the license-free Foundation_v8 simulator. Fortunately, the > Foundation_v8 simulator also supports the BASE_FVP model which companies > can purchase licenses for and contain much more functionality. > So we can, in u-boot, run either model by either using the VE FVP > (default), or turning on CONFIG_BASE_FVP for the more full featured > model. > > Rather than create a new armv8 board similar to armltd/vexpress64, add > semihosting calls to the existing one, enabled with CONFIG_SEMIHOSTING > and CONFIG_BASE_FVP both set. Also reuse the existing board config file > vexpress_aemv8a.h but differentiate the two models by the presence or > absence of CONFIG_BASE_FVP. This change is tested and works on both the > Foundation and Base fastmodel simulators. > > Support for armv7 in fastmodel is less useful due to the wide range of > available silicon and the lack of a free armv7 fastmodel, so this change > contains an untested armv7 placeholder for the service trap opcode. > > The level of semihosting support is minimal, restricted to just what it > takes to load images to memory. If more semihosting functionality is > required, such as file seek, outputting strings, reading characters, etc, > then it can be easily added later. Sorry for the late reply. We are using ARMv8 foundation model (the free version) to launch u-boot via the ARM Trusted Firmware (ATF). We are using a older u-boot version and cannot see the ATF launching the u-boot.bin. Please find the details of the ARMv8 foundation model command line and ATF, u-boot commit logs below (Host machine is a ubuntu-64 bit). ARMv8 foundation model Command Line used - $ ./Foundation_v8 --cores=1 --no-secure-memory --visualization --gicv3 --data="bl1.bin"@0x --data="fip.bin"@0x8000 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Booting trusted firmware boot loader stage 1 Built : 12:58:21, May 22 2014 ERROR: Firmware Image Package header check failed. Booting trusted firmware boot loader stage 2 BL2 Built : 12:58:22, May 22 2014 ERROR: Firmware Image Package header check failed. ERROR: Firmware Image Package header check failed. Booting trusted firmware boot loader stage 3 BL31 Built : 12:58:23, May 22 2014 ATF latest commit - commit ca823d2c881d9d8c7db364de7e362d2e75ad55df Author: Achin Gupta Date: Sun Feb 2 13:04:00 2014 + Increase coherent stack sizes This patch increases coherent stack size for both debug and release builds in order to accommodate stack-heavy printf() and extended EL3 functionality Change-Id: I30ef30530a01517a97e63d703873374828c09f20 u-boot commit - commit 22a240c32c1340183fce12867ae5f8736b92a638 Author: Alexey Brodkin Date: Fri Dec 13 10:35:11 2013 +0400 serial/serial_arc - add driver for ARC UART Driver for non-standard on-chip UART, instantiated in the ARC (Synopsys) FPGA Boards such as ARCAngel4/ML50x Signed-off-by: Alexey Brodkin Signed-off-by: Darwin Rambo > --- > > Changes in v3: > - minor format fixup in board file > > Changes in v2: > - use kernel_addr_r, fdt_addr_r, initrd_addr_r convention. > - Use env variables for kernel/fdt/initrd file names. > - Add CONFIG_BASE_FVP to differentiate VE and BASE FVP models. > - CONFIG_SEMIHOSTING only refers to bringing in semihosting code now. > - Remove unnecessary CONFIG_SYS_BAUDRATE_TABLE, > CONFIG_SYS_PROMPT_HUSH_PS2 > - Remove vexpress_aemv8a_semi.h and replace with CONFIG_BASE_FVP > - Update boards.cfg with option SEMIHOSTING and BASE_FVP > - Add doc/README.semihosting > > Changes in v1: > - Initial code > - Remove empty timer_init() function. > > arch/arm/include/asm/semihosting.h | 21 +++ > arch/arm/lib/Makefile|1 + > arch/arm/lib/semihosting.c | 235 > ++ > board/armltd/vexpress64/vexpress64.c | 101 ++- > boards.cfg
Re: [U-Boot] Standalone application issue.
Dear "mazen.e", In message <1400831110428-180515.p...@n7.nabble.com> you wrote: > > I am trying to load and execute the hello world standalone app on the > arndale exynos 5250. I created an image using the mkimage tool and then used > the bootm to load and execute the image. However, the applications does not > print anything on the terminal and all what I can see is the following: > > > Image Type: ARM U-Boot Standalone Program (uncompressed) >Data Size:594 Bytes = 594 Bytes >Load Address: 7020 >Entry Point: 7020 Where are these load and entry point addresses coming from? As far as I can see, the linker command for the hello_world progrtam looks like this: arm-linux-gnueabi-ld.bfd -g -Ttext 0xc10 -o examples/standalone/hello_world -e hello_world ... And I also see -> nm hello_world | grep hello_world 0c10 T hello_world So I would expect to see 0xC10 instead of 0x7020 ?? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Der Irrtum wiederholt sich immerfort in der Tat. Deshalb muß man das Wahre unermüdlich in Worten wiederholen. - Goethe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] esdhc/usdhc: Fix warning when CONFIG_SYS_FSL_ESDHC_USE_PIO is not set
In 7168977 we made calls to check_and_invalidate_dcache_range()
conditional on !CONFIG_SYS_FSL_ESDHC_USE_PIO. Only define this function
in this case as well.
Signed-off-by: Tom Rini
---
drivers/mmc/fsl_esdhc.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index dca28f4..5541613 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -246,6 +246,7 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
return 0;
}
+#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
static void check_and_invalidate_dcache_range
(struct mmc_cmd *cmd,
struct mmc_data *data) {
@@ -255,6 +256,8 @@ static void check_and_invalidate_dcache_range
unsigned end = start+size ;
invalidate_dcache_range(start, end);
}
+#endif
+
/*
* Sends a command out on the bus. Takes the mmc pointer,
* a command pointer, and an optional data pointer.
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] esdhc/usdhc: Fix warning when CONFIG_SYS_FSL_ESDHC_USE_PIO is not set
On Fri, May 23, 2014 at 09:20:53AM -0400, Tom Rini wrote: > In 7168977 we made calls to check_and_invalidate_dcache_range() > conditional on !CONFIG_SYS_FSL_ESDHC_USE_PIO. Only define this function > in this case as well. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-mmc 23052014
On Fri, May 23, 2014 at 12:37:06PM +0300, Pantelis Antoniou wrote: > Hi Tom, > > The following changes since commit d7782d06534fe4fa47a49fa7c106de5ba85a9687: > > Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-05-16 > 18:30: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 df348d8245922adbb03a3a979429c5e70342973c: > > cmd_mmc: use new mmc_select_hwpart() function (2014-05-23 12:23:28 +0300) > > > Andrew Gabbasov (1): > mmc: Handle switch error status bit in MMC card status > > Hannes Petermaier (1): > Add board_mmc_init(...) function for init mmc1 only > > Mateusz Zalega (1): > mmc: postponed needless timer initialization > > Pierre Aubert (3): > eMMC: add support for operations in RPMB partition > Add the function 'confirm_yesno' for interactive > eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command > > Stephen Warren (4): > cmd_part: fix typo in part command help text > disk: support devices with HW partitions > mmc: provide a select_hwpart implementation for get_device() > cmd_mmc: use new mmc_select_hwpart() function > > Ye.Li (1): > esdhc/usdhc: Fix PIO mode bug in fsl_esdhc driver > > README| 10 ++ > board/BuR/common/common.c | 7 + > common/cmd_fuse.c | 11 +- > common/cmd_mmc.c | 799 > +--- > common/cmd_nand.c | 16 +-- > common/cmd_otp.c | 18 +-- > common/cmd_part.c | 2 +- > common/console.c | 28 +++- > disk/part.c | 80 +-- > drivers/mmc/Makefile | 1 + > drivers/mmc/fsl_esdhc.c | 23 ++- > drivers/mmc/mmc.c | 35 - > drivers/mmc/rpmb.c| 323 ++ > include/common.h | 2 +- > include/configs/kwb.h | 2 +- > include/configs/tseries.h | 2 +- > include/mmc.h | 12 +- > include/part.h| 2 + > lib/Makefile | 1 + > 19 files changed, 1009 insertions(+), 365 deletions(-) > create mode 100644 drivers/mmc/rpmb.c Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] mmc: provide a select_hwpart implementation for get_device()
On 05/23/2014 03:21 AM, Pantelis Antoniou wrote: > Hi Stephen, > > On May 7, 2014, at 9:19 PM, Stephen Warren wrote: >> This enables specifying which eMMC HW partition to target for any U-Boot >> command that uses the generic get_partition() function to parse its >> command-line arguments. > Applied, but expect a follow up patch for returning something else than -1. What else should it return? -1 is consistent with plenty of code in that file... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] mmc: provide a select_hwpart implementation for get_device()
Hi Stephen, On May 23, 2014, at 6:58 PM, Stephen Warren wrote: > On 05/23/2014 03:21 AM, Pantelis Antoniou wrote: >> Hi Stephen, >> >> On May 7, 2014, at 9:19 PM, Stephen Warren wrote: >>> This enables specifying which eMMC HW partition to target for any U-Boot >>> command that uses the generic get_partition() function to parse its >>> command-line arguments. > >> Applied, but expect a follow up patch for returning something else than -1. > > What else should it return? -1 is consistent with plenty of code in that > file... > Some kind of -ERRNO value? Regards -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi: soft_spi: Support NULL din/dout buffers
On Fri, Apr 25, 2014 at 12:09 AM, Andrew Ruder
wrote:
> This mirrors the conventions used in other SPI drivers (kirkwood,
> davinci, atmel, et al) where the din/dout buffer can be NULL when the
> received/transmitted data isn't important. This reduces the need for
> allocating additional buffers when write-only/read-only functionality is
> needed.
>
> In the din == NULL case, the received data is simply not stored. In the
> dout == NULL case, zeroes are transmitted.
>
> Signed-off-by: Andrew Ruder
> Cc: Jean-Christophe PLAGNIOL-VILLARD
> Cc: Jagan Teki
> ---
> Cleaned up errors/warnings from checkpatch.pl. I'm surprised they were
> flagged
> by the script since the actual ERRORs were all on lines I didn't change but
> were
> only included in the context.
>
> scripts/checkpatch.pl 0001-spi-soft_spi-Support-NULL-din-dout-buffers.patch
> total: 0 errors, 0 warnings, 0 checks, 31 lines checked
>
> drivers/spi/soft_spi.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/spi/soft_spi.c b/drivers/spi/soft_spi.c
> index 5d22351..c969be3 100644
> --- a/drivers/spi/soft_spi.c
> +++ b/drivers/spi/soft_spi.c
> @@ -136,10 +136,14 @@ int spi_xfer(struct spi_slave *slave, unsigned int
> bitlen,
> /*
> * Check if it is time to work on a new byte.
> */
> - if((j % 8) == 0) {
> - tmpdout = *txd++;
> + if ((j % 8) == 0) {
> + if (txd)
> + tmpdout = *txd++;
> + else
> + tmpdout = 0;
> if(j != 0) {
> - *rxd++ = tmpdin;
> + if (rxd)
> + *rxd++ = tmpdin;
> }
> tmpdin = 0;
> }
> @@ -164,9 +168,11 @@ int spi_xfer(struct spi_slave *slave, unsigned int
> bitlen,
> * bits over to left-justify them. Then store the last byte
> * read in.
> */
> - if((bitlen % 8) != 0)
> - tmpdin <<= 8 - (bitlen % 8);
> - *rxd++ = tmpdin;
> + if (rxd) {
> + if ((bitlen % 8) != 0)
> + tmpdin <<= 8 - (bitlen % 8);
> + *rxd++ = tmpdin;
> + }
>
> if (flags & SPI_XFER_END)
> spi_cs_deactivate(slave);
> --
> 1.9.0.rc3.12.gbc97e2d
>
Applied to u-boot-spi/master
thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sf: params: Added support for Spansion S25FL512S_512K
> On Tue, May 6, 2014 at 5:10 PM, Michal Simek wrote:
>> Hi Jagan,
>>
>> On 04/25/2014 03:47 PM, Michal Simek wrote:
>>> From: Siva Durga Prasad Paladugu
>>>
>>> Added support for Spansion chip "S25FL512S_512K".
>>>
>>> Signed-off-by: Siva Durga Prasad Paladugu
>>> Signed-off-by: Michal Simek
>>> ---
>>>
>>> drivers/mtd/spi/sf_params.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
>>> index eb372b7..ac886fd 100644
>>> --- a/drivers/mtd/spi/sf_params.c
>>> +++ b/drivers/mtd/spi/sf_params.c
>>> @@ -60,6 +60,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
>>> {"S25FL256S_64K", 0x010219, 0x4d01,64 * 1024, 512, RD_FULL,
>>>WR_QPP},
>>> {"S25FL512S_256K", 0x010220, 0x4d00, 256 * 1024, 256, RD_FULL,
>>>WR_QPP},
>>> {"S25FL512S_64K", 0x010220, 0x4d01,64 * 1024, 1024, RD_FULL,
>>>WR_QPP},
>>> + {"S25FL512S_512K", 0x010220, 0x4f00, 256 * 1024, 256, RD_FULL,
>>>WR_QPP},
>>> #endif
>>> #ifdef CONFIG_SPI_FLASH_STMICRO /* STMICRO */
>>> {"M25P10", 0x202011, 0x0, 32 * 1024, 4, 0,
>>> 0},
>>> --
>>> 1.8.2.3
Applied to u-boot-spi/master
thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] cmd_mmc: use new mmc_select_hwpart() function
On 05/23/2014 03:24 AM, Pantelis Antoniou wrote: > Hi Stephen, > > On May 7, 2014, at 9:19 PM, Stephen Warren wrote: > >> From: Stephen Warren >> >> The implementation of mmc_select_hwpart() was cribbed from do_mmcops(). >> Update do_mmcops() to call mmc_select_hwpart() to avoid duplication. > Due to patch order mangling, I've applied but with some manual placement. > Please verify that > it works properly on your end after the patches land at u-boot-mmc. I think this looks fine, thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [UBOOT][PATCH] mtd: spi: fix quad bit set path
On Wed, Apr 23, 2014 at 6:57 PM, Sourav Poddar wrote:
> Currently, flash quad bit is set in "spi_flash_validate_params" and later
> at the end in the same api, we write 0 to status register for few flashes,
> thereby overriding the quad bit set. This fix moves the quad bit setting
> outside this api in "spi_flash_probe_slave"
>
> Signed-off-by: Sourav Poddar
> ---
> drivers/mtd/spi/sf_probe.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
> index 0a46fe3..8482f08 100644
> --- a/drivers/mtd/spi/sf_probe.c
> +++ b/drivers/mtd/spi/sf_probe.c
> @@ -197,16 +197,6 @@ static struct spi_flash
> *spi_flash_validate_params(struct spi_slave *spi,
> /* Go for default supported write cmd */
> flash->write_cmd = CMD_PAGE_PROGRAM;
>
> - /* Set the quad enable bit - only for quad commands */
> - if ((flash->read_cmd == CMD_READ_QUAD_OUTPUT_FAST) ||
> - (flash->read_cmd == CMD_READ_QUAD_IO_FAST) ||
> - (flash->write_cmd == CMD_QUAD_PAGE_PROGRAM)) {
> - if (spi_flash_set_qeb(flash, idcode[0])) {
> - debug("SF: Fail to set QEB for %02x\n", idcode[0]);
> - return NULL;
> - }
> - }
> -
> /* Read dummy_byte: dummy byte is determined based on the
> * dummy cycles of a particular command.
> * Fast commands - dummy_byte = dummy_cycles/8
> @@ -327,6 +317,16 @@ static struct spi_flash *spi_flash_probe_slave(struct
> spi_slave *spi)
> if (!flash)
> goto err_read_id;
>
> + /* Set the quad enable bit - only for quad commands */
> + if ((flash->read_cmd == CMD_READ_QUAD_OUTPUT_FAST) ||
> + (flash->read_cmd == CMD_READ_QUAD_IO_FAST) ||
> + (flash->write_cmd == CMD_QUAD_PAGE_PROGRAM)) {
> + if (spi_flash_set_qeb(flash, idcode[0])) {
> + debug("SF: Fail to set QEB for %02x\n", idcode[0]);
> + return NULL;
> + }
> + }
> +
> #ifdef CONFIG_OF_CONTROL
> if (spi_flash_decode_fdt(gd->fdt_blob, flash)) {
> debug("SF: FDT decode error\n");
> --
> 1.7.9.5
Applied to u-boot-spi/master
thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: Add support for semihosting for armv8 fastmodel targets.
Hi Bhupesh, I believe that this patch is now stale, because other changes to boards.cfg and vexpress_aemv8a.h were done after this patch was submitted. So it doesn't apply cleanly anymore and needs to be regenerated. In the meantime can you remove this patch from your world since I believe that it doesn't provide any functionality you need at this time? I will send in a v4 patch that applies cleanly to the latest u-boot. Am I suggesting the right process here? Thanks, Darwin On 14-05-23 05:05 AM, bhupesh.sha...@freescale.com wrote: Hi Darwin, -Original Message- From: Darwin Rambo [mailto:dra...@broadcom.com] Sent: Tuesday, March 25, 2014 12:46 AM To: u-boot@lists.denx.de Cc: Darwin Rambo; Albert Aribaud; Tom Rini; feng...@phytium.com.cn; Sharma Bhupesh-B45370 Subject: [PATCH v3] arm: Add support for semihosting for armv8 fastmodel targets. The reason for this change is to be able to use the ARM Trusted Firmware (ATF) to load the various ATF images, plus u-boot, which can then load the kernel/ramdisk/dtb with calls to an external host from a standard fastmodel armv8 board file using semihosting, and then launch the kernel without a bootwrapper. This gives us a more realistic boot sequence. There are two main ARM virtual Fixed Virtual Platform (FVP) models, Versatile Express (VE) FVP and BASE FVP (See http://www.arm.com/products/tools/models/fast-models/foundation- model.php) The initial vexpress64 u-boot board created here runs on the VE virtual platform using the license-free Foundation_v8 simulator. Fortunately, the Foundation_v8 simulator also supports the BASE_FVP model which companies can purchase licenses for and contain much more functionality. So we can, in u-boot, run either model by either using the VE FVP (default), or turning on CONFIG_BASE_FVP for the more full featured model. Rather than create a new armv8 board similar to armltd/vexpress64, add semihosting calls to the existing one, enabled with CONFIG_SEMIHOSTING and CONFIG_BASE_FVP both set. Also reuse the existing board config file vexpress_aemv8a.h but differentiate the two models by the presence or absence of CONFIG_BASE_FVP. This change is tested and works on both the Foundation and Base fastmodel simulators. Support for armv7 in fastmodel is less useful due to the wide range of available silicon and the lack of a free armv7 fastmodel, so this change contains an untested armv7 placeholder for the service trap opcode. The level of semihosting support is minimal, restricted to just what it takes to load images to memory. If more semihosting functionality is required, such as file seek, outputting strings, reading characters, etc, then it can be easily added later. Sorry for the late reply. We are using ARMv8 foundation model (the free version) to launch u-boot via the ARM Trusted Firmware (ATF). We are using a older u-boot version and cannot see the ATF launching the u-boot.bin. Please find the details of the ARMv8 foundation model command line and ATF, u-boot commit logs below (Host machine is a ubuntu-64 bit). ARMv8 foundation model Command Line used - $ ./Foundation_v8 --cores=1 --no-secure-memory --visualization --gicv3 --data="bl1.bin"@0x --data="fip.bin"@0x8000 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Booting trusted firmware boot loader stage 1 Built : 12:58:21, May 22 2014 ERROR: Firmware Image Package header check failed. Booting trusted firmware boot loader stage 2 BL2 Built : 12:58:22, May 22 2014 ERROR: Firmware Image Package header check failed. ERROR: Firmware Image Package header check failed. Booting trusted firmware boot loader stage 3 BL31 Built : 12:58:23, May 22 2014 ATF latest commit - commit ca823d2c881d9d8c7db364de7e362d2e75ad55df Author: Achin Gupta Date: Sun Feb 2 13:04:00 2014 + Increase coherent stack sizes This patch increases coherent stack size for both debug and release builds in order to accommodate stack-heavy printf() and extended EL3 functionality Change-Id: I30ef30530a01517a97e63d703873374828c09f20 u-boot commit - commit 22a240c32c1340183fce12867ae5f8736b92a638 Author: Alexey Brodkin Date: Fri Dec 13 10:35:11 2013 +0400 serial/serial_arc - add driver for ARC UART Driver for non-standard on-chip UART, instantiated in the ARC (Synopsys) FPGA Boards such as ARCAngel4/ML50x Signed-off-by: Alexey Brodkin Signed-off-by: Darwin Rambo --- Changes in v3: - minor format fixup in board file Changes in v2: - use kernel_addr_r, fdt_addr_r, initrd_addr_r convention. - Use env variables for kernel/fdt/initrd file names. - Add CONFIG_BASE_FVP to differentiate VE and BASE FVP models. - CONFIG_SEMIHOSTING only refers to bringing in semihosting code now. - Remove unnecessary CONFIG_SYS_BAUDRATE_TABLE, CONFIG_SYS_PROMPT_HUSH_PS2 - Remove vexpress_aemv8a_semi.h and replace with CONFIG_BASE_FVP - Update boards.cfg
[U-Boot] [PATCH] mmc: return meaningful error codes from mmc_select_hwpart
From: Stephen Warren
Rather than just returning -1 everywhere, try to return something
meaningful from mmc_select_hwpart(). Note that most other MMC functions
don't do this, including functions called from mmc_select_hwpart(), so
I'm not sure how effective this will be. Still, it's one less place with
hard-coded -1.
Suggested-by: Pantelis Antoniou
Signed-off-by: Stephen Warren
---
drivers/mmc/mmc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 8b53ead98f80..221a293797e9 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -558,19 +559,19 @@ int mmc_select_hwpart(int dev_num, int hwpart)
int ret;
if (!mmc)
- return -1;
+ return -ENODEV;
if (mmc->part_num == hwpart)
return 0;
if (mmc->part_config == MMCPART_NOAVAILABLE) {
printf("Card doesn't support part_switch\n");
- return -1;
+ return -EMEDIUMTYPE;
}
ret = mmc_switch_part(dev_num, hwpart);
if (ret)
- return -1;
+ return ret;
mmc->part_num = hwpart;
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] disk: default to HW partition 0 if not specified
From: Stephen Warren
Currently, get_device()/get_dev_hwpart() for MMC devices does not select
an explicit HW partition unless the user explicitly requests one, i.e. by
requesting device "mmc 0.0" rather than just "mmc 0". I think it makes
more sense if the default is to select HW partition 0 (main data area)
if the user didn't request a specific partition. Otherwise, the following
happens, which feels wrong:
Select HW partition 1 (boot0):
mmc dev 0 1
Attempts to access SW partition 1 on HW partition 1 (boot0), rather than
SW partition 1 on HW partition 0 (main data area):
ls mmc 0:1 /
With this patch, the second command above re-selects the main data area.
Many device types don't support HW partitions at all, so if HW partition
0 is selected (either explicitly or as the default) and there's no
select_hwpart function, we simply skip attempting to select a HW
partition.
Some MMC devices (i.e. SD cards) don't support HW partitions. However,
this patch still works, since mmc_start_init() sets the current
partition number to 0, and mmc_select_hwpart() succeeds if the requested
partition is already selected.
Signed-off-by: Stephen Warren
---
disk/part.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/disk/part.c b/disk/part.c
index 2827089d8d5f..b3097e32f0eb 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -86,7 +86,7 @@ block_dev_desc_t *get_dev_hwpart(const char *ifname, int dev,
int hwpart)
block_dev_desc_t *dev_desc = reloc_get_dev(dev);
if (!dev_desc)
return NULL;
- if (hwpart == -1)
+ if (hwpart == 0 && !select_hwpart)
return dev_desc;
if (!select_hwpart)
return NULL;
@@ -102,7 +102,7 @@ block_dev_desc_t *get_dev_hwpart(const char *ifname, int
dev, int hwpart)
block_dev_desc_t *get_dev(const char *ifname, int dev)
{
- return get_dev_hwpart(ifname, dev, -1);
+ return get_dev_hwpart(ifname, dev, 0);
}
#else
block_dev_desc_t *get_dev_hwpart(const char *ifname, int dev, int hwpart)
@@ -460,7 +460,7 @@ int get_device(const char *ifname, const char
*dev_hwpart_str,
hwpart_str++;
} else {
dev_str = dev_hwpart_str;
- hwpart = -1;
+ hwpart = 0;
}
dev = simple_strtoul(dev_str, &ep, 16);
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] cmd_mmc: default to HW partition 0 if not specified
From: Stephen Warren
Currently, "mmc dev 0" does not change the selected HW partition. I
think it makes more sense if "mmc dev 0" is an alias for "mmc dev 0 0",
i.e. that HW partition 0 (main data area) is always selected by default
if the user didn't request a specific partition. Otherwise, the following
happens, which feels wrong:
Select HW partition 1 (boot0):
mmc dev 0 1
Doesn't change the HW partition, so it's still 1 (boot0):
mmc dev 0
With this patch, the second command above re-selects the main data area.
Note that some MMC devices (i.e. SD cards) don't support HW partitions.
However, this patch still works, since mmc_start_init() sets the current
partition number to 0, and mmc_select_hwpart() succeeds if the requested
partition is already selected.
Signed-off-by: Stephen Warren
---
This series depends on "mmc: return meaningful error codes from
mmc_select_hwpart" (which I just sent) for context.
common/cmd_mmc.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index eea337506c3f..9e6a26fe62a2 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -403,7 +403,7 @@ static int do_mmc_part(cmd_tbl_t *cmdtp, int flag,
static int do_mmc_dev(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[])
{
- int dev, part = -1, ret;
+ int dev, part = 0, ret;
struct mmc *mmc;
if (argc == 1) {
@@ -426,13 +426,12 @@ static int do_mmc_dev(cmd_tbl_t *cmdtp, int flag,
if (!mmc)
return CMD_RET_FAILURE;
- if (part != -1) {
- ret = mmc_select_hwpart(dev, part);
- printf("switch to partitions #%d, %s\n",
- part, (!ret) ? "OK" : "ERROR");
- if (ret)
- return 1;
- }
+ ret = mmc_select_hwpart(dev, part);
+ printf("switch to partitions #%d, %s\n",
+ part, (!ret) ? "OK" : "ERROR");
+ if (ret)
+ return 1;
+
curr_device = dev;
if (mmc->part_config == MMCPART_NOAVAILABLE)
printf("mmc%d is current device\n", curr_device);
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] cmd_mmc.c: check mmc_init() during mmc dev
On 05/20/2014 10:57 AM, Stephen Warren wrote:
> From: Bryan Wu
>
> mmc dev ${devnum} will return 0 as success even if there is no card
> inserted. Booting script like tegra-common-post.h will call mmc dev
> ${devnum} to check the mmc device status, it always return 0 even if
> mmc_init() fails.
>
> Check mmc_init() return value let mmc dev command return failure
> when mmc_init() fails.
For the email archive record, it looks like this same logic has already
been implemented as part of:
1fd93c6e7d8a eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc'
command
... which was just recently committed into u-boot-mmc/master.
(See the code in init_mmc_device)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] cmd_mmc: make mmc dev always re-probe the HW
From: Stephen Warren Currently, U-Boot behaves as follows: - Begin with no SD card inserted in "mmc 1" - Execute: mmc dev 1 - This fails, since there is no card - User plugs in an SD card - Execute: mmc dev 1 - This still fails, since the HW isn't reprobed. With this change, U-Boot behaves as follows: - Begin with no SD card inserted in "mmc 1" - Execute: mmc dev 1 - This fails, since there is no card - User plugs in an SD card - Execute: mmc dev 1 - The newly present SD card is detected I know that "mmc rescan" will force the HW to be reprobed, but I feel it makes more sense if "mmc dev" always reprobes the HW after selecting the current MMC device. This allows scripts to just execute "mmc dev", and not have to also execute "mmc rescan" to check for media presense. Signed-off-by: Stephen Warren --- common/cmd_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c index 6c8db2e78c4f..1e40983c757b 100644 --- a/common/cmd_mmc.c +++ b/common/cmd_mmc.c @@ -418,7 +418,7 @@ static int do_mmc_dev(cmd_tbl_t *cmdtp, int flag, return CMD_RET_USAGE; } - mmc = init_mmc_device(dev, false); + mmc = init_mmc_device(dev, true); if (!mmc) return CMD_RET_FAILURE; -- 1.8.1.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] cmd_mmc: add force_init parameter to init_mmc_device()
From: Stephen Warren
This allows callers to inject mmc->has_init = 0 between finding the
MMC device, and calling mmc_init(), which forces mmc_init() to rescan
the HW. Future changes will use this feature.
Signed-off-by: Stephen Warren
---
common/cmd_mmc.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 9e6a26fe62a2..6741ebee3bca 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -92,7 +92,7 @@ static void print_mmcinfo(struct mmc *mmc)
printf("Bus Width: %d-bit\n", mmc->bus_width);
}
-static struct mmc *init_mmc_device(int dev)
+static struct mmc *init_mmc_device(int dev, bool force_init)
{
struct mmc *mmc;
mmc = find_mmc_device(dev);
@@ -100,6 +100,8 @@ static struct mmc *init_mmc_device(int dev)
printf("no mmc device at slot %x\n", dev);
return NULL;
}
+ if (force_init)
+ mmc->has_init = 0;
if (mmc_init(mmc))
return NULL;
return mmc;
@@ -117,7 +119,7 @@ static int do_mmcinfo(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
}
- mmc = init_mmc_device(curr_device);
+ mmc = init_mmc_device(curr_device, false);
if (!mmc)
return CMD_RET_FAILURE;
@@ -247,7 +249,7 @@ static int do_mmcrpmb(cmd_tbl_t *cmdtp, int flag,
if (flag == CMD_FLAG_REPEAT && !cp->repeatable)
return CMD_RET_SUCCESS;
- mmc = init_mmc_device(curr_device);
+ mmc = init_mmc_device(curr_device, false);
if (!mmc)
return CMD_RET_FAILURE;
@@ -292,7 +294,7 @@ static int do_mmc_read(cmd_tbl_t *cmdtp, int flag,
blk = simple_strtoul(argv[2], NULL, 16);
cnt = simple_strtoul(argv[3], NULL, 16);
- mmc = init_mmc_device(curr_device);
+ mmc = init_mmc_device(curr_device, false);
if (!mmc)
return CMD_RET_FAILURE;
@@ -320,7 +322,7 @@ static int do_mmc_write(cmd_tbl_t *cmdtp, int flag,
blk = simple_strtoul(argv[2], NULL, 16);
cnt = simple_strtoul(argv[3], NULL, 16);
- mmc = init_mmc_device(curr_device);
+ mmc = init_mmc_device(curr_device, false);
if (!mmc)
return CMD_RET_FAILURE;
@@ -348,7 +350,7 @@ static int do_mmc_erase(cmd_tbl_t *cmdtp, int flag,
blk = simple_strtoul(argv[1], NULL, 16);
cnt = simple_strtoul(argv[2], NULL, 16);
- mmc = init_mmc_device(curr_device);
+ mmc = init_mmc_device(curr_device, false);
if (!mmc)
return CMD_RET_FAILURE;
@@ -387,7 +389,7 @@ static int do_mmc_part(cmd_tbl_t *cmdtp, int flag,
block_dev_desc_t *mmc_dev;
struct mmc *mmc;
- mmc = init_mmc_device(curr_device);
+ mmc = init_mmc_device(curr_device, false);
if (!mmc)
return CMD_RET_FAILURE;
@@ -422,7 +424,7 @@ static int do_mmc_dev(cmd_tbl_t *cmdtp, int flag,
return CMD_RET_USAGE;
}
- mmc = init_mmc_device(dev);
+ mmc = init_mmc_device(dev, false);
if (!mmc)
return CMD_RET_FAILURE;
@@ -462,7 +464,7 @@ static int do_mmc_bootbus(cmd_tbl_t *cmdtp, int flag,
reset = simple_strtoul(argv[3], NULL, 10);
mode = simple_strtoul(argv[4], NULL, 10);
- mmc = init_mmc_device(dev);
+ mmc = init_mmc_device(dev, false);
if (!mmc)
return CMD_RET_FAILURE;
@@ -487,7 +489,7 @@ static int do_mmc_boot_resize(cmd_tbl_t *cmdtp, int flag,
bootsize = simple_strtoul(argv[2], NULL, 10);
rpmbsize = simple_strtoul(argv[3], NULL, 10);
- mmc = init_mmc_device(dev);
+ mmc = init_mmc_device(dev, false);
if (!mmc)
return CMD_RET_FAILURE;
@@ -520,7 +522,7 @@ static int do_mmc_partconf(cmd_tbl_t *cmdtp, int flag,
part_num = simple_strtoul(argv[3], NULL, 10);
access = simple_strtoul(argv[4], NULL, 10);
- mmc = init_mmc_device(dev);
+ mmc = init_mmc_device(dev, false);
if (!mmc)
return CMD_RET_FAILURE;
@@ -555,7 +557,7 @@ static int do_mmc_rst_func(cmd_tbl_t *cmdtp, int flag,
return CMD_RET_USAGE;
}
- mmc = init_mmc_device(dev);
+ mmc = init_mmc_device(dev, false);
if (!mmc)
return CMD_RET_FAILURE;
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] cmd_mmc: Use init_mmc_device() from do_mmc_rescan()
From: Stephen Warren
The body of init_mmc_device() is now identical to that of do_mmc_rescan()
except for the error codes returned. Modify do_mmc_rescan() to simply
call init_mmc_device() and convert the error codes, to avoid code
duplication.
Signed-off-by: Stephen Warren
---
common/cmd_mmc.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 6741ebee3bca..6c8db2e78c4f 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -371,16 +371,10 @@ static int do_mmc_rescan(cmd_tbl_t *cmdtp, int flag,
{
struct mmc *mmc;
- mmc = find_mmc_device(curr_device);
- if (!mmc) {
- printf("no mmc device at slot %x\n", curr_device);
+ mmc = init_mmc_device(curr_device, true);
+ if (!mmc)
return CMD_RET_FAILURE;
- }
-
- mmc->has_init = 0;
- if (mmc_init(mmc))
- return CMD_RET_FAILURE;
return CMD_RET_SUCCESS;
}
static int do_mmc_part(cmd_tbl_t *cmdtp, int flag,
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch v2] powerpc/mpc85xx: Add workaround for DDR erratum A004508
When the DDR controller is initialized below a junction temperature of
0°C and then operated above a junction temperature of 65°C, the DDR
controller may cause receive data errors, resulting ECC errors and/or
corrupted data. This erratum applies to the following SoCs and their
variants: MPC8536, MPC8569, MPC8572, P1010, P1020, P1021, P1022, P1023,
P2020.
Signed-off-by: York Sun
---
Change log
v2: Remove warning if workaround is not enabled.
arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 +++
arch/powerpc/include/asm/config_mpc85xx.h | 18 ++
drivers/ddr/fsl/ctrl_regs.c |6 ++
3 files changed, 27 insertions(+)
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 3d37a76..f69c834 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -231,6 +231,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
if ((SVR_MAJ(svr) == 1) || IS_SVR_REV(svr, 2, 0))
puts("Work-around for Erratum NMG ETSEC129 enabled\n");
#endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A004508
+ puts("Work-around for Erratum A004508 enabled\n");
+#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_A004510
puts("Work-around for Erratum A004510 enabled\n");
#endif
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index 34fc8fb..c9fd2a5 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -38,6 +38,7 @@
#define CONFIG_SYS_PPC_E500_DEBUG_TLB 1
#define CONFIG_SYS_FSL_SEC_COMPAT 2
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
+#define CONFIG_SYS_FSL_ERRATUM_A004508
#define CONFIG_SYS_FSL_ERRATUM_A005125
#elif defined(CONFIG_MPC8540)
@@ -122,6 +123,7 @@
#define CONFIG_SYS_FSL_SRIO_IB_WIN_NUM 5
#define CONFIG_SYS_FSL_RMU
#define CONFIG_SYS_FSL_SRIO_MSG_UNIT_NUM 2
+#define CONFIG_SYS_FSL_ERRATUM_A004508
#define CONFIG_SYS_FSL_ERRATUM_A005125
#elif defined(CONFIG_MPC8572)
@@ -132,6 +134,7 @@
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
#define CONFIG_SYS_FSL_ERRATUM_DDR_115
#define CONFIG_SYS_FSL_ERRATUM_DDR111_DDR134
+#define CONFIG_SYS_FSL_ERRATUM_A004508
#define CONFIG_SYS_FSL_ERRATUM_A005125
#elif defined(CONFIG_P1010)
@@ -154,6 +157,7 @@
#define CONFIG_SYS_FSL_ERRATUM_IFC_A003399
#define CONFIG_SYS_FSL_ERRATUM_A005125
#define CONFIG_SYS_FSL_ERRATUM_I2C_A004447
+#define CONFIG_SYS_FSL_ERRATUM_A004508
#define CONFIG_SYS_FSL_ERRATUM_A007075
#define CONFIG_SYS_FSL_ERRATUM_A006261
#define CONFIG_SYS_FSL_A004447_SVR_REV 0x10
@@ -171,6 +175,7 @@
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
#define CONFIG_SYS_FSL_ERRATUM_ELBC_A001
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
+#define CONFIG_SYS_FSL_ERRATUM_A004508
#define CONFIG_SYS_FSL_ERRATUM_A005125
/* P1012 is single core version of P1021 */
@@ -188,6 +193,7 @@
#define QE_MURAM_SIZE 0x6000UL
#define MAX_QE_RISC1
#define QE_NUM_OF_SNUM 28
+#define CONFIG_SYS_FSL_ERRATUM_A004508
#define CONFIG_SYS_FSL_ERRATUM_A005125
/* P1013 is single core version of P1022 */
@@ -202,6 +208,7 @@
#define CONFIG_SYS_FSL_ERRATUM_ELBC_A001
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
#define CONFIG_FSL_SATA_ERRATUM_A001
+#define CONFIG_SYS_FSL_ERRATUM_A004508
#define CONFIG_SYS_FSL_ERRATUM_A005125
#elif defined(CONFIG_P1014)
@@ -219,6 +226,7 @@
#define CONFIG_SYS_FSL_ERRATUM_IFC_A002769
#define CONFIG_SYS_FSL_ERRATUM_P1010_A003549
#define CONFIG_SYS_FSL_ERRATUM_IFC_A003399
+#define CONFIG_SYS_FSL_ERRATUM_A004508
/* P1017 is single core version of P1023 */
#elif defined(CONFIG_P1017)
@@ -234,6 +242,7 @@
#define CONFIG_SYS_FM_MURAM_SIZE 0x1
#define CONFIG_SYS_FSL_PCIE_COMPAT "fsl,qoriq-pcie-v2.2"
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff60
+#define CONFIG_SYS_FSL_ERRATUM_A004508
#define CONFIG_SYS_FSL_ERRATUM_A005125
#elif defined(CONFIG_P1020)
@@ -246,6 +255,7 @@
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
#define CONFIG_SYS_FSL_ERRATUM_ELBC_A001
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
+#define CONFIG_SYS_FSL_ERRATUM_A004508
#define CONFIG_SYS_FSL_ERRATUM_A005125
#ifndef CONFIG_USB_MAX_CONTROLLER_COUNT
#define CONFIG_USB_MAX_CONTROLLER_COUNT2
@@ -264,6 +274,7 @@
#define QE_MURAM_SIZE 0x6000UL
#define MAX_QE_RISC1
#define QE_NUM_OF_SNUM 28
+#define CONFIG_SYS_FSL_ERRATUM_A004508
#define CONFIG_SYS_FSL_ERRATUM_A005125
#define CONFIG_USB_MAX_CONTROLLER_COUNT1
@@ -278,6 +289,7 @@
#define CONFIG_SYS_FSL_ERRATUM_ELBC_A001
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
#define CONFIG_FSL_SATA_ERRATUM_A001
+#define CONFIG_SYS_FSL_ERRATUM_A004508
#define CONFIG_SYS_FSL_ERRATUM_A005125
#elif defined(CONFIG_P1023)
@@ -293,6 +305,7 @@
#define CONFIG_SYS_FM_MURAM_SIZE 0x1
#define CONFIG_SYS_FSL_PCIE_COMPAT
Re: [U-Boot] Add myself as maintainer for chromebook-x86
On Thu, May 15, 2014 at 02:42:11PM -0600, Simon Glass wrote: > This is currently the only x86 board. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] doc:git-mailrc: Add entry for dfu subsystem
On Thu, May 22, 2014 at 03:26:55PM +0200, Łukasz Majewski wrote: > Entry for dfu subsystem have been added to doc/git-mailrc file > > Signed-off-by: Lukasz Majewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3] examples: select libgcc for non-default architecture
On Fri, May 16, 2014 at 12:54:17PM +0400, Alexey Brodkin wrote: > In case of multilib-enabled toolchains if default architecture differ from > the one examples are being built for linker will fail to link example object > files with libgcc of another (non-compatible) architecture. > > Interesting enough for years in main Makefile we used CFLAGS/c_flags for this > but not for examples. > > So fixing it now. > > Signed-off-by: Alexey Brodkin > > Cc: Masahiro Yamada > Cc: Tom Rini > Cc: Wolfgang Denx > Acked-by: WOlfgang Denk > Acked-by: Masahiro Yamada Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH v2 1/4] dm: rename device struct to udevice
Hi Heiko, On 22 May 2014 17:56, Heiko Schocher wrote: > Hello Simon, > > Am 22.05.2014 22:34, schrieb Simon Glass: > >> +Tom >> >> Hi Heiko, >> >> On 22 May 2014 00:43, Heiko Schocher wrote: >>> >>> using UBI and DM together leads in compiler error, as >>> both define a "struct device", so rename "struct device" >>> in include/dm/device.h to "struct udevice", as we use >>> linux code (MTD/UBI/UBIFS some USB code,...) and cannot >>> change the linux "struct device" >>> >>> Signed-off-by: Heiko Schocher >>> Cc: Simon Glass >>> Cc: Marek Vasut >> >> >> I'm not 100% comfortable with this but if we really want to avoid >> changing kernel code that moves into U-Boot it is either this or a > > > I vote for this, as we want to sync with newer linux code from time > to time, and not changing linux code in U-Boot makes this easier. OK. > > >> '#define device ldevice' at the top of the linux code/in a header. I'm >> not sure which is preferable. > > > Some USB Code (more too?) is also from linux ... Marek? What do you > think? > > I just did not change the current situation, but if we decide to go > in this direction, I can try it ... but what, if a source code > file uses the U-Boot driver model and linux code? Could we fall > into such a case? > > >> If Tom decides to apply this, I'd like to request that it be done >> soon, since it has wide impact on driver model code. > > > Another possibility is, to move driver model specific vars into > the linux struct device ... which leads in a bigger "struct device" > for the driver model ... It sounds like Tom is happy with your patch as is, so let's go with that unless some serious issue comes up. > > >> Acked-by: Simon Glass >> >> Regards, >> Simon > > > bye, > Heiko > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Exynos5420: Introduce support for the Peach-Pit board
Hi Akshay, On 21 May 2014 23:23, Akshay Saraswat wrote: > While the Exynos5420 chip is used in both Smdk5420 and in the Peach-Pit > line of devices, there could be other boards using the same chip, so a > common configuration file is being added (exynos5420.h) as well > as two common device tree files (exynos54xx.dtsi & exynos5420.dtsi). > > The peach board as declared in boards.cfg is a copy of smdk5420 > declaration. The configuration files are similar, but define different > default device trees, console serial ports and prompts. > > The device tree files for smdk5420 and peach-pit inherit from the same > common file. > > Signed-off-by: Vadim Bendebury > Signed-off-by: Akshay Saraswat > Acked-by: Simon Glass This looks good to me. I think you might have an extra space in the last column of your boards.cfg addition, and CONFIG_CHROMEOS_PEACH might not be needed. But I can't get pit to boot with these patches - it hangs in SPL. Do you know what is going on? 9276cf9 (HEAD, try-pit) Exynos5420: DMC: Add software read leveling 7706877 DMC: exynos5420: Gate CLKM to when reading PHY_CON13 0bc31a0 Exynos5420: Remove code for enabling read leveling cc36404 Exynos5: DMC: Modify the definition of ddr3_mem_ctrl_init 4544c39 Exynos: Make sure ps_hold gets set in the SPL f08ba9d Exynos5420: Let macros be used for exynos5420 5620192 Exynos5420: Introduce support for the Peach-Pit board 73e3bea (samsung/master) ARM: exynos5420: removed undefined gpio structure Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/2] Introduction of new board Peach-Pit
Hi Akshay,
On 21 May 2014 23:23, Akshay Saraswat wrote:
> This board is based on Exynos5420 and is similar to SMDK5420 board.
> Adding new and refactoring existing DT and config files to support
> both SMDK5420 and Peach-Pit.
>
> Changes since v1:
> - Added "Acked-by".
One more thing I noticed - the first commit gives a build error:
02: Exynos5420: Introduce support for the Peach-Pit board
-make: *** No rule to make target `peach-pit_config'. Stop.
-make[1]: *** [peach-pit_config] Error 1
+In file included from include/asm/arch/cpu.h:181:0,
+ from
/home/sjg/c/src/third_party/u-boot/try-pit/.bm-work/00/include/configs/exynos5-dt.h:17,
+ from
/home/sjg/c/src/third_party/u-boot/try-pit/.bm-work/00/include/configs/peach-pit.h:12,
+ from include/config.h:10,
+ from
/home/sjg/c/src/third_party/u-boot/try-pit/.bm-work/00/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c:9:
+/home/sjg/c/src/third_party/u-boot/try-pit/.bm-work/00/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c:
In function ‘ddr3_mem_ctrl_init’:
+/home/sjg/c/src/third_party/u-boot/try-pit/.bm-work/00/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c:406:10:
error: ‘PAD_RETENTION_DRAM_COREBLK_VAL’ undeclared (first use in this
function)
+ writel(PAD_RETENTION_DRAM_COREBLK_VAL,
+ ^
+/home/sjg/c/src/third_party/u-boot/try-pit/.bm-work/00/arch/arm/include/asm/io.h:141:34:
note: in definition of macro ‘writel’
+ #define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })
+ ^
+/home/sjg/c/src/third_party/u-boot/try-pit/.bm-work/00/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c:406:10:
note: each undeclared identifier is reported only once for each
function it appears in
+make[3]: *** [spl/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.o] Error 1
+make[2]: *** [spl/arch/arm/cpu/armv7/exynos] Error 2
+make[1]: *** [spl/u-boot-spl] Error 2
It is fixed by the second commit.
>
> Akshay Saraswat (2):
> Exynos5420: Introduce support for the Peach-Pit board
> Exynos5420: Let macros be used for exynos5420
>
> arch/arm/cpu/armv7/exynos/exynos5_setup.h | 6 +-
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/exynos5420-peach-pit.dts | 127 +
> arch/arm/dts/exynos5420-smdk5420.dts | 23 +
> arch/arm/dts/exynos5420.dtsi | 70 --
> arch/arm/dts/exynos54xx.dtsi | 151
> ++
> boards.cfg| 1 +
> include/configs/exynos5420.h | 46 +
> include/configs/peach-pit.h | 27 ++
> include/configs/smdk5420.h| 49 ++
> 10 files changed, 367 insertions(+), 136 deletions(-)
> create mode 100644 arch/arm/dts/exynos5420-peach-pit.dts
> delete mode 100644 arch/arm/dts/exynos5420.dtsi
> create mode 100644 arch/arm/dts/exynos54xx.dtsi
> create mode 100644 include/configs/exynos5420.h
> create mode 100644 include/configs/peach-pit.h
>
> --
> 1.8.3.2
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Exynos5: DMC: Modify the definition of ddr3_mem_ctrl_init
Hi Akshay, On 21 May 2014 23:32, Akshay Saraswat wrote: > Passing fewer arguments is better and mem_iv_size is never > used. Let's keep only one argument and make it cleaner. I agree with removing mem_iv_size as it is not used. But all you are doing with the other parameter is making the called function look it up again. I'm not sure that is a win. It doesn't reduce code size. (see commit 05 - there is no change). ./tools/buildman/buildman -b try-pit smdk5420 -sS Summary of 8 commits for 2 boards (2 threads, 2 jobs per thread) 01: ARM: exynos5420: removed undefined gpio structure arm: + peach-pit 02: Exynos5420: Introduce support for the Peach-Pit board 03: Exynos5420: Let macros be used for exynos5420 arm:peach-pit 04: Exynos: Make sure ps_hold gets set in the SPL arm: (for 2/2 boards) spl/u-boot-spl:all +72.0 spl/u-boot-spl:text +72.0 05: Exynos5: DMC: Modify the definition of ddr3_mem_ctrl_init 06: Exynos5420: Remove code for enabling read leveling arm: (for 2/2 boards) spl/u-boot-spl:all -344.0 spl/u-boot-spl:text -344.0 07: DMC: exynos5420: Gate CLKM to when reading PHY_CON13 arm: (for 2/2 boards) spl/u-boot-spl:all +136.0 spl/u-boot-spl:text +136.0 08: Exynos5420: DMC: Add software read leveling arm: (for 2/2 boards) spl/u-boot-spl:all +712.0 spl/u-boot-spl:rodata +16.0 spl/u-boot-spl:text +696.0 (try-pit=9276cf: b/ fred.dtb mdk5420 sandbox/ scripts/ x) ~/u> Anyway it doesn't hurt, so: Acked-by: Simon Glass > > Signed-off-by: Hatim Ali > Signed-off-by: Akshay Saraswat > --- Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] Exynos5420: Remove code for enabling read leveling
Hi Akshay, On 21 May 2014 23:33, Akshay Saraswat wrote: > This patch intends to remove all code which enables hardware read > leveling. All characterization environments may not cope up with > h/w read leveling enabled, hence, we need to disable this. > Also, disabling h/w read leveling improves the MIF LVcc value > (LVcc value is the value at which DDR will fail to work properly). > Improving LVcc means we have enough voltage margin for MIF. > When h/w leveling is enabled, we have almost zero volatge margin. > > Signed-off-by: Alim Akhtar > Signed-off-by: Akshay Saraswat Acked-by: Simon Glass Does this mean that the read_leveling_enable structure member is not used? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] DMC: exynos5420: Gate CLKM to when reading PHY_CON13
On 21 May 2014 23:33, Akshay Saraswat wrote: > From: Doug Anderson > > From experiments it appears that PHY_CON13 is glitchy if we sample it > when CLKM is running. If we stop CLKM when sampling it the glitches > all go away, so we'll do that. > > We also check the "is it locked" bits of PHY_CON13 and loop until they > show that the value sampled actually represents a locked value. It > doesn't appear that the glitching and "is it locked" are related, but > it seems wise to wait until the PHY tells us the value is good before > we use it. In practice we will not loop more than a couple times (and > usually won't loop at all). > > Signed-off-by: Doug Anderson > Signed-off-by: Akshay Saraswat 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 4/4] Exynos5420: DMC: Add software read leveling
Hi Akshay,
On 21 May 2014 23:33, Akshay Saraswat wrote:
> Sometimes Read DQ and DQS are not in phase. Since, this
> phase shift differs from board to board, we need to
> calibrate it at DRAM init phase, that's read DQ calibration.
> This patch adds SW Read DQ calibration routine to compensate
> this skew.
The English could be a bit better here - also suggest formatting to 72
columns or more.
>
> Signed-off-by: Alim Akhtar
> Signed-off-by: Akshay Saraswat
> ---
> arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 244
> +-
> arch/arm/cpu/armv7/exynos/exynos5_setup.h | 5 +-
> arch/arm/include/asm/arch-exynos/dmc.h| 3 +
> arch/arm/include/asm/arch-exynos/power.h | 4 +-
> 4 files changed, 252 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
> b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
> index 0654c6a..a4f6099 100644
> --- a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
> +++ b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
> @@ -6,6 +6,7 @@
> * SPDX-License-Identifier:GPL-2.0+
> */
>
> +#include
> #include
> #include
> #include
> @@ -16,7 +17,12 @@
> #include "exynos5_setup.h"
> #include "clock_init.h"
>
> -#define TIMEOUT1
> +#define TIMEOUT1
Is this in milliseconds? If so TIMEOUT_MS, or maybe microseconds, TIMEOUT _US
> +#define NUM_BYTE_LANES 4
> +#define DEFAULT_DQS8
> +#define DEFAULT_DQS_X4 0x08080808
What does this mean?
> +#define FALSE 0
> +#define TRUE 1
You can just use true and false in U-Boot now (the bool type).
>
> #ifdef CONFIG_EXYNOS5250
> static void reset_phy_ctrl(void)
> @@ -222,6 +228,219 @@ int ddr3_mem_ctrl_init(int reset)
> #endif
>
> #ifdef CONFIG_EXYNOS5420
> +/*
> + * RAM address to use in the test.
> + *
> + * We'll use 4 words at this address and 4 at this address + 0x80 (Ares
> + * interleaves channels every 128 bytes). This will allow us to evaluate
> all of
> + * the chips in a 1 chip per channel (2GB) system and half the chips in a 2
> + * chip per channel (4GB) system. We can't test the 2nd chip since we need
> to
> + * do tests before the 2nd chip is enabled. Looking at the 2nd chip isn't
> + * critical because the 1st and 2nd chip have very similar timings (they'd
> + * better have similar timings, since there's only a single adjustment that
> is
> + * shared by both chips).
> + */
> +const unsigned int test_addr = 0x2000;
Isn't this CONFIG_SYS_SDRAM_BASE?
> +
> +/* Test pattern with which RAM will be tested */
> +static const unsigned int test_pattern[] = {
> + 0x5A5A5A5A,
> + 0xA5A5A5A5,
> + 0xF0F0F0F0,
> + 0x0F0F0F0F,
Lower case hex throughout?
> +};
> +
> +/*
/**
Should fix for each function.
> + * This function is a test vector for sw read leveling,
> + * it compares the read data with the written data.
> + *
> + * @param ch DMC channel number
> + * @param byte_lanewhich DQS byte offset,
> + * possible values are 0,1,2,3
> + * @returnsTRUE if memory was good, FALSE if not.
@return
> + */
> +static int dmc_valid_window_test_vector(int ch, int byte_lane)
> +{
> + unsigned int read_data;
> + unsigned int mask;
> + int i;
> +
> + mask = 0xFF << (8 * byte_lane);
> +
> + for (i = 0; i < ARRAY_SIZE(test_pattern); i++) {
> + read_data = readl(test_addr + i*4 + ch*0x80);
Spaces around * operators
> + if ((read_data & mask) != (test_pattern[i] & mask))
> + return FALSE;
> + }
> +
> + return TRUE;
> +}
> +
> +/*
> + * This function returns current read offset value.
> + *
> + * @param phy_ctrl pointer to the current phy controller
> + */
> +static unsigned int dmc_get_read_offset_value(struct exynos5420_phy_control
> + *phy_ctrl)
> +{
> + return readl(&phy_ctrl->phy_con4);
> +}
> +
> +/*
> + * This function performs resync, so that slave DLL is updated.
> + *
> + * @param phy_ctrl pointer to the current phy controller
> + */
> +static void ddr_phy_set_do_resync(struct exynos5420_phy_control *phy_ctrl)
> +{
> + setbits_le32(&phy_ctrl->phy_con10, PHY_CON10_CTRL_OFFSETR3);
> + clrbits_le32(&phy_ctrl->phy_con10, PHY_CON10_CTRL_OFFSETR3);
> +}
> +
> +/*
> + * This function sets read offset value register with 'offset'.
> + *
> + * ...we also call call ddr_phy_set_do_resync().
> + *
> + * @param phy_ctrl pointer to the current phy controller
> + * @param offset offset to read DQS
> + */
> +static void dmc_set_read_offset_value(struct exynos5420_phy_control
> *phy_ctrl,
> + unsigned int offset)
> +{
> + writel(offset, &phy_ctrl->phy_con4);
> + ddr_phy_set_do_resync(phy_ctrl);
> +}
> +
> +/*
> + * Convert a 2s complement byte to a byte with a sign
[U-Boot] [PATCH v4] arm: Add support for semihosting for armv8 fastmodel targets.
The reason for this change is to be able to use the ARM Trusted Firmware (ATF) to load the various ATF images, plus u-boot, which can then load the kernel/ramdisk/dtb with calls to an external host from a standard fastmodel armv8 board file using semihosting, and then launch the kernel without a bootwrapper. This gives us a more realistic boot sequence. There are two main ARM virtual Fixed Virtual Platform (FVP) models, Versatile Express (VE) FVP and BASE FVP (See http://www.arm.com/products/tools/models/fast-models/foundation-model.php) The initial vexpress64 u-boot board created here runs on the VE virtual platform using the license-free Foundation_v8 simulator. Fortunately, the Foundation_v8 simulator also supports the BASE_FVP model which companies can purchase licenses for and contain much more functionality. So we can, in u-boot, run either model by either using the VE FVP (default), or turning on CONFIG_BASE_FVP for the more full featured model. Rather than create a new armv8 board similar to armltd/vexpress64, add semihosting calls to the existing one, enabled with CONFIG_SEMIHOSTING and CONFIG_BASE_FVP both set. Also reuse the existing board config file vexpress_aemv8a.h but differentiate the two models by the presence or absence of CONFIG_BASE_FVP. This change is tested and works on both the Foundation and Base fastmodel simulators. Support for armv7 in fastmodel is less useful due to the wide range of available silicon and the lack of a free armv7 fastmodel, so this change contains an untested armv7 placeholder for the service trap opcode. The level of semihosting support is minimal, restricted to just what it takes to load images to memory. If more semihosting functionality is required, such as file seek, outputting strings, reading characters, etc, then it can be easily added later. Signed-off-by: Darwin Rambo Cc: tr...@ti.com Cc: feng...@phytium.com.cn Cc: bhupesh.sha...@freescale.com --- Changes in v4: - refreshed patch and retested - fix boards.cfg conflict - fix GICV3 conflict - minor documentation cleanup - semihosting.c, README.semihosting - change maintainer of semihosting target - tested with vexpress_aemv8a_semi target (BASE_FVP) against e75e73dd5f280b91f5bfc0a76a0fd09b6eba1c66 (May 16, 2014) Changes in v3: - minor format fixup in board file Changes in v2: - use kernel_addr_r, fdt_addr_r, initrd_addr_r convention. - Use env variables for kernel/fdt/initrd file names. - Add CONFIG_BASE_FVP to differentiate VE and BASE FVP models. - CONFIG_SEMIHOSTING only refers to bringing in semihosting code now. - Remove unnecessary CONFIG_SYS_BAUDRATE_TABLE, CONFIG_SYS_PROMPT_HUSH_PS2 - Remove vexpress_aemv8a_semi.h and replace with CONFIG_BASE_FVP - Update boards.cfg with option SEMIHOSTING and BASE_FVP - Add doc/README.semihosting Changes in v1: - Initial code - Remove empty timer_init() function. arch/arm/include/asm/semihosting.h | 21 +++ arch/arm/lib/Makefile|1 + arch/arm/lib/semihosting.c | 233 ++ board/armltd/vexpress64/vexpress64.c | 101 ++- boards.cfg |1 + doc/README.semihosting | 35 + include/configs/vexpress_aemv8a.h| 63 - 7 files changed, 443 insertions(+), 12 deletions(-) create mode 100644 arch/arm/include/asm/semihosting.h create mode 100644 arch/arm/lib/semihosting.c create mode 100644 doc/README.semihosting diff --git a/arch/arm/include/asm/semihosting.h b/arch/arm/include/asm/semihosting.h new file mode 100644 index 000..74111dc --- /dev/null +++ b/arch/arm/include/asm/semihosting.h @@ -0,0 +1,21 @@ +/* + * Copyright 2014 Broadcom Corporation + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#ifndef __SEMIHOSTING_H__ +#define __SEMIHOSTING_H__ + +/* + * ARM semihosting functions for loading images to memory. See the source + * code for more information. + */ +int smh_load(const char *fname, void *memp, int avail, int verbose); +int smh_read(int fd, void *memp, int len); +int smh_open(const char *fname, char *modestr); +int smh_close(int fd); +int smh_len_fd(int fd); +int smh_len(const char *fname); + +#endif /* __SEMIHOSTING_H__ */ diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index 585f1f7..1ef2400 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -32,6 +32,7 @@ obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o else obj-$(CONFIG_SPL_FRAMEWORK) += spl.o endif +obj-$(CONFIG_SEMIHOSTING) += semihosting.o obj-y += sections.o ifdef CONFIG_ARM64 diff --git a/arch/arm/lib/semihosting.c b/arch/arm/lib/semihosting.c new file mode 100644 index 000..cb5dc26 --- /dev/null +++ b/arch/arm/lib/semihosting.c @@ -0,0 +1,233 @@ +/* + * Copyright 2014 Broadcom Corporation + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +/* + * Minimal semihosting implementation for reading files into memory. If more + * features like writing files or console output are required they can be + * added late
Re: [U-Boot] [U-Boot, 1/3] cm-t54: add EEPROM support and MAC address handling
On Sun, Apr 27, 2014 at 01:18:46PM +0300, Dmitry Lifshitz wrote: > cm-t54 Eth MAC address is stored in onboard EEPROM. > Add EEPROM support and setup stored Eth MAC address. > > If EEPROM does not contain a valid MAC, then generate it from the > processor ID code (reference code is taken from OMAP5 uEvm board file). > > Modify Device Tree blob MAC address field with retrieved data. > > Signed-off-by: Dmitry Lifshitz > Acked-by: Igor Grinberg Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v1, 1/3] ARM: omap4: add platform specific info for GPMC and ELM controllers
On Thu, May 08, 2014 at 09:43:45PM +0530, pekon gupta wrote: > This patch moves platform specific information for GPMC and ELM controller > into separate header files, so that any derivative devices do not mess other > header files. > > Platform specific information added into arch-xx/../hardware.h > - CPU related platform specific details like base-address of GPMC and ELM > > Platform specific information added into arch-xx/../mem.h > - Generic configs for GPMC and ELM initialization. > - Hardware parameters or constrains specific to GPMC and ELM IP like; >number of max number of chip-selects available > > Signed-off-by: Pekon Gupta Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/3] cm-t54: add environment partition runtime detection
On Sun, Apr 27, 2014 at 01:18:48PM +0300, Dmitry Lifshitz wrote: > Add environment partition runtime detection callback. > > Signed-off-by: Dmitry Lifshitz > Acked-by: Igor Grinberg Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, U-Boot, 1/5] ARM: DRA72x: Add Silicon ID support
On Thu, May 15, 2014 at 11:08:38AM +0530, Lokesh Vutla wrote: > Add silicon ID code for DRA722 silicon. > > Signed-off-by: Lokesh Vutla > Acked-by: Tom Rini Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, am33xx: Enable CONFIG_SYS_GENERIC_BOARD for siemens boards
On Wed, May 14, 2014 at 12:40:27PM +0200, Heiko Schocher wrote: > Signed-off-by: Heiko Schocher > Cc: Tom Rini > Cc: Samuel Egli > Cc: Roger Meier > Tested-by: Samuel Egli Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v1, 2/3] ARM: omap5: add platform specific info for GPMC and ELM controllers
On Thu, May 08, 2014 at 09:43:46PM +0530, pekon gupta wrote: > This patch moves platform specific information for GPMC and ELM controller > into separate header files, so that any derivative devices do not mess other > header files. > > Platform specific information added into arch-xx/../hardware.h > - CPU related platform specific details like base-address of GPMC and ELM > > Platform specific information added into arch-xx/../mem.h > - Generic configs for GPMC and ELM initialization. > - Hardware parameters or constrains specific to GPMC and ELM IP like; >number of max number of chip-selects available > > Signed-off-by: Pekon Gupta Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: OMAP: Fix omap_sdram_size calculation
On Mon, May 12, 2014 at 01:49:33PM +0530, Lokesh Vutla wrote: > Last section of DMM is used for trapping tiler unmapped sections. > Corresponding trap_size should be deducted from total SDRAM size > only if trap section is overlapping with available SDRAM > based on DMM sections. Fixing the same. > > Signed-off-by: Lokesh Vutla Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, U-Boot, 2/5] ARM: DRA72x: volt: Update the pmic offsets
On Thu, May 15, 2014 at 11:08:39AM +0530, Lokesh Vutla wrote: > From: Keerthy > > TPS65917 is used in DRA722 evm. Update the address offsets accordingly. > > Signed-off-by: Lokesh Vutla > Signed-off-by: Keerthy > Acked-by: Tom Rini Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, U-Boot, 3/5] ARM: DRA72x: clocks: Update the hwdata
On Thu, May 15, 2014 at 11:08:40AM +0530, Lokesh Vutla wrote: > Adding the prcm, dplls, control module hooks for DRA72x. > > Signed-off-by: Lokesh Vutla > Acked-by: Tom Rini Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, U-Boot, 5/5] ARM: DRA7xx: ctrl: Fix efuse register addresses
On Thu, May 15, 2014 at 11:08:42AM +0530, Lokesh Vutla wrote: > Efuse register addresses are wrongly programmed. > Fixing the same. > > Signed-off-by: Lokesh Vutla > Acked-by: Tom Rini Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,U-Boot,4/5] ARM: DRA72x: Update EMIF data
On Thu, May 15, 2014 at 11:08:41AM +0530, Lokesh Vutla wrote: > DRA72 has 1GB connected to EMIF1 only. Updating the details. > And also enable WA for BUG0039 only if corresponding EMIF is present. > > Signed-off-by: Lokesh Vutla > Acked-by: Tom Rini Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,4/4] cm-t54: add cm-t54 board support
On Mon, May 19, 2014 at 12:50:54PM +0300, Dmitry Lifshitz wrote: > Add cm-t54 board directory, config file. Enable build. > > Basic support includes: > > Serial console > SD/MMC > eMMC > USB > Ethernet > > Signed-off-by: Dmitry Lifshitz > Acked-by: Igor Grinberg Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] compulab: eeprom: add default eeprom address
On Thu, May 15, 2014 at 11:25:09AM +0300, Igor Grinberg wrote: > Add default eeprom address setting. > > Signed-off-by: Igor Grinberg Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] armv7:TI: Add and migrate omap_hw_init_context
On Fri, May 16, 2014 at 01:02:24PM -0400, Tom Rini wrote: > The omap_hw_init_context function (and assorted helpers) is the same for > all OMAP-derived parts as when CHSETTINGS are used, that's the same and > our DDR base is also always the same. In order to make this common we > simply need to update the names of the define for DDR address space > which is also common. > > Cc: Sricharan R. > Cc: Lokesh Vutla > Signed-off-by: Tom Rini > Reviewed-by: Lokesh Vutla Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/9] omap: overo: allow the use of a plain text env file instead boot scripts
On Wed, May 21, 2014 at 02:04:47PM -0700, Ash Charles wrote: > Adapted from d70f5480 described below. > > commit d70f54808dfa83b574e1239c3eccbcf3317343e1 > Author: Javier Martinez Canillas > Date: Mon Jan 7 03:51:20 2013 + > > omap4: allow the use of a plain text env file instead boot scripts > > For production systems it is better to use script images since > they are protected by checksums and carry valuable information like > name and timestamp. Also, you can't validate the content passed to > env import. > > But for development, it is easier to use the env import command and > plain text files instead of script-images. > > Since both OMAP4 supported boards (Panda and TI SDP4430) are used > primarily for development, this patch allows U-Boot to load env var > from a text file in case that an boot.scr script-image is not present. > > The variable uenvcmd (if existent) will be executed (using run) after > uEnv.txt was loaded. If uenvcmd doesn't exist the default boot sequence > will be started. > > Signed-off-by: Javier Martinez Canillas > Acked-by: Nishanth Menon > > Signed-off-by: Peter A. Bigot > Tested-by: Ash Charles Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 2/9] OMAP3: overo: add command support for mtd and ubi
On Wed, May 21, 2014 at 02:04:48PM -0700, Ash Charles wrote: > The NAND linux partition format default was changed from jffs2 to ubi in > 254973e6df0e48f1a72b67905185c774dcd9f394 but the corresponding commands were > not enabled. > > Signed-off-by: Peter A. Bigot > Tested-by: Ash Charles Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 4/9] OMAP3: overo: eliminate hard-coded partition offsets
On Wed, May 21, 2014 at 02:04:50PM -0700, Ash Charles wrote: > The linux kernel is at nand0,3 using the current layout, but is best > accessed through the partition label "linux". Since CONFIG_CMD_MTDPARTS is > defined the CONFIG_JFFS2 settings are unreferenced; use "setenv partition > rootfs" to set the default mtd partition for jffs2. > > Signed-off-by: Peter A. Bigot > Tested-by: Ash Charles Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 5/9] arm: omap3: Fix omap3_overo SPL boot hangup
On Wed, May 21, 2014 at 02:04:51PM -0700, Ash Charles wrote: > Patch f33b9bd3 > [arm: omap3: Enable clocks for peripherals only if they are used] > breaks SPL booting on Overo. Since some gpio inputs are > read to detect the board revision. But with this patch above, the > clocks to the GPIO subsystems are not enabled per default any more. > The GPIO banks need to be configured specifically now. > > Signed-off-by: Ash Charles Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 3/9] OMAP3: overo: increase linux partition to 8 MiB
On Wed, May 21, 2014 at 02:04:49PM -0700, Ash Charles wrote: > From: "Peter A. Bigot" > > Linux kernel at version 3.5 is about 3.5 MiB; test kernels for 3.10 exceed 4 > MiB. Prepare for future upgrades by increasing the NAND partition now. > > Signed-off-by: Peter A. Bigot > Tested-by: Ash Charles Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 8/9, omap3, overo] Allow overo to boot with device tree
On Wed, May 21, 2014 at 02:04:54PM -0700, Ash Charles wrote: > Update the board configuration for Gumstix Overo. In particular, > add support for zImage and DTB files on boot. > > Signed-off-by: Ash Charles Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 6/9, omap3, overo] Add Board Revision for Wireless chip
On Wed, May 21, 2014 at 02:04:52PM -0700, Ash Charles wrote: > Gumstix Overo COMs with board revision 0x4 use a different Wifi and > Bluetooth module: Wi2Wi's W2CBW0015. No other code changes are required > in u-boot---just handling of this particular board revision. > > Signed-off-by: Ash Charles Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 7/9] OMAP3: overo: add some Gumstix expansion boards
On Wed, May 21, 2014 at 02:04:53PM -0700, Ash Charles wrote: > Add EEPROM ID switches for Alto35, Arbor43C, Stagecoach, Thumbo, and > Turtlecore Gumstix Overo expansion boards. > > Signed-off-by: Ash Charles Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 9/9] omap3: overo: Use common configurations for Overo
On Wed, May 21, 2014 at 02:04:55PM -0700, Ash Charles wrote: > Clean-up the board configuration file for the Gumstix Overo board by > including common omap3 definitions from ti_omap3_common.h as suggested > here [1]. > > [1] http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/185960 > > Signed-off-by: Ash Charles Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/1] am33xx: report silicon revision instead of code
On Thu, May 22, 2014 at 11:56:03AM +0400, Sergey Alyoshin wrote: > As revision code 1 is for silicon revision 2.0, it is easily confused with > silicon revision 1.0. > > Device type report also reworked in same style. > > Signed-off-by: Sergey Alyoshin Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] compulab: eeprom: enable any i2c driver
On Wed, Apr 16, 2014 at 01:48:26PM +0300, Ilya Ledvich wrote: > Make the common eeprom library available for any I2C driver. > > Signed-off-by: Ilya Ledvich > Signed-off-by: Igor Grinberg Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3] omap4: duovero: Add Gumstix DuoVero machine.
On Wed, May 14, 2014 at 08:34:34AM -0700, Ash Charles wrote: > This adds the Gumstix DuoVero machine [1]. This is a OMAP4430-based > computer-on-module (COM aka SOM) that can be mounted on various > expansion boards with different peripherals. > > [1] https://store.gumstix.com/index.php/category/43/ > > Signed-off-by: Ash Charles > Cc: Tom Rini After renaming enable_gpmc_cs_config to enable_gpmc_net_config (due to Pekon's series), applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
Hello, The following changes since commit 05d134b084590684bcf4d832c0035952727b7cd9: Merge remote-tracking branch 'u-boot/master' (2014-05-20 10:05:42 +0200) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to 39338a30fab2ce7d80dfe0d457071573727f499f: compulab: eeprom: enable any i2c driver (2014-05-23 19:40:39 -0400) Ash Charles (9): omap: overo: allow the use of a plain text env file instead boot scripts OMAP3: overo: add command support for mtd and ubi OMAP3: overo: eliminate hard-coded partition offsets arm: omap3: Fix omap3_overo SPL boot hangup Add Board Revision for Wireless chip OMAP3: overo: add some Gumstix expansion boards Allow overo to boot with device tree omap3: overo: Use common configurations for Overo omap4: duovero: Add Gumstix DuoVero machine. Dmitry Lifshitz (3): cm-t54: add cm-t54 board support cm-t54: add EEPROM support and MAC address handling cm-t54: add environment partition runtime detection Heiko Schocher (1): arm, am33xx: Enable CONFIG_SYS_GENERIC_BOARD for siemens boards Igor Grinberg (1): compulab: eeprom: add default eeprom address Ilya Ledvich (1): compulab: eeprom: enable any i2c driver Keerthy (1): ARM: DRA72x: volt: Update the pmic offsets Lokesh Vutla (5): ARM: DRA72x: Add Silicon ID support ARM: DRA72x: clocks: Update the hwdata ARM: DRA72x: Update EMIF data ARM: DRA7xx: ctrl: Fix efuse register addresses ARM: OMAP: Fix omap_sdram_size calculation Peter A. Bigot (1): OMAP3: overo: increase linux partition to 8 MiB Sergey Alyoshin (1): am33xx: report silicon revision instead of code Tom Rini (1): armv7:TI: Add and migrate omap_hw_init_context pekon gupta (3): ARM: omap4: add platform specific info for GPMC and ELM controllers ARM: omap5: add platform specific info for GPMC and ELM controllers ARM: omap: merge GPMC initialization code for all platform arch/arm/cpu/armv7/am33xx/Makefile |1 - arch/arm/cpu/armv7/am33xx/mem.c| 98 arch/arm/cpu/armv7/am33xx/sys_info.c | 41 ++-- arch/arm/cpu/armv7/omap-common/Makefile|4 - arch/arm/cpu/armv7/omap-common/emif-common.c |6 +- arch/arm/cpu/armv7/omap-common/hwinit-common.c | 15 +- arch/arm/cpu/armv7/omap-common/mem-common.c| 117 +- arch/arm/cpu/armv7/omap3/Makefile |1 - arch/arm/cpu/armv7/omap5/hw_data.c | 40 arch/arm/cpu/armv7/omap5/hwinit.c |3 + arch/arm/cpu/armv7/omap5/prcm-regs.c |8 +- arch/arm/cpu/armv7/omap5/sdram.c | 19 +- arch/arm/include/asm/arch-am33xx/sys_proto.h |1 + arch/arm/include/asm/arch-omap3/mem.h |1 + arch/arm/include/asm/arch-omap4/cpu.h |5 +- arch/arm/include/asm/arch-omap4/hardware.h | 26 +++ arch/arm/include/asm/arch-omap4/mem.h | 62 + arch/arm/include/asm/arch-omap4/omap.h |3 - arch/arm/include/asm/arch-omap4/sys_proto.h| 51 +--- arch/arm/include/asm/arch-omap5/cpu.h |5 +- arch/arm/include/asm/arch-omap5/hardware.h | 26 +++ arch/arm/include/asm/arch-omap5/mem.h | 62 + arch/arm/include/asm/arch-omap5/omap.h |9 +- arch/arm/include/asm/arch-omap5/sys_proto.h| 50 +--- arch/arm/include/asm/omap_common.h |7 +- arch/arm/include/asm/ti-common/sys_proto.h | 72 ++ board/compulab/cm_t54/Makefile | 10 + board/compulab/cm_t54/cm_t54.c | 262 + board/compulab/cm_t54/mux.c| 94 board/compulab/cm_t54/spl.c| 66 ++ board/compulab/common/Makefile |2 +- board/compulab/common/eeprom.c |5 + board/compulab/common/eeprom.h |2 +- board/gumstix/duovero/Makefile |8 + board/gumstix/duovero/duovero.c| 264 + board/gumstix/duovero/duovero_mux_data.h | 199 board/overo/overo.c| 43 +++- board/overo/overo.h| 17 ++ boards.cfg |2 + include/configs/cm_t54.h | 149 include/configs/duovero.h | 62 + include/configs/omap3_overo.h | 296 include/configs/siemens-am33x-common.h |2 + include/configs/ti_omap4_common.h |9 + 44 files changed, 1757 insertions(+), 468 deletions(-) delete mode 100644 arch/arm/cpu/armv7/am33xx/mem.c create mode 100644 arch/arm/include/asm/arch-omap4/hardware.h create mode 100644 arch/arm
Re: [U-Boot] [U-Boot, v1, 3/3] ARM: omap: merge GPMC initialization code for all platform
On Thu, May 08, 2014 at 09:43:47PM +0530, pekon gupta wrote: > GPMC controller on TI's OMAP SoC is general purpose controller to interface > with different types of external devices like; > - parallel NOR flash > - parallel NAND flash > - OneNand flash > - SDR RAM > - Ethernet Devices like LAN9220 > > Though GPMC configurations may be different for each platform depending on > clock-frequency and external device interfacing with controller. But > initialization sequence remains common across all platfoms. > > Thus this patch merges gpmc_init() scattered in different arch-xx/mem.c > files into single omap-common/mem-common.c > > However, actual platforms specific register config values are still sourced > from corresponding platform specific headers like; > AM33xx: arch/arm/include/asm/arch-am33xx/mem.h > OMAP3: arch/arm/include/asm/arch-omap3/mem.h > OMAP4: arch/arm/include/asm/arch-omap4/mem.h > OMAP4: arch/arm/include/asm/arch-omap5/mem.h > > Also, CONFIG_xx passed by board-profile decide config for which set of macros > need to be used for initialization > CONFIG_NAND:initialize GPMC for NAND device > CONFIG_NOR: initialize GPMC for NOR device > CONFIG_ONENAND: initialize GPMC for ONENAND device > > Signed-off-by: Pekon Gupta After adding GPMC_SIZE_256M to omap3/mem.h, applied to u-boot-ti/master, thanks! And note that git detect renames got a bit too agressive here so I had to apply it kinda by hand, but I think I did everything right. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/4] bootm: make use of legacy image format configurable
Hi Heiko,
On 19 May 2014 20:49, Heiko Schocher wrote:
> make the use of legacy image format configurable through
> the config define CONFIG_IMAGE_FORMAT_LEGACY.
>
> When relying on signed FIT images with required signature check
> the legacy image format should be disabled. Therefore introduce
> this new define and enable legacy image format if CONFIG_FIT_SIGNATURE
> is not set. If CONFIG_FIT_SIGNATURE is set disable per default
> the legacy image format.
>
> Signed-off-by: Heiko Schocher
> Cc: Simon Glass
> Cc: Lars Steubesand
> Cc: Mike Pearce
> Cc: Wolfgang Denk
> Cc: Tom Rini
> Cc: Michal Simek
>
> ---
> - changes for v2:
> - make the legacy image format configurable through
> the define CONFIG_IMAGE_FORMAT_LEGACY.
>
> Default:
> if not CONFIG_FIT_SIGNATURE is defined it is enabled,
> else disabled.
>
> Disable it with CONFIG_DISABLE_IMAGE_LEGACY if
> CONFIG_FIT_SIGNATURE is not defined.
> - changes for v3:
> - enable legacy image format for zync as default, as Michak
> suggested.
>
> - changes for v4:
> move changes for default settings in include/config_defaults.h
> to include/config_fallbacks.h, so board settings are considered
> as Lars Steubesand suggested.
> ---
> README| 18 ++
> common/cmd_bootm.c| 14 ++
> common/cmd_disk.c | 4
> common/cmd_fdc.c | 4
> common/cmd_fpga.c | 2 ++
> common/cmd_nand.c | 4
> common/cmd_source.c | 4
> common/cmd_ximg.c | 7 ++-
> common/image-fdt.c| 10 --
> common/image.c| 23 ---
> doc/uImage.FIT/signature.txt | 3 +++
> include/config_fallbacks.h| 8
> include/configs/zynq-common.h | 1 +
> include/image.h | 2 ++
> 14 files changed, 94 insertions(+), 10 deletions(-)
It all looks good to me except for one nit below.
> diff --git a/common/cmd_ximg.c b/common/cmd_ximg.c
> index 65a8319..813543a 100644
> --- a/common/cmd_ximg.c
> +++ b/common/cmd_ximg.c
> @@ -32,10 +32,13 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, char
> * const argv[])
> {
> ulong addr = load_addr;
> ulong dest = 0;
> - ulong data, len, count;
> + ulong data, len;
> int verify;
> int part = 0;
> +#if defined(CONFIG_IMAGE_FORMAT_LEGACY)
> + ulong count;
> image_header_t *hdr = NULL;
This is also used with CONFIG_BZIP2 (see lower in this function). This
change causes a build error in sandbox, for example.
I notice also that it causes a useful reduction in U-Boot size.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unable to boot the new FIT image
Hi, On 21 May 2014 15:12, Simon Glass wrote: > Hi Harsha, > > On 21 May 2014 06:46, Harsha Kiran wrote: >> Hi Simon, >> >> I have added the next patch in the series i.e., (../339610/) But the >> result is still the same. This particular patch just created a device tree >> In the arch/arm/dts folder For the beaglebone. I have already tried creating >> for am335x-evmsk and was able to build the u-boot-dtb.bin. >> >> I have noticed that MLO is configured to read only the u-boot.img not any >> other binaries (eg U-boot.bin or u-boot-dtb.bin). >> It gives me the following error.. >> spl_load_image_fat: error reading image u-boot.img, err - -1 Which part of >> the configuration I should change so that MLO tries to read the >> u-boot-dtb.bin as the third stage bootloader?? >> I tried loading MLO->u-boot.img first, but this time it reads the u-boot.img >> but gives the following error.. >> >> reading u-boot.img >> reading u-boot.img >> No valid FDT found - please append one to U-Boot binary, use u-boot-dtb.bin >> or define CONFIG_OF_EMBED. For sandbox, use -d ### ERROR ### >> Please RESET the board ### Also I wonder if this is related to Heiko's patch? Worth trying. http://patchwork.ozlabs.org/patch/350541/ Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] lib, fdt: move fdtdec_get_int() out of lib/fdtdec.c
Hi Heiko, On 18 May 2014 19:10, Heiko Schocher wrote: > move fdtdec_get_int() out of lib/fdtdec.c into lib/fdtdec_common.c > as this function is also used, if CONFIG_OF_CONTROL is not > used. Poped up on the ids8313 board using signed FIT images, > and activating CONFIG_SYS_GENERIC_BOARD. Without this patch > it shows on boot: > > No valid FDT found - please append one to U-Boot binary, use u-boot-dtb.bin > or define CONFIG_OF_EMBED. For sandbox, use -d > > With this patch, it boots again with CONFIG_SYS_GENERIC_BOARD > enabled. > > Signed-off-by: Heiko Schocher > Cc: Simon Glass > Cc: Tom Rini Acked-by: Simon Glass But I wonder if it might be possible to keep the debug() statement for the non-host side? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Exynos: Make sure ps_hold gets set in the SPL
On 22 May 2014 01:53, Akshay Saraswat wrote: > From: Doug Anderson > > Setting ps_hold ought to be one of the first things we do when we > first boot up. If we wait until the main u-boot runs we won't set it > in time and the PMIC may power us back off. > > Moving ps_hold setup into the generic power_init() which > should contain code that's currently duplicated in the > board_power_init() of several boards. > > Signed-off-by: Doug Anderson > Signed-off-by: Akshay Saraswat > --- > arch/arm/cpu/armv7/exynos/lowlevel_init.c | 6 +- > arch/arm/cpu/armv7/exynos/power.c | 14 ++ > arch/arm/include/asm/arch-exynos/power.h | 8 > 3 files changed, 27 insertions(+), 1 deletion(-) Acked-by: Simon Glass Also see http://patchwork.ozlabs.org/patch/350693/ but your patch is better. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] test:dfu: Add test script for testing DFU regression
Hi Lukasz,
On 22 May 2014 00:43, Lukasz Majewski wrote:
> This commit adds test script for testing if any commit has introduced
> regression to the DFU.
>
> It uses md5 to test if sent and received file is correct.
> The test detailed description is available at DESCRIPTION.TXT file.
>
> Signed-off-by: Lukasz Majewski
> ---
> test/dfu/DESCRIPTION.TXT| 27 ++
This sounds like an important and useful test, but I have a few
comments (coming from someone with little knowledge of dfu)
Would README be a better name?
> test/dfu/dfu_gadget_test.sh | 86
> +++
> 2 files changed, 113 insertions(+)
> create mode 100644 test/dfu/DESCRIPTION.TXT
> create mode 100755 test/dfu/dfu_gadget_test.sh
>
> diff --git a/test/dfu/DESCRIPTION.TXT b/test/dfu/DESCRIPTION.TXT
> new file mode 100644
> index 000..48da06b
> --- /dev/null
> +++ b/test/dfu/DESCRIPTION.TXT
> @@ -0,0 +1,27 @@
> +DFU TEST CASE DESCRIPTION:
> +
> +For running test script one needs to create:
> +./log and ./bkp
> +
> +One also need to generate with dd following files:
> +
> +dat_*
> +
> +(e.g. dat_127B.img dat_128B.img dat_129B.img dat_33M.img dat_4095B.img
> +dat_4096B.img dat_4097B.img dat_63B.img dat_64B.img dat_65B.img
> +dat_960.img dat_97M.img)
How do you do that? Is this intended for use with a particular board?
I think you are missing some info here.
> +
> +The size is only important (so if=/dev/urandom), especially corner cases of
> +DFU EP0's size of packet (64B). This is very helpful for fixing UDC driver
> +regressions.
> +
> +Moreover on a target device the "dfu_alt_info" env variable should be
> extended
> +to have "dfu_test.bin fat 0 6;" \ entry [1].
What is [1] ?
> +One can use fat, ext4 or any other supported file system.
> +
> +As a prerequisite one must also create proper partition with file system on
> it.
> +
> +Example usage:
> +./dfu_gadget_test.sh 11
> +
> +where 11 is the mumber of alt setting corresponding to entry [1].
> \ No newline at end of file
I'm really none-the-wiser as to how this works - I think you need to
add a bit more detail.
> diff --git a/test/dfu/dfu_gadget_test.sh b/test/dfu/dfu_gadget_test.sh
> new file mode 100755
> index 000..ebde2ff
> --- /dev/null
> +++ b/test/dfu/dfu_gadget_test.sh
> @@ -0,0 +1,86 @@
> +#! /bin/bash
> +set -e # any command return not equal to zero
> +clear
> +
> +DIR=./
> +SUFFIX=img
> +RCV_DIR=rcv/
> +LOG_FILE=./log/log-`date +%d-%m-%Y_%H-%M-%S`
> +
> +cleanup () {
> +rm -rf $RCV_DIR
> +}
> +
> +die () {
> + printf " \33[31m FAILED \33[0m \n"
Perhaps define $RED or whatever at the top and use those here?
> + cleanup
> + exit 1
> +}
> +
> +calculate_md5sum () {
> +MD5SUM=`md5sum $1`
> +MD5SUM=`echo $MD5SUM | cut -d ' ' -f1`
> +echo "md5sum:"$MD5SUM
> +}
> +
> +dfu_test_file () {
I suggest putting the argument in a variable here, instead of using $1
throughout the function.
> +printf
> "\33[32m=
> \33[0m\n"
> +printf "File:\33[32m %s \33[0m\n" $1
> +
> +# dfu-util -D $1 -a $TARGET_ALT_SETTING > /dev/null 2>&1
Remove this line?
> +dfu-util -D $1 -a $TARGET_ALT_SETTING >> $LOG_FILE 2>&1 || die $?
> +
> +echo -n "TX: "
> +calculate_md5sum $1
> +
> +MD5_TX=$MD5SUM
> +
> +N_FILE=$DIR$RCV_DIR${1:2}"_rcv"
> +
> +# dfu-util -U $N_FILE -a $TARGET_ALT_SETTING > /dev/null 2>&1
And again
> +dfu-util -U $N_FILE -a $TARGET_ALT_SETTING >> $LOG_FILE 2>&1 || die $?
> +
> +echo -n "RX: "
> +calculate_md5sum $N_FILE
> +MD5_RX=$MD5SUM
> +
> +if [ "$MD5_TX" == "$MD5_RX" ]
> + then
> + printf " \33[32m ---> OK \33[0m \n"
> + else
outdent
> + printf " \33[31m ---> FAILED \33[0m \n"
> + cleanup
> + exit 1
> +fi
> +
> +#echo $N_FILE
> +}
> +
> +printf
> "\33[32m=
> \33[0m\n"
> +echo "DFU EP0 transmission test program"
> +echo "Trouble shoot -> disable DBG (even the KERN_DEBUG) in the UDC driver"
> +echo "@ -> TRATS # dfu mmc 0"
> +mkdir -p $RCV_DIR
> +touch $LOG_FILE
> +
> +if [ $# -eq 0 ]
> +then
> + printf " \33[31m Please pass alt setting number!! \33[0m \n"
> + exit 0
> +fi
> +
> +TARGET_ALT_SETTING=$1
> +
> +if [ -n "$2" ]
> +then
> + dfu_test_file $2
> +else
> + for file in $DIR*.$SUFFIX
> + do
> + dfu_test_file $file
> + done
> +fi
> +
> +cleanup
> +
> +exit 0
> \ No newline at end of file
Why not?
> --
> 1.7.10.4
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] fdt_support: delete unnecessary DECLARE_GLOBAL_DATA_PTR
On 17 April 2014 22:40, Masahiro Yamada wrote: > gd->bd is not used in fdt_support.c. > > Signed-off-by: Masahiro Yamada 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 v2 2/9] fdt_support: refactor with fdt_find_or_add_subnode helper func
Hi Masahiro,
On 17 April 2014 22:40, Masahiro Yamada wrote:
> Some functions in fdt_support.c do the same routine:
> search a node with a given name ("chosen", "memory", etc.)
> or newly create it if it does not exist.
>
> So this commit makes that routine to a helper function.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v2: None
>
> common/fdt_support.c | 71
> ++--
> 1 file changed, 36 insertions(+), 35 deletions(-)
>
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index 2464847..849bdc8 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
[snip]
> @@ -160,14 +185,10 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
> initrd_end, int force)
> const char *path;
> uint64_t addr, size;
>
> - /* Find the "chosen" node. */
> - nodeoffset = fdt_path_offset (fdt, "/chosen");
> -
> - /* If there is no "chosen" node in the blob return */
> - if (nodeoffset < 0) {
> - printf("fdt_initrd: %s\n", fdt_strerror(nodeoffset));
> + /* find or create "/chosen" node. */
> + nodeoffset = fdt_find_or_add_subnode(fdt, 0, "chosen");
> + if (nodeoffset < 0)
It looks like you are changing the behaviour here, but I think that is
fine. We should create it if it is missing.
Acked-by: Simon Glass
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/9] fdt_support: delete force argument of fdt_initrd()
On 17 April 2014 22:40, Masahiro Yamada wrote: > After all, we have realized "force" argument is completely > useless. fdt_initrd() was always called with force = 1. > > We should always want to do the same thing > (set appropriate value to the property) > even if the property already exists. > > Signed-off-by: Masahiro Yamada Acked-by: Simon Glass > --- > > Changes in v2: > - Rebase on commit 0f507779ca > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/9] fdt_support: delete force argument of fdt_chosen()
On 17 April 2014 22:41, Masahiro Yamada wrote: > After all, we have realized "force" argument is completely > useless. fdt_chosen() was always called with force = 1. > > We should always want to do the same thing > (set appropriate value to the property) > even if the property already exists. > > Signed-off-by: Masahiro Yamada Acked-by: Simon Glass > --- > > Changes in v2: None > > common/cmd_fdt.c | 2 +- > common/fdt_support.c | 38 -- > common/image-fdt.c| 2 +- > include/fdt_support.h | 2 +- > 4 files changed, 15 insertions(+), 29 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/9] fdt_support: refactor fdt_fixup_stdout() function
On 17 April 2014 22:41, Masahiro Yamada wrote: > - Do not use a deep indentation. We have only 80-character >on each line and 1 indentation consumes 8 spaces. Before the >code moves far to the right, you should consider to >fix your code. See Linux Documentation/CodingStyle. > > - Add CONFIG_OF_STDOUT_VIA_ALIAS and OF_STDOUT_PATH macros >only to their definition. Do not add them to both >callee and caller. This is a tip to avoid using #ifdef >everywhere. > > - OF_STDOUT_PATH and CONFIG_OF_STDOUT_VIA_ALIAS are exclusive. >If both are defined, the former takes precedence. >Do not try to fix-up "linux,stdout-path" property twice. > > Signed-off-by: Masahiro Yamada Acked-by: Simon Glass > --- > > Changes in v2: None > > common/fdt_support.c | 85 > ++-- > 1 file changed, 42 insertions(+), 43 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/9] fdt_support: add 'const' qualifier for unchanged argument
On 17 April 2014 22:41, Masahiro Yamada wrote: > In the next commit, I will add a new function, fdt_pack_reg() > which uses get_cells_len(). > > Beforehand, this commit adds 'const' qualifier to get_cells_len(). > Otherwise, a warning message will appear: > warning: passing argument 1 of 'get_cells_len' discards 'const' > qualifier from pointer target type [enabled by default] > > Signed-off-by: Masahiro Yamada Acked-by: Simon Glass > --- > > Changes in v2: > - Drop the period at the end of the commit subject > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/9] fdt_support: fix an endian bug of fdt_fixup_memory_banks
On 17 April 2014 22:41, Masahiro Yamada wrote: > Data written to DTB must be converted to big endian order. > It is usually done by using cpu_to_fdt32(), cpu_to_fdt64(), etc. > > fdt_fixup_memory_banks() invoked write_cell(), which always > swaps byte order. > It means the function only worked on little endian architectures. > > This commit adds and uses a new helper function, fdt_pack_reg(), > which works on both big endian and little endian architrectures. > > Signed-off-by: Masahiro Yamada Acked-by: Simon Glass > --- > > Changes in v2: None > > common/fdt_support.c | 42 ++ > 1 file changed, 30 insertions(+), 12 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/9] fdt_support: fix an endian bug of fdt_initrd()
On 17 April 2014 22:41, Masahiro Yamada wrote: > Data written to DTB must be converted to big endian order. > It is usually done by using cpu_to_fdt32(), cpu_to_fdt64(), etc. > > fdt_initrd() invoked write_cell(), which always swaps byte order. > It means the function only worked on little endian architectures. > (On big endian architectures, the byte order should be kept as it is) > > This commit uses cpu_to_fdt32() and cpu_to_fdt64() > and deletes write_cell(). > > Signed-off-by: Masahiro Yamada Acked-by: Simon Glass > --- > > Changes in v2: None > > common/fdt_support.c | 41 - > 1 file changed, 20 insertions(+), 21 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 9/9] fdt_support: correct the return condition of fdt_initrd()
On 17 April 2014 22:41, Masahiro Yamada wrote: > Before this commit, fdt_initrd() just returned if initrd > start address is zero. > But it is possible if the RAM is located at address 0. > > This commit makes the return condition more reasonable: > Just return if the size of initrd is zero. > > Signed-off-by: Masahiro Yamada Acked-by: Simon Glass > --- > > Changes in v2: None > > common/fdt_support.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] idirafter causes host sha256.h to be included
+Masahiro Hi Jeroen, On 9 May 2014 12:31, Jeroen Hofstee wrote: > Hello, > > tools/Makefile uses the following substitution > > HOST_EXTRACFLAGS += -include $(srctree)/include/libfdt_env.h \ > $(patsubst -I%,-idirafter%, $(UBOOTINCLUDE)) \ > ... > > Which adds -idirafterinclude when compiling image-fit.c. Since > mentioned file includes sha256.h, which is a system include on FreeBSD, > the system version is included instead of the intended U-boot > include/sha256.h and building fails. Without the substitution it builds > successfully. > > What is the intention of using idirafter? I believe this is so that U-Boot headers are available when building. You might need to add a work-around like we have for libfdt_env.h. It is also possible that there is a more general solution, sorry I'm not sure what it might be. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 03/13] sandbox: Support iotrace feature
Hi Rommel, On 12 May 2014 18:46, Rommel G Custodio wrote: > Dear Simon Glass, > > Simon Glass chromium.org> writes: > >> >> Support the iotrace feature for sandbox, and enable it, using some dummy >> I/O access methods. >> >> Signed-off-by: Simon Glass chromium.org> >> --- > > > >> >> diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h >> index fa62cb6..8ca2a55 100644 >> --- a/include/configs/sandbox.h >> +++ b/include/configs/sandbox.h >> -16,6 +16,9 >> >> #endif >> >> +#define CONFIG_IO_TRACE >> +#define CONFIG_CMD_IO_TRACE >> + > > s/CONFIG_CMD_IO_TRACE/CONFIG_CMD_IOTRACE/g Thanks - I didn't actually see your email - it's a good idea to keep the author in cc. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Extend 'bootm' to support Linux kernel generated images
Hi Tom, On 21 May 2014 10:46, Tom Rini wrote: > On Wed, May 21, 2014 at 10:10:50PM +0200, Wolfgang Denk wrote: >> Dear Tom Rini, >> >> In message <20140521195824.GE1752@bill-the-cat> you wrote: >> > >> > Something that Rob mentioned to me at ELC, and others have mentioned >> > before is that it would be nice if 'bootm' (which says "boot application >> > image stored in memory" in the help, even) would just work with zImage >> > or Image or whatever is spit directly out of the kernel. >> >> I don;t think this is a good idea. "application image" is supposed to >> mean "one of the U-Boot image formats", which means the old legacy >> image format (with the 64 byte header), or FIT images. To boot a >> zImage file, we have the "bootz" command. > > Yes, it's historically meant something with an essentially (technically > no, practically, yes) U-Boot centric header on it. But that's not what > the help text says. And yes we have bootz for zImages and I added booti > for Image images. That resulted in "You mean I have to type different > things for arm and arm64? *sigh*" when explaining this in person. > >> I also think such a patch is pushing into the wrong direction. We >> should rather try and improve the kernel support for FIT images. > > That's neither here nor there. You can create and boot FIT images > today, anywhere it's enabled (including arm64). You can do the same > with legacy images (which also resulted in sighs when I mentioned this). > The kernel doesn't want any of this in the kernel tree. Developers want > to have as few steps between "build my kernel" and "now I'm testing my > kernel". Adding in "create / grab stub FIT file, run mkimage" results > in more unhappy developers. Unless I'm imagining it, some years ago I could type 'make fit_image' or similar for the kernel and get an image ready to boot. Did someone remove that feature from Linux and expect the number of steps needed to build a kernel to stay the same? It surprises me the lengths to which people are going to try to shoehorn .dtbs, compression, multiple dtbs, multi-arch etc. into the kenel zImage format. The decompression header is ugly, plus it is slower than doing these things in U-Boot. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mkimage: path behavior for FIT images
Hi Yegor,
On 20 May 2014 20:59, Yegor Yefremov wrote:
> I have following folder structure:
>
> board/kernel_fdt.its
> output/images/zImage
>
> The kernel.its has following path for the zImage:
>
> data = /incbin/("output/images/zImage");
>
> When I invoke mkimage like this, it complains, that
> "output/images/zImage" doesn't exist:
>
> mkimage -f board/kernel_fdt.its output/images/kernel_fdt.itb
>
> in other words it seems to take zImage's relative path starting from
> "board", where kernel_fdt.its is located. Is it a desired behavior and
> how can I override it, so that root will be set to the mkimage
> invocation path?
You could put ../output/... in there perhaps.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] Fix a few problems with the command parsers
In a few cases the behaviour of both the hush and built-in parsers seems incorrect. One such case was exposed by commit 1992dbf which attempted to execute a simple command using hush and get the correct return value. Further digging exposed the other problems. Simon Glass (4): Add final result tests for run_command_list() Fix itest mask overflow Fix hush to give the correct return code for a simple command Correct return code from builtin_run_command_list() common/cmd_itest.c | 2 +- common/hush.c | 4 +++- common/main.c | 2 +- test/command_ut.c | 5 + 4 files changed, 10 insertions(+), 3 deletions(-) -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] Add final result tests for run_command_list()
run_command_list() is supposed to return a return code of 0 for success
and 1 for failure. Add a few simple tests that confirm this. These tests
work both with the built-in parser and hush.
Signed-off-by: Simon Glass
---
test/command_ut.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/test/command_ut.c b/test/command_ut.c
index aaa1ee2..b2666bf 100644
--- a/test/command_ut.c
+++ b/test/command_ut.c
@@ -61,6 +61,11 @@ static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
"setenv list ${list}3", strlen("setenv list 1"), 0);
assert(!strcmp("1", getenv("list")));
+ assert(run_command("false", 0) == 1);
+ assert(run_command("echo", 0) == 0);
+ assert(run_command_list("false", -1, 0) == 1);
+ assert(run_command_list("echo", -1, 0) == 0);
+
#ifdef CONFIG_SYS_HUSH_PARSER
/* Test the 'test' command */
--
1.9.1.423.g4596e3a
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] Correct return code from builtin_run_command_list()
The return code is not consistent with builtin_run_command_list(). For the last command in a sequence, the return code is actually inverted. Fix it. Signed-off-by: Simon Glass --- common/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/main.c b/common/main.c index 9bee7bd..e2350bd 100644 --- a/common/main.c +++ b/common/main.c @@ -1485,7 +1485,7 @@ static int builtin_run_command_list(char *cmd, int flag) ++next; } if (rcode == 0 && *line) - rcode = (builtin_run_command(line, 0) >= 0); + rcode = (builtin_run_command(line, 0) < 0); return rcode; } -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] Fix hush to give the correct return code for a simple command
When a simple command like 'false' is provided, hush should return the result of that command. However, hush only does this if the FLAG_EXIT_FROM_LOOP flag is provided. Without this flag, hush will happily execute the empty string command immediate after 'false' and then return a success code. This behaviour does not seem very useful, and requiring the flag also seems wrong, since it means that hush will execute only the first command in a sequence. Add a check for empty string and fall out of the loop in that case. That at least fixes the simple command case. This is a change in behaviour but it is unlikely that the old behaviour would be considered correct in any case. Reported-by: Stefan Herbrechtsmeier Signed-off-by: Simon Glass --- common/hush.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/common/hush.c b/common/hush.c index 5b43224..7a16795 100644 --- a/common/hush.c +++ b/common/hush.c @@ -3218,7 +3218,9 @@ static int parse_stream_outer(struct in_str *inp, int flag) free_pipe_list(ctx.list_head,0); } b_free(&temp); - } while (rcode != -1 && !(flag & FLAG_EXIT_FROM_LOOP)); /* loop on syntax errors, return on EOF */ + /* loop on syntax errors, return on EOF */ + } while (rcode != -1 && !(flag & FLAG_EXIT_FROM_LOOP) && + (inp->peek != static_peek || b_peek(inp))); #ifndef __U_BOOT__ return 0; #else -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] Fix itest mask overflow
The mask value used in itest overflows and therefore it can return an incorrect result for something like 'itest 0 == 1'. Fix it. Signed-off-by: Simon Glass --- common/cmd_itest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/cmd_itest.c b/common/cmd_itest.c index ae2527b..76af62b 100644 --- a/common/cmd_itest.c +++ b/common/cmd_itest.c @@ -63,7 +63,7 @@ static long evalexp(char *s, int w) l = simple_strtoul(s, NULL, 16); } - return (l & ((1 << (w * 8)) - 1)); + return l & ((1UL << (w * 8)) - 1); } static char * evalstr(char *s) -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
