[U-Boot] [PATCH] semihosting: Improve ARMv7A support
Previous implementation of semihosting didn't account for cases where
doing an SVC call would clobber various data(most notable case would
be 'lr' and 'spsr' when doing SVC call in Supervisor mode). This patch
is an adaptation of the code from Newlib's Angel_SWI feature (can be
found in libc/sys/arm/swi.h) which hopefuly fixes the problem.
Tested with modified OpenOCD and custom Vybrid VF610 based board
Signed-off-by: Andrey Smirnov andrew.smir...@gmail.com
---
arch/arm/lib/semihosting.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/arch/arm/lib/semihosting.c b/arch/arm/lib/semihosting.c
index c3e964e..5f22c2d 100644
--- a/arch/arm/lib/semihosting.c
+++ b/arch/arm/lib/semihosting.c
@@ -26,18 +26,40 @@
/*
* Call the handler
*/
+#if defined(CONFIG_ARM64)
static noinline long smh_trap(unsigned int sysnum, void *addr)
{
register long result asm(r0);
-#if defined(CONFIG_ARM64)
asm volatile (hlt #0xf000 : =r (result) : 0(sysnum), r(addr));
+ return result;
+}
#else
- /* Note - untested placeholder */
- asm volatile (svc #0x123456 : =r (result) : 0(sysnum), r(addr));
+#if defined (CONFIG_SYS_THUMB_BUILD)
+#error Support for semihosting in THUMB mode is not implemented
#endif
+/*
+ * Call the handler
+ */
+static noinline long smh_trap(unsigned int sysnum, void *addr)
+{
+ int result;
+
+ asm volatile (mov r0, %1 \n\t
+ mov r1, %2 \n\t
+ svc #0x123456 \n\t
+ mov %0, r0 \n\t
+ : =r (result)
+ : r (sysnum), r (addr)
+ : r0, r1, r2, r3, ip, lr, memory, cc);
+ /* Clobbers r0 and r1, and lr if in supervisor
+mode Accordingly to page 13-77 of ARM DUI
+0040D other registers can also be clobbered.
+Some memory positions may also be changed by
+a system call, so they should not be kept in
+registers. */
return result;
}
-
+#endif
/*
* Open a file on the host. Mode is r or rb currently. Returns a file
* descriptor or -1 on error.
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/19] i2c: Add a mux for GPIO-based I2C bus arbitration
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: While I2C supports multi-master buses this is difficult to get right. The implementation on the master side in software is quite complex. Clock-stretching and the arbitrary time that an I2C transaction can take make it difficult to share the bus fairly in the face of high traffic. When one or more masters can be reset independently part-way through a transaction it is hard to know the state of the bus. This driver provides a scheme based on two 'claim' GPIOs, one driven by the AP (Application Processor, meaning the main CPU) and one driven by the EC (Embedded Controller, a small CPU aimed at handling system tasks). With these they can communicate and reliably share the bus. This scheme has minimal overhead and involves very little code. It is used on snow to permit the EC and the AP to share access to the main system PMIC and battery. The scheme can survive reboots by either side without difficulty. This scheme has been tested in the field with millions of devices. Since U-Boot runs on the AP, the terminology used is 'our' claim GPIO, meaning the AP's, and 'their' claim GPIO, meaning the EC's. This terminology is used by the device tree bindings in Linux also. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Add a README explaining the algorithm and update the commit message doc/README.i2c | 60 drivers/i2c/muxes/Kconfig | 9 ++ drivers/i2c/muxes/Makefile | 1 + drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 147 + 4 files changed, 217 insertions(+) create mode 100644 doc/README.i2c create mode 100644 drivers/i2c/muxes/i2c-arb-gpio-challenge.c Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/19] exynos: dts: Correct LDO and BUCK naming
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: At present lower case is used for the regulator names in the device tree. The kernel uses upper case and U-Boot will require this also since it will move to a case-sensitive name check. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Add new patch to correct LDO and BUCK naming arch/arm/dts/exynos4412-odroid.dts | 56 +++--- arch/arm/dts/exynos4412-trats2.dts | 70 +++--- 2 files changed, 63 insertions(+), 63 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/19] video: Work around lack of pinctrl
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: We haven't quite got pinctrl ready to apply to mainline. We don't want to GPIO pull-up/down support to the driver model GPIO layer either. So work around this for now. We can address this when pinctrl is complete. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Add a new patch to hold off the need for driver model pinctrl drivers/video/bridge/video-bridge-uclass.c | 28 ++-- 1 file changed, 18 insertions(+), 10 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/19] dm: i2c: Add support for multiplexed I2C buses
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: Add a new I2C_MUX uclass. Devices in this class can multiplex between several I2C buses, selecting them one at a time for use by the system. The multiplexing mechanism is left to the driver to decide - it may be controlled by GPIOs, for example. The uclass supports only two methods: select() and deselect(). The current mux state is expected to be stored in the mux itself since it is the only thing that knows how to make things work. The mux can record the current state and then avoid switching unless it is necessary. So select() can be skipped if the mux is already in the correct state. Also deselect() can be made a nop if required. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Update commit message and header file to better explain select()/deselect() doc/device-tree-bindings/i2c/i2c-mux.txt | 60 ++ drivers/i2c/Kconfig | 2 + drivers/i2c/Makefile | 2 + drivers/i2c/muxes/Kconfig| 8 ++ drivers/i2c/muxes/Makefile | 6 + drivers/i2c/muxes/i2c-mux-uclass.c | 198 +++ include/dm/uclass-id.h | 1 + include/i2c.h| 39 ++ 8 files changed, 316 insertions(+) create mode 100644 doc/device-tree-bindings/i2c/i2c-mux.txt create mode 100644 drivers/i2c/muxes/Kconfig create mode 100644 drivers/i2c/muxes/Makefile create mode 100644 drivers/i2c/muxes/i2c-mux-uclass.c Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/19] exynos: Drop old exynos5420-specific board code
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: Now that exynos5420 boards can use the generic exynos5 code, switch over to it and remove the old code. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Przemyslaw Marczak p.marc...@samsung.com --- Changes in v2: None board/samsung/smdk5420/Makefile | 4 - board/samsung/smdk5420/smdk5420.c | 143 include/configs/exynos5420-common.h | 2 + 3 files changed, 2 insertions(+), 147 deletions(-) delete mode 100644 board/samsung/smdk5420/smdk5420.c Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/19] exynos: dts: Drop the old TPS65090 I2C node
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: While the AP can access the main PMIC on snow, it must coordinate with the EC which also wants access. Drop the old definition, which can in principle generate collision errors. We will use the new arbitration driver instead. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None arch/arm/dts/exynos5250-snow.dts | 16 1 file changed, 16 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/19] exynos: config: Move common options to the common headers and tidy up
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: Many options are duplicated on the exynos5 boards. Move these to the common files. Also some options are not used so can be removed. Tidy this up to make the files easier to maintain. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Przemyslaw Marczak p.marc...@samsung.com --- Changes in v2: - Rebase to dm/master include/configs/arndale.h | 14 ++ include/configs/exynos5-common.h| 3 --- include/configs/exynos5-dt-common.h | 16 +++- include/configs/exynos5250-common.h | 16 ++-- include/configs/exynos5420-common.h | 9 +++-- include/configs/odroid_xu3.h| 2 ++ include/configs/peach-pi.h | 12 +--- include/configs/peach-pit.h | 20 +--- include/configs/smdk5250.h | 15 --- include/configs/smdk5420.h | 10 -- include/configs/snow.h | 12 +--- 11 files changed, 39 insertions(+), 90 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/19] video: Remove the old parade driver
On Mon, 3 Aug 2015 08:19:34 -0600 Simon Glass s...@chromium.org wrote: We have a new one which uses driver model and device tree configuration. Remove the old one. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Anatolij Gustschin ag...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: tegra: query_sdram_size() cleanup
Hi Stephen,
On 7 August 2015 at 16:12, Stephen Warren swar...@wwwdotorg.org wrote:
From: Stephen Warren swar...@nvidia.com
The return value of query_sdram_size() is assigned directly to
gd-ram_size in dram_init(). Adjust the return type to match the field
it's assigned to. This has the beneficial effect that on 64-bit systems,
the return value can correctly represent large RAM sizes over 4GB.
For similar reasons, change the type of variable size_bytes in the same
way.
query_sdram_size() would previously clip the detected RAM size to at most
just under 4GB in all cases, since on 32-bit systems, larger values could
not be represented. Disable this feature on 64-bit systems since the
representation restriction does not exist.
On 64-bit systems, never call get_ram_size() to validate the detected/
calculated RAM size. On any system with a secure OS/... carve-out, RAM
may not have a single contiguous usable area, and this can confuse
get_ram_size(). Ideally, we'd make this call conditional upon some other
flag that indicates specifically that a carve-out is actually in use. At
present, building for a 64-bit system is the best indication we have of
this fact. In fact, the call to get_ram_size() is not useful by the time
U-Boot runs on any system, since U-Boot (and potentially much other early
boot software) always runs from RAM on Tegra, so any mistakes in memory
controller register programming will already have manifested themselves
and prevented U-Boot from running to this point. In the future, we may
simply delete the call to get_ram_size() in all cases.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
arch/arm/mach-tegra/board.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index 40de72dc575f..b00e4b5c1e25 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -66,10 +66,11 @@ bool tegra_cpu_is_non_secure(void)
#endif
/* Read the RAM size directly from the memory controller */
-unsigned int query_sdram_size(void)
+static phys_size_t query_sdram_size(void)
{
struct mc_ctlr *const mc = (struct mc_ctlr *)NV_PA_MC_BASE;
- u32 emem_cfg, size_bytes;
+ u32 emem_cfg;
+ phys_size_t size_bytes;
emem_cfg = readl(mc-mc_emem_cfg);
#if defined(CONFIG_TEGRA20)
@@ -77,6 +78,7 @@ unsigned int query_sdram_size(void)
size_bytes = get_ram_size((void *)PHYS_SDRAM_1, emem_cfg * 1024);
#else
debug(mc-mc_emem_cfg (MEM_SIZE_MB) = 0x%08x\n, emem_cfg);
+#ifndef CONFIG_PHYS_64BIT
/*
* If =4GB RAM is present, the byte RAM size won't fit into 32-bits
* and will wrap. Clip the reported size to the maximum that a 32-bit
@@ -84,9 +86,12 @@ unsigned int query_sdram_size(void)
*/
if (emem_cfg = 4096) {
size_bytes = U32_MAX ~(0x1000 - 1);
- } else {
+ } else
+#endif
+ {
/* RAM size EMC is programmed to. */
- size_bytes = emem_cfg * 1024 * 1024;
+ size_bytes = (phys_size_t)emem_cfg * 1024 * 1024;
+#ifndef CONFIG_ARM64
/*
* If all RAM fits within 32-bits, it can be accessed without
* LPAE, so go test the RAM size. Otherwise, we can't access
@@ -97,6 +102,7 @@ unsigned int query_sdram_size(void)
if (emem_cfg = (0 - PHYS_SDRAM_1) / (1024 * 1024))
size_bytes = get_ram_size((void *)PHYS_SDRAM_1,
size_bytes);
+#endif
}
#endif
--
1.9.1
You might consider using 'if IS_ENABLED()' instead of #ifdef. Or
perhaps you should create a board_64.c if the code going to be so
different?
Also why do you use CONFIG_ARM64 for the second one and
CONFIG_PHYS_64BIT for the first?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH] common/lcd_console: fix console/logo regression
On 4 August 2015 at 07:49, Marcel Ziswiler mar...@ziswiler.com wrote: From: Marcel Ziswiler marcel.ziswi...@toradex.com The following commit changed the order of the column vs. row parameter to the lcd_init_console() function but missed actually changing it as well the second time it is called from lcd_clear() which resulted in a garbled text console which this patch fixes. commit 604c7d4a5a3cf70949f6e6094bf0d52ee3b4804d common/lcd_console: introduce display/framebuffer rotation Tested on Colibri T20 with my latest assortment of tegra fixes/enhancements patch set. Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com --- common/lcd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 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/3] ARM: tegra: move kernel_addr_r on T210
On 7 August 2015 at 16:12, Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com The new value is the most likely value where the kernel wants to end up at run-time. Selecting this value as the load address likely avoids the need to copy the kernel image from the actual load address to the desired load address. Note that this isn't guaranteed since the kernel may wish to run at an arbitrary location. In that case, U-Boot will still relocate the image according to its wishes; this change is a performance optimization, not a hard-coding of the final image location. Signed-off-by: Stephen Warren swar...@nvidia.com --- include/configs/tegra210-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 2/6] dm: core: Fix a typo in the uclass_get_device_by_name() comment
On 31 July 2015 at 03:08, Bin Meng bmeng...@gmail.com wrote: On Fri, Jul 31, 2015 at 3:40 AM, Simon Glass s...@chromium.org wrote: This function comment has a typo. Fix it. Signed-off-by: Simon Glass s...@chromium.org --- include/dm/uclass.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/dm/uclass.h b/include/dm/uclass.h index 3fe1739..d56877c 100644 --- a/include/dm/uclass.h +++ b/include/dm/uclass.h @@ -130,7 +130,7 @@ int uclass_get(enum uclass_id key, struct uclass **ucp); int uclass_get_device(enum uclass_id id, int index, struct udevice **devp); /** - * uclass_get_device_by_name() - Get a uclass device by it's name + * uclass_get_device_by_name() - Get a uclass device by its name * * This searches the devices in the uclass for one with the exactly given name. * -- Reviewed-by: Bin Meng bmeng...@gmail.com Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] x86: Enable debug UART for Minnowmax
On 2 August 2015 at 18:07, Simon Glass s...@chromium.org wrote: Enable the debug UART and emit a single 'a' early in the init sequence to show that it is working. Unfortunately the debug UART implementation needs a stack to work. I cannot seem to remove this limitation as the absolute 'jmp %eax' instruction goes off into the weeds. So this means that the character output cannot be any earlier than car_init_ret, where memory is available for a stack. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Lukasz Majewski l.majew...@samsung.com --- Changes in v2: - Put the debug UART setup code in comments since we don't always want it arch/x86/cpu/start.S| 9 + configs/minnowmax_defconfig | 4 2 files changed, 13 insertions(+) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ARM: tegra: represent RAM in 1 or 2 banks
On 7 August 2015 at 16:12, Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com Represent all available RAM in either one or two banks. The first bank describes any RAM below 4GB. The second bank describes any RAM above 4GB. This split is driven by the following requirements: - The NVIDIA L4T kernel requires separate entries in the DT /memory/reg property for memory below and above the 4GB boundary. The layout of that DT property is directly driven by the entries in the U-Boot bank array. - On systems with RAM beyond a physical address of 4GB, the potential existence of a carve-out at the end of RAM below 4GB can only be represented using multiple banks, since usable RAM is not contiguous. While making this change, add a lot more comments re: how and why RAM is represented in banks, and implement a few more semantic functions that define (and perhaps later detect at run-time) the size of any carve-out. Signed-off-by: Stephen Warren swar...@nvidia.com --- arch/arm/mach-tegra/board2.c | 120 - include/configs/tegra-common.h | 2 +- 2 files changed, 107 insertions(+), 15 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 v2] dm: usb: fix USB Ethernet without CONFIG_DM_ETH regression
Hi, On 5 August 2015 at 09:29, Simon Glass s...@chromium.org wrote: Hi Marcel, On 5 August 2015 at 08:58, Marcel Ziswiler mar...@ziswiler.com wrote: From: Marcel Ziswiler marcel.ziswi...@toradex.com The following commit enforces CONFIG_DM_ETH for USB Ethernet which breaks any board using CONFIG_USB_HOST_ETHER without CONFIG_DM_ETH which this patch fixes. commit 69559093f6173dcfcb041df0995063bdbd07d49b dm: usb: Avoid using USB ethernet with CONFIG_DM_USB and no DM_ETH Tested on Colibri T20/T30 as well as Apalis T30 with CONFIG_USB_HOST_ETHER and CONFIG_USB_ETHER_ASIX enabled and a LevelOne USB-0301 ASIX AX88772 dongle. Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com --- Changes in v2: Fix commit message as pointed out by Simon. common/cmd_usb.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) Acked-by: Simon Glass s...@chromium.org Applied to u-boot-dm, thanks! It turns out I dropped missed applying a patch: http://patchwork.ozlabs.org/patch/492686/ Thanks for fixing this. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v3 2/2] lib/fdtdec: Fix compiling warning caused by changing fdt_addr_t type
On 3 August 2015 at 13:02, York Sun york...@freescale.com wrote: fdt_addr_t is changed to phys_addr_t. The format in debug should be updated to %pa to match the type. Signed-off-by: York Sun york...@freescale.com CC: Simon Glass s...@chromium.org --- Change log: v3: split into a separated patch drivers/pci/pci_tegra.c | 10 +- drivers/spi/fsl_dspi.c |4 ++-- drivers/video/tegra.c |2 +- 3 files changed, 8 insertions(+), 8 deletions(-) Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] dm: core: Add a way to set a device name
On 31 July 2015 at 03:08, Bin Meng bmeng...@gmail.com wrote:
On Fri, Jul 31, 2015 at 3:40 AM, Simon Glass s...@chromium.org wrote:
Some devices are bound entirely by probing and do not have the benefit of
a device tree to give them a name. This is very common with PCI and USB. In
most cases this is fine, but we should add an official way to set a device
name. This should be called in the device's bind() method.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/core/device.c | 10 ++
include/dm/device.h | 15 +++
2 files changed, 25 insertions(+)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index caaf231..bbe7a94 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -603,3 +603,13 @@ bool device_is_last_sibling(struct udevice *dev)
return false;
return list_is_last(dev-sibling_node, parent-child_head);
}
+
+int device_set_name(struct udevice *dev, const char *name)
+{
+ name = strdup(name);
+ if (!name)
+ return -ENOMEM;
+ dev-name = name;
+
+ return 0;
+}
diff --git a/include/dm/device.h b/include/dm/device.h
index 38e23f8..5a04379 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -468,6 +468,21 @@ bool device_has_active_children(struct udevice *dev);
*/
bool device_is_last_sibling(struct udevice *dev);
+/**
+ * device_set_name() - set the name of a device
+ *
+ * This must be called in the device's bind() method and no later. Normally
+ * this is unnecessary but for probed devices which don't get a useful name
+ * this function can be helpful.
+ *
+ * @dev: Device to update
+ * @name: New name (this string is allocated new memory and attached to
+ * the device)
+ * @return 0 if OK, -ENOMEM if there is not enough memory to allocate the
+ * string
+ */
+int device_set_name(struct udevice *dev, const char *name);
+
/* device resource management */
typedef void (*dr_release_t)(struct udevice *dev, void *res);
typedef int (*dr_match_t)(struct udevice *dev, void *res, void *match_data);
--
Reviewed-by: Bin Meng bmeng...@gmail.com
Applied to u-boot-dm.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Introduce TPM driver model and STMicroelectronics ST33ZP24 TPMs
Hi Christophe,
On 9 August 2015 at 07:19, Christophe Ricard
christophe.ric...@gmail.com wrote:
Hi,
This patch serie introduce TPM driver model allowing to instantiate a TPM
using U_BOOT_DEVICE macro for platform_data or device tree.
As an information, there is no TCG transport protocol official specification
for i2c for TPM1.2. The TPM uclass allows to support different kind of bus
(LPC, I2C, SPI) keeping the TPM command duration in common.
Also, this serie introduce TPM1.2 from STMicroelectronics ST33ZP24 with
I2C and SPI support. It has been ported from existing Linux drivers.
This has been tested on Beagleboard xM.
As it happens I have just been trying to clean up the TPM drivers for
Kconfig and driver model.
Please see u-boot-dm branch tpm-working. I'll hurry up and try to send
out some patches and update the wiki. I wonder if we can join our work
somehow?
Regards,
Simon
Best Regards
Christophe
Christophe Ricard (3):
tpm: Move tpm_tis_i2c to tpm_i2c_infineon
tpm: Initial work to introduce TPM driver model
tpm: Add st33zp24 tpm with i2c and spi phy
README| 23 +-
drivers/tpm/Makefile | 5 +-
drivers/tpm/st33zp24/Makefile | 7 +
drivers/tpm/st33zp24/i2c.c| 226 +++
drivers/tpm/st33zp24/spi.c| 286 ++
drivers/tpm/st33zp24/st33zp24.c | 454
++
drivers/tpm/st33zp24/st33zp24.h | 29 ++
drivers/tpm/tpm.c | 275 +++--
drivers/tpm/{tpm_tis_i2c.c = tpm_i2c_infineon.c} | 271 -
drivers/tpm/tpm_private.h | 23 +-
include/dm/platform_data/st33zp24_i2c.h | 28 ++
include/dm/platform_data/st33zp24_spi.h | 30 ++
include/dm/platform_data/tpm_i2c_infineon.h | 23 ++
include/dm/uclass-id.h| 1 +
include/fdtdec.h | 5 +-
lib/fdtdec.c | 2 +
16 files changed, 1351 insertions(+), 337 deletions(-)
create mode 100644 drivers/tpm/st33zp24/Makefile
create mode 100644 drivers/tpm/st33zp24/i2c.c
create mode 100644 drivers/tpm/st33zp24/spi.c
create mode 100644 drivers/tpm/st33zp24/st33zp24.c
create mode 100644 drivers/tpm/st33zp24/st33zp24.h
rename drivers/tpm/{tpm_tis_i2c.c = tpm_i2c_infineon.c} (70%)
create mode 100644 include/dm/platform_data/st33zp24_i2c.h
create mode 100644 include/dm/platform_data/st33zp24_spi.h
create mode 100644 include/dm/platform_data/tpm_i2c_infineon.h
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Introduce TPM driver model and STMicroelectronics ST33ZP24 TPMs
Hi Simon,
Thanks for pointing me to the right tree and branch. I missed that :-(.
I will go and look at your on-going work and try to fit our STM drivers.
I will be happy to co-work on this.
Best regards
Christophe
Le dim. 9 août 2015 15:28, Simon Glass s...@chromium.org a écrit :
Hi Christophe,
On 9 August 2015 at 07:19, Christophe Ricard
christophe.ric...@gmail.com wrote:
Hi,
This patch serie introduce TPM driver model allowing to instantiate a TPM
using U_BOOT_DEVICE macro for platform_data or device tree.
As an information, there is no TCG transport protocol official
specification
for i2c for TPM1.2. The TPM uclass allows to support different kind of
bus
(LPC, I2C, SPI) keeping the TPM command duration in common.
Also, this serie introduce TPM1.2 from STMicroelectronics ST33ZP24 with
I2C and SPI support. It has been ported from existing Linux drivers.
This has been tested on Beagleboard xM.
As it happens I have just been trying to clean up the TPM drivers for
Kconfig and driver model.
Please see u-boot-dm branch tpm-working. I'll hurry up and try to send
out some patches and update the wiki. I wonder if we can join our work
somehow?
Regards,
Simon
Best Regards
Christophe
Christophe Ricard (3):
tpm: Move tpm_tis_i2c to tpm_i2c_infineon
tpm: Initial work to introduce TPM driver model
tpm: Add st33zp24 tpm with i2c and spi phy
README| 23 +-
drivers/tpm/Makefile | 5 +-
drivers/tpm/st33zp24/Makefile | 7 +
drivers/tpm/st33zp24/i2c.c| 226 +++
drivers/tpm/st33zp24/spi.c| 286 ++
drivers/tpm/st33zp24/st33zp24.c | 454
++
drivers/tpm/st33zp24/st33zp24.h | 29 ++
drivers/tpm/tpm.c | 275 +++--
drivers/tpm/{tpm_tis_i2c.c = tpm_i2c_infineon.c} | 271 -
drivers/tpm/tpm_private.h | 23 +-
include/dm/platform_data/st33zp24_i2c.h | 28 ++
include/dm/platform_data/st33zp24_spi.h | 30 ++
include/dm/platform_data/tpm_i2c_infineon.h | 23 ++
include/dm/uclass-id.h| 1 +
include/fdtdec.h | 5 +-
lib/fdtdec.c | 2 +
16 files changed, 1351 insertions(+), 337 deletions(-)
create mode 100644 drivers/tpm/st33zp24/Makefile
create mode 100644 drivers/tpm/st33zp24/i2c.c
create mode 100644 drivers/tpm/st33zp24/spi.c
create mode 100644 drivers/tpm/st33zp24/st33zp24.c
create mode 100644 drivers/tpm/st33zp24/st33zp24.h
rename drivers/tpm/{tpm_tis_i2c.c = tpm_i2c_infineon.c} (70%)
create mode 100644 include/dm/platform_data/st33zp24_i2c.h
create mode 100644 include/dm/platform_data/st33zp24_spi.h
create mode 100644 include/dm/platform_data/tpm_i2c_infineon.h
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 18/19] exynos: video: Remove non-device-tree code
Hi Simon, On Mon, 3 Aug 2015 08:19:36 -0600 Simon Glass s...@chromium.org wrote: We always use device tree on exynos, so remove the unused code. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Anatolij Gustschin ag...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: add new fdt address parsing functions
Hi Stephen, On 6 August 2015 at 15:31, Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com fdtdec_get_addr_size() hard-codes the number of cells used to represent an address or size in DT. This is incorrect in many cases depending on the DT binding for a particular node or property (e.g. it is incorrect for the reg property). In most cases, DT parsing code must use the properties #address-cells and #size-cells to parse addres properties. This change splits up the implementation of fdtdec_get_addr_size() so that the core logic can be used for both hard-coded and non-hard-coded cases. Various wrapper functions are implemented that support cases where hard-coded cell counts should or should not be used, and where the client does and doesn't know the parent node ID that contains the properties #address-cells and #size-cells. dev_get_addr() is updated to use the new functions. Core functionality in fdtdec_get_addr_size_fixed() is widely tested via fdtdec_get_addr_size(). I tested fdtdec_get_addr_size_auto_noparent() and dev_get_addr() by manually modifying the Tegra I2C driver to invoke them. Much of the core implementation of fdtdec_get_addr_size_fixed(), fdtdec_get_addr_size_auto_parent(), and fdtdec_get_addr_size_auto_noparent() comes from Thierry Reding's previous commit fdt: Fix fdtdec_get_addr_size() for 64-bit. Based-on-work-by: Thierry Reding tred...@nvidia.com Cc: Thierry Reding tred...@nvidia.com Cc: Simon Glass s...@chromium.org Cc: Michal Suchanek hramr...@gmail.com Signed-off-by: Stephen Warren swar...@nvidia.com --- For patch context, this patch relies on Thierry's fdt: Fix fdtdec_get_addr_size() for 64-bit having been reverted. --- drivers/core/device.c | 5 ++- include/fdtdec.h | 111 +++ lib/fdtdec.c | 116 +- 3 files changed, 202 insertions(+), 30 deletions(-) Acked-by: Simon Glass s...@chromium.org This looks perfect to me, and covers all cases. Thank you for resolving this. Re SPL I'll be getting back to that before long and taking another look at code size. If anything needs tweaking in dev_get_addr() I'll send a patch then. I'll wait to see if there are other comments and apply this to the fdt tree early next week. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert fdt: Fix fdtdec_get_addr_size() for 64-bit
Hi Stephen, On 6 August 2015 at 13:03, Stephen Warren swar...@wwwdotorg.org wrote: On 08/05/2015 05:45 PM, Simon Glass wrote: Hi Stephen, On 5 August 2015 at 12:22, Stephen Warren swar...@wwwdotorg.org wrote: On 08/04/2015 10:08 PM, Simon Glass wrote: Hi Stephen, On 3 August 2015 at 12:20, Stephen Warren swar...@wwwdotorg.org wrote: On 08/03/2015 09:52 AM, Simon Glass wrote: Hi Stephen, On 3 August 2015 at 09:12, Stephen Warren swar...@wwwdotorg.org wrote: On 08/02/2015 06:13 PM, Simon Glass wrote: This reverts commit 5b34436035fc862b5e8d0d2c3eab74ba36f1a7f4. This function has a few problems. It calls fdt_parent_offset() which as mentioned in code review is very slow. https://patchwork.ozlabs.org/patch/499482/ https://patchwork.ozlabs.org/patch/452604/ It also happens to break SPI flash on Minnowboard max which is how I noticed that this was applied. I can send a patch to tidy that up, but in any case I think we should consider a revert until the function is better implemented. The fact that the function needs to perform a slow operation is not a good reason for a revert. The slowness of the operation is just a matter of fact with DT not having uplinks in its data structure, and U-Boot using those data structures directly. You'd requested during review that I additionally implement a faster version of the function in the case where the parent node is already known, and said it was fine if that happened in a later patch. I have this on my TODO list, but it's only been a couple of days. I didn't expect this to go to mainline before your new patch. I didn't get that message from the thread; you wrote: Simon Glass wrote: Stephen Warren wrote: Simon Glass wrote: Also, how about (in addition) a version of this function that works for devices? Like: device_get_addr_size(struct udevice *dev, ...) so that it can handle this for you. That sounds like a separate patch? Yes, but I think we should get it in there so that people don't start using this (wildly inefficient) function when they don't need to. I think by passing in the parent node we force people to think about the cost. Yes the driver model function can be a separate patch, but let's get it in at about the same time. We have dev_get_addr() so could have dev_get_addr_size(). That sounds to like you'd like a followup patch soon after this patch (my assumption would be within a few days or weeks) to solve your comments, not that you wanted a replacement patch. I will take that feedback to be a little more forceful in future, sorry. Why not just fix the bug since you said you could? That seems far better than breaking the newly added Tegra210 support. I do have a patch but I'm not 100% comfortable with the approach. I don't see a good reason to move away from the idea of fdt_addr_t and fdt_addr_t being set correctly for the platform. Or maybe I misunderstand the problem the patch was trying to fix. As I said it did not have a commit message, so who knows :-) The size of fdt_addr_t isn't relevant *at all* when parsing DT. The only thing that matters is #address-cells/#size-cells. Those properties are what tell the parsing code how many bytes to read from the reg property. Whether the resultant value fits into the code's internal representation is an internal detail of the code, not part of the semantics of DT itself or how to parse it. If code assumes that #address-cells == sizeof(fdt_addr_t), it is indeed quite likely that everything will just happen to work most of the time. However, this is purely an accident and not something that anything should rely upon. (I think Tegra210 support still has CONFIG_PHYS_64BIT undefined which is admittedly a little /unexpected/ for a 64-bit U-Boot build, but in practice is perfectly /legal/ and will work out just fine since, except perhaps for RAM sizes, I don't believe any value in DT will actually require more than 32-bits to represent) I would like to have the types match the platform where possible. At least the types should not be smaller than the platform - e.g. if CONFIG_PHYS_64BIT is not defined we should not support 64-bit In general, there's no should not here; we cannot. If there's a 64-bit value in the DT (with bits above bit 31 set), then it can't be stored in a 32-bit variable. That said, if a DT has #address-cells=2, but the actual values stored in all reg values have 0 for the MS word, that'll actually work just fine. Note that it's 100% legal to set #address-cells=100 and just write a bunch of extra zeros into the property. Silly perhaps, but perfectly legal. Since the function should adapt to whatever #address-cells value is in the DT, supporting that case isn't any more work, so there's no reason we shouldn't. address/size in the device tree. This is for efficiency. We don't want to force all the U-Boot code to
Re: [U-Boot] [Patch v3 1/2] lib/fdtdec: Fix fdt_addr_t and fdt_size_t typedef
On 3 August 2015 at 13:02, York Sun york...@freescale.com wrote: fdt_addr_t is a physical address. It can be either 64-bit or 32-bit, depending on the architecture. It should be phys_addr_t instead of u64 or u32. Similarly, fdt_size_t is changed to phys_size_t. Signed-off-by: York Sun york...@freescale.com CC: Simon Glass s...@chromium.org --- Change log v3: Rebase code to latest master, split into two patches. v2: Rebase code to latest master, add change to fsl_dspi.c. include/fdtdec.h |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dm: pmic: max77686: Correct two typos in a comment
These were pointed out in review but I missed them. Signed-off-by: Simon Glass s...@chromium.org --- drivers/power/regulator/max77686.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/power/regulator/max77686.c b/drivers/power/regulator/max77686.c index 946b87c..56ecbc1 100644 --- a/drivers/power/regulator/max77686.c +++ b/drivers/power/regulator/max77686.c @@ -87,8 +87,8 @@ static int max77686_buck_volt2hex(int buck, int uV) * hex = (uV - 75) / 5. We assume that dynamic voltage * scaling via GPIOs is not enabled and don't support that. * If this is enabled then the driver will need to take that -* into account anrd check different registers depending on -* the current setting See the datasheet for details. +* into account and check different registers depending on +* the current setting. See the datasheet for details. */ hex = (uV - MAX77686_BUCK_UV_HMIN) / MAX77686_BUCK_UV_HSTEP; hex_max = MAX77686_BUCK_VOLT_MAX_HEX; -- 2.5.0.rc2.392.g76e840b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/19] exynos: Add common board code for exynos5 boards that use device tree
Hi Prazemyslaw,
On 5 August 2015 at 08:16, Przemyslaw Marczak p.marc...@samsung.com wrote:
Hello Simon,
On 08/03/2015 04:19 PM, Simon Glass wrote:
Some boards use device tree for almost all board-specific configuration.
They therefore do not need their own separate board code, but can all use
the same version. Add a common version of the board code. It uses the
PMIC, regulator and video bridge uclasses. This will support smdk5250,
smdk5420, snow, spring, pit and pi.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
board/samsung/common/Makefile | 1 +
board/samsung/common/exynos5-dt.c | 362
++
2 files changed, 363 insertions(+)
create mode 100644 board/samsung/common/exynos5-dt.c
diff --git a/board/samsung/common/Makefile b/board/samsung/common/Makefile
index 5fb01ce..6cbd906 100644
--- a/board/samsung/common/Makefile
+++ b/board/samsung/common/Makefile
@@ -11,4 +11,5 @@ obj-$(CONFIG_MISC_COMMON) += misc.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_BOARD_COMMON)+= board.o
+obj-$(CONFIG_EXYNOS5_DT) += exynos5-dt.o
endif
diff --git a/board/samsung/common/exynos5-dt.c
b/board/samsung/common/exynos5-dt.c
new file mode 100644
index 000..7d1b88a
--- /dev/null
+++ b/board/samsung/common/exynos5-dt.c
@@ -0,0 +1,362 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include dwc3-uboot.h
+#include fdtdec.h
+#include asm/io.h
+#include errno.h
+#include i2c.h
+#include mmc.h
+#include netdev.h
+#include samsung-usb-phy-uboot.h
+#include spi.h
+#include usb.h
+#include video_bridge.h
+#include asm/gpio.h
+#include asm/arch/cpu.h
+#include asm/arch/dwmmc.h
+#include asm/arch/mmc.h
+#include asm/arch/pinmux.h
+#include asm/arch/power.h
+#include asm/arch/sromc.h
+#include power/pmic.h
+#include power/max77686_pmic.h
+#include power/regulator.h
+#include power/s5m8767.h
+#include tmu.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static void board_enable_audio_codec(void)
+{
+ int node, ret;
+ struct gpio_desc en_gpio;
+
+ node = fdtdec_next_compatible(gd-fdt_blob, 0,
+ COMPAT_SAMSUNG_EXYNOS5_SOUND);
+ if (node = 0)
+ return;
+
+ ret = gpio_request_by_name_nodev(gd-fdt_blob, node,
+codec-enable-gpio, 0, en_gpio,
+GPIOD_IS_OUT |
GPIOD_IS_OUT_ACTIVE);
+ if (ret == -FDT_ERR_NOTFOUND)
+ return;
+
+ /* Turn on the GPIO which connects to the codec's enable line.
*/
+ gpio_set_pull(gpio_get_number(en_gpio), S5P_GPIO_PULL_NONE);
+
+#ifdef CONFIG_SOUND_MAX98095
+ /* Enable MAX98095 Codec */
+ gpio_request(EXYNOS5_GPIO_X17, max98095_enable);
+ gpio_direction_output(EXYNOS5_GPIO_X17, 1);
+ gpio_set_pull(EXYNOS5_GPIO_X17, S5P_GPIO_PULL_NONE);
+#endif
+}
+
+int exynos_init(void)
+{
+ board_enable_audio_codec();
+
+ return 0;
+}
+
+static int exynos_set_regulator(const char *name, uint uv)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = regulator_get_by_platname(name, dev);
+ if (ret) {
+ debug(%s: Cannot find regulator %s\n, __func__, name);
+ return ret;
+ }
+ ret = regulator_set_value(dev, uv);
+ if (ret) {
+ debug(%s: Cannot set regulator %s\n, __func__, name);
+ return ret;
+ }
+
+ return 0;
+}
+
+int exynos_power_init(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = pmic_get(max77686, dev);
+ if (!ret) {
+ /* TODO(s...@chromium.org): Move into the clock/pmic API */
+ ret = pmic_clrsetbits(dev, MAX77686_REG_PMIC_32KHZ, 0,
+ MAX77686_32KHCP_EN);
+ if (ret)
+ return ret;
+ ret = pmic_clrsetbits(dev, MAX77686_REG_PMIC_BBAT, 0,
+ MAX77686_BBCHOSTEN | MAX77686_BBCVS_3_5V);
+ if (ret)
+ return ret;
+ } else {
+ ret = pmic_get(s5m8767-pmic, dev);
+ /* TODO(s...@chromium.org): Use driver model to access
clock */
+#ifdef CONFIG_PMIC_S5M8767
What about: if (dev) or if (!ret dev), instead of #ifdef?
+ if (!ret)
+ s5m8767_enable_32khz_cp(dev);
+#endif
Unfortunately s5m8767_enable_32khz_cp() doesn't go through driver
model so we can't call it if it is not compiled in. The correct fix
would be to add a clock device as a child of the PMIC and set that up
with the clock uclass. Later.
Applied to u-boot-dm.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] tpm: Initial work to introduce TPM driver model
drivers/tpm/tpm.c is a TPM core driver port from Linux.
So far in u-boot only infineon i2c driver is using it but it could fit
for others...
Introduce a new tpm uclass so that every TPM driver can register against it and
and take benefit of common functions and data such as tpm_transmit,
tpm_register_hardware tpm_remove_hardware.
Finally tis_init, tis_open, tis_close, tis_sendrecv are using ops allowing
to introduce proprietary instructions.
Also this patch convert tpm_i2c_infineon for using this tpm uclass.
Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
README | 8 +-
drivers/tpm/Makefile| 2 +-
drivers/tpm/tpm.c | 275 +++-
drivers/tpm/tpm_i2c_infineon.c | 271 ---
drivers/tpm/tpm_private.h | 23 ++-
include/dm/platform_data/tpm_i2c_infineon.h | 23 +++
include/dm/uclass-id.h | 1 +
7 files changed, 270 insertions(+), 333 deletions(-)
create mode 100644 include/dm/platform_data/tpm_i2c_infineon.h
diff --git a/README b/README
index a563aa1..506ff6c 100644
--- a/README
+++ b/README
@@ -1489,19 +1489,13 @@ The following options need to be configured:
Support for PWM modul on the imx6.
- TPM Support:
- CONFIG_TPM
+ CONFIG_DM_TPM
Support TPM devices.
CONFIG_TPM_I2C_INFINEON
Support for infineon i2c bus TPM devices. Only one device
per system is supported at this time.
- CONFIG_TPM_TIS_I2C_BUS_NUMBER
- Define the the i2c bus number for the TPM device
-
- CONFIG_TPM_TIS_I2C_SLAVE_ADDRESS
- Define the TPM's address on the i2c bus
-
CONFIG_TPM_TIS_I2C_BURST_LIMITATION
Define the burst count bytes upper limit
diff --git a/drivers/tpm/Makefile b/drivers/tpm/Makefile
index fea246f..bd2cd6d 100644
--- a/drivers/tpm/Makefile
+++ b/drivers/tpm/Makefile
@@ -5,7 +5,7 @@
# TODO: Merge tpm_tis_lpc.c with tpm.c
obj-$(CONFIG_TPM_ATMEL_TWI) += tpm_atmel_twi.o
-obj-$(CONFIG_TPM_TIS_I2C) += tpm.o
+obj-$(CONFIG_DM_TPM) += tpm.o
obj-$(CONFIG_TPM_INFINEON_I2C) += tpm_i2c_infineon.o
obj-$(CONFIG_TPM_TIS_LPC) += tpm_tis_lpc.o
obj-$(CONFIG_TPM_TIS_SANDBOX) += tpm_tis_sandbox.o
diff --git a/drivers/tpm/tpm.c b/drivers/tpm/tpm.c
index a650892..caf208d 100644
--- a/drivers/tpm/tpm.c
+++ b/drivers/tpm/tpm.c
@@ -36,8 +36,6 @@
#include common.h
#include dm.h
#include linux/compiler.h
-#include fdtdec.h
-#include i2c.h
#include tpm.h
#include asm-generic/errno.h
#include linux/types.h
@@ -47,21 +45,6 @@
DECLARE_GLOBAL_DATA_PTR;
-/* TPM configuration */
-struct tpm {
-#ifdef CONFIG_DM_I2C
- struct udevice *dev;
-#else
- int i2c_bus;
- int slave_addr;
- int old_bus;
-#endif
- char inited;
-} tpm;
-
-/* Global structure for tpm chip data */
-static struct tpm_chip g_chip;
-
enum tpm_duration {
TPM_SHORT = 0,
TPM_MEDIUM = 1,
@@ -375,14 +358,12 @@ static unsigned long tpm_calc_ordinal_duration(struct
tpm_chip *chip,
return duration;
}
-static ssize_t tpm_transmit(const unsigned char *buf, size_t bufsiz)
+static ssize_t tpm_transmit(struct tpm_chip *chip, const unsigned char *buf,
size_t bufsiz)
{
int rc;
u32 count, ordinal;
unsigned long start, stop;
- struct tpm_chip *chip = g_chip;
-
/* switch endianess: big-little */
count = get_unaligned_be32(buf + TPM_CMD_COUNT_BYTE);
ordinal = get_unaligned_be32(buf + TPM_CMD_ORDINAL_BYTE);
@@ -441,233 +422,102 @@ out:
return rc;
}
-#ifdef CONFIG_DM_I2C
-static int tpm_open_dev(struct udevice *dev)
-{
- int rc;
-
- debug(%s: start\n, __func__);
- if (g_chip.is_open)
- return -EBUSY;
- rc = tpm_vendor_init_dev(dev);
- if (rc 0)
- g_chip.is_open = 0;
- return rc;
-}
-#else
-static int tpm_open(uint32_t dev_addr)
-{
- int rc;
-
- if (g_chip.is_open)
- return -EBUSY;
- rc = tpm_vendor_init(dev_addr);
- if (rc 0)
- g_chip.is_open = 0;
- return rc;
-}
-#endif
-static void tpm_close(void)
-{
- if (g_chip.is_open) {
- tpm_vendor_cleanup(g_chip);
- g_chip.is_open = 0;
- }
-}
-
-static int tpm_select(void)
-{
-#ifndef CONFIG_DM_I2C
- int ret;
-
- tpm.old_bus = i2c_get_bus_num();
- if (tpm.old_bus != tpm.i2c_bus) {
- ret = i2c_set_bus_num(tpm.i2c_bus);
- if (ret) {
- debug(%s: Fail to set i2c bus %d\n, __func__,
- tpm.i2c_bus);
- return -1;
- }
- }
-#endif
- return 0;
-}
-
-static int
[U-Boot] [PATCH 3/3] tpm: Add st33zp24 tpm with i2c and spi phy
Add TPM st33zp24 tpm with i2c and spi phy. This is a port from Linux.
This driver relies on tpm uclass.
Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
README | 11 +
drivers/tpm/Makefile| 1 +
drivers/tpm/st33zp24/Makefile | 7 +
drivers/tpm/st33zp24/i2c.c | 226
drivers/tpm/st33zp24/spi.c | 286
drivers/tpm/st33zp24/st33zp24.c | 454
drivers/tpm/st33zp24/st33zp24.h | 29 ++
include/dm/platform_data/st33zp24_i2c.h | 28 ++
include/dm/platform_data/st33zp24_spi.h | 30 +++
include/fdtdec.h| 5 +-
lib/fdtdec.c| 2 +
11 files changed, 1078 insertions(+), 1 deletion(-)
create mode 100644 drivers/tpm/st33zp24/Makefile
create mode 100644 drivers/tpm/st33zp24/i2c.c
create mode 100644 drivers/tpm/st33zp24/spi.c
create mode 100644 drivers/tpm/st33zp24/st33zp24.c
create mode 100644 drivers/tpm/st33zp24/st33zp24.h
create mode 100644 include/dm/platform_data/st33zp24_i2c.h
create mode 100644 include/dm/platform_data/st33zp24_spi.h
diff --git a/README b/README
index 506ff6c..d3f9590 100644
--- a/README
+++ b/README
@@ -1499,6 +1499,17 @@ The following options need to be configured:
CONFIG_TPM_TIS_I2C_BURST_LIMITATION
Define the burst count bytes upper limit
+ CONFIG_TPM_ST33ZP24
+ Support for STMicroelectronics TPM devices. Requires DM_TPM
support.
+
+ CONFIG_TPM_ST33ZP24_I2C
+ Support for STMicroelectronics ST33ZP24 I2C devices.
+ Requires TPM_ST33ZP24 and I2C.
+
+ CONFIG_TPM_ST33ZP24_SPI
+ Support for STMicroelectronics ST33ZP24 SPI devices.
+ Requires TPM_ST33ZP24 and SPI.
+
CONFIG_TPM_ATMEL_TWI
Support for Atmel TWI TPM device. Requires I2C support.
diff --git a/drivers/tpm/Makefile b/drivers/tpm/Makefile
index bd2cd6d..48bc5f3 100644
--- a/drivers/tpm/Makefile
+++ b/drivers/tpm/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_DM_TPM) += tpm.o
obj-$(CONFIG_TPM_INFINEON_I2C) += tpm_i2c_infineon.o
obj-$(CONFIG_TPM_TIS_LPC) += tpm_tis_lpc.o
obj-$(CONFIG_TPM_TIS_SANDBOX) += tpm_tis_sandbox.o
+obj-$(CONFIG_TPM_ST33ZP24) += st33zp24/
diff --git a/drivers/tpm/st33zp24/Makefile b/drivers/tpm/st33zp24/Makefile
new file mode 100644
index 000..ed28e8c
--- /dev/null
+++ b/drivers/tpm/st33zp24/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for ST33ZP24 TPM 1.2 driver
+#
+
+obj-$(CONFIG_TPM_ST33ZP24) += st33zp24.o
+obj-$(CONFIG_TPM_ST33ZP24_I2C) += i2c.o
+obj-$(CONFIG_TPM_ST33ZP24_SPI) += spi.o
diff --git a/drivers/tpm/st33zp24/i2c.c b/drivers/tpm/st33zp24/i2c.c
new file mode 100644
index 000..204021a
--- /dev/null
+++ b/drivers/tpm/st33zp24/i2c.c
@@ -0,0 +1,226 @@
+/*
+ * STMicroelectronics TPM ST33ZP24 I2C phy for UBOOT
+ * Copyright (C) 2015 STMicroelectronics
+ *
+ * Description: Device driver for ST33ZP24 I2C TPM TCG.
+ *
+ * This device driver implements the TPM interface as defined in
+ * the TCG TPM Interface Spec version 1.21, revision 1.0 and the
+ * STMicroelectronics I2C Protocol Stack Specification version 1.2.0.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include i2c.h
+#include dm.h
+#include linux/types.h
+#include malloc.h
+#include tpm.h
+#include errno.h
+#include asm/unaligned.h
+#include dm/platform_data/st33zp24_i2c.h
+
+#include ../tpm_private.h
+#include st33zp24.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define TPM_DUMMY_BYTE 0xAA
+#define TPM_ST33ZP24_I2C_SLAVE_ADDR 0x13
+
+struct st33zp24_i2c_phy {
+ uint8_t slave_addr;
+ int i2c_bus;
+ int old_bus;
+ u8 buf[TPM_BUFSIZE + 1];
+} __packed;
+
+/*
+ * write8_reg
+ * Send byte to the TIS register according to the ST33ZP24 I2C protocol.
+ * @param: tpm_register, the tpm tis register where the data should be written
+ * @param: tpm_data, the tpm_data to write inside the tpm_register
+ * @param: tpm_size, The length of the data
+ * @return: Number of byte written successfully else an error code.
+ */
+static int write8_reg(void *phy_id, u8 tpm_register, u8 *tpm_data, u16
tpm_size)
+{
+ struct st33zp24_i2c_phy *phy = phy_id;
+ int ret;
+ phy-buf[0] = tpm_register;
+ memcpy(phy-buf + 1, tpm_data, tpm_size);
+ ret = i2c_write(phy-slave_addr, 0, 0, phy-buf, tpm_size + 1);
+ if (!ret)
+ return tpm_size + 1;
+ return ret;
+} /* write8_reg() */
+
+/*
+* read8_reg
+* Recv byte from the TIS register according to the ST33ZP24 I2C protocol.
+* @param: tpm_register, the tpm tis register where the data should be read
+* @param: tpm_data, the TPM response
+* @param: tpm_size, tpm TPM response size to read.
+* @return: Number of byte read successfully else an error code.
+*/
Re: [U-Boot] [PATCH v2 06/19] cros_ec: Support the LDO access method used by spring
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: Add a driver to support the special LDO access used by spring. This is a custom method in the cros_ec protocol - it does not use an I2C pass-through. There are two implementation choices: 1. Write a special LDO driver which can talk across the EC. Duplicate all the logic from TPS65090 for retrying when the LDO fails to come up. 2. Write a special I2C bus driver which pretends to be a TPS65090 and transfers reads and writes using the LDO message. Either is distasteful. The latter method is chosen since it results in less code duplication and a fairly simple (30-line) implementation of the core logic. The crosec 'ldo' subcommand could be removed (since i2c md/mw will work instead) but is retained as a convenience. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None drivers/i2c/Kconfig | 13 drivers/i2c/Makefile | 1 + drivers/i2c/cros_ec_ldo.c | 77 +++ drivers/misc/cros_ec.c| 21 +++-- include/cros_ec.h | 4 +-- 5 files changed, 104 insertions(+), 12 deletions(-) create mode 100644 drivers/i2c/cros_ec_ldo.c Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/19] dm: cros_ec: Convert the I2C tunnel code to use driver model
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: The Chrome OS EC supports tunnelling through to an I2C bus on the EC. This currently uses a copy of the I2C command code and a special 'crosec' sub-command. With driver model we can define an I2C bus which tunnels through to the EC, and use the normal 'i2c' command to access it. This simplifies the code and removes some duplication. Add an I2C driver which tunnels through to the EC. Adjust the EC code to support binding child devices so that it can be set up. Adjust the existing I2C xfer function to fit driver model better. For now the old code remains to allow things to still work. It will be removed in a later patch once the new flow is fully enabled. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None configs/peach-pi_defconfig| 2 + configs/peach-pit_defconfig | 2 + drivers/i2c/Kconfig | 11 + drivers/i2c/Makefile | 1 + drivers/i2c/cros_ec_tunnel.c | 41 +++ drivers/misc/cros_ec.c| 93 +-- drivers/power/pmic/pmic_tps65090_ec.c | 8 +-- include/cros_ec.h | 14 +- 8 files changed, 161 insertions(+), 11 deletions(-) create mode 100644 drivers/i2c/cros_ec_tunnel.c Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] tpm: Move tpm_tis_i2c to tpm_i2c_infineon
As there is no TCG specification or recommendation for i2c TPM 1.2, move
tpm_tis_i2c driver to tpm_i2c_infineon. Other tpm vendors like atmel or
stmicroelectronics may have a different transport protocol for i2c.
Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
README| 4 ++--
drivers/tpm/Makefile | 2 +-
drivers/tpm/{tpm_tis_i2c.c = tpm_i2c_infineon.c} | 0
3 files changed, 3 insertions(+), 3 deletions(-)
rename drivers/tpm/{tpm_tis_i2c.c = tpm_i2c_infineon.c} (100%)
diff --git a/README b/README
index 1bcb63c..a563aa1 100644
--- a/README
+++ b/README
@@ -1492,8 +1492,8 @@ The following options need to be configured:
CONFIG_TPM
Support TPM devices.
- CONFIG_TPM_TIS_I2C
- Support for i2c bus TPM devices. Only one device
+ CONFIG_TPM_I2C_INFINEON
+ Support for infineon i2c bus TPM devices. Only one device
per system is supported at this time.
CONFIG_TPM_TIS_I2C_BUS_NUMBER
diff --git a/drivers/tpm/Makefile b/drivers/tpm/Makefile
index 150570e..fea246f 100644
--- a/drivers/tpm/Makefile
+++ b/drivers/tpm/Makefile
@@ -6,6 +6,6 @@
# TODO: Merge tpm_tis_lpc.c with tpm.c
obj-$(CONFIG_TPM_ATMEL_TWI) += tpm_atmel_twi.o
obj-$(CONFIG_TPM_TIS_I2C) += tpm.o
-obj-$(CONFIG_TPM_TIS_I2C) += tpm_tis_i2c.o
+obj-$(CONFIG_TPM_INFINEON_I2C) += tpm_i2c_infineon.o
obj-$(CONFIG_TPM_TIS_LPC) += tpm_tis_lpc.o
obj-$(CONFIG_TPM_TIS_SANDBOX) += tpm_tis_sandbox.o
diff --git a/drivers/tpm/tpm_tis_i2c.c b/drivers/tpm/tpm_i2c_infineon.c
similarity index 100%
rename from drivers/tpm/tpm_tis_i2c.c
rename to drivers/tpm/tpm_i2c_infineon.c
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] Introduce TPM driver model and STMicroelectronics ST33ZP24 TPMs
Hi,
This patch serie introduce TPM driver model allowing to instantiate a TPM
using U_BOOT_DEVICE macro for platform_data or device tree.
As an information, there is no TCG transport protocol official specification
for i2c for TPM1.2. The TPM uclass allows to support different kind of bus
(LPC, I2C, SPI) keeping the TPM command duration in common.
Also, this serie introduce TPM1.2 from STMicroelectronics ST33ZP24 with
I2C and SPI support. It has been ported from existing Linux drivers.
This has been tested on Beagleboard xM.
Best Regards
Christophe
Christophe Ricard (3):
tpm: Move tpm_tis_i2c to tpm_i2c_infineon
tpm: Initial work to introduce TPM driver model
tpm: Add st33zp24 tpm with i2c and spi phy
README| 23 +-
drivers/tpm/Makefile | 5 +-
drivers/tpm/st33zp24/Makefile | 7 +
drivers/tpm/st33zp24/i2c.c| 226 +++
drivers/tpm/st33zp24/spi.c| 286 ++
drivers/tpm/st33zp24/st33zp24.c | 454 ++
drivers/tpm/st33zp24/st33zp24.h | 29 ++
drivers/tpm/tpm.c | 275 +++--
drivers/tpm/{tpm_tis_i2c.c = tpm_i2c_infineon.c} | 271 -
drivers/tpm/tpm_private.h | 23 +-
include/dm/platform_data/st33zp24_i2c.h | 28 ++
include/dm/platform_data/st33zp24_spi.h | 30 ++
include/dm/platform_data/tpm_i2c_infineon.h | 23 ++
include/dm/uclass-id.h| 1 +
include/fdtdec.h | 5 +-
lib/fdtdec.c | 2 +
16 files changed, 1351 insertions(+), 337 deletions(-)
create mode 100644 drivers/tpm/st33zp24/Makefile
create mode 100644 drivers/tpm/st33zp24/i2c.c
create mode 100644 drivers/tpm/st33zp24/spi.c
create mode 100644 drivers/tpm/st33zp24/st33zp24.c
create mode 100644 drivers/tpm/st33zp24/st33zp24.h
rename drivers/tpm/{tpm_tis_i2c.c = tpm_i2c_infineon.c} (70%)
create mode 100644 include/dm/platform_data/st33zp24_i2c.h
create mode 100644 include/dm/platform_data/st33zp24_spi.h
create mode 100644 include/dm/platform_data/tpm_i2c_infineon.h
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Introduce TPM driver model and STMicroelectronics ST33ZP24 TPMs
Hi Chrstophe,
On 9 August 2015 at 08:19, Christophe Ricard
christophe.ric...@gmail.com wrote:
Hi Simon,
Thanks for pointing me to the right tree and branch. I missed that :-(.
Well I was hoping to send patches next week. I should have sent an
email to the list before starting.
I will go and look at your on-going work and try to fit our STM drivers.
I will be happy to co-work on this.
Great. I'll tidy this up and send out the patches early next week.
Regards,
Simon
Best regards
Christophe
Le dim. 9 août 2015 15:28, Simon Glass s...@chromium.org a écrit :
Hi Christophe,
On 9 August 2015 at 07:19, Christophe Ricard
christophe.ric...@gmail.com wrote:
Hi,
This patch serie introduce TPM driver model allowing to instantiate a
TPM
using U_BOOT_DEVICE macro for platform_data or device tree.
As an information, there is no TCG transport protocol official
specification
for i2c for TPM1.2. The TPM uclass allows to support different kind of
bus
(LPC, I2C, SPI) keeping the TPM command duration in common.
Also, this serie introduce TPM1.2 from STMicroelectronics ST33ZP24 with
I2C and SPI support. It has been ported from existing Linux drivers.
This has been tested on Beagleboard xM.
As it happens I have just been trying to clean up the TPM drivers for
Kconfig and driver model.
Please see u-boot-dm branch tpm-working. I'll hurry up and try to send
out some patches and update the wiki. I wonder if we can join our work
somehow?
Regards,
Simon
Best Regards
Christophe
Christophe Ricard (3):
tpm: Move tpm_tis_i2c to tpm_i2c_infineon
tpm: Initial work to introduce TPM driver model
tpm: Add st33zp24 tpm with i2c and spi phy
README| 23 +-
drivers/tpm/Makefile | 5 +-
drivers/tpm/st33zp24/Makefile | 7 +
drivers/tpm/st33zp24/i2c.c| 226 +++
drivers/tpm/st33zp24/spi.c| 286 ++
drivers/tpm/st33zp24/st33zp24.c | 454
++
drivers/tpm/st33zp24/st33zp24.h | 29 ++
drivers/tpm/tpm.c | 275 +++--
drivers/tpm/{tpm_tis_i2c.c = tpm_i2c_infineon.c} | 271 -
drivers/tpm/tpm_private.h | 23 +-
include/dm/platform_data/st33zp24_i2c.h | 28 ++
include/dm/platform_data/st33zp24_spi.h | 30 ++
include/dm/platform_data/tpm_i2c_infineon.h | 23 ++
include/dm/uclass-id.h| 1 +
include/fdtdec.h | 5 +-
lib/fdtdec.c | 2 +
16 files changed, 1351 insertions(+), 337 deletions(-)
create mode 100644 drivers/tpm/st33zp24/Makefile
create mode 100644 drivers/tpm/st33zp24/i2c.c
create mode 100644 drivers/tpm/st33zp24/spi.c
create mode 100644 drivers/tpm/st33zp24/st33zp24.c
create mode 100644 drivers/tpm/st33zp24/st33zp24.h
rename drivers/tpm/{tpm_tis_i2c.c = tpm_i2c_infineon.c} (70%)
create mode 100644 include/dm/platform_data/st33zp24_i2c.h
create mode 100644 include/dm/platform_data/st33zp24_spi.h
create mode 100644 include/dm/platform_data/tpm_i2c_infineon.h
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/9] dfu: tftp: update: Provide tftp support for the DFU subsystem
Hi Simon, Hi Lukasz, On 25 July 2015 at 02:11, Lukasz Majewski l.majew...@majess.pl wrote: This commit adds initial support for using tftp for downloading and upgrading firmware on the device. Signed-off-by: Lukasz Majewski l.majew...@majess.pl --- Changes for v2: - Return -ENOSYS instead of plain -1 - Remove interface and devstring env variables reading in the dfu_tftp_write() - Those parameters are now passed to dfu_tftp_write() function as its arguments --- drivers/dfu/Makefile | 1 + drivers/dfu/dfu_tftp.c | 65 ++ include/dfu.h | 13 ++ 3 files changed, 79 insertions(+) create mode 100644 drivers/dfu/dfu_tftp.c Is there a Kconfig option needed here? I will add proper Kconfig option for this code in the following patch: [PATCH v2 8/9] config: bbb: Configs necessary for running update via TFTP on Beagle Bone Black IMHO this patch is a better place to do that. Regards, Simon Best regards, Lukasz Majewski pgpnL2XmODoH5.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [V4 1/2] sf: Add clear flag status register operation on Micron chips
-Original Message-
From: Jagan Teki [mailto:jt...@openedev.com]
Sent: 2015年8月7日 16:22
To: Hou Zhiqiang-B48286
Cc: u-boot@lists.denx.de; Hu Mingkai-B21284
Subject: Re: [U-Boot] [V4 1/2] sf: Add clear flag status register
operation on Micron chips
On 23 July 2015 at 15:24, Zhiqiang Hou b48...@freescale.com wrote:
From: Hou Zhiqiang b48...@freescale.com
Add clear flag status register operation that was required by Micron
SPI flash chips after reading the flag status register to check if the
erase and program operations complete or an error occur.
Flag status requires N25Q512 + parts, so clear flag status we need add
only in this scenario is that true?
Yes, so the clear FSR operation will work only if the chip supports FSR.
And if the chip supports FSR, it will support both read and clear FSR.
So there is a condition branch if (cmd == CMD_FLAG_STATUS).
Signed-off-by: Hou Zhiqiang b48...@freescale.com
Signed-off-by: Mingkai.Hu mingkai...@freescale.com
---
drivers/mtd/spi/sf_internal.h | 9 +
drivers/mtd/spi/sf_ops.c | 40 ---
-
2 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h
b/drivers/mtd/spi/sf_internal.h index 9fb5557..703d4a7 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -73,6 +73,7 @@ enum {
#define CMD_WRITE_ENABLE 0x06
#define CMD_READ_CONFIG0x35
#define CMD_FLAG_STATUS0x70
+#define CMD_CLEAR_FLAG_STATUS 0x50
/* Read commands */
#define CMD_READ_ARRAY_SLOW0x03
@@ -96,6 +97,8 @@ enum {
#define STATUS_QEB_WINSPAN (1 1)
#define STATUS_QEB_MXIC(1 6)
#define STATUS_PEC (1 7)
+#define STATUS_PROT(1 1)
+#define STATUS_ERASE (1 5)
/* Flash timeout values */
#define SPI_FLASH_PROG_TIMEOUT (2 * CONFIG_SYS_HZ)
@@ -182,6 +185,12 @@ static inline int
spi_flash_cmd_write_disable(struct spi_flash *flash)
return spi_flash_cmd(flash-spi, CMD_WRITE_DISABLE, NULL, 0);
}
+/* Clear flag status register */
+static inline int spi_flash_cmd_clear_flag_status(struct spi_slave
+*spi) {
+ return spi_flash_cmd(spi, CMD_CLEAR_FLAG_STATUS, NULL, 0); }
+
/*
* Send the read status command to the device and wait for the wip
* (write-in-progress) bit to clear itself.
diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c index
38592f5..cbb9f00 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -160,6 +160,7 @@ static int spi_flash_poll_status(struct spi_slave
*spi, unsigned long timeout,
unsigned long timebase;
unsigned long flags = SPI_XFER_BEGIN;
int ret;
+ int out_of_time = 1;
u8 status;
u8 check_status = 0x0;
@@ -182,22 +183,45 @@ static int spi_flash_poll_status(struct spi_slave
*spi, unsigned long timeout,
WATCHDOG_RESET();
ret = spi_xfer(spi, 8, NULL, status, 0);
- if (ret)
+ if (ret) {
+ spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
return -1;
+ }
- if ((status poll_bit) == check_status)
+ if ((status poll_bit) == check_status) {
+ out_of_time = 0;
break;
+ }
} while (get_timer(timebase) timeout);
spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
- if ((status poll_bit) == check_status)
- return 0;
+ if (out_of_time) {
+ /* Timed out */
+ debug(SF: time out!\n);
+ if (cmd == CMD_FLAG_STATUS) {
+ if (spi_flash_cmd_clear_flag_status(spi) 0)
+ debug(SF: clear flag status failed\n);
+ }
+ ret = -1;
+ }
+#ifdef CONFIG_SPI_FLASH_STMICRO
+ else if (cmd == CMD_FLAG_STATUS) {
+ if (!(status (STATUS_PROT | STATUS_ERASE))) {
+ ret = 0;
+ } else {
+ debug(SF: flag status error);
+ ret = -1;
+ }
- /* Timed out */
- debug(SF: time out!\n);
- return -1;
+ if (spi_flash_cmd_clear_flag_status(spi) 0) {
+ debug(SF: clear flag status failed\n);
+ ret = -1;
+ }
+ }
+#endif
+ return ret;
}
int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long
timeout) @@ -252,7 +276,7 @@ int spi_flash_write_common(struct
spi_flash *flash, const u8 *cmd,
ret = spi_flash_cmd_wait_ready(flash,
Re: [U-Boot] [V4 2/2] sf: Turn SPI flash into 3-Byte address mode on Micron chips
Hi Jagan,
Do you have any feedback?
-Original Message-
From: Zhiqiang Hou [mailto:b48...@freescale.com]
Sent: 2015年7月23日 17:54
To: u-boot@lists.denx.de; jt...@openedev.com
Cc: Sun York-R58495; Hu Mingkai-B21284; Hou Zhiqiang-B48286
Subject: [V4 2/2] sf: Turn SPI flash into 3-Byte address mode on Micron
chips
From: Hou Zhiqiang b48...@freescale.com
For more than 16MiB Micron chips, there are 3-Byte and 4-Byte address
mode, and only the 3-Byte address mode is supported in u-boot.
So, reset the SPI flash to 3-Byte address mode in probe to ensure the SPI
flash work correctly, because it may be in 4-Byte address mode after warm
boot.
Signed-off-by: Hou Zhiqiang b48...@freescale.com
---
drivers/mtd/spi/sf_internal.h | 8
drivers/mtd/spi/sf_ops.c | 24
drivers/mtd/spi/sf_probe.c| 5 +
3 files changed, 37 insertions(+)
diff --git a/drivers/mtd/spi/sf_internal.h
b/drivers/mtd/spi/sf_internal.h index 703d4a7..3d7ed24 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -75,6 +75,10 @@ enum {
#define CMD_FLAG_STATUS 0x70
#define CMD_CLEAR_FLAG_STATUS0x50
+/* Used for Macronix and Winbond flashes */
+#define CMD_ENTER_4B_ADDR 0xB7
+#define CMD_EXIT_4B_ADDR0xE9
+
/* Read commands */
#define CMD_READ_ARRAY_SLOW 0x03
#define CMD_READ_ARRAY_FAST 0x0b
@@ -227,6 +231,10 @@ int spi_flash_read_common(struct spi_flash *flash,
const u8 *cmd, int spi_flash_cmd_read_ops(struct spi_flash *flash, u32
offset,
size_t len, void *data);
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+int spi_flash_cmd_4B_addr_switch(struct spi_flash *flash, int enable);
+#endif
+
#ifdef CONFIG_SPI_FLASH_MTD
int spi_flash_mtd_register(struct spi_flash *flash); void
spi_flash_mtd_unregister(void); diff --git a/drivers/mtd/spi/sf_ops.c
b/drivers/mtd/spi/sf_ops.c index cbb9f00..1ce14d1 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -93,6 +93,30 @@ int spi_flash_cmd_write_config(struct spi_flash *flash,
u8 wc) } #endif
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+int spi_flash_cmd_4B_addr_switch(struct spi_flash *flash, int enable) {
+ int ret;
+ u8 cmd;
+
+ cmd = enable ? CMD_ENTER_4B_ADDR : CMD_EXIT_4B_ADDR;
+
+ ret = spi_claim_bus(flash-spi);
+ if (ret) {
+ debug(SF: unable to claim SPI bus\n);
+ return ret;
+ }
+
+ ret = spi_flash_cmd_write_enable(flash);
+ if (ret 0) {
+ debug(SF: enabling write failed\n);
+ return ret;
+ }
+
+ return spi_flash_cmd(flash-spi, cmd, NULL, 0); } #endif
+
#ifdef CONFIG_SPI_FLASH_BAR
static int spi_flash_cmd_bankaddr_write(struct spi_flash *flash, u8
bank_sel) { diff --git a/drivers/mtd/spi/sf_probe.c
b/drivers/mtd/spi/sf_probe.c index e0283dc..5ba7dde 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -231,6 +231,11 @@ static int spi_flash_validate_params(struct
spi_slave *spi, u8 *idcode, #ifdef CONFIG_SPI_FLASH_STMICRO
if (params-flags E_FSR)
flash-poll_cmd = CMD_FLAG_STATUS;
+
+ if (flash-size SPI_FLASH_16MB_BOUN) {
+ if (spi_flash_cmd_4B_addr_switch(flash, 0) 0)
+ debug(SF: enter 3B address mode failed\n);
+ }
#endif
/* Configure the BAR - discover bank cmds and read current bank */
--
2.1.0.27.g96db324
Thanks,
Zhiqiang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] add dfu support for at91 sam9260 based boards
Hello Marek, Am 21.07.2015 um 04:03 schrieb Marek Vasut: On Monday, July 20, 2015 at 04:03:08 PM, Lukasz Majewski wrote: Hi Marek, add dfu supprt for at91 sam9260 based boards. The USB gadget driver is ported from linux: b2ba27a5c56ff: usb: gadget: at91_udc: move prepare clk into process context it drops a lot of checkpatch warnings/errors: checkpatch.pl found 12 error(s), 31 warning(s), 43 checks(s) but for further updates I did not fix them. The errors are all from this sort: error: drivers/usb/gadget/at91_udc.c,87: space prohibited before open square bracket '[' a lot of line over 80 characters warnings ... Heiko Schocher (3): ARM: at91: add cpu.h usb: gadget: at91_udc: add support for at91_udc at91, taurus, smartweb: add dfu support Marek, do you plan to review this patch series? (I would need at least one review before I pull the code). I took a brief look. One thing I don't quite like is the omnipresent #ifdef __UBOOT__ stuff. I'd much rather love to see some kind of a porting layer so the driver can just be picked from linux as-is, but that might be too much hassle. Yes, such a layer would be beautiful, but it is possible? We have no processes/task switching in U-Boot ... a lot of board do not use irqs ... Otherwise, I'm fine with it, though I nitpicked a bit. I just prepare a v2 ... bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] usb: gadget: at91_udc: add support for at91_udc
Hello Luaksz, Am 21.07.2015 um 08:59 schrieb Lukasz Majewski: Hi Heiko, ported from linux: b2ba27a5c56ff: usb: gadget: at91_udc: move prepare clk into process context IMHO, presented above description is not enough. I'd prefer to see one patch which adds the code from linux - including the exact commit message. Ok, I change this. Then, u-boot specific adjustments should be applied in a separate patch. In that way you would: 1. Avoid #ifdef __UBOOT__ Hmm.. I change this, but I do not hate this define, if I debug in the Code I immediately see, if it is linux code, or U-Boot specific ... we had such a discussion also on other places ... maybe we need here a decision, if we remove this define complete? 2. Make the process of updating code easier I soon post a v2, just did a rebase and found some compile errors for the smartweb board ... bye, Heiko Signed-off-by: Heiko Schocher h...@denx.de --- checkpatch detects a lot of errors, but as this code is copied from linux, I tend to not fix them, so later updates with linux code is easier. drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/at91_udc.c | 2203 + drivers/usb/gadget/at91_udc.h | 171 include/linux/usb/at91_udc.h | 20 + 4 files changed, 2395 insertions(+) create mode 100644 drivers/usb/gadget/at91_udc.c create mode 100644 drivers/usb/gadget/at91_udc.h create mode 100644 include/linux/usb/at91_udc.h diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 70bb550..22323fa 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_USB_ETHER) += epautoconf.o config.o usbstring.o # new USB gadget layer dependencies ifdef CONFIG_USB_GADGET +obj-$(CONFIG_USB_GADGET_AT91) += at91_udc.o obj-$(CONFIG_USB_GADGET_ATMEL_USBA) += atmel_usba_udc.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 diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c new file mode 100644 index 000..f4ae13b --- /dev/null +++ b/drivers/usb/gadget/at91_udc.c @@ -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH resend V2 1/3] mtd: nand: mxs support oobsize bigger than 512
Hi Scott, Do you have plan to pick the 3 patches? https://patchwork.ozlabs.org/patch/498050/ https://patchwork.ozlabs.org/patch/498049/ https://patchwork.ozlabs.org/patch/498048/ If not, then I prefer these 3 patches can go throught i.mx tree. Thanks, Peng. On Sun, Aug 02, 2015 at 11:18:38AM +0800, Peng Fan wrote: On Sat, Aug 01, 2015 at 01:54:48PM -0500, Scott Wood wrote: On Sat, 2015-08-01 at 20:38 +0200, Marek Vasut wrote: On Saturday, August 01, 2015 at 08:32:07 PM, Scott Wood wrote: On Sat, 2015-08-01 at 17:18 +0200, Marek Vasut wrote: On Saturday, August 01, 2015 at 07:56:39 AM, Peng Fan wrote: On Fri, Jul 31, 2015 at 09:36:45PM -0500, Scott Wood wrote: On Sat, 2015-08-01 at 09:15 +0800, Peng Fan wrote: On Fri, Jul 31, 2015 at 12:07:50PM -0500, Scott Wood wrote: On Tue, 2015-07-21 at 16:15 +0800, Peng Fan wrote: If ecc chunk data size is 512 and oobsize is bigger than 512, there is a chance that block_mark_bit_offset conflicts with bch ecc area. The following graph is modified from kernel gpmi-nand.c driver with each data block 512 bytes. We can see that Block Mark conflicts with ecc area from bch view. We can enlarge the ecc chunk size to avoid this problem to those oobsize which is larger than 512. Enlarge it by how much? What does the layout look like in that case? Enlarge it to 1024 bytes. Then say so in the changelog. You mean I need to add this in commit msg and send out a new patch version? Or you pick this one? This discussion is becoming ridiculous, can we please get this bugfix applied ? If you don't like some minor details in the commit message, can you please fix them while applying ? Yes, I can edit the changelog while applying, but that doesn't mean I'm not going to complain about a difficult-to-understand changelog, and I still would like to understand what is actually going on here. Don't assume I'm familiar with this hardware or its unusual page layout. You can help by explaining things, or you can not help by throwing a fit... I can point you to MX28 datasheet [1] chapter 16.2.2 and onward if you want to educate yourself, it's all explained there, concisely and clearly. [1] http://free-electrons.com/~maxime/pub/datasheet/MCIMX28RM.pdf Thanks. That preempted a question I was just about to ask Peng, because it wasn't clear that the meta area was covered by ECC. In mxs_nand.c driver, we use Combined Metadata Block 0, unbalanced ECC coverage layout from chapter 16.2.2 of MX28 datasheet. Peng. -Scott -- -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/2] Rename DDR4 target names
Hello York,
T1040D4RDB/T1042D4RDB boards have other difference as well apart from DDR4
w.r.t old T1040RDB/T1042RDB.
T1040D4RDB/T1042D4RDB is the naming convection that has been used to
distinguished new T1040RDB/T1042RDB board with DDR4 memory, new serdes protocol
support , new muxes , etc.
If the only difference would have been DDR4, then we could have renamed to
T1040RDB_DDR4 board.
But at this moment, the name T1040D4RDB is printed on the new boards and has
been used in all board, SDK related documentation for these new boards.
I think renaming them to T1040RDB_DDR4 will create confusion.
Regards
Priyanka
-Original Message-
From: York Sun [mailto:york...@freescale.com]
Sent: Friday, August 07, 2015 5:00 AM
To: U-Boot Mailing List
Cc: Wood Scott-B07421; Sun York-R58495; Stephen Warren; Masahiro
Yamada; Tom Rini; Joe Hershberger; Aggrwal Poonam-B10812; Jain Priyanka-
B32167; Liu Shengzhou-B36685
Subject: [PATCH v1 0/2] Rename DDR4 target names
Freescale T1 series supports both DDR3 and DDR4. We have boards for each
type of memory. To make the naming consistence and easy to understand,
use _DDR4 instead of _D4 for the names. The same applies to Layerscape
LS1 series, which already has _ddr4 in the name. LS2 series doesn't support
DDR3, so the emulator target for DDR3 is dropped.
York Sun (2):
armv8/ls2085a_emu: Drop DDR3 emulation target
powerpc/defconfig: Rename defconfig file for DDR4 targets
board/freescale/ls2085a/MAINTAINERS|1 -
board/freescale/t102xqds/MAINTAINERS |4 ++--
board/freescale/t1040qds/MAINTAINERS |2 +-
board/freescale/t104xrdb/MAINTAINERS | 20
++--
...fconfig = T1024QDS_DDR4_SECURE_BOOT_defconfig} |0
...040QDS_D4_defconfig = T1040QDS_DDR4_defconfig} |0
...NAND_defconfig = T1040RDB_DDR4_NAND_defconfig} |0
...RD_defconfig = T1040RDB_DDR4_SDCARD_defconfig} |0
...fconfig = T1040RDB_DDR4_SECURE_BOOT_defconfig} |0
..._defconfig = T1040RDB_DDR4_SPIFLASH_defconfig} |0
...1040D4RDB_defconfig = T1040RDB_DDR4_defconfig} |0
...NAND_defconfig = T1042RDB_DDR4_NAND_defconfig} |0
...RD_defconfig = T1042RDB_DDR4_SDCARD_defconfig} |0
...fconfig = T1042RDB_DDR4_SECURE_BOOT_defconfig} |0
..._defconfig = T1042RDB_DDR4_SPIFLASH_defconfig} |0
...1042D4RDB_defconfig = T1042RDB_DDR4_defconfig} |0
configs/ls2085a_emu_D4_defconfig | 14 --
configs/ls2085a_emu_defconfig |2 +-
18 files changed, 14 insertions(+), 29 deletions(-) rename
configs/{T1024QDS_D4_SECURE_BOOT_defconfig =
T1024QDS_DDR4_SECURE_BOOT_defconfig} (100%) rename
configs/{T1040QDS_D4_defconfig = T1040QDS_DDR4_defconfig} (100%)
rename configs/{T1040D4RDB_NAND_defconfig =
T1040RDB_DDR4_NAND_defconfig} (100%) rename
configs/{T1040D4RDB_SDCARD_defconfig =
T1040RDB_DDR4_SDCARD_defconfig} (100%) rename
configs/{T1040D4RDB_SECURE_BOOT_defconfig =
T1040RDB_DDR4_SECURE_BOOT_defconfig} (100%) rename
configs/{T1040D4RDB_SPIFLASH_defconfig =
T1040RDB_DDR4_SPIFLASH_defconfig} (100%) rename
configs/{T1040D4RDB_defconfig = T1040RDB_DDR4_defconfig} (100%)
rename configs/{T1042D4RDB_NAND_defconfig =
T1042RDB_DDR4_NAND_defconfig} (100%) rename
configs/{T1042D4RDB_SDCARD_defconfig =
T1042RDB_DDR4_SDCARD_defconfig} (100%) rename
configs/{T1042D4RDB_SECURE_BOOT_defconfig =
T1042RDB_DDR4_SECURE_BOOT_defconfig} (100%) rename
configs/{T1042D4RDB_SPIFLASH_defconfig =
T1042RDB_DDR4_SPIFLASH_defconfig} (100%) rename
configs/{T1042D4RDB_defconfig = T1042RDB_DDR4_defconfig} (100%)
delete mode 100644 configs/ls2085a_emu_D4_defconfig
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/19] cros_ec: Remove the old tunnel code
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: This is not needed with driver mode. Remove it. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None drivers/misc/cros_ec.c | 268 + include/cros_ec.h | 14 --- 2 files changed, 1 insertion(+), 281 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/19] dm: pmic: max77686: Support all BUCK regulators
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: Add support for all BUCK regulators, now that the correct register is accessed for each. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Add a comment about DVS in the driver drivers/power/regulator/max77686.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/19] video: Remove the old parade driver
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: We have a new one which uses driver model and device tree configuration. Remove the old one. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None drivers/video/Makefile | 1 - drivers/video/parade.c | 231 include/configs/peach-pi.h | 2 - include/configs/peach-pit.h | 2 - include/fdtdec.h| 1 - include/parade.h| 18 lib/fdtdec.c| 1 - 7 files changed, 256 deletions(-) delete mode 100644 drivers/video/parade.c delete mode 100644 include/parade.h Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 19/19] exynos: Add support for spring
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: Spring is the first ARM-based HP Chromebook 11. It is similar to snow and it uses the same Samsung Exynos5250 chip. But has some unusual features. Mainline support for it has lagged snow (both in kernel and U-Boot). Now that the exynos5 code is common we can support spring just by adding a device tree and a few lines of configuration. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Rebase to dm/master arch/arm/cpu/armv7/exynos/Kconfig | 6 + arch/arm/dts/Makefile | 1 + arch/arm/dts/exynos5250-spring.dts | 588 + board/samsung/smdk5250/Kconfig | 13 + board/samsung/smdk5250/MAINTAINERS | 6 + configs/spring_defconfig | 42 +++ include/configs/spring.h | 20 ++ 7 files changed, 676 insertions(+) create mode 100644 arch/arm/dts/exynos5250-spring.dts create mode 100644 configs/spring_defconfig create mode 100644 include/configs/spring.h Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 17/19] dts: Drop unused compatible ID for the NXP video bridge
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: This has moved to driver model so we can drop the fdtdec support. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None include/fdtdec.h | 1 - lib/fdtdec.c | 1 - 2 files changed, 2 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 18/19] exynos: video: Remove non-device-tree code
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: We always use device tree on exynos, so remove the unused code. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None arch/arm/include/asm/arch-exynos/dp_info.h | 2 -- drivers/video/exynos_dp.c | 22 -- 2 files changed, 24 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/19] exynos: Enable new features for exynos5 boards
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: Enable PMICs, regulators and the like so that new drivers will be made available. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None board/samsung/smdk5420/smdk5420.c | 2 +- configs/arndale_defconfig | 2 ++ configs/odroid-xu3_defconfig| 6 ++ configs/peach-pi_defconfig | 17 + configs/peach-pit_defconfig | 17 + configs/smdk5250_defconfig | 10 ++ configs/smdk5420_defconfig | 6 ++ configs/snow_defconfig | 23 +++ include/configs/arndale.h | 4 include/configs/exynos5-common.h| 10 ++ include/configs/exynos5-dt-common.h | 5 - include/configs/smdk5250.h | 3 --- include/configs/snow.h | 3 --- 13 files changed, 88 insertions(+), 20 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/19] exynos: Drop old exynos5250-specific board code
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: Now that most exynos5250 boards can use the generic exynos5 code, switch over to it and remove the old code. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None board/samsung/smdk5250/Makefile | 4 - board/samsung/smdk5250/exynos5-dt.c | 306 include/configs/exynos5-dt-common.h | 2 + 3 files changed, 2 insertions(+), 310 deletions(-) delete mode 100644 board/samsung/smdk5250/exynos5-dt.c Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/19] power: Remove old TPS65090 drivers
On 3 August 2015 at 08:19, Simon Glass s...@chromium.org wrote: Remove the old drivers (both the normal one and the cros_ec one) now that we have new drivers that use driver model. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None drivers/power/pmic/Makefile | 2 - drivers/power/pmic/pmic_tps65090.c| 310 -- drivers/power/pmic/pmic_tps65090_ec.c | 218 include/configs/peach-pit.h | 2 - include/fdtdec.h | 1 - include/power/tps65090_pmic.h | 73 lib/fdtdec.c | 1 - 7 files changed, 607 deletions(-) delete mode 100644 drivers/power/pmic/pmic_tps65090.c delete mode 100644 drivers/power/pmic/pmic_tps65090_ec.c delete mode 100644 include/power/tps65090_pmic.h Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cm5200: fix FAT function prototypes
Remove FAT function prototypes from the cm5200 firmware update code, and
include the relevant headers instead.
This exposes the fact that the custom prototyoe for do_fat_read() in
this file was incorrect. Rather than simply fixing the call-site, replace
do_fat_read() with fat_exists(). This removes the only use of
do_fat_read() outside of the FAT code.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
This should be applied before the series I posted that swaps out the FAT
filesystem implementation for ff.c.
---
board/cm5200/fwupdate.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/board/cm5200/fwupdate.c b/board/cm5200/fwupdate.c
index 06d50234e9ab..2b923624aea1 100644
--- a/board/cm5200/fwupdate.c
+++ b/board/cm5200/fwupdate.c
@@ -12,6 +12,7 @@
#include common.h
#include command.h
+#include fat.h
#include malloc.h
#include image.h
#include usb.h
@@ -19,9 +20,6 @@
#include fwupdate.h
-extern long do_fat_read(const char *, void *, unsigned long, int);
-extern int do_fat_fsload(cmd_tbl_t *, int, int, char * const []);
-
static int load_rescue_image(ulong);
void cm5200_fwupdate(void)
@@ -124,7 +122,7 @@ static int load_rescue_image(ulong addr)
/* Check if rescue image is present */
FW_DEBUG(Looking for firmware directory '%s'
on partition %d\n, fwdir, i);
- if (do_fat_read(fwdir, NULL, 0, LS_NO) == -1) {
+ if (!fat_exists(fwdir)) {
FW_DEBUG(No NX rescue image on
partition %d.\n, i);
partno = -2;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/16] common/cmd_ethsw: Add generic commands for Ethernet Switches
Hi York, On Fri, Aug 7, 2015 at 5:58 PM, York Sun york...@freescale.com wrote: On 08/07/2015 01:18 PM, Joe Hershberger wrote: snip + } + + /* if all our optional command's keywords perfectly match an +* optional pattern, then we can move to the next defined +* keywords in our command; remember the one that matched the +* greatest number of keywords +*/ Improper comment format. Please make sure you always run your patches through checkpatch.pl. I recommend using patman! Joe, Do you mean the multiple-line comment should start from the second line? I can change it when I merge the patch. Checkpatch/patman doesn't complain about this format. That is what I mean. I'm fairly certain that the format used here is incorrect. Perhaps there is an exception set in checkpatch.pl for this path or something. U-Boot appears to defer to Linux Kernel style for this. It appears to be an exception for net and drivers/net based on this: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle I'm not sure that u-boot is planning on following the same thing. I honestly haven't gone looking for how much of this is in the U-Boot source for net/. As the network stack maintainer, I would prefer to avoid a network stack difference from the rest of the codebase unless someone can present a good reason to do this. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
