Re: [U-Boot] [u-boot 14/40] usb: dwc3: linux-compat: Add header for dwc3 linux compatibiltiy
Hi Marek,
On Wednesday, February 25, 2015 at 09:17:53 AM, Lukasz Majewski wrote:
Hi Marek,
On Tuesday, February 24, 2015 at 02:21:40 PM, Kishon Vijay
Abraham I
wrote:
Hi,
On Monday 23 February 2015 08:29 PM, Marek Vasut wrote:
On Monday, February 23, 2015 at 07:19:03 AM, Kishon Vijay
Abraham
I wrote:
Hi,
On Monday 16 February 2015 04:02 PM, Lukasz Majewski wrote:
Hi Kishon, Marek
Added a header file to include various linux specific APIs
like pr_debug, WARN_ WARN_ON_ONCE etc.. in order to avoid
compilation error while building dwc3 driver.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/linux-compat.h | 30
++ 1 file changed, 30
insertions(+) create mode 100644
drivers/usb/dwc3/linux-compat.h
diff --git a/drivers/usb/dwc3/linux-compat.h
b/drivers/usb/dwc3/linux-compat.h new file mode 100644
index 000..58c4716
--- /dev/null
+++ b/drivers/usb/dwc3/linux-compat.h
@@ -0,0 +1,30 @@
+/**
+ * linux-compat.h - DesignWare USB3 Linux Compatibiltiy
Adapter Header
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated -
http://www.ti.com
+ *
+ * Authors: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Taken from Linux Kernel v3.16 (drivers/usb/dwc3/core.c)
and ported
+ * to uboot.
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ */
+
+#ifndef __DWC3_LINUX_COMPAT__
+#define __DWC3_LINUX_COMPAT__
+
+#define pr_debug(format)debug(format)
+#define WARN(val, format, arg...) debug(format,
##arg) +#define WARN_ON_ONCE(val)
debug(Error %d\n, val) +
+#define BUILD_BUG_ON_NOT_POWER_OF_2(n)
+
+static inline size_t strlcat(char *dest, const char *src,
size_t n) +{
+ strcat(dest, src);
+ return strlen(dest) + strlen(src);
+}
+
+#endif
Similar file has been already added to u-boot.
Please look into ./drivers/usb/musb-new/linux-compat.h
@Marek - maybe it is time to have a common one?
Can we do this separately?
Would it be too much of a hassle to make a common one please ?
Okay. I sent a new patch which should be applied on top of my v2
that removes creating a new linux compatibility header file for
dwc3.
Well you know that such patch should really go in first, right ?
But it's pretty pointless to push you to rework the entire thing
I'd say, so let's just apply all this stuff as is. Lukasz, do you
plan to pick it all up?
It thought that it would be directly taken to -usb tree.
Oh, oops, right. You're OK with the patchset as-is, right ?
I have no objections to version 2 of this patch. Feel free to apply it
to -usb tree.
--
Best regards,
Lukasz Majewski
Samsung RD 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] UMS on mx6sl
On Wednesday, February 25, 2015 at 12:10:33 AM, Eric Nelson wrote: Hi Fabio, On 02/24/2015 03:25 PM, Fabio Estevam wrote: On Tue, Feb 24, 2015 at 7:22 PM, Fabio Estevam feste...@gmail.com wrote: Hi, I am trying to get USB Mass Storage to work on mx6slevk, but I am getting the following error: = ums 0 mmc 1 UMS: disk start sector: 0x0, count: 0x762c00 g_dnl_register: failed!, error: -22 ERROR: g_dnl_register failed at common/cmd_usb_mass_storage.c:107/do_usb_mass_storage() On mx6qsabresd it works fine and I am able to mount the SD/eMMC card on the host PC. The mx6slevk changes are the same as the ones for sabresd and look like this: You might want to check this value: #define CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP This is only useful for keyboards ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UMS on mx6sl
On Wednesday, February 25, 2015 at 03:23:13 AM, Fabio Estevam wrote: On Tue, Feb 24, 2015 at 8:19 PM, Fabio Estevam feste...@gmail.com wrote: Hi Eric, On Tue, Feb 24, 2015 at 8:10 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: You might want to check this value: #define CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP Thanks for the suggestion. After adding this config the error is still the same: = ums 0 mmc 1 UMS: disk start sector: 0x0, count: 0x762c00 g_dnl_register: failed!, error: -19 ERROR: g_dnl_register failed at common/cmd_usb_mass_storage.c:107/do_usb_mass_storage() Ok, I managed to fix it. Will send a patch tomorrow, thanks Cool, thanks :) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu
On Tuesday, February 24, 2015 at 11:29:39 PM, Lukasz Majewski wrote: On Tue, 24 Feb 2015 18:56:59 +0100 Marek Vasut ma...@denx.de wrote: On Monday, February 23, 2015 at 10:06:08 AM, Lukasz Majewski wrote: Dear Marek, Hi! The following changes since commit d3d087c29c59dbae98c02de098e7e03f29320fe0: usb: musb-new: omap2430: Reset the MUSB controller early (2015-01-22 08:19:18 +0100) are available in the git repository at: git://git.denx.de/u-boot-dfu.git master for you to fetch changes up to 934d274534275f5f4bbb45697a13c50ae54be346: odroid: adjust get_dfu_alt_*() functions to new declarations (2015-02-23 09:48:22 +0100) Is this PR still valid please ? Did you change something on your DFU/master by any chance , like applying additional patches or somesuch please ? I've applied some fastboot related patches on the -dfu branch today. However, the PR is still valid and patches mentioned in it have been tested and validated. If possible please pull this PR. Hi! In case I pull u-boot-dfu/master , I pull 7 patches though, is that right? 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 v2 0/3] Clean out SPL ready for driver model
Hi Albert, On 24 February 2015 at 23:28, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Simon, I'm a bit (read: almost completely) lost re all the gdata removal stuff; seems like there is/was this series, and there is the 9-patch series too, and possibly others... Right now, what patch( seri)es should be applied exactly? I picked up everything I thought was relevant and sent a v4 series starting here: http://patchwork.ozlabs.org/patch/438581/ The cover letter is here: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/211429 So that is all now. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/7] dm: usb: Adjust users of the USB stack to work with driver model
On Sat, Jan 31, 2015 at 12:34 AM, Simon Glass s...@chromium.org wrote:
While we currently don't have driver model support for block devices and
Ethernet, we can still allow this to work when driver model is used for
USB.
Signed-off-by: Simon Glass s...@chromium.org
---
common/cmd_usb.c| 74 --
common/usb.c| 28 +
common/usb_hub.c| 13 +++-
common/usb_storage.c| 148
drivers/usb/eth/usb_ether.c | 46 +++---
include/usb.h | 76 +--
6 files changed, 286 insertions(+), 99 deletions(-)
diff --git a/common/cmd_usb.c b/common/cmd_usb.c
index 27813f0..b824634 100644
--- a/common/cmd_usb.c
+++ b/common/cmd_usb.c
@@ -10,6 +10,7 @@
#include common.h
#include command.h
+#include dm.h
#include asm/byteorder.h
#include asm/unaligned.h
#include part.h
@@ -254,16 +255,24 @@ static void usb_display_config(struct usb_device *dev)
static struct usb_device *usb_find_device(int devnum)
{
- struct usb_device *dev;
+#ifdef CONFIG_DM_USB
+ struct udevice *dev;
+
+ if (uclass_get_device_by_seq(UCLASS_USB, devnum, dev))
+ return NULL;
+ return dev_get_uclass_priv(dev);
+#else
+ struct usb_device *udev;
int d;
for (d = 0; d USB_MAX_DEVICE; d++) {
- dev = usb_get_dev_index(d);
- if (dev == NULL)
+ udev = usb_get_dev_index(d);
+ if (udev == NULL)
return NULL;
- if (dev-devnum == devnum)
- return dev;
+ if (udev-devnum == devnum)
+ return udev;
}
+#endif
return NULL;
}
@@ -466,9 +475,8 @@ static void do_usb_start(void)
*/
static int do_usb(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
-
+ struct usb_device *udev = NULL;
int i;
- struct usb_device *dev = NULL;
extern char usb_started;
#ifdef CONFIG_USB_STORAGE
block_dev_desc_t *stor_dev;
@@ -508,36 +516,64 @@ static int do_usb(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
if (strncmp(argv[1], tree, 4) == 0) {
puts(USB device tree:\n);
+#ifdef CONFIG_DM_USB
+ struct udevice *dev;
+
+ for (uclass_first_device(UCLASS_USB, dev);
+dev;
+uclass_next_device(dev)) {
+ struct usb_device *udev = dev_get_uclass_priv(dev);
+
+ usb_show_tree(udev);
+ }
+#else
for (i = 0; i USB_MAX_DEVICE; i++) {
+ struct usb_device *dev;
+
dev = usb_get_dev_index(i);
if (dev == NULL)
break;
if (dev-parent == NULL)
usb_show_tree(dev);
}
+#endif
return 0;
}
if (strncmp(argv[1], inf, 3) == 0) {
- int d;
if (argc == 2) {
+#ifdef CONFIG_DM_USB
+ struct udevice *dev;
+
+ for (uclass_first_device(UCLASS_USB, dev);
+ dev;
+ uclass_next_device(dev)) {
+ struct usb_device *udev;
+
+ udev = dev_get_uclass_priv(dev);
+ usb_display_desc(udev);
+ usb_display_config(udev);
+ }
+#else
+ int d;
for (d = 0; d USB_MAX_DEVICE; d++) {
- dev = usb_get_dev_index(d);
- if (dev == NULL)
+ udev = usb_get_dev_index(d);
+ if (udev == NULL)
break;
- usb_display_desc(dev);
- usb_display_config(dev);
+ usb_display_desc(udev);
+ usb_display_config(udev);
}
+#endif
return 0;
} else {
i = simple_strtoul(argv[2], NULL, 10);
printf(config for device %d\n, i);
- dev = usb_find_device(i);
- if (dev == NULL) {
+ udev = usb_find_device(i);
+ if (udev == NULL) {
printf(*** No device available ***\n);
return 0;
} else {
- usb_display_desc(dev);
-
[U-Boot] [PATCH v3] fastboot: add support for reboot-bootloader command
The fastboot reboot-bootloader command is defined to
re-enter into fastboot mode after rebooting into
bootloader. This command is usually used after updating
bootloader via fastboot.
This commit implements only a generic side of the
command - setting of the reset flag and then resetting.
Setting of the reset flag is implemented using __weak
fb_set_reboot_flag() function. The actual setting and
checking of the reset flag should be implemented by
a boot script and/or board/SoC specific code.
Signed-off-by: Alexey Firago alexey_fir...@mentor.com
---
Changes in v3:
- return -ENOSYS from default fb_set_reboot_flag()
Changes in v2:
- return error in default fb_set_reboot_flag()
drivers/usb/gadget/f_fastboot.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 310175a..a000c25 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -122,6 +122,7 @@ static struct usb_gadget_strings *fastboot_strings[] = {
};
static void rx_handler_command(struct usb_ep *ep, struct usb_request *req);
+static int strcmp_l1(const char *s1, const char *s2);
static void fastboot_complete(struct usb_ep *ep, struct usb_request *req)
{
@@ -317,8 +318,20 @@ static void compl_do_reset(struct usb_ep *ep, struct
usb_request *req)
do_reset(NULL, 0, 0, NULL);
}
+int __weak fb_set_reboot_flag(void)
+{
+ return -ENOSYS;
+}
+
static void cb_reboot(struct usb_ep *ep, struct usb_request *req)
{
+ char *cmd = req-buf;
+ if (!strcmp_l1(reboot-bootloader, cmd)) {
+ if (fb_set_reboot_flag()) {
+ fastboot_tx_write_str(FAILCannot set reboot flag);
+ return;
+ }
+ }
fastboot_func-in_req-complete = compl_do_reset;
fastboot_tx_write_str(OKAY);
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] warp: Select BOUNCE_BUFFER and CMD_EXT options
Add EXT2/EXT4 and BOUNCE_BUFFER support. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/warp.h | 4 1 file changed, 4 insertions(+) diff --git a/include/configs/warp.h b/include/configs/warp.h index cfc2323..8379cec 100644 --- a/include/configs/warp.h +++ b/include/configs/warp.h @@ -46,6 +46,10 @@ #define CONFIG_MMC #define CONFIG_CMD_MMC #define CONFIG_GENERIC_MMC +#define CONFIG_BOUNCE_BUFFER +#define CONFIG_CMD_EXT2 +#define CONFIG_CMD_EXT4 +#define CONFIG_CMD_EXT4_WRITE #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] fastboot: add support for reboot-bootloader command
On Tue, Feb 24, 2015 at 12:10 PM, Alexey Firago
alexey_fir...@mentor.com wrote:
The fastboot reboot-bootloader command is defined to
re-enter into fastboot mode after rebooting into
bootloader. This command is usually used after updating
bootloader via fastboot.
This commit implements only a generic side of the
command - setting of the reset flag and then resetting.
Setting of the reset flag is implemented using __weak
fb_set_reboot_flag() function. The actual setting and
checking of the reset flag should be implemented by
a boot script and/or board/SoC specific code.
Signed-off-by: Alexey Firago alexey_fir...@mentor.com
Acked-by: Rob Herring r...@kernel.org
---
Changes in v2:
- return error in default fb_set_reboot_flag()
drivers/usb/gadget/f_fastboot.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 310175a..37f6a65 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -122,6 +122,7 @@ static struct usb_gadget_strings *fastboot_strings[] = {
};
static void rx_handler_command(struct usb_ep *ep, struct usb_request *req);
+static int strcmp_l1(const char *s1, const char *s2);
static void fastboot_complete(struct usb_ep *ep, struct usb_request *req)
{
@@ -317,8 +318,20 @@ static void compl_do_reset(struct usb_ep *ep, struct
usb_request *req)
do_reset(NULL, 0, 0, NULL);
}
+int __weak fb_set_reboot_flag(void)
+{
+ return -1;
+}
+
static void cb_reboot(struct usb_ep *ep, struct usb_request *req)
{
+ char *cmd = req-buf;
+ if (!strcmp_l1(reboot-bootloader, cmd)) {
+ if (fb_set_reboot_flag()) {
+ fastboot_tx_write_str(FAILCannot set reboot flag);
+ return;
+ }
+ }
fastboot_func-in_req-complete = compl_do_reset;
fastboot_tx_write_str(OKAY);
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot 14/40] usb: dwc3: linux-compat: Add header for dwc3 linux compatibiltiy
On Wednesday, February 25, 2015 at 09:17:53 AM, Lukasz Majewski wrote:
Hi Marek,
On Tuesday, February 24, 2015 at 02:21:40 PM, Kishon Vijay Abraham I
wrote:
Hi,
On Monday 23 February 2015 08:29 PM, Marek Vasut wrote:
On Monday, February 23, 2015 at 07:19:03 AM, Kishon Vijay Abraham
I wrote:
Hi,
On Monday 16 February 2015 04:02 PM, Lukasz Majewski wrote:
Hi Kishon, Marek
Added a header file to include various linux specific APIs like
pr_debug, WARN_ WARN_ON_ONCE etc.. in order to avoid
compilation error while building dwc3 driver.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/linux-compat.h | 30
++ 1 file changed, 30
insertions(+) create mode 100644
drivers/usb/dwc3/linux-compat.h
diff --git a/drivers/usb/dwc3/linux-compat.h
b/drivers/usb/dwc3/linux-compat.h new file mode 100644
index 000..58c4716
--- /dev/null
+++ b/drivers/usb/dwc3/linux-compat.h
@@ -0,0 +1,30 @@
+/**
+ * linux-compat.h - DesignWare USB3 Linux Compatibiltiy
Adapter Header
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated -
http://www.ti.com
+ *
+ * Authors: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Taken from Linux Kernel v3.16 (drivers/usb/dwc3/core.c)
and ported
+ * to uboot.
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ */
+
+#ifndef __DWC3_LINUX_COMPAT__
+#define __DWC3_LINUX_COMPAT__
+
+#define pr_debug(format)debug(format)
+#define WARN(val, format, arg...) debug(format, ##arg)
+#define WARN_ON_ONCE(val) debug(Error %d\n,
val) +
+#define BUILD_BUG_ON_NOT_POWER_OF_2(n)
+
+static inline size_t strlcat(char *dest, const char *src,
size_t n) +{
+strcat(dest, src);
+return strlen(dest) + strlen(src);
+}
+
+#endif
Similar file has been already added to u-boot.
Please look into ./drivers/usb/musb-new/linux-compat.h
@Marek - maybe it is time to have a common one?
Can we do this separately?
Would it be too much of a hassle to make a common one please ?
Okay. I sent a new patch which should be applied on top of my v2
that removes creating a new linux compatibility header file for
dwc3.
Well you know that such patch should really go in first, right ? But
it's pretty pointless to push you to rework the entire thing I'd say,
so let's just apply all this stuff as is. Lukasz, do you plan to pick
it all up?
It thought that it would be directly taken to -usb tree.
Oh, oops, right. You're OK with the patchset as-is, right ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] Clean out SPL ready for driver model
Hi Albert, On 25 February 2015 at 06:27, Simon Glass s...@chromium.org wrote: Hi Albert, On 24 February 2015 at 23:28, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Simon, I'm a bit (read: almost completely) lost re all the gdata removal stuff; seems like there is/was this series, and there is the 9-patch series too, and possibly others... Right now, what patch( seri)es should be applied exactly? I picked up everything I thought was relevant and sent a v4 series starting here: http://patchwork.ozlabs.org/patch/438581/ The cover letter is here: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/211429 So that is all now. It does need a rebase due to the mach-tegra file move, but the conflict is trivial. Just in case, I have updated u-boo-dm/spl-working with a rebased version. Let me know if I should send v5. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 8/9] configs: ti_omap3_common: Enable workaround for ARM errata 454179, 430973, 621766
On Wed, Feb 25, 2015 at 6:27 AM, Paul Kocialkowski cont...@paulk.fr wrote:
Le mercredi 25 février 2015 à 13:31 +0200, Igor Grinberg a écrit :
On 02/25/15 13:19, Paul Kocialkowski wrote:
Le mardi 24 février 2015 à 16:57 -0600, Nishanth Menon a écrit :
Enable the OMAP3 specific errata code for 454179, 430973, 621766
and while at it, remove legacy non-revision checked errata logic.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap3/board.c | 16
include/configs/ti_omap3_common.h |6 ++
2 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/board.c
b/arch/arm/cpu/armv7/omap3/board.c
index 7ce30949a6c6..cc3a43341335 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -35,7 +35,6 @@ DECLARE_GLOBAL_DATA_PTR;
/* Declarations */
extern omap3_sysinfo sysinfo;
-static void omap3_setup_aux_cr(void);
#ifndef CONFIG_SYS_L2CACHE_OFF
static void omap3_invalidate_l2_cache_secure(void);
#endif
@@ -246,9 +245,6 @@ void s_init(void)
try_unlock_memory();
- /* Errata workarounds */
- omap3_setup_aux_cr();
-
#ifndef CONFIG_SYS_L2CACHE_OFF
/* Invalidate L2-cache from secure mode */
omap3_invalidate_l2_cache_secure();
@@ -428,18 +424,6 @@ void omap3_update_aux_cr_secure(u32 set_bits, u32
clear_bits)
}
}
-static void omap3_setup_aux_cr(void)
-{
- /* Workaround for Cortex-A8 errata: #454179 #430973
- * Set IBE bit
- * Set Disable Branch Size Mispredicts bit
- * Workaround for erratum #621766
- * Enable L1NEON bit
- * ACR |= (IBE | DBSM | L1NEON) = ACR |= 0xE0
- */
- omap3_update_aux_cr_secure(0xE0, 0);
-}
-
#ifndef CONFIG_SYS_L2CACHE_OFF
static void omap3_update_aux_cr(u32 set_bits, u32 clear_bits)
{
diff --git a/include/configs/ti_omap3_common.h
b/include/configs/ti_omap3_common.h
index f909f6b94a18..db15c12ddf53 100644
--- a/include/configs/ti_omap3_common.h
+++ b/include/configs/ti_omap3_common.h
Only a couple of OMAP3 boards in U-Boot include ti_omap3_common.h. You
can find a complete list of all the configs that need those options
enabled from my first patch on that topic:
http://lists.denx.de/pipermail/u-boot/2015-February/205809.html
I guess it's better to enable those on all the currently-supported omap3
platforms: that's the way it was so far and it won't hurt in cases it's
not needed thanks to the revision detection.
Or...
I think this patch might be a good enough argument to request people
switch to include ti_omap3_common.h instead of duplicating it in
private configs...
Don't you think?
The way I see it, ti_omap3_common.h is common for OMAP3 boards made by
TI. A few things there are not generic to omap3 in general (e.g. not
every board uses the U-Boot SPL, or UART3 for console).
However, I agree it would be beneficial to have an omap3_common.h config
with the options that are expected to be shared accross every possible
omap3 device (and with a few clever ifdef so that the minimum has to be
set in the including board configs).
I could try to come up with such a config if you wish, but I'm afraid
I'm not the most qualified person to do this (I only have a single omap3
device).
I am planning on a V3 based on trying to converge exynos and TI
platforms into a common code base. I will stick with ti_*_common.h
headers for now, we will keep all the other headers updated for the
moment. I do stand with the opinion that we should all be using the
same ti_omap3_common header for all platforms using the same SoC...
but that could be done as follow on patches.
That said, Paul, if you could contribute patches to the effect of
integrating all these platforms to ti_*_common.h, that'd be great.
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 8/9] configs: ti_omap3_common: Enable workaround for ARM errata 454179, 430973, 621766
Le mercredi 25 février 2015 à 13:31 +0200, Igor Grinberg a écrit :
On 02/25/15 13:19, Paul Kocialkowski wrote:
Le mardi 24 février 2015 à 16:57 -0600, Nishanth Menon a écrit :
Enable the OMAP3 specific errata code for 454179, 430973, 621766
and while at it, remove legacy non-revision checked errata logic.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap3/board.c | 16
include/configs/ti_omap3_common.h |6 ++
2 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/board.c
b/arch/arm/cpu/armv7/omap3/board.c
index 7ce30949a6c6..cc3a43341335 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -35,7 +35,6 @@ DECLARE_GLOBAL_DATA_PTR;
/* Declarations */
extern omap3_sysinfo sysinfo;
-static void omap3_setup_aux_cr(void);
#ifndef CONFIG_SYS_L2CACHE_OFF
static void omap3_invalidate_l2_cache_secure(void);
#endif
@@ -246,9 +245,6 @@ void s_init(void)
try_unlock_memory();
- /* Errata workarounds */
- omap3_setup_aux_cr();
-
#ifndef CONFIG_SYS_L2CACHE_OFF
/* Invalidate L2-cache from secure mode */
omap3_invalidate_l2_cache_secure();
@@ -428,18 +424,6 @@ void omap3_update_aux_cr_secure(u32 set_bits, u32
clear_bits)
}
}
-static void omap3_setup_aux_cr(void)
-{
- /* Workaround for Cortex-A8 errata: #454179 #430973
- * Set IBE bit
- * Set Disable Branch Size Mispredicts bit
- * Workaround for erratum #621766
- * Enable L1NEON bit
- * ACR |= (IBE | DBSM | L1NEON) = ACR |= 0xE0
- */
- omap3_update_aux_cr_secure(0xE0, 0);
-}
-
#ifndef CONFIG_SYS_L2CACHE_OFF
static void omap3_update_aux_cr(u32 set_bits, u32 clear_bits)
{
diff --git a/include/configs/ti_omap3_common.h
b/include/configs/ti_omap3_common.h
index f909f6b94a18..db15c12ddf53 100644
--- a/include/configs/ti_omap3_common.h
+++ b/include/configs/ti_omap3_common.h
Only a couple of OMAP3 boards in U-Boot include ti_omap3_common.h. You
can find a complete list of all the configs that need those options
enabled from my first patch on that topic:
http://lists.denx.de/pipermail/u-boot/2015-February/205809.html
I guess it's better to enable those on all the currently-supported omap3
platforms: that's the way it was so far and it won't hurt in cases it's
not needed thanks to the revision detection.
Or...
I think this patch might be a good enough argument to request people
switch to include ti_omap3_common.h instead of duplicating it in
private configs...
Don't you think?
The way I see it, ti_omap3_common.h is common for OMAP3 boards made by
TI. A few things there are not generic to omap3 in general (e.g. not
every board uses the U-Boot SPL, or UART3 for console).
However, I agree it would be beneficial to have an omap3_common.h config
with the options that are expected to be shared accross every possible
omap3 device (and with a few clever ifdef so that the minimum has to be
set in the including board configs).
I could try to come up with such a config if you wish, but I'm afraid
I'm not the most qualified person to do this (I only have a single omap3
device).
@@ -27,6 +27,12 @@
# define CONFIG_SYS_MALLOC_F_LEN (1 10)
#endif
+/* Common ARM Erratas */
+#define CONFIG_ARM_ARCH_CP15_ERRATA
+#define CONFIG_ARM_ERRATA_454179
+#define CONFIG_ARM_ERRATA_430973
+#define CONFIG_ARM_ERRATA_621766
+
/* The chip has SDRC controller */
#define CONFIG_SDRC
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Secure boot on imx28
Hi, I read somewhere tha we can generate signed boot sd file for imx28. I found target in makefile. But how can we configure uboot to generate this target ? Best regards, -- Jérôme Dusautois ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/7] RFC: dm: Add USB support
Hi Simon, On Sat, Jan 31, 2015 at 12:34 AM, Simon Glass s...@chromium.org wrote: This series adds basic driver model support to USB. The intent is to permit the various subsystems (OHCI, EHCI, XHCI) to co-exist and allow any number of USB ports of different types. So far the absolute limit on the number of USB devices is only slightly relaxed. Only USB controllers have a real driver model device. USB devices (including the hub in the controller) are not modelled as driver model devices. This is for two reasons: - it is easier since we don't need to bind a whole lot of devices when scanning - the two main USB devices (block devices and Ethernet) don't have driver mode support yet anyway, so it would be pointless. However the recent network RFC has encouraged me to send this. The basic approach is to set up the driver model structures in parallel to what already exists rather than to replace them. This allows both driver model and legacy to be used for USB, although not with the same board. So far only XHCI is supported. As an example the Exynos XHCI driver is converted to driver model. I would appreciate comments before going further. Caveats: - sandbox code is incomplete and there are no tests - 'usb stop' does not remove existing devices (I have not yet settled on the best approach) - the usb.h changes need to be split correctly into the patches once they are final This series is available at u-boot-dm/usb-working. Just ran a quick test on smdk5250. I used Below is what i get : -- SMDK5250 # usb start starting USB... USBRegister 2000140 NbrPorts 2 Starting the controller USB XHCI 1.00 0: scanning bus 0 for devices... cannot reset port 1!? 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 SMDK5250 # usb start starting USB... USB0: scanning bus 0 for devices... BUG: failure at drivers/usb/host/xhci-mem.c:666/xhci_setup_addressable_virt_dev()! BUG! resetting ... -- The first time when scanning bus 0 for devices... cannot reset port 1!? comes. This seems to be smdk issue only which i am looking into currently. But the second time when i run usb start, the setup itself hits a NULL pointer it seems. However just tot of u-boot-dm doesn't give this issue. The device gets detected when usb reset is used after doing a usb start first time. Even with my patch series, i hit a NULL pointer BUG, when doing a usb reset -- SMDK5250 # usb reset resetting USB... Host not halted after 16000 microseconds. BUG: failure at drivers/usb/host/xhci-mem.c:83/xhci_ring_free()! BUG! resetting ... -- However i could understand why this is coming, since usb_lowlevel_stop() called in xhci.c; at that time xhci's data structures are not initialized, and we hit this BUG. I will check further on snow. Simon Glass (7): dm: usb: Add a uclass for USB controllers dm: usb: Support driver model in exynos XHCI dm: usb: Adjust users of the USB stack to work with driver model dm: usb: WIP sandbox USB implementation dm: core: Add a function to get the uclass data for a device arm: Show relocated PC/LR in the register dump dm: exynos: Enable driver model for snow XHCI Makefile | 1 + arch/arm/lib/interrupts.c| 13 +- arch/sandbox/dts/sandbox.dts | 20 +++ arch/sandbox/include/asm/processor.h | 0 common/cmd_usb.c | 74 --- common/usb.c | 28 +++-- common/usb_hub.c | 13 +- common/usb_storage.c | 148 +- drivers/core/device.c| 10 ++ drivers/usb/dev/Makefile | 10 ++ drivers/usb/dev/sandbox-flash.c | 95 +++ drivers/usb/dev/sandbox-hub.c| 116 ++ drivers/usb/dev/usb-emul-uclass.c| 16 +++ drivers/usb/eth/usb_ether.c | 46 +-- drivers/usb/host/Makefile| 5 + drivers/usb/host/usb-sandbox.c | 151 +++ drivers/usb/host/usb-uclass.c| 227 ++ drivers/usb/host/xhci-exynos5.c | 115 +- drivers/usb/host/xhci.c | 229 --- drivers/usb/host/xhci.h | 24 include/configs/sandbox.h| 3 + include/configs/snow.h | 1 + include/dm/device.h | 10 ++ include/dm/uclass-id.h | 2 + include/usb.h| 76 +++-
Re: [U-Boot] [GIT] Pull request: u-boot-dfu
Hi Marek, On Tuesday, February 24, 2015 at 11:29:39 PM, Lukasz Majewski wrote: On Tue, 24 Feb 2015 18:56:59 +0100 Marek Vasut ma...@denx.de wrote: On Monday, February 23, 2015 at 10:06:08 AM, Lukasz Majewski wrote: Dear Marek, Hi! The following changes since commit d3d087c29c59dbae98c02de098e7e03f29320fe0: usb: musb-new: omap2430: Reset the MUSB controller early (2015-01-22 08:19:18 +0100) are available in the git repository at: git://git.denx.de/u-boot-dfu.git master for you to fetch changes up to 934d274534275f5f4bbb45697a13c50ae54be346: odroid: adjust get_dfu_alt_*() functions to new declarations (2015-02-23 09:48:22 +0100) Is this PR still valid please ? Did you change something on your DFU/master by any chance , like applying additional patches or somesuch please ? I've applied some fastboot related patches on the -dfu branch today. However, the PR is still valid and patches mentioned in it have been tested and validated. If possible please pull this PR. Hi! In case I pull u-boot-dfu/master , I pull 7 patches though, is that right? There are 9 patches actually. It's OK to pull them. Best regards, Marek Vasut -- Best regards, Lukasz Majewski Samsung RD 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] [PATCH 1/2] warp: Add User Mass Storage support
With UMS support we are able to flash the eMMC from U-boot, which is very
convenient.
Add UMS support to make the eMMC flashing process easier.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/warp/warp.c | 6 ++
include/configs/warp.h | 26 ++
2 files changed, 32 insertions(+)
diff --git a/board/warp/warp.c b/board/warp/warp.c
index 3b275c2..21ac5e7 100644
--- a/board/warp/warp.c
+++ b/board/warp/warp.c
@@ -21,6 +21,7 @@
#include watchdog.h
#include fsl_esdhc.h
#include mmc.h
+#include usb.h
DECLARE_GLOBAL_DATA_PTR;
@@ -82,6 +83,11 @@ int board_mmc_init(bd_t *bis)
return fsl_esdhc_initialize(bis, usdhc_cfg[0]);
}
+int board_usb_phy_mode(int port)
+{
+ return USB_INIT_DEVICE;
+}
+
int board_early_init_f(void)
{
setup_iomux_uart();
diff --git a/include/configs/warp.h b/include/configs/warp.h
index 82036e4..cfc2323 100644
--- a/include/configs/warp.h
+++ b/include/configs/warp.h
@@ -120,6 +120,32 @@
#define CONFIG_CMD_CACHE
#endif
+/* USB Configs */
+#define CONFIG_CMD_USB
+#ifdef CONFIG_CMD_USB
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_MX6
+#define CONFIG_USB_STORAGE
+#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
+#define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW)
+#define CONFIG_MXC_USB_FLAGS 0
+#define CONFIG_USB_MAX_CONTROLLER_COUNT1 /* Only OTG2 port enabled */
+#endif
+
+#define CONFIG_CI_UDC
+#define CONFIG_USBD_HS
+#define CONFIG_USB_GADGET_DUALSPEED
+
+#define CONFIG_USB_GADGET
+#define CONFIG_CMD_USB_MASS_STORAGE
+#define CONFIG_USB_GADGET_MASS_STORAGE
+#define CONFIG_USBDOWNLOAD_GADGET
+#define CONFIG_USB_GADGET_VBUS_DRAW2
+
+#define CONFIG_G_DNL_VENDOR_NUM0x0525
+#define CONFIG_G_DNL_PRODUCT_NUM 0xa4a5
+#define CONFIG_G_DNL_MANUFACTURER FSL
+
#define CONFIG_EXTRA_ENV_SETTINGS \
script=boot.scr\0 \
image=zImage\0 \
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: invoke board specific USB cleanup interface
On Wed, Feb 25, 2015 at 06:58:03PM +0900, Inha Song wrote: Hi, Rob, On Tue, 24 Feb 2015 10:20:13 -0600 Rob Herring r...@kernel.org wrote: On Mon, Jan 19, 2015 at 1:07 AM, Inha Song ideal.s...@samsung.com wrote: This patch invoke board-specific USB cleanup (board_usb_cleanup) interface. Signed-off-by: Inha Song ideal.s...@samsung.com --- common/cmd_dfu.c | 1 + common/cmd_thordown.c | 1 + common/cmd_usb_mass_storage.c | 1 + You missed fastboot at a minimum. Ok, I will add board_usb_cleanup fuction also in fastboot. What about other gadget functions such as rndis/cdc_etherent? I doesn't have any knowledge about rndis/cdc_etherent So, Afraid that to fix these code. So that's the problem with this approach. Kishon reminded me that on TI parts we see some PM problems because we don't always do a cleanup on the USB side for gadgets. I think the right answer here is to mirror the usb_stop() function in bootm_disable_interrupts() in common/bootm.c for the gadget code as well. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 03/10] Exynos542x: Add workaround for ARM errata 798870
On Wed, Feb 25, 2015 at 2:27 AM, Akshay Saraswat aksha...@samsung.com wrote:
Hi Nishanth,
On 17:13-20150224, Nishanth Menon wrote:
On 13:27-20150220, Akshay Saraswat wrote:
This patch adds workaround for ARM errata 798870 which says
If back-to-back speculative cache line fills (fill A and fill B) are
issued from the L1 data cache of a CPU to the L2 cache, the second
request (fill B) is then cancelled, and the second request would have
detected a hazard against a recent write or eviction (write B) to the
same cache line as fill B then the L2 logic might deadlock.
Signed-off-by: Kimoon Kim kimoon@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
Changes since v3:
- Added errata number in comment.
- Moved changes to arm generic armv7.h
Changes since v2:
- No change.
Changes since v1:
- Added Reviewed-by Tested-by.
- Added space before */ on line # 40.
arch/arm/include/asm/armv7.h | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index a13da23..a2040b7 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -69,6 +69,22 @@
#define CP15DSB asm volatile (mcr p15, 0, %0, c7, c10, 4 : : r
(0))
#define CP15DMB asm volatile (mcr p15, 0, %0, c7, c10, 5 : : r
(0))
+/*
+ * Workaround for ARM errata # 798870
+ * Set L2ACTLR[7] to reissue any memory transaction in the L2 that has
been
+ * stalled for 1024 cycles to verify that its hazard condition still
exists.
+ */
+static inline void v7_enable_l2_hazard_detect(void)
+{
+ uint32_t val;
+
+ /* L2ACTLR[7]: Enable hazard detect timeout */
+ asm volatile (mrc p15, 1, %0, c15, c0, 0\n\t : =r(val));
+ val |= (1 7);
+ asm volatile (mcr p15, 1, %0, c15, c0, 0\n\t : : r(val));
This wont work for us in DRA7/OMAP5 L2ACTLR cannot be modified by
u-boot. has to go to secure world using smc call.
+}
+
+void v7_en_l2_hazard_detect(void);
void v7_outer_cache_enable(void);
void v7_outer_cache_disable(void);
void v7_outer_cache_flush_all(void);
How about this - using the series:
https://patchwork.ozlabs.org/patch/443261/
https://patchwork.ozlabs.org/patch/443264/
https://patchwork.ozlabs.org/patch/443268/
https://patchwork.ozlabs.org/patch/443265/
https://patchwork.ozlabs.org/patch/443263/
https://patchwork.ozlabs.org/patch/443262/
https://patchwork.ozlabs.org/patch/443267/
https://patchwork.ozlabs.org/patch/443266/
https://patchwork.ozlabs.org/patch/443260/
I think the following might work for exynos?
Yes, that will probably do and if you look at v3 of this patch,
we were doing something similar. But I was convinced with the
below mentioned comments I recieved over v3, so updated it.
Having the ARM errata number mentioned in the comment here would make
the purpose of this code much more clear to anyone looking at it later
in the future.
Also isn't this a general purpose Cortex-A15 r2pX workaround,
also potentially useful for the other non-Exynos SoCs too?
I don't think it hurts to have a generic function with ARM errata workaround
implementation. Whoever wish to use it can call it in their boot path. And
it's
not even getting executed right now for any SoC other than Exynos542x, so
those
who don't want it need not bother about it. This was the intention. :)
Please let me know if you still want me to move it from armv7.h to
exynos/lowlevel_init.c
I think I can do a V3 on my series for a middle path between the two
approaches. Assuming that exynos does not need any specific custom smc
call for the l2actlr update. will split every erratum into a separate
patch of it's own.
diff --git a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
index 83e1dcfc1e13..0157105524ca 100644
--- a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
+++ b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
@@ -42,6 +42,23 @@ enum {
DO_POWER= 1 4,
};
+#ifdef CONFIG_ARM_ARCH_CP15_ERRATA
+void arch_cp15_errata_workaround(u32 midr, u32 variant, u32 rev, u32 comb)
+{
+#ifdef CONFIG_ARM_ERRATA_798870
+ if (comb = 0x20 comb 0x30) {
+ uint32_t l2actlr;
+
+ mrc_l2_aux_ctlr(l2actlr);
+ /* Disable ACE DVM/CMO message broadcas */
+ l2actlr |= (1 7);
+ mcr_l2_aux_ctlr(l2actlr);
+ mrc_l2_ctlr(l2actlr);
+ }
+#endif
+}
+#endif
+
int do_lowlevel_init(void)
{
uint32_t reset_status;
--
Regards,
Nishanth Menon
Regards,
Akshay Saraswat
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
---
Regards,
Nishanth Menon
___
U-Boot mailing list
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
So I can't debug with the BDI3000 because the target keeps on resetting... This happens over and over... - TARGET: processing power-up delay - TARGET: processing reset request - TARGET: BDI executes scan chain init string - TARGET: Bypass check 0x0001 = 0x0004 - TARGET: JTAG exists check passed - Core#0: ID code is 0x1BA00477 - Core#0: DP-CSW is 0xF000 - Core#0: DBG-AP at 0xC0008000 - Core#0: DIDRis 0x - TARGET: Reset sequence passed - TARGET: resetting target passed - TARGET: processing target startup - TARGET: processing target startup passed # TARGET: reset detected, restarting target How can I prevent the reset? -- View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-stuck-after-relocation-attempt-on-MX51-board-tp206738p206808.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UMS on mx6sl
Hi Marek, On Wed, Feb 25, 2015 at 9:11 AM, Marek Vasut ma...@denx.de wrote: On Wednesday, February 25, 2015 at 03:23:13 AM, Fabio Estevam wrote: Ok, I managed to fix it. Will send a patch tomorrow, thanks Cool, thanks :) Just to let you know that this original problem was caused by an error in the mx6sl-evk board file, so things look good in the USB stack. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] unassigned-patches/133: Re: [PATCH] x86: minnowmax: add GPIO mapping support
Hi Simon,
With a little bit of delay here are the responses ... :)
On 02/17/2015 08:04 PM, Simon Glass wrote:
Hi Gabriel,
On 15 February 2015 at 14:55, Gabriel Huau cont...@huau-gabriel.fr wrote:
Configure the pinctrl as it required to make some IO controllers
working (USB/UART/I2C/...).
The idea would be in the next version to modify the pch GPIO driver and
configure these pins through the device tree.
These modifications are ported from the coreboot project.
Signed-off-by: Gabriel Huau cont...@huau-gabriel.fr
Thanks for the patch!
I have mostly nits except for one comment about register access which
is different in U-Boot...
I read all the comments and I agree on almost all of them but I have
some questions.
+
+ /* Add correct func to GPIO pad config */
+ pad_conf0 = config-pad_conf0;
+ if (config-is_gpio) {
+ if (gpio = bank-gpio_f1_range_start
+ gpio = bank-gpio_f1_range_end)
+ pad_conf0 |= PAD_FUNC1;
+ else
+ pad_conf0 |= PAD_FUNC0;
+ }
+
+ writel(reg + PAD_CONF0_REG, pad_conf0);
+ writel(reg + PAD_CONF1_REG, config-pad_conf1);
+ writel(reg + PAD_VAL_REG, config-pad_val);
+ }
+
+ if (bank-legacy_base != GP_LEGACY_BASE_NONE)
+ for (set = 0; set = (bank-gpio_count - 1) / 32; ++set) {
+ reg = bank-legacy_base + 0x20 * set;
+
+ outl(use_sel[set], reg + LEGACY_USE_SEL_REG);
+ outl(io_sel[set], reg + LEGACY_IO_SEL_REG);
+ outl(gp_lvl[set], reg + LEGACY_GP_LVL_REG);
+ outl(tpe[set], reg + LEGACY_TPE_REG);
+ outl(tne[set], reg + LEGACY_TNE_REG);
+
+ /* TS registers are WOC */
If you know what this comment means, please spell it out without
abbreviations.
Actually, I don't know the meaning of WOC and I couldn't find a
definition in the datasheet.
+ outl(0, reg + LEGACY_TS_REG);
+
+ if (bank-has_wake_en)
+ outl(wake_en[set], reg + LEGACY_WAKE_EN_REG);
+ }
+}
+
+static void setup_gpio_route(const struct byt_gpio_map *sus,
+ const struct byt_gpio_map *core)
+{
+ uint32_t route_reg = 0;
+ int i;
+
+ for (i = 0; i 8; i++) {
+ /* SMI takes precedence and wake_en implies SCI. */
+ if (sus[i].smi)
+ route_reg |= ROUTE_SMI (2 * i);
+ else if (sus[i].sci)
+ route_reg |= ROUTE_SCI (2 * i);
+
+ if (core[i].smi)
+ route_reg |= ROUTE_SMI (2 * (i + 8));
+ else if (core[i].sci)
+ route_reg |= ROUTE_SCI (2 * (i + 8));
+ }
What happens to route_reg after this? I don't see it get returned.
I will remove the code, actually it was used when the SMI was enabled.
+
+#define GPIO_LEVEL_LOW 0
+#define GPIO_LEVEL_HIGH1
+
+#define GPIO_PEDGE_DISABLE 0
+#define GPIO_PEDGE_ENABLE 1
+
+#define GPIO_NEDGE_DISABLE 0
+#define GPIO_NEDGE_ENABLE 1
+
+/* config0[29] - Disable second mask */
+#define PAD_MASK2_DISABLE (1 29)
+
+/* config0[27] - Direct Irq En */
+#define PAD_IRQ_EN (1 27)
+
+/* config0[26] - gd_tne */
+#define PAD_TNE_IRQ(1 26)
+
+/* config0[25] - gd_tpe */
+#define PAD_TPE_IRQ(1 25)
+
+/* config0[24] - Gd Level */
+#define PAD_LEVEL_IRQ (1 24)
+#define PAD_EDGE_IRQ (0 24)
+
+/* config0[17] - Slow clkgate / glitch filter */
+#define PAD_SLOWGF_ENABLE (1 17)
+
+/* config0[16] - Fast clkgate / glitch filter */
+#define PAD_FASTGF_ENABLE (1 16)
+
+/* config0[15] - Hysteresis enable (inverted) */
+#define PAD_HYST_DISABLE (1 15)
+#define PAD_HYST_ENABLE(0 15)
+
+/* config0[14:13] - Hysteresis control */
+#define PAD_HYST_CTRL_DEFAULT (2 13)
+
+/* config0[11] - Bypass Flop */
+#define PAD_FLOP_BYPASS(1 11)
+#define PAD_FLOP_ENABLE(0 11)
+
+/* config0[10:9] - Pull str */
+#define PAD_PU_2K (0 9)
+#define PAD_PU_10K (1 9)
+#define PAD_PU_20K (2 9)
+#define PAD_PU_40K (3 9)
+
+/* config0[8:7] - Pull assign */
+#define PAD_PULL_DISABLE (0 7)
+#define PAD_PULL_UP(1 7)
+#define PAD_PULL_DOWN (2 7)
+
+/* config0[2:0] - Func. pin mux */
+#define PAD_FUNC0 0x0
+#define PAD_FUNC1 0x1
+#define PAD_FUNC2 0x2
+#define PAD_FUNC3 0x3
+#define PAD_FUNC4 0x4
+#define PAD_FUNC5 0x5
+#define
[U-Boot] [PATCH] cmd_usb_mass_storage: Remove extra 'ums' string in the usage text
Currently the usage text for the 'ums' command looks like this: Usage: ums ums USB_controller [devtype] devnum e.g. ums 0 mmc 0 ,so remove the extra 'ums' in the text. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- common/cmd_usb_mass_storage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c index 2c879ea..51c3fff 100644 --- a/common/cmd_usb_mass_storage.c +++ b/common/cmd_usb_mass_storage.c @@ -159,6 +159,6 @@ exit: U_BOOT_CMD(ums, 4, 1, do_usb_mass_storage, Use the UMS [User Mass Storage], - ums USB_controller [devtype] devnum e.g. ums 0 mmc 0\n + USB_controller [devtype] devnum e.g. ums 0 mmc 0\n devtype defaults to mmc ); -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: minnowmax: add GPIO mapping support
Hi Simon,
With a little bit of delay here are the responses ... :)
On 02/17/2015 08:04 PM, Simon Glass wrote:
Hi Gabriel,
On 15 February 2015 at 14:55, Gabriel Huau cont...@huau-gabriel.fr wrote:
Configure the pinctrl as it required to make some IO controllers
working (USB/UART/I2C/...).
The idea would be in the next version to modify the pch GPIO driver and
configure these pins through the device tree.
These modifications are ported from the coreboot project.
Signed-off-by: Gabriel Huau cont...@huau-gabriel.fr
Thanks for the patch!
I have mostly nits except for one comment about register access which
is different in U-Boot...
I read all the comments and I agree on almost all of them but I have
some questions.
+
+ /* Add correct func to GPIO pad config */
+ pad_conf0 = config-pad_conf0;
+ if (config-is_gpio) {
+ if (gpio = bank-gpio_f1_range_start
+ gpio = bank-gpio_f1_range_end)
+ pad_conf0 |= PAD_FUNC1;
+ else
+ pad_conf0 |= PAD_FUNC0;
+ }
+
+ writel(reg + PAD_CONF0_REG, pad_conf0);
+ writel(reg + PAD_CONF1_REG, config-pad_conf1);
+ writel(reg + PAD_VAL_REG, config-pad_val);
+ }
+
+ if (bank-legacy_base != GP_LEGACY_BASE_NONE)
+ for (set = 0; set = (bank-gpio_count - 1) / 32; ++set) {
+ reg = bank-legacy_base + 0x20 * set;
+
+ outl(use_sel[set], reg + LEGACY_USE_SEL_REG);
+ outl(io_sel[set], reg + LEGACY_IO_SEL_REG);
+ outl(gp_lvl[set], reg + LEGACY_GP_LVL_REG);
+ outl(tpe[set], reg + LEGACY_TPE_REG);
+ outl(tne[set], reg + LEGACY_TNE_REG);
+
+ /* TS registers are WOC */
If you know what this comment means, please spell it out without abbreviations.
Actually, I don't know the meaning of WOC and I couldn't find a
definition in the datasheet.
+ outl(0, reg + LEGACY_TS_REG);
+
+ if (bank-has_wake_en)
+ outl(wake_en[set], reg + LEGACY_WAKE_EN_REG);
+ }
+}
+
+static void setup_gpio_route(const struct byt_gpio_map *sus,
+ const struct byt_gpio_map *core)
+{
+ uint32_t route_reg = 0;
+ int i;
+
+ for (i = 0; i 8; i++) {
+ /* SMI takes precedence and wake_en implies SCI. */
+ if (sus[i].smi)
+ route_reg |= ROUTE_SMI (2 * i);
+ else if (sus[i].sci)
+ route_reg |= ROUTE_SCI (2 * i);
+
+ if (core[i].smi)
+ route_reg |= ROUTE_SMI (2 * (i + 8));
+ else if (core[i].sci)
+ route_reg |= ROUTE_SCI (2 * (i + 8));
+ }
What happens to route_reg after this? I don't see it get returned.
I will remove the code, actually it was used when the SMI was enabled.
+
+#define GPIO_LEVEL_LOW 0
+#define GPIO_LEVEL_HIGH1
+
+#define GPIO_PEDGE_DISABLE 0
+#define GPIO_PEDGE_ENABLE 1
+
+#define GPIO_NEDGE_DISABLE 0
+#define GPIO_NEDGE_ENABLE 1
+
+/* config0[29] - Disable second mask */
+#define PAD_MASK2_DISABLE (1 29)
+
+/* config0[27] - Direct Irq En */
+#define PAD_IRQ_EN (1 27)
+
+/* config0[26] - gd_tne */
+#define PAD_TNE_IRQ(1 26)
+
+/* config0[25] - gd_tpe */
+#define PAD_TPE_IRQ(1 25)
+
+/* config0[24] - Gd Level */
+#define PAD_LEVEL_IRQ (1 24)
+#define PAD_EDGE_IRQ (0 24)
+
+/* config0[17] - Slow clkgate / glitch filter */
+#define PAD_SLOWGF_ENABLE (1 17)
+
+/* config0[16] - Fast clkgate / glitch filter */
+#define PAD_FASTGF_ENABLE (1 16)
+
+/* config0[15] - Hysteresis enable (inverted) */
+#define PAD_HYST_DISABLE (1 15)
+#define PAD_HYST_ENABLE(0 15)
+
+/* config0[14:13] - Hysteresis control */
+#define PAD_HYST_CTRL_DEFAULT (2 13)
+
+/* config0[11] - Bypass Flop */
+#define PAD_FLOP_BYPASS(1 11)
+#define PAD_FLOP_ENABLE(0 11)
+
+/* config0[10:9] - Pull str */
+#define PAD_PU_2K (0 9)
+#define PAD_PU_10K (1 9)
+#define PAD_PU_20K (2 9)
+#define PAD_PU_40K (3 9)
+
+/* config0[8:7] - Pull assign */
+#define PAD_PULL_DISABLE (0 7)
+#define PAD_PULL_UP(1 7)
+#define PAD_PULL_DOWN (2 7)
+
+/* config0[2:0] - Func. pin mux */
+#define PAD_FUNC0 0x0
+#define PAD_FUNC1 0x1
+#define PAD_FUNC2 0x2
+#define PAD_FUNC3 0x3
+#define PAD_FUNC4 0x4
+#define PAD_FUNC5 0x5
+#define PAD_FUNC6 0x6
These could be an anonymous enum (optional)
For me, only the PAD_FUNCX could be part
[U-Boot] [PATCH] common/board_f: implement type casting for gd structure
In case of global data structure defined as register volatile compiler throws an warning about incorrect type used: ---8--- common/board_f.c: In function board_init_f_r: common/board_f.c:1073:2: warning: passing argument 1 of board_init_r +(sizetype)gd-reloc_off discards volatile qualifier from pointer target type [enabled by default] (board_init_r + gd-reloc_off)(gd, gd-relocaddr); ^ common/board_f.c:1073:2: note: expected struct gd_t * but argument is of type volatile struct gd_t * ---8--- An obvious fix is manual casting to gd_t *. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Simon Glass s...@chromium.org Cc: Tom Rini tr...@ti.com --- common/board_f.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/board_f.c b/common/board_f.c index a1dcc5f..96a23ae 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -1070,7 +1070,7 @@ void board_init_f_r(void) * Transfer execution from Flash to RAM by calculating the address * of the in-RAM copy of board_init_r() and calling it */ - (board_init_r + gd-reloc_off)(gd, gd-relocaddr); + (board_init_r + gd-reloc_off)((gd_t *)gd, gd-relocaddr); /* NOTREACHED - board_init_r() does not return */ hang(); -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Exynos: Clock: Fix exynos5_get_periph_rate for I2C.
Commit 2e82e9252695a612ab0cbf40fa0c7368515f6506 'Exynos: Clock: Cleanup soc_get_periph_rate' introduced a bug in I2C config. This patch makes cros_ec keyboard working again on Samsung Chromebook (snow). Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Akshay Saraswat aksha...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Joonyoung Shim jy0922.s...@samsung.com --- arch/arm/cpu/armv7/exynos/clock.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/clock.c b/arch/arm/cpu/armv7/exynos/clock.c index c6455c2..7f47d4d 100644 --- a/arch/arm/cpu/armv7/exynos/clock.c +++ b/arch/arm/cpu/armv7/exynos/clock.c @@ -423,8 +423,8 @@ static unsigned long exynos5_get_periph_rate(int peripheral) case PERIPH_ID_I2C6: case PERIPH_ID_I2C7: src = EXYNOS_SRC_MPLL; - div = readl(clk-div_top0); - sub_div = readl(clk-div_top1); + sub_div = readl(clk-div_top0); + div = readl(clk-div_top1); break; default: debug(%s: invalid peripheral %d, __func__, peripheral); -- 1.8.4.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] warp: Select BOUNCE_BUFFER and CMD_EXT options
On Wed, Feb 25, 2015 at 9:55 AM, Fabio Estevam fabio.este...@freescale.com wrote: Add EXT2/EXT4 and BOUNCE_BUFFER support. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] unassigned-patches/134: Re: [PATCH] x86: minnowmax: add GPIO mapping support
Hi Bin, On 02/24/2015 11:52 PM, Bin Meng wrote: Hi Gabriel, On Mon, Feb 16, 2015 at 5:55 AM, Gabriel Huau cont...@huau-gabriel.fr wrote: Configure the pinctrl as it required to make some IO controllers working (USB/UART/I2C/...). The idea would be in the next version to modify the pch GPIO driver and configure these pins through the device tree. These modifications are ported from the coreboot project. Signed-off-by: Gabriel Huau cont...@huau-gabriel.fr --- arch/x86/cpu/baytrail/Makefile| 1 + arch/x86/cpu/baytrail/gpio.c | 206 +++ arch/x86/include/asm/arch-baytrail/gpio.h | 364 ++ arch/x86/include/asm/arch-baytrail/iomap.h| 73 ++ arch/x86/include/asm/arch-baytrail/irq.h | 119 + arch/x86/include/asm/arch-baytrail/irqroute.h | 67 + arch/x86/include/asm/arch-baytrail/pci_devs.h | 144 ++ arch/x86/include/asm/arch-baytrail/pmc.h | 253 ++ board/intel/minnowmax/minnowmax.c | 212 +++ include/configs/minnowmax.h | 11 + 10 files changed, 1450 insertions(+) create mode 100644 arch/x86/cpu/baytrail/gpio.c create mode 100644 arch/x86/include/asm/arch-baytrail/iomap.h create mode 100644 arch/x86/include/asm/arch-baytrail/irq.h create mode 100644 arch/x86/include/asm/arch-baytrail/irqroute.h create mode 100644 arch/x86/include/asm/arch-baytrail/pci_devs.h create mode 100644 arch/x86/include/asm/arch-baytrail/pmc.h [snip] diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h index 823e051..738c6fa 100644 --- a/include/configs/minnowmax.h +++ b/include/configs/minnowmax.h @@ -69,4 +69,15 @@ /* Avoid a warning in the Realtek Ethernet driver */ #define CONFIG_SYS_CACHELINE_SIZE 16 +/* + * Baytrail has 3 GPIOs bank over PCI, there is no + * driver at the moment so let's disable the command + * and the default x86 driver to avoid any collision + * with the GPIO mapping code. + * @TODO: adding a baytrail-gpio driver and configure + * the muxing through the device tree + */ +#undef CONFIG_INTEL_ICH6_GPIO +#undef CONFIG_CMD_GPIO + Why undef these two? The BayTrail SoC does support GPIO banks in the legacy bridge. I might misunderstood the GPIO subsystem but I thought there was 2 banks available through the PCU iLB GPIO controller which contains the SCORE and SSUS (102 / 44 pins). The intel_ich6_gpio has a limitation of 32 GPIOs per bank and I thought it was just a different controller from the Baytrail, but if I can use it to control all the GPIOs + doing the IO mapping, I'll be glad to do it! #endif /* __CONFIG_H */ -- Regards, Bin Regards, Gabriel --- Added to GNATS database as unassigned-patches/134 Responsible:patch-coord Message-Id: 54edf800.8060...@huau-gabriel.fr In-Reply-To: CAEUhbmVRSwmt8HnW445a2kLzE12dmZcgJ+_Y7uj0u6uqvS=_...@mail.gmail.com References: 1424037328-31636-1-git-send-email-cont...@huau-gabriel.fr CAEUhbmVRSwmt8HnW445a2kLzE12dmZcgJ+_Y7uj0u6uqvS=_...@mail.gmail.com Patch-Date: Wed Feb 25 17:27:44 +0100 2015 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] usb: common: provide a _weak board_usb_cleanup() function
On Wednesday, February 25, 2015 at 10:15:24 AM, Lukasz Majewski wrote: Hi Marek, Hi! On Tuesday, February 24, 2015 at 05:05:29 PM, Lukasz Majewski wrote: Hi Lukasz, [...] I'll stick with your recommendation, though I'd like to -- somehow -- work in Inha's credit into those patches too. What do you think please ? Rob Herring had some comments to Inha original patches, so now I'm confused. Lets see if Inha fixes issues with original patch. It is also possible to drop only one patch from Kishon, namely common: cmd_dfu: invoke board_usb_cleanup() for cleaning up Gah, we're loosing traction here. Maybe we need to sync up and we surely need to apply something, otherwise this will become a chaotic mess. I placed all of the patches into u-boot-usb branch topic/dwc3 . Can you please check if it's working and what is possibly missing ? Let's work on top of that please, OK ? 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 1/2] warp: Add User Mass Storage support
On Wed, Feb 25, 2015 at 9:55 AM, Fabio Estevam fabio.este...@freescale.com wrote: With UMS support we are able to flash the eMMC from U-boot, which is very convenient. Add UMS support to make the eMMC flashing process easier. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_usb_mass_storage: Remove extra 'ums' string in the usage text
On Wed, Feb 25, 2015 at 1:03 PM, Fabio Estevam fabio.este...@freescale.com wrote: Currently the usage text for the 'ums' command looks like this: Usage: ums ums USB_controller [devtype] devnum e.g. ums 0 mmc 0 ,so remove the extra 'ums' in the text. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UMS on mx6sl
On Wednesday, February 25, 2015 at 05:07:00 PM, Fabio Estevam wrote: Hi Marek, On Wed, Feb 25, 2015 at 9:11 AM, Marek Vasut ma...@denx.de wrote: On Wednesday, February 25, 2015 at 03:23:13 AM, Fabio Estevam wrote: Ok, I managed to fix it. Will send a patch tomorrow, thanks Cool, thanks :) Just to let you know that this original problem was caused by an error in the mx6sl-evk board file, so things look good in the USB stack. Of course, I never ever doubted that ;-) 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] cmd_usb_mass_storage: Remove extra 'ums' string in the usage text
On Wednesday, February 25, 2015 at 05:03:19 PM, Fabio Estevam wrote: Currently the usage text for the 'ums' command looks like this: Usage: ums ums USB_controller [devtype] devnum e.g. ums 0 mmc 0 ,so remove the extra 'ums' in the text. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Marek Vasut ma...@denx.de 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 V2 2/9] ARM: OMAP3: Rename omap3.h to omap.h to be generic as all SoCs
On Wed, Feb 25, 2015 at 5:02 AM, Paul Kocialkowski cont...@paulk.fr wrote: Le mardi 24 février 2015 à 16:57 -0600, Nishanth Menon a écrit : This is in preperation of using generic cross OMAP code. I found it a bit confusing at first, since as far as I could see, this series does not introduce any cross-omap header (omap_smc1's prototype is being defined and duplicated in each arch-omap[345]/sys_proto.h, so there could be a need for one). However, since this is the naming scheme using in arch-omap[45], I'm fine with the renaming just for the sake of consistency. The consolidation path is a long way, I think.. lets do that in next stage? Do I get to add a Reviewed-By field? Lets get the discussions completed, then we can.. I think. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: minnowmax: add GPIO mapping support
Hi Bin, On 02/24/2015 11:52 PM, Bin Meng wrote: Hi Gabriel, On Mon, Feb 16, 2015 at 5:55 AM, Gabriel Huau cont...@huau-gabriel.fr wrote: Configure the pinctrl as it required to make some IO controllers working (USB/UART/I2C/...). The idea would be in the next version to modify the pch GPIO driver and configure these pins through the device tree. These modifications are ported from the coreboot project. Signed-off-by: Gabriel Huau cont...@huau-gabriel.fr --- arch/x86/cpu/baytrail/Makefile| 1 + arch/x86/cpu/baytrail/gpio.c | 206 +++ arch/x86/include/asm/arch-baytrail/gpio.h | 364 ++ arch/x86/include/asm/arch-baytrail/iomap.h| 73 ++ arch/x86/include/asm/arch-baytrail/irq.h | 119 + arch/x86/include/asm/arch-baytrail/irqroute.h | 67 + arch/x86/include/asm/arch-baytrail/pci_devs.h | 144 ++ arch/x86/include/asm/arch-baytrail/pmc.h | 253 ++ board/intel/minnowmax/minnowmax.c | 212 +++ include/configs/minnowmax.h | 11 + 10 files changed, 1450 insertions(+) create mode 100644 arch/x86/cpu/baytrail/gpio.c create mode 100644 arch/x86/include/asm/arch-baytrail/iomap.h create mode 100644 arch/x86/include/asm/arch-baytrail/irq.h create mode 100644 arch/x86/include/asm/arch-baytrail/irqroute.h create mode 100644 arch/x86/include/asm/arch-baytrail/pci_devs.h create mode 100644 arch/x86/include/asm/arch-baytrail/pmc.h [snip] diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h index 823e051..738c6fa 100644 --- a/include/configs/minnowmax.h +++ b/include/configs/minnowmax.h @@ -69,4 +69,15 @@ /* Avoid a warning in the Realtek Ethernet driver */ #define CONFIG_SYS_CACHELINE_SIZE 16 +/* + * Baytrail has 3 GPIOs bank over PCI, there is no + * driver at the moment so let's disable the command + * and the default x86 driver to avoid any collision + * with the GPIO mapping code. + * @TODO: adding a baytrail-gpio driver and configure + * the muxing through the device tree + */ +#undef CONFIG_INTEL_ICH6_GPIO +#undef CONFIG_CMD_GPIO + Why undef these two? The BayTrail SoC does support GPIO banks in the legacy bridge. I might misunderstood the GPIO subsystem but I thought there was 2 banks available through the PCU iLB GPIO controller which contains the SCORE and SSUS (102 / 44 pins). The intel_ich6_gpio has a limitation of 32 GPIOs per bank and I thought it was just a different controller from the Baytrail, but if I can use it to control all the GPIOs + doing the IO mapping, I'll be glad to do it! #endif /* __CONFIG_H */ -- Regards, Bin Regards, Gabriel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu
On Wednesday, February 25, 2015 at 02:09:45 PM, Lukasz Majewski wrote: Hi Marek, Hi! On Tuesday, February 24, 2015 at 11:29:39 PM, Lukasz Majewski wrote: On Tue, 24 Feb 2015 18:56:59 +0100 Marek Vasut ma...@denx.de wrote: On Monday, February 23, 2015 at 10:06:08 AM, Lukasz Majewski wrote: Dear Marek, Hi! The following changes since commit d3d087c29c59dbae98c02de098e7e03f29320fe0: usb: musb-new: omap2430: Reset the MUSB controller early (2015-01-22 08:19:18 +0100) are available in the git repository at: git://git.denx.de/u-boot-dfu.git master for you to fetch changes up to 934d274534275f5f4bbb45697a13c50ae54be346: odroid: adjust get_dfu_alt_*() functions to new declarations (2015-02-23 09:48:22 +0100) Is this PR still valid please ? Did you change something on your DFU/master by any chance , like applying additional patches or somesuch please ? I've applied some fastboot related patches on the -dfu branch today. However, the PR is still valid and patches mentioned in it have been tested and validated. If possible please pull this PR. Hi! In case I pull u-boot-dfu/master , I pull 7 patches though, is that right? There are 9 patches actually. It's OK to pull them. Uh oh, next time I'll ask you to send an updated PR. Applied all 9, thanks! 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 V2 7/9] ARM: OMAP3: Introduce OMAP3 Cortex-A8 revision specific errata
On 02/25/2015 05:15 AM, Paul Kocialkowski wrote:
Le mardi 24 février 2015 à 16:57 -0600, Nishanth Menon a écrit :
430973: Stale prediction on replaced inter working branch causes
Cortex-A8 to execute in the wrong ARM/Thumb state
Impacts: Everything lower than r2p1
Work around: Set IBE to 1
According to the Linux kernel source, this should only affect r1p*
(hence, not r2p0):
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mm/proc-v7.S#n321
I did look at the official Cortex-A8 errata doc (I think this is under
NDA at least under TI).. Doc revision 20.0
This has a Errata Summary Table where X indicates the revision
impacted. As per that, I see:
r1p1, r1p2, r1p3, r1p7 impacted. the first not impacted is r2p1.
Hence the cmp r3, #0x21 (and orrlt).
Can someone from ARM ltd comment if there could be a better
implementation? I will post a V3 based on latest documentation on my hand.
454179: Stale prediction may inhibit target address misprediction on
next predicted taken branch
Impacts: Everything lower than r2p1
Work around: Set IBE and disable branch size mispredict to 1
621766: Under a specific set of conditions, executing a sequence of
NEON or vfp load instructions can cause processor deadlock
Impacts: Everything lower than r2p1
Work around: Set L1NEON to 1
Erratum 458693 also sets L1NEON bit and is said to only affect r2p0
according to the Linux kernel source:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mm/proc-v7.S#n321
I'm not sure this is relevant (different erratum but similar
workaround), but it seems odd to me.
Since the OMAP3 generation of processors have a wide variety of CPU
revisions, it is more logical to enforce an implementation using
revision checks.
Anyways, this worked just fine on my omap3630 device ( r2p1) and didn't
trigger the errata workarounds. I reckon someone would have to test on a
device that does require those workarounds (e.g. omap35xx).
Signed-off-by: Nishanth Menon n...@ti.com
---
README |3 +++
arch/arm/cpu/armv7/omap3/board.c|2 +-
arch/arm/cpu/armv7/omap3/lowlevel_init.S| 37
+++
arch/arm/include/asm/arch-omap3/sys_proto.h |1 +
4 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/README b/README
index d76cdc68d406..f309e27bbd02 100644
--- a/README
+++ b/README
@@ -625,6 +625,9 @@ The following options need to be configured:
with CONFIG_ARM_ARCH_CP15_ERRATA define. These need to have an
SoC specific implementation of the erratum workaround to
function.
+CONFIG_ARM_ERRATA_430973
+CONFIG_ARM_ERRATA_454179
+CONFIG_ARM_ERRATA_621766
CONFIG_ARM_ERRATA_798870
- Driver Model
diff --git a/arch/arm/cpu/armv7/omap3/board.c
b/arch/arm/cpu/armv7/omap3/board.c
index 51abc4b09e36..7ce30949a6c6 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -408,7 +408,7 @@ static void omap3_emu_romcode_call(u32 service_id, u32
*parameters)
do_omap3_emu_romcode_call(service_id, OMAP3_PUBLIC_SRAM_SCRATCH_AREA);
}
-static void omap3_update_aux_cr_secure(u32 set_bits, u32 clear_bits)
+void omap3_update_aux_cr_secure(u32 set_bits, u32 clear_bits)
{
u32 acr;
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index 84591b8b5bab..b8e6ebccd4e7 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -48,6 +48,43 @@ ENTRY(do_omap3_emu_romcode_call)
POP {r4-r12, pc}
ENDPROC(do_omap3_emu_romcode_call)
+#ifdef CONFIG_ARM_ARCH_CP15_ERRATA
+.globl arch_cp15_errata_workaround
+/*
+ * R0 has MIDR
+ * R1 has CPU Variant (bits 20-23)
+ * R2 has CPU Revision (bits 0-3)
+ * R3 is compbined CPU variant 4 + CPU revision
+ */
+ENTRY(arch_cp15_errata_workaround)
+push{r4-r12, lr}@ save registers - ROM code may pollute
+
+mov r0, #0 @ Nothing to set in ACR
+mov r1, #0 @ Nothing to clear in ACR
+
+#ifdef CONFIG_ARM_ERRATA_454179
+cmp r3, #0x21 @ Only on r2p1
+orrlt r0, r0, #(0x3 6) @ Set DBSM(BIT7) and IBE(BIT6) bits
+#endif
+
+#ifdef CONFIG_ARM_ERRATA_430973
+cmp r3, #0x21 @ Only on r2p1
+orrlt r0, r0, #(0x1 6) @ Set IBE bit
+#endif
+
+#ifdef CONFIG_ARM_ERRATA_621766
+cmp r3, #0x21 @ Only on r2p1
+orrlt r0, r0, #(0x1 5) @ Set L1NEON bit
+#endif
+
+add r2, r1, r0
+teq r2, #0 @ See if nothing to set or clear
+bne omap3_update_aux_cr_secure @update as per ROM code
configuration needs
+
+pop {r4-r12, pc}@restore the registers back.
Re: [U-Boot] [PATCH v4 03/10] Exynos542x: Add workaround for ARM errata 798870
Akshay Saraswat aksha...@samsung.com writes: [...] I don't think it hurts to have a generic function with ARM errata workaround implementation. Whoever wish to use it can call it in their boot path. And it's not even getting executed right now for any SoC other than Exynos542x, so those who don't want it need not bother about it. This was the intention. :) What about exynos542x platforms which also have secure firmware? Are you testing this on any of those (e.g. exynos5422-odroid-xu3?) Kevin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] stdio: extend name to 32 symbols
With limit of 16 symbols very simple device names derived drom device
tree description could not be displayed correctly.
For example serial0@0xc0fc1000 will be truncated to sensless
serial0@0xc0fc10 - note dropped tariling zeros.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Simon Glass s...@chromium.org
Cc: Tom Rini tr...@ti.com
---
include/stdio_dev.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/stdio_dev.h b/include/stdio_dev.h
index 24da23f..95d6246 100644
--- a/include/stdio_dev.h
+++ b/include/stdio_dev.h
@@ -23,7 +23,7 @@
struct stdio_dev {
int flags; /* Device flags: input/output/system
*/
int ext;/* Supported extensions
*/
- charname[16]; /* Device name
*/
+ charname[32]; /* Device name
*/
/* GENERAL functions */
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 03/10] Exynos542x: Add workaround for ARM errata 798870
Nishanth Menon n...@ti.com writes:
On 13:27-20150220, Akshay Saraswat wrote:
This patch adds workaround for ARM errata 798870 which says
If back-to-back speculative cache line fills (fill A and fill B) are
issued from the L1 data cache of a CPU to the L2 cache, the second
request (fill B) is then cancelled, and the second request would have
detected a hazard against a recent write or eviction (write B) to the
same cache line as fill B then the L2 logic might deadlock.
Signed-off-by: Kimoon Kim kimoon@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
Changes since v3:
- Added errata number in comment.
- Moved changes to arm generic armv7.h
Changes since v2:
- No change.
Changes since v1:
- Added Reviewed-by Tested-by.
- Added space before */ on line # 40.
arch/arm/include/asm/armv7.h | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index a13da23..a2040b7 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -69,6 +69,22 @@
#define CP15DSB asm volatile (mcr p15, 0, %0, c7, c10, 4 : : r
(0))
#define CP15DMB asm volatile (mcr p15, 0, %0, c7, c10, 5 : : r
(0))
+/*
+ * Workaround for ARM errata # 798870
+ * Set L2ACTLR[7] to reissue any memory transaction in the L2 that has been
+ * stalled for 1024 cycles to verify that its hazard condition still exists.
+ */
+static inline void v7_enable_l2_hazard_detect(void)
+{
+uint32_t val;
+
+/* L2ACTLR[7]: Enable hazard detect timeout */
+asm volatile (mrc p15, 1, %0, c15, c0, 0\n\t : =r(val));
+val |= (1 7);
+asm volatile (mcr p15, 1, %0, c15, c0, 0\n\t : : r(val));
This wont work for us in DRA7/OMAP5 L2ACTLR cannot be modified by
u-boot. has to go to secure world using smc call.
I believe the same may be true even on some exynos5 platforms with
secure firmware (e.g. exynos5422-odroid-xu3).
Kevin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot on raspberry 2: booting in SVC secure mode
On 02/25/2015 02:30 AM, Vincent wrote: Hi, as explained here http://community.arm.com/message/25127, it is possible to boot the raspberry 2 in secure mode, by adding the kernel_old=1 option in config.txt. The main effects of this option are: - all 4 cores start executing in secure SVC mode instead of non-secure SVC mode - all 4 cores start at 0x instead of 0x8000 - the initial boot code that setup SMP and exits secure mode is not executed After browsing u-boot's source code, it seems that their boot code is more or less extracted from what u-boot is doing. However I didn't manage to compile u-boot for the raspberry 2 supporting this secure mode. Could anyone explain me what options I need to configure in rpi_2_defconfig so that u-boot supports secure boot for the raspberry 2 and what the boot sequence will be in this case ? I don't mind fixing the code if necessary but I'm a bit lost in the order of events in the initialization. (Luckily I just happened to notice this message while looking at another one nearby. CCing the relevant board maintainer(s) explicitly would help your messages be noticed) To modify U-Boot to support the alternate entry point/load address, you'd hopefully only need to change the definition of CONFIG_SYS_TEXT_BASE in include/configs/rpi*.h. I wasn't aware of the thread/option you mention, so I have not attempted to boot the RPi2 U-Boot in secure mode. If you're lucky, U-Boot itself will just work once TEXT_BASE is fixed. To boot a kernel, you'll probably need to at least configure the ARM architected timers CNTFRQ register for the kernel. Perhaps there are a few other things like that missing? It might be interesting to enable U-Boot's PSCI support on the RPi2, so that an upstream kernel could gain SMP support without the need for explicit BCM2836 SMP support code. So far, I haven't attempted anything with an (upstream) kernel on RPi2, just U-Boot. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
Dear Dave Kucharczyk, On Wed, Feb 25, 2015 at 3:19 AM, DaveKucharczyk david.kucharc...@gmail.com wrote: I'm porting U-Boot for an MX51 based board. This is the boot sequence with debug on... U-Boot 2014.07-svn10 (Feb 24 2015 - 15:49:39) initcall: 9ff85820 U-Boot code: 9FF8 - 9FFA6824 BSS: - 9FFD944C initcall: 9ff8118c CPU: Freescale i.MX51 rev3.0 at 800 MHz initcall: 9ff858ac I2C: ready initcall: 9ff85894 DRAM: initcall: 9ff81ff4 initcall: 9ff85a04 Monitor len: 0005944C Ram size: 1000 Ram top: A000 initcall: 9ff855b0 initcall: 9ff857c8 TLB table from 9fff to 9fff4000 initcall: 9ff855c8 initcall: 9ff8577c Reserving 357k for U-Boot at: 9ff96000 initcall: 9ff85750 Reserving 1280k for malloc() at: 9fe56000 initcall: 9ff85850 Reserving 88 Bytes for Board Info at: 9fe55fa8 initcall: 9ff855d0 initcall: 9ff8571c Reserving 216 Bytes for Global Data at: 9fe55ed0 initcall: 9ff856b8 initcall: 9ff855e4 initcall: 9ff859ec initcall: 9ff85948 RAM Configuration: Bank #0: 9000 256 MiB DRAM: 256 MiB initcall: 9ff8569c New Stack Pointer is: 9fe55eb0 initcall: 9ff85618 initcall: 9ff85648 Relocation Offset is: 00016000 Relocating to 9ff96000, new gd at 9fe55ed0, sp at 9fe55eb0 And that's where it hangs and resets in a continuous loop. I confirmed that the entire init_sequence completed in board_f.c, but never makes it to board_r.c So...according to ./arch/arm/lib/crt0.S ... /* assembly code */ board_init_f --we make it out of here /* assembly code */ -- stuck somewhere in here relocate_code -- stuck somewhere in here /* assembly code */ -- stuck somewhere in here board_init_r --we never make it here I can't sprinkle any debug statements where it's stuck because it's all assembly. Before I break out the BDI tomorrow does anyone have any ideas? BTW it works on our 512MB board, but not the 256MB board. Thanks. The following needs to be added for i.MX51 and i.MX53 too: http://lists.denx.de/pipermail/u-boot/2015-February/205849.html This should fix your issue. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 07/11] ARM: OMAP3: Get rid of omap3_gp_romcode_call and replace with omap_smc1
omap_smc1 is now generic enough to remove duplicate
omap3_gp_romcode_call logic that omap3 introduced.
As part of this change, move to using the generic lowlevel_init.S for
omap3 as well.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap-common/Makefile|2 +-
arch/arm/cpu/armv7/omap-common/lowlevel_init.S |2 ++
arch/arm/cpu/armv7/omap3/board.c |6 ++
arch/arm/cpu/armv7/omap3/lowlevel_init.S | 11 ---
arch/arm/include/asm/arch-omap3/sys_proto.h|2 +-
5 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile
b/arch/arm/cpu/armv7/omap-common/Makefile
index 7695e16d36f5..f3725b267c99 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -28,7 +28,7 @@ endif
ifeq ($(CONFIG_OMAP34XX),)
obj-y += boot-common.o
-obj-y += lowlevel_init.o
endif
+obj-y += lowlevel_init.o
obj-y += mem-common.o
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 9b24369e4dc1..7d0f09496d85 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -16,11 +16,13 @@
#include asm/arch/spl.h
#include linux/linkage.h
+#ifndef CONFIG_OMAP34XX
ENTRY(save_boot_params)
ldr r1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS
str r0, [r1]
bx lr
ENDPROC(save_boot_params)
+#endif
ENTRY(omap_smc1)
PUSH{r4-r12, lr}@ save registers - ROM code may pollute
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 90d6ae7bb5f5..51abc4b09e36 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -418,8 +418,7 @@ static void omap3_update_aux_cr_secure(u32 set_bits, u32
clear_bits)
acr |= set_bits;
if (get_device_type() == GP_DEVICE) {
- omap3_gp_romcode_call(OMAP3_GP_ROMCODE_API_WRITE_ACR,
- acr);
+ omap_smc1(OMAP3_GP_ROMCODE_API_WRITE_ACR, acr);
} else {
struct emu_hal_params emu_romcode_params;
emu_romcode_params.num_params = 1;
@@ -459,8 +458,7 @@ static void omap3_update_aux_cr(u32 set_bits, u32
clear_bits)
static void omap3_invalidate_l2_cache_secure(void)
{
if (get_device_type() == GP_DEVICE) {
- omap3_gp_romcode_call(OMAP3_GP_ROMCODE_API_L2_INVAL,
- 0);
+ omap_smc1(OMAP3_GP_ROMCODE_API_L2_INVAL, 0);
} else {
struct emu_hal_params emu_romcode_params;
emu_romcode_params.num_params = 1;
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index 78577b1d1c75..84591b8b5bab 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -27,17 +27,6 @@ ENTRY(save_boot_params)
ENDPROC(save_boot_params)
#endif
-ENTRY(omap3_gp_romcode_call)
- PUSH {r4-r12, lr} @ Save all registers from ROM code!
- MOV r12, r0 @ Copy the Service ID in R12
- MOV r0, r1 @ Copy parameter to R0
- mcr p15, 0, r0, c7, c10, 4 @ DSB
- mcr p15, 0, r0, c7, c10, 5 @ DMB
- .word 0xe1600070 @ SMC #0 to enter monitor - hand assembled
- @ because we use -march=armv5
- POP {r4-r12, pc}
-ENDPROC(omap3_gp_romcode_call)
-
/*
* Funtion for making PPA HAL API calls in secure devices
* Input:
diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h
b/arch/arm/include/asm/arch-omap3/sys_proto.h
index bcf92fbe658b..c06605d533d3 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -73,6 +73,6 @@ void power_init_r(void);
void dieid_num_r(void);
void get_dieid(u32 *id);
void do_omap3_emu_romcode_call(u32 service_id, u32 parameters);
-void omap3_gp_romcode_call(u32 service_id, u32 parameter);
+void omap_smc1(u32 service, u32 val);
u32 warm_reset(void);
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 11/11] ARM: OMAP3: rx51: Enable workaround for ARM errata 454179, 430973, 621766
RX51 has a secure logic which uses different parameters compared to
traditional implementation. So, make the generic secure acr write
over-ride-able by board file and refactor rx51 code to use this.
While at it, enable the OMAP3 specific errata code for 454179, 430973,
621766.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap3/board.c| 45 ---
arch/arm/include/asm/arch-omap3/sys_proto.h |1 +
board/nokia/rx51/rx51.c | 19 ++-
include/configs/nokia_rx51.h|4 +++
4 files changed, 37 insertions(+), 32 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 5587a10cdafd..bfbc197bf99c 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -404,31 +404,30 @@ static void omap3_emu_romcode_call(u32 service_id, u32
*parameters)
do_omap3_emu_romcode_call(service_id, OMAP3_PUBLIC_SRAM_SCRATCH_AREA);
}
-void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
- u32 cpu_variant, u32 cpu_rev)
+void __weak omap3_set_aux_cr_secure(u32 acr)
{
- if (get_device_type() == GP_DEVICE) {
- omap_smc1(OMAP3_GP_ROMCODE_API_WRITE_ACR, acr);
- } else {
- struct emu_hal_params emu_romcode_params;
- emu_romcode_params.num_params = 1;
- emu_romcode_params.param1 = acr;
- omap3_emu_romcode_call(OMAP3_EMU_HAL_API_WRITE_ACR,
- (u32 *)emu_romcode_params);
- }
+ struct emu_hal_params emu_romcode_params;
+
+ emu_romcode_params.num_params = 1;
+ emu_romcode_params.param1 = acr;
+ omap3_emu_romcode_call(OMAP3_EMU_HAL_API_WRITE_ACR,
+ (u32 *)emu_romcode_params);
}
-static void omap3_update_aux_cr_secure(u32 set_bits, u32 clear_bits)
+void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
+ u32 cpu_variant, u32 cpu_rev)
{
- u32 acr;
+ /* Write ACR - affects secure banked bits */
+ if (get_device_type() == GP_DEVICE)
+ omap_smc1(OMAP3_GP_ROMCODE_API_WRITE_ACR, acr);
+ else
+ omap3_set_aux_cr_secure(acr);
- /* Read ACR */
- asm volatile (mrc p15, 0, %0, c1, c0, 1 : =r (acr));
- acr = ~clear_bits;
- acr |= set_bits;
- v7_arch_cp15_set_acr(acr, 0, 0, 0, 0);
+ /* Write ACR - affects non-secure banked bits - some erratas need it */
+ asm volatile (mcr p15, 0, %0, c1, c0, 1 : : r (acr));
}
+
#ifndef CONFIG_SYS_L2CACHE_OFF
static void omap3_update_aux_cr(u32 set_bits, u32 clear_bits)
{
@@ -438,9 +437,8 @@ static void omap3_update_aux_cr(u32 set_bits, u32
clear_bits)
asm volatile (mrc p15, 0, %0, c1, c0, 1 : =r (acr));
acr = ~clear_bits;
acr |= set_bits;
+ v7_arch_cp15_set_acr(acr, 0, 0, 0, 0);
- /* Write ACR - affects non-secure banked bits */
- asm volatile (mcr p15, 0, %0, c1, c0, 1 : : r (acr));
}
/* Invalidate the entire L2 cache from secure mode */
@@ -459,10 +457,9 @@ static void omap3_invalidate_l2_cache_secure(void)
void v7_outer_cache_enable(void)
{
- /* Set L2EN */
- omap3_update_aux_cr_secure(0x2, 0);
/*
+* Set L2EN
* On some revisions L2EN bit is banked on some revisions it's not
* No harm in setting both banked bits(in fact this is required
* by an erratum)
@@ -472,10 +469,8 @@ void v7_outer_cache_enable(void)
void omap3_outer_cache_disable(void)
{
- /* Clear L2EN */
- omap3_update_aux_cr_secure(0, 0x2);
-
/*
+* Clear L2EN
* On some revisions L2EN bit is banked on some revisions it's not
* No harm in clearing both banked bits(in fact this is required
* by an erratum)
diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h
b/arch/arm/include/asm/arch-omap3/sys_proto.h
index c06605d533d3..ff1bf736cf06 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -74,5 +74,6 @@ void dieid_num_r(void);
void get_dieid(u32 *id);
void do_omap3_emu_romcode_call(u32 service_id, u32 parameters);
void omap_smc1(u32 service, u32 val);
+void omap3_set_aux_cr_secure(u32 acr);
u32 warm_reset(void);
#endif
diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c
index 08fcaf21b3c6..3d019b01428b 100644
--- a/board/nokia/rx51/rx51.c
+++ b/board/nokia/rx51/rx51.c
@@ -341,6 +341,17 @@ static void omap3_emu_romcode_call(u32 service_id, u32
*parameters)
do_omap3_emu_romcode_call(service_id, OMAP3_PUBLIC_SRAM_SCRATCH_AREA);
}
+void omap3_set_aux_cr_secure(u32 acr)
+{
+ struct emu_hal_params_rx51 emu_romcode_params = { 0, };
+
+ emu_romcode_params.num_params = 2;
+ emu_romcode_params.param1 = acr;
+
+ omap3_emu_romcode_call(OMAP3_EMU_HAL_API_WRITE_ACR,
+
[U-Boot] [PATCH V3 01/11] ARM: Introduce erratum workaround for 798870
Add workaround for Cortex-A15 ARM erratum 798870 which says
If back-to-back speculative cache line fills (fill A and fill B) are
issued from the L1 data cache of a CPU to the L2 cache, the second
request (fill B) is then cancelled, and the second request would have
detected a hazard against a recent write or eviction (write B) to the
same cache line as fill B then the L2 logic might deadlock.
Implementations for SoC families such as Exynos, OMAP5/DRA7 etc
will be widely different.
Every SoC has slightly different manner of setting up access to L2ACLR
and similar registers since the Secure Monitor handling of Secure
Monitor Call(smc) is diverse. Hence an weak function is introduced
which may be overriden to implement SoC specific accessor implementation.
Based on ARM errata Document revision 18.0 (22 Nov 2013)
Signed-off-by: Nishanth Menon n...@ti.com
---
README |5 +
arch/arm/cpu/armv7/Makefile |2 +-
arch/arm/cpu/armv7/cp15.c| 23 +++
arch/arm/cpu/armv7/start.S | 20
arch/arm/include/asm/armv7.h |3 +++
5 files changed, 52 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/armv7/cp15.c
diff --git a/README b/README
index a28ff133ee05..11ec37ba4a00 100644
--- a/README
+++ b/README
@@ -621,6 +621,11 @@ The following options need to be configured:
exists, unlike the similar options in the Linux kernel. Do not
set these options unless they apply!
+ NOTE: The following can be machine specific errata. These
+ do have ability to provide rudimentary version and machine
+ specific checks, but expect no product checks.
+ CONFIG_ARM_ERRATA_798870
+
- Driver Model
Driver model is a new framework for devices in U-Boot
introduced in early 2014. U-Boot is being progressively
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 409e6f5651b6..43da3e586f71 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -9,7 +9,7 @@ extra-y := start.o
obj-y += cache_v7.o
-obj-y += cpu.o
+obj-y += cpu.o cp15.o
obj-y += syslib.o
ifneq
($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY)$(CONFIG_SUNXI),)
diff --git a/arch/arm/cpu/armv7/cp15.c b/arch/arm/cpu/armv7/cp15.c
new file mode 100644
index ..8ac81c9ba147
--- /dev/null
+++ b/arch/arm/cpu/armv7/cp15.c
@@ -0,0 +1,23 @@
+/*
+ * (C) Copyright 2015 Texas Insturments
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/*
+ * CP15 specific code
+ */
+
+#include common.h
+#include command.h
+#include asm/system.h
+#include asm/cache.h
+#include asm/armv7.h
+#include linux/compiler.h
+
+void __weak v7_arch_cp15_set_l2aux_ctrl(u32 l2actlr, u32 cpu_midr,
+u32 cpu_rev_comb, u32 cpu_variant,
+u32 cpu_rev)
+{
+ asm volatile (mcr p15, 1, %0, c15, c0, 0\n\t : : r(l2actlr));
+}
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 70048c10aee6..ec46cec9cb1c 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -163,6 +163,26 @@ ENTRY(cpu_init_cp15)
mcr p15, 0, r0, c15, c0, 1 @ write diagnostic register
#endif
+ mrc p15, 0, r1, c0, c0, 0 @ r1 has Read Main ID Register (MIDR)
+ mov r3, r1, lsr #20 @ get variant field
+ and r3, r3, #0xf@ r3 has CPU variant
+ and r4, r1, #0xf@ r4 has CPU revision
+ mov r2, r3, lsl #4 @ shift variant field for combined value
+ orr r2, r4, r2 @ r2 has combined CPU variant + revision
+
+#ifdef CONFIG_ARM_ERRATA_798870
+ cmp r2, #0x30 @ Applies to lower than R3p0
+ bge skip_errata_798870 @ skip if not affected rev
+ cmp r2, #0x20 @ Applies to including and above R2p0
+ blt skip_errata_798870 @ skip if not affected rev
+
+ mrc p15, 1, r0, c15, c0, 0 @ read l2 aux ctrl reg
+ orr r0, r0, #1 7 @ Enable hazard-detect timeout
+ b v7_arch_cp15_set_l2aux_ctrl
+ isb @ Recommended ISB after l2actlr update
+skip_errata_798870:
+#endif
+
mov pc, lr @ back to my caller
ENDPROC(cpu_init_cp15)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index a13da23cf172..30e0cc3cf3d5 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -93,6 +93,9 @@ extern char __secure_end[];
#endif /* CONFIG_ARMV7_NONSEC || CONFIG_ARMV7_VIRT */
+void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32 cpu_midr,
+u32 cpu_rev_comb, u32 cpu_variant,
+u32 cpu_rev);
#endif /* ! __ASSEMBLY__
[U-Boot] [PATCH V3 08/11] ARM: DRA7 / OMAP5: Add workaround for ARM errata 798870
From: Praveen Rao p...@ti.com
This patch enables the workaround for ARM errata 798870 for OMAP5 /
DRA7 which says If back-to-back speculative cache line fills (fill
A and fill B) are issued from the L1 data cache of a CPU to the
L2 cache, the second request (fill B) is then cancelled, and the
second request would have detected a hazard against a recent write or
eviction (write B) to the same cache line as fill B then the L2 logic
might deadlock.
An l2auxctlr accessor implementation for OMAP5 and DRA7 is introduced
here as well.
Signed-off-by: Praveen Rao p...@ti.com
Signed-off-by: Angela Stegmaier angelaba...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap5/hwinit.c |7 +++
arch/arm/include/asm/arch-omap5/sys_proto.h |4
include/configs/ti_omap5_common.h |3 +++
3 files changed, 14 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index a8a474a88be9..f8060555b680 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -381,3 +381,10 @@ void setup_warmreset_time(void)
rst_val |= rst_time;
writel(rst_val, (*prcm)-prm_rsttime);
}
+
+void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32 cpu_midr,
+u32 cpu_rev_comb, u32 cpu_variant,
+u32 cpu_rev)
+{
+ omap_smc1(OMAP5_SERVICE_L2ACTLR_SET, l2auxctrl);
+}
diff --git a/arch/arm/include/asm/arch-omap5/sys_proto.h
b/arch/arm/include/asm/arch-omap5/sys_proto.h
index 103830319a41..37dc9925eae2 100644
--- a/arch/arm/include/asm/arch-omap5/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap5/sys_proto.h
@@ -66,4 +66,8 @@ static inline u32 usec_to_32k(u32 usec)
{
return div_round_up(32768 * usec, 100);
}
+
+void omap_smc1(u32 service, u32 val);
+#define OMAP5_SERVICE_L2ACTLR_SET0x104
+
#endif
diff --git a/include/configs/ti_omap5_common.h
b/include/configs/ti_omap5_common.h
index 925cb42dd38d..09f05f18a75d 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -21,6 +21,9 @@
#define CONFIG_DISPLAY_BOARDINFO
#define CONFIG_ARCH_CPU_INIT
+/* Common ARM Erratas */
+#define CONFIG_ARM_ERRATA_798870
+
#define CONFIG_SYS_CACHELINE_SIZE 64
/* Use General purpose timer 1 */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 05/11] ARM: OMAP: Change set_pl310_ctrl_reg to be generic
set_pl310_ctrl_reg does use the Secure Monitor Call (SMC) to setup
PL310 control register, however, that is something that is generic
enough to be used for OMAP5 generation of processors as well. The
only difference being the service being invoked for the function.
So, convert the service to a macro and use a generic name (same as
that used in Linux for some consistency). While at that, also add
a data barrier which is necessary as per recommendation.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 13 -
arch/arm/cpu/armv7/omap4/hwinit.c |4 ++--
arch/arm/include/asm/arch-omap4/sys_proto.h|5 -
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 86c0e4217478..9b24369e4dc1 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -22,11 +22,14 @@ ENTRY(save_boot_params)
bx lr
ENDPROC(save_boot_params)
-ENTRY(set_pl310_ctrl_reg)
- PUSH{r4-r11, lr}@ save registers - ROM code may pollute
+ENTRY(omap_smc1)
+ PUSH{r4-r12, lr}@ save registers - ROM code may pollute
@ our registers
- LDR r12, =0x102 @ Set PL310 control register - value in R0
+ MOV r12, r0 @ Service
+ MOV r0, r1 @ Argument
+ DSB
+ DMB
.word 0xe1600070 @ SMC #0 - hand assembled because -march=armv5
@ call ROM Code API to set control register
- POP {r4-r11, pc}
-ENDPROC(set_pl310_ctrl_reg)
+ POP {r4-r12, pc}
+ENDPROC(omap_smc1)
diff --git a/arch/arm/cpu/armv7/omap4/hwinit.c
b/arch/arm/cpu/armv7/omap4/hwinit.c
index db16548fac49..9792761d40a0 100644
--- a/arch/arm/cpu/armv7/omap4/hwinit.c
+++ b/arch/arm/cpu/armv7/omap4/hwinit.c
@@ -159,11 +159,11 @@ void init_omap_revision(void)
#ifndef CONFIG_SYS_L2CACHE_OFF
void v7_outer_cache_enable(void)
{
- set_pl310_ctrl_reg(1);
+ omap_smc1(OMAP4_SERVICE_PL310_CONTROL_REG_SET, 1);
}
void v7_outer_cache_disable(void)
{
- set_pl310_ctrl_reg(0);
+ omap_smc1(OMAP4_SERVICE_PL310_CONTROL_REG_SET, 0);
}
#endif /* !CONFIG_SYS_L2CACHE_OFF */
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index e19975efaf50..f425e3af54f5 100644
--- a/arch/arm/include/asm/arch-omap4/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap4/sys_proto.h
@@ -37,7 +37,7 @@ void do_set_mux(u32 base, struct pad_conf_entry const *array,
int size);
void set_muxconf_regs_essential(void);
u32 wait_on_value(u32, u32, void *, u32);
void sdelay(unsigned long);
-void set_pl310_ctrl_reg(u32 val);
+void omap_smc1(u32 service, u32 val);
void setup_clocks_for_console(void);
void prcm_init(void);
void bypass_dpll(u32 const base);
@@ -57,4 +57,7 @@ int omap_vc_bypass_send_value(u8 sa, u8 reg_addr, u8
reg_data);
u32 warm_reset(void);
void force_emif_self_refresh(void);
void setup_warmreset_time(void);
+
+#define OMAP4_SERVICE_PL310_CONTROL_REG_SET0x102
+
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] Clean out SPL ready for driver model
Hello Simon, On Wed, 25 Feb 2015 07:00:23 -0700, Simon Glass s...@chromium.org wrote: Hi Albert, On 25 February 2015 at 06:27, Simon Glass s...@chromium.org wrote: Hi Albert, On 24 February 2015 at 23:28, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Simon, I'm a bit (read: almost completely) lost re all the gdata removal stuff; seems like there is/was this series, and there is the 9-patch series too, and possibly others... Right now, what patch( seri)es should be applied exactly? I picked up everything I thought was relevant and sent a v4 series starting here: http://patchwork.ozlabs.org/patch/438581/ The cover letter is here: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/211429 So that is all now. It does need a rebase due to the mach-tegra file move, but the conflict is trivial. Just in case, I have updated u-boo-dm/spl-working with a rebased version. Let me know if I should send v5. No need for a v5 just for the mach-* move IMO. I'll look at v4. Regards, Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 09/11] ARM: OMAP5 / DRA7: Setup L2 Aux Control Register with recommended configuration
Update to existing recommendation for L2ACTLR configuration to prevent
system instability and optimize performance.
These apply to both OMAP5 and DRA7.
Reported-by: Vivek Chengalvala vchengalv...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap5/hwinit.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index f8060555b680..8d6b59eeb044 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -304,6 +304,21 @@ void config_data_eye_leveling_samples(u32 emif_base)
(*ctrl)-control_emif2_sdram_config_ext);
}
+void init_cpu_configuration(void)
+{
+ u32 l2actlr;
+
+ asm volatile(mrc p15, 1, %0, c15, c0, 0 : =r(l2actlr));
+ /*
+* L2ACTLR: Ensure to enable the following:
+* 3: Disable clean/evict push to external
+* 4: Disable WriteUnique and WriteLineUnique transactions from master
+* 8: Disable DVM/CMO message broadcast
+*/
+ l2actlr |= 0x118;
+ omap_smc1(OMAP5_SERVICE_L2ACTLR_SET, l2actlr);
+}
+
void init_omap_revision(void)
{
/*
@@ -342,6 +357,7 @@ void init_omap_revision(void)
default:
*omap_si_rev = OMAP5430_SILICON_ID_INVALID;
}
+ init_cpu_configuration();
}
void reset_cpu(ulong ignored)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 10/11] ARM: OMAP3: Enable workaround for ARM errata 454179, 430973, 621766
Enable the OMAP3 specific errata code for 454179, 430973, 621766
and while at it, remove legacy non-revision checked errata logic.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap3/board.c | 31 ++-
include/configs/am3517_crane.h |4
include/configs/am3517_evm.h |4
include/configs/cm_t35.h |4
include/configs/cm_t3517.h |4
include/configs/dig297.h |4
include/configs/mcx.h |4
include/configs/omap3_evm_common.h |4
include/configs/omap3_logic.h |4
include/configs/omap3_mvblx.h |4
include/configs/omap3_pandora.h|4
include/configs/omap3_sdp3430.h|4
include/configs/tam3517-common.h |4
include/configs/tao3530.h |4
include/configs/ti_omap3_common.h |5 +
include/configs/tricorder.h|4
16 files changed, 71 insertions(+), 21 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 51abc4b09e36..5587a10cdafd 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -35,7 +35,6 @@ DECLARE_GLOBAL_DATA_PTR;
/* Declarations */
extern omap3_sysinfo sysinfo;
-static void omap3_setup_aux_cr(void);
#ifndef CONFIG_SYS_L2CACHE_OFF
static void omap3_invalidate_l2_cache_secure(void);
#endif
@@ -246,9 +245,6 @@ void s_init(void)
try_unlock_memory();
- /* Errata workarounds */
- omap3_setup_aux_cr();
-
#ifndef CONFIG_SYS_L2CACHE_OFF
/* Invalidate L2-cache from secure mode */
omap3_invalidate_l2_cache_secure();
@@ -408,15 +404,9 @@ static void omap3_emu_romcode_call(u32 service_id, u32
*parameters)
do_omap3_emu_romcode_call(service_id, OMAP3_PUBLIC_SRAM_SCRATCH_AREA);
}
-static void omap3_update_aux_cr_secure(u32 set_bits, u32 clear_bits)
+void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
+ u32 cpu_variant, u32 cpu_rev)
{
- u32 acr;
-
- /* Read ACR */
- asm volatile (mrc p15, 0, %0, c1, c0, 1 : =r (acr));
- acr = ~clear_bits;
- acr |= set_bits;
-
if (get_device_type() == GP_DEVICE) {
omap_smc1(OMAP3_GP_ROMCODE_API_WRITE_ACR, acr);
} else {
@@ -428,16 +418,15 @@ static void omap3_update_aux_cr_secure(u32 set_bits, u32
clear_bits)
}
}
-static void omap3_setup_aux_cr(void)
+static void omap3_update_aux_cr_secure(u32 set_bits, u32 clear_bits)
{
- /* Workaround for Cortex-A8 errata: #454179 #430973
-* Set IBE bit
-* Set Disable Branch Size Mispredicts bit
-* Workaround for erratum #621766
-* Enable L1NEON bit
-* ACR |= (IBE | DBSM | L1NEON) = ACR |= 0xE0
-*/
- omap3_update_aux_cr_secure(0xE0, 0);
+ u32 acr;
+
+ /* Read ACR */
+ asm volatile (mrc p15, 0, %0, c1, c0, 1 : =r (acr));
+ acr = ~clear_bits;
+ acr |= set_bits;
+ v7_arch_cp15_set_acr(acr, 0, 0, 0, 0);
}
#ifndef CONFIG_SYS_L2CACHE_OFF
diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h
index a4128773ddb2..39e121d9bc99 100644
--- a/include/configs/am3517_crane.h
+++ b/include/configs/am3517_crane.h
@@ -19,6 +19,10 @@
#define CONFIG_OMAP1 /* in a TI OMAP core */
#define CONFIG_OMAP3_AM3517CRANE 1 /* working with CRANEBOARD */
#define CONFIG_OMAP_COMMON
+/* Common ARM Erratas */
+#define CONFIG_ARM_ERRATA_454179
+#define CONFIG_ARM_ERRATA_430973
+#define CONFIG_ARM_ERRATA_621766
#define CONFIG_EMIF4 /* The chip has EMIF4 controller */
diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
index 94398c625eb0..930d7af31f18 100644
--- a/include/configs/am3517_evm.h
+++ b/include/configs/am3517_evm.h
@@ -19,6 +19,10 @@
#define CONFIG_OMAP1 /* in a TI OMAP core */
#define CONFIG_OMAP3_AM3517EVM 1 /* working with AM3517EVM */
#define CONFIG_OMAP_COMMON
+/* Common ARM Erratas */
+#define CONFIG_ARM_ERRATA_454179
+#define CONFIG_ARM_ERRATA_430973
+#define CONFIG_ARM_ERRATA_621766
#define CONFIG_EMIF4 /* The chip has EMIF4 controller */
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index 56a5506f5c78..451cb5e2fb4f 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -26,6 +26,10 @@
#define CONFIG_CM_T3X /* working with CM-T35 and CM-T3730 */
#define CONFIG_OMAP_COMMON
#define CONFIG_SYS_GENERIC_BOARD
+/* Common ARM Erratas */
+#define CONFIG_ARM_ERRATA_454179
+#define CONFIG_ARM_ERRATA_430973
+#define CONFIG_ARM_ERRATA_621766
#define CONFIG_SDRC/* The chip has SDRC controller */
diff --git a/include/configs/cm_t3517.h b/include/configs/cm_t3517.h
index ee1b7a0cb5a7..8c6313832250 100644
--- a/include/configs/cm_t3517.h
+++ b/include/configs/cm_t3517.h
@@ -17,6 +17,10 @@
#define
[U-Boot] [PATCH V3 06/11] ARM: OMAP3: Rename omap3.h to omap.h to be generic as all SoCs
This is in preperation of using generic cross OMAP code.
Signed-off-by: Nishanth Menon n...@ti.com
---
.../arm/include/asm/arch-omap3/{omap3.h = omap.h} |0
include/configs/am3517_crane.h |2 +-
include/configs/am3517_evm.h |2 +-
include/configs/cm_t35.h |2 +-
include/configs/cm_t3517.h |2 +-
include/configs/dig297.h |2 +-
include/configs/mcx.h |2 +-
include/configs/nokia_rx51.h |2 +-
include/configs/omap3_evm.h|2 +-
include/configs/omap3_evm_quick_mmc.h |2 +-
include/configs/omap3_evm_quick_nand.h |2 +-
include/configs/omap3_logic.h |2 +-
include/configs/omap3_mvblx.h |2 +-
include/configs/omap3_pandora.h|2 +-
include/configs/omap3_sdp3430.h|2 +-
include/configs/omap3_zoom1.h |2 +-
include/configs/tam3517-common.h |2 +-
include/configs/tao3530.h |2 +-
include/configs/ti_omap3_common.h |2 +-
include/configs/tricorder.h|2 +-
20 files changed, 19 insertions(+), 19 deletions(-)
rename arch/arm/include/asm/arch-omap3/{omap3.h = omap.h} (100%)
diff --git a/arch/arm/include/asm/arch-omap3/omap3.h
b/arch/arm/include/asm/arch-omap3/omap.h
similarity index 100%
rename from arch/arm/include/asm/arch-omap3/omap3.h
rename to arch/arm/include/asm/arch-omap3/omap.h
diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h
index 09ee10c0590b..a4128773ddb2 100644
--- a/include/configs/am3517_crane.h
+++ b/include/configs/am3517_crane.h
@@ -23,7 +23,7 @@
#define CONFIG_EMIF4 /* The chip has EMIF4 controller */
#include asm/arch/cpu.h /* get chip and board defs */
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
/*
* Display CPU and Board information
diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
index 190ef0e71bfb..94398c625eb0 100644
--- a/include/configs/am3517_evm.h
+++ b/include/configs/am3517_evm.h
@@ -23,7 +23,7 @@
#define CONFIG_EMIF4 /* The chip has EMIF4 controller */
#include asm/arch/cpu.h /* get chip and board defs */
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
/*
* Display CPU and Board information
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index 9767512a5cf0..56a5506f5c78 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -30,7 +30,7 @@
#define CONFIG_SDRC/* The chip has SDRC controller */
#include asm/arch/cpu.h /* get chip and board defs */
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
/*
* Display CPU and Board information
diff --git a/include/configs/cm_t3517.h b/include/configs/cm_t3517.h
index 918032bd753a..ee1b7a0cb5a7 100644
--- a/include/configs/cm_t3517.h
+++ b/include/configs/cm_t3517.h
@@ -30,7 +30,7 @@
#define CONFIG_EMIF4 /* The chip has EMIF4 controller */
#include asm/arch/cpu.h /* get chip and board defs */
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
/*
* Display CPU and Board information
diff --git a/include/configs/dig297.h b/include/configs/dig297.h
index c8739ed29490..8791199fc61d 100644
--- a/include/configs/dig297.h
+++ b/include/configs/dig297.h
@@ -36,7 +36,7 @@
#define CONFIG_SDRC/* The chip has SDRC controller */
#include asm/arch/cpu.h /* get chip and board defs */
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
/*
* Display CPU and Board information
diff --git a/include/configs/mcx.h b/include/configs/mcx.h
index 26eb2203540f..2cf66c40d6fe 100644
--- a/include/configs/mcx.h
+++ b/include/configs/mcx.h
@@ -26,7 +26,7 @@
#define CONFIG_EMIF4 /* The chip has EMIF4 controller */
#include asm/arch/cpu.h /* get chip and board defs */
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
#define CONFIG_OF_LIBFDT
#define CONFIG_FIT
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index 46fc91e5e197..442e16ae686b 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -42,7 +42,7 @@
#define CONFIG_SDRC/* The chip has SDRC controller */
#include asm/arch/cpu.h /* get chip and board defs */
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
#include asm/arch/mem.h
#include linux/stringify.h
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index 8bdc08f5864c..4e587e10ffd3 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -18,7 +18,7 @@
#define __OMAP3EVM_CONFIG_H
#include asm/arch/cpu.h
-#include asm/arch/omap3.h
+#include asm/arch/omap.h
/*
[U-Boot] [PATCH V3 02/11] ARM: Introduce erratum workaround for 454179
454179: Stale prediction may inhibit target address misprediction on
next predicted taken branch
Impacts: Every Cortex-A8 processors with revision lower than r2p1
Work around: Set IBE and disable branch size mispredict to 1
Also provide a hook for SoC specific handling to take place if needed.
Based on ARM errata Document revision 20.0 (13 Nov 2010)
Signed-off-by: Nishanth Menon n...@ti.com
---
README |1 +
arch/arm/cpu/armv7/cp15.c|6 ++
arch/arm/cpu/armv7/start.S | 11 +++
arch/arm/include/asm/armv7.h |2 ++
4 files changed, 20 insertions(+)
diff --git a/README b/README
index 11ec37ba4a00..e538cf061286 100644
--- a/README
+++ b/README
@@ -624,6 +624,7 @@ The following options need to be configured:
NOTE: The following can be machine specific errata. These
do have ability to provide rudimentary version and machine
specific checks, but expect no product checks.
+ CONFIG_ARM_ERRATA_454179
CONFIG_ARM_ERRATA_798870
- Driver Model
diff --git a/arch/arm/cpu/armv7/cp15.c b/arch/arm/cpu/armv7/cp15.c
index 8ac81c9ba147..b44c9f94a822 100644
--- a/arch/arm/cpu/armv7/cp15.c
+++ b/arch/arm/cpu/armv7/cp15.c
@@ -21,3 +21,9 @@ void __weak v7_arch_cp15_set_l2aux_ctrl(u32 l2actlr, u32
cpu_midr,
{
asm volatile (mcr p15, 1, %0, c15, c0, 0\n\t : : r(l2actlr));
}
+
+void __weak v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
+u32 cpu_variant, u32 cpu_rev)
+{
+ asm volatile (mcr p15, 0, %0, c1, c0, 1\n\t : : r(acr));
+}
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index ec46cec9cb1c..1f20e12b92f9 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -183,6 +183,17 @@ ENTRY(cpu_init_cp15)
skip_errata_798870:
#endif
+#ifdef CONFIG_ARM_ERRATA_454179
+ cmp r2, #0x21 @ Only on r2p1
+ blt skip_errata_454179
+
+ mrc p15, 0, r0, c1, c0, 1 @ Read ACR
+ orr r0, r0, #(0x3 6) @ Set DBSM(BIT7) and IBE(BIT6) bits
+ b v7_arch_cp15_set_acr
+
+skip_errata_454179:
+#endif
+
mov pc, lr @ back to my caller
ENDPROC(cpu_init_cp15)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index 30e0cc3cf3d5..434b34de0ce9 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -96,6 +96,8 @@ extern char __secure_end[];
void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32 cpu_midr,
u32 cpu_rev_comb, u32 cpu_variant,
u32 cpu_rev);
+void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
+ u32 cpu_variant, u32 cpu_rev);
#endif /* ! __ASSEMBLY__ */
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 0/11] ARM: OMAP3-DRA7: CP15 erratum workarounds and improvements
Hi,
The third incarnation of this series to address various ideas of
previous V2 series. I will skip the full blurb and point to V1/V2
links for the usual blurb.
Changes since V2:
- Added documentation revisioning info with ARM erratums
- patch series are split up to address ARM erratums first followed by TI
OMAP conversion
- More OMAP3 now get erratum implementation - had to redo rx51 a little
- I think is better helps exynos:
https://patchwork.ozlabs.org/patch/443271/
https://patchwork.ozlabs.org/patch/441863/
- Rearranged the series to address generic ARM first followed by rest.
V2: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/213060
V1: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/212174
Nishanth Menon (10):
ARM: Introduce erratum workaround for 798870
ARM: Introduce erratum workaround for 454179
ARM: Introduce erratum workaround for 430973
ARM: Introduce erratum workaround for 621766
ARM: OMAP: Change set_pl310_ctrl_reg to be generic
ARM: OMAP3: Rename omap3.h to omap.h to be generic as all SoCs
ARM: OMAP3: Get rid of omap3_gp_romcode_call and replace with
omap_smc1
ARM: OMAP5 / DRA7: Setup L2 Aux Control Register with recommended
configuration
ARM: OMAP3: Enable workaround for ARM errata 454179, 430973, 621766
ARM: OMAP3: rx51: Enable workaround for ARM errata 454179, 430973,
621766
Praveen Rao (1):
ARM: DRA7 / OMAP5: Add workaround for ARM errata 798870
README |8 +++
arch/arm/cpu/armv7/Makefile|2 +-
arch/arm/cpu/armv7/cp15.c | 29 ++
arch/arm/cpu/armv7/omap-common/Makefile|2 +-
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 15 +++--
arch/arm/cpu/armv7/omap3/board.c | 60 +++-
arch/arm/cpu/armv7/omap3/lowlevel_init.S | 11
arch/arm/cpu/armv7/omap4/hwinit.c |4 +-
arch/arm/cpu/armv7/omap5/hwinit.c | 23
arch/arm/cpu/armv7/start.S | 53 +
.../arm/include/asm/arch-omap3/{omap3.h = omap.h} |0
arch/arm/include/asm/arch-omap3/sys_proto.h|3 +-
arch/arm/include/asm/arch-omap4/sys_proto.h|5 +-
arch/arm/include/asm/arch-omap5/sys_proto.h|4 ++
arch/arm/include/asm/armv7.h |5 ++
board/nokia/rx51/rx51.c| 19 ---
include/configs/am3517_crane.h |6 +-
include/configs/am3517_evm.h |6 +-
include/configs/cm_t35.h |6 +-
include/configs/cm_t3517.h |6 +-
include/configs/dig297.h |6 +-
include/configs/mcx.h |6 +-
include/configs/nokia_rx51.h |6 +-
include/configs/omap3_evm.h|2 +-
include/configs/omap3_evm_common.h |4 ++
include/configs/omap3_evm_quick_mmc.h |2 +-
include/configs/omap3_evm_quick_nand.h |2 +-
include/configs/omap3_logic.h |6 +-
include/configs/omap3_mvblx.h |6 +-
include/configs/omap3_pandora.h|6 +-
include/configs/omap3_sdp3430.h|6 +-
include/configs/omap3_zoom1.h |2 +-
include/configs/tam3517-common.h |6 +-
include/configs/tao3530.h |6 +-
include/configs/ti_omap3_common.h |7 ++-
include/configs/ti_omap5_common.h |3 +
include/configs/tricorder.h|6 +-
37 files changed, 262 insertions(+), 87 deletions(-)
create mode 100644 arch/arm/cpu/armv7/cp15.c
rename arch/arm/include/asm/arch-omap3/{omap3.h = omap.h} (100%)
Regards,
Nishanth Menon
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 03/11] ARM: Introduce erratum workaround for 430973
430973: Stale prediction on replaced inter working branch causes Cortex-A8 to execute in the wrong ARM/Thumb state Impacts: Every Cortex-A8 processors with revision lower than r2p1 Work around: Set IBE to 1 Based on ARM errata Document revision 20.0 (13 Nov 2010) Signed-off-by: Nishanth Menon n...@ti.com --- README |1 + arch/arm/cpu/armv7/start.S | 11 +++ 2 files changed, 12 insertions(+) diff --git a/README b/README index e538cf061286..484ae9ee39a8 100644 --- a/README +++ b/README @@ -624,6 +624,7 @@ The following options need to be configured: NOTE: The following can be machine specific errata. These do have ability to provide rudimentary version and machine specific checks, but expect no product checks. + CONFIG_ARM_ERRATA_430973 CONFIG_ARM_ERRATA_454179 CONFIG_ARM_ERRATA_798870 diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 1f20e12b92f9..45e8578db60c 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -194,6 +194,17 @@ skip_errata_798870: skip_errata_454179: #endif +#ifdef CONFIG_ARM_ERRATA_430973 + cmp r2, #0x21 @ Only on r2p1 + blt skip_errata_430973 + + mrc p15, 0, r0, c1, c0, 1 @ Read ACR + orr r0, r0, #(0x1 6) @ Set IBE bit + b v7_arch_cp15_set_acr + +skip_errata_430973: +#endif + mov pc, lr @ back to my caller ENDPROC(cpu_init_cp15) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 04/11] ARM: Introduce erratum workaround for 621766
621766: Under a specific set of conditions, executing a sequence of NEON or vfp load instructions can cause processor deadlock Impacts: Every Cortex-A8 processors with revision lower than r2p1 Work around: Set L1NEON to 1 Based on ARM errata Document revision 20.0 (13 Nov 2010) Signed-off-by: Nishanth Menon n...@ti.com --- README |1 + arch/arm/cpu/armv7/start.S | 11 +++ 2 files changed, 12 insertions(+) diff --git a/README b/README index 484ae9ee39a8..5ee789aea627 100644 --- a/README +++ b/README @@ -626,6 +626,7 @@ The following options need to be configured: specific checks, but expect no product checks. CONFIG_ARM_ERRATA_430973 CONFIG_ARM_ERRATA_454179 + CONFIG_ARM_ERRATA_621766 CONFIG_ARM_ERRATA_798870 - Driver Model diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 45e8578db60c..2d92276a0475 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -205,6 +205,17 @@ skip_errata_454179: skip_errata_430973: #endif +#ifdef CONFIG_ARM_ERRATA_621766 + cmp r2, #0x21 @ Only on r2p1 + blt skip_errata_621766 + + mrc p15, 0, r0, c1, c0, 1 @ Read ACR + orr r0, r0, #(0x1 5) @ Set L1NEON bit + b v7_arch_cp15_set_acr + +skip_errata_621766: +#endif + mov pc, lr @ back to my caller ENDPROC(cpu_init_cp15) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 03/10] Exynos542x: Add workaround for ARM errata 798870
On 02/25/2015 01:55 PM, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
On 13:27-20150220, Akshay Saraswat wrote:
This patch adds workaround for ARM errata 798870 which says
If back-to-back speculative cache line fills (fill A and fill B) are
issued from the L1 data cache of a CPU to the L2 cache, the second
request (fill B) is then cancelled, and the second request would have
detected a hazard against a recent write or eviction (write B) to the
same cache line as fill B then the L2 logic might deadlock.
Signed-off-by: Kimoon Kim kimoon@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
Changes since v3:
- Added errata number in comment.
- Moved changes to arm generic armv7.h
Changes since v2:
- No change.
Changes since v1:
- Added Reviewed-by Tested-by.
- Added space before */ on line # 40.
arch/arm/include/asm/armv7.h | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index a13da23..a2040b7 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -69,6 +69,22 @@
#define CP15DSBasm volatile (mcr p15, 0, %0, c7, c10, 4 : : r
(0))
#define CP15DMBasm volatile (mcr p15, 0, %0, c7, c10, 5 : : r
(0))
+/*
+ * Workaround for ARM errata # 798870
+ * Set L2ACTLR[7] to reissue any memory transaction in the L2 that has been
+ * stalled for 1024 cycles to verify that its hazard condition still
exists.
+ */
+static inline void v7_enable_l2_hazard_detect(void)
+{
+ uint32_t val;
+
+ /* L2ACTLR[7]: Enable hazard detect timeout */
+ asm volatile (mrc p15, 1, %0, c15, c0, 0\n\t : =r(val));
+ val |= (1 7);
+ asm volatile (mcr p15, 1, %0, c15, c0, 0\n\t : : r(val));
This wont work for us in DRA7/OMAP5 L2ACTLR cannot be modified by
u-boot. has to go to secure world using smc call.
I believe the same may be true even on some exynos5 platforms with
secure firmware (e.g. exynos5422-odroid-xu3).
I hope http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/213207
should probably help handle for secure and non-secure devices by some
soc specific glue layer (something similar to omap3 perhaps).. I am
not too familiar with exynos family to comment better.
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: move -march=* and -mtune= options to arch/arm/Makefile
Hello Masahiro, On Tue, 10 Feb 2015 19:52:56 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: My main motivation for this commit: [1] Follow the arch/arm/Makefile style of Linux Kernel [2] Maintain compiler options systematically Currently, we give -march=* and -mtune=* options inconsistently: Only some of the CPUs pass -march=* and -mtune=* options. By collecting flags into the arch/arm/Makefile, we can tell which options are missing at a glance. [3] Prepare for deprecating arch/*/cpu/*/config.mk Note: This commit just moves the compiler options so as not to change the behavior at all. It does not care the correctness of the given options. Fox example, -march=armv5te might be better than -march=armv4 for ARM946EJS, but it is beyond the scope this commit. Also, filling the missing -march=* and -tune=* is left to follow-up patches. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- I'm fine with the patch's goal and principle, but it does not seem to apply properly to u-boot-arm/master. Can you have a look? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 8/9] configs: ti_omap3_common: Enable workaround for ARM errata 454179, 430973, 621766
Le mercredi 25 février 2015 à 08:32 -0600, menon.nisha...@gmail.com a
écrit :
On Wed, Feb 25, 2015 at 6:27 AM, Paul Kocialkowski cont...@paulk.fr wrote:
Le mercredi 25 février 2015 à 13:31 +0200, Igor Grinberg a écrit :
On 02/25/15 13:19, Paul Kocialkowski wrote:
Le mardi 24 février 2015 à 16:57 -0600, Nishanth Menon a écrit :
Enable the OMAP3 specific errata code for 454179, 430973, 621766
and while at it, remove legacy non-revision checked errata logic.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap3/board.c | 16
include/configs/ti_omap3_common.h |6 ++
2 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/board.c
b/arch/arm/cpu/armv7/omap3/board.c
index 7ce30949a6c6..cc3a43341335 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -35,7 +35,6 @@ DECLARE_GLOBAL_DATA_PTR;
/* Declarations */
extern omap3_sysinfo sysinfo;
-static void omap3_setup_aux_cr(void);
#ifndef CONFIG_SYS_L2CACHE_OFF
static void omap3_invalidate_l2_cache_secure(void);
#endif
@@ -246,9 +245,6 @@ void s_init(void)
try_unlock_memory();
- /* Errata workarounds */
- omap3_setup_aux_cr();
-
#ifndef CONFIG_SYS_L2CACHE_OFF
/* Invalidate L2-cache from secure mode */
omap3_invalidate_l2_cache_secure();
@@ -428,18 +424,6 @@ void omap3_update_aux_cr_secure(u32 set_bits, u32
clear_bits)
}
}
-static void omap3_setup_aux_cr(void)
-{
- /* Workaround for Cortex-A8 errata: #454179 #430973
- * Set IBE bit
- * Set Disable Branch Size Mispredicts bit
- * Workaround for erratum #621766
- * Enable L1NEON bit
- * ACR |= (IBE | DBSM | L1NEON) = ACR |= 0xE0
- */
- omap3_update_aux_cr_secure(0xE0, 0);
-}
-
#ifndef CONFIG_SYS_L2CACHE_OFF
static void omap3_update_aux_cr(u32 set_bits, u32 clear_bits)
{
diff --git a/include/configs/ti_omap3_common.h
b/include/configs/ti_omap3_common.h
index f909f6b94a18..db15c12ddf53 100644
--- a/include/configs/ti_omap3_common.h
+++ b/include/configs/ti_omap3_common.h
Only a couple of OMAP3 boards in U-Boot include ti_omap3_common.h. You
can find a complete list of all the configs that need those options
enabled from my first patch on that topic:
http://lists.denx.de/pipermail/u-boot/2015-February/205809.html
I guess it's better to enable those on all the currently-supported omap3
platforms: that's the way it was so far and it won't hurt in cases it's
not needed thanks to the revision detection.
Or...
I think this patch might be a good enough argument to request people
switch to include ti_omap3_common.h instead of duplicating it in
private configs...
Don't you think?
The way I see it, ti_omap3_common.h is common for OMAP3 boards made by
TI. A few things there are not generic to omap3 in general (e.g. not
every board uses the U-Boot SPL, or UART3 for console).
However, I agree it would be beneficial to have an omap3_common.h config
with the options that are expected to be shared accross every possible
omap3 device (and with a few clever ifdef so that the minimum has to be
set in the including board configs).
I could try to come up with such a config if you wish, but I'm afraid
I'm not the most qualified person to do this (I only have a single omap3
device).
I am planning on a V3 based on trying to converge exynos and TI
platforms into a common code base. I will stick with ti_*_common.h
headers for now, we will keep all the other headers updated for the
moment. I do stand with the opinion that we should all be using the
same ti_omap3_common header for all platforms using the same SoC...
but that could be done as follow on patches.
That said, Paul, if you could contribute patches to the effect of
integrating all these platforms to ti_*_common.h, that'd be great.
I will try to come up with a common configuration for omap3 (and
possibly omap4 and omap5 too). Do you mind if I drop the ti_ prefix? I
don't feel it's relevant to mention the chip manufacturer there,
especially when it's not used anywhere else in the tree (except for the
boards that are actually procuced by TI such as the evms, etc).
signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 01/24] fsl-ch3/lowlevel: TZPC and TZASC programming to configure non-secure accesses
On 01/06/2015 01:11 PM, York Sun wrote: From: Bhupesh Sharma bhupesh.sha...@freescale.com This patch ensures that the TZPC (BP147) and TZASC-400 programming happens for LS2085A SoC only when the desired config flags are enabled and ensures that the TZPC programming is done to allow Non-secure (NS) + secure (S) transactions only for DCGF registers. The TZASC component is not present on LS2085A-Rev1, so the TZASC-400 config flag is turned OFF for now. Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com --- This set is applied to u-boot-fsl-qoriq master branch. Awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
I applied the patch, but it still hangs. The directory tree is different for mx5x vs. MX35 I added relocate.S to...arch/arm/cpu/armv7/mx5/relocate.S and modified Makefile here...arch/arm/cpu/armv7/mx5/Makefile Does that seem right? -- View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-stuck-after-relocation-attempt-on-MX51-board-tp206738p206846.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm/ls102xa: create TLB to map PCIe region
On 01/21/2015 01:29 AM, Minghuan Lian wrote: LS1021A's PCIe1 region begins 0x40_; PCIe2 begins 0x48_. In order to access PCIe device, we must create TLB to map the 40bit physical address to 32bit virtual address. This patch will enable MMU after DDR is available and creates MMU table in DRAM to map all 4G space; then, re-use the reserved space to map PCIe region. The following the mapping layout. VA mapping: --- 0GB | | | | |---| 0x2400 |///| === 192MB VA map for PCIe1 with offset 0x40__ |---| 0x3 | | |---| 0x3400 |///| === 192MB VA map for PCIe2 with offset 0x48__ |---| 0x4000 | | |---| 0x8000 DDR0 space start |\\\| |\\\| === 2GB VA map for 2GB DDR0 Memory space |\\\| --- 4GB DDR0 space end Signed-off-by: Minghuan Lian minghuan.l...@freescale.com --- Applied to u-boot-fsl-qoriq master branch, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: fsl_esdhc: Add support for DDR mode
On 01/20/2015 07:16 AM, Volodymyr Riazantsev wrote: Add support of the DDR mode for eSDHC driver. Enable it for i.MX6 SoC family only. Change-Id: Ie27a945c9fe79d044cc886e269b60747f1744116 Signed-off-by: Volodymyr Riazantsev volodymyr.riazant...@globallogic.com --- Applied to u-boot-fsl-qoriq master branch, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v6] crypto/fsl - Add progressive hashing support using hardware acceleration.
On 02/23/2015 10:06 AM, Simon Glass wrote: On 20 February 2015 at 00:21, Gaurav Rana gaurav.r...@freescale.com wrote: Currently only normal hashing is supported using hardware acceleration. Added support for progressive hashing using hardware. Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com Signed-off-by: Gaurav Rana gaurav.r...@freescale.com CC: Simon Glass s...@chromium.org --- Changes in v6: Modify description for CONFIG_SHA256, CONFIG_SHA256, CONFIG_SHA_PROG_HW_ACCEL, CONFIG_SHA_HW_ACCEL in README and Kconfig. Reviewed-by: Simon Glass s...@chromium.org Applied to u-boot-fsl-qoriq master branch, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/1] fastboot: Update getvar command to get 'userdata' partition size
Hi Rob,
On 20 February 2015 at 20:24, Rob Herring rob.herr...@linaro.org wrote:
On Wed, Feb 18, 2015 at 1:52 PM, Dileep Katta dileep.ka...@linaro.org
wrote:
This patch adds functionality to getvar command to get the userdata
partition
size.
This is non-standard and doesn't scale to other partitions. There is
Is there a way to add support for retrieving some non-standard variables,
such as cpu_type or
board specific information in getvar or other command(oem!) in fastboot?
already a standard var partition-size:part name. There is also
partition-type:part name which probably needs to be supported as
well. It would probably be good to have generic code to retrieve
fastboot variables from a u-boot environment variables. Something like
this:
fastboot: allow retrieving fastboot variables from env
Signed-off-by: Rob Herring r...@kernel.org
Thanks for the suggestion.
Is it fine to extend fb_mmc_get_ptn_size() in this patch to to support standard
var partition-size:part name
and similar functionality for partition-type?
or using mtdparts environment variable to get partition-type or
partition-size is preferable? Please advise.
Regards, Dileep
diff --git a/drivers/usb/gadget/f_fastboot.c
b/drivers/usb/gadget/f_fastboot.c
index 310175a..31e1063 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -364,8 +364,15 @@ static void cb_getvar(struct usb_ep *ep, struct
usb_request *req)
else
strcpy(response, FAILValue not set);
} else {
- error(unknown variable: %s\n, cmd);
- strcpy(response, FAILVariable not implemented);
+ char envstr[32];
+ snprintf(envstr, sizeof(envstr) - 1, fastboot.%s, cmd);
+ s = getenv(envstr);
+ if (s) {
+ strncat(response, s, chars_left);
+ } else {
+ error(unknown variable: %s\n, cmd);
+ strcpy(response, FAILVariable not implemented);
+ }
}
fastboot_tx_write_str(response);
}
Rob
Signed-off-by: Dileep Katta dileep.ka...@linaro.org
---
common/fb_mmc.c | 38
++
drivers/usb/gadget/f_fastboot.c | 2 ++
include/fb_mmc.h| 2 ++
3 files changed, 42 insertions(+)
diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index 6ea3938..1bb6335 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -32,6 +32,44 @@ void fastboot_okay(const char *s)
strncat(response_str, s, RESPONSE_LEN - 4 - 1);
}
+void fb_mmc_get_ptn_size(const char *cmd, char *response)
+{
+ int ret;
+ block_dev_desc_t *dev_desc;
+ disk_partition_t info;
+ u32 sz_mb;
+ u64 sz = 0;
+ char buf[RESPONSE_LEN];
+
+ /* initialize the response buffer */
+ response_str = response;
+
+ dev_desc = get_dev(mmc, CONFIG_FASTBOOT_FLASH_MMC_DEV);
+ if (!dev_desc || dev_desc-type == DEV_TYPE_UNKNOWN) {
+ error(invalid mmc device);
+ fastboot_fail(invalid mmc device);
+ return;
+ }
+
+ ret = get_partition_info_efi_by_name(dev_desc, cmd, info);
+ if (ret) {
+ error(cannot find partition: '%s', cmd);
+ fastboot_fail(cannot find partition);
+ return;
+ }
+
+ sz = (info.size * (u64)info.blksz) 10;
+
+ if (sz = 0x) {
+ sz_mb = (u32)(sz 10);
+ sprintf(buf, 0x%d MB, sz_mb);
+ fastboot_okay(buf);
+ } else {
+ sprintf(buf, %d KB, (u32)sz);
+ fastboot_okay(buf);
+ }
+}
+
static void write_raw_image(block_dev_desc_t *dev_desc,
disk_partition_t *info,
const char *part_name, void *buffer,
unsigned int download_bytes)
diff --git a/drivers/usb/gadget/f_fastboot.c
b/drivers/usb/gadget/f_fastboot.c
index 310175a..17b64ef 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -363,6 +363,8 @@ static void cb_getvar(struct usb_ep *ep, struct
usb_request *req)
strncat(response, s, chars_left);
else
strcpy(response, FAILValue not set);
+ } else if (!strcmp_l1(userdata_size, cmd)) {
+ fb_mmc_get_ptn_size(userdata, response);
} else {
error(unknown variable: %s\n, cmd);
strcpy(response, FAILVariable not implemented);
diff --git a/include/fb_mmc.h b/include/fb_mmc.h
index 1ad1d13..353f325 100644
--- a/include/fb_mmc.h
+++ b/include/fb_mmc.h
@@ -4,5 +4,7 @@
* SPDX-License-Identifier:GPL-2.0+
*/
+void fb_mmc_get_ptn_size(const char *cmd, char *response);
+
void
[U-Boot] Please pull u-boot-fsl-qoriq master
Tom, The following changes since commit 38dac81b3d0e777f301ca98100bfbcab01d616c2: Merge branch 'master' of git://git.denx.de/u-boot-mmc (2015-02-23 16:18:06 -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 94e3c8c4fd7bfe395fa467973cd647551d6d98c7: crypto/fsl - Add progressive hashing support using hardware acceleration. (2015-02-25 13:20:02 -0800) Alison Wang (2): arm: ls102xa: Define default values for some CCSR macros arm: ls1021x: Add support for initializing CAAM's stream id Arnab Basu (2): ARMv8/fsl-lsch3: Patch cpu node properties in DT for online cores ARMv8/ls2085a: Switch to passing earlycon to kernel Bhupesh Sharma (3): fsl-ch3/lowlevel: TZPC and TZASC programming to configure non-secure accesses armv8/fsl-lsch3: Add fdt-fixup for clock frequency of the DUART nodes ls2085/configs: Ensure right banners are printed for EMU and SIMU J. German Rivera (1): drivers/mc: Migrated MC Flibs to 0.5.2 Kuldip Giroh (1): ARMv8/LS2085A: HugeTLB support is required by default in LS NADK Minghuan Lian (4): arm/ls102xa: create TLB to map PCIe region arm/ls102xa: use a array to define pexmscportsr arm/ls1021a: add PCIe settings driver/pci: add Layerscape PCIe driver Stuart Yoder (1): ARMv8/ls2085a: Move kernel image load address Volodymyr Riazantsev (1): mmc: fsl_esdhc: Add support for DDR mode York Sun (15): armv8/fsl-lsch3: Change normal memory shareability armv8/fsl-lsch3: Convert flushing L3 to assembly to avoid using stack armv8/ls2085a: Enable cluster timebase for all clusters driver/ddr/fsl: Adjust CAS to preamble override for emulator driver/ddr/fsl: Add workaround for A008336 driver/ddr/fsl: Add workround for erratumn A008514 armv8/fsl-lsch3: Add support for second DDR clock driver/ddr/fsl: Add support for multiple DDR clocks ARMv8/LS2085A: Enable auto precharge for DP-DDR driver/ddr/fsl: Fix a typo in timing_cfg_8 calculation ARMv8/LS2085A: Adjust system clock and DDR clock driver/ddr/fsl: Add sync of refresh armv8/fsl-lsch3: Enable workaround for A008336 armv8/fsl-lsch3: Enable erratum workround for A008514 armv8/ls2085a_emu: Enable sync of refresh chenhui zhao (1): arm: ls102xa: workaround for cache coherency problem gaurav rana (2): crypto/fsl: Make function names consistent for blob encapsulation/decapsulation. crypto/fsl - Add progressive hashing support using hardware acceleration. Kconfig|4 +- README | 23 +- arch/arm/cpu/armv7/ls102xa/cpu.c | 231 +- arch/arm/cpu/armv8/cache.S |6 + arch/arm/cpu/armv8/cache_v8.c | 18 +- arch/arm/cpu/armv8/fsl-lsch3/cpu.c | 62 +-- arch/arm/cpu/armv8/fsl-lsch3/fdt.c | 28 +- arch/arm/cpu/armv8/fsl-lsch3/lowlevel.S| 132 ++ arch/arm/cpu/armv8/fsl-lsch3/mp.c |8 + arch/arm/cpu/armv8/fsl-lsch3/mp.h |1 + arch/arm/cpu/armv8/fsl-lsch3/speed.c | 16 +- arch/arm/include/asm/arch-fsl-lsch3/config.h | 38 ++ arch/arm/include/asm/arch-fsl-lsch3/immap_lsch3.h |3 + arch/arm/include/asm/arch-ls102xa/config.h | 15 + arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 40 +- .../include/asm/arch-ls102xa/ls102xa_stream_id.h | 57 +++ arch/arm/include/asm/armv8/mmu.h |3 +- arch/arm/include/asm/global_data.h |3 + arch/arm/include/asm/system.h |1 + arch/arm/lib/bootm.c |2 +- board/freescale/common/ls102xa_stream_id.c | 15 + board/freescale/ls1021aqds/ls1021aqds.c| 21 + board/freescale/ls1021atwr/ls1021atwr.c| 21 + board/freescale/ls2085a/ddr.c |1 + board/freescale/ls2085a/ls2085a.c | 29 +- common/cmd_blob.c | 18 +- common/hash.c | 10 + doc/README.fsl-trustzone-components| 25 ++ drivers/crypto/fsl/fsl_blob.c |4 +- drivers/crypto/fsl/fsl_hash.c | 138 +- drivers/crypto/fsl/fsl_hash.h | 34 ++ drivers/ddr/fsl/arm_ddr_gen3.c |2 +- drivers/ddr/fsl/ctrl_regs.c| 216 + drivers/ddr/fsl/ddr1_dimm_params.c | 18 +- drivers/ddr/fsl/ddr2_dimm_params.c | 12 +- drivers/ddr/fsl/ddr3_dimm_params.c |8 +- drivers/ddr/fsl/ddr4_dimm_params.c |8
Re: [U-Boot] [PATCH] arm: ls102xa: Define default values for some CCSR macros
On 01/16/2015 01:23 AM, Alison Wang wrote: This patch is to define default values for some CCSR macros to make header files cleaner. Signed-off-by: Alison Wang alison.w...@freescale.com --- Applied to u-boot-fsl-qoriq master branch, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] arm/ls102xa: use a array to define pexmscportsr
On 01/21/2015 01:29 AM, Minghuan Lian wrote: Signed-off-by: Minghuan Lian minghuan.l...@freescale.com --- This set is applied to u-boot-fsl-qoriq master branch, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: ls1021x: Add support for initializing CAAM's stream id
On 01/16/2015 01:21 AM, Alison Wang wrote: There 4 JRs, 4 RTICs and 8 DECOs, and set them the same stream id for using the same SMMU3 on LS1021A. Signed-off-by: Xiubo Li li.xi...@freescale.com Signed-off-by: Alison Wang alison.w...@freescale.com --- Changes in v2: - Move changing CCSR macros to a separated patch. Applied to u-boot-fsl-qoriq master branch, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: ls102xa: workaround for cache coherency problem
On 01/22/2015 11:53 PM, Chenhui Zhao wrote: The RCPM FSM may not be reset after power-on, for example, in the cases of cold boot and wakeup from deep sleep. It causes cache coherency problem and may block deep sleep. Therefore, reset them if they are not be reset. Signed-off-by: Chenhui Zhao chenhui.z...@freescale.com --- Applied to u-boot-fsl-qoriq master branch, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v3] crypto/fsl: Make function names consistent for blob encapsulation/decapsulation.
On 02/24/2015 08:07 PM, Gaurav Rana wrote: This patch does the following: 1. The function names for encapsulation and decapsulation were inconsitent in freescale's implementation and cmd_blob file. This patch corrects the issues. 2. The function protopye is also modified to change the length parameter from u8 to u32 to allow encapsulation and decapsulation of larger images. 3. Modified the description of km paramter in the command usage for better readability. Signed-off-by: Gaurav Rana gaurav.r...@freescale.com Reviewed-by: Ruchika Gupta ruchika.gu...@freescale.com --- Changes in v3: Fixed blob_help_text[] array declaration. Changes in v2: Modify blob_help_text[] array common/cmd_blob.c | 18 ++ drivers/crypto/fsl/fsl_blob.c | 4 ++-- 2 files changed, 12 insertions(+), 10 deletions(-) Applied to u-boot-fsl-qoriq master branch, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address
Hi Suriyan, On Thu, Jan 22, 2015 at 5:46 PM, Suriyan Ramasami suriya...@gmail.com wrote: On Thu, Jan 22, 2015 at 9:51 AM, Kevin Hilman khil...@kernel.org wrote: Suriyan Ramasami suriya...@gmail.com writes: Hello Kevin, On Wed, Jan 21, 2015 at 4:54 PM, Kevin Hilman khil...@kernel.org wrote: Hi Surijan, Suriyan Ramasami suriya...@gmail.com writes: Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same. The layout of SD card is as follows: BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625. I took the binaries from your .zip file above and put them on the SD card for my odroid-xu3 at the offsets above. I'm using BL1 and TZSW from the u-boot-hardkernel release[1] and using u-boot-dtb.bin from my own mainline u-boot build which inclues the odroid-xu3 patches. If I leave the indicator block zero'd, everything works fine, and it boots my version of mainline u-boot without any problems. If I then write a non-zero value to the first byte of the indicator block and write your unsigned BL2 at the appropriate offset, it no longer boots. Is the unsigned BL2 supposed to boot u-boot at offset 65 when it's finished as well? The unsigned SPL from mainline used will be spl/u-boot-spl.bin (raw jump to offset 0 in that file will be pure code without headers) OK. Changes are needed in spl_boot.c to make it next load u-boot-dtb.bin. I shall try to list most of the changes here: 1.arch/arm/cpu/armv7/exynos/spl_boot.c: The Odroid-XU3's IROM function pointers does not have any code (AFAICT). I checked the locations that are listed in the array table and found all 0's there. We need to replace function copy_uboot_to_ram() with something similar from HK's file, so that it uses exynos_smc() calls to load the bits from SD card, or we could enable MMC code in SPL (haven't tried it) and use those functions instead. For quick results,I just forced an SD card read. 2. #define CONFIG_SEC_FW_SIZE (15 10) /* 15 KB */ somewhere, so that the start offset for U-Boot is calculated correctly. 3. for chain loading we define CONFIG_SPL_TEXT_BASE to be, say 0x63E0 so that when its executed the static global pointers are accessed correctly - static struct spl_machine_param machine_param in file smdk5420_spl.c. 4. mem_ctrl_init() hangs in while (val != FOUTBPLL); One workaround is to use HKs version of this function which again uses some smc calls. With all these changes, SPL chainloading works. Do you have a patch against mainline u-boot for all these changes? I'd be happy to test. Give me some time and I shall iron out my notes and get back to creating a patch for this against mainline U-Boot. Curious if you've had any time to prepare some patches against mainline u-boot. I'm very curious to try this on the odroid-xu3. Thanks, Kevin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
Hi Dave, On Wed, Feb 25, 2015 at 6:23 PM, DaveKucharczyk david.kucharc...@gmail.com wrote: I applied the patch, but it still hangs. The directory tree is different for mx5x vs. MX35 I added relocate.S to...arch/arm/cpu/armv7/mx5/relocate.S and modified Makefile here...arch/arm/cpu/armv7/mx5/Makefile Does that seem right? I have just tested top of tree U-boot and my mx53loco board boots fine. It seems your issue is a different one. You are using 2014.07, can you try it with 2015.01 instead? Also, you said that your 512MB board version works fine, but the 256MB fails. I suppose you are using two different binaries for each board, right? You can't have a single binary for the two boards, unless you use the SPL approach. Regards. Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: support Thumb-1 with CONFIG_SYS_THUMB_BUILD
Hello Albert, On Tue, 24 Feb 2015 14:53:36 +0100, Albert ARIBAUD albert.u.b...@aribaud.net wrote: When building a THumb-1-only target with CONFIG_SYS_THUMB_BUILD, some files fail to build, most of the time because they include mcr instructions, which only exist for Thumb-2. Thos patch introduces a Kconfig option CONFIG_THUMB2 and uses it to select between Thumb-2 and ARM mode for the aforementioned files. Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net --- This patch has been build-tested and run-tested on ED Mini V2, above the edmini: switch to SPL patch, and found to reduce U-Boot size by 25% and SPL size by 14%... and to run fine. :) This patch has also been tested against side effects on the non-Thumb wireless_space target. The binaries produced with and without ths patch were found to differ only by their version string. Changes in v2: - fixed a typo in the commit message - added file arch/arm/thumb1/include/asm/proc-armv/system.h, which overrides arch/arm/include/asm/proc-armv/system.h when building for Thumb-1 and provides non-functional but Thumb-compilable IRQ and FIQ related macros and functions. Ok, this does not fare as good as I have hoped, because there are also thumb1-unfrendly macros in arch/arm/include/asm/cache.h, this time with mcr and mrc instructions. /me hates macros used as inline functions. :( I cannot just replace the macros with empty inline functions as I did with arch/arm/include/asm/proc-armv/system.h, since this would cause cache to not work. :( This leaves only one solution: when buildding for thumb1, replace the macros in cache.h with plain function prototypes, and provide simple ARM-state implementations for these. We'll lose a bit of performance as instead of a single mcr or mrc instruction, we'll have a call switching from Thumb to ARM state, the mcr/mrc instruction, and a return to Thumb state. Hopefully that won't hurt performance too much. V3 in the works. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] rpi_2 builds fine with make, fails with buildman
Hello Stephen, On Tue, 24 Feb 2015 09:51:56 -0700, Stephen Warren swar...@wwwdotorg.org wrote: On 02/24/2015 01:48 AM, Albert ARIBAUD wrote: Hello, Can anyone confirm that on current u-boot/master, rpi_2 build fine with git clean -xfd; make rpi_2_defconfig; make but fails with tools/buildman/buildman rpi_2 with the following error: arm: + rpi_2 +make[3]: *** No rule to make target 'arch/arm/cpu/armv7/bcm2835/../../arm1176/bcm2835//init.o', needed by 'arch/arm/cpu/armv7/bcm2835/built-in.o'. Stop. +make[2]: *** [arch/arm/cpu/armv7/bcm2835] Error 2 +make[1]: *** [arch/arm/cpu/armv7] Error 2 +make: *** [sub-make] Error 2 My gut feeling is that the problem lies with the fact that arch/arm/cpu/armv7/bcm2835/ contains a Makefile which refers to init.o, reset.o, timer.o and mbox.o but the source code for these resides in another directory, arch/arm/cpu/arm1176/bcm2835/. CC:ing Stephen as directory arch/arm/cpu/armv7/bcm2835/ was introduced by his commit db75356f (committed by Tom, also cc:) and Simon, since the issue is related to buildman. This problem exists with quite a few boards, including the rpi port before the addition of rpi_2 support. It's a bit intermittent which may be why you didn't notice before. See the following, and replies: http://lists.denx.de/pipermail/u-boot/2015-February/205255.html Thanks. Indeed it hadn't bitten me so far. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041
[Reposting comment on v4 as York requested]
On Wed, Feb 25, 2015 at 02:17:56PM +0530, Aneesh Bansal wrote:
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 4cf8853..ef56cc0 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -843,6 +843,23 @@ int cpu_init_r(void)
setup_mp();
#endif
+#if defined(CONFIG_SYS_RAMBOOT) defined(CONFIG_SYS_INIT_L3_ADDR) \
+ defined(CONFIG_SECURE_BOOT)
+ /* Disable the TLB Created for L3 and create the TLB required for
+ * PCIE (CONFIG_SYS_PCIE1_MEM_VIRT) which was not created earlier.
+ */
+ int tlb_index;
+ tlb_index = find_tlb_idx((void *)CONFIG_BPTR_VIRT_ADDR, 1);
+ if (tlb_index != -1) {
+ disable_tlb(tlb_index);
+
+ set_tlb(1, CONFIG_SYS_PCIE1_MEM_VIRT,
+ CONFIG_SYS_PCIE1_MEM_PHYS,
+ MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, tlb_index, BOOKE_PAGESZ_1G, 1);
+ }
+#endif
Why are you assuming in generic 85xx code that the TLB for PCIE1 needs
to be created? e500mc should have enough TLB1 entries that you don't
need to share (or if it's due to address conflicts, a board may have PCI
at a different address), and PCI may not exist at all on some boards.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot tftp problem
Hello, Joe Can you provide more exact details on the servers you are trying including versions? Perhaps also provide pcap files (not text dumps) so the exact packet contents can be observed? Recently I've done some tests, hope you find them interesting. Server in question: Linux sterver 3.2.0-4-686-pae #1 SMP Debian 3.2.65-1+deb7u1 i686 GNU/Linux r8169 :08:04.0: eth1: RTL8169sc/8110sc at 0xf827e000, 90:e6:ba:07:3e:a5, XID 1800 IRQ 19 ii tftpd 0.17-18 i386 Trivial file transfer protocol server I have mirrored 2 ports at the switch. Here's what I have found: 1. tftp block ack packets have some extra bytes. They are mage octet tim. Suppose that's because buffer reuse in u-boot after uImage octet timeout 5, although I'm not so sure. 2. u-boot never generates wrong block acks if #define TIMEOUT 8000UL. Obviously 8 seconds is enough for tftp server to resend the block, so with this define, it is not timing out and keeps downloading till the end. Ofcourse it just masks the real problem, nothing more. 3. at the times of server resending block it is u-boot who lost the packet. I believe that if the packet was delivered to mirrored port, it must have been delivered to u-boot. But logging at u-boot shows no evidence of packet reception, however packets following missed one are registered. 4. the only condition at which u-boot didn't loose packets and downloaded uImage without timeouts was when I made it log everything regarding network. this gave enormous output to console, but no tftp packets lost. Even though I tested it twice it could be a coincidence. Also I tried disabling caches. Rebuilding with CONFIG_SYS_ICACHE_OFF and CONFIG_SYS_DCACHE_OFF was no difference at all. At least for tftp download. I was about to provide you with pcap files from mirror port and corresponding u-boot console log, but sadly seems that I have deleted u-boot log by mistake :( I think I have to repeat the whole thing before I can provide you with them both. Best regards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
Fabio Estevam-2 wrote Also, you said that your 512MB board version works fine, but the 256MB fails. I suppose you are using two different binaries for each board, right? You can't have a single binary for the two boards, unless you use the SPL approach. Fabio, we use one binary. It has runtime memory discovery via gpio's (resistor reads). DRAM size is reported correctly from both boards. It just hangs on the 256MB board. We do not have SPL setup. -- View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-stuck-after-relocation-attempt-on-MX51-board-tp206738p206862.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] Boot from the bootable paritions
In the discussion after the submission of the Let the distro boot command scan all partitions patchset it became clear the general consensus was that u-boot should not simply scan all partitions but instead only partitions with the bootable flag set, falling back to parition 1 as was previously done. This set of patches implements that Changes since v1: * Make updated part list command more precise about what arguments ordering it accepts. Sjoerd Simons (3): part: Add support for list filtering on bootable partitions config_cmd_default.h: Add 'env exists' command config_distro_bootcmd.h: Prefer booting from bootable paritions common/cmd_part.c | 53 +++-- include/config_cmd_default.h| 1 + include/config_distro_bootcmd.h | 3 ++- 3 files changed, 44 insertions(+), 13 deletions(-) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] part: Add support for list filtering on bootable partitions
Add an optional -bootable parameter to the part list commands to only
put the list of bootable partitions in the environment variable
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
common/cmd_part.c | 53 +
1 file changed, 41 insertions(+), 12 deletions(-)
Changes since v1:
* Be more specific about the arguments ordering that is accepted
diff --git a/common/cmd_part.c b/common/cmd_part.c
index c99f527..d04588e 100644
--- a/common/cmd_part.c
+++ b/common/cmd_part.c
@@ -53,29 +53,57 @@ static int do_part_list(int argc, char * const argv[])
{
int ret;
block_dev_desc_t *desc;
+ char *var = NULL;
+ bool bootable = false;
+ int i;
- if (argc 2 || argc 3)
+ if (argc 2)
return CMD_RET_USAGE;
+ if (argc 2) {
+ for (i = 2; i argc ; i++) {
+ if (argv[i][0] == '-') {
+ if (!strcmp(argv[i], -bootable)) {
+ bootable = true;
+ } else {
+ printf(Unknown option %s\n, argv[i]);
+ return CMD_RET_USAGE;
+ }
+ } else {
+ var = argv[i];
+ break;
+ }
+ }
+
+ /* Loops should have been exited at the last argument, which
+* as it contained the variable */
+ if (argc != i + 1)
+ return CMD_RET_USAGE;
+ }
+
ret = get_device(argv[0], argv[1], desc);
if (ret 0)
return 1;
- if (argc == 3) {
+ if (var != NULL) {
int p;
- char str[512] = { 0, };
+ char str[512] = { '\0', };
disk_partition_t info;
for (p = 1; p 128; p++) {
+ char t[5];
int r = get_partition_info(desc, p, info);
- if (r == 0) {
- char t[5];
- sprintf(t, %s%d, str[0] ? : , p);
- strcat(str, t);
- }
+ if (r != 0)
+ continue;
+
+ if (bootable !info.bootable)
+ continue;
+
+ sprintf(t, %s%d, str[0] ? : , p);
+ strcat(str, t);
}
- setenv(argv[2], str);
+ setenv(var, str);
return 0;
}
@@ -98,7 +126,7 @@ static int do_part(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
U_BOOT_CMD(
- part, 5, 1, do_part,
+ part, CONFIG_SYS_MAXARGS, 1, do_part,
disk partition related commands,
part uuid interface dev:part\n
- print partition UUID\n
@@ -106,6 +134,7 @@ U_BOOT_CMD(
- set environment variable to partition UUID\n
part list interface dev\n
- print a device's partition table\n
- part list interface dev varname\n
- - set environment variable to the list of partitions
+ part list interface dev [flags] varname\n
+ - set environment variable to the list of partitions\n
+ flags can be -bootable (list only bootable partitions)
);
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] config_distro_bootcmd.h: Prefer booting from bootable paritions
List bootable partitions and only scan those for bootable files, falling
back to partition 1 if there are no bootable partitions
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Reviewed-by: Hans de Goede hdego...@redhat.com
---
include/config_distro_bootcmd.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Changes since v1:
* No changes
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 07a0b3b..ad2dda1 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -197,7 +197,8 @@
done\0 \
\
scan_dev_for_boot_part= \
- part list ${devtype} ${devnum} devplist;\
+ part list ${devtype} ${devnum} -bootable devplist; \
+ env exists devplist || setenv devplist 1; \
for bootpart in ${devplist}; do \
if fstype ${devtype} ${devnum}:${bootpart} \
bootfstype; then\
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] config_cmd_default.h: Add 'env exists' command
env exists allows scripts to query whether an environment variable exists. Enable by default as it adds only a trivial amount of code and can be useful in scripts. Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk Reviewed-by: Hans de Goede hdego...@redhat.com --- include/config_cmd_default.h | 1 + 1 file changed, 1 insertion(+) Changes since v1: * no changes diff --git a/include/config_cmd_default.h b/include/config_cmd_default.h index 73c9544..e79a13b 100644 --- a/include/config_cmd_default.h +++ b/include/config_cmd_default.h @@ -21,6 +21,7 @@ #define CONFIG_CMD_CONSOLE /* coninfo */ #define CONFIG_CMD_ECHO/* echo arguments */ #define CONFIG_CMD_EDITENV /* editenv */ +#define CONFIG_CMD_ENV_EXISTS /* query whether env variables exists */ #define CONFIG_CMD_FPGA/* FPGA configuration Support */ #define CONFIG_CMD_IMI /* iminfo */ #define CONFIG_CMD_ITEST /* Integer (and string) test*/ -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/20] tegra: Expand Nyan-big support
Hey Simon, Incidentally i got acces to a Nyan big and wanted to start testing u-boot on it. Unfortunately putting a uImage in a vboot signed blob to chainload it from the primary bootloader like on the exynos based chromebooks seemed not to work. Do you have any good pointers how to use u-boot on nyan? (Ideally without having to re-flash coreboot, as i would like to create images people can easily test on a vanilla chromebook) On Tue, 2015-02-17 at 15:29 -0700, Simon Glass wrote: This series expands Nyan-big support: - Enable Chrome OS EC, so that the keyboard works - Add some extra clock and pre-kernel init required for reliable operation - Add Chrome OS environment variables, including 'run nvboot' to allow booting Chrome OS more easily Still missing are audio and USB. Doug Anderson (1): Add Chrome OS config header Simon Glass (19): dm: spi: Avoid setting the speed with every transfer cros_ec: Show the protocol version in the debug message cros_ec: Handle the single duplex requirement in cros_ec tegra: Provide more accurate microsecond time tegra: cros_ec: Add tegra support for Chrome OS EC tegra: spi: Drop the claim_bus() method to correct delays dm: tegra: cros_ec: Enable Chrome OS EC on Nyan-big dm: gpio: Add an implementation for gpio_get_number() tegra: spi: Support slow SPI rates tegra: clock: Support enabling external clocks tegra: clock: Adjust PLL access to avoid a warning tegra: Introduce SRAM repair on tegra124 tegra: Add missing tegra124 peripherals tegra: Increase maximum arguments to 32 tegra: lcd: Tidy up clock init tegra: Allow board-specific init tegra: nyan-big: Add additional clock and kernel init tegra: config: Allow Chrome OS environment settings to be included tegra: config: nyan-big: Add options required by Chrome OS boot arch/arm/cpu/tegra-common/Makefile| 1 + arch/arm/cpu/tegra-common/clock.c | 24 +- arch/arm/cpu/tegra-common/powergate.c | 20 +- arch/arm/cpu/tegra-common/timer.c | 87 arch/arm/cpu/tegra124-common/clock.c | 2 +- arch/arm/dts/tegra124-nyan-big.dts| 6 +- arch/arm/include/asm/arch-tegra/clock.h | 8 + arch/arm/include/asm/arch-tegra/sys_proto.h | 7 + arch/arm/include/asm/arch-tegra124/clock-tables.h | 12 +- arch/arm/include/asm/arch-tegra124/flow.h | 12 + board/nvidia/common/board.c | 8 +- board/nvidia/nyan-big/nyan-big.c | 76 configs/nyan-big_defconfig| 5 + drivers/gpio/gpio-uclass.c| 12 + drivers/misc/cros_ec.c| 3 +- drivers/misc/cros_ec_spi.c| 23 +- drivers/spi/spi-uclass.c | 9 +- drivers/spi/tegra114_spi.c| 51 +-- drivers/video/tegra124/tegra124-lcd.c | 4 +- include/configs/chromeos.h| 464 ++ include/configs/nyan-big.h| 8 + include/configs/tegra-common-post.h | 15 +- include/configs/tegra-common.h| 2 +- include/spi.h | 3 + 24 files changed, 804 insertions(+), 58 deletions(-) create mode 100644 arch/arm/cpu/tegra-common/timer.c create mode 100644 include/configs/chromeos.h smime.p7s Description: S/MIME cryptographic 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 master
On Wed, Feb 25, 2015 at 01:29:17PM -0800, York Sun wrote: Tom, The following changes since commit 38dac81b3d0e777f301ca98100bfbcab01d616c2: Merge branch 'master' of git://git.denx.de/u-boot-mmc (2015-02-23 16:18:06 -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 94e3c8c4fd7bfe395fa467973cd647551d6d98c7: crypto/fsl - Add progressive hashing support using hardware acceleration. (2015-02-25 13:20:02 -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 0/9] ARM: tegra: pinmux: Tegra210 support
On 02/25/2015 05:54 PM, Simon Glass wrote: On 24 February 2015 at 17:06, Stephen Warren swar...@wwwdotorg.org wrote: On 02/24/2015 04:44 PM, Simon Glass wrote: On 24 February 2015 at 14:08, Stephen Warren swar...@wwwdotorg.org wrote: This series performs a few small cleanups to or parameterizations of the existing Tegra pinmux driver, and adds Tegra210 support. The Tegra210 code isn't actually used yet, since the balance of the Tegra210 support is not yet present. However, it should start appearing soon. ... Stephen Warren (9): ARM: tegra: pinmux: add note re: drive group field defines ARM: tegra: pinmux: simplify some defines ARM: tegra: pinmux: handle feature removal on newer SoCs ARM: tegra: pinmux: move some type definitions ARM: tegra: pinmux: partially handle varying register layouts ARM: tegra: pinmux: support hsm/schmitt on pins ARM: tegra: pinmux: account for different drivegroup base registers ARM: tegra: pinmux: support Tegra210's e_io_hv pin option ARM: tegra: pinmux: add Tegra210 support Does the Linux side look similar to this? The use of #defines seem like a potential temporary solution but I hope it doesn't stay that way. ... The Linux side was already a bit more parameterized, so the Tegra210 support series doesn't have as many patches as the U-Boot series. However, that comes at the cost of the per-SoC drivers having much larger data tables, so I don't expect we'd want to adopt in U-Boot the same level of driver parameterization as Linux. I see - do you know how much bigger the tables are? Kernel per-SoC files: textdata bss dec hex filename 255321068 0 2660067e8 pinctrl-tegra30.o 187441032 0 197764d40 pinctrl-tegra114.o 198681128 0 209965204 pinctrl-tegra124.o 16296 972 0 172684374 pinctrl-tegra210.o U-Boot per-SoC files, although these could actually be reduced to zero if we re-wrote the per-board pinmux tables to use FUNC0..3 enums (i.e. raw HW register mux values) and hence got rid of the need to map a mux enum to FUNC0..3 values. Auto-generation of the per-board files would make pretty easy, if all boards were in tegra-pinmux-scripts. textdata bss dec hex filename 996 4 01000 3e8 .../tegra30/pinmux.o 1036 4 01040 410 .../tegra114/pinmux.o 1076 4 01080 438 .../tegra124/pinmux.o ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] spi: designware_spi: revisit FIFO size detection again
By specification the FIFO size would be in a range 2-256 bytes. From TX Level
prospective it means we can set threshold in the range 0-(FIFO size - 1) bytes.
Hence there are currently two issues:
a) FIFO size 2 bytes is actually skipped since TX Level is 1 bit and could be
either 0 or 1 byte;
b) FIFO size is incorrectly decreased by 1 which already done by meaning of
TX Level register.
Fixes: 501943696ea4 (spi: designware_spi: Fix detecting FIFO depth)
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
Signed-off-by: Axel Lin axel@ingics.com
---
This fix is from linux-spi tree:
http://git.kernel.org/cgit/linux/kernel/git/broonie/spi.git/commit/?h=for-linusid=9d239d353c319f9ff884c287ce47feb7cdf60ddc
drivers/spi/designware_spi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index 2624844..8f5c0fc 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -164,13 +164,13 @@ static void spi_hw_init(struct dw_spi_priv *priv)
if (!priv-fifo_len) {
u32 fifo;
- for (fifo = 2; fifo = 256; fifo++) {
+ for (fifo = 1; fifo 256; fifo++) {
dw_writew(priv, DW_SPI_TXFLTR, fifo);
if (fifo != dw_readw(priv, DW_SPI_TXFLTR))
break;
}
- priv-fifo_len = (fifo == 2) ? 0 : fifo - 1;
+ priv-fifo_len = (fifo == 1) ? 0 : fifo;
dw_writew(priv, DW_SPI_TXFLTR, 0);
}
debug(%s: fifo_len=%d\n, __func__, priv-fifo_len);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] x86: Support machines with 4GB of RAM
Hi Simon,
On Thu, Feb 26, 2015 at 8:55 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 25 February 2015 at 00:10, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Wed, Feb 11, 2015 at 9:59 AM, Simon Glass s...@chromium.org wrote:
Some systems have more than 4GB of RAM. U-Boot can only place things below
4GB so any memory above that should not be used. Ignore any such memory so
that the memory size will not exceed the maximum.
This prevents gd-ram_size exceeding 4GB which causes problems for PCI
devices which use DMA.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/coreboot/sdram.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/cpu/coreboot/sdram.c b/arch/x86/cpu/coreboot/sdram.c
index e98a230..9c3ab81 100644
--- a/arch/x86/cpu/coreboot/sdram.c
+++ b/arch/x86/cpu/coreboot/sdram.c
@@ -90,7 +90,8 @@ int dram_init(void)
struct memrange *memrange = lib_sysinfo.memrange[i];
unsigned long long end = memrange-base + memrange-size;
- if (memrange-type == CB_MEM_RAM end ram_size)
+ if (memrange-type == CB_MEM_RAM end ram_size
+ memrange-base (1ULL 32))
Can we safely assume no single entry in memrange[] lies across the 4GB
boundary?
From what I have seen, yes. There always seems to be a hole in memory
from about 3.3GB to 4GB.
OK, then
Reviewed-by: Bin Meng bmeng...@gmail.com
ram_size = end;
}
gd-ram_size = ram_size;
@@ -108,7 +109,8 @@ void dram_init_banksize(void)
for (i = 0, j = 0; i lib_sysinfo.n_memranges; i++) {
struct memrange *memrange =
lib_sysinfo.memrange[i];
- if (memrange-type == CB_MEM_RAM) {
+ if (memrange-type == CB_MEM_RAM
+ memrange-base (1ULL 32)) {
gd-bd-bi_dram[j].start = memrange-base;
gd-bd-bi_dram[j].size = memrange-size;
j++;
--
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v4 08/23] net: Use int instead of u8 for boolean flag
On 24 February 2015 at 17:02, Joe Hershberger joe.hershber...@ni.com wrote: On some archs masking the parameter is inefficient, so don't use u8. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reported-by: Simon Glass s...@chromium.org --- Changes in v4: -New to v4 Changes in v3: None Changes in v2: None include/net.h | 2 +- net/eth.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v4 07/23] net: Change return codes from net/eth.c to use errorno constants
On 24 February 2015 at 17:02, Joe Hershberger joe.hershber...@ni.com wrote: Many functions returned -1 previously. Change them to return appropriate error codes. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reported-by: Simon Glass s...@chromium.org --- Changes in v4: -New to v4 Changes in v3: None Changes in v2: None net/eth.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/20] tegra: Provide more accurate microsecond time
On 02/17/2015 03:29 PM, Simon Glass wrote:
Add an implementation of the timer functions for tegra, so that timing
is more accurate. Tegra has a 1 microsecond timer for this purpose.
I'm a bit confused about this:
include/configs/tegra-common.h:32:#define CONFIG_SYS_TIMER_COUNTER
NV_PA_TMRUS_BASE
lib/time.c:
#ifdef CONFIG_SYS_TIMER_COUNTER
unsigned long notrace timer_read_counter(void)
{
#ifdef CONFIG_SYS_TIMER_COUNTS_DOWN
return ~readl(CONFIG_SYS_TIMER_COUNTER);
#else
return readl(CONFIG_SYS_TIMER_COUNTER);
#endif
}
Doesn't that provide the same set of features, without requiring
Tegra-specific code?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 17/20] tegra: nyan-big: Add additional clock and kernel init
On 02/17/2015 03:29 PM, Simon Glass wrote: We need to turn on all audio-related clocks for the kernel to boot. Otherwise it will hang when trying to enable audio. This certainly isn't true for the upstream kernel; is this some bug in the ChromeOS kernel? If so, we should explicitly call this out in the commit description. Also for Linux set up the ODMDATA and graphics driver video protection. Why doesn't ODMDATA come from the BCT? The way this is suppose to work is that the boot ROM copies the BCT into IRAM, and U-Boot (or indeed any bootloader) copies the ODMDATA field from the BCT in IRAM into the PMC scratch20 register. This logic is already all in place in U-Boot, and indeed any NVIDIA-authored bootloader AFAIK. Is this U-Boot port intended to run as a Coreboot payload rather than natively, and Coreboot is somehow corrupting the copy of the BCT in IRAM? If so, we should explicitly call this out in the commit description. I would personally want to (be able to) make my SPI flash r/w and replace Coreboot with U-Boot. Perhaps we need different board names for those two use-cases; something like nyan-big for the Coreboot payload, and nyan-big-native for the version you'd write directly into SPI? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 18/20] Add Chrome OS config header
On 02/17/2015 03:29 PM, Simon Glass wrote: From: Doug Anderson diand...@chromium.org This header includes useful scripts which can be used with any board that can boot Chrome OS. In particular, 'run nvboot' will boot a board without verified boot enabled. I think this needs a bit of minification for an upstream U-Boot. In particular, many of the environment variables overlap semantically or by name with those from include/config_distro_*.h, and I'd like to see any U-Boot for the Tegra Chromebooks (at least) support booting both ChromeOS kernels and arbitrary distros using the environment from config_distro_bootcmd.h. diff --git a/include/configs/chromeos.h b/include/configs/chromeos.h +/* Stringify a token */ +#ifndef STRINGIFY +#define _STRINGIFY(x) #x +#define STRINGIFY(x) _STRINGIFY(x) +#endif Shouldn't that be in some common header so it isn't ever duplicated? +#define CONFIG_CROS_FULL There are a ton of macros in here without much in the way of explanation. Shouldn't everything be documented in the README? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 1/1] fastboot: Add support for flashing zImage
This patch adds support to flash zImage to the boot partition on eMMC.
Usage: fastboot flash zImage path_to_zImage
Signed-off-by: Angela Stegmaier angelaba...@ti.com
Signed-off-by: Dileep Katta dileep.ka...@linaro.org
---
drivers/usb/gadget/f_fastboot.c | 152
1 file changed, 152 insertions(+)
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 310175a..d3d16c0 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -23,6 +23,7 @@
#ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
#include fb_mmc.h
#endif
+#include android_image.h
#define FASTBOOT_VERSION 0.4
@@ -492,6 +493,152 @@ static void cb_continue(struct usb_ep *ep, struct
usb_request *req)
}
#ifdef CONFIG_FASTBOOT_FLASH
+static int fastboot_update_zimage(void);
+
+static u32 fastboot_get_boot_ptn(struct andr_img_hdr *hdr, char *response,
+ block_dev_desc_t *dev_desc)
+{
+ u32 hdr_sectors = 0;
+ u32 sector_size;
+ int status = 0;
+ strcpy(response, OKAY);
+ disk_partition_t info;
+
+ status = get_partition_info_efi_by_name(dev_desc, boot, info);
+ if (status) {
+ strcpy(response, FAILCannot find boot partition);
+ goto out;
+ }
+
+ /* Read the boot image header */
+ sector_size = info.blksz;
+ hdr_sectors = (sizeof(struct andr_img_hdr)/sector_size) + 1;
+ status = dev_desc-block_read(dev_desc-dev, info.start,
+ hdr_sectors, (void *)hdr);
+
+ if (status 0) {
+ strcpy(response, FAILCannot read hdr from boot partition);
+ goto out;
+ }
+ if (android_image_check_header(hdr) != 0) {
+ printf(bad boot image magic\n);
+ strcpy(response, FAILBoot partition not initialized);
+ goto out;
+ }
+
+ return hdr_sectors;
+
+out:
+ strcpy(response, INFO);
+ fastboot_tx_write_str(response);
+
+ return -1;
+}
+
+#define CEIL(a, b) (((a) / (b)) + ((a % b) 0 ? 1 : 0))
+
+static int fastboot_update_zimage(void)
+{
+ struct andr_img_hdr *hdr = NULL;
+ u8 *ramdisk_buffer;
+ u32 ramdisk_sector_start, ramdisk_sectors;
+ u32 kernel_sector_start, kernel_sectors;
+ u32 hdr_sectors = 0;
+ u32 sectors_per_page = 0;
+ int ret = 0;
+ block_dev_desc_t *dev_desc;
+ disk_partition_t info;
+ char response[RESPONSE_LEN];
+ u32 addr = CONFIG_USB_FASTBOOT_BUF_ADDR;
+
+ strcpy(response, OKAY);
+ printf(Flashing zImage...%d bytes\n, download_bytes);
+
+ dev_desc = get_dev(mmc, CONFIG_FASTBOOT_FLASH_MMC_DEV);
+ if (!dev_desc || dev_desc-type == DEV_TYPE_UNKNOWN) {
+ sprintf(response + strlen(response),
+ FAILInvalid mmc device);
+ ret = -1;
+ goto out;
+ }
+
+ addr += CEIL(download_bytes, 0x1000) * 0x1000;
+ hdr = (struct andr_img_hdr *)addr;
+
+ hdr_sectors = fastboot_get_boot_ptn(hdr, response, dev_desc);
+ if (hdr_sectors = 0) {
+ sprintf(response + strlen(response),
+ FAILInvalid number of boot sectors %d, hdr_sectors);
+ ret = -1;
+ goto out;
+ }
+ ret = get_partition_info_efi_by_name(dev_desc, boot, info);
+ if (ret) {
+ strcpy(response, FAILCannot find boot partition);
+ ret = -1;
+ goto out;
+ }
+
+ /* Extract ramdisk location and read it into local buffer */
+ sectors_per_page = hdr-page_size / info.blksz;
+ ramdisk_sector_start = info.start + sectors_per_page;
+ ramdisk_sector_start += CEIL(hdr-kernel_size, hdr-page_size)*
+sectors_per_page;
+ ramdisk_sectors = CEIL(hdr-ramdisk_size, hdr-page_size)*
+ sectors_per_page;
+
+ ramdisk_buffer = (u8 *)hdr;
+ ramdisk_buffer += (hdr_sectors * info.blksz);
+ ret = dev_desc-block_read(dev_desc-dev, ramdisk_sector_start,
+ ramdisk_sectors, ramdisk_buffer);
+ if (ret 0) {
+ sprintf(response, FAILCannot read ramdisk from 'boot');
+ ret = -1;
+ goto out;
+ }
+
+ /* Change the boot img hdr */
+ hdr-kernel_size = download_bytes;
+ ret = dev_desc-block_write(dev_desc-dev, info.start,
+ hdr_sectors, (void *)hdr);
+ if (ret 0) {
+ sprintf(response, FAILCannot writeback boot img hdr);
+ ret = -1;
+ goto out;
+ }
+
+ /* Write the new downloaded kernel*/
+ kernel_sector_start = info.start + sectors_per_page;
+ kernel_sectors = CEIL(hdr-kernel_size, hdr-page_size)*
+
Re: [U-Boot] [PATCH v1 1/1] fastboot: Update getvar command to get 'userdata' partition size
On Wed, Feb 25, 2015 at 3:45 PM, Dileep Katta dileep.ka...@linaro.org wrote: Hi Rob, On 20 February 2015 at 20:24, Rob Herring rob.herr...@linaro.org wrote: On Wed, Feb 18, 2015 at 1:52 PM, Dileep Katta dileep.ka...@linaro.org wrote: This patch adds functionality to getvar command to get the userdata partition size. This is non-standard and doesn't scale to other partitions. There is Is there a way to add support for retrieving some non-standard variables, such as cpu_type or board specific information in getvar or other command(oem!) in fastboot? That is what my patch does. You just have to create the env variable on your board. already a standard var partition-size:part name. There is also partition-type:part name which probably needs to be supported as well. It would probably be good to have generic code to retrieve fastboot variables from a u-boot environment variables. Something like this: fastboot: allow retrieving fastboot variables from env Signed-off-by: Rob Herring r...@kernel.org Thanks for the suggestion. Is it fine to extend fb_mmc_get_ptn_size() in this patch to to support standard var partition-size:part name and similar functionality for partition-type? That's probably ok, but it would not work on an un-formatted device (perhaps that is okay). Also, I'd rather not see more MMC specific code. Soon as I want to support a device with SATA, then we've got to go generalize everything. or using mtdparts environment variable to get partition-type or partition-size is preferable? Please advise. The partitioning/formatting code needs to know the sizes of partitions, so keeping them in env vars could be reused by both. Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] x86: Support machines with 4GB of RAM
Hi Bin,
On 25 February 2015 at 00:10, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Wed, Feb 11, 2015 at 9:59 AM, Simon Glass s...@chromium.org wrote:
Some systems have more than 4GB of RAM. U-Boot can only place things below
4GB so any memory above that should not be used. Ignore any such memory so
that the memory size will not exceed the maximum.
This prevents gd-ram_size exceeding 4GB which causes problems for PCI
devices which use DMA.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/coreboot/sdram.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/cpu/coreboot/sdram.c b/arch/x86/cpu/coreboot/sdram.c
index e98a230..9c3ab81 100644
--- a/arch/x86/cpu/coreboot/sdram.c
+++ b/arch/x86/cpu/coreboot/sdram.c
@@ -90,7 +90,8 @@ int dram_init(void)
struct memrange *memrange = lib_sysinfo.memrange[i];
unsigned long long end = memrange-base + memrange-size;
- if (memrange-type == CB_MEM_RAM end ram_size)
+ if (memrange-type == CB_MEM_RAM end ram_size
+ memrange-base (1ULL 32))
Can we safely assume no single entry in memrange[] lies across the 4GB
boundary?
From what I have seen, yes. There always seems to be a hole in memory
from about 3.3GB to 4GB.
ram_size = end;
}
gd-ram_size = ram_size;
@@ -108,7 +109,8 @@ void dram_init_banksize(void)
for (i = 0, j = 0; i lib_sysinfo.n_memranges; i++) {
struct memrange *memrange = lib_sysinfo.memrange[i];
- if (memrange-type == CB_MEM_RAM) {
+ if (memrange-type == CB_MEM_RAM
+ memrange-base (1ULL 32)) {
gd-bd-bi_dram[j].start = memrange-base;
gd-bd-bi_dram[j].size = memrange-size;
j++;
--
Regards,
Bin
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/22] RFC: x86: Split up arch_cpu_init()
Hi Bin,
On 25 February 2015 at 01:45, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Thu, Feb 19, 2015 at 5:10 AM, Simon Glass s...@chromium.org wrote:
At present we do more in this function than we should. Create a new
x86_post_cpu_init() which can be called from the board file when needed
(e.g. in board_early_init_f(). This allows us to use driver model for
our x86_post_cpu_init() function.
It is likely that some future refactoring will improve this and reduce
the number of steps, using driver model's probing features.
Note: this needs more discussion - e.g. I believe it breaks other x86
boards. We may want to plumb this in differently (e.g. promote
x86_post_cpu_init() to the board_init_f() boot sequence).
Or maybe change the order in board_f.c so that arch_cpu_init() comes
after init_dm()?
I feel that arch_cpu_init() should be for very early things, the
absolute minimum to allow the machine to function and driver model to
be set up. Clearly x86 does not conform to that now!
But I think there are a few things that fit in this category so having
the separated seems better.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/ivybridge/cpu.c| 8
arch/x86/include/asm/u-boot-x86.h | 1 +
board/google/chromebook_link/link.c | 6 ++
3 files changed, 15 insertions(+)
diff --git a/arch/x86/cpu/ivybridge/cpu.c b/arch/x86/cpu/ivybridge/cpu.c
index 5fd3753..2796314 100644
--- a/arch/x86/cpu/ivybridge/cpu.c
+++ b/arch/x86/cpu/ivybridge/cpu.c
@@ -116,6 +116,14 @@ static void set_spi_speed(void)
int arch_cpu_init(void)
{
+ post_code(POST_CPU_INIT);
+ timer_set_base(rdtsc());
+
+ return x86_cpu_init_f();
+}
+
+int x86_post_cpu_init(void)
+{
const void *blob = gd-fdt_blob;
struct pci_controller *hose;
int node;
diff --git a/arch/x86/include/asm/u-boot-x86.h
b/arch/x86/include/asm/u-boot-x86.h
index c743efd..d5a9535 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -38,6 +38,7 @@ void reset_cpu(ulong addr);
ulong board_get_usable_ram_top(ulong total_size);
void dram_init_banksize(void);
int default_print_cpuinfo(void);
+int x86_post_cpu_init(void);
/* Set up a UART which can be used with printch(), printhex8(), etc. */
int setup_early_uart(void);
diff --git a/board/google/chromebook_link/link.c
b/board/google/chromebook_link/link.c
index 9978e92..9ebbb9f 100644
--- a/board/google/chromebook_link/link.c
+++ b/board/google/chromebook_link/link.c
@@ -120,6 +120,12 @@ static const struct pch_gpio_map link_gpio_map = {
int board_early_init_f(void)
{
+ int ret;
+
+ ret = x86_post_cpu_init();
+ if (ret)
+ return ret;
+
ich_gpio_set_gpio_map(link_gpio_map);
return 0;
--
Regards,
Bin
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] x86: Add support for panther (Asus Chromebox)
Hi Bin,
On 25 February 2015 at 00:32, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Wed, Feb 11, 2015 at 9:59 AM, Simon Glass s...@chromium.org wrote:
Support running U-Boot as a coreboot payload. Tested peripherals include:
- Video (HDMI and DisplayPort)
- SATA disk
- Gigabit Ethernet
- SPI flash
USB3 does not work. This may be a problem with the USB3 PCI driver or
something in the USB3 stack and has not been investigated So far this is
disabled. The SD card slot also does not work.
For video, coreboot will need to run the OPROM to set this up.
With this board, bare support (running without coreboot) is not available
as yet.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/Kconfig | 16 +
arch/x86/dts/Makefile | 1 +
arch/x86/dts/chromebox_panther.dts | 64
++
board/google/chromebox_panther/Kconfig | 18 ++
configs/chromebox_panther_defconfig| 11 ++
include/configs/chromebox_panther.h| 17 +
6 files changed, 127 insertions(+)
create mode 100644 arch/x86/dts/chromebox_panther.dts
create mode 100644 board/google/chromebox_panther/Kconfig
create mode 100644 configs/chromebox_panther_defconfig
create mode 100644 include/configs/chromebox_panther.h
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index fef11f3..6c667ae 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -32,6 +32,20 @@ config TARGET_CHROMEBOOK_LINK
and it provides a 2560x1700 high resolution touch-enabled LCD
display.
+config TARGET_CHROMEBOX_PANTHER
+ bool Support Chromebox panther (not available)
+ select n
+ help
+ Note: At present this must be used with Coreboot. See README.x86
+ for instructions.
+
+ This is the Asus Chromebox CN60 released in 2014. It uses an Intel
+ Haswell Celeron 2955U Dual Core CPU with 2GB of SDRAM. It has a
+ Lynx Point platform controller hub, PCIe WiFi and Bluetooth. It
also
+ includes a USB SD reader, four USB3 ports, display port and HDMI
+ video output and a 16GB SATA solid state drive. There is no Chrome
+ OS EC on this model.
+
config TARGET_CROWNBAY
bool Support Intel Crown Bay CRB
help
@@ -420,6 +434,8 @@ source board/coreboot/coreboot/Kconfig
source board/google/chromebook_link/Kconfig
+source board/google/chromebox_panther/Kconfig
+
source board/intel/crownbay/Kconfig
source board/intel/minnowmax/Kconfig
diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile
index 7a66133..431bbd8 100644
--- a/arch/x86/dts/Makefile
+++ b/arch/x86/dts/Makefile
@@ -1,4 +1,5 @@
dtb-y += chromebook_link.dtb \
+ chromebox_panther.dtb \
crownbay.dtb \
galileo.dtb \
minnowmax.dtb
diff --git a/arch/x86/dts/chromebox_panther.dts
b/arch/x86/dts/chromebox_panther.dts
new file mode 100644
index 000..01d43e4
--- /dev/null
+++ b/arch/x86/dts/chromebox_panther.dts
@@ -0,0 +1,64 @@
+/dts-v1/;
+
+/include/ skeleton.dtsi
+/include/ serial.dtsi
+
+/ {
+ model = Google Panther;
+ compatible = google,panther, intel,celeron-haswell;
intel,celeron-haswell? celeron is the brand name of the processor.
To keep in consistent with other dts files, I think we can just
describe it to be intel,haswell.
OK.
+
+ aliases {
+ spi0 = /spi;
+ };
+
+ config {
+ silent-console = 0;
+ no-keyboard;
+ };
+
+ gpioa {
+ compatible = intel,ich6-gpio;
+ u-boot,dm-pre-reloc;
+ reg = 0 0x10;
+ bank-name = A;
+ };
+
+ gpiob {
+ compatible = intel,ich6-gpio;
+ u-boot,dm-pre-reloc;
+ reg = 0x30 0x10;
+ bank-name = B;
+ };
+
+ gpioc {
+ compatible = intel,ich6-gpio;
+ u-boot,dm-pre-reloc;
+ reg = 0x40 0x10;
+ bank-name = C;
+ };
+
+ chosen {
+ stdout-path = /serial;
+ };
+
+ spi {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = intel,ich-spi;
+ spi-flash@0 {
+ #size-cells = 1;
+ #address-cells = 1;
+ reg = 0;
+ compatible = winbond,w25q64, spi-flash;
+ memory-map = 0xff80 0x0080;
+ rw-mrc-cache {
+ label = rw-mrc-cache;
+ /* Alignment: 4k (for updating) */
+ reg = 0x003e 0x0001;
+ type = wiped;
+ wipe-value = [ff];
+ };
+ };
+
Re: [U-Boot] [PATCH 0/9] ARM: tegra: pinmux: Tegra210 support
Hi Stephen, On 24 February 2015 at 17:06, Stephen Warren swar...@wwwdotorg.org wrote: On 02/24/2015 04:44 PM, Simon Glass wrote: Hi Stephen, On 24 February 2015 at 14:08, Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com This series performs a few small cleanups to or parameterizations of the existing Tegra pinmux driver, and adds Tegra210 support. The Tegra210 code isn't actually used yet, since the balance of the Tegra210 support is not yet present. However, it should start appearing soon. I've at least compile-tested this by over-writing the Tegra124 pinmux driver and Jetson TK1 board pinmux data tables with the Tegra210 versions. TomW, note I made a couple minor tweaks since the latest version I sent internally; let's apply this version upstream. Stephen Warren (9): ARM: tegra: pinmux: add note re: drive group field defines ARM: tegra: pinmux: simplify some defines ARM: tegra: pinmux: handle feature removal on newer SoCs ARM: tegra: pinmux: move some type definitions ARM: tegra: pinmux: partially handle varying register layouts ARM: tegra: pinmux: support hsm/schmitt on pins ARM: tegra: pinmux: account for different drivegroup base registers ARM: tegra: pinmux: support Tegra210's e_io_hv pin option ARM: tegra: pinmux: add Tegra210 support Does the Linux side look similar to this? The use of #defines seem like a potential temporary solution but I hope it doesn't stay that way. It feels like maybe we need to define an API that would suit all Tegra chips? The Linux side was already a bit more parameterized, so the Tegra210 support series doesn't have as many patches as the U-Boot series. However, that comes at the cost of the per-SoC drivers having much larger data tables, so I don't expect we'd want to adopt in U-Boot the same level of driver parameterization as Linux. I see - do you know how much bigger the tables are? You can find the kernel patches on the linux-tegra mailing list; I posted them roughly the same time as the U-Boot patches. The U-Boot API to the pinmux driver is already identical across all chips (at least Tegra114+; Tegra20 and perhaps Tegra30 boards might use some more fine-grained APIs in what I'd assert is a legacy fashion); the board file simply calls gpio_config_table(), pinmux_config_pingrp_table(), and pinmux_config_drvgrp_table(), passing the relevant data table to each. The only difference between SoCs is the set of fields in the data table, since each SoC has a different feature set. While we could reduce the number of ifdefs and unify the structs across chips, this would be at the cost of bloating structs with fields that aren't supported, and including functions to apply settings that will never be used by any pin's data table entries, thus using more .text and .rodata space without good reason. OK, well that's up to you, I suppose I was talking about the lower-level API, and probably that ties in with the discussion about a pinctl layer. Let's see what happens in the future. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] stdio: extend name to 32 symbols
On 25 February 2015 at 11:26, Alexey Brodkin
alexey.brod...@synopsys.com wrote:
With limit of 16 symbols very simple device names derived drom device
tree description could not be displayed correctly.
For example serial0@0xc0fc1000 will be truncated to sensless
serial0@0xc0fc10 - note dropped tariling zeros.
trailing
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Simon Glass s...@chromium.org
Cc: Tom Rini tr...@ti.com
Reviewed-by: Simon Glass s...@chromium.org
---
include/stdio_dev.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/stdio_dev.h b/include/stdio_dev.h
index 24da23f..95d6246 100644
--- a/include/stdio_dev.h
+++ b/include/stdio_dev.h
@@ -23,7 +23,7 @@
struct stdio_dev {
int flags; /* Device flags: input/output/system
*/
int ext;/* Supported extensions
*/
- charname[16]; /* Device name
*/
+ charname[32]; /* Device name
*/
/* GENERAL functions */
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 20/20] tegra: config: nyan-big: Add options required by Chrome OS boot
On 02/17/2015 03:29 PM, Simon Glass wrote: We need to match the device tree in the FIT with the U-Boot model so we can automatically select the right device tree. Also adjust the load address so that the device tree is not in the way when a zImage kernel tries to extract itself. We don't tend to use LOADADDR in any of the default boot scripts any more. Rather, we explicitly load files to a semantic location indicated by one of the following variables in tegra124-common.h: #define MEM_LAYOUT_ENV_SETTINGS \ scriptaddr=0x9000\0 \ pxefile_addr_r=0x9010\0 \ kernel_addr_r=0x8100\0 \ fdt_addr_r=0x8200\0 \ ramdisk_addr_r=0x8210\0 Perhaps the ChromeOS boot scripts could be adjusted to use one/some of those variables? If the value of CONFIG_LOADADDR isn't appropriate, perhaps we should fix it for all Tegra SoCs/boards? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
Dear Dave Kucharczyk, On Wed, Feb 25, 2015 at 11:08 PM, DaveKucharczyk david.kucharc...@gmail.com wrote: Fabio Estevam-2 wrote Also, you said that your 512MB board version works fine, but the 256MB fails. I suppose you are using two different binaries for each board, right? You can't have a single binary for the two boards, unless you use the SPL approach. Fabio, we use one binary. It has runtime memory discovery via gpio's (resistor reads). DRAM size is reported correctly from both boards. It just hangs on the 256MB board. We do not have SPL setup. You should try with 2015.01 as Fabio suggested. Also, check the CONFIG_SYS_TEXT_BASE of your board. From your log, I'm wondering if it's not set too high, resulting in an overlap of the pre- and post-relocation addresses occupied by your binary in the 256-MiB case. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
