Re: [U-Boot] [PATCH 1/2] usb, g_dnl: generalize DFU detach functions
Hi Rob,
> From: Rob Herring
>
> In order to add detach functions for fastboot, make the DFU detach
> related functions common so they can be shared.
>
> Signed-off-by: Rob Herring
> ---
> common/cmd_dfu.c | 6 +++---
> drivers/dfu/dfu.c | 16
> drivers/usb/gadget/f_dfu.c | 2 +-
> drivers/usb/gadget/g_dnl.c | 17 +
> include/dfu.h | 3 ---
> include/g_dnl.h| 4
> 6 files changed, 25 insertions(+), 23 deletions(-)
>
> diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c
> index 9e020b4..e975abe 100644
> --- a/common/cmd_dfu.c
> +++ b/common/cmd_dfu.c
> @@ -38,10 +38,10 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> int controller_index = simple_strtoul(usb_controller, NULL,
> 0); board_usb_init(controller_index, USB_INIT_DEVICE);
> - dfu_clear_detach();
> + g_dnl_clear_detach();
> g_dnl_register("usb_dnl_dfu");
> while (1) {
> - if (dfu_detach()) {
> + if (g_dnl_detach()) {
> /*
>* Check if USB bus reset is performed after
> detach,
>* which indicates that -R switch has been
> passed to @@ -74,7 +74,7 @@ done:
> if (dfu_reset)
> run_command("reset", 0);
>
> - dfu_clear_detach();
> + g_dnl_clear_detach();
>
> return ret;
> }
> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> index c0aba6e..a3e3ec5 100644
> --- a/drivers/dfu/dfu.c
> +++ b/drivers/dfu/dfu.c
> @@ -17,7 +17,6 @@
> #include
> #include
>
> -static bool dfu_detach_request;
> static LIST_HEAD(dfu_list);
> static int dfu_alt_num;
> static int alt_num_cnt;
> @@ -39,21 +38,6 @@ __weak bool dfu_usb_get_reset(void)
> return true;
> }
>
> -bool dfu_detach(void)
> -{
> - return dfu_detach_request;
> -}
> -
> -void dfu_trigger_detach(void)
> -{
> - dfu_detach_request = true;
> -}
> -
> -void dfu_clear_detach(void)
> -{
> - dfu_detach_request = false;
> -}
> -
> static int dfu_find_alt_num(const char *s)
> {
> int i = 0;
> diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
> index 16fc9dd..ead71eb 100644
> --- a/drivers/usb/gadget/f_dfu.c
> +++ b/drivers/usb/gadget/f_dfu.c
> @@ -366,7 +366,7 @@ static int state_dfu_idle(struct f_dfu *f_dfu,
> to_runtime_mode(f_dfu);
> f_dfu->dfu_state = DFU_STATE_appIDLE;
>
> - dfu_trigger_detach();
> + g_dnl_trigger_detach();
> break;
> default:
> f_dfu->dfu_state = DFU_STATE_dfuERROR;
> diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
> index 25611ac..ee52a29 100644
> --- a/drivers/usb/gadget/g_dnl.c
> +++ b/drivers/usb/gadget/g_dnl.c
> @@ -163,6 +163,23 @@ __weak int g_dnl_board_usb_cable_connected(void)
> return -EOPNOTSUPP;
> }
>
> +static bool g_dnl_detach_request;
> +
> +bool g_dnl_detach(void)
> +{
> + return g_dnl_detach_request;
> +}
> +
> +void g_dnl_trigger_detach(void)
> +{
> + g_dnl_detach_request = true;
> +}
> +
> +void g_dnl_clear_detach(void)
> +{
> + g_dnl_detach_request = false;
> +}
> +
> static int g_dnl_get_bcd_device_number(struct usb_composite_dev
> *cdev) {
> struct usb_gadget *gadget = cdev->gadget;
> diff --git a/include/dfu.h b/include/dfu.h
> index f1a71c7..c27856c 100644
> --- a/include/dfu.h
> +++ b/include/dfu.h
> @@ -150,9 +150,6 @@ struct dfu_entity *dfu_get_entity(int alt);
> char *dfu_extract_token(char** e, int *n);
> void dfu_trigger_reset(void);
> int dfu_get_alt(char *name);
> -bool dfu_detach(void);
> -void dfu_trigger_detach(void);
> -void dfu_clear_detach(void);
> int dfu_init_env_entities(char *interface, char *devstr);
> unsigned char *dfu_get_buf(struct dfu_entity *dfu);
> unsigned char *dfu_free_buf(void);
> diff --git a/include/g_dnl.h b/include/g_dnl.h
> index 1b1b35e..4eeb5e4 100644
> --- a/include/g_dnl.h
> +++ b/include/g_dnl.h
> @@ -39,4 +39,8 @@ int g_dnl_register(const char *s);
> void g_dnl_unregister(void);
> void g_dnl_set_serialnumber(char *);
>
> +bool g_dnl_detach(void);
> +void g_dnl_trigger_detach(void);
> +void g_dnl_clear_detach(void);
> +
> #endif /* __G_DOWNLOAD_H_ */
Acked-by: Lukasz Majewski
Tested-by: Lukasz Majewski
(Test HW: Trats2 board)
I will add this patch to u-boot-dfu tree.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] fastboot: add support for continue command
Hi Rob,
> From: Rob Herring
>
> The fastboot continue command is defined to exit fastboot and continue
> autoboot. This commit implements the continue command and the exiting
> of fastboot only. Subsequent u-boot commands can be processed after
> exiting fastboot. Autoboot should implement a boot script such as
> "fastboot; mmc read <...>; bootm" to fully implement the fastboot
> continue function.
>
> Signed-off-by: Rob Herring
> ---
> common/cmd_fastboot.c | 4
> drivers/usb/gadget/f_fastboot.c | 14 ++
> 2 files changed, 18 insertions(+)
>
> diff --git a/common/cmd_fastboot.c b/common/cmd_fastboot.c
> index 909616d..b72f4f3 100644
> --- a/common/cmd_fastboot.c
> +++ b/common/cmd_fastboot.c
> @@ -15,17 +15,21 @@ static int do_fastboot(cmd_tbl_t *cmdtp, int
> flag, int argc, char *const argv[]) {
> int ret;
>
> + g_dnl_clear_detach();
> ret = g_dnl_register("usb_dnl_fastboot");
> if (ret)
> return ret;
>
> while (1) {
> + if (g_dnl_detach())
> + break;
> if (ctrlc())
> break;
> usb_gadget_handle_interrupts();
> }
>
> g_dnl_unregister();
> + g_dnl_clear_detach();
> return CMD_RET_SUCCESS;
> }
>
> diff --git a/drivers/usb/gadget/f_fastboot.c
> b/drivers/usb/gadget/f_fastboot.c index 71b62e5..310175a 100644
> --- a/drivers/usb/gadget/f_fastboot.c
> +++ b/drivers/usb/gadget/f_fastboot.c
> @@ -480,6 +480,17 @@ static void cb_boot(struct usb_ep *ep, struct
> usb_request *req) fastboot_tx_write_str("OKAY");
> }
>
> +static void do_exit_on_complete(struct usb_ep *ep, struct
> usb_request *req) +{
> + g_dnl_trigger_detach();
> +}
> +
> +static void cb_continue(struct usb_ep *ep, struct usb_request *req)
> +{
> + fastboot_func->in_req->complete = do_exit_on_complete;
> + fastboot_tx_write_str("OKAY");
> +}
> +
> #ifdef CONFIG_FASTBOOT_FLASH
> static void cb_flash(struct usb_ep *ep, struct usb_request *req)
> {
> @@ -520,6 +531,9 @@ static const struct cmd_dispatch_info
> cmd_dispatch_info[] = { }, {
> .cmd = "boot",
> .cb = cb_boot,
> + }, {
> + .cmd = "continue",
> + .cb = cb_continue,
> },
> #ifdef CONFIG_FASTBOOT_FLASH
> {
Acked-by: Lukasz Majewski
Tested-by: Lukasz Majewski
(Test HW: Trats2 board)
I will add this patch to u-boot-dfu tree.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] VEXPRESS64 ARMv8 U-Boot maintenance
Hi folks (David & Steve listed as AArch64/v8 maintainers), are you actively maintaining and reviewing ARM64 board patches? I am working on support for the ARM Juno Development Platform real hardware, which is now up and running on my desk. I will add this board with myself as maintainer. But who takes care of the code in arch/arm/cpu/armv8? I have some questions about the rendez-vous code in the armv8 start.S file, as if two CPUs (master & slave) would come running into U-Boot, which is not what ARM Trusted Firmware does, it arrives only on the master CPU. Can any of you explain why that code is there? Else I will start looking at it and add myself as maintainer for this. Please also have a look at my patches to the Semihosting code: http://patchwork.ozlabs.org/patch/412628/ http://patchwork.ozlabs.org/patch/412629/ http://patchwork.ozlabs.org/patch/412630/ Yours, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/19] lib: errno: introduce errno_str(): returns errno related message
Hello Simon, On 12/11/2014 04:25 AM, Simon Glass wrote: On 22 October 2014 at 09:31, Tom Rini wrote: On Wed, Oct 08, 2014 at 10:48:37PM +0200, Przemyslaw Marczak wrote: The functions error's numbers are standarized - but the error messages are not. The errors are often handled with unclear error messages, so why not use an errno standarized messages. Advantages: - This could decrease the binary size. - Appended with a detailed information, the error message will be clear. This commit introduces new function: - const char *errno_to_str(int errno) The functions returns a pointer to the errno corresponding text message: - if errno is null or positive number - a pointer to "Success" message - if errno is negative - a pointer to errno related message Signed-off-by: Przemyslaw Marczak In and of itself, Reviewed-by: Tom Rini Applied to u-boot-dm, thanks! - Simon Thank, maybe today or tomorrow I will send the I2C for exynos and next I can continue work on pmic. Best regards, -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] fastboot: handle flash write to GPT partition
Hi Steve,
> Hi Lukasz,
>
> On 14-12-09 01:05 AM, Lukasz Majewski wrote:
> > Hi Steve,
> >
> >> Implement a feature to allow fastboot to write the downloaded image
> >> to the space reserved for the Protective MBR and the Primary GUID
> >> Partition Table.
> >>
> >> Signed-off-by: Steve Rae
> >> ---
> >>
> >> Changes in v2:
> >> add validation of the GPT before writing to flash
> >> (suggested by: Lukasz Majewski )
> >>
> >> README | 7 +++
> >> common/fb_mmc.c | 26 +++---
> >> disk/part_efi.c | 37 +
> >> include/part.h | 10 ++
> >> 4 files changed, 77 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/README b/README
> >> index 4ca04d0..5f50cdd 100644
> >> --- a/README
> >> +++ b/README
> >> @@ -1773,6 +1773,13 @@ The following options need to be configured:
> >>regarding the non-volatile storage device. Define
> >> this to the eMMC device that fastboot should use to store the
> >> image.
> >>
> >> + CONFIG_FASTBOOT_GPT_NAME
> >> + The fastboot "flash" command supports writing the
> >> downloaded
> >> + image to the Protective MBR and the Primary GUID
> >> Partition
> >> + Table. This occurs when the specified "partition
> >> name" on the
> >> + "fastboot flash" command line matches this value.
> >> + Default is GPT_ENTRY_NAME (currently "gpt") if
> >> undefined. +
> >> - Journaling Flash filesystem support:
> >>CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF,
> >> CONFIG_JFFS2_NAND_SIZE, CONFIG_JFFS2_NAND_DEV
> >> diff --git a/common/fb_mmc.c b/common/fb_mmc.c
> >> index fb06d8a..a646a7b 100644
> >> --- a/common/fb_mmc.c
> >> +++ b/common/fb_mmc.c
> >> @@ -4,12 +4,17 @@
> >>* SPDX-License-Identifier: GPL-2.0+
> >>*/
> >>
> >> +#include
> >> #include
> >> #include
> >> #include
> >> #include
> >> #include
> >>
> >> +#ifndef CONFIG_FASTBOOT_GPT_NAME
> >> +#define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
> >> +#endif
> >> +
> >> /* The 64 defined bytes plus the '\0' */
> >> #define RESPONSE_LEN (64 + 1)
> >>
> >> @@ -62,9 +67,9 @@ static void write_raw_image(block_dev_desc_t
> >> *dev_desc, disk_partition_t *info, void fb_mmc_flash_write(const
> >> char *cmd, void *download_buffer, unsigned int download_bytes, char
> >> *response) {
> >> - int ret;
> >>block_dev_desc_t *dev_desc;
> >>disk_partition_t info;
> >> + lbaint_t blksz;
> >>
> >>/* initialize the response buffer */
> >>response_str = response;
> >> @@ -76,8 +81,23 @@ void fb_mmc_flash_write(const char *cmd, void
> >> *download_buffer, return;
> >>}
> >>
> >> - ret = get_partition_info_efi_by_name(dev_desc, cmd,
> >> &info);
> >> - if (ret) {
> >> + if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
> >> + printf("%s: updating GUID Partition Table
> >> (including MBR)\n",
> >> + __func__);
> >> + /* start at Protective MBR */
> >> + info.start = (GPT_PRIMARY_PARTITION_TABLE_LBA -
> >> 1);
> >> + blksz = dev_desc->blksz;
> >> + info.blksz = blksz;
> >> + /* assume that the Partition Entry Array starts in
> >> LBA 2 */
> >> + info.size = (2 + (GPT_ENTRY_NUMBERS *
> >> GPT_ENTRY_SIZE) / blksz); +
> >> + if (is_valid_gpt_primary(download_buffer,
> >> dev_desc->blksz)) {
> >> + printf("%s: invalid GPT - refusing to
> >> write to flash\n",
> >> + __func__);
> >> + fastboot_fail("invalid GPT partition");
> >> + return;
> >> + }
> >
> > IMHO some extra code to update secondary (backup) GPT is needed
> > here.
> >
> > A good example may be at part_efi.c - print_part_efi() function [1].
> >
>
> OK -- added "prepare and write Backup GPT" in v3
>
> >> + } else if (get_partition_info_efi_by_name(dev_desc, cmd,
> >> &info)) { error("cannot find partition: '%s'\n", cmd);
> >>fastboot_fail("cannot find partition");
> >>return;
> >> diff --git a/disk/part_efi.c b/disk/part_efi.c
> >> index efed58f..86cb160 100644
> >> --- a/disk/part_efi.c
> >> +++ b/disk/part_efi.c
> >> @@ -455,6 +455,43 @@ err:
> >>free(gpt_h);
> >>return ret;
> >> }
> >> +
> >> +int is_valid_gpt_primary(void *buf, unsigned long blksz)
> >
> > The name is a bit misleading - I rather though about something like
> > is_valid_gpt_buf() and write it in a similar way to is_valid_gpt()
> > which would allow using it for both primary and secondary GPTs
> > (like in [1]).
>
> OK - I changed the name, however, it still can only handle a buffer
> which contains:
> - 512 bytes of MBR, followed by
> - 512 bytes of GPT Header, followed by
> the GPT Entries at the specified offset (typically 2 * 512 bytes)
> Thus, it cannot be used for the Backup GPT anyway
I think that it should be possible to reuse the code:
1. There is "is_pmbr_valid()" function @ part_efi.c - so you don't n
Re: [U-Boot] [PATCH v3] fastboot: handle flash write to GPT partitions
Hi Steve,
> Implement a feature to allow fastboot to write the downloaded image
> to the space reserved for the Protective MBR and the Primary GUID
> Partition Table.
> Additionally, prepare and write the Backup GUID Partition Table.
>
> Signed-off-by: Steve Rae
> ---
>
> Changes in v3:
> - prefer leXX_to_cpu() over cpu_to_leXX()
> - enhance calculation of pointer to GPT Entries
> - prepare and write the Backup GPT
>(requested by: Lukasz Majewski )
>
> Changes in v2:
> add validation of the GPT before writing to flash
> (suggested by: Lukasz Majewski )
>
> README | 9 +
> common/fb_mmc.c | 26 --
> disk/part_efi.c | 107
>
> include/part.h | 20 +++ 4 files changed, 159 insertions(+),
> 3 deletions(-)
>
> diff --git a/README b/README
> index 4ca04d0..42ece99 100644
> --- a/README
> +++ b/README
> @@ -1773,6 +1773,15 @@ The following options need to be configured:
> regarding the non-volatile storage device. Define
> this to the eMMC device that fastboot should use to store the image.
>
> + CONFIG_FASTBOOT_GPT_NAME
> + The fastboot "flash" command supports writing the
> downloaded
> + image to the Protective MBR and the Primary GUID
> Partition
> + Table. (Additionally, this downloaded image is
> post-processed
> + to generate and write the Backup GUID Partition
> Table.)
> + This occurs when the specified "partition name" on
> the
> + "fastboot flash" command line matches this value.
> + Default is GPT_ENTRY_NAME (currently "gpt") if
> undefined. +
> - Journaling Flash filesystem support:
> CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF,
> CONFIG_JFFS2_NAND_SIZE, CONFIG_JFFS2_NAND_DEV
> diff --git a/common/fb_mmc.c b/common/fb_mmc.c
> index fb06d8a..5acc8df 100644
> --- a/common/fb_mmc.c
> +++ b/common/fb_mmc.c
> @@ -4,12 +4,17 @@
> * SPDX-License-Identifier: GPL-2.0+
> */
>
> +#include
> #include
> #include
> #include
> #include
> #include
>
> +#ifndef CONFIG_FASTBOOT_GPT_NAME
> +#define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
> +#endif
> +
> /* The 64 defined bytes plus the '\0' */
> #define RESPONSE_LEN (64 + 1)
>
> @@ -62,7 +67,6 @@ static void write_raw_image(block_dev_desc_t
> *dev_desc, disk_partition_t *info, void fb_mmc_flash_write(const char
> *cmd, void *download_buffer, unsigned int download_bytes, char
> *response) {
> - int ret;
> block_dev_desc_t *dev_desc;
> disk_partition_t info;
>
> @@ -76,8 +80,24 @@ void fb_mmc_flash_write(const char *cmd, void
> *download_buffer, return;
> }
>
> - ret = get_partition_info_efi_by_name(dev_desc, cmd, &info);
> - if (ret) {
> + if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
> + printf("%s: updating MBR, Primary and Backup
> GPT(s)\n",
> +__func__);
> + if (is_valid_gpt_buf(download_buffer,
> dev_desc->blksz)) {
> + printf("%s: invalid GPT - refusing to write
> to flash\n",
> +__func__);
> + fastboot_fail("invalid GPT partition");
> + return;
> + }
> + if (write_mbr_and_gpt_partitions(dev_desc,
> download_buffer)) {
> + printf("%s: writing GPT partitions
> failed\n", __func__);
> + fastboot_fail("writing GPT partitions
> failed");
> + return;
> + }
> + printf(" success\n");
> + fastboot_okay("");
> + return;
> + } else if (get_partition_info_efi_by_name(dev_desc, cmd,
> &info)) { error("cannot find partition: '%s'\n", cmd);
> fastboot_fail("cannot find partition");
> return;
> diff --git a/disk/part_efi.c b/disk/part_efi.c
> index efed58f..9cc04da 100644
> --- a/disk/part_efi.c
> +++ b/disk/part_efi.c
> @@ -455,6 +455,113 @@ err:
> free(gpt_h);
> return ret;
> }
> +
> +int is_valid_gpt_buf(void *buf, unsigned long blksz)
Please see my comment to v2 regarding this function.
> +{
> + int rc = 0;
> + gpt_header *gpt_h;
> + gpt_entry *gpt_e;
> + gpt_header gpt_hdr;
> + uint32_t calc_crc32;
> +
> + /* GPT Header starts at "LBA[1]" in the buffer */
> + gpt_h = buf + blksz;
> + if (le64_to_cpu(gpt_h->signature) != GPT_HEADER_SIGNATURE) {
> + printf("%s: 'signature' is invalid\n", __func__);
> + return -1;
> + }
> +
> + memcpy(&gpt_hdr, gpt_h, sizeof(gpt_header));
> + gpt_hdr.header_crc32 = 0;
> + calc_crc32 = efi_crc32((const unsigned char *)&gpt_hdr,
> +le32_to_cpu(gpt_h->header_size));
> + if (le32_to_cpu(gpt_h->header_crc32) != calc_crc32) {
> + printf("%s: 'header_crc32' is invalid\n", __func__);
> + rc += 1;
> + }
> +
> + /*
[U-Boot] [PATCH] mtd: nand: revive "nand scrub" command
Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14),
the "nand scrub" command has not been working.
The scrub is a U-Boot extension and we have to modify nand_base.c
that originates in Linux.
Mark the code with #ifdef __UBOOT__ so we will never accidentally
drop it when we re-sync the NAND framework with Linux in the future.
Signed-off-by: Masahiro Yamada
Cc: Scott Wood
Cc: Heiko Schocher
---
drivers/mtd/nand/nand_base.c | 5 +
include/linux/mtd/mtd.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 70e780c..83bd033 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2905,8 +2905,13 @@ int nand_erase_nand(struct mtd_info *mtd, struct
erase_info *instr,
WATCHDOG_RESET();
/* Check if we have a bad block, we do not erase bad blocks! */
+#ifdef __UBOOT__
+ if (!instr->scrub && nand_block_checkbad(mtd, ((loff_t) page) <<
+ chip->page_shift, 0, allowbbt)) {
+#else
if (nand_block_checkbad(mtd, ((loff_t) page) <<
chip->page_shift, 0, allowbbt)) {
+#endif
pr_warn("%s: attempt to erase a bad block at page
0x%08x\n",
__func__, page);
instr->state = MTD_ERASE_FAILED;
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 8666413..2b4e218 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -52,7 +52,9 @@ struct erase_info {
u_long priv;
u_char state;
struct erase_info *next;
+#ifdef __UBOOT__
int scrub;
+#endif
};
struct mtd_erase_region_info {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] watchdog not resetting beaglebone after timeout period
Hi, I'm using latest u-boot master (9b416a9f4ca7cf5ac4d5f7143d67edde7f7d7326) running on beaglebone (white). This board has watchdog enabled by default for 60 secs timeout but in my case it's not resetting board after that amount of time. I did check watchdog registers: U-Boot# md.l 0x44e35000 30 44e35000: 502a0501 ..*P 44e35010: 0010 0001 44e35020: 0020 ffe2005e ffe2 ...^... 44e35030: edcb 44e35040: DD.. 44e35050: and it seems value in register WDT_WCRR doesn't increment -> it could mean that 32kHz clock isn't working? Any other ideas what to check? Thanks. BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] gadget: f_thor: check pointers before use in download_tail()
Some pointers in function download_tail() were not checked
before the use. This could possibly cause the data abort.
To avoid this, check if the pointers are not null is added.
Signed-off-by: Przemyslaw Marczak
---
drivers/usb/gadget/f_thor.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index 78519fa..9f77ba6 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -205,12 +205,24 @@ static long long int download_head(unsigned long long
total,
static int download_tail(long long int left, int cnt)
{
- struct dfu_entity *dfu_entity = dfu_get_entity(alt_setting_num);
- void *transfer_buffer = dfu_get_buf(dfu_entity);
+ struct dfu_entity *dfu_entity;
+ void *transfer_buffer;
int ret;
debug("%s: left: %llu cnt: %d\n", __func__, left, cnt);
+ dfu_entity = dfu_get_entity(alt_setting_num);
+ if (!dfu_entity) {
+ printf("Alt setting: %d entity not found!\n", alt_setting_num);
+ return -ENOENT;
+ }
+
+ transfer_buffer = dfu_get_buf(dfu_entity);
+ if (!transfer_buffer) {
+ error("Transfer buffer not allocated!");
+ return -ENXIO;
+ }
+
if (left) {
ret = dfu_write(dfu_entity, transfer_buffer, left, cnt++);
if (ret) {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] dfu: mmc: check if mmc device exists in mmc_block_op()
The function mmc_block_op() is the last function before
the physicall data write, but the mmc device pointer is not
checked. If mmc device not exists, then data abort will occur.
To avoid this, first the mmc device pointer is checked.
Signed-off-by: Przemyslaw Marczak
---
drivers/dfu/dfu_mmc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 72fa03e..41ac188 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -40,10 +40,16 @@ static int mmc_access_part(struct dfu_entity *dfu, struct
mmc *mmc, int part)
static int mmc_block_op(enum dfu_op op, struct dfu_entity *dfu,
u64 offset, void *buf, long *len)
{
- struct mmc *mmc = find_mmc_device(dfu->data.mmc.dev_num);
+ struct mmc *mmc;
u32 blk_start, blk_count, n = 0;
int ret, part_num_bkp = 0;
+ mmc = find_mmc_device(dfu->data.mmc.dev_num);
+ if (!mmc) {
+ printf("Device MMC %d - not found!", dfu->data.mmc.dev_num);
+ return -ENODEV;
+ }
+
/*
* We must ensure that we work in lba_blk_size chunks, so ALIGN
* this value.
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Controlling write protect pin on SPI flash
Hello, Is there, or is anyone working on, code for controlling the write protect pin of SPI flash devices using a GPIO? In effect an "sf protect " command? I have had a look in 2014.07 which is on the platform we are using but can't see anything. Thanks, Andy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
The present fat implementation ignores FAT16 long name
directory entries which aren't placed in a single sector.
This was becouse of the buffer was always filled by the
two sectors, and the loop was made also for two sectors.
If some file long name entries are stored in two sectors,
the we have two cases:
Case 1:
Both of sectors are in the buffer - all required data
for long file name is in the buffer.
- Read OK!
Case 2:
The current directory entry is placed at the end of the
second buffered sector. And the next entries are placed
in a sector which is not buffered yet. Then two next
sectors are buffered and the mentioned entry is ignored.
- Read fail!
This commit fixes this issue by:
- read two sectors after loop on each single is done
- keep the last used sector as a first in the buffer
before the read of two next
The commit doesn't affects the fat32 imlementation,
which works good as previous.
Signed-off-by: Przemyslaw Marczak
Cc: Mikhail Zolotaryov
Cc: Tom Rini
Cc: Stephen Warren
Cc: Simon Glass
Cc: Suriyan Ramasami
Cc: Lukasz Majewski
Cc: Wolfgang Denk
---
fs/fat/fat.c | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 04a51db..afbf12d 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -823,8 +823,11 @@ int do_fat_read_at(const char *filename, loff_t pos, void
*buffer,
int ret = -1;
int firsttime;
__u32 root_cluster = 0;
+ __u32 read_blk;
int rootdir_size = 0;
- int j;
+ int j, k;
+ int do_read;
+ __u8 *dir_ptr;
if (read_bootsectandvi(&bs, &volinfo, &mydata->fatsize)) {
debug("Error: reading boot sector\n");
@@ -910,23 +913,35 @@ int do_fat_read_at(const char *filename, loff_t pos, void
*buffer,
}
j = 0;
+ k = 0;
while (1) {
int i;
- if (j == 0) {
+ if (mydata->fatsize == 32 || !k) {
+ dir_ptr = do_fat_read_at_block;
+ k = 1;
+ } else {
+ dir_ptr = (do_fat_read_at_block + mydata->sect_size);
+ memcpy(do_fat_read_at_block, dir_ptr,
mydata->sect_size);
+ }
+
+ do_read = 1;
+
+ if (mydata->fatsize == 32 && j)
+ do_read = 0;
+
+ if (do_read) {
debug("FAT read sect=%d, clust_size=%d,
DIRENTSPERBLOCK=%zd\n",
cursect, mydata->clust_size, DIRENTSPERBLOCK);
- if (disk_read(cursect,
- (mydata->fatsize == 32) ?
- (mydata->clust_size) :
- PREFETCH_BLOCKS,
- do_fat_read_at_block) < 0) {
+ read_blk = (mydata->fatsize == 32) ?
+ mydata->clust_size : PREFETCH_BLOCKS;
+ if (disk_read(cursect, read_blk, dir_ptr) < 0) {
debug("Error: reading rootdir block\n");
goto exit;
}
- dentptr = (dir_entry *) do_fat_read_at_block;
+ dentptr = (dir_entry *)dir_ptr;
}
for (i = 0; i < DIRENTSPERBLOCK; i++) {
@@ -951,7 +966,7 @@ int do_fat_read_at(const char *filename, loff_t pos, void
*buffer,
get_vfatname(mydata,
root_cluster,
-do_fat_read_at_block,
+dir_ptr,
dentptr, l_name);
if (dols == LS_ROOT) {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 02/11] dm: i2c: Implement driver model support in the i2c command
On 10 December 2014 at 08:55, Simon Glass wrote: > The concept of a 'current bus' is now implemented in the command line > rather than in the uclass. Also the address length does not need to > be specified with each command - really we should consider dropping > this from most commands but it works OK for now. > > Signed-off-by: Simon Glass > Acked-by: Heiko Schocher > Reviewed-by: Masahiro Yamada > --- > > Changes in v6: None > Changes in v5: None > Changes in v4: > - Update call to i2c_probe() > > Changes in v3: > - Add new 'i2c flags' command to get/set chip flags > - Adjust for slightly altered I2C uclass API > > Changes in v2: > - Call the deblock() method for 'i2c reset' > - Change alen to int so that it can be -1 (this was a bug) > > common/cmd_i2c.c | 376 > +++ > 1 file changed, 323 insertions(+), 53 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 01/11] dm: i2c: Add a uclass for I2C
On 10 December 2014 at 08:55, Simon Glass wrote: > The uclass implements the same operations as the current I2C framework but > makes some changes to make it fit driver model better: > > - Remove the chip address from API calls > - Remove the address length from API calls > - Remove concept of 'current' I2C bus > - Drop all existing init functions > > Acked-by: Heiko Schocher > Reviewed-by: Masahiro Yamada > Signed-off-by: Simon Glass > --- > > Changes in v6: None > Changes in v5: > - Add a function comment for i2c_probe_chip() > - Add an assert for offset_len in i2c_setup_offset() > - Add more detail to return value comment on get_buf_speed() > - Add more detail to return value comment on xfer() method > - Fix -INVAL typo > - Make i2c_get_bus_speed() independent of i2c_set_bus_speed() > - Split DM_I2C_CHIP_RD_ADDRESS into read and write varaints > - Update comments in struct i2c_msg to allow buf to be NULL > - Use a NULL buffer in i2c_probe_chip() > > Changes in v4: > - Add a constant for I2C_MAX_OFFSET_LEN > - Add a probe_chip() method to the uclass > - Add chip flags to i2c_probe() > - Add comment to i2c_setup_offset() > - Add comments to indicate which methods are optional > - Add comments to set_bus_speed() method > - Adjust i2c_bind_driver() to avoid calloc()/free() > - Drop set_offset_len() method > - Fix copying of chip flags to message in i2c_setup_offset() > - Fix endianness of i2c_setup_offset() > - Fix method comment for xfer() > - Invert return value of i2c_setup_offset() > - Probe with a message length of 0 > - Rename i2c_generic_drv to i2c_generic_chip_drv > - Rename i2c_read_bytewise() and implement a real one > > Changes in v3: > - Add a helper to query chip flags > - Add support for reading a byte at a time with an address for each byte > - Change uclass <=> driver API to use a message list > - Correct bogus address len code (was confused with chip address length) > - Drop extra call to i2c_bind_driver() in i2c_probe() > > Changes in v2: > - Add a 'deblock' method to recover an I2C bus stuck in mid-transaction > - Add a helper function to find a chip on a particular bus number > - Add some debugging for generic I2C device binding > - Fix cihp typo > - Implement generic I2C devices to allow 'i2c probe' on unknown devices > - Return the probed device from i2c_probe() > - Set the bus speed after the bus is probed > > drivers/i2c/Makefile | 1 + > drivers/i2c/i2c-uclass.c | 466 > + > include/config_fallbacks.h | 6 + > include/dm/uclass-id.h | 2 + > include/i2c.h | 352 ++ > 5 files changed, 827 insertions(+) > create mode 100644 drivers/i2c/i2c-uclass.c Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 03/11] dm: i2c: Add I2C emulation driver for sandbox
On 10 December 2014 at 08:55, Simon Glass wrote: > In order to test I2C we need some sort of emulation interface. Add hooks > to allow a driver to emulate an I2C device for sandbox. > > Signed-off-by: Simon Glass > Acked-by: Heiko Schocher > Reviewed-by: Masahiro Yamada > --- > > Changes in v6: None > Changes in v5: None > Changes in v4: None > Changes in v3: None > Changes in v2: None > > drivers/i2c/Makefile | 1 + > drivers/i2c/i2c-emul-uclass.c | 14 ++ > include/dm/uclass-id.h| 1 + > 3 files changed, 16 insertions(+) > create mode 100644 drivers/i2c/i2c-emul-uclass.c > Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 09/11] dm: i2c: Add tests for I2C
On 10 December 2014 at 08:55, Simon Glass wrote: > Add some basic tests to check that the system works as expected. > > Signed-off-by: Simon Glass > Acked-by: Heiko Schocher > --- > > Changes in v6: None > Changes in v5: > - Adjust tests for DM_I2C_CHIP_RE_ADDRESS split > > Changes in v4: > - Add an assert for non-null > - Add tests for offset length > - Adjust tests to match uclass changes > > Changes in v3: > - Update for new uclass <=> emulateor interface > > Changes in v2: > - Add a new asm/test.h header for tests in sandbox > - Add a test for automatic binding of generic I2C devices > > include/dm/ut.h | 12 > test/dm/Makefile | 1 + > test/dm/i2c.c| 216 > +++ > test/dm/test.dts | 17 + > 4 files changed, 246 insertions(+) > create mode 100644 test/dm/i2c.c > Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 04/11] dm: i2c: Add a sandbox I2C driver
On 10 December 2014 at 08:55, Simon Glass wrote: > This driver includes some test features such as only supporting certain > bus speeds. It passes its I2C traffic through to an emulator. > > Acked-by: Heiko Schocher > Signed-off-by: Simon Glass > --- > > Changes in v6: > - Drop a stale comment > - Pass value from i2c_get_chip() to get_emul() > - Use dm_scan_fdt_node() to find emulator Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 08/11] dm: Add a simple EEPROM driver
On 10 December 2014 at 08:55, Simon Glass wrote: > There seem to be a few EEPROM drivers around - perhaps we should have a > single standard one? This simple driver is used for sandbox testing, but > could be pressed into more active service. > > Signed-off-by: Simon Glass > Acked-by: Heiko Schocher > Reviewed-by: Masahiro Yamada > --- > > Changes in v6: None > Changes in v5: None > Changes in v4: None > Changes in v3: None > Changes in v2: > - Update commit message for EEPROM driver > > drivers/misc/Makefile | 1 + > drivers/misc/i2c_eeprom.c | 51 > +++ > include/dm/uclass-id.h| 1 + > include/i2c_eeprom.h | 19 ++ > 4 files changed, 72 insertions(+) > create mode 100644 drivers/misc/i2c_eeprom.c > create mode 100644 include/i2c_eeprom.h Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 07/11] dm: i2c: dts: Add an I2C bus for sandbox
On 10 December 2014 at 08:55, Simon Glass wrote: > Add an I2C bus to the device tree, with an EEPROM emulator attached to one > of the addresses. > > Signed-off-by: Simon Glass > Acked-by: Heiko Schocher > Reviewed-by: Masahiro Yamada > --- > > Changes in v6: None > Changes in v5: None > Changes in v4: None > Changes in v3: None > Changes in v2: None > > arch/sandbox/dts/sandbox.dts | 17 + > 1 file changed, 17 insertions(+) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 05/11] dm: i2c: Add an I2C EEPROM simulator
On 10 December 2014 at 17:54, Masahiro Yamada wrote: > > On Wed, 10 Dec 2014 08:55:51 -0700 > Simon Glass wrote: > >> To enable testing of I2C, add a simple I2C EEPROM simulator for sandbox. >> It supports reading and writing from a small data store. >> >> Signed-off-by: Simon Glass >> Acked-by: Heiko Schocher >> --- >> >> Changes in v6: >> - Drop the probe_chip() method which is not needed > > > > Reviewed-by: Masahiro Yamada > > Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 06/11] dm: i2c: config: Enable I2C for sandbox using driver model
On 10 December 2014 at 08:55, Simon Glass wrote: > Enable the options to bring up I2C on sandbox. Also enable all the available > I2C commands for testing purposes. > > Signed-off-by: Simon Glass > Acked-by: Heiko Schocher Applied to u-boot-dm. > --- > > Changes in v6: None > Changes in v5: None > Changes in v4: None > Changes in v3: None > Changes in v2: None > > include/configs/sandbox.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h > index 2b03841..657f751 100644 > --- a/include/configs/sandbox.h > +++ b/include/configs/sandbox.h > @@ -112,6 +112,12 @@ > #define CONFIG_SPI_FLASH_STMICRO > #define CONFIG_SPI_FLASH_WINBOND > > +#define CONFIG_DM_I2C > +#define CONFIG_CMD_I2C > +#define CONFIG_SYS_I2C_SANDBOX > +#define CONFIG_I2C_EDID > +#define CONFIG_I2C_EEPROM > + > /* Memory things - we don't really want a memory test */ > #define CONFIG_SYS_LOAD_ADDR 0x > #define CONFIG_SYS_MEMTEST_START 0x0010 > -- > 2.2.0.rc0.207.ga3a616c > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 10/11] dm: device: Add newline to debug() messages
On 10 December 2014 at 08:55, Simon Glass wrote: > Some of these are missing a newline. Add it. > > Signed-off-by: Simon Glass > --- > > Changes in v6: None > Changes in v5: None > Changes in v4: > - Add new patch to add newline to debug() messages > > Changes in v3: None > Changes in v2: None > > drivers/core/device.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/19] lib: errno: introduce errno_str(): returns errno related message
Hi Przemyslaw, On 11 December 2014 at 03:11, Przemyslaw Marczak wrote: > Hello Simon, > > > On 12/11/2014 04:25 AM, Simon Glass wrote: >> >> On 22 October 2014 at 09:31, Tom Rini wrote: >>> >>> On Wed, Oct 08, 2014 at 10:48:37PM +0200, Przemyslaw Marczak wrote: >>> The functions error's numbers are standarized - but the error messages are not. The errors are often handled with unclear error messages, so why not use an errno standarized messages. Advantages: - This could decrease the binary size. - Appended with a detailed information, the error message will be clear. This commit introduces new function: - const char *errno_to_str(int errno) The functions returns a pointer to the errno corresponding text message: - if errno is null or positive number - a pointer to "Success" message - if errno is negative - a pointer to errno related message Signed-off-by: Przemyslaw Marczak >>> >>> >>> In and of itself, >>> >>> Reviewed-by: Tom Rini >> >> >> Applied to u-boot-dm, thanks! >> >> - Simon >> > > Thank, maybe today or tomorrow I will send the I2C for exynos and next I can > continue work on pmic. OK sounds good. I've pushed DM I2C things to dm/master, although not Tegra yet while I wait on the nyan-big patch. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/3] ARM: tegra: Add support for nyan-big board
Hi Tom, On 10 December 2014 at 14:45, Simon Glass wrote: > > Hi Tom, > > On 10 December 2014 at 14:09, Tom Warren wrote: > > Simon, > > > >> -Original Message- > >> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass > >> Sent: Wednesday, December 10, 2014 2:04 PM > >> To: Tom Warren > >> Cc: U-Boot Mailing List; Stephen Warren; Allen Martin; Stephen Warren; > >> Albert Aribaud > >> Subject: Re: [PATCH v5 3/3] ARM: tegra: Add support for nyan-big board > >> > >> Hi Tom, > >> > >> On 10 December 2014 at 12:36, Simon Glass wrote: > >> > Hi Tom, > >> > > >> > On Dec 10, 2014 12:05 PM, "Tom Warren" wrote: > >> >> > >> >> Simon, > >> >> > >> >> > -Original Message- > >> >> > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon > >> >> > Glass > >> >> > Sent: Wednesday, December 10, 2014 10:50 AM > >> >> > To: Tom Warren > >> >> > Cc: U-Boot Mailing List; Allen Martin; Albert Aribaud; Stephen > >> >> > Warren; Stephen Warren > >> >> > Subject: Re: [PATCH v5 3/3] ARM: tegra: Add support for nyan-big > >> >> > board > >> >> > > >> >> > Hi Tom, > >> >> > > >> >> > > >> >> > On 10 December 2014 at 10:39, Tom Warren > >> wrote: > >> >> > > Simon, > >> >> > > > >> >> > > The v4 PCIE patch series fails to apply to u-boot-tegra/master > >> >> > > after > >> >> > rebasing my repo against both ARM master and U-Boot 'master' master > >> >> > (i.e. > >> >> > FETCH_HEAD = > >> >> > > 32fdf0e4d82bdca5d64d86330e461e59685f9959branch 'master' of > >> >> > git://git.denx.de/u-boot). 3 - 4 patches fail when using git am. > >> >> > > > >> >> > > I worked thru the conflicts for both branches (my master rebased > >> >> > > against > >> >> > ARM and U-Boot TOT), and did a MAKEALL -s tegra, and jetson-tk1, > >> >> > beaver and cardhu fail to build (jetson err log below). Looks like > >> >> > you developed this with your DM I2C series in place? > >> >> > > > >> >> > > To submit a PR from the Tegra repo, I need to either rebase first > >> >> > > against > >> >> > ARM master (my SOP), or against U-Boot 'master'. So you patches, > >> >> > if they're bound for the Tegra repo, need to work in one of those > >> >> > scenarios. > >> >> > > > >> >> > > Tom > >> >> > > >> >> > Thanks for looking at it. This series depends on the I2C driver > >> >> > model series. > >> >> > It's available at u-boot-dm/i2c-working if you want to check it > >> >> > out. I plan to apply that very soon. > >> >> > > >> >> > I'm sorry I didn't make that clear in this series. I mentioned it > >> >> > on the list at one point but should have added it here. If you > >> >> > like, you could ack it and I can apply to u-boot-dm after I2C is in > >> >> > there. > >> >> I can't ACK something that I can't get to apply to my repo nor build > >> >> nor test. So you'll have to wait on that from Stephen, Thierry (based > >> >> on code > >> >> review) or someone that wants to add DM I2C to Tegra, apply your PCIe > >> >> patches, and test. That's not my normal workflow, though, and I don't > >> >> have the BW to devote to extra hurdles right now. > >> >> > >> > > >> > You could try applying to u-boot-dm/i2c-working. It only has the DM > >> > i2c series in it, plus Tegra stuff. I put a lot of time into cleaning > >> > up this Tegra series to save you and Thierry time. > >> > >> Also Thierry took a look the PCIe series and responded here: > >> > >> http://patchwork.ozlabs.org/patch/410175/ > >> > >> There were three nits which I have addressed. > >> > >> For this Nyan-big patch I really don't need a test credit (would be nice, > >> but > >> not necessary). After all it's a new board and if problems are found they > >> can > >> be fixed. But I do need to apply it before DM I2C. > >> Stephen has looked at a few revs. > >> > >> How about this for a plan: > >> > >> - Apply Nyan-big to DM > >> - Apply DM I2C series to DM > >> - Pull request to mainline (final for DM this release unless SPL is > >> resolved > >> somehow) > >> > >> Then if you have time: > >> - Tom - apply PCIe to Tegra tree > >> - Pull request to mainline > > The problem there is that I'd need to wait for the PR to mainline to go > > thru before I could rebase Tegra against mainline, and only then apply PCIe > > patches. Time-wise, it's obviously better for you to do this in one fell > > swoop from the DM repo. > > > > Does the nyan-big patchset apply/build cleanly in u-boot-tegra/master? If > > so, I can apply it and do a Tegra test build and then send a PR to Albert > > if all is clear. > > OK, true. > > The Tegra tree is too far behind master, but if you catch it up you > can make it work: > > (try-nyan=9e10b9: b/ common/ doc/ sandbox/) u> pwclient git-am 417781 > Applying patch #417781 using 'git am' > Description: [U-Boot,v5,1/3] dts: Bring in Chrome OS keyboard device > tree definition > Applying: dts: Bring in Chrome OS keyboard device tree definition > (try-nyan=ddebcc: b/ common/ doc/ sandbox/) u> pwclient git-am 417782 > Applying patch #417
Re: [U-Boot] [PATCH v2 15/27] x86: Integrate Tunnel Creek processor microcode
Hi Bin, On 9 December 2014 at 23:24, Simon Glass wrote: > Hi Bin. > > > On 9 December 2014 at 23:17, Bin Meng wrote: >> Hi Simon, >> >> On Wed, Dec 10, 2014 at 2:09 PM, Simon Glass wrote: >>> Hi Bin, >>> >>> On 9 December 2014 at 07:50, Bin Meng wrote: Integrate the processor microcode version 1.05 for Tunnel Creek, CPUID device 20661h. Signed-off-by: Bin Meng --- Changes in v2: None >>> >>> We are going to end up with microcode both in the device tree and in >>> an assembler include file. >>> >>> This seems unfortunate. I wonder if we can always put it in the device >>> tree, but then optionally also compile it into the image using a >>> symbol (as we do in dts/Makefile for CONFIG_OF_EMBED). This could be >>> done with fdtget to read the binary output of the property perhaps. I >>> haven't looked at it in detail though. >>> >> >> This will do for the embedded case, but it won't help for the separate dtb >> case. >> >>> Maybe this is too clumsy but it would be good to have it in one >>> format. Or maybe we should have a tool which can generate either >>> format. >> >> I don't think we are able to parse device tree in that early phase >> (before car_init), to get the microcode content from dtb. I know in >> some Intel processors, the microcode update are required before CAR >> initialization, as without the microcode update, the CAR >> initialization will fail. > > Right, I meant that we could perhaps do this in the build system - > i.e. compile in the microcode after reading it from the device tree. > > Not thrilled with the idea... I wonder if we could do this: 1. Put the microcode in a .dtsi file, perhaps with a tool to do this automatically. 3. Build the board 2. Use something like this to extract the hex data manualy: fdtget -tx /path/to/u-boot.dtb /microcode/update@0 data | sed 's/ /, 0x/g' then put this in a file that you compile. That way if we come up with a clever solution later we can use it. Unfortunately it means submitting the same microcode update in a .c format for now, but have a path to fixing it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/27] x86: Integrate Tunnel Creek processor microcode
Hi Simon, On Thu, Dec 11, 2014 at 10:34 PM, Simon Glass wrote: > Hi Bin, > > On 9 December 2014 at 23:24, Simon Glass wrote: >> Hi Bin. >> >> >> On 9 December 2014 at 23:17, Bin Meng wrote: >>> Hi Simon, >>> >>> On Wed, Dec 10, 2014 at 2:09 PM, Simon Glass wrote: Hi Bin, On 9 December 2014 at 07:50, Bin Meng wrote: > Integrate the processor microcode version 1.05 for Tunnel Creek, > CPUID device 20661h. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None We are going to end up with microcode both in the device tree and in an assembler include file. This seems unfortunate. I wonder if we can always put it in the device tree, but then optionally also compile it into the image using a symbol (as we do in dts/Makefile for CONFIG_OF_EMBED). This could be done with fdtget to read the binary output of the property perhaps. I haven't looked at it in detail though. >>> >>> This will do for the embedded case, but it won't help for the separate dtb >>> case. >>> Maybe this is too clumsy but it would be good to have it in one format. Or maybe we should have a tool which can generate either format. >>> >>> I don't think we are able to parse device tree in that early phase >>> (before car_init), to get the microcode content from dtb. I know in >>> some Intel processors, the microcode update are required before CAR >>> initialization, as without the microcode update, the CAR >>> initialization will fail. >> >> Right, I meant that we could perhaps do this in the build system - >> i.e. compile in the microcode after reading it from the device tree. >> >> Not thrilled with the idea... > > I wonder if we could do this: > > 1. Put the microcode in a .dtsi file, perhaps with a tool to do this > automatically. > 3. Build the board > 2. Use something like this to extract the hex data manualy: 'manually' means we don't let the build system to do this 'automatically'? > > fdtget -tx /path/to/u-boot.dtb /microcode/update@0 data | sed 's/ /, 0x/g' > > then put this in a file that you compile. That way if we come up with > a clever solution later we can use it. Unfortunately it means > submitting the same microcode update in a .c format for now, but have > a path to fixing it. > Sorry I am confused. In what format should we submit the microcode data? Is it dtsi or .c? Intel normally releases the microcode update in .h format. BTW: I have cleaned up the remaining coding convention issues for ths FSP codes. Do you want to continue reviewing other patches in this v2, so that I can fix all issues in v3? Do you think we need address this microcode update in v3? I think we can leave this issue for this series, and address this microcode issue in another patch series, as it may touch the chromebook_link codes. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-socfpga/master
Hi Tom, below is the stuff I had stashed in a tree for a while now. All of the cadence stuff was sent way before RC1 and stabilized just after RC1 was out, yet I was not able to get it out earlier. The stuff from Ding are fixes, which were sent after RC2. All of this is contained to socfpga, so I believe it's fine to apply even now. The following changes since commit 97cdf64026c7d749dd7a5c0dbaba7a60a7292ac9: Merge branch 'sandbox' of git://git.denx.de/u-boot-x86 (2014-12-04 09:24:05 -0500) are available in the git repository at: git://git.denx.de/u-boot-socfpga.git master for you to fetch changes up to b9b5cf0ea3c5c141f31cc0c4c8edebbfd9ff5866: socfpga: correctly increment freeze_controller_base address (2014-12-06 13:53:57 +0100) Dinh Nguyen (3): arm: socfpga: set skew settings for ethernet phy socfpga: add missing struct member fifo_triple_byte socfpga: correctly increment freeze_controller_base address Stefan Roese (15): arm: socfpga: Add myself as maintainer for the SoCrates board arm: socfpga: dts: Move to SPDX license identifiers spi: Add Cadence QSPI DM driver used by SoCFPGA arm: socfpga: dts: Add Cadence QSPI DT node to socfpga.dtsi arm: socfpga: dts: Add spi0 alias for Cadence QSPI driver arm: socfpga: Add Cadence QSPI support to config header spi: Add designware master SPI DM driver used on SoCFPGA arm: socfpga: dts: Add spi0/1 dts nodes for the Designware master SPI devices arm: socfpga: dts: socrates: Add spi1/2 aliases needed DM SPI probing arm: socfpga: Add Designware (DW) SPI support to config header arm: socfpga: dts: altr,rst-mgr.h: Move to SPDX license identifiers arm: socfpga: Use only one clrbits_le32 call to deassert SPI reset bits arm: socfpga: Add missing DW master SPI clock prototyp to clock_manager.h spi: designware_spi: Some fixes / changes arm: socfpga: DW_SPI: Remove clock info from config header arch/arm/cpu/armv7/socfpga/freeze_controller.c| 6 +- arch/arm/cpu/armv7/socfpga/reset_manager.c| 4 +- arch/arm/dts/socfpga.dtsi | 56 -- arch/arm/dts/socfpga_cyclone5.dtsi| 13 +- arch/arm/dts/socfpga_cyclone5_socrates.dts| 39 ++-- arch/arm/include/asm/arch-socfpga/clock_manager.h | 1 + arch/arm/include/asm/arch-socfpga/freeze_controller.h | 1 - arch/arm/include/asm/arch-socfpga/scan_manager.h | 1 + board/altera/socfpga/MAINTAINERS | 5 + board/altera/socfpga/socfpga_cyclone5.c | 16 ++ drivers/spi/Makefile | 2 + drivers/spi/cadence_qspi.c| 345 drivers/spi/cadence_qspi.h| 76 drivers/spi/cadence_qspi_apb.c| 898 drivers/spi/designware_spi.c | 426 include/configs/socfpga_common.h | 33 +++- include/dt-bindings/reset/altr,rst-mgr.h | 9 +- 17 files changed, 1879 insertions(+), 52 deletions(-) create mode 100644 drivers/spi/cadence_qspi.c create mode 100644 drivers/spi/cadence_qspi.h create mode 100644 drivers/spi/cadence_qspi_apb.c create mode 100644 drivers/spi/designware_spi.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
Hi Tom, minor USB fixes. The following changes since commit 0d485b9095328cdc81b2ee94ff59b988c69b9127: Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2014-11-13 10:35:13 -0500) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 0c6de8853b2571251fdefe34598e0c344fe1372b: usb: ehci: do not set the LSB of Current qTD pointer (2014-11-19 23:31:54 +0100) Masahiro Yamada (1): usb: ehci: do not set the LSB of Current qTD pointer Peng Fan (3): usb:ehci-mx6 add phy mode query function imx:mx6slevk add board level support for usb imx:mx6sxsabresd add board level support for usb Łukasz Majewski (2): dfu: thor: fix: Modify dfu_get_alt() function to support absolute paths test: ums: Add sleep before unmount directory arch/arm/include/asm/arch-mx6/mx6sl_pins.h | 5 + board/freescale/mx6slevk/mx6slevk.c | 49 + board/freescale/mx6sxsabresd/mx6sxsabresd.c | 49 + drivers/dfu/dfu.c | 29 +++-- drivers/usb/host/ehci-hcd.c | 1 - drivers/usb/host/ehci-mx6.c | 27 +-- include/configs/mx6slevk.h | 14 ++ include/configs/mx6sxsabresd.h | 14 ++ include/usb/ehci-fsl.h | 2 ++ test/ums/ums_gadget_test.sh | 10 +- 10 files changed, 194 insertions(+), 6 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB Host not enumerating properly on AM335x-based board
On Wednesday, December 10, 2014 at 04:23:49 PM, Maxime Ripard wrote: > Hi, > > On Thu, Nov 20, 2014 at 05:49:17PM +0100, Maxime Ripard wrote: > > Hi, > > > > I'm currently working on 2014.07, on a custom TI AM335x based board. > > > > Everything works great so far, except when we're trying to have USB > > host working. > > > > The board has the MUSB1 controller wired as USB Host only, with the > > following configuration: > > > > #define CONFIG_USB_MUSB_DSPS > > #define CONFIG_ARCH_MISC_INIT > > #define CONFIG_MUSB_PIO_ONLY > > #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT > > #define CONFIG_MUSB_HOST > > #define CONFIG_MUSB_DSPS > > #define CONFIG_AM335X_USB1 > > #define CONFIG_AM335X_USB1_MODE MUSB_HOST > > > > #ifdef CONFIG_MUSB_HOST > > #define CONFIG_CMD_USB > > #define CONFIG_USB_STORAGE > > #define CONFIG_USB_HOST_ETHER > > #define CONFIG_USB_ETHER_ASIX > > #endif > > > > Whenever we try to scan the USB controller and that a device is > > attached, we get the following output: > > > > U-Boot# usb start > > (Re)start USB... > > USB0: scanning bus 0 for devices... 1 USB Device(s) found > > > >scanning usb for storage devices... 0 Storage Device(s) found > >scanning usb for ethernet devices... 0 Ethernet Device(s) found > > Just an update on this one. > > Our configuration was missing CONFIG_USB_GADGET_DUALSPEED that, even > though its name suggest otherwise, seems to be needed to enable USB2.0 > devices support in the musb-new driver. > > With this additional configuration option, everything works as > expected. Wow, this is excellent news, good job finding this! On the other hand, this behavior is very braindead and should be fixed before someone else gets burnt. Do you have any ideas for a patch please ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: Add DT support for SoCFPGA
On Monday, December 08, 2014 at 09:23:18 AM, Stefan Roese wrote: > Marek, > > On 08.12.2014 09:15, Stefan Roese wrote: > > On 06.12.2014 13:58, Marek Vasut wrote: > >> On Thursday, October 30, 2014 at 09:19:56 AM, Stefan Roese wrote: > >>> This patch includes the latest DT sources for socfpga from the current > >>> Linux kernel. And enables CONFIG_OF_CONTROL for socfpga_cyclone5 to > >>> make use of this new DT support. > >>> > >>> Note that now the image to use is u-boot-dtb.img! > >>> > >>> Signed-off-by: Stefan Roese > >>> Cc: Marek Vasut > >>> Cc: Chin Liang See > >>> Cc: Dinh Nguyen > >>> Cc: Vince Bridgers > >>> Cc: Albert Aribaud > >>> Cc: Pavel Machek > >> > >> Hi Stefan, > >> > >> any chance you can update this against current u-boot-socfpga/master > >> please ? > >> I think this should be 5 minute job at best. > > > > Will do. > > Its already in mainline. This patch has superseeded the one you refer by > this mail: > > 51c580c6c92c01884f520f4ffaeb6885ee8e666e > arm: socfpga: Add DT support for SoCFPGA and add socfpga_socrates target > > Let me know if something is still missing or unclear. Thank you for checking ! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB Host not enumerating properly on AM335x-based board
Hi, On Thu, Dec 11, 2014 at 02:09:30PM +0100, Marek Vasut wrote: > On Wednesday, December 10, 2014 at 04:23:49 PM, Maxime Ripard wrote: > > Hi, > > > > On Thu, Nov 20, 2014 at 05:49:17PM +0100, Maxime Ripard wrote: > > > Hi, > > > > > > I'm currently working on 2014.07, on a custom TI AM335x based board. > > > > > > Everything works great so far, except when we're trying to have USB > > > host working. > > > > > > The board has the MUSB1 controller wired as USB Host only, with the > > > following configuration: > > > > > > #define CONFIG_USB_MUSB_DSPS > > > #define CONFIG_ARCH_MISC_INIT > > > #define CONFIG_MUSB_PIO_ONLY > > > #define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT > > > #define CONFIG_MUSB_HOST > > > #define CONFIG_MUSB_DSPS > > > #define CONFIG_AM335X_USB1 > > > #define CONFIG_AM335X_USB1_MODE MUSB_HOST > > > > > > #ifdef CONFIG_MUSB_HOST > > > #define CONFIG_CMD_USB > > > #define CONFIG_USB_STORAGE > > > #define CONFIG_USB_HOST_ETHER > > > #define CONFIG_USB_ETHER_ASIX > > > #endif > > > > > > Whenever we try to scan the USB controller and that a device is > > > attached, we get the following output: > > > > > > U-Boot# usb start > > > (Re)start USB... > > > USB0: scanning bus 0 for devices... 1 USB Device(s) found > > > > > >scanning usb for storage devices... 0 Storage Device(s) found > > >scanning usb for ethernet devices... 0 Ethernet Device(s) found > > > > Just an update on this one. > > > > Our configuration was missing CONFIG_USB_GADGET_DUALSPEED that, even > > though its name suggest otherwise, seems to be needed to enable USB2.0 > > devices support in the musb-new driver. > > > > With this additional configuration option, everything works as > > expected. > > Wow, this is excellent news, good job finding this! > > On the other hand, this behavior is very braindead and should be fixed before > someone else gets burnt. I agree :) > Do you have any ideas for a patch please ? It's really used by two drivers: musb-new and gadget/ether.c The ethernet driver seems to be doing the right thing: this option controls wether the gadget should use high or full speed. musb-new on the other hand seems to be using it to set up the actual controller speed, disregarding wether it's running in host or device mode. So I guess we could split these two apart, and introduce an option called CONFIG_MUSB_DUALSPEED? The tricky thing will be to convert the configurations using this option, since you can't really know with a grep / sed what they are using it for: ethernet, musb, both? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/27] x86: Integrate Tunnel Creek processor microcode
Hi Bin, On 11 December 2014 at 08:01, Bin Meng wrote: > Hi Simon, > > On Thu, Dec 11, 2014 at 10:34 PM, Simon Glass wrote: >> Hi Bin, >> >> On 9 December 2014 at 23:24, Simon Glass wrote: >>> Hi Bin. >>> >>> >>> On 9 December 2014 at 23:17, Bin Meng wrote: Hi Simon, On Wed, Dec 10, 2014 at 2:09 PM, Simon Glass wrote: > Hi Bin, > > On 9 December 2014 at 07:50, Bin Meng wrote: >> Integrate the processor microcode version 1.05 for Tunnel Creek, >> CPUID device 20661h. >> >> Signed-off-by: Bin Meng >> --- >> >> Changes in v2: None > > We are going to end up with microcode both in the device tree and in > an assembler include file. > > This seems unfortunate. I wonder if we can always put it in the device > tree, but then optionally also compile it into the image using a > symbol (as we do in dts/Makefile for CONFIG_OF_EMBED). This could be > done with fdtget to read the binary output of the property perhaps. I > haven't looked at it in detail though. > This will do for the embedded case, but it won't help for the separate dtb case. > Maybe this is too clumsy but it would be good to have it in one > format. Or maybe we should have a tool which can generate either > format. I don't think we are able to parse device tree in that early phase (before car_init), to get the microcode content from dtb. I know in some Intel processors, the microcode update are required before CAR initialization, as without the microcode update, the CAR initialization will fail. >>> >>> Right, I meant that we could perhaps do this in the build system - >>> i.e. compile in the microcode after reading it from the device tree. >>> >>> Not thrilled with the idea... >> >> I wonder if we could do this: >> >> 1. Put the microcode in a .dtsi file, perhaps with a tool to do this >> automatically. >> 3. Build the board >> 2. Use something like this to extract the hex data manualy: > > 'manually' means we don't let the build system to do this 'automatically'? For now, since I suspect automatically might be hard for you. > >> >> fdtget -tx /path/to/u-boot.dtb /microcode/update@0 data | sed 's/ /, 0x/g' >> >> then put this in a file that you compile. That way if we come up with >> a clever solution later we can use it. Unfortunately it means >> submitting the same microcode update in a .c format for now, but have >> a path to fixing it. >> > > Sorry I am confused. In what format should we submit the microcode > data? Is it dtsi or .c? Intel normally releases the microcode update > in .h format. We should have a tool which converts Intel's format into a device tree .dtsi include file. I'd like that .dtsi to be the file we commit to the U-Boot source tree. However since this is not suitable for your platform then we need to figure out an approach to convert it to a form you need. I believe all you really need to know is the address of the microcode update, and I feel there must be a way to make this work automatically in the build system. My suggestion above was just a short-term approach to get you unblocked. > > BTW: I have cleaned up the remaining coding convention issues for ths > FSP codes. Do you want to continue reviewing other patches in this v2, > so that I can fix all issues in v3? Do you think we need address this > microcode update in v3? I think we can leave this issue for this > series, and address this microcode issue in another patch series, as > it may touch the chromebook_link codes. Yes I will get to the others. Overall it all looks fine so don't expect anything major. I'm happy to sort out the microcode in a later series if you prefer, but we do need to fix it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/3] ARM: tegra: Add support for nyan-big board
Hi Tom, On 11 December 2014 at 08:58, Tom Warren wrote: > Simon, > > Feel free to do everything in the DM tree. Once DM makes it to mainline, and > hence to ARM and Tegra, we'll be better able to add Tegra things into the > Tegra repo. OK, I'll pull in the nyan-big patches to DM then I2C and retest. - Simon > > Tom > >> -Original Message- >> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass >> Sent: Thursday, December 11, 2014 7:22 AM >> To: Tom Warren >> Cc: U-Boot Mailing List; Stephen Warren; Allen Martin; Stephen Warren; >> Albert Aribaud >> Subject: Re: [PATCH v5 3/3] ARM: tegra: Add support for nyan-big board >> >> Hi Tom, >> >> On 10 December 2014 at 14:45, Simon Glass wrote: >> > >> > Hi Tom, >> > >> > On 10 December 2014 at 14:09, Tom Warren >> wrote: >> > > Simon, >> > > >> > >> -Original Message- >> > >> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon >> > >> Glass >> > >> Sent: Wednesday, December 10, 2014 2:04 PM >> > >> To: Tom Warren >> > >> Cc: U-Boot Mailing List; Stephen Warren; Allen Martin; Stephen >> > >> Warren; Albert Aribaud >> > >> Subject: Re: [PATCH v5 3/3] ARM: tegra: Add support for nyan-big >> > >> board >> > >> >> > >> Hi Tom, >> > >> >> > >> On 10 December 2014 at 12:36, Simon Glass >> wrote: >> > >> > Hi Tom, >> > >> > >> > >> > On Dec 10, 2014 12:05 PM, "Tom Warren" >> wrote: >> > >> >> >> > >> >> Simon, >> > >> >> >> > >> >> > -Original Message- >> > >> >> > From: s...@google.com [mailto:s...@google.com] On Behalf Of >> > >> >> > Simon Glass >> > >> >> > Sent: Wednesday, December 10, 2014 10:50 AM >> > >> >> > To: Tom Warren >> > >> >> > Cc: U-Boot Mailing List; Allen Martin; Albert Aribaud; Stephen >> > >> >> > Warren; Stephen Warren >> > >> >> > Subject: Re: [PATCH v5 3/3] ARM: tegra: Add support for >> > >> >> > nyan-big board >> > >> >> > >> > >> >> > Hi Tom, >> > >> >> > >> > >> >> > >> > >> >> > On 10 December 2014 at 10:39, Tom Warren >> >> > >> wrote: >> > >> >> > > Simon, >> > >> >> > > >> > >> >> > > The v4 PCIE patch series fails to apply to >> > >> >> > > u-boot-tegra/master after >> > >> >> > rebasing my repo against both ARM master and U-Boot 'master' >> > >> >> > master (i.e. >> > >> >> > FETCH_HEAD = >> > >> >> > > 32fdf0e4d82bdca5d64d86330e461e59685f9959branch >> 'master' of >> > >> >> > git://git.denx.de/u-boot). 3 - 4 patches fail when using git am. >> > >> >> > > >> > >> >> > > I worked thru the conflicts for both branches (my master >> > >> >> > > rebased against >> > >> >> > ARM and U-Boot TOT), and did a MAKEALL -s tegra, and >> > >> >> > jetson-tk1, beaver and cardhu fail to build (jetson err log >> > >> >> > below). Looks like you developed this with your DM I2C series in >> place? >> > >> >> > > >> > >> >> > > To submit a PR from the Tegra repo, I need to either rebase >> > >> >> > > first against >> > >> >> > ARM master (my SOP), or against U-Boot 'master'. So you >> > >> >> > patches, if they're bound for the Tegra repo, need to work in >> > >> >> > one of those scenarios. >> > >> >> > > >> > >> >> > > Tom >> > >> >> > >> > >> >> > Thanks for looking at it. This series depends on the I2C >> > >> >> > driver model series. >> > >> >> > It's available at u-boot-dm/i2c-working if you want to check >> > >> >> > it out. I plan to apply that very soon. >> > >> >> > >> > >> >> > I'm sorry I didn't make that clear in this series. I mentioned >> > >> >> > it on the list at one point but should have added it here. If >> > >> >> > you like, you could ack it and I can apply to u-boot-dm after >> > >> >> > I2C is in there. >> > >> >> I can't ACK something that I can't get to apply to my repo nor >> > >> >> build nor test. So you'll have to wait on that from Stephen, >> > >> >> Thierry (based on code >> > >> >> review) or someone that wants to add DM I2C to Tegra, apply your >> > >> >> PCIe patches, and test. That's not my normal workflow, though, >> > >> >> and I don't have the BW to devote to extra hurdles right now. >> > >> >> >> > >> > >> > >> > You could try applying to u-boot-dm/i2c-working. It only has the >> > >> > DM i2c series in it, plus Tegra stuff. I put a lot of time into >> > >> > cleaning up this Tegra series to save you and Thierry time. >> > >> >> > >> Also Thierry took a look the PCIe series and responded here: >> > >> >> > >> http://patchwork.ozlabs.org/patch/410175/ >> > >> >> > >> There were three nits which I have addressed. >> > >> >> > >> For this Nyan-big patch I really don't need a test credit (would be >> > >> nice, but not necessary). After all it's a new board and if >> > >> problems are found they can be fixed. But I do need to apply it before >> DM I2C. >> > >> Stephen has looked at a few revs. >> > >> >> > >> How about this for a plan: >> > >> >> > >> - Apply Nyan-big to DM >> > >> - Apply DM I2C series to DM >> > >> - Pull request to mainline (final for DM this release unless SPL is >> > >> resolved >> > >> somehow) >> > >> >> > >> Then if
Re: [U-Boot] [PULL] u-boot-socfpga/master
On Thursday, December 11, 2014 at 01:53:15 PM, Marek Vasut wrote: > Hi Tom, > > below is the stuff I had stashed in a tree for a while now. All of the > cadence stuff was sent way before RC1 and stabilized just after RC1 was > out, yet I was not able to get it out earlier. The stuff from Ding are > fixes, which were sent after RC2. All of this is contained to socfpga, so > I believe it's fine to apply even now. Please abort this one, I just noticed there's one patch which causes trouble. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: socfpga: board: Repair Micrel PHY tuning
From: Pavel Machek
Add proper error checking into the PHY tuning patch. Make the PHY tunning only
happen in case the KSZ9021 PHY is enabled in config. Call the config callback
after the tuning finished.
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Tom Rini
Cc: Pavel Machek
---
board/altera/socfpga/socfpga_cyclone5.c | 34 +++--
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/board/altera/socfpga/socfpga_cyclone5.c
b/board/altera/socfpga/socfpga_cyclone5.c
index 772a58e..459d82f 100644
--- a/board/altera/socfpga/socfpga_cyclone5.c
+++ b/board/altera/socfpga/socfpga_cyclone5.c
@@ -46,19 +46,41 @@ int board_init(void)
return 0;
}
+/*
+ * PHY configuration
+ */
+#ifdef CONFIG_PHY_MICREL_KSZ9021
int board_phy_config(struct phy_device *phydev)
{
+ int ret;
/*
* These skew settings for the KSZ9021 ethernet phy is required for
ethernet
* to work reliably on most flavors of cyclone5 boards.
*/
- ksz9021_phy_extended_write(phydev, MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW,
- 0x0);
- ksz9021_phy_extended_write(phydev, MII_KSZ9021_EXT_RGMII_TX_DATA_SKEW,
- 0x0);
- ksz9021_phy_extended_write(phydev, MII_KSZ9021_EXT_RGMII_CLOCK_SKEW,
- 0xf0f0);
+ ret = ksz9021_phy_extended_write(phydev,
+MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW,
+0x0);
+ if (ret)
+ return ret;
+
+ ret = ksz9021_phy_extended_write(phydev,
+MII_KSZ9021_EXT_RGMII_TX_DATA_SKEW,
+0x0);
+ if (ret)
+ return ret;
+
+ ret = ksz9021_phy_extended_write(phydev,
+MII_KSZ9021_EXT_RGMII_CLOCK_SKEW,
+0xf0f0);
+ if (ret)
+ return ret;
+
+ if (phydev->drv->config)
+ return phydev->drv->config(phydev);
+
+ return 0;
}
+#endif
#ifdef CONFIG_USB_GADGET
struct s3c_plat_otg_data socfpga_otg_data = {
--
2.0.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] RFC: dm: Kconfig: Move all driver model CONFIGs to Kconfig
Hi Simon, > > diff --git a/Kconfig b/Kconfig > index 153ee2b..d4ca152 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -158,3 +158,5 @@ source "drivers/Kconfig" > source "fs/Kconfig" > > source "lib/Kconfig" > + > +source "test/dm/Kconfig" Perhaps we might want "test/Kconfig" in the future. > --- a/arch/arm/cpu/armv7/tegra-common/Kconfig > +++ b/arch/arm/cpu/armv7/tegra-common/Kconfig > @@ -20,6 +20,27 @@ endchoice > config USE_PRIVATE_LIBGCC > default y if SPL_BUILD > > +config DM > + default y > + > +config SPL_DM > + default y > + > +config DM_SERIAL > + default y > + > +config DM_SPI > + default y > + > +config DM_SPI_FLASH > + default y > + > +config DM_I2C > + default y > + > +config DM_GPIO > + default y > + Are all of these user-configurable? I mean, do Tegra boards work fine without CONFIG_DM_* ? I doubt it because you have already converted Tegra drivers. - Use "select" if the option is mandatory for that board - Use "default y" if the option is still optional, but recommended. > source "arch/arm/cpu/armv7/tegra20/Kconfig" > source "arch/arm/cpu/armv7/tegra30/Kconfig" > source "arch/arm/cpu/armv7/tegra114/Kconfig" > diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig > index 3057325..1b4cbce 100644 > --- a/arch/sandbox/Kconfig > +++ b/arch/sandbox/Kconfig > @@ -10,4 +10,43 @@ config SYS_BOARD > config SYS_CONFIG_NAME > default "sandbox" > > +config DM > + default y > + > +config DM_GPIO > + default y > + > +config DM_SERIAL > + default y > + > +config CMD_DEMO > + default y > + > +config CMD_DM > + default y > + > +config DM_DEMO > + default y > + > +config DM_DEMO_SIMPLE > + default y > + > +config DM_DEMO_SHAPE > + default y > + > +config DM_TEST > + default y > + > +config DM_CROS_EC > + default y > + > +config DM_SPI > + default y > + > +config DM_SPI_FLASH > + default y > + > +config DM_I2C > + default y > + Why do you like this syntax? - If the option is not user-configurable, use "select" - If the option is user-configurable and you want change the default value, add it to configs/sandbox_defconfig > diff --git a/board/samsung/goni/Kconfig b/board/samsung/goni/Kconfig > index cbbf5a9..006e864 100644 > --- a/board/samsung/goni/Kconfig > +++ b/board/samsung/goni/Kconfig > @@ -12,4 +12,13 @@ config SYS_SOC > config SYS_CONFIG_NAME > default "s5p_goni" > > +config DM > + default y > + > +config DM_GPIO > + default y > + > +config DM_SERIAL > + default y > + "select" or "_defconfig" > diff --git a/common/Kconfig b/common/Kconfig > index fd84fa0..174bf4f 100644 > --- a/common/Kconfig > +++ b/common/Kconfig > @@ -153,6 +153,29 @@ endmenu > > menu "Device access commands" > > +config CMD_DM > + bool "dm - Access to driver model information" > + depends on DM > + default y > + help > + Provides access to driver model data structures and information, > + such as a list of devices, list of uclasses and the state of each > + device (e.g. activated). This is not required for operation, but > + can be useful to see the state of driver model for debugging or > + interest. > + > +config CMD_DEMO > + bool "demo - Demonstration commands for driver model" > + depends on DM > + help > + Procides a 'demo' command which can be used to play around with > + driver model. To use this properly you will need to enable one or > + both of the demo devices (DM_DEMO_SHAPE and DM_DEMO_SIMPLE). > + Otherwise you will always get an empty list of devices. The demo > + devices are defined in the sandbox device tree, so the easiest > + option is to use sandbox and pass the -d point to sandbox's > + u-boot.dtb file. > + These seems rather "Misc commands". > config CMD_LOADB > bool "loadb" > help > diff --git a/configs/Linksprite_pcDuino3_fdt_defconfig > b/configs/Linksprite_pcDuino3_fdt_defconfig > index a33f3a7..931b5dd 100644 > --- a/configs/Linksprite_pcDuino3_fdt_defconfig > +++ b/configs/Linksprite_pcDuino3_fdt_defconfig > @@ -2,6 +2,8 @@ CONFIG_SPL=y > > CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPH(2),USB_EHCI" > CONFIG_FDTFILE="sun7i-a20-pcduino3.dtb" > CONFIG_DM=y > +CONFIG_DM_GPIO=y > +CONFIG_DM_SERIAL=y > CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-pcduino3" > CONFIG_OF_CONTROL=y > CONFIG_OF_SEPARATE=y Here, you use _defconfig. What is the difference? > diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig > index d2799dc..2ae2cc4 100644 > --- a/drivers/core/Kconfig > +++ b/drivers/core/Kconfig > @@ -2,5 +2,123 @@ config DM > bool "Enable Driver Model" > depends on !SPL_BUILD > help > - This config option enables Driver Model. > - To use legacy drivers, say N. > + Th
Re: [U-Boot] [PATCH 2/2] Kconfig: Move CONFIG_SYS_MALLOC_F_LEN to Kconfig
Hi Simon, 2014-12-09 22:21 GMT+09:00 Simon Glass : > diff --git a/arch/arm/cpu/armv7/tegra-common/Kconfig > b/arch/arm/cpu/armv7/tegra-common/Kconfig > index 898e86d..9c98d19 100644 > --- a/arch/arm/cpu/armv7/tegra-common/Kconfig > +++ b/arch/arm/cpu/armv7/tegra-common/Kconfig > @@ -17,6 +17,9 @@ config TEGRA124 > > endchoice > > +config SYS_MALLOC_F_LEN > + default 0x1800 > + I do not object against your way now, but it seems unfortunate because I think this kind of stuff should go to _defconfig. The problem is that we have much more defconfig files than Linux without much differences but we do not have something like tegra-common_defconfig. I have been thinking of this these days. Perhaps, one possible solution I have come up with is to use scripts/kconfig/merge_config.sh For example, - "make tegra30_defconfig" + tegra30_harmony.config -> Harmony board - "make tegra30_defconfig" + tegra30_seaboard.config-> Seaboard -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Kconfig: Move CONFIG_SYS_MALLOC_F_LEN to Kconfig
Hi Masahiro, On 11 December 2014 at 10:53, Masahiro YAMADA wrote: > Hi Simon, > > > 2014-12-09 22:21 GMT+09:00 Simon Glass : >> diff --git a/arch/arm/cpu/armv7/tegra-common/Kconfig >> b/arch/arm/cpu/armv7/tegra-common/Kconfig >> index 898e86d..9c98d19 100644 >> --- a/arch/arm/cpu/armv7/tegra-common/Kconfig >> +++ b/arch/arm/cpu/armv7/tegra-common/Kconfig >> @@ -17,6 +17,9 @@ config TEGRA124 >> >> endchoice >> >> +config SYS_MALLOC_F_LEN >> + default 0x1800 >> + > > > I do not object against your way now, but it seems unfortunate because > I think this kind of stuff should go to _defconfig. > > The problem is that we have much more defconfig files than Linux > without much differences but we do not have something like > tegra-common_defconfig. > > I have been thinking of this these days. > > Perhaps, one possible solution I have come up with is to use > scripts/kconfig/merge_config.sh > For example, > > - "make tegra30_defconfig" + tegra30_harmony.config -> Harmony board > - "make tegra30_defconfig" + tegra30_seaboard.config-> Seaboard > Yes something like this was the discussion I was wanting to have. As you can see I found myself adding things to Kconfig to avoid needing to add loads of common stuff to multiple files. It otherwise rapidly becomes unmaintainable I think. I personally find the kernel Kconfigs a pain in that way - in Chrome OS we have a config merging script to try to make it less painful. Something like you proposed would solve this, but IMO it should be part of the build system, not hacked in by each vendor. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-fsl-qoriq.git master
Tom, The following changes since commit 32fdf0e4d82bdca5d64d86330e461e59685f9959: Prepare v2015.01-rc3 (2014-12-08 16:35:08 -0500) are available in the git repository at: git://git.denx.de/u-boot-fsl-qoriq.git master for you to fetch changes up to 0de15707a71ec64dbc1ead2831457f1550179ea7: kconfig: ls102xa: Change the prompt messages (2014-12-11 09:42:41 -0800) Alison Wang (12): ls102xa: pblimage: Add pblimage tool support for LS102xA spl: Use u-boot.img instead of u-boot.bin arm: spl: Add I2C linker list in generic .lds kconfig: ls1021a: add SUPPORT_SPL ls102xa: qixis: Add CONFIG_QIXIS_I2C_ACCESS macro arm: ls102xa: Add SD boot support for LS1021AQDS board arm: ls102xa: Add SD boot support for LS1021ATWR board arm: ls1021a: Add CONFIG_DOS_PARTITION and CONFIG_CMD_FAT support arm: ls102xa: Fix SD/NAND/QSPI boot defination error for QE support arm: ls102xa: Add QSPI boot support for LS1021AQDS/TWR board arm: ls102xa: Add NAND boot support for LS1021AQDS board kconfig: ls102xa: Change the prompt messages Chenhui Zhao (1): ls1021aqds: set the default I2C channel before DDR init Jaiprakash Singh (1): driver/mtd: Fix IFC compilation warnings Minghuan Lian (1): arm: ls102xa: Update PCIe dts node status Nikhil Badola (3): drivers: usb: Make usb device-tree fixup code architecture independent drivers: usb: fsl: Add USB device-tree errata framework drivers: usb: fsl: Check USB Erratum A007792 applicability Tang Yuantian (2): arm: ls102xa: fixed a bus frequency setting error fsl/sleep: updated the deep sleep framework for QorIQ platforms Xiubo Li (6): ARM: HYP/non-sec: add the pen address BE mode support. ARM: HYP/non-sec: Fix the ARCH Timer frequency setting. ls1021a: adding a secondary core boot address and kick functions ls102xa: changing a few targets' configurations. ARM: ls102xa: allow all the peripheral access permission as R/W. ARM: ls102xa: Setting device's stream id for SMMUs. Yao Yuan (1): ls1021aqds: add hwconfig setting to do pin mux chenhui zhao (1): arm: ls102xa: clear EPU registers for deep sleep Makefile | 11 +- arch/arm/Kconfig |6 +- arch/arm/cpu/armv7/ls102xa/Makefile|2 + arch/arm/cpu/armv7/ls102xa/cpu.c | 34 +++ arch/arm/cpu/armv7/ls102xa/fdt.c |2 +- arch/arm/cpu/armv7/ls102xa/fsl_epu.c | 57 arch/arm/cpu/armv7/ls102xa/fsl_epu.h | 68 + arch/arm/cpu/armv7/ls102xa/spl.c | 33 +++ arch/arm/cpu/armv7/nonsec_virt.S |7 +- arch/arm/cpu/u-boot-spl.lds|3 + arch/arm/include/asm/arch-ls102xa/config.h |9 + arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h |9 + .../include/asm/arch-ls102xa/ls102xa_stream_id.h | 17 ++ arch/arm/include/asm/arch-ls102xa/ns_access.h | 118 arch/arm/include/asm/arch-ls102xa/spl.h| 20 ++ arch/arm/include/asm/pcie_layerscape.h | 13 + arch/powerpc/cpu/mpc8xxx/fdt.c | 104 --- board/freescale/common/Makefile| 10 + board/freescale/common/arm_sleep.c | 95 +++ board/freescale/common/ls102xa_stream_id.c | 18 ++ board/freescale/common/mpc85xx_sleep.c | 88 ++ board/freescale/common/ns_access.c | 30 +++ board/freescale/common/qixis.h |7 + board/freescale/common/sleep.h | 21 ++ board/freescale/ls1021aqds/MAINTAINERS |3 + board/freescale/ls1021aqds/ddr.c |5 +- board/freescale/ls1021aqds/ls1021aqds.c| 283 ++-- board/freescale/ls1021aqds/ls102xa_pbi.cfg | 12 + board/freescale/ls1021aqds/ls102xa_rcw_nand.cfg|7 + board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg | 14 + board/freescale/ls1021atwr/MAINTAINERS |2 + board/freescale/ls1021atwr/ls1021atwr.c| 151 +++ board/freescale/ls1021atwr/ls102xa_pbi.cfg | 12 + board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg | 14 + configs/ls1021aqds_nand_defconfig |4 + configs/ls1021aqds_qspi_defconfig |3 + configs/ls1021aqds_sdcard_defconfig|4 + configs/ls1021atwr_qspi_defconfig |3 + configs/ls1021atwr_sdcard_defconfig|4 + drivers/ddr/fsl/arm_ddr_gen3.c | 45 +++- drivers/ddr/fsl/fsl_ddr_gen4.c | 44 ++- drivers/ddr/fsl/mpc85xx_ddr_gen3.c | 67 ++--- drivers/mtd/nand/fsl_ifc_nand.c|2 +-
Re: [U-Boot] [PATCH] arm: ls102xa: fixed a bus frequency setting error
On 10/20/2014 10:51 PM, yuantian.t...@freescale.com wrote: > From: Tang Yuantian > > The bus frequency in SOC node should be clock frequency of platform. > That is not true if it is devided by 2. > > Signed-off-by: Tang Yuantian > --- > arch/arm/cpu/armv7/ls102xa/fdt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: ls102xa: clear EPU registers for deep sleep
On 10/22/2014 03:20 AM, Chenhui Zhao wrote: > After wakeup from deep sleep, Clear EPU registers as early as possible > to prevent from possible issue. It's also safe to clear at normal boot. > > Signed-off-by: Chenhui Zhao > --- Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: ls102xa: Update PCIe dts node status
On 10/30/2014 10:43 PM, Minghuan Lian wrote: > The patch changes PCIe dts node status to 'disabled' if the > corresponding controller is disabled according to serdes protocol. > > Signed-off-by: Minghuan Lian > --- Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ls1021aqds: set the default I2C channel before DDR init
On 11/05/2014 06:51 PM, Alison Wang wrote: > From: Chenhui Zhao > > When resuming from deep sleep, the I2C channel may not be > in the default channel. So, switch to the default channel > before accessing DDR SPD. > > Signed-off-by: Chenhui Zhao > --- Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/9] ls102xa: pblimage: Add pblimage tool support for LS102xA
On 12/02/2014 11:00 PM, Alison Wang wrote: > For LS102xA, the size of spl/u-boot-spl.bin is variable. > This patch adds the support to deal with the variable > u-boot size in pblimage tool. It will be padded to 64 > byte boundary. > > Use pblimage_check_params() to add the specific operations > for ARM, such as PBI CRC and END command and the calculation > of pbl_cmd_initaddr. > > Signed-off-by: Alison Wang > --- > Change log: > v4: No change. > v3: Change the Copyright year. > v2: Remove the definition of CONFIG_SPL_MAX_SIZE. > Pad the variable u-boot size to 64 byte boundary in pblimage tool. > Use pblimage_check_params() insteady of basing on the file name. > Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/9] spl: Use u-boot.img instead of u-boot.bin
On 12/02/2014 11:00 PM, Alison Wang wrote: > In SD boot, the magic number of u-boot image will be checked. > For LS102xA, u-boot.bin doesn't have the magic number. So use > u-boot.img which includes the magic number instead of u-boot.bin > when producing u-boot-with-spl-pbl.bin. > > Signed-off-by: Alison Wang > --- > Change log: > v4: No change. > v3: No change. > v2: No change. > Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/9] kconfig: ls1021a: add SUPPORT_SPL
On 12/02/2014 11:00 PM, Alison Wang wrote: > Add SUPPORT_SPL feature for SD and NAND boot on > LS1021AQDS and LS1021ATWR. > > Signed-off-by: Alison Wang > --- > Change log: > v4: New file. > Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/9] ls102xa: qixis: Add CONFIG_QIXIS_I2C_ACCESS macro
On 12/02/2014 11:00 PM, Alison Wang wrote: > Through adding CONFIG_QIXIS_I2C_ACCESS macro, > QIXIS_READ(reg)/QIXIS_WRITE(reg, value) can be used > for both i2c and ifc access to QIXIS FPGA. This is > more convenient for coding. > > Signed-off-by: Jason Jin > Signed-off-by: Alison Wang > --- > Change log: > v4: No change. > v3: No change. > v2: No change. > Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/9] arm: ls102xa: Add SD boot support for LS1021AQDS board
On 12/02/2014 11:00 PM, Alison Wang wrote: > This patch adds SD boot support for LS1021AQDS board. SPL > framework is used. PBL initialize the internal RAM and copy > SPL to it, then SPL initialize DDR using SPD and copy u-boot > from SD card to DDR, finally SPL transfer control to u-boot. > > Signed-off-by: Alison Wang > Signed-off-by: Jason Jin > --- > Change log: > v4: Enable IFC in SD boot. > v3: Update MAINTAINERS file. > Update PBI and RCW for SD boot. > v2: Use generic u-boot-spl.lds. Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 8/9] arm: ls102xa: Add SD boot support for LS1021ATWR board
On 12/02/2014 11:00 PM, Alison Wang wrote: > This patch adds SD boot support for LS1021ATWR board. SPL > framework is used. PBL initialize the internal RAM and copy > SPL to it, then SPL initialize DDR using SPD and copy u-boot > from SD card to DDR, finally SPL transfer control to u-boot. > > Signed-off-by: Chen Lu > Signed-off-by: Alison Wang > Signed-off-by: Jason Jin > --- > Change log: > v4: Enable IFC in SD boot. > v3: Update MAINTAINERS file. > Update PBI and RCW for SD boot. > v2: Use generic u-boot-spl.lds. > Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: ls1021a: Add CONFIG_DOS_PARTITION and CONFIG_CMD_FAT support
On 12/09/2014 01:37 AM, Alison Wang wrote: > This patch will fix the bug that the partitions on the SD card could > not be accessed and add the support for the FAT fs. > > Signed-off-by: Alison Wang > --- > Change log: > v2: Rebase the patch. > Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: ls102xa: Add QSPI boot support for LS1021AQDS/TWR board
On 12/09/2014 01:38 AM, Alison Wang wrote: > This patch adds QSPI boot support for LS1021AQDS/TWR board. > The QSPI boot image need to be programmed into the QSPI flash > first. Then the booting will start from QSPI memory space. > > Signed-off-by: Alison Wang > --- > Change log: > v2: Rebase the patch. > Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] arm: ls102xa: Add NAND boot support for LS1021AQDS board
On 12/09/2014 01:38 AM, Alison Wang wrote: > This patch adds NAND boot support for LS1021AQDS board. SPL > framework is used. PBL initialize the internal RAM and copy > SPL to it, then SPL initialize DDR using SPD and copy u-boot > from NAND flash to DDR, finally SPL transfer control to u-boot. > > Signed-off-by: Prabhakar Kushwaha > Signed-off-by: Alison Wang > --- > Change log: > v2: Rebase the patch. > Add CONFIG_SYS_DCSR_DCFG_ADDR instead of CONFIG_SYS_DCSRBAR. > Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] arm: ls102xa: Fix SD/NAND/QSPI boot defination error for QE support
On 12/09/2014 01:37 AM, Alison Wang wrote: > The SD/NAND/QSPI boot definations are wrong for QE support, this > patch is to fix this error. > > Signed-off-by: Alison Wang > --- Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] ls1021aqds: add hwconfig setting to do pin mux
On 11/25/2014 10:54 PM, Yuan Yao wrote: > The Freescale LS1021AQDS share some pins, so Add the hwconfig option > that allows the user to choose which the function he wants. > > The main pin mux IP is: > eSDHC, SAI, IIC2, RGMII, CAN, SAI. > > Signed-off-by: Yuan Yao > --- > Changed in v3: > - Add the change log in comment section. > - Use #define instead of magic numbers and computation. > Changed in v2: > - Rebase to latest u-boot. Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3][v2] drivers: usb: Make usb device-tree fixup code architecture independent
On 10/20/2014 04:20 AM, Nikhil Badola wrote: > move usb device tree fixup code from "arch/powerpc/" to "drivers/usb/" > so that it works independent of architecture it is running on > > Signed-off-by: Ramneek Mehresh > Signed-off-by: Nikhil Badola > --- > Changes for v2 : > - Fixed compilation error for Platforms with > CONFIG_USB_MAX_CONTROLLER_COUNT not defined > - Depends on https://patchwork.ozlabs.org/patch/401063/ Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] drivers: usb: fsl: Add USB device-tree errata framework
On 09/29/2014 10:54 PM, Nikhil Badola wrote: > Add a new framework for fsl usb erratum handling to standardize > erratum checking only inside Uboot. Information to kernel is passed > via a boolean property corresponding to erratum, hence eliminating > need for code duplication inside kernel > > Signed-off-by: Ramneek Mehresh > Signed-off-by: Nikhil Badola > --- Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: usb: fsl: Check USB Erratum A007792 applicability
On 10/29/2014 09:41 PM, Nikhil Badola wrote: > Check USB Erratum A007792 applicability. If applicable, add > corresponding property in the device tree via device tree fixup > > Signed-off-by: Nikhil Badola > --- > Depends on http://patchwork.ozlabs.org/patch/400407/ Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl/sleep: updated the deep sleep framework for QorIQ platforms
On 11/20/2014 07:17 PM, yuantian.t...@freescale.com wrote: > From: Tang Yuantian > > With the introducing of generic board and ARM-based cores, current > deep sleep framework doesn't work anymore. > This patch will convert the current framework to adapt this change. > Basically it does: > 1. Converts all the Freescale's DDR driver to support deep sleep. > 2. Added basic framework support for ARM-based and PPC-based > cores separately. > > Signed-off-by: Tang Yuantian > --- Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 1/6] ARM: HYP/non-sec: add the pen address BE mode support.
On 11/21/2014 01:40 AM, Xiubo Li wrote: > For some SoCs, the pen address register maybe in BE mode and the > CPUs are in LE mode. > > This patch adds BE mode support for smp pen address. > > Signed-off-by: Xiubo Li > Acked-by: York Sun > --- Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/9] arm: spl: Add I2C linker list in generic .lds
On 12/02/2014 11:00 PM, Alison Wang wrote: > On LS1, DDR is initialized by reading SPD through I2C interface > in SPL code. For I2C, ll_entry_count() is called, and it returns > the number of elements of a linker-generated array placed into > subsection of .u_boot_list section specified by _list argument. > So add I2C linker list in the generic .lds to fix the issue about > using I2C in SPL. > > Signed-off-by: Alison Wang > --- > Change log: > v4: No change. > v3: No change. > v2: New file. > Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-fsl-qoriq.git master
Tom, Hold on pulling this. Sorry I just found one patch was respined but assigned to Albert. I will send another PR after I verify it. York On 12/11/2014 10:52 AM, York Sun wrote: > Tom, > > The following changes since commit 32fdf0e4d82bdca5d64d86330e461e59685f9959: > > Prepare v2015.01-rc3 (2014-12-08 16:35:08 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-fsl-qoriq.git master > > for you to fetch changes up to 0de15707a71ec64dbc1ead2831457f1550179ea7: > > kconfig: ls102xa: Change the prompt messages (2014-12-11 09:42:41 -0800) > > > Alison Wang (12): > ls102xa: pblimage: Add pblimage tool support for LS102xA > spl: Use u-boot.img instead of u-boot.bin > arm: spl: Add I2C linker list in generic .lds > kconfig: ls1021a: add SUPPORT_SPL > ls102xa: qixis: Add CONFIG_QIXIS_I2C_ACCESS macro > arm: ls102xa: Add SD boot support for LS1021AQDS board > arm: ls102xa: Add SD boot support for LS1021ATWR board > arm: ls1021a: Add CONFIG_DOS_PARTITION and CONFIG_CMD_FAT support > arm: ls102xa: Fix SD/NAND/QSPI boot defination error for QE support > arm: ls102xa: Add QSPI boot support for LS1021AQDS/TWR board > arm: ls102xa: Add NAND boot support for LS1021AQDS board > kconfig: ls102xa: Change the prompt messages > > Chenhui Zhao (1): > ls1021aqds: set the default I2C channel before DDR init > > Jaiprakash Singh (1): > driver/mtd: Fix IFC compilation warnings > > Minghuan Lian (1): > arm: ls102xa: Update PCIe dts node status > > Nikhil Badola (3): > drivers: usb: Make usb device-tree fixup code architecture independent > drivers: usb: fsl: Add USB device-tree errata framework > drivers: usb: fsl: Check USB Erratum A007792 applicability > > Tang Yuantian (2): > arm: ls102xa: fixed a bus frequency setting error > fsl/sleep: updated the deep sleep framework for QorIQ platforms > > Xiubo Li (6): > ARM: HYP/non-sec: add the pen address BE mode support. > ARM: HYP/non-sec: Fix the ARCH Timer frequency setting. > ls1021a: adding a secondary core boot address and kick functions > ls102xa: changing a few targets' configurations. > ARM: ls102xa: allow all the peripheral access permission as R/W. > ARM: ls102xa: Setting device's stream id for SMMUs. > > Yao Yuan (1): > ls1021aqds: add hwconfig setting to do pin mux > > chenhui zhao (1): > arm: ls102xa: clear EPU registers for deep sleep > > Makefile | 11 +- > arch/arm/Kconfig |6 +- > arch/arm/cpu/armv7/ls102xa/Makefile|2 + > arch/arm/cpu/armv7/ls102xa/cpu.c | 34 +++ > arch/arm/cpu/armv7/ls102xa/fdt.c |2 +- > arch/arm/cpu/armv7/ls102xa/fsl_epu.c | 57 > arch/arm/cpu/armv7/ls102xa/fsl_epu.h | 68 + > arch/arm/cpu/armv7/ls102xa/spl.c | 33 +++ > arch/arm/cpu/armv7/nonsec_virt.S |7 +- > arch/arm/cpu/u-boot-spl.lds|3 + > arch/arm/include/asm/arch-ls102xa/config.h |9 + > arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h |9 + > .../include/asm/arch-ls102xa/ls102xa_stream_id.h | 17 ++ > arch/arm/include/asm/arch-ls102xa/ns_access.h | 118 > arch/arm/include/asm/arch-ls102xa/spl.h| 20 ++ > arch/arm/include/asm/pcie_layerscape.h | 13 + > arch/powerpc/cpu/mpc8xxx/fdt.c | 104 --- > board/freescale/common/Makefile| 10 + > board/freescale/common/arm_sleep.c | 95 +++ > board/freescale/common/ls102xa_stream_id.c | 18 ++ > board/freescale/common/mpc85xx_sleep.c | 88 ++ > board/freescale/common/ns_access.c | 30 +++ > board/freescale/common/qixis.h |7 + > board/freescale/common/sleep.h | 21 ++ > board/freescale/ls1021aqds/MAINTAINERS |3 + > board/freescale/ls1021aqds/ddr.c |5 +- > board/freescale/ls1021aqds/ls1021aqds.c| 283 > ++-- > board/freescale/ls1021aqds/ls102xa_pbi.cfg | 12 + > board/freescale/ls1021aqds/ls102xa_rcw_nand.cfg|7 + > board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg | 14 + > board/freescale/ls1021atwr/MAINTAINERS |2 + > board/freescale/ls1021atwr/ls1021atwr.c| 151 +++ > board/freescale/ls1021atwr/ls102xa_pbi.cfg | 12 + > board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg | 14 + > configs/ls1021aqds_nand_defconfig |4 + > configs/ls1021aqds_qspi_defconfig |3 + > configs/ls1021aqds_sdcard_defconfig|
Re: [U-Boot] [PATCHv4 3/6] ls1021a: adding a secondary core boot address and kick functions
On 11/21/2014 01:40 AM, Xiubo Li wrote: > Define the board specific smp_set_cpu_boot_addr() function to set > the start address for secondary cores in the LS1021A specific manner. > > Define the board specific smp_kick_all_cpus() functioin to boot a > secondary core. Here the BRR contains control bits for enabling boot > for each core. On exiting HRESET or PORESET, the RCW BOOT_HO field > optionally allows for logical core 0 to be released for booting or to > remain in boot holdoff. All other cores remain in boot holdoff until > their corresponding bit is set. > > Signed-off-by: Xiubo Li > Acked-by: York Sun > --- Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 4/6] ls102xa: changing a few targets' configurations.
On 11/21/2014 01:40 AM, Xiubo Li wrote: > Enable hypervisors utilizing the ARMv7 virtualization extension > on the LS1021A-QDS/TWR boards with the A7 core tile, we add the > required configuration variable. > > Signed-off-by: Xiubo Li > Acked-by: York Sun > --- Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 6/6] ARM: ls102xa: Setting device's stream id for SMMUs.
On 11/21/2014 01:40 AM, Xiubo Li wrote: > LS1 has 4 SMMUs for address translation of the masters. All the > SMMUs' stream IDs are 8-bit. The address translation depends on the > stream ID of the incoming transaction. > Each master has unique stream ID assigned to it and is configurable > through SCFG registers. The stream ID for the masters is identical > and share the same register field of STREAM ID registers. > > Signed-off-by: Xiubo Li > Acked-by: York Sun > --- Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 5/6] ARM: ls102xa: allow all the peripheral access permission as R/W.
On 11/21/2014 01:40 AM, Xiubo Li wrote: > The Central Security Unit (CSU) allows secure world software to > change the default access control policies of peripherals/bus > slaves, determining which bus masters may access them. This > allows peripherals to be separated into distinct security domains. > Combined with SMMU configuration of the system masters privileges, > these features provide protection against indirect unauthorized > access to data. > > For now we configure all the peripheral access permissions as R/W. > > Signed-off-by: Xiubo Li > Acked-by: York Sun > --- Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] driver/mtd: Fix IFC compilation warnings
On 11/26/2014 11:08 PM, Jaiprakash Singh wrote: > From: Jaiprakash Singh > > 'eccstat' array elements might be used uninitialized > > Signed-off-by: Jaiprakash Singh > --- Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kconfig: ls102xa: Change the prompt messages
On 12/03/2014 12:18 AM, Alison Wang wrote: > As NOR/NAND/SD boot are all supported on LS1021AQDS/TWR > boards, the prompt message "Support ls1021aqds_nor" in > Kconfig is not clear. This patch changes it to > "Support ls1021aqds". > > Signed-off-by: Alison Wang > --- Applied to u-boot-fsl-qoriq master, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 respin 2/6] ARM: HYP/non-sec: Fix the ARCH Timer frequency setting.
On 11/23/2014 06:44 PM, Xiubo Li wrote: > For some SoCs, the system clock frequency may not equal to the > ARCH Timer's frequency. > > This patch uses the CONFIG_TIMER_CLK_FREQ instead of > CONFIG_SYS_CLK_FREQ, then the system clock macro and arch timer > macor could be set separately and without interfering each other. > > Signed-off-by: Xiubo Li > --- > > Hi Albert, > > I there is one mistake about the CONFIG_TIMER_CLK_FREQ defination for > sun7i platform. > > So i respin this patch separately. > > Thanks, > > BRs > Xiubo > I will have to merge the difference as a separated commit. Missed this one because it wasn't assigned to me. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/3] dts: Bring in Chrome OS keyboard device tree definition
On 5 December 2014 at 09:26, Simon Glass wrote: > Hi, > > On 5 December 2014 at 09:17, Sjoerd Simons > wrote: >> >> Hey Simon, >> >> On Thu, 2014-12-04 at 06:36 -0700, Simon Glass wrote: >> > This will be used by nyan-big, but bring it in in a separate patch since it >> > will be common to other boards. >> > >> > Signed-off-by: Simon Glass >> >> This will clash with the patch i sent last week to pull (sorry i didn't >> see your v3 for this earlier) in this dtsi & its documentation & fix >> the existing exynos users/code to correctly use it.. >> >> I'm not very familiar with how the u-boot merging process works, so i >> wonder how to best get these patches merged without unnecessary >> conflicts between e.g. the samsung/tegra trees. > > It's a race! It will be pretty easy to drop whichever one we need to. > I haven't heard anything on the Tegra side. > > Regards, > Simon As discussed with Tom Warren: Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/3] tegra: dts: Sync tegra124.dtsi with linux kernel
On 4 December 2014 at 06:36, Simon Glass wrote: > Sync this up with Linux v3.18-rc5. Exclude features that are unlikely to > supported in U-Boot soon (regulators, pinmux). Also the addresses are > updated to 32-bit. Otherwise it is the same. Also bring in the dt-bindings > for pinctrl. > > Signed-off-by: Simon Glass > Acked-by: Stephen Warren > --- > > Changes in v5: None > Changes in v4: None > Changes in v3: > - Add patch to update tegra124.dtsi from Linux v3.18-rc5 > > Changes in v2: None > > arch/arm/dts/tegra124.dtsi | 114 > > include/dt-bindings/pinctrl/pinctrl-tegra.h | 45 +++ > 2 files changed, 159 insertions(+) > create mode 100644 include/dt-bindings/pinctrl/pinctrl-tegra.h As discussed with Tom Warren: Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/3] ARM: tegra: Add support for nyan-big board
On 11 December 2014 at 09:01, Simon Glass wrote: > Hi Tom, > > On 11 December 2014 at 08:58, Tom Warren wrote: >> Simon, >> >> Feel free to do everything in the DM tree. Once DM makes it to mainline, and >> hence to ARM and Tegra, we'll be better able to add Tegra things into the >> Tegra repo. > > OK, I'll pull in the nyan-big patches to DM then I2C and retest. Applied to u-boot-dm. > >> >> Tom >> >>> -Original Message- >>> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass >>> Sent: Thursday, December 11, 2014 7:22 AM >>> To: Tom Warren >>> Cc: U-Boot Mailing List; Stephen Warren; Allen Martin; Stephen Warren; >>> Albert Aribaud >>> Subject: Re: [PATCH v5 3/3] ARM: tegra: Add support for nyan-big board >>> >>> Hi Tom, >>> >>> On 10 December 2014 at 14:45, Simon Glass wrote: >>> > >>> > Hi Tom, >>> > >>> > On 10 December 2014 at 14:09, Tom Warren >>> wrote: >>> > > Simon, >>> > > >>> > >> -Original Message- >>> > >> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon >>> > >> Glass >>> > >> Sent: Wednesday, December 10, 2014 2:04 PM >>> > >> To: Tom Warren >>> > >> Cc: U-Boot Mailing List; Stephen Warren; Allen Martin; Stephen >>> > >> Warren; Albert Aribaud >>> > >> Subject: Re: [PATCH v5 3/3] ARM: tegra: Add support for nyan-big >>> > >> board >>> > >> >>> > >> Hi Tom, >>> > >> >>> > >> On 10 December 2014 at 12:36, Simon Glass >>> wrote: >>> > >> > Hi Tom, >>> > >> > >>> > >> > On Dec 10, 2014 12:05 PM, "Tom Warren" >>> wrote: >>> > >> >> >>> > >> >> Simon, >>> > >> >> >>> > >> >> > -Original Message- >>> > >> >> > From: s...@google.com [mailto:s...@google.com] On Behalf Of >>> > >> >> > Simon Glass >>> > >> >> > Sent: Wednesday, December 10, 2014 10:50 AM >>> > >> >> > To: Tom Warren >>> > >> >> > Cc: U-Boot Mailing List; Allen Martin; Albert Aribaud; Stephen >>> > >> >> > Warren; Stephen Warren >>> > >> >> > Subject: Re: [PATCH v5 3/3] ARM: tegra: Add support for >>> > >> >> > nyan-big board >>> > >> >> > >>> > >> >> > Hi Tom, >>> > >> >> > >>> > >> >> > >>> > >> >> > On 10 December 2014 at 10:39, Tom Warren >>> >>> > >> wrote: >>> > >> >> > > Simon, >>> > >> >> > > >>> > >> >> > > The v4 PCIE patch series fails to apply to >>> > >> >> > > u-boot-tegra/master after >>> > >> >> > rebasing my repo against both ARM master and U-Boot 'master' >>> > >> >> > master (i.e. >>> > >> >> > FETCH_HEAD = >>> > >> >> > > 32fdf0e4d82bdca5d64d86330e461e59685f9959branch >>> 'master' of >>> > >> >> > git://git.denx.de/u-boot). 3 - 4 patches fail when using git am. >>> > >> >> > > >>> > >> >> > > I worked thru the conflicts for both branches (my master >>> > >> >> > > rebased against >>> > >> >> > ARM and U-Boot TOT), and did a MAKEALL -s tegra, and >>> > >> >> > jetson-tk1, beaver and cardhu fail to build (jetson err log >>> > >> >> > below). Looks like you developed this with your DM I2C series in >>> place? >>> > >> >> > > >>> > >> >> > > To submit a PR from the Tegra repo, I need to either rebase >>> > >> >> > > first against >>> > >> >> > ARM master (my SOP), or against U-Boot 'master'. So you >>> > >> >> > patches, if they're bound for the Tegra repo, need to work in >>> > >> >> > one of those scenarios. >>> > >> >> > > >>> > >> >> > > Tom >>> > >> >> > >>> > >> >> > Thanks for looking at it. This series depends on the I2C >>> > >> >> > driver model series. >>> > >> >> > It's available at u-boot-dm/i2c-working if you want to check >>> > >> >> > it out. I plan to apply that very soon. >>> > >> >> > >>> > >> >> > I'm sorry I didn't make that clear in this series. I mentioned >>> > >> >> > it on the list at one point but should have added it here. If >>> > >> >> > you like, you could ack it and I can apply to u-boot-dm after >>> > >> >> > I2C is in there. >>> > >> >> I can't ACK something that I can't get to apply to my repo nor >>> > >> >> build nor test. So you'll have to wait on that from Stephen, >>> > >> >> Thierry (based on code >>> > >> >> review) or someone that wants to add DM I2C to Tegra, apply your >>> > >> >> PCIe patches, and test. That's not my normal workflow, though, >>> > >> >> and I don't have the BW to devote to extra hurdles right now. >>> > >> >> >>> > >> > >>> > >> > You could try applying to u-boot-dm/i2c-working. It only has the >>> > >> > DM i2c series in it, plus Tegra stuff. I put a lot of time into >>> > >> > cleaning up this Tegra series to save you and Thierry time. >>> > >> >>> > >> Also Thierry took a look the PCIe series and responded here: >>> > >> >>> > >> http://patchwork.ozlabs.org/patch/410175/ >>> > >> >>> > >> There were three nits which I have addressed. >>> > >> >>> > >> For this Nyan-big patch I really don't need a test credit (would be >>> > >> nice, but not necessary). After all it's a new board and if >>> > >> problems are found they can be fixed. But I do need to apply it before >>> DM I2C. >>> > >> Stephen has looked at a few revs. >>> > >> >>> > >> How about this for a plan: >>> > >> >>
Re: [U-Boot] [PATCH] mtd: nand: revive "nand scrub" command
On Thu, 2014-12-11 at 19:49 +0900, Masahiro Yamada wrote: > Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14), > the "nand scrub" command has not been working. > > The scrub is a U-Boot extension and we have to modify nand_base.c > that originates in Linux. > > Mark the code with #ifdef __UBOOT__ so we will never accidentally > drop it when we re-sync the NAND framework with Linux in the future. No more "#ifdef __UBOOT__" please. Instead, never again do a "start from scratch" resync the way that the above commit was done. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-fsl-qoriq.git master
Tom, This replace PR sent earlier today. The following changes since commit 32fdf0e4d82bdca5d64d86330e461e59685f9959: Prepare v2015.01-rc3 (2014-12-08 16:35:08 -0500) are available in the git repository at: git://git.denx.de/u-boot-fsl-qoriq.git master for you to fetch changes up to d0419f400af6f4bbe5c4ee5c97f6fbbdedec6cf3: ARM: HYP/non-sec: Fix the ARCH Timer frequency setting for sun7i (2014-12-11 12:37:42 -0800) Alison Wang (12): ls102xa: pblimage: Add pblimage tool support for LS102xA spl: Use u-boot.img instead of u-boot.bin arm: spl: Add I2C linker list in generic .lds kconfig: ls1021a: add SUPPORT_SPL ls102xa: qixis: Add CONFIG_QIXIS_I2C_ACCESS macro arm: ls102xa: Add SD boot support for LS1021AQDS board arm: ls102xa: Add SD boot support for LS1021ATWR board arm: ls1021a: Add CONFIG_DOS_PARTITION and CONFIG_CMD_FAT support arm: ls102xa: Fix SD/NAND/QSPI boot defination error for QE support arm: ls102xa: Add QSPI boot support for LS1021AQDS/TWR board arm: ls102xa: Add NAND boot support for LS1021AQDS board kconfig: ls102xa: Change the prompt messages Chenhui Zhao (1): ls1021aqds: set the default I2C channel before DDR init Jaiprakash Singh (1): driver/mtd: Fix IFC compilation warnings Minghuan Lian (1): arm: ls102xa: Update PCIe dts node status Nikhil Badola (3): drivers: usb: Make usb device-tree fixup code architecture independent drivers: usb: fsl: Add USB device-tree errata framework drivers: usb: fsl: Check USB Erratum A007792 applicability Tang Yuantian (2): arm: ls102xa: fixed a bus frequency setting error fsl/sleep: updated the deep sleep framework for QorIQ platforms Xiubo Li (7): ARM: HYP/non-sec: add the pen address BE mode support. ARM: HYP/non-sec: Fix the ARCH Timer frequency setting. ls1021a: adding a secondary core boot address and kick functions ls102xa: changing a few targets' configurations. ARM: ls102xa: allow all the peripheral access permission as R/W. ARM: ls102xa: Setting device's stream id for SMMUs. ARM: HYP/non-sec: Fix the ARCH Timer frequency setting for sun7i Yao Yuan (1): ls1021aqds: add hwconfig setting to do pin mux chenhui zhao (1): arm: ls102xa: clear EPU registers for deep sleep Makefile | 11 +- arch/arm/Kconfig |6 +- arch/arm/cpu/armv7/ls102xa/Makefile|2 + arch/arm/cpu/armv7/ls102xa/cpu.c | 34 +++ arch/arm/cpu/armv7/ls102xa/fdt.c |2 +- arch/arm/cpu/armv7/ls102xa/fsl_epu.c | 57 arch/arm/cpu/armv7/ls102xa/fsl_epu.h | 68 + arch/arm/cpu/armv7/ls102xa/spl.c | 33 +++ arch/arm/cpu/armv7/nonsec_virt.S |7 +- arch/arm/cpu/u-boot-spl.lds|3 + arch/arm/include/asm/arch-ls102xa/config.h |9 + arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h |9 + .../include/asm/arch-ls102xa/ls102xa_stream_id.h | 17 ++ arch/arm/include/asm/arch-ls102xa/ns_access.h | 118 arch/arm/include/asm/arch-ls102xa/spl.h| 20 ++ arch/arm/include/asm/pcie_layerscape.h | 13 + arch/powerpc/cpu/mpc8xxx/fdt.c | 104 --- board/freescale/common/Makefile| 10 + board/freescale/common/arm_sleep.c | 95 +++ board/freescale/common/ls102xa_stream_id.c | 18 ++ board/freescale/common/mpc85xx_sleep.c | 88 ++ board/freescale/common/ns_access.c | 30 +++ board/freescale/common/qixis.h |7 + board/freescale/common/sleep.h | 21 ++ board/freescale/ls1021aqds/MAINTAINERS |3 + board/freescale/ls1021aqds/ddr.c |5 +- board/freescale/ls1021aqds/ls1021aqds.c| 283 ++-- board/freescale/ls1021aqds/ls102xa_pbi.cfg | 12 + board/freescale/ls1021aqds/ls102xa_rcw_nand.cfg|7 + board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg | 14 + board/freescale/ls1021atwr/MAINTAINERS |2 + board/freescale/ls1021atwr/ls1021atwr.c| 151 +++ board/freescale/ls1021atwr/ls102xa_pbi.cfg | 12 + board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg | 14 + configs/ls1021aqds_nand_defconfig |4 + configs/ls1021aqds_qspi_defconfig |3 + configs/ls1021aqds_sdcard_defconfig|4 + configs/ls1021atwr_qspi_defconfig |3 + configs/ls1021atwr_sdcard_defconfig|4 + drivers/ddr/fsl/arm_ddr_gen3.c | 45 +++- drivers/ddr/fsl/fsl_ddr_gen4.c | 44 ++
Re: [U-Boot] [PATCHv4 respin 2/6] ARM: HYP/non-sec: Fix the ARCH Timer frequency setting.
On 12/11/2014 11:39 AM, York Sun wrote: > On 11/23/2014 06:44 PM, Xiubo Li wrote: >> For some SoCs, the system clock frequency may not equal to the >> ARCH Timer's frequency. >> >> This patch uses the CONFIG_TIMER_CLK_FREQ instead of >> CONFIG_SYS_CLK_FREQ, then the system clock macro and arch timer >> macor could be set separately and without interfering each other. >> >> Signed-off-by: Xiubo Li >> --- >> >> Hi Albert, >> >> I there is one mistake about the CONFIG_TIMER_CLK_FREQ defination for >> sun7i platform. >> >> So i respin this patch separately. >> >> Thanks, >> >> BRs >> Xiubo >> > > I will have to merge the difference as a separated commit. Missed this one > because it wasn't assigned to me. > The difference is applied to u-boot-fsl-qoriq master as ARM: HYP/non-sec: Fix the ARCH Timer frequency setting for sun7i Awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 2/6] ARM: HYP/non-sec: Fix the ARCH Timer frequency setting.
On 11/21/2014 01:40 AM, Xiubo Li wrote: > For some SoCs, the system clock frequency may not equal to the > ARCH Timer's frequency. > > This patch uses the CONFIG_TIMER_CLK_FREQ instead of > CONFIG_SYS_CLK_FREQ, then the system clock macro and arch timer > macor could be set separately and without interfering each other. > > Signed-off-by: Xiubo Li > Acked-by: York Sun > --- Applied to u-boot-fsl-qoriq master, awaiting upstream. This patch has been respined, the difference is applied as a separated commit. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: revive "nand scrub" command
On Thursday, December 11, 2014 at 09:37:10 PM, Scott Wood wrote: > On Thu, 2014-12-11 at 19:49 +0900, Masahiro Yamada wrote: > > Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14), > > the "nand scrub" command has not been working. > > > > The scrub is a U-Boot extension and we have to modify nand_base.c > > that originates in Linux. > > > > Mark the code with #ifdef __UBOOT__ so we will never accidentally > > drop it when we re-sync the NAND framework with Linux in the future. > > No more "#ifdef __UBOOT__" please. Do you happen to have a helpful suggestion how to clearly mark those bits of code then please ? > Instead, never again do a "start > from scratch" resync the way that the above commit was done. This was already discussed, no need to revive this topic here now. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: revive "nand scrub" command
On Thu, 2014-12-11 at 22:37 +0100, Marek Vasut wrote: > On Thursday, December 11, 2014 at 09:37:10 PM, Scott Wood wrote: > > On Thu, 2014-12-11 at 19:49 +0900, Masahiro Yamada wrote: > > > Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14), > > > the "nand scrub" command has not been working. > > > > > > The scrub is a U-Boot extension and we have to modify nand_base.c > > > that originates in Linux. > > > > > > Mark the code with #ifdef __UBOOT__ so we will never accidentally > > > drop it when we re-sync the NAND framework with Linux in the future. > > > > No more "#ifdef __UBOOT__" please. > > Do you happen to have a helpful suggestion how to clearly mark those bits of > code then please ? This was already discussed. :-) See the archives for why I think this is bad. > > Instead, never again do a "start > > from scratch" resync the way that the above commit was done. > > This was already discussed, no need to revive this topic here now. Sorry, but these patches fixing breakages that resulted from that merge demonstrate that there is a need to revive it, if there's anyone that still thinks it's a good idea -- Heiko seemed to be in agreement that there's no need to do that for future syncs: http://lists.denx.de/pipermail/u-boot/2014-November/194256.html -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
Hi Przemyslaw, On 11 December 2014 at 05:01, Przemyslaw Marczak wrote: > > The present fat implementation ignores FAT16 long name > directory entries which aren't placed in a single sector. > > This was becouse of the buffer was always filled by the > two sectors, and the loop was made also for two sectors. > > If some file long name entries are stored in two sectors, > the we have two cases: > > Case 1: > Both of sectors are in the buffer - all required data > for long file name is in the buffer. > - Read OK! > > Case 2: > The current directory entry is placed at the end of the > second buffered sector. And the next entries are placed > in a sector which is not buffered yet. Then two next > sectors are buffered and the mentioned entry is ignored. > - Read fail! > > This commit fixes this issue by: > - read two sectors after loop on each single is done > - keep the last used sector as a first in the buffer > before the read of two next > > The commit doesn't affects the fat32 imlementation, > which works good as previous. This is very interesting\! Is this the same failure that I saw on this thread? http://u-boot.10912.n7.nabble.com/PATCH-U-Boot-ARM-rpi-b-detect-board-revision-td196720.html (search for fatload) "I tried this out. It worked OK for me except that it can't find the device tree file bcm2835-rpi-b-rev2.dtb. Oddly I can fatload it from /bcm2835-rpi-b-rev2.dtb but when I try from /syslinux/..//bcm2835-rpi-b-rev2.dtb it fails and cannot find the file. Reducing the filename length to 8 chars works. I wonder what year of my life FAT will stop plaguing me? " Also can you write a test for this in test/fs/fs-test.sh? Regards, Simon [snip] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-dm
Hi Tom Rini, Here is the I2C driver model work at last along with the first conversion. The following changes since commit 9b416a9f4ca7cf5ac4d5f7143d67edde7f7d7326: Merge branch 'master' of git://www.denx.de/git/u-boot-imx (2014-12-10 09:07:25 -0500) are available in the git repository at: git://git.denx.de/u-boot-dm.git for you to fetch changes up to b0e6ef46405353270595ffa35c21f4334c541189: dm: i2c: tegra: Convert to driver model (2014-12-11 13:18:44 -0700) Allen Martin (1): ARM: tegra: Add support for nyan-big board Masahiro Yamada (2): lib: string: move strlcpy() to a common place dm_test: improve the appearance shown by "dm tree" command Przemyslaw Marczak (1): lib: errno: introduce errno_str(): returns errno related message Simon Glass (15): dm: serial_pl01x: Add missing private data size dm: rpi: Move serial to driver model dm: i2c: Add a uclass for I2C dm: i2c: Implement driver model support in the i2c command dm: i2c: Add I2C emulation driver for sandbox dm: i2c: Add a sandbox I2C driver dm: i2c: Add an I2C EEPROM simulator dm: i2c: config: Enable I2C for sandbox using driver model dm: i2c: dts: Add an I2C bus for sandbox dm: Add a simple EEPROM driver dm: i2c: Add tests for I2C dm: device: Add newline to debug() messages dts: Bring in Chrome OS keyboard device tree definition tegra: dts: Sync tegra124.dtsi with linux kernel dm: i2c: tegra: Convert to driver model arch/arm/cpu/armv7/tegra124/Kconfig| 10 +++ arch/arm/cpu/tegra20-common/pmu.c | 21 +++-- arch/arm/dts/Makefile | 1 + arch/arm/dts/cros-ec-keyboard.dtsi | 105 +++ arch/arm/dts/tegra124-jetson-tk1.dts | 1 - arch/arm/dts/tegra124-nyan-big.dts | 365 arch/arm/dts/tegra124.dtsi | 114 + arch/arm/dts/tegra30-tec-ng.dts| 4 + arch/arm/include/asm/arch-tegra/tegra_i2c.h| 2 +- arch/sandbox/dts/sandbox.dts | 17 arch/sandbox/include/asm/test.h| 26 ++ board/avionic-design/common/tamonten-ng.c | 12 ++- board/nvidia/cardhu/cardhu.c | 13 ++- board/nvidia/common/board.c| 4 - board/nvidia/dalmore/dalmore.c | 21 +++-- board/nvidia/nyan-big/Kconfig | 24 ++ board/nvidia/nyan-big/MAINTAINERS | 6 ++ board/nvidia/nyan-big/Makefile | 9 ++ board/nvidia/nyan-big/nyan-big.c | 27 ++ board/nvidia/nyan-big/pinmux-config-nyan-big.h | 287 +++ board/nvidia/venice2/as3722_init.h | 2 +- board/nvidia/whistler/whistler.c | 29 --- board/raspberrypi/rpi/rpi.c| 12 +++ board/toradex/apalis_t30/apalis_t30.c | 19 ++--- common/cmd_i2c.c | 376 +++ configs/nyan-big_defconfig | 5 ++ drivers/core/device.c | 6 +- drivers/i2c/Makefile | 2 + drivers/i2c/i2c-emul-uclass.c | 14 drivers/i2c/i2c-uclass.c | 466 +++ drivers/i2c/sandbox_i2c.c | 111 + drivers/i2c/tegra_i2c.c| 366 +++-- drivers/misc/Makefile | 4 + drivers/misc/i2c_eeprom.c | 51 drivers/misc/i2c_eeprom_emul.c | 168 + drivers/power/tps6586x.c | 27 ++ drivers/serial/serial_pl01x.c | 1 + drivers/usb/gadget/ether.c | 24 -- include/config_fallbacks.h | 6 ++ include/configs/apalis_t30.h | 3 - include/configs/beaver.h | 3 - include/configs/cardhu.h | 5 -- include/configs/colibri_t30.h | 3 - include/configs/dalmore.h | 5 -- include/configs/jetson-tk1.h | 5 -- include/configs/nyan-big.h | 74 + include/configs/rpi.h | 6 +- include/configs/sandbox.h | 6 ++ include/configs/seaboard.h | 3 - include/configs/tec-ng.h | 5
Re: [U-Boot] [PULL] u-boot-usb/master
On Thu, Dec 11, 2014 at 01:54:19PM +0100, Marek Vasut wrote: > Hi Tom, > > minor USB fixes. > > The following changes since commit 0d485b9095328cdc81b2ee94ff59b988c69b9127: > > Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2014-11-13 > 10:35:13 > -0500) > > are available in the git repository at: > > > git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to 0c6de8853b2571251fdefe34598e0c344fe1372b: > > usb: ehci: do not set the LSB of Current qTD pointer (2014-11-19 23:31:54 > +0100) > 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] Please pull u-boot-fsl-qoriq.git master
On Thu, Dec 11, 2014 at 12:41:00PM -0800, York Sun wrote: > Tom, > > This replace PR sent earlier today. > > The following changes since commit 32fdf0e4d82bdca5d64d86330e461e59685f9959: > > Prepare v2015.01-rc3 (2014-12-08 16:35:08 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-fsl-qoriq.git master > > for you to fetch changes up to d0419f400af6f4bbe5c4ee5c97f6fbbdedec6cf3: > > ARM: HYP/non-sec: Fix the ARCH Timer frequency setting for sun7i (2014-12-11 > 12:37:42 -0800) > 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] dm: sh: serial: Add support driver model
Hi,
Thanks for your review.
2014-12-11 13:49 GMT+09:00 Simon Glass :
> Hi Nobuhiro,
>
> On 9 December 2014 at 22:44, Nobuhiro Iwamatsu
> wrote:
>> This adds driver model support with this driver. This was tested by Koelsch
>> board and Gose board.
>>
>> Signed-off-by: Nobuhiro Iwamatsu
>> ---
>> drivers/serial/serial_sh.c | 299
>> ---
>> drivers/serial/serial_sh.h | 10 +-
>> include/dm/platform_data/serial_sh.h | 37 +
>> 3 files changed, 245 insertions(+), 101 deletions(-)
>> create mode 100644 include/dm/platform_data/serial_sh.h
>>
>
> Nice to see this patch.
>
>> diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
>> index 7c1f271..dd5f9bf 100644
>> --- a/drivers/serial/serial_sh.c
>> +++ b/drivers/serial/serial_sh.c
>> @@ -1,78 +1,20 @@
>> /*
>> * SuperH SCIF device driver.
>> * Copyright (C) 2013 Renesas Electronics Corporation
>> - * Copyright (C) 2007,2008,2010 Nobuhiro Iwamatsu
>> + * Copyright (C) 2007,2008,2010, 2014 Nobuhiro Iwamatsu
>> * Copyright (C) 2002 - 2008 Paul Mundt
>> *
>> * SPDX-License-Identifier:GPL-2.0+
>> */
>>
>> #include
>> +#include
>> #include
>> #include
>> -#include "serial_sh.h"
>> #include
>> #include
>> -
>> -#if defined(CONFIG_CONS_SCIF0)
>> -# define SCIF_BASE SCIF0_BASE
>> -#elif defined(CONFIG_CONS_SCIF1)
>> -# define SCIF_BASE SCIF1_BASE
>> -#elif defined(CONFIG_CONS_SCIF2)
>> -# define SCIF_BASE SCIF2_BASE
>> -#elif defined(CONFIG_CONS_SCIF3)
>> -# define SCIF_BASE SCIF3_BASE
>> -#elif defined(CONFIG_CONS_SCIF4)
>> -# define SCIF_BASE SCIF4_BASE
>> -#elif defined(CONFIG_CONS_SCIF5)
>> -# define SCIF_BASE SCIF5_BASE
>> -#elif defined(CONFIG_CONS_SCIF6)
>> -# define SCIF_BASE SCIF6_BASE
>> -#elif defined(CONFIG_CONS_SCIF7)
>> -# define SCIF_BASE SCIF7_BASE
>> -#else
>> -# error "Default SCIF doesn't set."
>> -#endif
>> -
>> -#if defined(CONFIG_SCIF_A)
>> - #define SCIF_BASE_PORT PORT_SCIFA
>> -#else
>> - #define SCIF_BASE_PORT PORT_SCIF
>> -#endif
>> -
>> -static struct uart_port sh_sci = {
>> - .membase= (unsigned char*)SCIF_BASE,
>> - .mapbase= SCIF_BASE,
>> - .type = SCIF_BASE_PORT,
>> -};
>> -
>> -static void sh_serial_setbrg(void)
>> -{
>> - DECLARE_GLOBAL_DATA_PTR;
>> -#ifdef CONFIG_SCIF_USE_EXT_CLK
>> - unsigned short dl = DL_VALUE(gd->baudrate, CONFIG_SH_SCIF_CLK_FREQ);
>> - sci_out(&sh_sci, DL, dl);
>> - /* Need wait: Clock * 1/dl × 1/16 */
>> - udelay((100 * dl * 16 / CONFIG_SYS_CLK_FREQ) * 1000 + 1);
>> -#else
>> - sci_out(&sh_sci, SCBRR,
>> - SCBRR_VALUE(gd->baudrate, CONFIG_SH_SCIF_CLK_FREQ));
>> -#endif
>> -}
>> -
>> -static int sh_serial_init(void)
>> -{
>> - sci_out(&sh_sci, SCSCR , SCSCR_INIT(&sh_sci));
>> - sci_out(&sh_sci, SCSCR , SCSCR_INIT(&sh_sci));
>> - sci_out(&sh_sci, SCSMR, 0);
>> - sci_out(&sh_sci, SCSMR, 0);
>> - sci_out(&sh_sci, SCFCR, SCFCR_RFRST|SCFCR_TFRST);
>> - sci_in(&sh_sci, SCFCR);
>> - sci_out(&sh_sci, SCFCR, 0);
>> -
>> - serial_setbrg();
>> - return 0;
>> -}
>> +#include
>> +#include "serial_sh.h"
>>
>> #if defined(CONFIG_CPU_SH7760) || \
>> defined(CONFIG_CPU_SH7780) || \
>> @@ -109,83 +51,249 @@ static int scif_rxfill(struct uart_port *port)
>> }
>> #endif
>>
>> -static int serial_rx_fifo_level(void)
>> +static void sh_serial_init_generic(struct uart_port *port)
>> +{
>> + sci_out(port, SCSCR , SCSCR_INIT(port));
>> + sci_out(port, SCSCR , SCSCR_INIT(port));
>> + sci_out(port, SCSMR, 0);
>> + sci_out(port, SCSMR, 0);
>> + sci_out(port, SCFCR, SCFCR_RFRST|SCFCR_TFRST);
>> + sci_in(port, SCFCR);
>> + sci_out(port, SCFCR, 0);
>> +}
>> +
>> +static void
>> +sh_serial_setbrg_generic(struct uart_port *port, int clk, int baudrate)
>> {
>> - return scif_rxfill(&sh_sci);
>> + if (port->clk_mode == EXT_CLK) {
>> + unsigned short dl = DL_VALUE(baudrate, clk);
>> + sci_out(port, DL, dl);
>> + /* Need wait: Clock * 1/dl × 1/16 */
>> + udelay((100 * dl * 16 / clk) * 1000 + 1);
>> + } else {
>> + sci_out(port, SCBRR, SCBRR_VALUE(baudrate, clk));
>> + }
>> }
>>
>> -static void handle_error(void)
>> +static void handle_error(struct uart_port *port)
>> {
>> - sci_in(&sh_sci, SCxSR);
>> - sci_out(&sh_sci, SCxSR, SCxSR_ERROR_CLEAR(&sh_sci));
>> - sci_in(&sh_sci, SCLSR);
>> - sci_out(&sh_sci, SCLSR, 0x00);
>> + sci_in(port, SCxSR);
>> + sci_out(port, SCxSR, SCxSR_ERROR_CLEAR(port));
>> + sci_in(port, SCLSR);
>> + sci_out(port, SCLSR, 0x00);
>> }
>>
>> -static void serial_raw_putc(const char c)
>> +static void serial_raw_putc(struct uart_port *port, const char c)
>> {
>> while (1) {
>> /* Tx fifo is empty */
>> -
[U-Boot] [PATCH v2] dm: sh: serial: Add support driver model
This adds driver model support with this driver. This was tested by Koelsch
board and Gose board.
Signed-off-by: Nobuhiro Iwamatsu
---
V2: Fix loop for tx fifo and tx fifo.
Fix write return code writing with DM.
drivers/serial/serial_sh.c | 311 ---
drivers/serial/serial_sh.h | 10 +-
include/dm/platform_data/serial_sh.h | 37 +
3 files changed, 252 insertions(+), 106 deletions(-)
create mode 100644 include/dm/platform_data/serial_sh.h
diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 7c1f271..882c147 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -1,78 +1,21 @@
/*
* SuperH SCIF device driver.
* Copyright (C) 2013 Renesas Electronics Corporation
- * Copyright (C) 2007,2008,2010 Nobuhiro Iwamatsu
+ * Copyright (C) 2007,2008,2010, 2014 Nobuhiro Iwamatsu
* Copyright (C) 2002 - 2008 Paul Mundt
*
* SPDX-License-Identifier:GPL-2.0+
*/
#include
+#include
+#include
#include
#include
-#include "serial_sh.h"
#include
#include
-
-#if defined(CONFIG_CONS_SCIF0)
-# define SCIF_BASE SCIF0_BASE
-#elif defined(CONFIG_CONS_SCIF1)
-# define SCIF_BASE SCIF1_BASE
-#elif defined(CONFIG_CONS_SCIF2)
-# define SCIF_BASE SCIF2_BASE
-#elif defined(CONFIG_CONS_SCIF3)
-# define SCIF_BASE SCIF3_BASE
-#elif defined(CONFIG_CONS_SCIF4)
-# define SCIF_BASE SCIF4_BASE
-#elif defined(CONFIG_CONS_SCIF5)
-# define SCIF_BASE SCIF5_BASE
-#elif defined(CONFIG_CONS_SCIF6)
-# define SCIF_BASE SCIF6_BASE
-#elif defined(CONFIG_CONS_SCIF7)
-# define SCIF_BASE SCIF7_BASE
-#else
-# error "Default SCIF doesn't set."
-#endif
-
-#if defined(CONFIG_SCIF_A)
- #define SCIF_BASE_PORT PORT_SCIFA
-#else
- #define SCIF_BASE_PORT PORT_SCIF
-#endif
-
-static struct uart_port sh_sci = {
- .membase= (unsigned char*)SCIF_BASE,
- .mapbase= SCIF_BASE,
- .type = SCIF_BASE_PORT,
-};
-
-static void sh_serial_setbrg(void)
-{
- DECLARE_GLOBAL_DATA_PTR;
-#ifdef CONFIG_SCIF_USE_EXT_CLK
- unsigned short dl = DL_VALUE(gd->baudrate, CONFIG_SH_SCIF_CLK_FREQ);
- sci_out(&sh_sci, DL, dl);
- /* Need wait: Clock * 1/dl $B!_(B 1/16 */
- udelay((100 * dl * 16 / CONFIG_SYS_CLK_FREQ) * 1000 + 1);
-#else
- sci_out(&sh_sci, SCBRR,
- SCBRR_VALUE(gd->baudrate, CONFIG_SH_SCIF_CLK_FREQ));
-#endif
-}
-
-static int sh_serial_init(void)
-{
- sci_out(&sh_sci, SCSCR , SCSCR_INIT(&sh_sci));
- sci_out(&sh_sci, SCSCR , SCSCR_INIT(&sh_sci));
- sci_out(&sh_sci, SCSMR, 0);
- sci_out(&sh_sci, SCSMR, 0);
- sci_out(&sh_sci, SCFCR, SCFCR_RFRST|SCFCR_TFRST);
- sci_in(&sh_sci, SCFCR);
- sci_out(&sh_sci, SCFCR, 0);
-
- serial_setbrg();
- return 0;
-}
+#include
+#include "serial_sh.h"
#if defined(CONFIG_CPU_SH7760) || \
defined(CONFIG_CPU_SH7780) || \
@@ -109,83 +52,250 @@ static int scif_rxfill(struct uart_port *port)
}
#endif
-static int serial_rx_fifo_level(void)
+static void sh_serial_init_generic(struct uart_port *port)
+{
+ sci_out(port, SCSCR , SCSCR_INIT(port));
+ sci_out(port, SCSCR , SCSCR_INIT(port));
+ sci_out(port, SCSMR, 0);
+ sci_out(port, SCSMR, 0);
+ sci_out(port, SCFCR, SCFCR_RFRST|SCFCR_TFRST);
+ sci_in(port, SCFCR);
+ sci_out(port, SCFCR, 0);
+}
+
+static void
+sh_serial_setbrg_generic(struct uart_port *port, int clk, int baudrate)
{
- return scif_rxfill(&sh_sci);
+ if (port->clk_mode == EXT_CLK) {
+ unsigned short dl = DL_VALUE(baudrate, clk);
+ sci_out(port, DL, dl);
+ /* Need wait: Clock * 1/dl $B!_(B 1/16 */
+ udelay((100 * dl * 16 / clk) * 1000 + 1);
+ } else {
+ sci_out(port, SCBRR, SCBRR_VALUE(baudrate, clk));
+ }
}
-static void handle_error(void)
+static void handle_error(struct uart_port *port)
{
- sci_in(&sh_sci, SCxSR);
- sci_out(&sh_sci, SCxSR, SCxSR_ERROR_CLEAR(&sh_sci));
- sci_in(&sh_sci, SCLSR);
- sci_out(&sh_sci, SCLSR, 0x00);
+ sci_in(port, SCxSR);
+ sci_out(port, SCxSR, SCxSR_ERROR_CLEAR(port));
+ sci_in(port, SCLSR);
+ sci_out(port, SCLSR, 0x00);
}
-static void serial_raw_putc(const char c)
+static int serial_raw_putc(struct uart_port *port, const char c)
{
- while (1) {
- /* Tx fifo is empty */
- if (sci_in(&sh_sci, SCxSR) & SCxSR_TEND(&sh_sci))
- break;
- }
+ /* Tx fifo is empty */
+ if (!(sci_in(port, SCxSR) & SCxSR_TEND(port)))
+ return -EAGAIN;
+
+ sci_out(port, SCxTDR, c);
+ sci_out(port, SCxSR, sci_in(port, SCxSR) & ~SCxSR_TEND(port));
- sci_out(&sh_sci, SCxTDR, c);
- sci_out(&sh_sci, SCxSR, sci_in(&sh_sci, SCxSR) & ~SCxSR_TEND(&sh_sci));
+ return 0;
}
-static void sh_serial_putc(c
Re: [U-Boot] [PATCH v2] dm: sh: serial: Add support driver model
On 11 December 2014 at 19:04, Nobuhiro Iwamatsu
wrote:
> This adds driver model support with this driver. This was tested by Koelsch
> board and Gose board.
>
> Signed-off-by: Nobuhiro Iwamatsu
> ---
> V2: Fix loop for tx fifo and tx fifo.
> Fix write return code writing with DM.
Acked-by: Simon Glass
But see question below.
>
> drivers/serial/serial_sh.c | 311
> ---
> drivers/serial/serial_sh.h | 10 +-
> include/dm/platform_data/serial_sh.h | 37 +
> 3 files changed, 252 insertions(+), 106 deletions(-)
> create mode 100644 include/dm/platform_data/serial_sh.h
>
> diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
> index 7c1f271..882c147 100644
> --- a/drivers/serial/serial_sh.c
> +++ b/drivers/serial/serial_sh.c
> @@ -1,78 +1,21 @@
> /*
> * SuperH SCIF device driver.
> * Copyright (C) 2013 Renesas Electronics Corporation
> - * Copyright (C) 2007,2008,2010 Nobuhiro Iwamatsu
> + * Copyright (C) 2007,2008,2010, 2014 Nobuhiro Iwamatsu
> * Copyright (C) 2002 - 2008 Paul Mundt
> *
> * SPDX-License-Identifier:GPL-2.0+
> */
>
> #include
> +#include
> +#include
> #include
> #include
> -#include "serial_sh.h"
> #include
> #include
> -
> -#if defined(CONFIG_CONS_SCIF0)
> -# define SCIF_BASE SCIF0_BASE
> -#elif defined(CONFIG_CONS_SCIF1)
> -# define SCIF_BASE SCIF1_BASE
> -#elif defined(CONFIG_CONS_SCIF2)
> -# define SCIF_BASE SCIF2_BASE
> -#elif defined(CONFIG_CONS_SCIF3)
> -# define SCIF_BASE SCIF3_BASE
> -#elif defined(CONFIG_CONS_SCIF4)
> -# define SCIF_BASE SCIF4_BASE
> -#elif defined(CONFIG_CONS_SCIF5)
> -# define SCIF_BASE SCIF5_BASE
> -#elif defined(CONFIG_CONS_SCIF6)
> -# define SCIF_BASE SCIF6_BASE
> -#elif defined(CONFIG_CONS_SCIF7)
> -# define SCIF_BASE SCIF7_BASE
> -#else
> -# error "Default SCIF doesn't set."
> -#endif
> -
> -#if defined(CONFIG_SCIF_A)
> - #define SCIF_BASE_PORT PORT_SCIFA
> -#else
> - #define SCIF_BASE_PORT PORT_SCIF
> -#endif
> -
> -static struct uart_port sh_sci = {
> - .membase= (unsigned char*)SCIF_BASE,
> - .mapbase= SCIF_BASE,
> - .type = SCIF_BASE_PORT,
> -};
> -
> -static void sh_serial_setbrg(void)
> -{
> - DECLARE_GLOBAL_DATA_PTR;
> -#ifdef CONFIG_SCIF_USE_EXT_CLK
> - unsigned short dl = DL_VALUE(gd->baudrate, CONFIG_SH_SCIF_CLK_FREQ);
> - sci_out(&sh_sci, DL, dl);
> - /* Need wait: Clock * 1/dl × 1/16 */
> - udelay((100 * dl * 16 / CONFIG_SYS_CLK_FREQ) * 1000 + 1);
> -#else
> - sci_out(&sh_sci, SCBRR,
> - SCBRR_VALUE(gd->baudrate, CONFIG_SH_SCIF_CLK_FREQ));
> -#endif
> -}
> -
> -static int sh_serial_init(void)
> -{
> - sci_out(&sh_sci, SCSCR , SCSCR_INIT(&sh_sci));
> - sci_out(&sh_sci, SCSCR , SCSCR_INIT(&sh_sci));
> - sci_out(&sh_sci, SCSMR, 0);
> - sci_out(&sh_sci, SCSMR, 0);
> - sci_out(&sh_sci, SCFCR, SCFCR_RFRST|SCFCR_TFRST);
> - sci_in(&sh_sci, SCFCR);
> - sci_out(&sh_sci, SCFCR, 0);
> -
> - serial_setbrg();
> - return 0;
> -}
> +#include
> +#include "serial_sh.h"
>
> #if defined(CONFIG_CPU_SH7760) || \
> defined(CONFIG_CPU_SH7780) || \
> @@ -109,83 +52,250 @@ static int scif_rxfill(struct uart_port *port)
> }
> #endif
>
> -static int serial_rx_fifo_level(void)
> +static void sh_serial_init_generic(struct uart_port *port)
> +{
> + sci_out(port, SCSCR , SCSCR_INIT(port));
> + sci_out(port, SCSCR , SCSCR_INIT(port));
> + sci_out(port, SCSMR, 0);
> + sci_out(port, SCSMR, 0);
> + sci_out(port, SCFCR, SCFCR_RFRST|SCFCR_TFRST);
> + sci_in(port, SCFCR);
> + sci_out(port, SCFCR, 0);
> +}
> +
> +static void
> +sh_serial_setbrg_generic(struct uart_port *port, int clk, int baudrate)
> {
> - return scif_rxfill(&sh_sci);
> + if (port->clk_mode == EXT_CLK) {
> + unsigned short dl = DL_VALUE(baudrate, clk);
> + sci_out(port, DL, dl);
> + /* Need wait: Clock * 1/dl × 1/16 */
> + udelay((100 * dl * 16 / clk) * 1000 + 1);
> + } else {
> + sci_out(port, SCBRR, SCBRR_VALUE(baudrate, clk));
> + }
> }
>
> -static void handle_error(void)
> +static void handle_error(struct uart_port *port)
> {
> - sci_in(&sh_sci, SCxSR);
> - sci_out(&sh_sci, SCxSR, SCxSR_ERROR_CLEAR(&sh_sci));
> - sci_in(&sh_sci, SCLSR);
> - sci_out(&sh_sci, SCLSR, 0x00);
> + sci_in(port, SCxSR);
> + sci_out(port, SCxSR, SCxSR_ERROR_CLEAR(port));
> + sci_in(port, SCLSR);
> + sci_out(port, SCLSR, 0x00);
> }
>
> -static void serial_raw_putc(const char c)
> +static int serial_raw_putc(struct uart_port *port, const char c)
> {
> - while (1) {
> - /* Tx fifo is empty */
> - if (sci_in(&sh_sci, SCxSR) & SCxSR_TEND(&sh_sci))
> - break;
> - }
> +
Re: [U-Boot] [PATCH v2 15/27] x86: Integrate Tunnel Creek processor microcode
Hi Simon, On Thu, Dec 11, 2014 at 11:50 PM, Simon Glass wrote: > Hi Bin, > > On 11 December 2014 at 08:01, Bin Meng wrote: >> Hi Simon, >> >> On Thu, Dec 11, 2014 at 10:34 PM, Simon Glass wrote: >>> Hi Bin, >>> >>> On 9 December 2014 at 23:24, Simon Glass wrote: Hi Bin. On 9 December 2014 at 23:17, Bin Meng wrote: > Hi Simon, > > On Wed, Dec 10, 2014 at 2:09 PM, Simon Glass wrote: >> Hi Bin, >> >> On 9 December 2014 at 07:50, Bin Meng wrote: >>> Integrate the processor microcode version 1.05 for Tunnel Creek, >>> CPUID device 20661h. >>> >>> Signed-off-by: Bin Meng >>> --- >>> >>> Changes in v2: None >> >> We are going to end up with microcode both in the device tree and in >> an assembler include file. >> >> This seems unfortunate. I wonder if we can always put it in the device >> tree, but then optionally also compile it into the image using a >> symbol (as we do in dts/Makefile for CONFIG_OF_EMBED). This could be >> done with fdtget to read the binary output of the property perhaps. I >> haven't looked at it in detail though. >> > > This will do for the embedded case, but it won't help for the separate > dtb case. > >> Maybe this is too clumsy but it would be good to have it in one >> format. Or maybe we should have a tool which can generate either >> format. > > I don't think we are able to parse device tree in that early phase > (before car_init), to get the microcode content from dtb. I know in > some Intel processors, the microcode update are required before CAR > initialization, as without the microcode update, the CAR > initialization will fail. Right, I meant that we could perhaps do this in the build system - i.e. compile in the microcode after reading it from the device tree. Not thrilled with the idea... >>> >>> I wonder if we could do this: >>> >>> 1. Put the microcode in a .dtsi file, perhaps with a tool to do this >>> automatically. >>> 3. Build the board >>> 2. Use something like this to extract the hex data manualy: >> >> 'manually' means we don't let the build system to do this 'automatically'? > > For now, since I suspect automatically might be hard for you. > >> >>> >>> fdtget -tx /path/to/u-boot.dtb /microcode/update@0 data | sed 's/ /, 0x/g' >>> >>> then put this in a file that you compile. That way if we come up with >>> a clever solution later we can use it. Unfortunately it means >>> submitting the same microcode update in a .c format for now, but have >>> a path to fixing it. >>> >> >> Sorry I am confused. In what format should we submit the microcode >> data? Is it dtsi or .c? Intel normally releases the microcode update >> in .h format. > > We should have a tool which converts Intel's format into a device tree > .dtsi include file. I'd like that .dtsi to be the file we commit to > the U-Boot source tree. However since this is not suitable for your > platform then we need to figure out an approach to convert it to a > form you need. I believe all you really need to know is the address of > the microcode update, and I feel there must be a way to make this work > automatically in the build system. > > My suggestion above was just a short-term approach to get you unblocked. > >> >> BTW: I have cleaned up the remaining coding convention issues for ths >> FSP codes. Do you want to continue reviewing other patches in this v2, >> so that I can fix all issues in v3? Do you think we need address this >> microcode update in v3? I think we can leave this issue for this >> series, and address this microcode issue in another patch series, as >> it may touch the chromebook_link codes. > > Yes I will get to the others. Overall it all looks fine so don't > expect anything major. I'm happy to sort out the microcode in a later > series if you prefer, but we do need to fix it. Yes, we can address the microcode issue in a later series. For this v2 series, I would assume I can just send v3 with the remaining U-Boot coding convention changes and it is ready to apply? Let me know if you have different thoughts. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/27] x86: Add basic support to queensbay platform and crownbay board
Hi Bin,
On 9 December 2014 at 07:50, Bin Meng wrote:
> Implement minimum required functions for the basic support to
> queensbay platform and crownbay board.
>
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v2:
> - Replace 0xcf9 with macro PORT_RESET from processor.h
> - Move FspInit call from start.S to car_init
> - Add UART0_BASE and UART1_BASE to ibmpc.h
>
> arch/x86/cpu/queensbay/Makefile | 9
> arch/x86/cpu/queensbay/tnc.c | 48 ++
> arch/x86/cpu/queensbay/tnc_car.S | 103
> ++
> arch/x86/cpu/queensbay/tnc_dram.c | 78 +
> arch/x86/cpu/queensbay/tnc_pci.c | 61 ++
> arch/x86/include/asm/ibmpc.h | 3 ++
> board/intel/crownbay/MAINTAINERS | 6 +++
> board/intel/crownbay/Makefile | 7 +++
> board/intel/crownbay/crownbay.c | 21
> board/intel/crownbay/start.S | 9
> 10 files changed, 345 insertions(+)
> create mode 100644 arch/x86/cpu/queensbay/Makefile
> create mode 100644 arch/x86/cpu/queensbay/tnc.c
> create mode 100644 arch/x86/cpu/queensbay/tnc_car.S
> create mode 100644 arch/x86/cpu/queensbay/tnc_dram.c
> create mode 100644 arch/x86/cpu/queensbay/tnc_pci.c
> create mode 100644 board/intel/crownbay/MAINTAINERS
> create mode 100644 board/intel/crownbay/Makefile
> create mode 100644 board/intel/crownbay/crownbay.c
> create mode 100644 board/intel/crownbay/start.S
>
> diff --git a/arch/x86/cpu/queensbay/Makefile b/arch/x86/cpu/queensbay/Makefile
> new file mode 100644
> index 000..ace04ca
> --- /dev/null
> +++ b/arch/x86/cpu/queensbay/Makefile
> @@ -0,0 +1,9 @@
> +#
> +# Copyright (C) 2014, Bin Meng
> +#
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +
> +obj-y += tnc_car.o tnc_dram.o tnc.o
> +obj-y += fsp_configs.o fsp_support.o
> +obj-$(CONFIG_PCI) += tnc_pci.o
> diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c
> new file mode 100644
> index 000..b1df57a
> --- /dev/null
> +++ b/arch/x86/cpu/queensbay/tnc.c
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright (C) 2014, Bin Meng
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +int arch_cpu_init(void)
> +{
> + post_code(POST_CPU_INIT);
> +#ifdef CONFIG_SYS_X86_TSC_TIMER
> + timer_set_base(rdtsc());
> +#endif
> +
> + return x86_cpu_init_f();
> +}
> +
> +int print_cpuinfo(void)
> +{
> + post_code(POST_CPU_INFO);
> + return default_print_cpuinfo();
> +}
> +
> +void reset_cpu(ulong addr)
> +{
> + /* cold reset */
> + outb(0x06, PORT_RESET);
> +}
> +
> +void board_final_cleanup(void)
> +{
> + EFI_STATUS status;
Is this an enum? We should avoid capital types and also typedef /
#define for types.
> +
> + /* call into FspNotify */
> + debug("Calling into FSP (notify phase INIT_PHASE_BOOT): ");
> + status = fsp_notify(NULL, INIT_PHASE_BOOT);
> + if (status != FSP_SUCCESS)
> + debug("fail, error code %x\n", status);
> + else
> + debug("OK\n");
> +
> + return;
> +}
> diff --git a/arch/x86/cpu/queensbay/tnc_car.S
> b/arch/x86/cpu/queensbay/tnc_car.S
> new file mode 100644
> index 000..4f39e42
> --- /dev/null
> +++ b/arch/x86/cpu/queensbay/tnc_car.S
> @@ -0,0 +1,103 @@
> +/*
> + * Copyright (C) 2014, Bin Meng
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include
> +#include
> +
> +.globl car_init
> +car_init:
> + /*
> +* Note: ebp holds the BIST value (built-in self test) so far, but ebp
> +* will be destroyed through the FSP call, thus we have to test the
> +* BIST value here before we call into FSP.
> +*/
> + test%ebp, %ebp
> + jz car_init_start
> + post_code(POST_BIST_FAILURE)
> + jmp die
> +
> +car_init_start:
> + post_code(POST_CAR_START)
> + lea find_fsp_header_stack, %esp
> + jmp find_fsp_header
> +
> +find_fsp_header_ret:
> + /* EAX points to FSP_INFO_HEADER */
> + mov %eax, %ebp
> +
> + /* sanity test */
> + cmp $CONFIG_FSP_LOCATION, %eax
> + jb die
> +
> + /* calculate TempRamInitEntry address */
> + mov 0x30(%ebp), %eax
> + add 0x1c(%ebp), %eax
> +
> + /* call FSP TempRamInitEntry to setup temporary stack */
> + lea temp_ram_init_stack, %esp
> + jmp *%eax
> +
> +temp_ram_init_ret:
> + addl$4, %esp
> + cmp $0, %eax
> + jz continue
Can we make this jnz put the error code below instead of it being in
the normal path flow?
> + post_code(POST_CAR_FAILURE)
> +
> +die:
> + hlt
> + jmp die
> + hlt
> +
> +continue:
> + post_code(POST_CAR_CPU_CACHE)
> +
> + /*
> +* The FSP TempRamInit initializes the ecx and edx registers to
> +* point to a temporary but writable memory r
Re: [U-Boot] [PATCH v2 17/27] x86: ich6-gpio: Add Intel Tunnel Creek GPIO support
On 9 December 2014 at 07:50, Bin Meng wrote:
> Intel Tunnel Creek GPIO register block is compatible with current
> ich6-gpio driver, except the offset and content of GPIO block base
> address register in the LPC PCI configuration space are different.
>
> Use u16 instead of u32 to store the 16-bit I/O address of the GPIO
> registers so that it could support both Ivybridge and Tunnel Creek.
>
> Signed-off-by: Bin Meng
Acked-by: Simon Glass
>
> ---
>
> Changes in v2:
> - Add a comment to explain we don't need check bit0 in GPIO base
> address register
> - Add setup_pch_gpios() in crownbay.c
>
> arch/x86/include/asm/arch-queensbay/gpio.h | 13 +
> arch/x86/include/asm/gpio.h| 4 ++--
> board/coreboot/coreboot/coreboot.c | 2 +-
> board/google/chromebook_link/link.c| 2 +-
> board/intel/crownbay/crownbay.c| 5 +
> drivers/gpio/intel_ich6_gpio.c | 20
> 6 files changed, 34 insertions(+), 12 deletions(-)
> create mode 100644 arch/x86/include/asm/arch-queensbay/gpio.h
>
> diff --git a/arch/x86/include/asm/arch-queensbay/gpio.h
> b/arch/x86/include/asm/arch-queensbay/gpio.h
> new file mode 100644
> index 000..ab4e059
> --- /dev/null
> +++ b/arch/x86/include/asm/arch-queensbay/gpio.h
> @@ -0,0 +1,13 @@
> +/*
> + * Copyright (C) 2014, Bin Meng
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#ifndef _X86_ARCH_GPIO_H_
> +#define _X86_ARCH_GPIO_H_
> +
> +/* Where in config space is the register that points to the GPIO registers?
> */
> +#define PCI_CFG_GPIOBASE 0x44
> +
> +#endif /* _X86_ARCH_GPIO_H_ */
> diff --git a/arch/x86/include/asm/gpio.h b/arch/x86/include/asm/gpio.h
> index 1787e52..1099427 100644
> --- a/arch/x86/include/asm/gpio.h
> +++ b/arch/x86/include/asm/gpio.h
> @@ -11,7 +11,7 @@
> #include
>
> struct ich6_bank_platdata {
> - uint32_t base_addr;
> + uint16_t base_addr;
> const char *bank_name;
> };
>
> @@ -147,7 +147,7 @@ struct pch_gpio_map {
> } set3;
> };
>
> -void setup_pch_gpios(u32 gpiobase, const struct pch_gpio_map *gpio);
> +void setup_pch_gpios(u16 gpiobase, const struct pch_gpio_map *gpio);
> void ich_gpio_set_gpio_map(const struct pch_gpio_map *map);
>
> #endif /* _X86_GPIO_H_ */
> diff --git a/board/coreboot/coreboot/coreboot.c
> b/board/coreboot/coreboot/coreboot.c
> index b260f9a..154faf6 100644
> --- a/board/coreboot/coreboot/coreboot.c
> +++ b/board/coreboot/coreboot/coreboot.c
> @@ -16,7 +16,7 @@ int arch_early_init_r(void)
> return 0;
> }
>
> -void setup_pch_gpios(u32 gpiobase, const struct pch_gpio_map *gpio)
> +void setup_pch_gpios(u16 gpiobase, const struct pch_gpio_map *gpio)
> {
> return;
> }
> diff --git a/board/google/chromebook_link/link.c
> b/board/google/chromebook_link/link.c
> index 4d95c1c..9978e92 100644
> --- a/board/google/chromebook_link/link.c
> +++ b/board/google/chromebook_link/link.c
> @@ -125,7 +125,7 @@ int board_early_init_f(void)
> return 0;
> }
>
> -void setup_pch_gpios(u32 gpiobase, const struct pch_gpio_map *gpio)
> +void setup_pch_gpios(u16 gpiobase, const struct pch_gpio_map *gpio)
> {
> /* GPIO Set 1 */
> if (gpio->set1.level)
> diff --git a/board/intel/crownbay/crownbay.c b/board/intel/crownbay/crownbay.c
> index 8c6df98..54670d3 100644
> --- a/board/intel/crownbay/crownbay.c
> +++ b/board/intel/crownbay/crownbay.c
> @@ -19,3 +19,8 @@ int board_early_init_f(void)
>
> return 0;
> }
> +
> +void setup_pch_gpios(u16 gpiobase, const struct pch_gpio_map *gpio)
> +{
> + return;
> +}
> diff --git a/drivers/gpio/intel_ich6_gpio.c b/drivers/gpio/intel_ich6_gpio.c
> index 1f0d9df..5f67b3f 100644
> --- a/drivers/gpio/intel_ich6_gpio.c
> +++ b/drivers/gpio/intel_ich6_gpio.c
> @@ -39,9 +39,9 @@
>
> struct ich6_bank_priv {
> /* These are I/O addresses */
> - uint32_t use_sel;
> - uint32_t io_sel;
> - uint32_t lvl;
> + uint16_t use_sel;
> + uint16_t io_sel;
> + uint16_t lvl;
> };
>
> /* TODO: Move this to device tree, or platform data */
> @@ -57,7 +57,7 @@ static int gpio_ich6_ofdata_to_platdata(struct udevice *dev)
> u8 tmpbyte;
> u16 tmpword;
> u32 tmplong;
> - u32 gpiobase;
> + u16 gpiobase;
> int offset;
>
> /* Where should it be? */
> @@ -116,11 +116,15 @@ static int gpio_ich6_ofdata_to_platdata(struct udevice
> *dev)
> /*
> * GPIOBASE moved to its current offset with ICH6, but prior to
> * that it was unused (or undocumented). Check that it looks
> -* okay: not all ones or zeros, and mapped to I/O space (bit 0).
> +* okay: not all ones or zeros.
> +*
> +* Note we don't need check bit0 here, because the Tunnel Creek
> +* GPIO base address register bit0 is reserved (read returns 0),
> +* while on the Ivybridge the bit0 is used to indicate it is an
> +* I/O space.
>
Re: [U-Boot] [PATCH v2 19/27] x86: Add queensbay and crownbay Kconfig files
On 9 December 2014 at 07:50, Bin Meng wrote: > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - Fix several typos in queensbay/Kconfig > - Change FSP_FILE and CMC_FILE description to indicate the file is > in the board directory > - Add help for FSP_TEMP_RAM_ADDR > - Add more help for CMC_FILE Acked-by: Simon Glass > > arch/x86/Kconfig | 13 +++ > arch/x86/cpu/queensbay/Kconfig | 79 > ++ > board/intel/crownbay/Kconfig | 20 +++ > 3 files changed, 112 insertions(+) > create mode 100644 arch/x86/cpu/queensbay/Kconfig > create mode 100644 board/intel/crownbay/Kconfig > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index fdfb618..ebf72b3 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -32,6 +32,15 @@ config TARGET_CHROMEBOOK_LINK > and it provides a 2560x1700 high resolution touch-enabled LCD > display. > > +config TARGET_CROWNBAY > + bool "Support Intel Crown Bay CRB" > + help > + This is the Intel Crown Bay Customer Reference Board. It contains > + the Intel Atom Processor E6xx populated on the COM Express module > + with 1GB DDR2 soldered down memory and a carrier board with the > + Intel Platform Controller Hub EG20T, other system components and > + peripheral connectors for PCIe/SATA/USB/LAN/SD/UART/Audio/LVDS. > + > endchoice > > config RAMBASE > @@ -310,8 +319,12 @@ endmenu > > source "arch/x86/cpu/ivybridge/Kconfig" > > +source "arch/x86/cpu/queensbay/Kconfig" > + > source "board/coreboot/coreboot/Kconfig" > > source "board/google/chromebook_link/Kconfig" > > +source "board/intel/crownbay/Kconfig" > + > endmenu > diff --git a/arch/x86/cpu/queensbay/Kconfig b/arch/x86/cpu/queensbay/Kconfig > new file mode 100644 > index 000..56fe85c > --- /dev/null > +++ b/arch/x86/cpu/queensbay/Kconfig > @@ -0,0 +1,79 @@ > +# > +# Copyright (C) 2014, Bin Meng > +# > +# SPDX-License-Identifier: GPL-2.0+ > +# > + > +config INTEL_QUEENSBAY > + bool > + select HAVE_FSP > + select HAVE_CMC > + > +if INTEL_QUEENSBAY > + > +config HAVE_FSP > + bool "Add an Firmware Support Package binary" > + help > + Select this option to add an Firmware Support Package binary to > + the resulting U-Boot image. It is a binary blob which U-Boot uses > + to set up SDRAM and other chipset specific initialization. > + > + Note: Without this binary U-Boot will not be able to set up its > + SDRAM so will not boot. > + > +config FSP_FILE > + string "Firmware Support Package binary filename" > + depends on HAVE_FSP > + default "fsp.bin" > + help > + The filename of the file to use as Firmware Support Package binary > + in the board directory. > + > +config FSP_LOCATION > + hex "Firmware Support Package binary location" > + depends on HAVE_FSP > + default 0xfffc > + help > + FSP is not Position Independent Code (PIC) and the whole FSP has to > + be rebased if it is placed at a location which is different from the > + perferred base address specified during the FSP build. Use Intel's > + Binary Configuration Tool (BCT) to do the rebase. > + > + The default base address of 0xfffc indicates that the binary > must > + be located at offset 0xc from the beginning of a 1MB flash > device. > + > +config FSP_TEMP_RAM_ADDR > + hex > + default 0x200 > + help > + Stack top address which is used in FspInit after DRAM is ready and > + CAR is disabled. > + > +config HAVE_CMC > + bool "Add a Chipset Micro Code state machine binary" > + help > + Select this option to add a Chipset Micro Code state machine binary > + to the resulting U-Boot image. It is a 64K data block of machine > + specific code which must be put in the flash for the processor to > + access when powered up before system BIOS is executed. > + > +config CMC_FILE > + string "Chipset Micro Code state machine filename" > + depends on HAVE_CMC > + default "cmc.bin" > + help > + The filename of the file to use as Chipset Micro Code state machine > + binary in the board directory. > + > +config CMC_LOCATION > + hex "Chipset Micro Code state machine binary location" > + depends on HAVE_CMC > + default 0xfffb > + help > + The location of the CMC binary is determined by a strap. It must be > + put in flash at a location matching the strap-determined base > address. > + > + The default base address of 0xfffb indicates that the binary > must > + be located at offset 0xb from the beginning of a 1MB flash > device. > + > +endif > diff --git a/board/intel/crownbay/Kconfig b/board/intel/crownbay/Kconfig > new file mode 100644 > index 000..
Re: [U-Boot] [PATCH v2 20/27] x86: Add crownbay defconfig and config.h
On 9 December 2014 at 07:50, Bin Meng wrote:
> Signed-off-by: Bin Meng
> ---
>
> Changes in v2: None
>
> configs/crownbay_defconfig | 6 ++
> include/configs/crownbay.h | 52
> ++
> 2 files changed, 58 insertions(+)
> create mode 100644 configs/crownbay_defconfig
> create mode 100644 include/configs/crownbay.h
Acked-by: Simon Glass
>
> diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig
> new file mode 100644
> index 000..ce90553
> --- /dev/null
> +++ b/configs/crownbay_defconfig
> @@ -0,0 +1,6 @@
> +CONFIG_SYS_EXTRA_OPTIONS="SYS_TEXT_BASE=0xfff0"
> +CONFIG_X86=y
> +CONFIG_TARGET_CROWNBAY=y
> +CONFIG_OF_CONTROL=y
> +CONFIG_OF_SEPARATE=y
> +CONFIG_DEFAULT_DEVICE_TREE="crownbay"
> diff --git a/include/configs/crownbay.h b/include/configs/crownbay.h
> new file mode 100644
> index 000..2314e62
> --- /dev/null
> +++ b/include/configs/crownbay.h
> @@ -0,0 +1,52 @@
> +/*
> + * Copyright (C) 2014, Bin Meng
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +/*
> + * board/config.h - configuration options, board specific
> + */
> +
> +#ifndef __CONFIG_H
> +#define __CONFIG_H
> +
> +#include
> +
> +#define CONFIG_SYS_MONITOR_LEN (1 << 20)
> +#define CONFIG_SYS_X86_START16 0xf800
> +#define CONFIG_BOARD_EARLY_INIT_F
> +
> +#define CONFIG_X86_RESET_VECTOR
> +#define CONFIG_NR_DRAM_BANKS 1
> +
> +#define CONFIG_COREBOOT_SERIAL
> +#define CONFIG_SMSC_LPC47M
> +
> +#define CONFIG_PCI_MEM_BUS 0x4000
> +#define CONFIG_PCI_MEM_PHYSCONFIG_PCI_MEM_BUS
> +#define CONFIG_PCI_MEM_SIZE0x8000
> +
> +#define CONFIG_PCI_PREF_BUS0xc000
> +#define CONFIG_PCI_PREF_PHYS CONFIG_PCI_PREF_BUS
> +#define CONFIG_PCI_PREF_SIZE 0x2000
> +
> +#define CONFIG_PCI_IO_BUS 0x2000
> +#define CONFIG_PCI_IO_PHYS CONFIG_PCI_IO_BUS
> +#define CONFIG_PCI_IO_SIZE 0xe000
> +
> +#define CONFIG_SYS_EARLY_PCI_INIT
> +#define CONFIG_PCI_PNP
> +
> +#define CONFIG_STD_DEVICES_SETTINGS "stdin=serial\0" \
> + "stdout=serial\0" \
> + "stderr=serial\0"
> +
> +#define CONFIG_SCSI_DEV_LIST\
> + {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SATA}
> +
> +/* Video is not supported */
> +#undef CONFIG_VIDEO
> +#undef CONFIG_CFB_CONSOLE
> +
> +#endif /* __CONFIG_H */
> --
> 1.8.2.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 21/27] x86: Use consistent name XXX_ADDR for binary blob flash address
On 9 December 2014 at 07:50, Bin Meng wrote:
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v2:
> - New patch to use consistent name XXX_ADDR for binary blobs
>
> Makefile | 2 +-
> arch/x86/cpu/ivybridge/sdram.c | 2 +-
> arch/x86/cpu/queensbay/Kconfig | 4 ++--
> arch/x86/cpu/queensbay/fsp_support.c | 2 +-
> arch/x86/cpu/queensbay/tnc_car.S | 2 +-
> include/configs/chromebook_link.h| 2 +-
> 6 files changed, 7 insertions(+), 7 deletions(-)
Well you could squash most of this into the previous patch, but it
doesn't matter.
Acked-by: Simon Glass
>
> diff --git a/Makefile b/Makefile
> index c9ae77b..ff4c4aa 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -973,7 +973,7 @@ IFDTOOL_ME_FLAGS += -i
> ME:$(srctree)/board/$(BOARDDIR)/me.bin
> endif
>
> ifneq ($(CONFIG_HAVE_MRC),)
> -IFDTOOL_FLAGS += -w
> $(CONFIG_X86_MRC_START):$(srctree)/board/$(BOARDDIR)/mrc.bin
> +IFDTOOL_FLAGS += -w
> $(CONFIG_X86_MRC_ADDR):$(srctree)/board/$(BOARDDIR)/mrc.bin
> endif
>
> ifneq ($(CONFIG_X86_OPTION_ROM_ADDR),)
> diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c
> index df2b990..b95e781 100644
> --- a/arch/x86/cpu/ivybridge/sdram.c
> +++ b/arch/x86/cpu/ivybridge/sdram.c
> @@ -177,7 +177,7 @@ int sdram_initialise(struct pei_data *pei_data)
>
> debug("PEI data at %p, size %x:\n", pei_data, sizeof(*pei_data));
>
> - data = (char *)CONFIG_X86_MRC_START;
> + data = (char *)CONFIG_X86_MRC_ADDR;
> if (data) {
> int rv;
> int (*func)(struct pei_data *);
> diff --git a/arch/x86/cpu/queensbay/Kconfig b/arch/x86/cpu/queensbay/Kconfig
> index 56fe85c..f6b5201 100644
> --- a/arch/x86/cpu/queensbay/Kconfig
> +++ b/arch/x86/cpu/queensbay/Kconfig
> @@ -29,7 +29,7 @@ config FSP_FILE
> The filename of the file to use as Firmware Support Package binary
> in the board directory.
>
> -config FSP_LOCATION
> +config FSP_ADDR
> hex "Firmware Support Package binary location"
> depends on HAVE_FSP
> default 0xfffc
> @@ -65,7 +65,7 @@ config CMC_FILE
> The filename of the file to use as Chipset Micro Code state machine
> binary in the board directory.
>
> -config CMC_LOCATION
> +config CMC_ADDR
> hex "Chipset Micro Code state machine binary location"
> depends on HAVE_CMC
> default 0xfffb
> diff --git a/arch/x86/cpu/queensbay/fsp_support.c
> b/arch/x86/cpu/queensbay/fsp_support.c
> index 58a30de..e85f823 100644
> --- a/arch/x86/cpu/queensbay/fsp_support.c
> +++ b/arch/x86/cpu/queensbay/fsp_support.c
> @@ -64,7 +64,7 @@ UINT32 __attribute__((optimize("O0"))) find_fsp_header(void)
> volatile register UINT8 * fsp asm("eax");
>
> /* Initalize the FSP base */
> - fsp = (UINT8 *)CONFIG_FSP_LOCATION;
> + fsp = (UINT8 *)CONFIG_FSP_ADDR;
>
> /* Check the FV signature, _FVH */
> if (((EFI_FIRMWARE_VOLUME_HEADER *)fsp)->signature == 0x4856465F) {
> diff --git a/arch/x86/cpu/queensbay/tnc_car.S
> b/arch/x86/cpu/queensbay/tnc_car.S
> index 4f39e42..344597b 100644
> --- a/arch/x86/cpu/queensbay/tnc_car.S
> +++ b/arch/x86/cpu/queensbay/tnc_car.S
> @@ -29,7 +29,7 @@ find_fsp_header_ret:
> mov %eax, %ebp
>
> /* sanity test */
> - cmp $CONFIG_FSP_LOCATION, %eax
> + cmp $CONFIG_FSP_ADDR, %eax
> jb die
>
> /* calculate TempRamInitEntry address */
> diff --git a/include/configs/chromebook_link.h
> b/include/configs/chromebook_link.h
> index 645b31c..c9d84e4 100644
> --- a/include/configs/chromebook_link.h
> +++ b/include/configs/chromebook_link.h
> @@ -25,7 +25,7 @@
>
> #define CONFIG_X86_RESET_VECTOR
> #define CONFIG_NR_DRAM_BANKS 8
> -#define CONFIG_X86_MRC_START 0xfffa
> +#define CONFIG_X86_MRC_ADDR0xfffa
> #define CONFIG_CACHE_MRC_SIZE_KB 512
>
> #define CONFIG_COREBOOT_SERIAL
> --
> 1.8.2.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 22/27] x86: Include FSP and CMC binary in the u-boot.rom build rules
On 9 December 2014 at 07:50, Bin Meng wrote:
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v2:
> - Update ifdtool flags to indicate FSP and CMC files are in
> the board directory
> - Use consistent XXX_FILE name for binary blob file
>
> Makefile | 10 +-
> include/configs/chromebook_link.h | 2 +-
> 2 files changed, 10 insertions(+), 2 deletions(-)
Acked-by: Simon Glass
>
> diff --git a/Makefile b/Makefile
> index ff4c4aa..81d27cf 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -976,8 +976,16 @@ ifneq ($(CONFIG_HAVE_MRC),)
> IFDTOOL_FLAGS += -w
> $(CONFIG_X86_MRC_ADDR):$(srctree)/board/$(BOARDDIR)/mrc.bin
> endif
>
> +ifneq ($(CONFIG_HAVE_FSP),)
> +IFDTOOL_FLAGS += -w
> $(CONFIG_FSP_ADDR):$(srctree)/board/$(BOARDDIR)/$(CONFIG_FSP_FILE)
> +endif
> +
> +ifneq ($(CONFIG_HAVE_CMC),)
> +IFDTOOL_FLAGS += -w
> $(CONFIG_CMC_ADDR):$(srctree)/board/$(BOARDDIR)/$(CONFIG_CMC_FILE)
> +endif
> +
> ifneq ($(CONFIG_X86_OPTION_ROM_ADDR),)
> -IFDTOOL_FLAGS += -w
> $(CONFIG_X86_OPTION_ROM_ADDR):$(srctree)/board/$(BOARDDIR)/$(CONFIG_X86_OPTION_ROM_FILENAME)
> +IFDTOOL_FLAGS += -w
> $(CONFIG_X86_OPTION_ROM_ADDR):$(srctree)/board/$(BOARDDIR)/$(CONFIG_X86_OPTION_ROM_FILE)
> endif
>
> quiet_cmd_ifdtool = IFDTOOL $@
> diff --git a/include/configs/chromebook_link.h
> b/include/configs/chromebook_link.h
> index c9d84e4..b311f4c 100644
> --- a/include/configs/chromebook_link.h
> +++ b/include/configs/chromebook_link.h
> @@ -39,7 +39,7 @@
> {PCI_VENDOR_ID_INTEL, \
> PCI_DEVICE_ID_INTEL_PANTHERPOINT_AHCI_MOBILE}
>
> -#define CONFIG_X86_OPTION_ROM_FILENAME pci8086,0166.bin
> +#define CONFIG_X86_OPTION_ROM_FILE pci8086,0166.bin
> #define CONFIG_X86_OPTION_ROM_ADDR 0xfff9
> #define CONFIG_VIDEO_X86
>
> --
> 1.8.2.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 23/27] x86: crownbay: Add SPI flash support
Hi Bin,
On 9 December 2014 at 07:50, Bin Meng wrote:
> Signed-off-by: Bin Meng
>
Please can you always add a little commit message?
Acked-by: Simon Glass
> ---
>
> Changes in v2:
> - Move PCH_LPC_DEV to arch/x86/include/asm/arch-queensbay/tnc.h
> - Check return value of x86_cpu_init_f()
>
> arch/x86/cpu/queensbay/tnc.c | 26 +-
> arch/x86/include/asm/arch-queensbay/tnc.h | 15 +++
> include/configs/crownbay.h| 2 ++
> 3 files changed, 42 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/include/asm/arch-queensbay/tnc.h
>
> diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c
> index b1df57a..8a0e04e 100644
> --- a/arch/x86/cpu/queensbay/tnc.c
> +++ b/arch/x86/cpu/queensbay/tnc.c
> @@ -6,18 +6,42 @@
>
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
>
> +static void unprotect_spi_flash(void)
> +{
> + u32 bc;
> +
> + bc = pci_read_config32(PCH_LPC_DEV, 0xd8);
> + bc |= 0x1; /* unprotect the flash */
> + pci_write_config32(PCH_LPC_DEV, 0xd8, bc);
> +}
> +
> int arch_cpu_init(void)
> {
> + struct pci_controller *hose;
> + int ret;
> +
> post_code(POST_CPU_INIT);
> #ifdef CONFIG_SYS_X86_TSC_TIMER
> timer_set_base(rdtsc());
> #endif
>
> - return x86_cpu_init_f();
> + ret = x86_cpu_init_f();
> + if (ret)
> + return ret;
> +
> + ret = pci_early_init_hose(&hose);
> + if (ret)
> + return ret;
> +
> + unprotect_spi_flash();
> +
> + return 0;
> }
>
> int print_cpuinfo(void)
> diff --git a/arch/x86/include/asm/arch-queensbay/tnc.h
> b/arch/x86/include/asm/arch-queensbay/tnc.h
> new file mode 100644
> index 000..67c5e05
> --- /dev/null
> +++ b/arch/x86/include/asm/arch-queensbay/tnc.h
> @@ -0,0 +1,15 @@
> +/*
> + * Copyright (C) 2014, Bin Meng
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#ifndef _X86_ARCH_TNC_H_
> +#define _X86_ARCH_TNC_H_
> +
> +#include
> +
> +/* PCI Configuration Space (D31:F0): LPC */
> +#define PCH_LPC_DEVPCI_BDF(0, 0x1f, 0)
> +
> +#endif /* _X86_ARCH_TNC_H_ */
> diff --git a/include/configs/crownbay.h b/include/configs/crownbay.h
> index 2314e62..a051b11 100644
> --- a/include/configs/crownbay.h
> +++ b/include/configs/crownbay.h
> @@ -45,6 +45,8 @@
> #define CONFIG_SCSI_DEV_LIST\
> {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SATA}
>
> +#define CONFIG_SPI_FLASH_SST
> +
> /* Video is not supported */
> #undef CONFIG_VIDEO
> #undef CONFIG_CFB_CONSOLE
> --
> 1.8.2.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 25/27] x86: crownbay: Add SDHCI support
On 9 December 2014 at 07:50, Bin Meng wrote:
> There are two standard SD card slots on the Crown Bay board, which
> are connected to the Topcliff PCH SDIO controllers. Enable the SDHC
> support so that we can use them.
>
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v2:
> - Use ARRAY_SIZE(mmc_supported) instead of 2
> - Check return value of add_sdhci()
>
> arch/x86/cpu/queensbay/Makefile | 2 +-
> arch/x86/cpu/queensbay/topcliff.c | 47
> +++
> include/configs/crownbay.h| 6 +
> 3 files changed, 54 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/cpu/queensbay/topcliff.c
Acked-by: Simon Glass
>
> diff --git a/arch/x86/cpu/queensbay/Makefile b/arch/x86/cpu/queensbay/Makefile
> index ace04ca..2c2ec01 100644
> --- a/arch/x86/cpu/queensbay/Makefile
> +++ b/arch/x86/cpu/queensbay/Makefile
> @@ -4,6 +4,6 @@
> # SPDX-License-Identifier: GPL-2.0+
> #
>
> -obj-y += tnc_car.o tnc_dram.o tnc.o
> +obj-y += tnc_car.o tnc_dram.o tnc.o topcliff.o
> obj-y += fsp_configs.o fsp_support.o
> obj-$(CONFIG_PCI) += tnc_pci.o
> diff --git a/arch/x86/cpu/queensbay/topcliff.c
> b/arch/x86/cpu/queensbay/topcliff.c
> new file mode 100644
> index 000..b01422a
> --- /dev/null
> +++ b/arch/x86/cpu/queensbay/topcliff.c
> @@ -0,0 +1,47 @@
> +/*
> + * Copyright (C) 2014, Bin Meng
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static struct pci_device_id mmc_supported[] = {
> + { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SDIO_0 },
> + { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SDIO_1 },
> + { }
> +};
> +
> +int cpu_mmc_init(bd_t *bis)
> +{
> + struct sdhci_host *mmc_host;
> + pci_dev_t devbusfn;
> + u32 iobase;
> + int ret;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(mmc_supported); i++) {
> + devbusfn = pci_find_devices(mmc_supported, i);
> + if (devbusfn == -1)
> + return -ENODEV;
> +
> + mmc_host = (struct sdhci_host *)malloc(sizeof(struct
> sdhci_host));
> + if (!mmc_host)
> + return -ENOMEM;
> +
> + mmc_host->name = "Topcliff SDHCI";
> + pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_0, &iobase);
> + mmc_host->ioaddr = (void *)iobase;
> + mmc_host->quirks = 0;
> + ret = add_sdhci(mmc_host, 0, 0);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> diff --git a/include/configs/crownbay.h b/include/configs/crownbay.h
> index 09a52ab..b9db6b7 100644
> --- a/include/configs/crownbay.h
> +++ b/include/configs/crownbay.h
> @@ -48,6 +48,12 @@
>
> #define CONFIG_SPI_FLASH_SST
>
> +#define CONFIG_MMC
> +#define CONFIG_SDHCI
> +#define CONFIG_GENERIC_MMC
> +#define CONFIG_MMC_SDMA
> +#define CONFIG_CMD_MMC
> +
> /* Video is not supported */
> #undef CONFIG_VIDEO
> #undef CONFIG_CFB_CONSOLE
> --
> 1.8.2.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 26/27] x86: Rename coreboot-serial to x86-serial
On 9 December 2014 at 07:50, Bin Meng wrote:
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v2:
> - New patch to rename coreboot-serial to x86-serial
>
Acked-by: Simon Glass
> arch/x86/dts/coreboot.dtsi | 2 +-
> drivers/serial/Makefile| 2 +-
> drivers/serial/{serial_coreboot.c => serial_x86.c} | 12 ++--
> include/configs/chromebook_link.h | 2 +-
> include/configs/coreboot.h | 2 +-
> include/configs/crownbay.h | 2 +-
> 6 files changed, 11 insertions(+), 11 deletions(-)
> rename drivers/serial/{serial_coreboot.c => serial_x86.c} (67%)
>
> diff --git a/arch/x86/dts/coreboot.dtsi b/arch/x86/dts/coreboot.dtsi
> index c8dc4ce..65a93ac 100644
> --- a/arch/x86/dts/coreboot.dtsi
> +++ b/arch/x86/dts/coreboot.dtsi
> @@ -6,7 +6,7 @@
> };
>
> serial {
> - compatible = "coreboot-uart";
> + compatible = "x86-uart";
> reg = <0x3f8 0x10>;
> reg-shift = <0>;
> io-mapped = <1>;
> diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
> index 8c84942..4cc00cd 100644
> --- a/drivers/serial/Makefile
> +++ b/drivers/serial/Makefile
> @@ -43,7 +43,7 @@ obj-$(CONFIG_ARC_SERIAL) += serial_arc.o
> obj-$(CONFIG_TEGRA_SERIAL) += serial_tegra.o
> obj-$(CONFIG_UNIPHIER_SERIAL) += serial_uniphier.o
> obj-$(CONFIG_OMAP_SERIAL) += serial_omap.o
> -obj-$(CONFIG_COREBOOT_SERIAL) += serial_coreboot.o
> +obj-$(CONFIG_X86_SERIAL) += serial_x86.o
>
> ifndef CONFIG_SPL_BUILD
> obj-$(CONFIG_USB_TTY) += usbtty.o
> diff --git a/drivers/serial/serial_coreboot.c b/drivers/serial/serial_x86.c
> similarity index 67%
> rename from drivers/serial/serial_coreboot.c
> rename to drivers/serial/serial_x86.c
> index 5c6a76c..e81e035 100644
> --- a/drivers/serial/serial_coreboot.c
> +++ b/drivers/serial/serial_x86.c
> @@ -9,12 +9,12 @@
> #include
> #include
>
> -static const struct udevice_id coreboot_serial_ids[] = {
> - { .compatible = "coreboot-uart" },
> +static const struct udevice_id x86_serial_ids[] = {
> + { .compatible = "x86-uart" },
> { }
> };
>
> -static int coreboot_serial_ofdata_to_platdata(struct udevice *dev)
> +static int x86_serial_ofdata_to_platdata(struct udevice *dev)
> {
> struct ns16550_platdata *plat = dev_get_platdata(dev);
> int ret;
> @@ -27,10 +27,10 @@ static int coreboot_serial_ofdata_to_platdata(struct
> udevice *dev)
> return 0;
> }
> U_BOOT_DRIVER(serial_ns16550) = {
> - .name = "serial_coreboot",
> + .name = "serial_x86",
> .id = UCLASS_SERIAL,
> - .of_match = coreboot_serial_ids,
> - .ofdata_to_platdata = coreboot_serial_ofdata_to_platdata,
> + .of_match = x86_serial_ids,
> + .ofdata_to_platdata = x86_serial_ofdata_to_platdata,
> .platdata_auto_alloc_size = sizeof(struct ns16550_platdata),
> .priv_auto_alloc_size = sizeof(struct NS16550),
> .probe = ns16550_serial_probe,
> diff --git a/include/configs/chromebook_link.h
> b/include/configs/chromebook_link.h
> index b311f4c..8930210 100644
> --- a/include/configs/chromebook_link.h
> +++ b/include/configs/chromebook_link.h
> @@ -28,7 +28,7 @@
> #define CONFIG_X86_MRC_ADDR0xfffa
> #define CONFIG_CACHE_MRC_SIZE_KB 512
>
> -#define CONFIG_COREBOOT_SERIAL
> +#define CONFIG_X86_SERIAL
>
> #define CONFIG_SCSI_DEV_LIST {PCI_VENDOR_ID_INTEL, \
> PCI_DEVICE_ID_INTEL_NM10_AHCI}, \
> diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h
> index 2581380..990a2d1 100644
> --- a/include/configs/coreboot.h
> +++ b/include/configs/coreboot.h
> @@ -49,7 +49,7 @@
> {PCI_VENDOR_ID_INTEL, \
> PCI_DEVICE_ID_INTEL_PANTHERPOINT_AHCI_MOBILE}
>
> -#define CONFIG_COREBOOT_SERIAL
> +#define CONFIG_X86_SERIAL
>
> #define CONFIG_STD_DEVICES_SETTINGS "stdin=usbkbd,vga,serial\0" \
> "stdout=vga,serial,cbmem\0" \
> diff --git a/include/configs/crownbay.h b/include/configs/crownbay.h
> index b9db6b7..eadb339 100644
> --- a/include/configs/crownbay.h
> +++ b/include/configs/crownbay.h
> @@ -20,7 +20,7 @@
> #define CONFIG_X86_RESET_VECTOR
> #define CONFIG_NR_DRAM_BANKS 1
>
> -#define CONFIG_COREBOOT_SERIAL
> +#define CONFIG_X86_SERIAL
> #define CONFIG_SMSC_LPC47M
>
> #define CONFIG_PCI_MEM_BUS 0x4000
> --
> 1.8.2.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 27/27] x86: Add a README.x86 for U-Boot on x86 support
On 9 December 2014 at 07:50, Bin Meng wrote: > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - Remove the 'make menuconfig' in the crownbay build instructions > - Indicate all the binary blobs should be put in the board directory > > doc/README.x86 | 126 > + > 1 file changed, 126 insertions(+) > create mode 100644 doc/README.x86 Acked-by: Simon Glass > > diff --git a/doc/README.x86 b/doc/README.x86 > new file mode 100644 > index 000..902aa7e > --- /dev/null > +++ b/doc/README.x86 > @@ -0,0 +1,126 @@ > +# > +# Copyright (C) 2014, Simon Glass > +# Copyright (C) 2014, Bin Meng > +# > +# SPDX-License-Identifier: GPL-2.0+ > +# > + > +U-Boot on x86 > += > + > +This document describes the information about U-Boot running on x86 targets, > +including supported boards, build instructions, todo list, etc. > + > +Status > +-- > +U-Boot supports running as a coreboot [1] payload on x86. So far only link > +(Chromebook pixel) has been tested, but it should work with minimal > adjustments > +on other x86 boards since coreboot deals with most of the low-level details. > + > +U-Boot also supports booting directly from x86 reset vector without coreboot, > +aka raw support or bare support. Currently Google Chromebook link and Intel > +Crown Bay board support running U-Boot 'bare metal'. > + > +As for loading OS, U-Boot supports directly booting a 32-bit or 64-bit Linux > +kernel as part of a FIT image. It also supports a compressed zImage. > + > +Build Instructions > +-- > +Building U-Boot as a coreboot payload is just like building U-Boot for > targets > +on other architectures, like below: > + > +$ make coreboot-x86_defconfig > +$ make all > + > +Building rom version U-Boot (hereafter referred to as u-boot.rom) is a little > +bit tricky, as generally it requires several binary blobs which are not > shipped > +in the U-Boot source tree. Due to this reason, the u-boot.rom build is not > +turned on by default in the U-Boot source tree. Firstly, you need turn it on > +by uncommenting the following line in the main U-Boot Makefile: > + > +# ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom > + > +Google Chromebook link specific instructions: > + > +Firstly, you need the following binary blobs: > + > +* descriptor.bin - Intel flash descriptor > +* me.bin - Intel Management Engine > +* mrc.bin - Memory Reference Code, which sets up SDRAM > +* video ROM - sets up the display > + > +You can get these binary blobs by: > + > +$ git clone http://review.coreboot.org/p/blobs.git > +$ cd blobs > + > +Find the following files: > + > +* ./mainboard/google/link/descriptor.bin > +* ./mainboard/google/link/me.bin > +* ./northbridge/intel/sandybridge/systemagent-ivybridge.bin > + > +The 3rd one should be renamed to mrc.bin. > +As for the video ROM, you can get it here [2]. > +Make sure all these binary blobs are put in the board directory. > + > +Now you can build U-Boot and obtain u-boot.rom: > + > +$ make chromebook_link_defconfig > +$ make all > + > +Intel Crown Bay specific instructions: > + > +U-Boot support of Intel Crown Bay board [3] relies on a binary blob called > +Firmware Support Package [4] to perform all the necessary initialization > steps > +as documented in the BIOS Writer Guide including initialization of the CPU, > +memory controller, chipset and certain bus interfaces. > + > +Downalod the Intel FSP for Atom E6xx series and Platform Controller Hub > EG20T, > +install it on your host and locate the FSP binary blob. Note this platform > +also requires a Chipset Micro Code (CMC) state machine binary to be present > in > +the SPI flash where u-boot.rom resides, and this CMC binary blob can be found > +in this FSP package too. > + > +* ./FSP/QUEENSBAY_FSP_GOLD_001_20-DECEMBER-2013.fd > +* ./Microcode/C0_22211.BIN > + > +Rename the first one to fsp.bin and second one to cmc.bin and put them in the > +board directory. > + > +Now you can build U-Boot and obtaim u-boot.rom > + > +$ make crownbay_defconfig > +$ make all > + > +CPU Microcode > +- > +Modern CPU usually requires a special bit stream called microcode [5] to be > +loaded on the processor after power up in order to function properly. U-Boot > +has already integrated these as hex dumps in the source tree. > + > +Driver Model > + > +x86 has been converted to use driver model for serial and GPIO. > + > +Device Tree > +--- > +x86 uses device tree to configure the board thus requires CONFIG_OF_CONTROL > to > +be turned on. Not every device on the board is configured via devie tree, but > +more and more devices will be added as time goes by. Check out the directory > +arch/x86/dts/ for these device tree source files. > + > +TODO List > +- > +- MTRR support (for performance) > +- Audio > +- Chrome OS verified boot > +- SMI and ACPI support, to provide platform info and facilities to Linux > + > +References > +-- > +[1]
Re: [U-Boot] [PATCH v2 16/27] x86: Add basic support to queensbay platform and crownbay board
Hi Simon,
On Fri, Dec 12, 2014 at 11:18 AM, Simon Glass wrote:
> Hi Bin,
>
> On 9 December 2014 at 07:50, Bin Meng wrote:
>> Implement minimum required functions for the basic support to
>> queensbay platform and crownbay board.
>>
>> Signed-off-by: Bin Meng
>>
>> ---
>>
>> Changes in v2:
>> - Replace 0xcf9 with macro PORT_RESET from processor.h
>> - Move FspInit call from start.S to car_init
>> - Add UART0_BASE and UART1_BASE to ibmpc.h
>>
>> arch/x86/cpu/queensbay/Makefile | 9
>> arch/x86/cpu/queensbay/tnc.c | 48 ++
>> arch/x86/cpu/queensbay/tnc_car.S | 103
>> ++
>> arch/x86/cpu/queensbay/tnc_dram.c | 78 +
>> arch/x86/cpu/queensbay/tnc_pci.c | 61 ++
>> arch/x86/include/asm/ibmpc.h | 3 ++
>> board/intel/crownbay/MAINTAINERS | 6 +++
>> board/intel/crownbay/Makefile | 7 +++
>> board/intel/crownbay/crownbay.c | 21
>> board/intel/crownbay/start.S | 9
>> 10 files changed, 345 insertions(+)
>> create mode 100644 arch/x86/cpu/queensbay/Makefile
>> create mode 100644 arch/x86/cpu/queensbay/tnc.c
>> create mode 100644 arch/x86/cpu/queensbay/tnc_car.S
>> create mode 100644 arch/x86/cpu/queensbay/tnc_dram.c
>> create mode 100644 arch/x86/cpu/queensbay/tnc_pci.c
>> create mode 100644 board/intel/crownbay/MAINTAINERS
>> create mode 100644 board/intel/crownbay/Makefile
>> create mode 100644 board/intel/crownbay/crownbay.c
>> create mode 100644 board/intel/crownbay/start.S
>>
>> diff --git a/arch/x86/cpu/queensbay/Makefile
>> b/arch/x86/cpu/queensbay/Makefile
>> new file mode 100644
>> index 000..ace04ca
>> --- /dev/null
>> +++ b/arch/x86/cpu/queensbay/Makefile
>> @@ -0,0 +1,9 @@
>> +#
>> +# Copyright (C) 2014, Bin Meng
>> +#
>> +# SPDX-License-Identifier: GPL-2.0+
>> +#
>> +
>> +obj-y += tnc_car.o tnc_dram.o tnc.o
>> +obj-y += fsp_configs.o fsp_support.o
>> +obj-$(CONFIG_PCI) += tnc_pci.o
>> diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c
>> new file mode 100644
>> index 000..b1df57a
>> --- /dev/null
>> +++ b/arch/x86/cpu/queensbay/tnc.c
>> @@ -0,0 +1,48 @@
>> +/*
>> + * Copyright (C) 2014, Bin Meng
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +int arch_cpu_init(void)
>> +{
>> + post_code(POST_CPU_INIT);
>> +#ifdef CONFIG_SYS_X86_TSC_TIMER
>> + timer_set_base(rdtsc());
>> +#endif
>> +
>> + return x86_cpu_init_f();
>> +}
>> +
>> +int print_cpuinfo(void)
>> +{
>> + post_code(POST_CPU_INFO);
>> + return default_print_cpuinfo();
>> +}
>> +
>> +void reset_cpu(ulong addr)
>> +{
>> + /* cold reset */
>> + outb(0x06, PORT_RESET);
>> +}
>> +
>> +void board_final_cleanup(void)
>> +{
>> + EFI_STATUS status;
>
> Is this an enum? We should avoid capital types and also typedef /
> #define for types.
This will be fixed in the U-Boot coding convention final cleanup in v3.
>> +
>> + /* call into FspNotify */
>> + debug("Calling into FSP (notify phase INIT_PHASE_BOOT): ");
>> + status = fsp_notify(NULL, INIT_PHASE_BOOT);
>> + if (status != FSP_SUCCESS)
>> + debug("fail, error code %x\n", status);
>> + else
>> + debug("OK\n");
>> +
>> + return;
>> +}
>> diff --git a/arch/x86/cpu/queensbay/tnc_car.S
>> b/arch/x86/cpu/queensbay/tnc_car.S
>> new file mode 100644
>> index 000..4f39e42
>> --- /dev/null
>> +++ b/arch/x86/cpu/queensbay/tnc_car.S
>> @@ -0,0 +1,103 @@
>> +/*
>> + * Copyright (C) 2014, Bin Meng
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include
>> +#include
>> +
>> +.globl car_init
>> +car_init:
>> + /*
>> +* Note: ebp holds the BIST value (built-in self test) so far, but
>> ebp
>> +* will be destroyed through the FSP call, thus we have to test the
>> +* BIST value here before we call into FSP.
>> +*/
>> + test%ebp, %ebp
>> + jz car_init_start
>> + post_code(POST_BIST_FAILURE)
>> + jmp die
>> +
>> +car_init_start:
>> + post_code(POST_CAR_START)
>> + lea find_fsp_header_stack, %esp
>> + jmp find_fsp_header
>> +
>> +find_fsp_header_ret:
>> + /* EAX points to FSP_INFO_HEADER */
>> + mov %eax, %ebp
>> +
>> + /* sanity test */
>> + cmp $CONFIG_FSP_LOCATION, %eax
>> + jb die
>> +
>> + /* calculate TempRamInitEntry address */
>> + mov 0x30(%ebp), %eax
>> + add 0x1c(%ebp), %eax
>> +
>> + /* call FSP TempRamInitEntry to setup temporary stack */
>> + lea temp_ram_init_stack, %esp
>> + jmp *%eax
>> +
>> +temp_ram_init_ret:
>> + addl$4, %esp
>> + cmp $0, %eax
>> + jz continue
>
> Can we make this jnz put the error code below instead of it being in
> the norma
Re: [U-Boot] [PATCH v2 23/27] x86: crownbay: Add SPI flash support
Hi Simon On Fri, Dec 12, 2014 at 11:28 AM, Simon Glass wrote: > Hi Bin, > > On 9 December 2014 at 07:50, Bin Meng wrote: >> Signed-off-by: Bin Meng >> > > Please can you always add a little commit message? > Sure, will add some commit message in v3. > Acked-by: Simon Glass > [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/27] x86: Add basic support to queensbay platform and crownbay board
Hi Bin,
On 11 December 2014 at 20:34, Bin Meng wrote:
> Hi Simon,
>
> On Fri, Dec 12, 2014 at 11:18 AM, Simon Glass wrote:
>> Hi Bin,
>>
>> On 9 December 2014 at 07:50, Bin Meng wrote:
>>> Implement minimum required functions for the basic support to
>>> queensbay platform and crownbay board.
>>>
>>> Signed-off-by: Bin Meng
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Replace 0xcf9 with macro PORT_RESET from processor.h
>>> - Move FspInit call from start.S to car_init
>>> - Add UART0_BASE and UART1_BASE to ibmpc.h
>>>
>>> arch/x86/cpu/queensbay/Makefile | 9
>>> arch/x86/cpu/queensbay/tnc.c | 48 ++
>>> arch/x86/cpu/queensbay/tnc_car.S | 103
>>> ++
>>> arch/x86/cpu/queensbay/tnc_dram.c | 78 +
>>> arch/x86/cpu/queensbay/tnc_pci.c | 61 ++
>>> arch/x86/include/asm/ibmpc.h | 3 ++
>>> board/intel/crownbay/MAINTAINERS | 6 +++
>>> board/intel/crownbay/Makefile | 7 +++
>>> board/intel/crownbay/crownbay.c | 21
>>> board/intel/crownbay/start.S | 9
>>> 10 files changed, 345 insertions(+)
>>> create mode 100644 arch/x86/cpu/queensbay/Makefile
>>> create mode 100644 arch/x86/cpu/queensbay/tnc.c
>>> create mode 100644 arch/x86/cpu/queensbay/tnc_car.S
>>> create mode 100644 arch/x86/cpu/queensbay/tnc_dram.c
>>> create mode 100644 arch/x86/cpu/queensbay/tnc_pci.c
>>> create mode 100644 board/intel/crownbay/MAINTAINERS
>>> create mode 100644 board/intel/crownbay/Makefile
>>> create mode 100644 board/intel/crownbay/crownbay.c
>>> create mode 100644 board/intel/crownbay/start.S
>>>
>>> diff --git a/arch/x86/cpu/queensbay/Makefile
>>> b/arch/x86/cpu/queensbay/Makefile
>>> new file mode 100644
>>> index 000..ace04ca
>>> --- /dev/null
>>> +++ b/arch/x86/cpu/queensbay/Makefile
>>> @@ -0,0 +1,9 @@
>>> +#
>>> +# Copyright (C) 2014, Bin Meng
>>> +#
>>> +# SPDX-License-Identifier: GPL-2.0+
>>> +#
>>> +
>>> +obj-y += tnc_car.o tnc_dram.o tnc.o
>>> +obj-y += fsp_configs.o fsp_support.o
>>> +obj-$(CONFIG_PCI) += tnc_pci.o
>>> diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c
>>> new file mode 100644
>>> index 000..b1df57a
>>> --- /dev/null
>>> +++ b/arch/x86/cpu/queensbay/tnc.c
>>> @@ -0,0 +1,48 @@
>>> +/*
>>> + * Copyright (C) 2014, Bin Meng
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0+
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +int arch_cpu_init(void)
>>> +{
>>> + post_code(POST_CPU_INIT);
>>> +#ifdef CONFIG_SYS_X86_TSC_TIMER
>>> + timer_set_base(rdtsc());
>>> +#endif
>>> +
>>> + return x86_cpu_init_f();
>>> +}
>>> +
>>> +int print_cpuinfo(void)
>>> +{
>>> + post_code(POST_CPU_INFO);
>>> + return default_print_cpuinfo();
>>> +}
>>> +
>>> +void reset_cpu(ulong addr)
>>> +{
>>> + /* cold reset */
>>> + outb(0x06, PORT_RESET);
>>> +}
>>> +
>>> +void board_final_cleanup(void)
>>> +{
>>> + EFI_STATUS status;
>>
>> Is this an enum? We should avoid capital types and also typedef /
>> #define for types.
>
> This will be fixed in the U-Boot coding convention final cleanup in v3.
>
>>> +
>>> + /* call into FspNotify */
>>> + debug("Calling into FSP (notify phase INIT_PHASE_BOOT): ");
>>> + status = fsp_notify(NULL, INIT_PHASE_BOOT);
>>> + if (status != FSP_SUCCESS)
>>> + debug("fail, error code %x\n", status);
>>> + else
>>> + debug("OK\n");
>>> +
>>> + return;
>>> +}
>>> diff --git a/arch/x86/cpu/queensbay/tnc_car.S
>>> b/arch/x86/cpu/queensbay/tnc_car.S
>>> new file mode 100644
>>> index 000..4f39e42
>>> --- /dev/null
>>> +++ b/arch/x86/cpu/queensbay/tnc_car.S
>>> @@ -0,0 +1,103 @@
>>> +/*
>>> + * Copyright (C) 2014, Bin Meng
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0+
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +
>>> +.globl car_init
>>> +car_init:
>>> + /*
>>> +* Note: ebp holds the BIST value (built-in self test) so far, but
>>> ebp
>>> +* will be destroyed through the FSP call, thus we have to test the
>>> +* BIST value here before we call into FSP.
>>> +*/
>>> + test%ebp, %ebp
>>> + jz car_init_start
>>> + post_code(POST_BIST_FAILURE)
>>> + jmp die
>>> +
>>> +car_init_start:
>>> + post_code(POST_CAR_START)
>>> + lea find_fsp_header_stack, %esp
>>> + jmp find_fsp_header
>>> +
>>> +find_fsp_header_ret:
>>> + /* EAX points to FSP_INFO_HEADER */
>>> + mov %eax, %ebp
>>> +
>>> + /* sanity test */
>>> + cmp $CONFIG_FSP_LOCATION, %eax
>>> + jb die
>>> +
>>> + /* calculate TempRamInitEntry address */
>>> + mov 0x30(%ebp), %eax
>>> + add 0x1c(%ebp), %eax
>>> +
>>> + /* call FSP TempRamInitEntry to setup temporary stack */
>>> + lea temp_ram_init_stack, %es
Re: [U-Boot] [PATCH v2 15/27] x86: Integrate Tunnel Creek processor microcode
Hi Bin, On 11 December 2014 at 20:00, Bin Meng wrote: > Hi Simon, > > On Thu, Dec 11, 2014 at 11:50 PM, Simon Glass wrote: >> Hi Bin, >> >> On 11 December 2014 at 08:01, Bin Meng wrote: >>> Hi Simon, >>> >>> On Thu, Dec 11, 2014 at 10:34 PM, Simon Glass wrote: Hi Bin, On 9 December 2014 at 23:24, Simon Glass wrote: > Hi Bin. > > > On 9 December 2014 at 23:17, Bin Meng wrote: >> Hi Simon, >> >> On Wed, Dec 10, 2014 at 2:09 PM, Simon Glass wrote: >>> Hi Bin, >>> >>> On 9 December 2014 at 07:50, Bin Meng wrote: Integrate the processor microcode version 1.05 for Tunnel Creek, CPUID device 20661h. Signed-off-by: Bin Meng --- Changes in v2: None >>> >>> We are going to end up with microcode both in the device tree and in >>> an assembler include file. >>> >>> This seems unfortunate. I wonder if we can always put it in the device >>> tree, but then optionally also compile it into the image using a >>> symbol (as we do in dts/Makefile for CONFIG_OF_EMBED). This could be >>> done with fdtget to read the binary output of the property perhaps. I >>> haven't looked at it in detail though. >>> >> >> This will do for the embedded case, but it won't help for the separate >> dtb case. >> >>> Maybe this is too clumsy but it would be good to have it in one >>> format. Or maybe we should have a tool which can generate either >>> format. >> >> I don't think we are able to parse device tree in that early phase >> (before car_init), to get the microcode content from dtb. I know in >> some Intel processors, the microcode update are required before CAR >> initialization, as without the microcode update, the CAR >> initialization will fail. > > Right, I meant that we could perhaps do this in the build system - > i.e. compile in the microcode after reading it from the device tree. > > Not thrilled with the idea... I wonder if we could do this: 1. Put the microcode in a .dtsi file, perhaps with a tool to do this automatically. 3. Build the board 2. Use something like this to extract the hex data manualy: >>> >>> 'manually' means we don't let the build system to do this 'automatically'? >> >> For now, since I suspect automatically might be hard for you. >> >>> fdtget -tx /path/to/u-boot.dtb /microcode/update@0 data | sed 's/ /, 0x/g' then put this in a file that you compile. That way if we come up with a clever solution later we can use it. Unfortunately it means submitting the same microcode update in a .c format for now, but have a path to fixing it. >>> >>> Sorry I am confused. In what format should we submit the microcode >>> data? Is it dtsi or .c? Intel normally releases the microcode update >>> in .h format. >> >> We should have a tool which converts Intel's format into a device tree >> .dtsi include file. I'd like that .dtsi to be the file we commit to >> the U-Boot source tree. However since this is not suitable for your >> platform then we need to figure out an approach to convert it to a >> form you need. I believe all you really need to know is the address of >> the microcode update, and I feel there must be a way to make this work >> automatically in the build system. >> >> My suggestion above was just a short-term approach to get you unblocked. >> >>> >>> BTW: I have cleaned up the remaining coding convention issues for ths >>> FSP codes. Do you want to continue reviewing other patches in this v2, >>> so that I can fix all issues in v3? Do you think we need address this >>> microcode update in v3? I think we can leave this issue for this >>> series, and address this microcode issue in another patch series, as >>> it may touch the chromebook_link codes. >> >> Yes I will get to the others. Overall it all looks fine so don't >> expect anything major. I'm happy to sort out the microcode in a later >> series if you prefer, but we do need to fix it. > > Yes, we can address the microcode issue in a later series. > > For this v2 series, I would assume I can just send v3 with the > remaining U-Boot coding convention changes and it is ready to apply? > Let me know if you have different thoughts. I sent through a few other comments that you saw, but once they are resolved, yes. I plan to test this and then apply it immediately so long as we can do this by early next week. Normally we would wait for the merge window, but as this bare x86 support is entirely new in this cycle anyway I see no problem with just going ahead, and in fact I think waiting would be worse since you have improved fixed a few problems and generalised in some areas. I'm not entirely sure this will make it to mainline - I will check with Tom. But he may be OK with it for the same reasons I am. Regards, Simon
Re: [U-Boot] [PATCH v2 16/27] x86: Add basic support to queensbay platform and crownbay board
Hi Simon, On Fri, Dec 12, 2014 at 11:53 AM, Simon Glass wrote: > Hi Bin, > [snip] diff --git a/arch/x86/cpu/queensbay/tnc_car.S b/arch/x86/cpu/queensbay/tnc_car.S new file mode 100644 index 000..4f39e42 --- /dev/null +++ b/arch/x86/cpu/queensbay/tnc_car.S @@ -0,0 +1,103 @@ +/* + * Copyright (C) 2014, Bin Meng + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include + +.globl car_init +car_init: + /* +* Note: ebp holds the BIST value (built-in self test) so far, but ebp +* will be destroyed through the FSP call, thus we have to test the +* BIST value here before we call into FSP. +*/ + test%ebp, %ebp + jz car_init_start + post_code(POST_BIST_FAILURE) + jmp die + +car_init_start: + post_code(POST_CAR_START) + lea find_fsp_header_stack, %esp + jmp find_fsp_header + +find_fsp_header_ret: + /* EAX points to FSP_INFO_HEADER */ + mov %eax, %ebp + + /* sanity test */ + cmp $CONFIG_FSP_LOCATION, %eax + jb die + + /* calculate TempRamInitEntry address */ + mov 0x30(%ebp), %eax + add 0x1c(%ebp), %eax + + /* call FSP TempRamInitEntry to setup temporary stack */ + lea temp_ram_init_stack, %esp + jmp *%eax + +temp_ram_init_ret: + addl$4, %esp + cmp $0, %eax + jz continue >>> >>> Can we make this jnz put the error code below instead of it being in >>> the normal path flow? >> >> Sure. >> + post_code(POST_CAR_FAILURE) + +die: + hlt + jmp die + hlt + +continue: + post_code(POST_CAR_CPU_CACHE) + + /* +* The FSP TempRamInit initializes the ecx and edx registers to +* point to a temporary but writable memory range (Cache-As-RAM). +* ecx: the start of this temporary memory range, +* edx: the end of this range. +*/ + + /* stack grows down from top of CAR */ + movl%edx, %esp + + movl$CONFIG_FSP_TEMP_RAM_ADDR, %eax + xorl%edx, %edx + xorl%ecx, %ecx + callfsp_init >>> >>> Do we have to call fsp_init so early? Could we not call it from >>> cpu_init_f() or even later? >> >> Unfortunately yes. According to FSP architecture spec, the fsp_init >> will not return to its caller, instead it requires the bootloader to >> provide a so-called continuation function to pass into the FSP as a >> parameter of fsp_init, and fsp_init will call that continuation >> function directly. > > But couldn't it be called from C with an assembler shim? > > My objective is to make the assembler code as short as possible and > call board_init_f() as soon as possible. So can we no call this later > in the init sequence? It may work from cpu_init_f() with an some inline assembly, but I am not sure and need do some experiments. Besides this, there is another issue that fsp_init() will setup another stack after the call using the fsp_init parameter stack_top, which means any data on the previous stack (on the CAR) gets lost (ie: global_data). I mentioned in one of the discussion thread before, that supposed FSP should support such scenario, however it does not work. I planned to look into this in the future. Perhaps we need leave this issue for now for this series. I will investigate it later. How do you think? >> + +.global fsp_init_done +fsp_init_done: + /* +* We come here from FspInit with eax pointing to the HOB list. +* Save eax to esi temporarily. +*/ + movl%eax, %esi + /* +* Re-initialize the ebp (BIST) to zero, as we already reach here +* which means we passed BIST testing before. +*/ + xorl%ebp, %ebp + jmp car_init_ret + + .balign 4 +find_fsp_header_stack: + .long find_fsp_header_ret + + .balign 4 +temp_ram_init_stack: >>> >>> Can we use temp_ram_init_vars or similar? This name makes it look like >>> it is a temporary stack. >> >> Yes, it is indeed a temporary ROM stack. > > It's not writeable though, right? So in what sense it is a stack? It is the ROM stack of the fsp_tempram_init call. See the codes below: /* calculate TempRamInitEntry address */ mov 0x30(%ebp), %eax add 0x1c(%ebp), %eax /* call FSP TempRamInitEntry to setup temporary stack */ lea temp_ram_init_stack, %esp jmp *%eax It needs to have the re
