Re: [U-Boot] [RFC PATCH 06/12] devres: introduce Devres (Managed Device Resource) framework
Hello Simon, On Thu, 9 Jul 2015 07:31:05 -0600, Simon Glass s...@chromium.org wrote: Hi, On 8 July 2015 at 23:41, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Masahiro, On Thu, 9 Jul 2015 14:16:33 +0900, Masahiro Yamada yamada.masah...@socionext.com wrote: Hi Simon, 3. How do we handle things like gpio_exynos_bind() which allocs some data and passes it to a device it creates, as platform data? At present we don't free it. So, currently this driver is leaking the memory, isn't it? If we use devm_kzalloc() here, the platdata for GPIOs will be released when the parent pinctrl is unbound. Does gpio_exynos_bind() get called enough between entry and exit from U-boot that the memory leaks prevent U-Boot from doing its job properly? No we only bind devices once in U-Boot, except for USB which recently changed. Then I'll be the Devil's advocate and question the interest of adding code in U-Boot to fix a leak which, when it happens at all, does not substantially affect U-Boot's functionality. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/13] apalis/colibri_t20/t30: integrate recovery mode detection
On 08.07.2015 22:57, Stephen Warren wrote: On 07/07/2015 12:04 AM, Marcel Ziswiler wrote: On 6 July 2015 18:38:21 CEST, Simon Glass s...@chromium.org wrote: Out of interest, is this just a message for the user? Why is it useful? Well, we or customers might do other interesting things on entering rcm like stopping autoboot or automatically start ums. But that's not what this patch does; it simply prints a message. It doesn't seem terribly useful. IMO, it really is useful: The boot ROM takes other initialization steps when using RCM recovery mode vs. full NAND/eMMC boot. We have had issues in the past where the Linux kernel hangs or shows issues just because something (e.g. USB, NAND or eMMC) was/or was not initialized by the boot ROM first. Of course those are bugs, and need to be resolved in the end. But it can be helpful to reproduce issues when one sees whether the recovery mode has been used or not... -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 06/12] devres: introduce Devres (Managed Device Resource) framework
Hi Albert, On 9 July 2015 at 09:03, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Simon, On Thu, 9 Jul 2015 07:31:05 -0600, Simon Glass s...@chromium.org wrote: Hi, On 8 July 2015 at 23:41, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Masahiro, On Thu, 9 Jul 2015 14:16:33 +0900, Masahiro Yamada yamada.masah...@socionext.com wrote: Hi Simon, 3. How do we handle things like gpio_exynos_bind() which allocs some data and passes it to a device it creates, as platform data? At present we don't free it. So, currently this driver is leaking the memory, isn't it? If we use devm_kzalloc() here, the platdata for GPIOs will be released when the parent pinctrl is unbound. Does gpio_exynos_bind() get called enough between entry and exit from U-boot that the memory leaks prevent U-Boot from doing its job properly? No we only bind devices once in U-Boot, except for USB which recently changed. Then I'll be the Devil's advocate and question the interest of adding code in U-Boot to fix a leak which, when it happens at all, does not substantially affect U-Boot's functionality. Yes, I don't think it matters in practice. I could fix it in the current code too. To be complete we also need a way to 'allocate' driver names such that they are freed when unbound. Not all names are static strings. Regards Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RESEND] tools/imximage: set DCD pointer to NULL when its length is 0
When dcd_len is 0 the Write Data command that the set_dcd_rst_v2() routine generates is empty. This causes HAB to complain that the command is invalid. - HAB Event 1 - event data: 0xdb 0x00 0x0c 0x41 0x33 0x06 0xc0 0x00 0xcc 0x00 0x04 0x04 To fix this set the DCD pointer in the IVT to NULL in this case. The DCD header itself is still needed for detect_imximage_version() to determine the image version. Signed-off-by: Baruch Siach bar...@tkos.co.il --- Resending with a proper To: header. tools/imximage.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/imximage.c b/tools/imximage.c index 6f469ae6336c..7b91d09699ad 100644 --- a/tools/imximage.c +++ b/tools/imximage.c @@ -250,7 +250,11 @@ static void set_imx_hdr_v2(struct imx_header *imxhdr, uint32_t dcd_len, hdr_base = entry_point - imximage_init_loadsize + flash_offset; fhdr_v2-self = hdr_base; - fhdr_v2-dcd_ptr = hdr_base + offsetof(imx_header_v2_t, dcd_table); + if (dcd_len 0) + fhdr_v2-dcd_ptr = hdr_base + + offsetof(imx_header_v2_t, dcd_table); + else + fhdr_v2-dcd_ptr = 0; fhdr_v2-boot_data_ptr = hdr_base + offsetof(imx_header_v2_t, boot_data); hdr_v2-boot_data.start = entry_point - imximage_init_loadsize; -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/13] apalis/colibri_t20/t30: integrate recovery mode detection
On 07/09/2015 09:02 AM, Stefan Agner wrote: On 08.07.2015 22:57, Stephen Warren wrote: On 07/07/2015 12:04 AM, Marcel Ziswiler wrote: On 6 July 2015 18:38:21 CEST, Simon Glass s...@chromium.org wrote: Out of interest, is this just a message for the user? Why is it useful? Well, we or customers might do other interesting things on entering rcm like stopping autoboot or automatically start ums. But that's not what this patch does; it simply prints a message. It doesn't seem terribly useful. IMO, it really is useful: The boot ROM takes other initialization steps when using RCM recovery mode vs. full NAND/eMMC boot. We have had issues in the past where the Linux kernel hangs or shows issues just because something (e.g. USB, NAND or eMMC) was/or was not initialized by the boot ROM first. Of course those are bugs, and need to be resolved in the end. But it can be helpful to reproduce issues when one sees whether the recovery mode has been used or not... Surely you can remember whether you pressed the reset button or used tegrarcm/... to push U-Boot onto the device in recovery mode? If it really is that useful, then I'd suggest not making this board-specific, since it's a SoC-defined concept, not a board-defined concept. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hardware hashing on unsigned fitImage nodes.
Hi Andre,
On 7 July 2015 at 19:22, Andre Wolokita andre.wolok...@analog.com wrote:
Hi Simon,
Hopefully you're the right person to be contacting about this; if not, please
point me in the right direction.
We've recently had a contractor write a hash driver for our crypto
accelerator, intended to accelerate fitImage verification. They noticed that
the hardware hashing API would only be called for the signed nodes (we are
only signing the config node) while the unsigned nodes were still being
processed in software. Their proposed solution was to add logic to
fit_image_check_hash() in common/fit-image.c:
diff --git a/common/image-fit.c b/common/image-fit.c
index 4ffc5aa..1cb26cc 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -906,7 +906,10 @@ static int fit_image_check_hash(const void *fit, int
noffset, const void *data,
uint8_t *fit_value;
int fit_value_len;
int ignore;
-
+#ifdef CONFIG_ADI_HASH
+ struct image_region region;
+ int i;
+#endif
*err_msgp = NULL;
if (fit_image_hash_get_algo(fit, noffset, algo)) {
@@ -928,12 +931,28 @@ static int fit_image_check_hash(const void *fit, int
noffset, const void *data,
*err_msgp = Can't get hash value property;
return -1;
}
+#ifdef CONFIG_ADI_HASH
+ region.data = data;
+ region.size = size;
+ memset(value, '\0', FIT_MAX_HASH_LEN);
+ /* h/w acceleration */
+ if(hash_calculate(algo, region, 1, value)){
+ *err_msgp = Unsupported hash algorithm;
+ return -1;
+ }
+
+ if(strcmp(algo, sha1)==0)
+ value_len = SHA1_SUM_LEN;
+ else
+ value_len = FIT_MAX_HASH_LEN;
+#else
if (calculate_hash(data, size, algo, value, value_len)) {
*err_msgp = Unsupported hash algorithm;
return -1;
}
I realise that adding to common code is probably discouraged. Is there any
other solutions that do not involve doing so? Thank you in advance.
We had a similar thing come up with the RSA algorithm. If you see
drivers/crypto you will find an API that was created for
hardware-accelerated modular exponentiation. There is a software
driver as a fallback.
For hashing, we have hash.c which provides a reasonable API. We could
convert this to driver model with a uclass for hashing. Perhaps it
could support multiple algorithms, with -ENOSYS indicating that the
driver does not support that algorithm, in which case the uclass could
try the next driver? There is something similar in reset_walk() in
this patch:
http://patchwork.ozlabs.org/patch/487822/
This would involve replacing the existing hash.c code, but I suggest
you could do this by creating CONFIG_DM_HASH and when that is defined,
hash. c does not get compiled. You can implement the API in hash.h
using your uclass.
Regards,
Simon
Regards,
Andre.
--
Andre Wolokita (andre.wolok...@analog.com)
Design Engineer, Analog Devices Australia Pty Ltd
Unit 3, 97 Lewis Road, Wantirna, Victoria, 3152, AUSTRALIA
Direct: +61 3 9881 9933 Main: +61 3 9881
Fax: +61 3 9881 9988 Web: www.analog.com/au
Embedded Digital Signal Processing Software.
This communication is proprietary and confidential.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/25] dm: Introduce Rockchip RK3288 support
Hi Ulrich, On 9 July 2015 at 07:16, Ulrich Prinz ulrich.pr...@googlemail.com wrote: Am 08.07.2015 um 17:25 schrieb Simon Glass: +ML Hi Ulrich, On 7 July 2015 at 08:32, Ulrich Prinz ulrich.pr...@googlemail.com wrote: Am 24.06.2015 um 01:28 schrieb Simon Glass: Great, nice to hear from you! There's lots to do. I try my very best... Is there a reachable git repo that I can clone from you, or can you give me Sorry I didn't include that in the cover letter. It's u-boot-dm in branch rockchip-working - http://git.denx.de/u-boot-dm.git/ I followed your README.rockchip and sucessfully created the spl image for download via USB, but trying to load it results in: # ./firefly/tools/mkimage -T rkimage -d ./firefly/spl/u-boot-spl.bin ./firefly/out # cat ./firefly/out | openssl rc4 -K 7c4e0304550509072d2c7b38170d1711 ./firefly/out.img # rkflashtool l firefly/out.img rkflashtool: info: rkflashtool v5.2 rkflashtool: info: Detected RK3288... rkflashtool: info: interface claimed rkflashtool: info: MASK ROM MODE rkflashtool: info: load DDR init rkflashtool is stuck at that point and doesn't return. Serial port is silent. Don't you mean this? ./firefly/tools/mkimage -T rkimage -d ./firefly/spl/u-boot-dtb.spl.bin You need to send U-Boot and its device tree. Perhaps there is a mistake in my instructions but this is what I see here: http://patchwork.ozlabs.org/patch/487875/ + +To create a suitable image and write it to the board: + + ./firefly-rk3288/tools/mkimage -T rkimage -d ./firefly-rk3288/spl/u-boot-spl-dtb.bin out + cat out | openssl rc4 -K 7c4e0304550509072d2c7b38170d1711 | rkflashtool l + Second I tried sd-card image # ./firefly/tools/mkimage -T rksd -d firefly/spl/u-boot-spl-dtb.bin out.sd Warning: SPL image is too large (size 0x82b1) and will not boot Despite of the warning, I copied things to the SD and tried booting but it doesn't light up on serial console. The only difference I have, compared to your setup, is probably the toolchain. I have tried linaros 4.9._2014.11 and 4.8_2014q2 and ubuntu's 4.9.3, all arm-none-eabi. The resulting images are of the following size, more or less independent of the compiler I tried: 720965 Jul 9 14:44 u-boot-spl* 29652 Jul 9 14:44 u-boot-spl.bin* 3757 Jul 9 14:44 u-boot-spl.dtb 33453 Jul 9 14:44 u-boot-spl-dtb.bin This needs to be 32KB or it will not boot. It seems to be a Rockchip boot ROM limitation. With my toolchain it is. I'll check it again later on. I do have a patched toolchain which doesn't add a whole load of unused strings. Maybe that is the difference. Probably I need to cut the size down a bit. 1748823 Jul 9 14:44 u-boot* 208876 Jul 9 14:44 u-boot.bin* regards Ulrich Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] armv8: fsl-lsch3: Rewrite MMU translation table entries
This patch rewrites MMU translation table entries to achieve:
a) Start with all table entries as invalid.
b) Rewrite the table entries as device-ngnrne for cache-inhibit
access.
c) Rewrite the table entries as normal for cache-enabled access.
Signed-off-by: Alison Wang alison.w...@freescale.com
Signed-off-by: York Sun york...@freescale.com
---
arch/arm/cpu/armv8/cache_v8.c| 17 +-
arch/arm/cpu/armv8/fsl-lsch3/README | 71
arch/arm/cpu/armv8/fsl-lsch3/cpu.c | 462 +--
arch/arm/include/asm/arch-fsl-lsch3/config.h | 1 +
arch/arm/include/asm/armv8/mmu.h | 8 +-
5 files changed, 379 insertions(+), 180 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index c5ec529..978175f 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -12,13 +12,22 @@
DECLARE_GLOBAL_DATA_PTR;
#ifndef CONFIG_SYS_DCACHE_OFF
-void set_pgtable_section(u64 *page_table, u64 index, u64 section,
-u64 memory_type)
+inline void set_pgtable_section(u64 *page_table, u64 index, u64 section,
+u64 memory_type, u64 share)
{
u64 value;
value = section | PMD_TYPE_SECT | PMD_SECT_AF;
value |= PMD_ATTRINDX(memory_type);
+ value |= share;
+ page_table[index] = value;
+}
+
+inline void set_pgtable_table(u64 *page_table, u64 index, u64 *table_addr)
+{
+ u64 value;
+
+ value = (u64)table_addr | PMD_TYPE_TABLE;
page_table[index] = value;
}
@@ -32,7 +41,7 @@ static void mmu_setup(void)
/* Setup an identity-mapping for all spaces */
for (i = 0; i (PGTABLE_SIZE 3); i++) {
set_pgtable_section(page_table, i, i SECTION_SHIFT,
- MT_DEVICE_NGNRNE);
+ MT_DEVICE_NGNRNE, PMD_SECT_NON_SHARE);
}
/* Setup an identity-mapping for all RAM space */
@@ -42,7 +51,7 @@ static void mmu_setup(void)
for (j = start SECTION_SHIFT;
j end SECTION_SHIFT; j++) {
set_pgtable_section(page_table, j, j SECTION_SHIFT,
- MT_NORMAL);
+ MT_NORMAL, PMD_SECT_NON_SHARE);
}
}
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/README
b/arch/arm/cpu/armv8/fsl-lsch3/README
index 3c15479..08da7e4 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/README
+++ b/arch/arm/cpu/armv8/fsl-lsch3/README
@@ -171,3 +171,74 @@ nand write u-boot image in memory 8 size of u-boot
image
Notice the difference from QDS is SRC, SRC_ADDR and the offset of u-boot image
to match board NAND device with 4KB/page, block size 512KB.
+
+MMU Translation Tables
+==
+
+(1) Early MMU Tables:
+
+ Level 0 Level 1 Level 2
+------
+| 0x00__ | - | 0x00__ | - | 0x00__ |
+------
+| 0x80__ | --|| 0x00_4000_ || 0x00_0020_ |
+-- |----
+|invalid | || 0x00_8000_ || 0x00_0040_ |
+-- |----
+ || 0x00_c000_ || 0x00_0060_ |
+ |----
+ || 0x01__ || 0x00_0080_ |
+ |----
+ |... ...
+ |--
+ || 0x05_8000_ | --|
+ |--|
+ || 0x05_c000_ ||
+ |--|
+ |... |
+ |--| --
+ |-- | 0x80__ ||- | 0x00_3000_ |
+ ----
+ | 0x80_4000_ || 0x00_3020_ |
+ ----
+ | 0x80_8000_ || 0x00_3040_ |
+ ----
+ | 0x80_c000_ || 0x00_3060_ |
+ ----
+ | 0x81__ || 0x00_3080_ |
+ ----
+... ...
+
+(2) Final MMU Tables:
+
+ Level 0
Re: [U-Boot] [PATCH 07/55] exynos: i2c: Correct bug in pinmux selection
Hi Simon, On 08/07/15 11:38, Simon Glass wrote: Hi Minkyu, On 6 July 2015 at 19:36, Minkyu Kang mk7.k...@samsung.com wrote: Dear Simon, On 07/07/15 00:27, Simon Glass wrote: Hi Minkyu, Przemyslaw, On 5 July 2015 at 00:15, Heiko Schocher h...@denx.de wrote: Hello Simon, Am 03.07.2015 um 02:15 schrieb Simon Glass: When driver model is not used the current code does not correctly select the pinmux for the I2C bus. This bug was introduced by this commit: 8dfcbaa dm: i2c: s3c24x0: adjust to dm-i2c api Signed-off-by: Simon Glass s...@chromium.org --- drivers/i2c/s3c24x0_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Heiko Schocher h...@denx.de As it is a bugfix, this should go in the current release ... right? Minkyu, are you able to pick this up please? If not I can do it. Only this patch? or all of samsung related patches? Yes only this patch. It has been confirmed my Przemyslaw now too. OK. then, do you want to take other patches to your tree? Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2][V2] pci: Add function to find an extended capability
PCIe extends device's configuration space to 4k and provides
extended capability. The patch adds function to find them.
The code is ported from Linux PCIe driver.
Signed-off-by: Minghuan Lian minghuan.l...@freescale.com
---
Change log:
v2-v1:
1. add a descriptor of pci_find_next_ext_capability
2. fix a typo
drivers/pci/pci.c | 53 +
include/pci.h | 41 +
2 files changed, 94 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 157491c..df50b48 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -526,3 +526,56 @@ int pci_find_cap(struct pci_controller *hose, pci_dev_t
dev, int pos, int cap)
}
return 0;
}
+
+/**
+ * pci_find_next_ext_capability - Find an extended capability
+ *
+ * Returns the address of the next matching extended capability structure
+ * within the device's PCI configuration space or 0 if the device does
+ * not support it. Some capabilities can occur several times, e.g., the
+ * vendor-specific capability, and this provides a way to find them all.
+ */
+int pci_find_next_ext_capability(struct pci_controller *hose, pci_dev_t dev,
+int start, int cap)
+{
+ u32 header;
+ int ttl, pos = PCI_CFG_SPACE_SIZE;
+
+ /* minimum 8 bytes per capability */
+ ttl = (PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) / 8;
+
+ if (start)
+ pos = start;
+
+ pci_hose_read_config_dword(hose, dev, pos, header);
+ if (header == 0x || header == 0)
+ return 0;
+
+ while (ttl-- 0) {
+ if (PCI_EXT_CAP_ID(header) == cap pos != start)
+ return pos;
+
+ pos = PCI_EXT_CAP_NEXT(header);
+ if (pos PCI_CFG_SPACE_SIZE)
+ break;
+
+ pci_hose_read_config_dword(hose, dev, pos, header);
+ if (header == 0x || header == 0)
+ break;
+ }
+
+ return 0;
+}
+
+/**
+ * pci_hose_find_ext_capability - Find an extended capability
+ *
+ * Returns the address of the requested extended capability structure
+ * within the device's PCI configuration space or 0 if the device does
+ * not support it.
+ */
+int pci_hose_find_ext_capability(struct pci_controller *hose, pci_dev_t dev,
+int cap)
+{
+ return pci_find_next_ext_capability(hose, dev, 0, cap);
+}
diff --git a/include/pci.h b/include/pci.h
index 07b1e9a..2f88714 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -11,6 +11,9 @@
#ifndef _PCI_H
#define _PCI_H
+#define PCI_CFG_SPACE_SIZE 256
+#define PCI_CFG_SPACE_EXP_SIZE 4096
+
/*
* Under PCI, each device has 256 bytes of configuration address space,
* of which the first 64 bytes are standardized as follows:
@@ -413,6 +416,39 @@
#define PCI_FIND_CAP_TTL 0x48
#define CAP_START_POS 0x40
+/* Extended Capabilities (PCI-X 2.0 and Express) */
+#define PCI_EXT_CAP_ID(header) (header 0x)
+#define PCI_EXT_CAP_VER(header)((header 16) 0xf)
+#define PCI_EXT_CAP_NEXT(header) ((header 20) 0xffc)
+
+#define PCI_EXT_CAP_ID_ERR 0x01/* Advanced Error Reporting */
+#define PCI_EXT_CAP_ID_VC 0x02/* Virtual Channel Capability */
+#define PCI_EXT_CAP_ID_DSN 0x03/* Device Serial Number */
+#define PCI_EXT_CAP_ID_PWR 0x04/* Power Budgeting */
+#define PCI_EXT_CAP_ID_RCLD0x05/* Root Complex Link Declaration */
+#define PCI_EXT_CAP_ID_RCILC 0x06/* Root Complex Internal Link Control */
+#define PCI_EXT_CAP_ID_RCEC0x07/* Root Complex Event Collector */
+#define PCI_EXT_CAP_ID_MFVC0x08/* Multi-Function VC Capability */
+#define PCI_EXT_CAP_ID_VC9 0x09/* same as _VC */
+#define PCI_EXT_CAP_ID_RCRB0x0A/* Root Complex RB? */
+#define PCI_EXT_CAP_ID_VNDR0x0B/* Vendor-Specific */
+#define PCI_EXT_CAP_ID_CAC 0x0C/* Config Access - obsolete */
+#define PCI_EXT_CAP_ID_ACS 0x0D/* Access Control Services */
+#define PCI_EXT_CAP_ID_ARI 0x0E/* Alternate Routing ID */
+#define PCI_EXT_CAP_ID_ATS 0x0F/* Address Translation Services */
+#define PCI_EXT_CAP_ID_SRIOV 0x10/* Single Root I/O Virtualization */
+#define PCI_EXT_CAP_ID_MRIOV 0x11/* Multi Root I/O Virtualization */
+#define PCI_EXT_CAP_ID_MCAST 0x12/* Multicast */
+#define PCI_EXT_CAP_ID_PRI 0x13/* Page Request Interface */
+#define PCI_EXT_CAP_ID_AMD_XXX 0x14/* Reserved for AMD */
+#define PCI_EXT_CAP_ID_REBAR 0x15/* Resizable BAR */
+#define PCI_EXT_CAP_ID_DPA 0x16/* Dynamic Power Allocation */
+#define PCI_EXT_CAP_ID_TPH 0x17/* TPH Requester */
+#define PCI_EXT_CAP_ID_LTR 0x18/* Latency Tolerance Reporting */
+#define PCI_EXT_CAP_ID_SECPCI 0x19/* Secondary PCIe Capability */
+#define PCI_EXT_CAP_ID_PMUX0x1A/* Protocol Multiplexing */
Re: [U-Boot] [PATCH] generic_board: Call checkboard even though the root node has a model property
On 7/10/2015 6:06 AM, Simon Glass wrote: Hi, On 9 July 2015 at 05:58, Haikun Wang haikun.w...@freescale.com wrote: Showing both: Model: Freescale Layerscape 2085a QDS Board Board: LS2085E-QDS, Board Arch: V1, Board version: B, boot from vBank: 4 This looks like duplication (at least the first part). Anyway I don't see any problem with this change. Hi Simon, The model information is hard-coded. Sometimes we need print run-time information of the board. We just want to print the version information and they are stored in the on-board FPGA registers on LS2085AQDS. Best regards, Wang Haikun Reviewed-by: Simon Glass s...@chromium.org Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/55] exynos: i2c: Correct bug in pinmux selection
Hi Minkyu, On 9 July 2015 at 19:43, Minkyu Kang mk7.k...@samsung.com wrote: Hi Simon, On 08/07/15 11:38, Simon Glass wrote: Hi Minkyu, On 6 July 2015 at 19:36, Minkyu Kang mk7.k...@samsung.com wrote: Dear Simon, On 07/07/15 00:27, Simon Glass wrote: Hi Minkyu, Przemyslaw, On 5 July 2015 at 00:15, Heiko Schocher h...@denx.de wrote: Hello Simon, Am 03.07.2015 um 02:15 schrieb Simon Glass: When driver model is not used the current code does not correctly select the pinmux for the I2C bus. This bug was introduced by this commit: 8dfcbaa dm: i2c: s3c24x0: adjust to dm-i2c api Signed-off-by: Simon Glass s...@chromium.org --- drivers/i2c/s3c24x0_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Heiko Schocher h...@denx.de As it is a bugfix, this should go in the current release ... right? Minkyu, are you able to pick this up please? If not I can do it. Only this patch? or all of samsung related patches? Yes only this patch. It has been confirmed my Przemyslaw now too. OK. then, do you want to take other patches to your tree? There are still dependencies on u-boot-dm, so I cannot yet. But if you like I can do that later, after I have merged some more driver model support patches. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] x86: Display correct CS/EIP/EFLAGS when there is an error code
Hi Simon,
On Fri, Jul 10, 2015 at 6:00 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 7 July 2015 at 23:17, Bin Meng bmeng...@gmail.com wrote:
Some exceptions cause an error code to be saved on the current stack
after the EIP value. We should extract CS/EIP/EFLAGS from different
position on the stack based on the exception number.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
arch/x86/cpu/interrupts.c | 29 -
arch/x86/include/asm/ptrace.h | 16 +---
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/arch/x86/cpu/interrupts.c b/arch/x86/cpu/interrupts.c
index c777d36..4a6c21f 100644
--- a/arch/x86/cpu/interrupts.c
+++ b/arch/x86/cpu/interrupts.c
@@ -34,12 +34,39 @@ DECLARE_GLOBAL_DATA_PTR;
static void dump_regs(struct irq_regs *regs)
{
+ unsigned long cs, eip, eflags;
unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
unsigned long d0, d1, d2, d3, d6, d7;
unsigned long sp;
+ /*
+* Some exceptions cause an error code to be saved on the current
stack
+* after the EIP value. We should extract CS/EIP/EFLAGS from
different
+* position on the stack based on the exception number.
+*/
+ switch (regs-irq_id) {
+ case 8:
+ case 10:
+ case 11:
+ case 12:
+ case 13:
+ case 14:
+ case 17:
Is there an enum for these values?
I don't find one. Will use enum in v2.
+ cs = regs-context.ctx2.xcs;
+ eip = regs-context.ctx2.eip;
+ eflags = regs-context.ctx2.eflags;
+ /* We should fix up the ESP due to error code */
+ regs-esp += 4;
+ break;
+ default:
+ cs = regs-context.ctx1.xcs;
+ eip = regs-context.ctx1.eip;
+ eflags = regs-context.ctx1.eflags;
+ break;
+ }
+
printf(EIP: %04x:[%08lx] EFLAGS: %08lx\n,
- (u16)regs-xcs, regs-eip, regs-eflags);
+ (u16)cs, eip, eflags);
printf(EAX: %08lx EBX: %08lx ECX: %08lx EDX: %08lx\n,
regs-eax, regs-ebx, regs-ecx, regs-edx);
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index a727dbf..3849bc0 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -63,9 +63,19 @@ struct irq_regs {
/* Pushed by vector handler (irq_num) */
long irq_id;
/* Pushed by cpu in response to interrupt */
- long eip;
- long xcs;
- long eflags;
+ union {
+ struct {
+ long eip;
+ long xcs;
+ long eflags;
+ } ctx1;
+ struct {
+ long err;
+ long eip;
+ long xcs;
+ long eflags;
+ } ctx2;
+ } context;
} __attribute__ ((packed));
/* Arbitrarily choose the same ptrace numbers as used by the Sparc code. */
--
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:fsl_esdhc invalidate dcache before read
Ping. Anyone review/apply this patch? On Thu, Jun 25, 2015 at 10:32:26AM +0800, Peng Fan wrote: DCIMVAC is upgraded to DCCIMVAC for the individual processor (Cortex-A7) that the DCIMVAC is executed on. We should follow the linux dma follow. Before DMA read, first invalidate dcache then after DMA read, invalidate dcache again. With the DMA direction DMA_FROM_DEVICE, the dcache need be invalidated again after the DMA completion. The reason is that we need explicity make sure the dcache been invalidated thus to get the DMA'ed memory correctly from the physical memory. Any cache-line fill during the DMA operations such as the pre-fetching can cause the DMA coherency issue, thus CPU get the stale data. Signed-off-by: Peng Fan peng@freescale.com Signed-off-by: Ye.Li b37...@freescale.com Signed-off-by: Nitin Garg nitin.g...@freescale.com Signed-off-by: Jason Liu r64...@freescale.com --- drivers/mmc/fsl_esdhc.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index c4719e6..0510bf0 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -341,6 +341,9 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data) err = esdhc_setup_data(mmc, data); if(err) return err; + + if (data-flags MMC_DATA_READ) + check_and_invalidate_dcache_range(cmd, data); } /* Figure out the transfer arguments */ @@ -437,6 +440,11 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data) } } while ((irqstat DATA_COMPLETE) != DATA_COMPLETE); + /* + * Need invalidate the dcache here again to avoid any + * cache-fill during the DMA operations such as the + * speculative pre-fetching etc. + */ if (data-flags MMC_DATA_READ) check_and_invalidate_dcache_range(cmd, data); #endif -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Regards, Peng. -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] x86: Simplify architecture defined exception handling in irq_llsr()
Instead of using switch..case for architecture defined exceptions,
simply unify the handling by printing a message of exception name,
followed by registers dump then halt the CPU.
With this unification, it also fixes the wrong exception numbers
for #MF/#AC/#MC/#XM which should be 16/17/18/19 not 15/16/17/18.
Signed-off-by: Bin Meng bmeng...@gmail.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in v2: None
arch/x86/cpu/interrupts.c | 151 ++
1 file changed, 46 insertions(+), 105 deletions(-)
diff --git a/arch/x86/cpu/interrupts.c b/arch/x86/cpu/interrupts.c
index 043a8d4..853c82f 100644
--- a/arch/x86/cpu/interrupts.c
+++ b/arch/x86/cpu/interrupts.c
@@ -32,6 +32,41 @@ DECLARE_GLOBAL_DATA_PTR;
pushl $#x\n \
jmp irq_common_entry\n
+static char *exceptions[] = {
+ Divide Error,
+ Debug,
+ NMI Interrupt,
+ Breakpoint,
+ Overflow,
+ BOUND Range Exceeded,
+ Invalid Opcode (Undefined Opcode),
+ Device Not Avaiable (No Math Coprocessor),
+ Double Fault,
+ Coprocessor Segment Overrun,
+ Invalid TSS,
+ Segment Not Present,
+ Stack Segment Fault,
+ Gerneral Protection,
+ Page Fault,
+ Reserved,
+ x87 FPU Floating-Point Error,
+ Alignment Check,
+ Machine Check,
+ SIMD Floating-Point Exception,
+ Virtualization Exception,
+ Reserved,
+ Reserved,
+ Reserved,
+ Reserved,
+ Reserved,
+ Reserved,
+ Reserved,
+ Reserved,
+ Reserved,
+ Reserved,
+ Reserved
+};
+
static void dump_regs(struct irq_regs *regs)
{
unsigned long cs, eip, eflags;
@@ -112,6 +147,13 @@ static void dump_regs(struct irq_regs *regs)
}
}
+static void do_exception(struct irq_regs *regs)
+{
+ printf(%s\n, exceptions[regs-irq_id]);
+ dump_regs(regs);
+ hang();
+}
+
struct idt_entry {
u16 base_low;
u16 selector;
@@ -228,111 +270,10 @@ void irq_llsr(struct irq_regs *regs)
* Order Number: 253665-029US, November 2008
* Table 6-1. Exceptions and Interrupts
*/
- switch (regs-irq_id) {
- case 0x00:
- printf(Divide Error (Division by zero)\n);
- dump_regs(regs);
- hang();
- break;
- case 0x01:
- printf(Debug Interrupt (Single step)\n);
- dump_regs(regs);
- break;
- case 0x02:
- printf(NMI Interrupt\n);
- dump_regs(regs);
- break;
- case 0x03:
- printf(Breakpoint\n);
- dump_regs(regs);
- break;
- case 0x04:
- printf(Overflow\n);
- dump_regs(regs);
- hang();
- break;
- case 0x05:
- printf(BOUND Range Exceeded\n);
- dump_regs(regs);
- hang();
- break;
- case 0x06:
- printf(Invalid Opcode (UnDefined Opcode)\n);
- dump_regs(regs);
- hang();
- break;
- case 0x07:
- printf(Device Not Available (No Math Coprocessor)\n);
- dump_regs(regs);
- hang();
- break;
- case 0x08:
- printf(Double fault\n);
- dump_regs(regs);
- hang();
- break;
- case 0x09:
- printf(Co-processor segment overrun\n);
- dump_regs(regs);
- hang();
- break;
- case 0x0a:
- printf(Invalid TSS\n);
- dump_regs(regs);
- break;
- case 0x0b:
- printf(Segment Not Present\n);
- dump_regs(regs);
- hang();
- break;
- case 0x0c:
- printf(Stack Segment Fault\n);
- dump_regs(regs);
- hang();
- break;
- case 0x0d:
- printf(General Protection\n);
- dump_regs(regs);
- break;
- case 0x0e:
- printf(Page fault\n);
- dump_regs(regs);
- hang();
- break;
- case 0x0f:
- printf(Floating-Point Error (Math Fault)\n);
- dump_regs(regs);
- break;
- case 0x10:
- printf(Alignment check\n);
- dump_regs(regs);
- break;
- case 0x11:
- printf(Machine Check\n);
- dump_regs(regs);
- break;
- case 0x12:
- printf(SIMD Floating-Point Exception\n);
- dump_regs(regs);
- break;
- case 0x13:
- case 0x14:
- case 0x15:
- case 0x16:
- case 0x17:
- case 0x18:
- case 0x19:
- case 0x1a:
- case 0x1b:
- case
[U-Boot] [PATCH v2 1/2] x86: Display correct CS/EIP/EFLAGS when there is an error code
Some exceptions cause an error code to be saved on the current stack
after the EIP value. We should extract CS/EIP/EFLAGS from different
position on the stack based on the exception number.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
Changes in v2:
- Use enum for x86 exception numbers
arch/x86/cpu/interrupts.c| 29 -
arch/x86/include/asm/interrupt.h | 24
arch/x86/include/asm/ptrace.h| 16 +---
3 files changed, 65 insertions(+), 4 deletions(-)
diff --git a/arch/x86/cpu/interrupts.c b/arch/x86/cpu/interrupts.c
index c777d36..043a8d4 100644
--- a/arch/x86/cpu/interrupts.c
+++ b/arch/x86/cpu/interrupts.c
@@ -34,12 +34,39 @@ DECLARE_GLOBAL_DATA_PTR;
static void dump_regs(struct irq_regs *regs)
{
+ unsigned long cs, eip, eflags;
unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
unsigned long d0, d1, d2, d3, d6, d7;
unsigned long sp;
+ /*
+* Some exceptions cause an error code to be saved on the current stack
+* after the EIP value. We should extract CS/EIP/EFLAGS from different
+* position on the stack based on the exception number.
+*/
+ switch (regs-irq_id) {
+ case EXC_DF:
+ case EXC_TS:
+ case EXC_NP:
+ case EXC_SS:
+ case EXC_GP:
+ case EXC_PF:
+ case EXC_AC:
+ cs = regs-context.ctx2.xcs;
+ eip = regs-context.ctx2.eip;
+ eflags = regs-context.ctx2.eflags;
+ /* We should fix up the ESP due to error code */
+ regs-esp += 4;
+ break;
+ default:
+ cs = regs-context.ctx1.xcs;
+ eip = regs-context.ctx1.eip;
+ eflags = regs-context.ctx1.eflags;
+ break;
+ }
+
printf(EIP: %04x:[%08lx] EFLAGS: %08lx\n,
- (u16)regs-xcs, regs-eip, regs-eflags);
+ (u16)cs, eip, eflags);
printf(EAX: %08lx EBX: %08lx ECX: %08lx EDX: %08lx\n,
regs-eax, regs-ebx, regs-ecx, regs-edx);
diff --git a/arch/x86/include/asm/interrupt.h b/arch/x86/include/asm/interrupt.h
index 0a75f89..6eef4f9 100644
--- a/arch/x86/include/asm/interrupt.h
+++ b/arch/x86/include/asm/interrupt.h
@@ -13,6 +13,30 @@
#include asm/types.h
+/* Architecture defined exceptions */
+enum x86_exception {
+ EXC_DE = 0,
+ EXC_DB,
+ EXC_NMI,
+ EXC_BP,
+ EXC_OF,
+ EXC_BR,
+ EXC_UD,
+ EXC_NM,
+ EXC_DF,
+ EXC_CSO,
+ EXC_TS,
+ EXC_NP,
+ EXC_SS,
+ EXC_GP,
+ EXC_PF,
+ EXC_MF = 16,
+ EXC_AC,
+ EXC_MC,
+ EXC_XM,
+ EXC_VE
+};
+
/* arch/x86/cpu/interrupts.c */
void set_vector(u8 intnum, void *routine);
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index a727dbf..3849bc0 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -63,9 +63,19 @@ struct irq_regs {
/* Pushed by vector handler (irq_num) */
long irq_id;
/* Pushed by cpu in response to interrupt */
- long eip;
- long xcs;
- long eflags;
+ union {
+ struct {
+ long eip;
+ long xcs;
+ long eflags;
+ } ctx1;
+ struct {
+ long err;
+ long eip;
+ long xcs;
+ long eflags;
+ } ctx2;
+ } context;
} __attribute__ ((packed));
/* Arbitrarily choose the same ptrace numbers as used by the Sparc code. */
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2][V2] pci/layerscape: Add EP mode support
The patch will initialize PCIe controller on EP mode
1. Setup bar:
bar0 32bit 4K for specific configuration
bar1 32bit 8K for MSIX
bar2 64bit 4K for descriptor of memory
bar4 64bit 1M for DMA memory test
2. Setup iATU:
iATU inbound 0-3 to map bar transaction to memory address
started at CONFIG_SYS_PCI_EP_MEMORY_BASE
iATU outbound 0 to map 4G memory space
Signed-off-by: Minghuan Lian minghuan.l...@freescale.com
---
Change log:
v2-v1: no change
drivers/pci/pcie_layerscape.c | 137 +-
1 file changed, 135 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 402c519..bf66225 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -24,6 +24,10 @@
#define CONFIG_SYS_PCI_MEMORY_SIZE (2 * 1024 * 1024 * 1024UL) /* 2G */
#endif
+#ifndef CONFIG_SYS_PCI_EP_MEMORY_BASE
+#define CONFIG_SYS_PCI_EP_MEMORY_BASE CONFIG_SYS_LOAD_ADDR
+#endif
+
/* iATU registers */
#define PCIE_ATU_VIEWPORT 0x900
#define PCIE_ATU_REGION_INBOUND(0x1 31)
@@ -40,6 +44,7 @@
#define PCIE_ATU_CR2 0x908
#define PCIE_ATU_ENABLE(0x1 31)
#define PCIE_ATU_BAR_MODE_ENABLE (0x1 30)
+#define PCIE_ATU_BAR_NUM(bar) ((bar) 8)
#define PCIE_ATU_LOWER_BASE0x90C
#define PCIE_ATU_UPPER_BASE0x910
#define PCIE_ATU_LIMIT 0x914
@@ -51,6 +56,7 @@
/* LUT registers */
#define PCIE_LUT_BASE 0x8
+#define PCIE_LUT_LCTRL00x7F8
#define PCIE_LUT_DBG 0x7FC
#define PCIE_DBI_RO_WR_EN 0x8bc
@@ -64,6 +70,25 @@
#define PCIE_DBI_SIZE 0x10 /* 1M */
+#define PCIE_LCTRL0_CFG2_ENABLE(1 31)
+#define PCIE_LCTRL0_VF(vf) ((vf) 22)
+#define PCIE_LCTRL0_PF(pf) ((pf) 16)
+#define PCIE_LCTRL0_VF_ACTIVE (1 21)
+#define PCIE_LCTRL0_VAL(pf, vf)(PCIE_LCTRL0_PF(pf) |
\
+PCIE_LCTRL0_VF(vf) | \
+((vf) == 0 ? 0 : PCIE_LCTRL0_VF_ACTIVE) | \
+PCIE_LCTRL0_CFG2_ENABLE)
+
+#define PCIE_NO_SRIOV_BAR_BASE 0x1000
+
+#define PCIE_PF_NUM2
+#define PCIE_VF_NUM64
+
+#define PCIE_BAR0_SIZE (4 * 1024) /* 4K */
+#define PCIE_BAR1_SIZE (8 * 1024) /* 8K for MSIX */
+#define PCIE_BAR2_SIZE (4 * 1024) /* 4K */
+#define PCIE_BAR4_SIZE (1 * 1024 * 1024) /* 1M */
+
struct ls_pcie {
int idx;
void __iomem *dbi;
@@ -75,6 +100,7 @@ struct ls_pcie {
struct ls_pcie_info {
unsigned long regs;
int pci_num;
+ u64 phys_base;
u64 cfg0_phys;
u64 cfg0_size;
u64 cfg1_phys;
@@ -90,6 +116,7 @@ struct ls_pcie_info {
#define SET_LS_PCIE_INFO(x, num) \
{ \
x.regs = CONFIG_SYS_PCIE##num##_ADDR; \
+ x.phys_base = CONFIG_SYS_PCIE##num##_PHYS_ADDR; \
x.cfg0_phys = CONFIG_SYS_PCIE_CFG0_PHYS_OFF + \
CONFIG_SYS_PCIE##num##_PHYS_ADDR; \
x.cfg0_size = CONFIG_SYS_PCIE_CFG0_SIZE;\
@@ -196,6 +223,18 @@ static void ls_pcie_iatu_outbound_set(struct ls_pcie
*pcie, int idx, int type,
writel(PCIE_ATU_ENABLE, pcie-dbi + PCIE_ATU_CR2);
}
+/* Use bar match mode and MEM type as default */
+static void ls_pcie_iatu_inbound_set(struct ls_pcie *pcie, int idx,
+int bar, u64 phys)
+{
+ writel(PCIE_ATU_REGION_INBOUND | idx, pcie-dbi + PCIE_ATU_VIEWPORT);
+ writel((u32)phys, pcie-dbi + PCIE_ATU_LOWER_TARGET);
+ writel(phys 32, pcie-dbi + PCIE_ATU_UPPER_TARGET);
+ writel(PCIE_ATU_TYPE_MEM, pcie-dbi + PCIE_ATU_CR1);
+ writel(PCIE_ATU_ENABLE | PCIE_ATU_BAR_MODE_ENABLE |
+ PCIE_ATU_BAR_NUM(bar), pcie-dbi + PCIE_ATU_CR2);
+}
+
static void ls_pcie_setup_atu(struct ls_pcie *pcie, struct ls_pcie_info *info)
{
#ifdef DEBUG
@@ -349,6 +388,97 @@ static void ls_pcie_setup_ctrl(struct ls_pcie *pcie,
#endif
}
+static void ls_pcie_ep_setup_atu(struct ls_pcie *pcie,
+struct ls_pcie_info *info)
+{
+ u64 phys = CONFIG_SYS_PCI_EP_MEMORY_BASE;
+
+ /* ATU 0 : INBOUND : map BAR0 */
+ ls_pcie_iatu_inbound_set(pcie, PCIE_ATU_REGION_INDEX0, 0, phys);
+ /* ATU 1 : INBOUND : map BAR1 */
+ phys += PCIE_BAR1_SIZE;
+ ls_pcie_iatu_inbound_set(pcie, PCIE_ATU_REGION_INDEX1, 1, phys);
+ /* ATU 2 : INBOUND : map BAR2 */
+ phys += PCIE_BAR2_SIZE;
+ ls_pcie_iatu_inbound_set(pcie, PCIE_ATU_REGION_INDEX2, 2, phys);
+ /* ATU 3 : INBOUND : map BAR4 */
+ phys = CONFIG_SYS_PCI_EP_MEMORY_BASE + PCIE_BAR4_SIZE;
+ ls_pcie_iatu_inbound_set(pcie, PCIE_ATU_REGION_INDEX3, 4, phys);
+
+ /* ATU 0 : OUTBOUND : map 4G MEM */
+
[U-Boot] [PATCH] x86: Adjust config option order in defconfig for Crown Bay and Minnowmax
Update crownbay_defconfig and minnowmax_defconfig with 'savedefconfig' result so that the config option order matches Kconfig. Signed-off-by: Bin Meng bmeng...@gmail.com --- configs/crownbay_defconfig | 8 configs/minnowmax_defconfig | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig index 379b881..17e6a72 100644 --- a/configs/crownbay_defconfig +++ b/configs/crownbay_defconfig @@ -4,7 +4,9 @@ CONFIG_DEFAULT_DEVICE_TREE=crownbay CONFIG_TARGET_CROWNBAY=y CONFIG_SMP=y CONFIG_MAX_CPUS=2 +CONFIG_HAVE_VGA_BIOS=y CONFIG_GENERATE_PIRQ_TABLE=y +CONFIG_GENERATE_MP_TABLE=y CONFIG_CMD_CPU=y # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set @@ -16,10 +18,8 @@ CONFIG_CMD_BOOTSTAGE=y CONFIG_OF_CONTROL=y CONFIG_CPU=y CONFIG_SPI_FLASH=y -CONFIG_USE_PRIVATE_LIBGCC=y -CONFIG_SYS_VSNPRINTF=y -CONFIG_HAVE_VGA_BIOS=y -CONFIG_GENERATE_MP_TABLE=y CONFIG_VIDEO_VESA=y CONFIG_FRAMEBUFFER_SET_VESA_MODE=y CONFIG_DM_RTC=y +CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_SYS_VSNPRINTF=y diff --git a/configs/minnowmax_defconfig b/configs/minnowmax_defconfig index 45f666c..29dd44b 100644 --- a/configs/minnowmax_defconfig +++ b/configs/minnowmax_defconfig @@ -3,8 +3,8 @@ CONFIG_VENDOR_INTEL=y CONFIG_DEFAULT_DEVICE_TREE=minnowmax CONFIG_TARGET_MINNOWMAX=y CONFIG_HAVE_INTEL_ME=y -CONFIG_HAVE_VGA_BIOS=y CONFIG_SMP=y +CONFIG_HAVE_VGA_BIOS=y CONFIG_GENERATE_SFI_TABLE=y CONFIG_CMD_CPU=y # CONFIG_CMD_IMLS is not set @@ -16,10 +16,10 @@ CONFIG_BOOTSTAGE_REPORT=y CONFIG_CMD_BOOTSTAGE=y CONFIG_OF_CONTROL=y CONFIG_CPU=y +CONFIG_DM_PCI=y CONFIG_SPI_FLASH=y CONFIG_VIDEO_VESA=y CONFIG_FRAMEBUFFER_SET_VESA_MODE=y CONFIG_FRAMEBUFFER_VESA_MODE_11A=y CONFIG_USE_PRIVATE_LIBGCC=y CONFIG_SYS_VSNPRINTF=y -CONFIG_DM_PCI=y -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] ahci: Fix compiling warnings under 64bit platforms
Thanks for pointing out. Fixed in patch v3. Regards, Yuantian -Original Message- From: Tom Rini [mailto:tr...@konsulko.com] Sent: Thursday, July 09, 2015 9:48 AM To: Tang Yuantian-B29983 Cc: Xie Shaohui-B21989; u-boot@lists.denx.de Subject: Re: [U-Boot,v2] ahci: Fix compiling warnings under 64bit platforms On Tue, Jul 07, 2015 at 03:48:26PM +0800, tang yuantian wrote: From: Tang Yuantian yuantian.t...@freescale.com When compling under 64bit platforms, there are lots of warnings, like: drivers/block/ahci.c:114:18: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] u8 *port_mmio = (u8 *)probe_ent-port[port].port_mmio; ^ drivers/block/ahci.c: In function ?.hci_host_init?. drivers/block/ahci.c:218:49: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] probe_ent-port[i].port_mmio = ahci_port_base((u32) mmio, i); .. Signed-off-by: Shaohui Xie shaohui@freescale.com Signed-off-by: Tang Yuantian yuantian.t...@freescale.com --- This introduces a warning with ELDK 5.5 on nitrogen6q,novena,ot1200_spl,nitrogen6q2g,m53evk,mx6qsabrelite,udoo_q uad,ima3-mx53,tb s2910,cm_fx6,ot1200,gwventana,mx53loco: ../drivers/block/dwc_ahsata.c:169:32: warning: assignment makes pointer from integer without a cast [enabled by default] ../drivers/block/dwc_ahsata.c: In function 'ahci_port_start': ../drivers/block/dwc_ahsata.c:523:2: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'ulong' [-Wformat=] -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] ahci: Fix compiling warnings under 64bit platforms
From: Tang Yuantian yuantian.t...@freescale.com
When compling under 64bit platforms, there are lots of warnings,
like:
drivers/block/ahci.c:114:18: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
u8 *port_mmio = (u8 *)probe_ent-port[port].port_mmio;
^
drivers/block/ahci.c: In function ?.hci_host_init?.
drivers/block/ahci.c:218:49: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
probe_ent-port[i].port_mmio = ahci_port_base((u32) mmio, i);
..
Signed-off-by: Shaohui Xie shaohui@freescale.com
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
v3:
- fix warnings this patch caused on drivers/block/dwc_ahsata.c
- take case of tbl_addr_hi when work under 64bit mode
v2:
- refined some type casts
drivers/block/ahci.c | 64 +-
drivers/block/dwc_ahsata.c | 13 ++
include/ahci.h | 8 +++---
3 files changed, 47 insertions(+), 38 deletions(-)
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 4fb846a..a57f674 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -43,13 +43,13 @@ u16 *ataid[AHCI_MAX_PORTS];
#define WAIT_MS_FLUSH 5000
#define WAIT_MS_LINKUP 200
-static inline u32 ahci_port_base(u32 base, u32 port)
+static inline void __iomem *ahci_port_base(void __iomem *base, u32 port)
{
return base + 0x100 + (port * 0x80);
}
-static void ahci_setup_port(struct ahci_ioports *port, unsigned long base,
+static void ahci_setup_port(struct ahci_ioports *port, void __iomem *base,
unsigned int port_idx)
{
base = ahci_port_base(base, port_idx);
@@ -61,7 +61,7 @@ static void ahci_setup_port(struct ahci_ioports *port,
unsigned long base,
#define msleep(a) udelay(a * 1000)
-static void ahci_dcache_flush_range(unsigned begin, unsigned len)
+static void ahci_dcache_flush_range(unsigned long begin, unsigned long len)
{
const unsigned long start = begin;
const unsigned long end = start + len;
@@ -75,7 +75,7 @@ static void ahci_dcache_flush_range(unsigned begin, unsigned
len)
* controller is invalidated from dcache; next access comes from
* physical RAM.
*/
-static void ahci_dcache_invalidate_range(unsigned begin, unsigned len)
+static void ahci_dcache_invalidate_range(unsigned long begin, unsigned long
len)
{
const unsigned long start = begin;
const unsigned long end = start + len;
@@ -94,7 +94,7 @@ static void ahci_dcache_flush_sata_cmd(struct ahci_ioports
*pp)
AHCI_PORT_PRIV_DMA_SZ);
}
-static int waiting_for_cmd_completed(volatile u8 *offset,
+static int waiting_for_cmd_completed(void __iomem *offset,
int timeout_msec,
u32 sign)
{
@@ -111,7 +111,7 @@ int __weak ahci_link_up(struct ahci_probe_ent *probe_ent,
u8 port)
{
u32 tmp;
int j = 0;
- u8 *port_mmio = (u8 *)probe_ent-port[port].port_mmio;
+ void __iomem *port_mmio = probe_ent-port[port].port_mmio;
/*
* Bring up SATA link.
@@ -131,7 +131,7 @@ int __weak ahci_link_up(struct ahci_probe_ent *probe_ent,
u8 port)
#ifdef CONFIG_SUNXI_AHCI
/* The sunxi AHCI controller requires this undocumented setup */
-static void sunxi_dma_init(volatile u8 *port_mmio)
+static void sunxi_dma_init(void __iomem *port_mmio)
{
clrsetbits_le32(port_mmio + PORT_P0DMACR, 0xff00, 0x4400);
}
@@ -171,10 +171,10 @@ static int ahci_host_init(struct ahci_probe_ent
*probe_ent)
u16 tmp16;
unsigned short vendor;
#endif
- volatile u8 *mmio = (volatile u8 *)probe_ent-mmio_base;
+ void __iomem *mmio = probe_ent-mmio_base;
u32 tmp, cap_save, cmd;
int i, j, ret;
- volatile u8 *port_mmio;
+ void __iomem *port_mmio;
u32 port_map;
debug(ahci_host_init: start\n);
@@ -215,9 +215,9 @@ static int ahci_host_init(struct ahci_probe_ent *probe_ent)
for (i = 0; i probe_ent-n_ports; i++) {
if (!(port_map (1 i)))
continue;
- probe_ent-port[i].port_mmio = ahci_port_base((u32) mmio, i);
+ probe_ent-port[i].port_mmio = ahci_port_base(mmio, i);
port_mmio = (u8 *) probe_ent-port[i].port_mmio;
- ahci_setup_port(probe_ent-port[i], (unsigned long)mmio, i);
+ ahci_setup_port(probe_ent-port[i], mmio, i);
/* make sure port is not active */
tmp = readl(port_mmio + PORT_CMD);
@@ -329,7 +329,7 @@ static void ahci_print_info(struct ahci_probe_ent
*probe_ent)
pci_dev_t pdev = probe_ent-dev;
u16 cc;
#endif
- volatile u8 *mmio = (volatile u8 *)probe_ent-mmio_base;
+ void __iomem *mmio = probe_ent-mmio_base;
u32 vers, cap, cap2, impl, speed;
const char *speed_s;
const char
Re: [U-Boot] [PATCH 08/11] spi: ti_qspi: Use DMA to read from qspi flash
On 07/03/2015 05:12 PM, Tom Rini wrote:
On Fri, Jul 03, 2015 at 04:46:10PM +0530, Vignesh R wrote:
ti_qspi uses memory map mode for faster read. Enabling DMA will increase
read speed by 3x @48MHz on DRA74 EVM.
Signed-off-by: Vignesh R vigne...@ti.com
This ignores the feedback from
http://lists.denx.de/pipermail/u-boot/2014-July/183715.html where we
need to model the DMA changes on how it's done for mxs_spi.c
Is the following patch an acceptable solution?
8---
Move DMA related initialization code to helper function in ti-edma3
driver. Use this function for scheduling DMA transfer from ti_qspi driver.
diff --git a/arch/arm/include/asm/ti-common/ti-edma3.h
b/arch/arm/include/asm/ti-common/ti-edma3.h
index 5adc1dac0e65..6a7a321c1bdf 100644
--- a/arch/arm/include/asm/ti-common/ti-edma3.h
+++ b/arch/arm/include/asm/ti-common/ti-edma3.h
@@ -117,5 +117,7 @@ void edma3_set_src_addr(u32 base, int slot, u32 src);
void edma3_set_transfer_params(u32 base, int slot, int acnt,
int bcnt, int ccnt, u16 bcnt_rld,
enum edma3_sync_dimension sync_mode);
+void edma3_transfer(unsigned long edma3_base_addr, unsigned int
+ edma_slot_num, void *dst, void *src, size_t len);
#endif
diff --git a/drivers/dma/ti-edma3.c b/drivers/dma/ti-edma3.c
index 8184ded9fa81..d6a427f2e21d 100644
--- a/drivers/dma/ti-edma3.c
+++ b/drivers/dma/ti-edma3.c
@@ -382,3 +382,81 @@ void qedma3_stop(u32 base, struct
edma3_channel_config *cfg)
/* Clear the channel map */
__raw_writel(0, base + EDMA3_QCHMAP(cfg-chnum));
}
+
+void edma3_transfer(unsigned long edma3_base_addr, unsigned int
+ edma_slot_num, void *dst, void *src, size_t len)
+{
+ struct edma3_slot_configslot;
+ struct edma3_channel_config edma_channel;
+ int b_cnt_value = 1;
+ int rem_bytes = 0;
+ int a_cnt_value = len;
+ unsigned intaddr = (unsigned int) (dst);
+ unsigned intmax_acnt = 0x7FFFU;
+
+ if (len max_acnt) {
+ b_cnt_value = (len / max_acnt);
+ rem_bytes = (len % max_acnt);
+ a_cnt_value = max_acnt;
+ }
+
+ slot.opt= 0;
+ slot.src= ((unsigned int) src);
+ slot.acnt = a_cnt_value;
+ slot.bcnt = b_cnt_value;
+ slot.ccnt = 1;
+ slot.src_bidx = a_cnt_value;
+ slot.dst_bidx = a_cnt_value;
+ slot.src_cidx = 0;
+ slot.dst_cidx = 0;
+ slot.link = EDMA3_PARSET_NULL_LINK;
+ slot.bcntrld= 0;
+ slot.opt= EDMA3_SLOPT_TRANS_COMP_INT_ENB |
+ EDMA3_SLOPT_COMP_CODE(0) |
+ EDMA3_SLOPT_STATIC | EDMA3_SLOPT_AB_SYNC;
+
+ edma3_slot_configure(edma3_base_addr, edma_slot_num, slot);
+ edma_channel.slot = edma_slot_num;
+ edma_channel.chnum = 0;
+ edma_channel.complete_code = 0;
+/* set event trigger to dst update */
+ edma_channel.trigger_slot_word = EDMA3_TWORD(dst);
+
+ qedma3_start(edma3_base_addr, edma_channel);
+ edma3_set_dest_addr(edma3_base_addr, edma_channel.slot, addr);
+
+ while (edma3_check_for_transfer(edma3_base_addr, edma_channel))
+ ;
+ qedma3_stop(edma3_base_addr, edma_channel);
+
+ if (rem_bytes != 0) {
+ slot.opt= 0;
+ slot.src=
+ (b_cnt_value * max_acnt) + ((unsigned int) src);
+ slot.acnt = rem_bytes;
+ slot.bcnt = 1;
+ slot.ccnt = 1;
+ slot.src_bidx = rem_bytes;
+ slot.dst_bidx = rem_bytes;
+ slot.src_cidx = 0;
+ slot.dst_cidx = 0;
+ slot.link = EDMA3_PARSET_NULL_LINK;
+ slot.bcntrld= 0;
+ slot.opt= EDMA3_SLOPT_TRANS_COMP_INT_ENB |
+ EDMA3_SLOPT_COMP_CODE(0) |
+ EDMA3_SLOPT_STATIC | EDMA3_SLOPT_AB_SYNC;
+ edma3_slot_configure(edma3_base_addr, edma_slot_num, slot);
+ edma_channel.slot = edma_slot_num;
+ edma_channel.chnum = 0;
+ edma_channel.complete_code = 0;
+ /* set event trigger to dst update */
+ edma_channel.trigger_slot_word = EDMA3_TWORD(dst);
+
+ qedma3_start(edma3_base_addr, edma_channel);
+ edma3_set_dest_addr(edma3_base_addr, edma_channel.slot, addr +
+ (max_acnt * b_cnt_value));
+ while (edma3_check_for_transfer(edma3_base_addr, edma_channel))
+ ;
+ qedma3_stop(edma3_base_addr, edma_channel);
+
Re: [U-Boot] [PATCH v2 7/8] mtd/nand/ubi: assortment of alignment fixes
Hi Scott On Wed, 2015-07-08 at 18:25 -0500, Scott Wood wrote: As per discussion on v1, this isn't enough to guarantee that the stop address will be aligned. There needs to be a wrapper around memalign() that cache- aligns the size as well. -Scott Sorry, that isn't quite clear to me yet. You're saying I would need to handle that in this patch? Looking through the sources I actually found only one single usage of memalign() which explicitly takes care of this the way you propose: drivers/usb/host/xhci-mem.c:ptr = memalign(cacheline_size, ALIGN(size, cacheline_size)); I'm just wondering about the 107 other places in U-Boot where memalign() is already used the way I do in this patch. Wouldn't there need to be an infrastructure solution done to e.g. memalign() itself? Cheers Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
On Friday 03 July 2015 01:23 AM, Paul Kocialkowski wrote: Le jeudi 02 juillet 2015 à 15:10 -0400, Tom Rini a écrit : On Thu, Jul 02, 2015 at 12:19:41AM +0200, Paul Kocialkowski wrote: OMAP devices might boot from peripheral devices, such as UART or USB. When that happens, the U-Boot SPL tries to boot the next stage (complete U-Boot) from that peripheral device, but in most cases, this is not a valid boot device. This introduces a fallback option that reads the SYS_BOOT pins, that are used by the bootrom to determine which device to boot from. It is intended for the SYS_BOOT value to be interpreted in the memory-preferred scheme, so that the U-Boot SPL can load the next stage from a valid location. Practically, this options allows loading the U-Boot SPL through USB and have it load the next stage according to the memory device selected by SYS_BOOT instead of stalling. Can you elaborate on this more please? The normal flow is that you load SPL via UART and then load U-Boot via UART, or SPL via USB RNDIS and then U-Boot via USB RNDIS. It sounds like you're changing things so that you load first via UART and then via say SD (or whatever the pins would be set for) unless you have the bits enabled for loading the next stage via that peripheral, which is the default case. Well to be honest, I haven't tried loading the main U-Boot binary via the USB ethernet gaget, after loading the U-Boot SPL via USB with the omap bootrom. Perhaps this would have worked just as well, but it isn't enabled for the OMAP3 and I thought it would be easier to just load from e.g. the MMC. No, this is not the normal convention. Since you are able to load SPL via USB ethernet gadget, you should be able to load u-boot also. USB ethernet gadget should be enabled in SPL. Now, I know you didn't do this just for fun, so what's the use case you have here exactly? Thanks! My use case is a bit specific: the device I have only has UART Tx available (so I cannot send anything) and USB available. Hence, I needed a way to load the main U-Boot binary from a place I could easily reflash (the external sdcard in my case). Do you think it would be worth adding support for USB ethernet on omap platforms? By the way, this patch set doesn't conflict with anything, and could still be there as a fallback when CONFIG_SPL_USBETH_SUPPORT is not defined. Even though it does not conflict, this is not how omap platforms are being done. SPL and u-boot are always loaded via the same boot device. I would really not recommend this patch. Thanks and regards, Lokesh That is, provided that I make my code check for BOOT_DEVICE_USBETH and not do anything if it is defined, so that we can have both BOOT_DEVICE_USBETH and BOOT_DEVICE_USB definitions (to the same value) and choose which one to use by defining CONFIG_SPL_USBETH_SUPPORT or not. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: tegra: enable GPU DT node when appropriate
T124 requires some specific configuration (VPR setup) to be performed by
the bootloader before the GPU can be used. For this reason, the GPU node
in the device tree is disabled by default. This patch enables the node
if U-boot has performed VPR configuration.
Boards enabled by this patch are T124's Jetson TK1 and Venice 2.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Tom Warren twar...@nvidia.com
---
arch/arm/include/asm/arch-tegra/gpu.h | 16
arch/arm/mach-tegra/gpu.c | 19 +++
board/nvidia/jetson-tk1/jetson-tk1.c | 8
board/nvidia/venice2/venice2.c| 8
include/configs/jetson-tk1.h | 2 ++
include/configs/venice2.h | 2 ++
6 files changed, 55 insertions(+)
diff --git a/arch/arm/include/asm/arch-tegra/gpu.h
b/arch/arm/include/asm/arch-tegra/gpu.h
index b347a21835f5..eac73ed5fddf 100644
--- a/arch/arm/include/asm/arch-tegra/gpu.h
+++ b/arch/arm/include/asm/arch-tegra/gpu.h
@@ -25,3 +25,19 @@ static inline bool gpu_configured(void)
}
#endif /* CONFIG_TEGRA_GPU */
+
+
+#if defined(CONFIG_OF_LIBFDT)
+
+int gpu_enable_node(void *blob, const char *gpupath);
+
+#else /* CONFIG_OF_LIBFDT */
+
+static inline int gpu_enable_node(void *blob, const char *gpupath)
+{
+ return 0;
+}
+
+#endif /* CONFIG_OF_LIBFDT */
+
+#endif
diff --git a/arch/arm/mach-tegra/gpu.c b/arch/arm/mach-tegra/gpu.c
index b2fa50b5400e..4ea046d3e5b6 100644
--- a/arch/arm/mach-tegra/gpu.c
+++ b/arch/arm/mach-tegra/gpu.c
@@ -45,3 +45,22 @@ bool vpr_configured(void)
{
return _configured;
}
+
+#if defined(CONFIG_OF_LIBFDT)
+
+int gpu_enable_node(void *blob, const char *gpupath)
+{
+ int offset;
+
+ if (vpr_configured()) {
+ offset = fdt_path_offset(blob, gpupath);
+ if (offset 0) {
+ fdt_status_okay(blob, offset);
+ debug(enabled GPU node %s\n, gpupath);
+ }
+ }
+
+ return 0;
+}
+
+#endif
diff --git a/board/nvidia/jetson-tk1/jetson-tk1.c
b/board/nvidia/jetson-tk1/jetson-tk1.c
index 52425a8f6dea..3c21767ce4da 100644
--- a/board/nvidia/jetson-tk1/jetson-tk1.c
+++ b/board/nvidia/jetson-tk1/jetson-tk1.c
@@ -11,6 +11,7 @@
#include asm/arch/gpio.h
#include asm/arch/pinmux.h
+#include asm/arch-tegra/gpu.h
#include pinmux-config-jetson-tk1.h
@@ -79,3 +80,10 @@ int board_eth_init(bd_t *bis)
return pci_eth_init(bis);
}
#endif /* PCI */
+
+int ft_board_setup(void *blob, bd_t *bd)
+{
+ gpu_enable_node(blob, /gpu@0,5700);
+
+ return 0;
+}
diff --git a/board/nvidia/venice2/venice2.c b/board/nvidia/venice2/venice2.c
index c56ef129d6c7..3e2b9a7745e9 100644
--- a/board/nvidia/venice2/venice2.c
+++ b/board/nvidia/venice2/venice2.c
@@ -8,6 +8,7 @@
#include common.h
#include asm/arch/gpio.h
#include asm/arch/pinmux.h
+#include asm/arch-tegra/gpu.h
#include pinmux-config-venice2.h
/*
@@ -27,3 +28,10 @@ void pinmux_init(void)
pinmux_config_drvgrp_table(venice2_drvgrps,
ARRAY_SIZE(venice2_drvgrps));
}
+
+int ft_board_setup(void *blob, bd_t *bd)
+{
+ gpu_enable_node(blob, /gpu@0,5700);
+
+ return 0;
+}
diff --git a/include/configs/jetson-tk1.h b/include/configs/jetson-tk1.h
index 3bbff282df27..b3e649664508 100644
--- a/include/configs/jetson-tk1.h
+++ b/include/configs/jetson-tk1.h
@@ -82,4 +82,6 @@
#define CONFIG_ARMV7_SECURE_BASE 0xfff0
#define CONFIG_ARMV7_SECURE_RESERVE_SIZE 0x0010
+#define CONFIG_OF_BOARD_SETUP
+
#endif /* __CONFIG_H */
diff --git a/include/configs/venice2.h b/include/configs/venice2.h
index 1d9d053b3566..bc5080aa27f0 100644
--- a/include/configs/venice2.h
+++ b/include/configs/venice2.h
@@ -64,4 +64,6 @@
#include tegra-common-usb-gadget.h
#include tegra-common-post.h
+#define CONFIG_OF_BOARD_SETUP
+
#endif /* __CONFIG_H */
--
2.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: tegra: move VPR configuration to a later stage
U-boot is responsible for enabling the GPU DT node after all necessary
configuration (VPR setup for T124) is performed. In order to be able to
check whether this configuration has been performed right before booting
the kernel, make it happen during board_init().
Also move VPR configuration into the more generic gpu.c file, which will
also host other GPU-related functions, and let boards specify
individually whether they need VPR setup or not.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Tom Warren twar...@nvidia.com
---
arch/arm/include/asm/arch-tegra/ap.h | 9 ---
arch/arm/include/asm/arch-tegra/gpu.h | 27
arch/arm/mach-tegra/Makefile | 2 +-
arch/arm/mach-tegra/ap.c | 3 ---
arch/arm/mach-tegra/board2.c | 3 +++
arch/arm/mach-tegra/gpu.c | 47 +++
arch/arm/mach-tegra/vpr.c | 35 --
include/configs/tegra124-common.h | 3 +++
8 files changed, 81 insertions(+), 48 deletions(-)
create mode 100644 arch/arm/include/asm/arch-tegra/gpu.h
create mode 100644 arch/arm/mach-tegra/gpu.c
delete mode 100644 arch/arm/mach-tegra/vpr.c
diff --git a/arch/arm/include/asm/arch-tegra/ap.h
b/arch/arm/include/asm/arch-tegra/ap.h
index ca40e4e0bce6..2d58271e39f9 100644
--- a/arch/arm/include/asm/arch-tegra/ap.h
+++ b/arch/arm/include/asm/arch-tegra/ap.h
@@ -66,15 +66,6 @@ int tegra_get_sku_info(void);
/* Do any chip-specific cache config */
void config_cache(void);
-#if defined(CONFIG_TEGRA124)
-/* Do chip-specific vpr config */
-void config_vpr(void);
-#else
-static inline void config_vpr(void)
-{
-}
-#endif
-
#if defined(CONFIG_TEGRA_SUPPORT_NON_SECURE)
bool tegra_cpu_is_non_secure(void);
#endif
diff --git a/arch/arm/include/asm/arch-tegra/gpu.h
b/arch/arm/include/asm/arch-tegra/gpu.h
new file mode 100644
index ..b347a21835f5
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra/gpu.h
@@ -0,0 +1,27 @@
+/*
+ * (C) Copyright 2015
+ * NVIDIA Corporation www.nvidia.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __ASM_ARCH_TEGRA_GPU_H
+#define __ASM_ARCH_TEGRA_GPU_H
+
+#if defined(CONFIG_TEGRA_GPU)
+
+void config_gpu(void);
+bool gpu_configured(void);
+
+#else /* CONFIG_TEGRA_GPU */
+
+static inline void config_gpu(void)
+{
+}
+
+static inline bool gpu_configured(void)
+{
+ return false;
+}
+
+#endif /* CONFIG_TEGRA_GPU */
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index fefc180b130e..f6f5583d6dd1 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -24,7 +24,7 @@ obj-y += pinmux-common.o
obj-y += powergate.o
obj-y += xusb-padctl.o
obj-$(CONFIG_DISPLAY_CPUINFO) += sys_info.o
-obj-$(CONFIG_TEGRA124) += vpr.o
+obj-$(CONFIG_TEGRA_GPU) += gpu.o
obj-$(CONFIG_TEGRA_CLOCK_SCALING) += emc.o
ifndef CONFIG_SPL_BUILD
diff --git a/arch/arm/mach-tegra/ap.c b/arch/arm/mach-tegra/ap.c
index 0b94e8aaf9c3..70613f9c3649 100644
--- a/arch/arm/mach-tegra/ap.c
+++ b/arch/arm/mach-tegra/ap.c
@@ -218,7 +218,4 @@ void s_init(void)
/* enable SMMU */
smmu_enable();
-
- /* init vpr */
- config_vpr();
}
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
index ce9b6959efb1..1d7c5eff5587 100644
--- a/arch/arm/mach-tegra/board2.c
+++ b/arch/arm/mach-tegra/board2.c
@@ -29,6 +29,7 @@
#include asm/arch-tegra/sys_proto.h
#include asm/arch-tegra/uart.h
#include asm/arch-tegra/warmboot.h
+#include asm/arch-tegra/gpu.h
#ifdef CONFIG_TEGRA_CLOCK_SCALING
#include asm/arch/emc.h
#endif
@@ -125,6 +126,8 @@ int board_init(void)
clock_init();
clock_verify();
+ config_gpu();
+
#ifdef CONFIG_TEGRA_SPI
pin_mux_spi();
#endif
diff --git a/arch/arm/mach-tegra/gpu.c b/arch/arm/mach-tegra/gpu.c
new file mode 100644
index ..b2fa50b5400e
--- /dev/null
+++ b/arch/arm/mach-tegra/gpu.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright (c) 2014-2015, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+/* Tegra vpr routines */
+
+#include common.h
+#include asm/io.h
+#include asm/arch/tegra.h
+#include asm/arch/mc.h
+
+#include fdt_support.h
+
+static bool _configured;
+
+void config_gpu(void)
+{
+ struct mc_ctlr *mc = (struct mc_ctlr *)NV_PA_MC_BASE;
+
+ /* Turn VPR off */
+
[U-Boot] [PATCH 0/2] ARM: tegra: enable GPU DT node
Tegra124 requires the bootloader to perform VPR initialization, otherwise the GPU cannot be used by the system. Since using the GPU without that initialization results in a hang, the GPU DT node is left disabled, and it is the task of the bootloader to enable it after ensuring it is safe to use the GPU. VPR init is already performed since patch df3443dfa449, but the device tree was left untouched. This patch series performs this last step and prepares the GPU intialization code to receive more code for newer chips. Patch 1 of this series moves the GPU initialization code to a more generic place, since newer chips like T210 require extra steps to initialize the GPU (e.g. WPR setup). It also performs VPR initialization at a later time of the bootloader life, so that we can check the status variable right before booting the kernel and patch the DT accordingly. Patch 2 performs the DT patching using the ft_board_setup() hook. Alexandre Courbot (2): ARM: tegra: move VPR configuration to a later stage ARM: tegra: enable GPU DT node when appropriate arch/arm/include/asm/arch-tegra/ap.h | 9 - arch/arm/include/asm/arch-tegra/gpu.h | 43 +++ arch/arm/mach-tegra/Makefile | 2 +- arch/arm/mach-tegra/ap.c | 3 -- arch/arm/mach-tegra/board2.c | 3 ++ arch/arm/mach-tegra/gpu.c | 66 +++ arch/arm/mach-tegra/vpr.c | 35 --- board/nvidia/jetson-tk1/jetson-tk1.c | 8 + board/nvidia/venice2/venice2.c| 8 + include/configs/jetson-tk1.h | 2 ++ include/configs/tegra124-common.h | 3 ++ include/configs/venice2.h | 2 ++ 12 files changed, 136 insertions(+), 48 deletions(-) create mode 100644 arch/arm/include/asm/arch-tegra/gpu.h create mode 100644 arch/arm/mach-tegra/gpu.c delete mode 100644 arch/arm/mach-tegra/vpr.c -- 2.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
Le jeudi 09 juillet 2015 à 13:29 +0530, Lokesh Vutla a écrit : On Friday 03 July 2015 01:23 AM, Paul Kocialkowski wrote: Le jeudi 02 juillet 2015 à 15:10 -0400, Tom Rini a écrit : On Thu, Jul 02, 2015 at 12:19:41AM +0200, Paul Kocialkowski wrote: OMAP devices might boot from peripheral devices, such as UART or USB. When that happens, the U-Boot SPL tries to boot the next stage (complete U-Boot) from that peripheral device, but in most cases, this is not a valid boot device. This introduces a fallback option that reads the SYS_BOOT pins, that are used by the bootrom to determine which device to boot from. It is intended for the SYS_BOOT value to be interpreted in the memory-preferred scheme, so that the U-Boot SPL can load the next stage from a valid location. Practically, this options allows loading the U-Boot SPL through USB and have it load the next stage according to the memory device selected by SYS_BOOT instead of stalling. Can you elaborate on this more please? The normal flow is that you load SPL via UART and then load U-Boot via UART, or SPL via USB RNDIS and then U-Boot via USB RNDIS. It sounds like you're changing things so that you load first via UART and then via say SD (or whatever the pins would be set for) unless you have the bits enabled for loading the next stage via that peripheral, which is the default case. Well to be honest, I haven't tried loading the main U-Boot binary via the USB ethernet gaget, after loading the U-Boot SPL via USB with the omap bootrom. Perhaps this would have worked just as well, but it isn't enabled for the OMAP3 and I thought it would be easier to just load from e.g. the MMC. No, this is not the normal convention. Since you are able to load SPL via USB ethernet gadget, The bootrom is not making any USB ethernet gadget available, it's using its own USB bulk protocol that is defined on the TRM. But I reckon it's USB booting either way. you should be able to load u-boot also. USB ethernet gadget should be enabled in SPL. I'm not saying it should not. This would be a useful feature and loading both parts via USB makes sense. Now, I know you didn't do this just for fun, so what's the use case you have here exactly? Thanks! My use case is a bit specific: the device I have only has UART Tx available (so I cannot send anything) and USB available. Hence, I needed a way to load the main U-Boot binary from a place I could easily reflash (the external sdcard in my case). Do you think it would be worth adding support for USB ethernet on omap platforms? By the way, this patch set doesn't conflict with anything, and could still be there as a fallback when CONFIG_SPL_USBETH_SUPPORT is not defined. Even though it does not conflict, this is not how omap platforms are being done. SPL and u-boot are always loaded via the same boot device. I would really not recommend this patch. My patch simply adds a feature. Why does it matter if it's consistent or not with the way people at TI thought it should be used? Also, the behaviour my patch implements has nothing specific to the OMAP and is a fallback mechanism. It will only be used when the device has no other working boot method. Are you suggesting we should let the device hang in that case? I agree it could be useful to print some error message indicating that the fallback is being used, so that users know there is something wrong with the intended boot method. That is, provided that I make my code check for BOOT_DEVICE_USBETH and not do anything if it is defined, so that we can have both BOOT_DEVICE_USBETH and BOOT_DEVICE_USB definitions (to the same value) and choose which one to use by defining CONFIG_SPL_USBETH_SUPPORT or not. -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ 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] [PATCH] arm: baltos: change USB ports functions
Baltos has USB0 connected to a USB hub and thus is host-only. USB1 is connected to microUSB connector and thus should use OTG mode. Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com --- include/configs/baltos.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/baltos.h b/include/configs/baltos.h index fb7818a..cce5e4f 100644 --- a/include/configs/baltos.h +++ b/include/configs/baltos.h @@ -282,9 +282,9 @@ #define CONFIG_USB_GADGET_VBUS_DRAW2 #define CONFIG_MUSB_HOST #define CONFIG_AM335X_USB0 -#define CONFIG_AM335X_USB0_MODEMUSB_PERIPHERAL +#define CONFIG_AM335X_USB0_MODEMUSB_HOST #define CONFIG_AM335X_USB1 -#define CONFIG_AM335X_USB1_MODE MUSB_HOST +#define CONFIG_AM335X_USB1_MODE MUSB_OTG #ifdef CONFIG_MUSB_HOST #define CONFIG_CMD_USB -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] generic_board: Call checkboard even though the root node has a model property
In case of enable CONFIG_OF_CONTROL and has a model property in the root node,
the board special checkboard will not be called.
Usually we show some useful version information in the function.
This patch enable call checkboard in any case.
It is not conflicting with showing model at the same time.
For example on LS2085AQDS:
Showing model only:
Model: Freescale Layerscape 2085a QDS Board
Showing checkboard only:
Board: LS2085E-QDS, Board Arch: V1, Board version: B, boot from vBank: 4
Showing both:
Model: Freescale Layerscape 2085a QDS Board
Board: LS2085E-QDS, Board Arch: V1, Board version: B, boot from vBank: 4
Signed-off-by: Haikun Wang haikun.w...@freescale.com
---
common/board_info.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/common/board_info.c b/common/board_info.c
index 42d0641..4e5a1f7 100644
--- a/common/board_info.c
+++ b/common/board_info.c
@@ -14,8 +14,7 @@ int __weak checkboard(void)
/*
* If the root node of the DTB has a model property, show it.
- * If CONFIG_OF_CONTROL is disabled or the model property is missing,
- * fall back to checkboard().
+ * Then call checkboard().
*/
int show_board_info(void)
{
@@ -25,10 +24,8 @@ int show_board_info(void)
model = fdt_getprop(gd-fdt_blob, 0, model, NULL);
- if (model) {
+ if (model)
printf(Model: %s\n, model);
- return 0;
- }
#endif
return checkboard();
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dm: do not set DM_FLAG_ACTIVATED twice
Currently, DM_FLAG_ACTIVATED is set twice; before calling
uclass_pre_probe_device() and again before calling drv-probe().
It looks like Simon's intention is the first one.
The DM_FLAG_ACTIVATED was moved twice, by commit 02eeb1bbb174
(dm: core: Mark device as active before calling its probe()
method), and then by commit 206d4d2b4b30 (dm: core: Mark device
as active before calling uclass probe() methods).
The first marking was added by the last move.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
---
drivers/core/device.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index e5291e2..e4097c9 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -264,7 +264,6 @@ int device_probe_child(struct udevice *dev, void
*parent_priv)
goto fail;
}
- dev-flags |= DM_FLAG_ACTIVATED;
if (drv-probe) {
ret = drv-probe(dev);
if (ret) {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/13] apalis/colibri_t20/t30: integrate recovery mode detection
On Wed, 2015-07-08 at 14:57 -0600, Stephen Warren wrote: But that's not what this patch does; it simply prints a message. It doesn't seem terribly useful. Agreed but I look at it more like a documented entry point. In our downstream U-Boot we use it to stop autoboot to allow for manual recovery handling of our BSP demo images but unfortunately that does not play that well with the tegra-uboot-flasher as it stands so I decided to just have that message printed for now. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] apalis/colibri_t20/t30: increase tftp blocksize
On Wed, 2015-07-08 at 15:03 -0600, Stephen Warren wrote: Do either of patches 12 and 13 make sense for all Tegra boards? In German we would call that a Gretchenfrage. BTW: I just noticed that somehow on T20 one can not quite use 16K as on the T30 (e.g. it fails with EHCI timed out on TD - token=0x88008d80). Wondering why that is but for now I will limit it to 1536 bytes in an upcoming v2 thereof. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 06/12] devres: introduce Devres (Managed Device Resource) framework
Hi, On 8 July 2015 at 23:41, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Masahiro, On Thu, 9 Jul 2015 14:16:33 +0900, Masahiro Yamada yamada.masah...@socionext.com wrote: Hi Simon, 3. How do we handle things like gpio_exynos_bind() which allocs some data and passes it to a device it creates, as platform data? At present we don't free it. So, currently this driver is leaking the memory, isn't it? If we use devm_kzalloc() here, the platdata for GPIOs will be released when the parent pinctrl is unbound. Does gpio_exynos_bind() get called enough between entry and exit from U-boot that the memory leaks prevent U-Boot from doing its job properly? No we only bind devices once in U-Boot, except for USB which recently changed. 4. There is a data size overhead to this which is not insignificant. As I read it we add 16 bytes to each memory allocation, which for most devices will amount to 32 or 48 bytes. Currently struct udevice is 84 bytes so increasing the overhead by 50% for no real improvement in functionality. This does matter in SPL in some cases. With all that said I think overall this is a good and useful change. I can see it saving hassle later. So, can we reduce the overhead / turn it off for SPL? Perhaps it could dissolve to nothing if CONFIG_DM_DEVICE_REMOVE is not defined? I think I can do this. devres.c can be built (and makes sense) only when CONFIG_DM_DEVICE_REMOVE is enabled. Agreed. In fact perhaps we need two options here - one that controls the inclusion of the remove() code and one that controls unbind(). As it happens I started yesterday on a change to check driver model pointers. I've been talking about it for a while but there are enough drivers out there that I think it is worth doing now. I hope to have something next week. However it doesn't look like it will interfere with your change much. BTW can we please have exported functions documented in the header file? IIRC, when we discussed this before, we could not reach agreement which should be documented, headers or sources. I know you prefer comments in headers, while I prefer in sources (like Linux). I can move them to dm/device.h if you think it is important to be consistent in the DM core portion. My .02EUR: I prefer comments in both, targeting different people. In .h files, for the benefit of users of the function, describe what it does, what its arguments mean and what its return value means. Yes, I like to see the file's API documented in the header so you can understand how to use it without reading through all the .c code. In .c files, for the benefit of maintainers (in a loose sense) of the function, describe how it does its job (if and where the code does not make it reasonably obvious). Sounds good. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: do not set DM_FLAG_ACTIVATED twice
On 9 July 2015 at 07:11, Masahiro Yamada yamada.masah...@socionext.com wrote: Currently, DM_FLAG_ACTIVATED is set twice; before calling uclass_pre_probe_device() and again before calling drv-probe(). It looks like Simon's intention is the first one. The DM_FLAG_ACTIVATED was moved twice, by commit 02eeb1bbb174 (dm: core: Mark device as active before calling its probe() method), and then by commit 206d4d2b4b30 (dm: core: Mark device as active before calling uclass probe() methods). The first marking was added by the last move. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- drivers/core/device.c | 1 - 1 file changed, 1 deletion(-) Acked-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 v3] ahci: Fix compiling warnings under 64bit platforms
Hi, On 9 July 2015 at 00:37, yuantian.t...@freescale.com wrote: From: Tang Yuantian yuantian.t...@freescale.com When compling under 64bit platforms, there are lots of warnings, like: drivers/block/ahci.c:114:18: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] u8 *port_mmio = (u8 *)probe_ent-port[port].port_mmio; ^ drivers/block/ahci.c: In function ?.hci_host_init?. drivers/block/ahci.c:218:49: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] probe_ent-port[i].port_mmio = ahci_port_base((u32) mmio, i); .. Signed-off-by: Shaohui Xie shaohui@freescale.com Signed-off-by: Tang Yuantian yuantian.t...@freescale.com --- v3: - fix warnings this patch caused on drivers/block/dwc_ahsata.c - take case of tbl_addr_hi when work under 64bit mode v2: - refined some type casts drivers/block/ahci.c | 64 +- drivers/block/dwc_ahsata.c | 13 ++ include/ahci.h | 8 +++--- 3 files changed, 47 insertions(+), 38 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] x86: Adjust config option order in defconfig for Crown Bay and Minnowmax
On 9 July 2015 at 04:37, Bin Meng bmeng...@gmail.com wrote: Update crownbay_defconfig and minnowmax_defconfig with 'savedefconfig' result so that the config option order matches Kconfig. Signed-off-by: Bin Meng bmeng...@gmail.com --- configs/crownbay_defconfig | 8 configs/minnowmax_defconfig | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] g_dnl: add missing declaration
Signed-off-by: Steve Rae s...@broadcom.com
---
Changes in v3: None
Changes in v2: None
include/g_dnl.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/g_dnl.h b/include/g_dnl.h
index 4eeb5e4..ba49f1f 100644
--- a/include/g_dnl.h
+++ b/include/g_dnl.h
@@ -34,6 +34,7 @@ struct g_dnl_bind_callback {
};
int g_dnl_bind_fixup(struct usb_device_descriptor *, const char *);
+int g_dnl_get_board_bcd_device_number(int gcnum);
int g_dnl_board_usb_cable_connected(void);
int g_dnl_register(const char *s);
void g_dnl_unregister(void);
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] usb: gadget: bcm_udc_otg files
From: Jiandong Zheng jdzh...@broadcom.com
Add the required files for the Broadcom UDC OTG interface.
Signed-off-by: Jiandong Zheng jdzh...@broadcom.com
Signed-off-by: Steve Rae s...@broadcom.com
---
Changes in v3:
- use static inline functions instead of macros
- update the delay (2ms) to match the kernel code
Changes in v2: None
arch/arm/include/asm/arch-bcm281xx/sysmap.h | 7
drivers/usb/gadget/bcm_udc_otg.h| 22 +
drivers/usb/gadget/bcm_udc_otg_phy.c| 51 +
3 files changed, 80 insertions(+)
create mode 100644 drivers/usb/gadget/bcm_udc_otg.h
create mode 100644 drivers/usb/gadget/bcm_udc_otg_phy.c
diff --git a/arch/arm/include/asm/arch-bcm281xx/sysmap.h
b/arch/arm/include/asm/arch-bcm281xx/sysmap.h
index 93ebf34..dbcc88c 100644
--- a/arch/arm/include/asm/arch-bcm281xx/sysmap.h
+++ b/arch/arm/include/asm/arch-bcm281xx/sysmap.h
@@ -27,4 +27,11 @@
#define SECWD2_BASE_ADDR 0x35002f40
#define TIMER_BASE_ADDR0x3e00d000
+#define HSOTG_DCTL_OFFSET 0x0804
+#defineHSOTG_DCTL_SFTDISCON_MASK 0x0002
+
+#define HSOTG_CTRL_PHY_P1CTL_OFFSET0x0008
+#defineHSOTG_CTRL_PHY_P1CTL_SOFT_RESET_MASK
0x0002
+#defineHSOTG_CTRL_PHY_P1CTL_NON_DRIVING_MASK 0x0001
+
#endif
diff --git a/drivers/usb/gadget/bcm_udc_otg.h b/drivers/usb/gadget/bcm_udc_otg.h
new file mode 100644
index 000..d47aefa
--- /dev/null
+++ b/drivers/usb/gadget/bcm_udc_otg.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2015 Broadcom Corporation.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __BCM_UDC_OTG_H
+#define __BCM_UDC_OTG_H
+
+#include common.h
+
+static inline void wfld_set(uintptr_t addr, uint32_t fld_val, uint32_t
fld_mask)
+{
+ writel(((readl(addr) ~(fld_mask)) | (fld_val)), (addr));
+}
+
+static inline void wfld_clear(uintptr_t addr, uint32_t fld_mask)
+{
+ writel((readl(addr) ~(fld_mask)), (addr));
+}
+
+#endif
diff --git a/drivers/usb/gadget/bcm_udc_otg_phy.c
b/drivers/usb/gadget/bcm_udc_otg_phy.c
new file mode 100644
index 000..f8690b0
--- /dev/null
+++ b/drivers/usb/gadget/bcm_udc_otg_phy.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright 2015 Broadcom Corporation.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include config.h
+#include common.h
+#include asm/io.h
+#include asm/arch/sysmap.h
+
+#include usb/s3c_udc.h
+#include bcm_udc_otg.h
+
+void otg_phy_init(struct s3c_udc *dev)
+{
+ /* set Phy to driving mode */
+ wfld_clear(HSOTG_CTRL_BASE_ADDR + HSOTG_CTRL_PHY_P1CTL_OFFSET,
+ HSOTG_CTRL_PHY_P1CTL_NON_DRIVING_MASK);
+
+ udelay(100);
+
+ /* clear Soft Disconnect */
+ wfld_clear(HSOTG_BASE_ADDR + HSOTG_DCTL_OFFSET,
+ HSOTG_DCTL_SFTDISCON_MASK);
+
+ /* invoke Reset (active low) */
+ wfld_clear(HSOTG_CTRL_BASE_ADDR + HSOTG_CTRL_PHY_P1CTL_OFFSET,
+ HSOTG_CTRL_PHY_P1CTL_SOFT_RESET_MASK);
+
+ /* Reset needs to be asserted for 2ms */
+ udelay(2000);
+
+ /* release Reset */
+ wfld_set(HSOTG_CTRL_BASE_ADDR + HSOTG_CTRL_PHY_P1CTL_OFFSET,
+HSOTG_CTRL_PHY_P1CTL_SOFT_RESET_MASK,
+HSOTG_CTRL_PHY_P1CTL_SOFT_RESET_MASK);
+}
+
+void otg_phy_off(struct s3c_udc *dev)
+{
+ /* Soft Disconnect */
+ wfld_set(HSOTG_BASE_ADDR + HSOTG_DCTL_OFFSET,
+HSOTG_DCTL_SFTDISCON_MASK,
+HSOTG_DCTL_SFTDISCON_MASK);
+
+ /* set Phy to non-driving (reset) mode */
+ wfld_set(HSOTG_CTRL_BASE_ADDR + HSOTG_CTRL_PHY_P1CTL_OFFSET,
+HSOTG_CTRL_PHY_P1CTL_NON_DRIVING_MASK,
+HSOTG_CTRL_PHY_P1CTL_NON_DRIVING_MASK);
+}
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/3] This series implements fastboot on the bcm28155_ap boards.
The OTG hardware is a DWC2 controller and this series uses the existing gadget driver (s3c_udc_otg.c). Changes in v3: - use static inline functions instead of macros - update the delay (2ms) to match the kernel code - use SZ_1M - undefine the 8-bit phy interface Changes in v2: - rebased against u-boot-dfu Jiandong Zheng and Steve Rae (2): usb: gadget: bcm_udc_otg files implement Fastboot via USB OTG on bcm28155_ap boards Steve Rae (1): g_dnl: add missing declaration arch/arm/include/asm/arch-bcm281xx/sysmap.h | 7 board/broadcom/bcm28155_ap/bcm28155_ap.c| 40 ++ drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/bcm_udc_otg.h| 22 + drivers/usb/gadget/bcm_udc_otg_phy.c| 51 + include/configs/bcm28155_ap.h | 20 +++ include/g_dnl.h | 1 + 7 files changed, 142 insertions(+) create mode 100644 drivers/usb/gadget/bcm_udc_otg.h create mode 100644 drivers/usb/gadget/bcm_udc_otg_phy.c -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] implement Fastboot via USB OTG on bcm28155_ap boards
From: Jiandong Zheng jdzh...@broadcom.com
Signed-off-by: Jiandong Zheng jdzh...@broadcom.com
Signed-off-by: Steve Rae s...@broadcom.com
---
Changes in v3:
- use SZ_1M
- undefine the 8-bit phy interface
Changes in v2:
- rebased against u-boot-dfu
board/broadcom/bcm28155_ap/bcm28155_ap.c | 40
drivers/usb/gadget/Makefile | 1 +
include/configs/bcm28155_ap.h| 20
3 files changed, 61 insertions(+)
diff --git a/board/broadcom/bcm28155_ap/bcm28155_ap.c
b/board/broadcom/bcm28155_ap/bcm28155_ap.c
index 940a1c2..20eb191 100644
--- a/board/broadcom/bcm28155_ap/bcm28155_ap.c
+++ b/board/broadcom/bcm28155_ap/bcm28155_ap.c
@@ -12,12 +12,20 @@
#include asm/kona-common/clk.h
#include asm/arch/sysmap.h
+#include usb.h
+#include usb/s3c_udc.h
+#include g_dnl.h
+
#define SECWATCHDOG_SDOGCR_OFFSET 0x
#define SECWATCHDOG_SDOGCR_EN_SHIFT27
#define SECWATCHDOG_SDOGCR_SRSTEN_SHIFT26
#define SECWATCHDOG_SDOGCR_CLKS_SHIFT 20
#define SECWATCHDOG_SDOGCR_LD_SHIFT0
+#ifndef CONFIG_USB_SERIALNO
+#define CONFIG_USB_SERIALNO 1234567890
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
/*
@@ -85,3 +93,35 @@ int board_mmc_init(bd_t *bis)
return ret;
}
#endif
+
+#ifdef CONFIG_USB_GADGET
+static struct s3c_plat_otg_data bcm_otg_data = {
+ .regs_otg = HSOTG_BASE_ADDR
+};
+
+int board_usb_init(int index, enum usb_init_type init)
+{
+ debug(%s: performing s3c_udc_probe\n, __func__);
+ return s3c_udc_probe(bcm_otg_data);
+}
+
+int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
+{
+ debug(%s\n, __func__);
+ if (!getenv(serial#))
+ g_dnl_set_serialnumber(CONFIG_USB_SERIALNO);
+ return 0;
+}
+
+int g_dnl_get_board_bcd_device_number(int gcnum)
+{
+ debug(%s\n, __func__);
+ return 1;
+}
+
+int board_usb_cleanup(int index, enum usb_init_type init)
+{
+ debug(%s\n, __func__);
+ return 0;
+}
+#endif
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 4e15323..4c11a7e 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_USB_ETHER) += epautoconf.o config.o usbstring.o
# new USB gadget layer dependencies
ifdef CONFIG_USB_GADGET
obj-$(CONFIG_USB_GADGET_ATMEL_USBA) += atmel_usba_udc.o
+obj-$(CONFIG_USB_GADGET_BCM_UDC_OTG_PHY) += bcm_udc_otg_phy.o
obj-$(CONFIG_USB_GADGET_S3C_UDC_OTG) += s3c_udc_otg.o
obj-$(CONFIG_USB_GADGET_S3C_UDC_OTG_PHY) += s3c_udc_otg_phy.o
obj-$(CONFIG_USB_GADGET_FOTG210) += fotg210.o
diff --git a/include/configs/bcm28155_ap.h b/include/configs/bcm28155_ap.h
index 900dc42..f023f27 100644
--- a/include/configs/bcm28155_ap.h
+++ b/include/configs/bcm28155_ap.h
@@ -109,6 +109,7 @@
* for example.
*/
#define CONFIG_DOS_PARTITION
+#define CONFIG_EFI_PARTITION
/* version string, parser, etc */
#define CONFIG_VERSION_VARIABLE
@@ -136,4 +137,23 @@
#undef CONFIG_CMD_NFS
+/* Fastboot and USB OTG */
+#define CONFIG_USB_FUNCTION_FASTBOOT
+#define CONFIG_CMD_FASTBOOT
+#define CONFIG_FASTBOOT_FLASH
+#define CONFIG_FASTBOOT_FLASH_MMC_DEV 0
+#define CONFIG_SYS_CACHELINE_SIZE 64
+#define CONFIG_USB_FASTBOOT_BUF_SIZE (CONFIG_SYS_SDRAM_SIZE - SZ_1M)
+#define CONFIG_USB_FASTBOOT_BUF_ADDR CONFIG_SYS_SDRAM_BASE
+#define CONFIG_USB_GADGET
+#define CONFIG_USB_GADGET_DUALSPEED
+#define CONFIG_USB_GADGET_VBUS_DRAW0
+#define CONFIG_USB_GADGET_S3C_UDC_OTG
+#define CONFIG_USB_GADGET_BCM_UDC_OTG_PHY
+#define CONFIG_USB_GADGET_DOWNLOAD
+#define CONFIG_USBID_ADDR 0x34052c46
+#define CONFIG_G_DNL_VENDOR_NUM0x18d1 /* google */
+#define CONFIG_G_DNL_PRODUCT_NUM 0x0d02 /* nexus one */
+#define CONFIG_G_DNL_MANUFACTURER Broadcom Corporation
+
#endif /* __BCM28155_AP_H */
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/54] dm: Introduce new driver model uclasses
Hi Jagan, On 9 July 2015 at 14:31, Jagan Teki jt...@openedev.com wrote: On 2 July 2015 at 12:33, Jagan Teki jt...@openedev.com wrote: On 1 July 2015 at 02:38, Simon Glass s...@chromium.org wrote: Hi Tom, On 30 June 2015 at 14:31, Tom Rini tr...@konsulko.com wrote: On Tue, Jun 30, 2015 at 01:10:45PM -0700, York Sun wrote: On 06/30/2015 12:01 PM, Tom Rini wrote: On Tue, Jun 30, 2015 at 11:42:41AM -0700, York Sun wrote: On 06/30/2015 11:33 AM, Simon Glass wrote: Hi York, On 30 June 2015 at 10:08, York Sun york...@freescale.com wrote: Simon, Does the dm force using device tree? I was reviewing a patch set regarding SPI and found OF_CONTROL has to be selected in order to get the driver model happy. My understanding of the driver model is both device tree and platform data are allowed, like Linux. Is that still true? For buses you need device tree. I was rather hoping that we could avoid platform data on platforms that have device tree. What is the point? Simon, It happens on a platform not using device tree, but DM will be used. I prefer DM to have both, rather than being forced to use device tree, unless we are going to enforce using device tree on all new platforms. Since device tree is still an option, I feel it is best to support platform data, like Linux drivers do. Well, to what end? My recollection is that in short, the kernel has both since platform data predates device tree (and converting platform data to device tree is still a thing that happens). But we're trying to skip that intermediate step. Are there platforms where you do not plan to use a device tree, ever? My observations with this approach (dm-spi) 1. We're planning to move spi driver with dm support but many of the boards which used spi drivers don't have dts support yet. 2. I think dm will progress only when dts support progresses. The only solution for this - if we need to move any driver to dm then check for dts on particular board this driver uses and move that board to have dts support. Any comments? Any suggestions? Yes, or maybe enable DTS for the board? It's not that hard. E.g. see this for Raspberry Pi: http://patchwork.ozlabs.org/patch/492694/ http://patchwork.ozlabs.org/patch/492698/ http://patchwork.ozlabs.org/patch/492700/ Tom, I am not against using device tree at all. It is more dynamic and flexible. But I don't see any indication that we favor device tree over pdata (except in the code). If we are skipping pdata for new drivers, a clear message will be helpful. That's what I am trying to get clarification. OK. I think we'd agreed to that at ELC-E last year and it might have been in a few here-and-there emails but it's worth spelling out somewhere. Hey Simon? doc/driver-model/README.txt has a pdata example, so maybe the answer here is it's time to update README.txt in a few ways :) I'll prepare a patch. thanks! -- Jagan | openedev. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/8] mtd/nand/ubi: assortment of alignment fixes
On Thu, 2015-07-09 at 09:47 +0200, Marcel Ziswiler wrote:
Hi Scott
On Wed, 2015-07-08 at 18:25 -0500, Scott Wood wrote:
As per discussion on v1, this isn't enough to guarantee that the stop
address
will be aligned. There needs to be a wrapper around memalign() that
cache-
aligns the size as well.
-Scott
Sorry, that isn't quite clear to me yet. You're saying I would need to
handle that in this patch?
Looking through the sources I actually found only one single usage of
memalign() which explicitly takes care of this the way you propose:
drivers/usb/host/xhci-mem.c: ptr = memalign(cacheline_size, ALIGN(size,
cacheline_size));
I'm just wondering about the 107 other places in U-Boot where memalign()
is already used the way I do in this patch.
I suppose there are enough existing ones that it won't hurt to add more --
it's still an improvement over the current situation -- but it'd be good to
fix it properly before it gets forgotten.
Wouldn't there need to be an infrastructure solution done to e.g.
memalign() itself?
No, just a wrapper:
static inline void *malloc_cache_aligned(size_t size)
{
return memalign(ARCH_DMA_MINALIGN, ALIGN(size, ARCH_DMA_MINALIGN));
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] hang: ARM64/Relocating u-boot from u-boot
Dear Jagan, In message cad6g_rskry4qcjdhz6gtowcwbdvyffwcwjd2x3k91uvxsff...@mail.gmail.com you wrote: On that note, I have tried the same by loading u-boot on external-RAM with TEXT_BASE and it ran very feasibly. the design is like the SOC has ROM with first stage bootloader and second stage is u-boot and external-RAM got initialized in first stage bootloader(not in u-boot). this design works fine? It may work (and very often does), but there are subtle things to keep in mind (like write-once registers) which are good for nasty surprises sometimes. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Have you lived in this village all your life?No, not yet. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/54] dm: Introduce new driver model uclasses
On 2 July 2015 at 12:33, Jagan Teki jt...@openedev.com wrote: On 1 July 2015 at 02:38, Simon Glass s...@chromium.org wrote: Hi Tom, On 30 June 2015 at 14:31, Tom Rini tr...@konsulko.com wrote: On Tue, Jun 30, 2015 at 01:10:45PM -0700, York Sun wrote: On 06/30/2015 12:01 PM, Tom Rini wrote: On Tue, Jun 30, 2015 at 11:42:41AM -0700, York Sun wrote: On 06/30/2015 11:33 AM, Simon Glass wrote: Hi York, On 30 June 2015 at 10:08, York Sun york...@freescale.com wrote: Simon, Does the dm force using device tree? I was reviewing a patch set regarding SPI and found OF_CONTROL has to be selected in order to get the driver model happy. My understanding of the driver model is both device tree and platform data are allowed, like Linux. Is that still true? For buses you need device tree. I was rather hoping that we could avoid platform data on platforms that have device tree. What is the point? Simon, It happens on a platform not using device tree, but DM will be used. I prefer DM to have both, rather than being forced to use device tree, unless we are going to enforce using device tree on all new platforms. Since device tree is still an option, I feel it is best to support platform data, like Linux drivers do. Well, to what end? My recollection is that in short, the kernel has both since platform data predates device tree (and converting platform data to device tree is still a thing that happens). But we're trying to skip that intermediate step. Are there platforms where you do not plan to use a device tree, ever? My observations with this approach (dm-spi) 1. We're planning to move spi driver with dm support but many of the boards which used spi drivers don't have dts support yet. 2. I think dm will progress only when dts support progresses. The only solution for this - if we need to move any driver to dm then check for dts on particular board this driver uses and move that board to have dts support. Any comments? Any suggestions? Tom, I am not against using device tree at all. It is more dynamic and flexible. But I don't see any indication that we favor device tree over pdata (except in the code). If we are skipping pdata for new drivers, a clear message will be helpful. That's what I am trying to get clarification. OK. I think we'd agreed to that at ELC-E last year and it might have been in a few here-and-there emails but it's worth spelling out somewhere. Hey Simon? doc/driver-model/README.txt has a pdata example, so maybe the answer here is it's time to update README.txt in a few ways :) I'll prepare a patch. thanks! -- Jagan | openedev. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] hang: ARM64/Relocating u-boot from u-boot
On 8 July 2015 at 12:16, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Wolfgang, On Wed, 08 Jul 2015 00:36:52 +0200, Wolfgang Denk w...@denx.de wrote: Dear Jagan, In message CAD6G_RQnrBWyPp1CyiDxkZ4vme4PB5fNHDX-f2Sf=9cvrod...@mail.gmail.com you wrote: I'm running u-boot from u-boot prompt, just like a standalone application with CONFIG_SYS_TEXT_BASE address. ... (note: the board here identifies itself as ARM64 Reference Board, which does not exist in the current U-Boot source code, so this is obviously a non-mainline(-yet?) port for which we could hardly give assistance anyway.) Has any one tried the same before, please let me know for any inputs? Actually this is even a FAQ: http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM If I may, this FAQ is slightly outdated, in that chainloading U-Boot is not only possible but actually made possible by design, at least for many ARM (and possibly some ARM64) targets, and I suspect for many non-ARM targets too, as long as they use SPL. First off: the FAQ is perfectly true if applied to running SPL from SPL. But you can easily run U-Boot from SPL -- that's actually the point of SPL in the first place -- and this is done, usually, by having SPL reset the hardware to the extent of getting external RAM working, and conversively having U-Boot reset the hardware in (OS) booting condition *except* for the external RAM part which U-Boot could not do anyway. IOW, on targets with SPL, U-Boot starts with the guarantee that all initializations needed for external RAM to work have been done, and it guarantees that it will not perform these external RAM inits again. And since an SPL-chainloaded U-Boot runs with external already initialized and does not initialize it again, it follows that this U-Boot is a valid environment for running another instance of itself, provided the new instance and current instances do not overwrite each other. And U-Boot relocates itself to the highest possible address, thereby freeing up its load address. Provided this load address was chosen low in external RAM, and provided the board has enough external RAM (which any board aiming to chainload a big Linux kernel from a smaller U-Boot should have), this allows loading U-Boot to its link-time address from a running U-Boot instance without any trashing of either instance. All of this makes it nont only perfectly possible for (SPL-run) U-Boot to chainload (SPL-run) U-Boot, it pretty much guarantees it. And while chainloading ans SPL-run U-Boot is useless in bringing up a board (where the effort is in SPL itself), it becomes very useful in adding or modifying all the rest of U-Boot, for instance tweaking the performance of a network driver. (on an OT note, I'd even say that a SPL-supported U-Bot which cannot chainload itself probably does not completely and/or properly reset the hardware into booting condition, but that's slightly beside the point.) Note that the above description applies to any target in which U-Boot starts from external RAM rather than IRAM or FLASH; not only those targets with SPL, but also those with a ROM bootloader capable to initialize the external RAM and chain to its payoad there, e.g. kirkwood. So, SPL-capable u-boot will have capable to chainload itself from external RAM is that correct? and for verifying any u-boot by running from external-RAM should be SPL-driven, is that correct? On that note, I have tried the same by loading u-boot on external-RAM with TEXT_BASE and it ran very feasibly. the design is like the SOC has ROM with first stage bootloader and second stage is u-boot and external-RAM got initialized in first stage bootloader(not in u-boot). this design works fine? Maybe we could add an addendum to the FAQ for the SPL and ROM bootloader cases? thanks! -- Jagan | openedev. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] hang: ARM64/Relocating u-boot from u-boot
Dear Albert, In message 20150708084625.5a18e9a5@lilith you wrote: http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM If I may, this FAQ is slightly outdated, in that chainloading U-Boot is not only possible but actually made possible by design, at least for many ARM (and possibly some ARM64) targets, and I suspect for many non-ARM targets too, as long as they use SPL. I agree that the documentation could need some dditional explanations, but it is not exactly outdated nor incorrect. First off: the FAQ is perfectly true if applied to running SPL from SPL. Right. This is the part that needs to be explained: You cannot (at least not in general, there are always some exceptions) run the code that is supposed to run first again from an already running U-Boot. With Non-SPL versions this is the plain U-Boot binary, with SPL it's the SPL, etc. IOW, on targets with SPL, U-Boot starts with the guarantee that all initializations needed for external RAM to work have been done, and it guarantees that it will not perform these external RAM inits again. This is true, but not always sufficient. There may still be initializations that cannot be done again. And since an SPL-chainloaded U-Boot runs with external already initialized and does not initialize it again, it follows that this U-Boot is a valid environment for running another instance of itself, provided the new instance and current instances do not overwrite each other. This is often the case, but not necessarily always. There are systems with components that can be initialized just once after a reset - for example, the watchdog on some systems. If your first U-Boot configures the watchdog on such a system to run, and you try and load another U-Boot image which tries to disable the watchdog, it will not work, and the new U-Boot will crash as it fails to trigger toe watchdog. All of this makes it nont only perfectly possible for (SPL-run) U-Boot to chainload (SPL-run) U-Boot, it pretty much guarantees it. The point is, this guarantee is a one-time-only guarantee. There is no guarantee that you can do exactly the same twice, without a reset inbetween. Yes, I agree, it will just work in most of the cases. But this is _not_ guaranteed, and we should at least warn potential users of such methods that they really have to understand _exactly_ what they are doing, and even if it's working now it may be broken in the next version of U-Boot. (on an OT note, I'd even say that a SPL-supported U-Bot which cannot chainload itself probably does not completely and/or properly reset the hardware into booting condition, but that's slightly beside the point.) Not all hardware can be reset by software actions alone. There are things like write-once registers. Once written, you MUST perform a reset to write any different values. Maybe we could add an addendum to the FAQ for the SPL and ROM bootloader cases? It's a wiki, all contributions are welcome. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you can't explain it to a six year old, you don't understand it yourself. - Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND] tools/imximage: set DCD pointer to NULL when its length is 0
Hi Baruch, On 09/07/2015 17:19, Baruch Siach wrote: When dcd_len is 0 the Write Data command that the set_dcd_rst_v2() routine generates is empty. This causes HAB to complain that the command is invalid. - HAB Event 1 - event data: 0xdb 0x00 0x0c 0x41 0x33 0x06 0xc0 0x00 0xcc 0x00 0x04 0x04 To fix this set the DCD pointer in the IVT to NULL in this case. The DCD header itself is still needed for detect_imximage_version() to determine the image version. Signed-off-by: Baruch Siach bar...@tkos.co.il --- Resending with a proper To: header. tools/imximage.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/imximage.c b/tools/imximage.c index 6f469ae6336c..7b91d09699ad 100644 --- a/tools/imximage.c +++ b/tools/imximage.c @@ -250,7 +250,11 @@ static void set_imx_hdr_v2(struct imx_header *imxhdr, uint32_t dcd_len, hdr_base = entry_point - imximage_init_loadsize + flash_offset; fhdr_v2-self = hdr_base; - fhdr_v2-dcd_ptr = hdr_base + offsetof(imx_header_v2_t, dcd_table); + if (dcd_len 0) + fhdr_v2-dcd_ptr = hdr_base + + offsetof(imx_header_v2_t, dcd_table); + else + fhdr_v2-dcd_ptr = 0; fhdr_v2-boot_data_ptr = hdr_base + offsetof(imx_header_v2_t, boot_data); hdr_v2-boot_data.start = entry_point - imximage_init_loadsize; It looks ok for me. Acked-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Adjust config option order in defconfig for Crown Bay and Minnowmax
On 9 July 2015 at 14:21, Simon Glass s...@chromium.org wrote: On 9 July 2015 at 04:37, Bin Meng bmeng...@gmail.com wrote: Update crownbay_defconfig and minnowmax_defconfig with 'savedefconfig' result so that the config option order matches Kconfig. Signed-off-by: Bin Meng bmeng...@gmail.com --- configs/crownbay_defconfig | 8 configs/minnowmax_defconfig | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) Acked-by: Simon Glass s...@chromium.org Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] x86: Simplify architecture defined exception handling in irq_llsr()
On 7 July 2015 at 23:17, Bin Meng bmeng...@gmail.com wrote: Instead of using switch..case for architecture defined exceptions, simply unify the handling by printing a message of exception name, followed by registers dump then halt the CPU. With this unification, it also fixes the wrong exception numbers for #MF/#AC/#MC/#XM which should be 16/17/18/19 not 15/16/17/18. Signed-off-by: Bin Meng bmeng...@gmail.com --- arch/x86/cpu/interrupts.c | 151 ++ 1 file changed, 46 insertions(+), 105 deletions(-) Acked-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 1/2] x86: Display correct CS/EIP/EFLAGS when there is an error code
Hi Bin,
On 7 July 2015 at 23:17, Bin Meng bmeng...@gmail.com wrote:
Some exceptions cause an error code to be saved on the current stack
after the EIP value. We should extract CS/EIP/EFLAGS from different
position on the stack based on the exception number.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
arch/x86/cpu/interrupts.c | 29 -
arch/x86/include/asm/ptrace.h | 16 +---
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/arch/x86/cpu/interrupts.c b/arch/x86/cpu/interrupts.c
index c777d36..4a6c21f 100644
--- a/arch/x86/cpu/interrupts.c
+++ b/arch/x86/cpu/interrupts.c
@@ -34,12 +34,39 @@ DECLARE_GLOBAL_DATA_PTR;
static void dump_regs(struct irq_regs *regs)
{
+ unsigned long cs, eip, eflags;
unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
unsigned long d0, d1, d2, d3, d6, d7;
unsigned long sp;
+ /*
+* Some exceptions cause an error code to be saved on the current
stack
+* after the EIP value. We should extract CS/EIP/EFLAGS from different
+* position on the stack based on the exception number.
+*/
+ switch (regs-irq_id) {
+ case 8:
+ case 10:
+ case 11:
+ case 12:
+ case 13:
+ case 14:
+ case 17:
Is there an enum for these values?
+ cs = regs-context.ctx2.xcs;
+ eip = regs-context.ctx2.eip;
+ eflags = regs-context.ctx2.eflags;
+ /* We should fix up the ESP due to error code */
+ regs-esp += 4;
+ break;
+ default:
+ cs = regs-context.ctx1.xcs;
+ eip = regs-context.ctx1.eip;
+ eflags = regs-context.ctx1.eflags;
+ break;
+ }
+
printf(EIP: %04x:[%08lx] EFLAGS: %08lx\n,
- (u16)regs-xcs, regs-eip, regs-eflags);
+ (u16)cs, eip, eflags);
printf(EAX: %08lx EBX: %08lx ECX: %08lx EDX: %08lx\n,
regs-eax, regs-ebx, regs-ecx, regs-edx);
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index a727dbf..3849bc0 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -63,9 +63,19 @@ struct irq_regs {
/* Pushed by vector handler (irq_num) */
long irq_id;
/* Pushed by cpu in response to interrupt */
- long eip;
- long xcs;
- long eflags;
+ union {
+ struct {
+ long eip;
+ long xcs;
+ long eflags;
+ } ctx1;
+ struct {
+ long err;
+ long eip;
+ long xcs;
+ long eflags;
+ } ctx2;
+ } context;
} __attribute__ ((packed));
/* Arbitrarily choose the same ptrace numbers as used by the Sparc code. */
--
1.8.2.1
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] generic_board: Call checkboard even though the root node has a model property
Hi, On 9 July 2015 at 05:58, Haikun Wang haikun.w...@freescale.com wrote: Showing both: Model: Freescale Layerscape 2085a QDS Board Board: LS2085E-QDS, Board Arch: V1, Board version: B, boot from vBank: 4 This looks like duplication (at least the first part). Anyway I don't see any problem with this change. Reviewed-by: Simon Glass s...@chromium.org Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] x86: Initial ACPI support for minnowmax and qemu.
Signed-off-by: Saket Sinha saket.sinh...@gmail.com
---
arch/x86/Kconfig | 7 +
arch/x86/cpu/qemu/Makefile | 3 +-
arch/x86/cpu/qemu/acpi.c | 176 +++
arch/x86/cpu/qemu/acpi/cpu-hotplug.asl | 78 +
arch/x86/cpu/qemu/acpi/dbug.asl| 26 ++
arch/x86/cpu/qemu/acpi/hpet.asl| 36 +++
arch/x86/cpu/qemu/acpi/isa.asl | 102 +++
arch/x86/cpu/qemu/acpi/pci-crs.asl | 94 ++
arch/x86/cpu/qemu/dsdt.asl | 454 +
arch/x86/include/asm/acpi_table.h | 387
arch/x86/lib/Makefile | 1 +
arch/x86/lib/acpi_table.c | 395 +
arch/x86/lib/tables.c | 5 +
board/intel/minnowmax/Makefile | 3 +-
board/intel/minnowmax/acpi.c | 251
board/intel/minnowmax/acpi/cpu.asl | 56
board/intel/minnowmax/acpi/device_nvs.asl | 66 +
board/intel/minnowmax/acpi/ec.asl | 0
board/intel/minnowmax/acpi/globalnvs.asl | 83 ++
board/intel/minnowmax/acpi/mainboard.asl | 4 +
board/intel/minnowmax/acpi/platform.asl| 52
board/intel/minnowmax/acpi/sleepstates.asl | 5 +
board/intel/minnowmax/acpi/superio.asl | 0
board/intel/minnowmax/dsdt.asl | 29 ++
scripts/Makefile.lib | 11 +
25 files changed, 2322 insertions(+), 2 deletions(-)
create mode 100644 arch/x86/cpu/qemu/acpi.c
create mode 100644 arch/x86/cpu/qemu/acpi/cpu-hotplug.asl
create mode 100644 arch/x86/cpu/qemu/acpi/dbug.asl
create mode 100644 arch/x86/cpu/qemu/acpi/hpet.asl
create mode 100644 arch/x86/cpu/qemu/acpi/isa.asl
create mode 100644 arch/x86/cpu/qemu/acpi/pci-crs.asl
create mode 100644 arch/x86/cpu/qemu/dsdt.asl
create mode 100644 arch/x86/include/asm/acpi_table.h
create mode 100644 arch/x86/lib/acpi_table.c
create mode 100644 board/intel/minnowmax/acpi.c
create mode 100644 board/intel/minnowmax/acpi/cpu.asl
create mode 100644 board/intel/minnowmax/acpi/device_nvs.asl
create mode 100644 board/intel/minnowmax/acpi/ec.asl
create mode 100644 board/intel/minnowmax/acpi/globalnvs.asl
create mode 100644 board/intel/minnowmax/acpi/mainboard.asl
create mode 100644 board/intel/minnowmax/acpi/platform.asl
create mode 100644 board/intel/minnowmax/acpi/sleepstates.asl
create mode 100644 board/intel/minnowmax/acpi/superio.asl
create mode 100644 board/intel/minnowmax/dsdt.asl
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cbbaa4f..7beda01 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -338,6 +338,13 @@ config GENERATE_MP_TABLE
endmenu
+config GENERATE_ACPI_TABLE
+ bool Generate ACPI(Advanced Configuration and Power Interface) table
+ default y
+ help
+ The Advanced Configuration and Power Interface (ACPI) specification
provides an open standard for device configuration and management by
the operating system. It defines platform-independent interfaces for hardware
discovery, configuration, power management monitoring.
+
+
config MAX_PIRQ_LINKS
int
default 8
diff --git a/arch/x86/cpu/qemu/Makefile b/arch/x86/cpu/qemu/Makefile
index be79723..1fbfbc5 100644
--- a/arch/x86/cpu/qemu/Makefile
+++ b/arch/x86/cpu/qemu/Makefile
@@ -4,5 +4,6 @@
# SPDX-License-Identifier: GPL-2.0+
#
-obj-y += car.o dram.o qemu.o
+obj-y += car.o dram.o qemu.o
+obj-$(CONFIG_GENERATE_ACPI_TABLE) += acpi.o dsdt.o
obj-$(CONFIG_PCI) += pci.o
diff --git a/arch/x86/cpu/qemu/acpi.c b/arch/x86/cpu/qemu/acpi.c
new file mode 100644
index 000..aab374a
--- /dev/null
+++ b/arch/x86/cpu/qemu/acpi.c
@@ -0,0 +1,176 @@
+#include asm/acpi_table.h
+#include asm/cpu.h
+#include asm/ioapic.h
+#include asm/lapic.h
+#include asm/tables.h
+#include asm/pci.h
+#include cpu.h
+#include dm.h
+#include dm/uclass-internal.h
+#include dm/lists.h
+
+void acpi_create_fadt(struct acpi_fadt * fadt, struct acpi_facs * facs, void
*dsdt)
+{
+ acpi_header_t *header = (fadt-header);
+ u16 pmbase;
+
+ pci_dev_t bdf = PCI_BDF(0, 0x1f, 0);
+ pci_read_config_word(bdf, 0x40, pmbase);
+
+ memset((void *) fadt, 0, sizeof(struct acpi_fadt));
+ memcpy(header-signature, FACP, 4);
+ header-length = sizeof(struct acpi_fadt);
+ header-revision = 3;
+ memcpy(header-oem_id, OEM_ID, 6);
+ memcpy(header-oem_table_id, ACPI_TABLE_CREATOR, 8);
+ memcpy(header-asl_compiler_id, ASLC, 4);
+ header-asl_compiler_revision = 0;
+
+ fadt-firmware_ctrl = (unsigned long) facs;
+ fadt-dsdt = (unsigned long) dsdt;
+ fadt-model = 0x00;
+ fadt-preferred_pm_profile = PM_MOBILE;
+ fadt-sci_int = 0x9;
+ fadt-smi_cmd = 0;
+ fadt-acpi_enable = 0;
+ fadt-acpi_disable = 0;
+ fadt-s4bios_req = 0x0;
+ fadt-pstate_cnt = 0;
+
[U-Boot] [PATCH] Support ACPI on minnowmax and qemu-x86 targets
This is an initial attempt to support ACPI on minnowmax and qemu-x86 targets. This is still a work in progress. The Linux kernel boot logs on minnowmax can be found at http://pastebin.com/Vdk8PqaV . Saket Sinha (1): x86: Initial ACPI support for minnowmax and qemu. arch/x86/Kconfig | 7 + arch/x86/cpu/qemu/Makefile | 3 +- arch/x86/cpu/qemu/acpi.c | 176 +++ arch/x86/cpu/qemu/acpi/cpu-hotplug.asl | 78 + arch/x86/cpu/qemu/acpi/dbug.asl| 26 ++ arch/x86/cpu/qemu/acpi/hpet.asl| 36 +++ arch/x86/cpu/qemu/acpi/isa.asl | 102 +++ arch/x86/cpu/qemu/acpi/pci-crs.asl | 94 ++ arch/x86/cpu/qemu/dsdt.asl | 454 + arch/x86/include/asm/acpi_table.h | 387 arch/x86/lib/Makefile | 1 + arch/x86/lib/acpi_table.c | 395 + arch/x86/lib/tables.c | 5 + board/intel/minnowmax/Makefile | 3 +- board/intel/minnowmax/acpi.c | 251 board/intel/minnowmax/acpi/cpu.asl | 56 board/intel/minnowmax/acpi/device_nvs.asl | 66 + board/intel/minnowmax/acpi/ec.asl | 0 board/intel/minnowmax/acpi/globalnvs.asl | 83 ++ board/intel/minnowmax/acpi/mainboard.asl | 4 + board/intel/minnowmax/acpi/platform.asl| 52 board/intel/minnowmax/acpi/sleepstates.asl | 5 + board/intel/minnowmax/acpi/superio.asl | 0 board/intel/minnowmax/dsdt.asl | 29 ++ scripts/Makefile.lib | 11 + 25 files changed, 2322 insertions(+), 2 deletions(-) create mode 100644 arch/x86/cpu/qemu/acpi.c create mode 100644 arch/x86/cpu/qemu/acpi/cpu-hotplug.asl create mode 100644 arch/x86/cpu/qemu/acpi/dbug.asl create mode 100644 arch/x86/cpu/qemu/acpi/hpet.asl create mode 100644 arch/x86/cpu/qemu/acpi/isa.asl create mode 100644 arch/x86/cpu/qemu/acpi/pci-crs.asl create mode 100644 arch/x86/cpu/qemu/dsdt.asl create mode 100644 arch/x86/include/asm/acpi_table.h create mode 100644 arch/x86/lib/acpi_table.c create mode 100644 board/intel/minnowmax/acpi.c create mode 100644 board/intel/minnowmax/acpi/cpu.asl create mode 100644 board/intel/minnowmax/acpi/device_nvs.asl create mode 100644 board/intel/minnowmax/acpi/ec.asl create mode 100644 board/intel/minnowmax/acpi/globalnvs.asl create mode 100644 board/intel/minnowmax/acpi/mainboard.asl create mode 100644 board/intel/minnowmax/acpi/platform.asl create mode 100644 board/intel/minnowmax/acpi/sleepstates.asl create mode 100644 board/intel/minnowmax/acpi/superio.asl create mode 100644 board/intel/minnowmax/dsdt.asl -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
