Re: [U-Boot] Relocation issue - need help!
Hello Wolfgang, 2014-10-22 18:56 GMT+02:00 Wolfgang Denk w...@denx.de: Dear Dirk, In message CANVMifLGzKz+=-k-e9_ssxbxpypdg1yqexc-tscapi7wvxq...@mail.gmail.com you wrote: I had exactly the same behaviour some time ago and tracked it down to this (and posted it on the mailing list, but sadly got no feedback): Thanks a lot for this pointer. I am really glad this was helpful. It was very nasty to track down, so I was really concerned when I found it. For that reson I chose u-boot ppc does not work with gcc 4.8 as a topic when I reported it to U-Boot mailing list and put you on CC on august 5th. But maybe I should have been more explicit, something like APOCALYPSE NOW: u-boot ppc does not work with gcc 4.8 ;) This problem is *not* fixed by the links Marek addressed. Just a quick explanation of what is going on: Since gcc 4.8 we have new sections .data.rel.ro and .data.rel.ro.local. They contain absolute addresses that should really be fixed up in our relocation process but are not considered yet. In your case you wre running u-boot referencing the not fixed-up addresses which worked perfectly as long as they still pointed to valid content. But as soon as you erased flash this was no longer the case. To make debugging even more fun, behaviour also depends on cache contents. In my original mail I referenced this potential solution, at least it worked for me: https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html Cheers DIrk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] image: Fix Android boot image support
Hello, Mr. Glass. On Wednesday 22 October 2014 11:29:00 AM Simon Glass wrote: One little nit below but it looks OK to me. I'm assume that no one would want to replace the command line completely? In some setups, one image can be used with several versions, or even different boards of hardware. The bootloader passes a command line argument to specify this. Also, the header file for the mkbootimg specifies that the kernel_args[] is appended to the kernel commandline. So I thought this would make it consistent with other bootloaders, and the spec. I hope you can write a test too. Re your comment about not wanting to change the code much - if we go that way the code will get really ugly. When you add features you often need to refactor. When there are tests, it becomes easier to know you have not broken things. Thanks for the tip. I'll try to write a test if I get the time. One thing comes to mind. To be able to write a test, we'll need an image to test against. I think pulling in the mkbootimg tool is the right move. The other option I can think of is bundling a small dummy image with U-Boot, which I think is a bit ugly. What do you think? Reviewed-by: Simon Glass s...@chromium.org nit: return -ENOMEM - suggest adding a comment to android_image_get_kernel() so its args and return value are documented. Thank you. I'll send in a new version soon. Regards, Simon Regards, Ahmad Draidi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-tegra/master into ARM/master
MAKEALL -s tegra is error/warning-free. The following changes since commit 3d420cbd355a5f09e4f113eb10579a264a8ef138: Merge branch 'u-boot-socfpga/topic/arm/socfpga-20141010' into 'u-boot-arm/master' (2014-10-11 01:20:55 +0200) are available in the git repository at: git://git.denx.de/u-boot-tegra.git master for you to fetch changes up to 9aafef4f360616a507578b8868092f096b093aa9: tegra: apalis_t30: master revamp (2014-10-22 09:30:55 -0700) Marcel Ziswiler (11): arm: tegra: initial support for apalis t30 arm: tegra: use architecture specific memcpy mmc: Tegra: Fix timeout issue seen on certain eMMC parts tegra: gpio: fix null label regression tegra: colibri_t30: asix usb ethernet reset regression gpio: header file comment spelling fixes tegra: clean-up useless define ARM: tegra: Use mem size from MC in combination with get_ram_size() tegra: colibri_t30: clean-up spurious new line tegra: dts: colibri_t30 add serial port details tegra: apalis_t30: master revamp Stephen Warren (1): ARM: tegra: add PCIe-related pins to the Jetson TK1 pinmux tables arch/arm/cpu/armv7/tegra30/Kconfig | 4 + arch/arm/cpu/tegra-common/board.c | 64 +--- arch/arm/dts/Makefile | 1 + arch/arm/dts/tegra30-apalis.dts| 304 ++ arch/arm/dts/tegra30-colibri.dts | 4 + arch/arm/include/asm/arch-tegra114/mc.h| 37 +++ arch/arm/include/asm/arch-tegra114/tegra.h | 1 + arch/arm/include/asm/arch-tegra20/mc.h | 36 +++ arch/arm/include/asm/arch-tegra20/tegra.h | 1 + arch/arm/include/asm/arch-tegra30/mc.h | 38 +++ arch/arm/include/asm/arch-tegra30/tegra.h | 1 + arch/arm/include/asm/mach-types.h | 13 + board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h | 5 + board/toradex/apalis_t30/Kconfig | 12 + board/toradex/apalis_t30/MAINTAINERS | 7 + board/toradex/apalis_t30/Makefile | 6 + board/toradex/apalis_t30/apalis_t30.c | 92 ++ .../toradex/apalis_t30/pinmux-config-apalis_t30.h | 347 + board/toradex/colibri_t30/colibri_t30.c| 2 +- configs/apalis_t30_defconfig | 5 + drivers/gpio/tegra_gpio.c | 3 + drivers/mmc/tegra_mmc.c| 2 +- include/asm-generic/gpio.h | 10 +- include/configs/apalis_t30.h | 75 + include/configs/colibri_t30.h | 1 - include/configs/tegra-common-post.h| 4 - include/configs/tegra-common.h | 2 + 27 files changed, 1014 insertions(+), 63 deletions(-) create mode 100644 arch/arm/dts/tegra30-apalis.dts create mode 100644 arch/arm/include/asm/arch-tegra114/mc.h create mode 100644 arch/arm/include/asm/arch-tegra20/mc.h create mode 100644 arch/arm/include/asm/arch-tegra30/mc.h create mode 100644 board/toradex/apalis_t30/Kconfig create mode 100644 board/toradex/apalis_t30/MAINTAINERS create mode 100644 board/toradex/apalis_t30/Makefile create mode 100644 board/toradex/apalis_t30/apalis_t30.c create mode 100644 board/toradex/apalis_t30/pinmux-config-apalis_t30.h create mode 100644 configs/apalis_t30_defconfig create mode 100644 include/configs/apalis_t30.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation issue - need help!
Hello Wolfgang, 2014-10-22 18:56 GMT+02:00 Wolfgang Denk w...@denx.de: Dear Dirk, In message CANVMifLGzKz+=-k-e9_ssxbxpypdg1yqexc-tscapi7wvxq...@mail.gmail.com you wrote: I had exactly the same behaviour some time ago and tracked it down to this (and posted it on the mailing list, but sadly got no feedback): Thanks a lot for this pointer. I am really glad this was helpful. It was very nasty to track down, so I was really concerned when I found it. For that reson I chose u-boot ppc does not work with gcc 4.8 as a topic when I reported it to U-Boot mailing list and put you on CC on august 5th. But maybe I should have been more explicit, something like APOCALYPSE NOW: u-boot ppc does not work with gcc 4.8 ;) This problem is *not* fixed by the links Marek addressed. Just a quick explanation of what is going on: Since gcc 4.8 we have new sections .data.rel.ro and .data.rel.ro.local. They contain absolute addresses that should really be fixed up in our relocation process but are not considered yet. In your case you wre running u-boot referencing the not fixed-up addresses which worked perfectly as long as they still pointed to valid content. But as soon as you erased flash this was no longer the case. To make debugging even more fun, behaviour also depends on cache contents. Ouch, that was a nasty surprise. In my original mail I referenced this potential solution, at least it worked for me: https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html That looks like the correct fix but I presume both .data.rel.ro and data.rel.ro.local should be added? Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] dm: at91: Add driver model support for atmel GPIO driver
Dear Simon,
On 06.10.14 20:14, Simon Glass wrote:
Modify this driver to support driver model, with platform data required to
determine the GPIOs that it controls.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/include/asm/arch-at91/gpio.h | 6 +
drivers/gpio/at91_gpio.c | 221
+++---
2 files changed, 183 insertions(+), 44 deletions(-)
diff --git a/arch/arm/include/asm/arch-at91/gpio.h
b/arch/arm/include/asm/arch-at91/gpio.h
index 7121388..6d2a7b7 100644
--- a/arch/arm/include/asm/arch-at91/gpio.h
+++ b/arch/arm/include/asm/arch-at91/gpio.h
@@ -253,4 +253,10 @@ static inline unsigned at91_gpio_to_pin(unsigned gpio)
return gpio % 32;
}
+/* Platform data for each GPIO port */
+struct at91_port_platdata {
+ uint32_t base_addr;
+ const char *bank_name;
+};
+
#endif /* __ASM_ARCH_AT91_GPIO_H */
diff --git a/drivers/gpio/at91_gpio.c b/drivers/gpio/at91_gpio.c
index 6517af1..822ba8c 100644
--- a/drivers/gpio/at91_gpio.c
+++ b/drivers/gpio/at91_gpio.c
@@ -10,11 +10,14 @@
#include config.h
#include common.h
+#include dm.h
#include asm/io.h
#include linux/sizes.h
+#include asm/gpio.h
#include asm/arch/hardware.h
#include asm/arch/at91_pio.h
-#include asm/arch/gpio.h
+
+#define GPIO_PER_BANK32
static struct at91_port *at91_pio_get_port(unsigned port)
{
@@ -39,19 +42,25 @@ static struct at91_port *at91_pio_get_port(unsigned port)
}
}
+static void at91_set_port_pullup(struct at91_port *at91_port, unsigned
offset,
+ int use_pullup)
+{
+ u32 mask;
+
+ mask = 1 offset;
+ if (use_pullup)
+ writel(mask, at91_port-puer);
+ else
+ writel(mask, at91_port-pudr);
+ writel(mask, at91_port-per);
+}
+
int at91_set_pio_pullup(unsigned port, unsigned pin, int use_pullup)
{
struct at91_port *at91_port = at91_pio_get_port(port);
- u32 mask;
- if (at91_port (pin 32)) {
- mask = 1 pin;
- if (use_pullup)
- writel(1 pin, at91_port-puer);
- else
- writel(1 pin, at91_port-pudr);
- writel(mask, at91_port-per);
- }
+ if (at91_port (pin 32))
could we please use the newly defined GPIO_PER_BANK here and elsewhere?
+ at91_set_port_pullup(at91_port, pin, use_pullup);
return 0;
}
@@ -172,6 +181,29 @@ int at91_set_d_periph(unsigned port, unsigned pin, int
use_pullup)
}
#endif
+#ifdef CONFIG_DM_GPIO
+static bool at91_get_port_output(struct at91_port *at91_port, int offset)
+{
+ u32 mask, val;
+
+ mask = 1 offset;
+ val = readl(at91_port-osr);
+ return val mask ? true : false;
Nitpick, wouldn't just 'return val mask' work here? It would be
implicit conversion, but isn't the construct here also implicit conversion?
+}
+#endif
+
+static void at91_set_port_input(struct at91_port *at91_port, int offset,
+ int use_pullup)
+{
+ u32 mask;
+
+ mask = 1 offset;
+ writel(mask, at91_port-idr);
+ at91_set_port_pullup(at91_port, offset, use_pullup);
+ writel(mask, at91_port-odr);
+ writel(mask, at91_port-per);
+}
+
/*
* mux the pin to the gpio controller (instead of A or B peripheral), and
* configure it for an input.
@@ -179,19 +211,29 @@ int at91_set_d_periph(unsigned port, unsigned pin, int
use_pullup)
int at91_set_pio_input(unsigned port, u32 pin, int use_pullup)
{
struct at91_port *at91_port = at91_pio_get_port(port);
- u32 mask;
- if (at91_port (pin 32)) {
- mask = 1 pin;
- writel(mask, at91_port-idr);
- at91_set_pio_pullup(port, pin, use_pullup);
- writel(mask, at91_port-odr);
- writel(mask, at91_port-per);
- }
+ if (at91_port (pin 32))
+ at91_set_port_input(at91_port, pin, use_pullup);
return 0;
}
+static void at91_set_port_output(struct at91_port *at91_port, int offset,
+ int value)
+{
+ u32 mask;
+
+ mask = 1 offset;
+ writel(mask, at91_port-idr);
+ writel(mask, at91_port-pudr);
+ if (value)
+ writel(mask, at91_port-sodr);
+ else
+ writel(mask, at91_port-codr);
+ writel(mask, at91_port-oer);
+ writel(mask, at91_port-per);
+}
+
/*
* mux the pin to the gpio controller (instead of A or B peripheral),
* and configure it for an output.
@@ -199,19 +241,9 @@ int at91_set_pio_input(unsigned port, u32 pin, int
use_pullup)
int at91_set_pio_output(unsigned port, u32 pin, int value)
{
struct at91_port *at91_port = at91_pio_get_port(port);
- u32 mask;
- if (at91_port (port ATMEL_PIO_PORTS) (pin 32)) {
- mask = 1 pin;
- writel(mask, at91_port-idr);
-
Re: [U-Boot] [PATCH 4/7] dm: at91: Add platform data for GPIO on at91sam9260-based boards
Hi Simon,
On 06.10.14 20:14, Simon Glass wrote:
These boards all have the same GPIO arrangement, so add some common platform
data that can be used by all boards. Remove the configs which are no longer
required.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c | 14 ++
arch/arm/include/asm/arch-at91/at91sam9260.h | 4 +++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
b/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
index cae4abc..5edcfc2 100644
--- a/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
+++ b/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
@@ -7,6 +7,7 @@
*/
#include common.h
+#include dm.h
#include asm/io.h
#include asm/arch/at91_common.h
#include asm/arch/at91_pmc.h
@@ -207,3 +208,16 @@ void at91_mci_hw_init(void)
#endif
}
#endif
+
+/* Platform data for the GPIOs */
+static const struct at91_port_platdata at91sam9260_plat[] = {
+ { ATMEL_BASE_PIOA, A },
+ { ATMEL_BASE_PIOB, B },
+ { ATMEL_BASE_PIOC, C },
data sheet call the parts 'Px', sam9260 has PA0..PA31, PB0..PB31 and
PC0..PC31, shouldn't we use that name here too?
+};
+
+U_BOOT_DEVICES(at91sam9260_gpios) = {
+ { gpio_at91, at91sam9260_plat[0] },
+ { gpio_at91, at91sam9260_plat[1] },
+ { gpio_at91, at91sam9260_plat[2] },
+};
diff --git a/arch/arm/include/asm/arch-at91/at91sam9260.h
b/arch/arm/include/asm/arch-at91/at91sam9260.h
index 2e902ee..4d46def 100644
--- a/arch/arm/include/asm/arch-at91/at91sam9260.h
+++ b/arch/arm/include/asm/arch-at91/at91sam9260.h
@@ -136,9 +136,11 @@
/*
* Other misc defines
*/
+#ifndef CONFIG_DM_GPIO
#define ATMEL_PIO_PORTS 3 /* these SoCs have 3
PIO */
-#define ATMEL_PMC_UHPAT91SAM926x_PMC_UHP
#define ATMEL_BASE_PIO ATMEL_BASE_PIOA
+#endif
+#define ATMEL_PMC_UHPAT91SAM926x_PMC_UHP
/*
* SoC specific defines
Best regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mtd: nand: allow to skip BBT scanning during NAND inititialization
Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14), chip-scan_bbt() is called at the end of nand_scan_tail(). It means the first read access happens immediately after the generic NAND initialization process. It causes a problem to some SoCs of UniPhier platform because some of their register values need to be fixed up after the general initialization procedure has been finished. Otherwise, read asccess fails. Such a fix-up is SoC-specific enough to be written in a board file rather than in driver code. One of possible and clean enough ways to work around this issue is postpone the BBT scanning until necessary fix-up is done in board_late_init() or somewhere else. CONFIG_MTD_NAND_SKIP_BBTSCAN, if enabled, allows to skip the BBT scanning at the end of nand_scan_tail(). Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Scott Wood scottw...@freescale.com --- If this patch is accepted, I will turn on this config option for my boards. drivers/mtd/nand/Kconfig | 13 + drivers/mtd/nand/nand.c | 4 2 files changed, 17 insertions(+) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 75c2c06..e9d133d 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -2,6 +2,19 @@ menu NAND Device Support if !SPL_BUILD +MTD_NAND_SKIP_BBTSCAN + bool Skip BBT scanning + help + The current implementation of nand_scan_tail() calls scan_bbt handler + at the end of itself to build a bad block table. It means the first + read access happens in the initizalization procedure. It causes a + problem on some SoCs that need some extra SoC-specific settings + before starting read/write access. + + If this option is enabled, bad block scanning is skipped during the + nand device initialization. You are resposible to build a bad block + table lator. + config NAND_DENALI bool Support Denali NAND controller help diff --git a/drivers/mtd/nand/nand.c b/drivers/mtd/nand/nand.c index 4cf4c1c..a249647 100644 --- a/drivers/mtd/nand/nand.c +++ b/drivers/mtd/nand/nand.c @@ -88,6 +88,10 @@ static void nand_init_chip(int i) mtd-priv = nand; nand-IO_ADDR_R = nand-IO_ADDR_W = (void __iomem *)base_addr; +#ifdef CONFIG_MTD_NAND_SKIP_BBTSCAN + nand-options |= NAND_SKIP_BBTSCAN; +#endif + if (board_nand_init(nand)) return; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: Add I2C support to SoCFPGA
Hi Marek, Hi Heiko! On 21.10.2014 08:44, Heiko Schocher wrote: /* + * I2C support + */ +#define CONFIG_HARD_I2C No ... do not add this define please. +#define CONFIG_DW_I2C +#define CONFIG_I2C_MULTI_BUS I presume this should be converted to CONFIG_SYS_I2C framework instead of using this I2C multibus horror, no? ... Yes, please! Which i2c driver does socfpga use? If it is the drivers/i2c/designware_i2c.c driver, please convert it to the CONFIG_SYS_I2C framework. Yes. Its the designware driver. I wanted to make this I2C support for SoCFPGA least intrusive. But I see your point. Moving this driver to the new I2C framework makes sense. You may also take a look into Simons RFC patches, which introduce DM model: http://lists.denx.de/pipermail/u-boot/2014-October/191497.html This seems a bit too early for me. I'll try to find some time to move to the CONFIG_SYS_I2C framework... Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: mxs: Enable DCDC converter for battery boot
Hi Marek, and Fabio Shouldn't this be conditional? #if defined CONFIG_MXS_ENABLE_4P2 mxs_power_enable_4p2(); #endif Then the boards that need this power supply enable CONFIG_MXS_ENABLE_4P2 in its config file. No, we want to start the DCDC converter unconditionally when running on battery power to increase efficiency. I just stumbled upon this, because our board does not boot reliably any more with this change. Perhaps we have a special situation in that our board is powered via DCDC_BATT only by an external power source (no battery). I am currently working on creating a patch to only conditionally enabling this feature, or to enable it by default and have it conditionally be disabled for boards that are known to have problems with this. Which approach seems to be more feasible to you? Regards Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ot1200: fix sf detection
Hi Christian, On 22/10/2014 11:29, Christian Gmeiner wrote: Commit 155fa9af95ac5be857a7327e7a968a296e60d4c8 changed the way to define a GPIO line, which can be used to force CS high across multiple transactions. In order to fix sf detection change board code to make use of board_spi_cs_gpio(..). Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel 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] ot1200: add sata support
Hi Christian, On 22/10/2014 11:55, Christian Gmeiner wrote: One of the possible boot devices can be sata. Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel 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 v2 00/40] ARM: tegra: Add PCIe support
On Wed, Oct 22, 2014 at 09:07:40PM -0600, Simon Glass wrote: Hi, On 11 September 2014 10:00, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Thierry, On Tue, 26 Aug 2014 17:33:48 +0200, Thierry Reding thierry.red...@gmail.com wrote: From: Thierry Reding tred...@nvidia.com Note: this series was split over several custodians (including myself). It might thus get applied piecewise... Shouldn't it rather be assigned a single custodian -with others giving their Ack) and be applied as a whole? And yes, I'm ok with getting all the pieces. As this series still need some minor work, and the DT patches are separate, I have pushed them to u-boot-fdt/master and issued a pull request. Thierry are you going to pick this up again soon? We should try to get this series applied in the next few weeks. I'm completely swamped right now, but I definitely plan on getting back to this at some point. But I can't really say for sure how soon that'll be. Thierry pgp5mX71fqp7u.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] e1000: fix sw fw sync on igb i210/i211
On Tue, Oct 21, 2014 at 5:26 AM, Marcel Ziswiler mar...@ziswiler.com wrote:
I finally had a look at the datasheet and spotted an additional
register address difference between regular E1000 and i210/i211 chips.
This patch fixes this and now successfully works on programmed
i210/i211 as well as unprogrammed i211.
Signed-off-by: Marcel Ziswiler mar...@ziswiler.com
---
Please note that unprogrammed i210 seem to behave slightly different
and do not assert the CFG_DONE bit in the EEMNGCTL register upon PHY
reset. However if this error condition is ignored then successful data
transfer is possible. Due to the rather hacky nature thereof this is
not addressed by my patch.
Hi Marcel,
I've never been able to get e1000_swfw_sync_acquire() to not timeout
on the boards with i210 devices that I have (IMX6 with 2x i210
programmed as 8086:1533 using int phys). In my case with your patch
below as well as York's patch
(https://patchwork.ozlabs.org/patch/400628/) I still see failures. The
I210_SW_FW_SYNC reg returns swfw_sync=0x03, fwmask=0x2, and
swmask=0x2 which results in:
Driver can't access resource, SW_FW_SYNC timeout.
Unable to acquire swfw sync
Error Resetting the PHY
e1000: e1000#0: ERROR: Hardware Initialization Failed
I've always had to ignore the return value from e1000_reset() to avoid
this issue and use the devices.
Any ideas?
BTW: What about my previous patch this one kind of bases on?
[PATCH] e1000: add i211 and unprogrammed i210/i211 support
I don't have any i211's but I'll see if I can get hold of an
unprogrammed i210 to test with.
Tim
drivers/net/e1000.c | 6 --
drivers/net/e1000.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index b092867..798c8aa 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -1112,7 +1112,10 @@ e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t
mask)
if (e1000_get_hw_eeprom_semaphore(hw))
return -E1000_ERR_SWFW_SYNC;
- swfw_sync = E1000_READ_REG(hw, SW_FW_SYNC);
+ if (hw-mac_type == e1000_igb)
+ swfw_sync = E1000_READ_REG(hw, I210_SW_FW_SYNC);
+ else
+ swfw_sync = E1000_READ_REG(hw, SW_FW_SYNC);
if (!(swfw_sync (fwmask | swmask)))
break;
@@ -4429,7 +4432,6 @@ e1000_phy_hw_reset(struct e1000_hw *hw)
if (hw-mac_type = e1000_82571)
mdelay(10);
-
} else {
/* Read the Extended Device Control Register, assert the
PHY_RESET_DIR
* bit to put the PHY into reset. Then, take it out of reset.
diff --git a/drivers/net/e1000.h b/drivers/net/e1000.h
index b025ecc..6d110eb 100644
--- a/drivers/net/e1000.h
+++ b/drivers/net/e1000.h
@@ -2497,6 +2497,7 @@ struct e1000_hw {
#define ICH_GFPREG_BASE_MASK 0x1FFF
#define ICH_FLASH_LINEAR_ADDR_MASK 0x00FF
+#define E1000_I210_SW_FW_SYNC 0x5B50 /* Software-Firmware Synchronization -
RW */
#define E1000_SW_FW_SYNC 0x05B5C /* Software-Firmware Synchronization - RW */
/* SPI EEPROM Status Register */
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: bootm: Allow booting in secure mode on hyp capable systems
Hi Ian,
On 10/22/2014 08:55 PM, Ian Campbell wrote:
On Wed, 2014-10-22 at 15:45 +0200, Hans de Goede wrote:
if (!fake) {
#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
-armv7_init_nonsec();
-secure_ram_addr(_do_nonsec_entry)(kernel_entry,
- 0, machid, r2);
-#else
-kernel_entry(0, machid, r2);
+if (boot_nonsec()) {
+armv7_init_nonsec();
+secure_ram_addr(_do_nonsec_entry)(kernel_entry,
+ 0, machid, r2);
+}
#endif
+kernel_entry(0, machid, r2);
There's a subtle different here, which is that this final kernel_entry
call used to be in the #else clause, and so emitted for the NONSEC ||
VIRT case. So if the _do_nonsec_entry call were to fail (not currently
possible) and return you'd end up trying again via the sec path.
I'm not sure that's a bad thing, but it is a difference so it'd be good
to know it was a deliberate choice (or not).
I was under the assumption that do_nonsec_entry would never fail, and would
not return, which is why I wrote this code the way I wrote it. I'm not sure
if retrying in secure mode meets the principle of least surprise, so I guess
the #if .. #endif block should probably get an else added before the #endif,
do you agree?
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common: command: trivial coding style fixes
- Do not insert a whitespace between a function name and
an open paranthesis
- Fix comment style
- Do not split an error message into multiple lines
even if it exceeds 80 columns
- Do not split for statement where it fits in 80 columns
- Do not use assignment in if condition
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
common/command.c | 56 ++--
1 file changed, 26 insertions(+), 30 deletions(-)
diff --git a/common/command.c b/common/command.c
index 746b7e3..4719f49 100644
--- a/common/command.c
+++ b/common/command.c
@@ -18,13 +18,13 @@
* for long help messages
*/
-int _do_help (cmd_tbl_t *cmd_start, int cmd_items, cmd_tbl_t * cmdtp, int
- flag, int argc, char * const argv[])
+int _do_help(cmd_tbl_t *cmd_start, int cmd_items, cmd_tbl_t *cmdtp, int flag,
+int argc, char * const argv[])
{
int i;
int rcode = 0;
- if (argc == 1) {/*show list of commands */
+ if (argc == 1) {/* show list of commands */
cmd_tbl_t *cmd_array[cmd_items];
int i, j, swaps;
@@ -38,8 +38,8 @@ int _do_help (cmd_tbl_t *cmd_start, int cmd_items, cmd_tbl_t
* cmdtp, int
for (i = cmd_items - 1; i 0; --i) {
swaps = 0;
for (j = 0; j i; ++j) {
- if (strcmp (cmd_array[j]-name,
- cmd_array[j + 1]-name) 0) {
+ if (strcmp(cmd_array[j]-name,
+ cmd_array[j + 1]-name) 0) {
cmd_tbl_t *tmp;
tmp = cmd_array[j];
cmd_array[j] = cmd_array[j + 1];
@@ -56,7 +56,7 @@ int _do_help (cmd_tbl_t *cmd_start, int cmd_items, cmd_tbl_t
* cmdtp, int
const char *usage = cmd_array[i]-usage;
/* allow user abort */
- if (ctrlc ())
+ if (ctrlc())
return 1;
if (usage == NULL)
continue;
@@ -69,26 +69,23 @@ int _do_help (cmd_tbl_t *cmd_start, int cmd_items,
cmd_tbl_t * cmdtp, int
* command help (long version)
*/
for (i = 1; i argc; ++i) {
- if ((cmdtp = find_cmd_tbl (argv[i], cmd_start, cmd_items )) !=
NULL) {
+ cmdtp = find_cmd_tbl(argv[i], cmd_start, cmd_items);
+ if (cmdtp != NULL) {
rcode |= cmd_usage(cmdtp);
} else {
- printf (Unknown command '%s' - try 'help'
-without arguments for list of all
-known commands\n\n, argv[i]
- );
+ printf(Unknown command '%s' - try 'help' without
arguments for list of all known commands\n\n,
+ argv[i]);
rcode = 1;
}
}
return rcode;
}
-/***
- * find command table entry for a command
- */
-cmd_tbl_t *find_cmd_tbl (const char *cmd, cmd_tbl_t *table, int table_len)
+/* find command table entry for a command */
+cmd_tbl_t *find_cmd_tbl(const char *cmd, cmd_tbl_t *table, int table_len)
{
cmd_tbl_t *cmdtp;
- cmd_tbl_t *cmdtp_temp = table; /*Init value */
+ cmd_tbl_t *cmdtp_temp = table; /* Init value */
const char *p;
int len;
int n_found = 0;
@@ -101,11 +98,9 @@ cmd_tbl_t *find_cmd_tbl (const char *cmd, cmd_tbl_t *table,
int table_len)
*/
len = ((p = strchr(cmd, '.')) == NULL) ? strlen (cmd) : (p - cmd);
- for (cmdtp = table;
-cmdtp != table + table_len;
-cmdtp++) {
- if (strncmp (cmd, cmdtp-name, len) == 0) {
- if (len == strlen (cmdtp-name))
+ for (cmdtp = table; cmdtp != table + table_len; cmdtp++) {
+ if (strncmp(cmd, cmdtp-name, len) == 0) {
+ if (len == strlen(cmdtp-name))
return cmdtp; /* full match */
cmdtp_temp = cmdtp; /* abbreviated command ? */
@@ -119,7 +114,7 @@ cmd_tbl_t *find_cmd_tbl (const char *cmd, cmd_tbl_t *table,
int table_len)
return NULL;/* not found or ambiguous command */
}
-cmd_tbl_t *find_cmd (const char *cmd)
+cmd_tbl_t *find_cmd(const char *cmd)
{
cmd_tbl_t *start = ll_entry_start(cmd_tbl_t, cmd);
const int len = ll_entry_count(cmd_tbl_t, cmd);
@@ -138,8 +133,8 @@ int cmd_usage(const cmd_tbl_t *cmdtp)
return 1;
}
- puts (cmdtp-help);
- putc ('\n');
+ puts(cmdtp-help);
+ putc('\n');
#endif /*
Re: [U-Boot] [PATCH 6/7] serial: uniphier: move CONFIG_UNIPHIER_SERIAL to Kconfig
Hi Simon, On Wed, 22 Oct 2014 21:31:22 -0600 Simon Glass s...@chromium.org wrote: diff --git a/include/configs/ph1_sld8.h b/include/configs/ph1_sld8.h index 41e2299..1062aac 100644 --- a/include/configs/ph1_sld8.h +++ b/include/configs/ph1_sld8.h @@ -28,9 +28,7 @@ * SoC UART : enable CONFIG_UNIPHIER_SERIAL * On-board UART: enable CONFIG_SYS_NS16550_SERIAL */ -#if 1 -#define CONFIG_UNIPHIER_SERIAL -#else +#if 0 #define CONFIG_SYS_NS16550_SERIAL #endif Why not just remove this code? There are two types of UART ports on our boards - On-chip UART core - Some of our boards also have a on-board 16550 UART. For those boards, user can select a favorate UART port. In the future, CONFIG_SYS_NS16550_SERIAL also should be moved to Kconfig to allow users to enable/disable each UART driver. I know this code is silly. The only excuse I could find was just a reminder of TODO item for me. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] sunxi: Add CONFIG_OLD_SUNXI_KERNEL_COMPAT Kconfig option
Add a Kconfig option which users can select when they want to boot older
kernels, e.g. the linux-sunxi 3.4 kernels. For now this just forces the pll5
p value to 1 (divide by 2) as that is what those kernels are hardcoded too,
in the future this may enable further workarounds.
Signed-off-by: Hans de Goede hdego...@redhat.com
--
Changes in v2:
-s/CONFIG_OLD_KERNEL_COMPAT/CONFIG_OLD_SUNXI_KERNEL_COMPAT.
-Move the code block setting P(1) for old kernels to where P gets cleared
---
arch/arm/cpu/armv7/sunxi/dram.c | 4
board/sunxi/Kconfig | 7 +++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/cpu/armv7/sunxi/dram.c b/arch/arm/cpu/armv7/sunxi/dram.c
index 0cbcf57..3cf3cbf 100644
--- a/arch/arm/cpu/armv7/sunxi/dram.c
+++ b/arch/arm/cpu/armv7/sunxi/dram.c
@@ -262,6 +262,10 @@ static void mctl_setup_dram_clock(u32 clk, u32 mbus_clk)
reg_val = ~CCM_PLL5_CTRL_K_MASK; /* set K to 0 (x1) */
reg_val = ~CCM_PLL5_CTRL_N_MASK; /* set N to 0 (x0) */
reg_val = ~CCM_PLL5_CTRL_P_MASK; /* set P to 0 (x1) */
+#ifdef CONFIG_OLD_SUNXI_KERNEL_COMPAT
+ /* Old kernels are hardcoded to P=1 (divide by 2) */
+ reg_val |= CCM_PLL5_CTRL_P(1);
+#endif
if (clk = 540 clk 552) {
/* dram = 540MHz */
reg_val |= CCM_PLL5_CTRL_M(CCM_PLL5_CTRL_M_X(2));
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 121d7d0..fb650c0 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -20,6 +20,13 @@ config SYS_SOC
config FDTFILE
string Default fdtfile env setting for this board
+config OLD_SUNXI_KERNEL_COMPAT
+ boolean Enable workarounds for booting old kernels
+ default n
+ ---help---
+ Set this to enable various workarounds for old kernels, this results in
+ sub-optimal settings for newer kernels, only enable if needed.
+
config MMC0_CD_PIN
string Card detect pin for mmc0
default
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_mem: call unmap_sysmem() after map_sysmem()
Actually, unmap_sysmem() does nothing. Just in case. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Simon Glass s...@chromium.org --- common/cmd_mem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/cmd_mem.c b/common/cmd_mem.c index bfca59e..0d50dcf 100644 --- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -480,6 +480,9 @@ static int do_mem_cp(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if ((count % (64 10)) == 0) WATCHDOG_RESET(); } + unmap_sysmem(buf); + unmap_sysmem(src); + return 0; } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sun7i: Set CONFIG_ARMV7_SEC_BY_DEFAULT when CONFIG_OLD_KERNEL_COMPAT is set
Hi Tom, On 10/22/2014 09:24 PM, Tom Rini wrote: On Wed, Oct 22, 2014 at 03:45:23PM +0200, Hans de Goede wrote: Old kernels cannot handle booting in non-secure (hyp) mode, so when CONFIG_OLD_KERNEL_COMPAT is set, also set CONFIG_ARMV7_SEC_BY_DEFAULT. Note that whether to booting secure or non-secure can always be overriden using the bootm_boot_mode environment variable. This belongs in Kconfig. If you want to make it really optional all the same, make modifying it depend on CONFIG_EXPERT too. I understand where your coming from, but the problem is that CONFIG_ARMV7_SEC_BY_DEFAULT as a Kconfig option should depend on CONFIG_ARMV7_VIRT or CONFIG_ARMV7_NONSEC, which depend on CONFIG_ARMV7_PSCI / CONFIG_ARMV7_PSCI_NR_CPUS and CONFIG_ARMV7_SECURE_BASE, all of which are currently set through include/configs/foo.h. I know that the plan is to move all of these to Kconfig eventually, but there still is a lot of figuring out how that exactly should be done, and as such I believe that it is best to set CONFIG_ARMV7_SEC_BY_DEFAULT the old-fashioned way for now. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sun7i: Set CONFIG_ARMV7_SEC_BY_DEFAULT when CONFIG_OLD_KERNEL_COMPAT is set
Hi, On 10/22/2014 08:57 PM, Ian Campbell wrote: On Wed, 2014-10-22 at 15:45 +0200, Hans de Goede wrote: Old kernels cannot handle booting in non-secure (hyp) mode, so when CONFIG_OLD_KERNEL_COMPAT is set, also set CONFIG_ARMV7_SEC_BY_DEFAULT. Note that whether to booting secure or non-secure can always be overriden nits: boot (not booting, or s/whether to/ perhaps) and overridden using the bootm_boot_mode environment variable. Signed-off-by: Hans de Goede hdego...@redhat.com --- include/configs/sun7i.h | 4 1 file changed, 4 insertions(+) diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h index 966cbd8..4a864b2 100644 --- a/include/configs/sun7i.h +++ b/include/configs/sun7i.h @@ -35,6 +35,10 @@ #define CONFIG_ARMV7_PSCI 1 #define CONFIG_ARMV7_PSCI_NR_CPUS 2 #define CONFIG_ARMV7_SECURE_BASESUNXI_SRAM_B_BASE +#ifdef CONFIG_OLD_KERNEL_COMPAT +#define CONFIG_ARMV7_SEC_BY_DEFAULT 1 +#endif I think this would be better right after the NONSEC+VIRT defines just above the context here, since they are related. Fixed in my personal tree, I'll do a v2 as soon as the Kconfig question Tom raised is answered. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dm: move platform data headers to include/dm/platform_data
The platform_data structures are generally referenced from both
drivers and board files. That is why header files defining
platform_data sturectures are placed in include directory,
but our top level include directory is already too cluttered.
Let's collect platform_data definitions under the directory
include/dm/platform_data as Linux gather them around under
include/linux/platform_data.
This commit moves two header files:
include/serial_mxc.h - include/dm/platform_data/serial_mxc.h
include/serial_pl01x.h - include/dm/platform_data/serial_pl01x.h
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Simon Glass s...@chromium.org
---
board/compulab/cm_fx6/cm_fx6.c| 2 +-
drivers/serial/serial_mxc.c | 2 +-
drivers/serial/serial_pl01x.c | 2 +-
include/{ = dm/platform_data}/serial_mxc.h | 0
include/{ = dm/platform_data}/serial_pl01x.h | 0
5 files changed, 3 insertions(+), 3 deletions(-)
rename include/{ = dm/platform_data}/serial_mxc.h (100%)
rename include/{ = dm/platform_data}/serial_pl01x.h (100%)
diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
index f77ff48..a56777b 100644
--- a/board/compulab/cm_fx6/cm_fx6.c
+++ b/board/compulab/cm_fx6/cm_fx6.c
@@ -15,7 +15,7 @@
#include netdev.h
#include fdt_support.h
#include sata.h
-#include serial_mxc.h
+#include dm/platform_data/serial_mxc.h
#include asm/arch/crm_regs.h
#include asm/arch/sys_proto.h
#include asm/arch/iomux.h
diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 9ce24f9..0c761d7 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -7,7 +7,7 @@
#include common.h
#include dm.h
#include errno.h
-#include serial_mxc.h
+#include dm/platform_data/serial_mxc.h
#include watchdog.h
#include asm/arch/imx-regs.h
#include asm/arch/clock.h
diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
index e6313ad..38dda91 100644
--- a/drivers/serial/serial_pl01x.c
+++ b/drivers/serial/serial_pl01x.c
@@ -17,7 +17,7 @@
#include watchdog.h
#include asm/io.h
#include serial.h
-#include serial_pl01x.h
+#include dm/platform_data/serial_pl01x.h
#include linux/compiler.h
#include serial_pl01x_internal.h
diff --git a/include/serial_mxc.h b/include/dm/platform_data/serial_mxc.h
similarity index 100%
rename from include/serial_mxc.h
rename to include/dm/platform_data/serial_mxc.h
diff --git a/include/serial_pl01x.h b/include/dm/platform_data/serial_pl01x.h
similarity index 100%
rename from include/serial_pl01x.h
rename to include/dm/platform_data/serial_pl01x.h
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: Add I2C support to SoCFPGA
On Thursday, October 23, 2014 at 09:55:25 AM, Stefan Roese wrote: Hi Marek, Hi Heiko! Hi all! On 21.10.2014 08:44, Heiko Schocher wrote: /* + * I2C support + */ +#define CONFIG_HARD_I2C No ... do not add this define please. +#define CONFIG_DW_I2C +#define CONFIG_I2C_MULTI_BUS I presume this should be converted to CONFIG_SYS_I2C framework instead of using this I2C multibus horror, no? ... Yes, please! Which i2c driver does socfpga use? If it is the drivers/i2c/designware_i2c.c driver, please convert it to the CONFIG_SYS_I2C framework. Yes. Its the designware driver. I wanted to make this I2C support for SoCFPGA least intrusive. But I see your point. Moving this driver to the new I2C framework makes sense. You may also take a look into Simons RFC patches, which introduce DM model: http://lists.denx.de/pipermail/u-boot/2014-October/191497.html This seems a bit too early for me. I'll try to find some time to move to the CONFIG_SYS_I2C framework... I think this makes sense indeed and helps a lot. Thank you very much! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: bootm: Allow booting in secure mode on hyp capable systems
On Thu, 2014-10-23 at 10:22 +0200, Hans de Goede wrote:
Hi Ian,
On 10/22/2014 08:55 PM, Ian Campbell wrote:
On Wed, 2014-10-22 at 15:45 +0200, Hans de Goede wrote:
if (!fake) {
#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
- armv7_init_nonsec();
- secure_ram_addr(_do_nonsec_entry)(kernel_entry,
-0, machid, r2);
-#else
- kernel_entry(0, machid, r2);
+ if (boot_nonsec()) {
+ armv7_init_nonsec();
+ secure_ram_addr(_do_nonsec_entry)(kernel_entry,
+0, machid, r2);
+ }
#endif
+ kernel_entry(0, machid, r2);
There's a subtle different here, which is that this final kernel_entry
call used to be in the #else clause, and so emitted for the NONSEC ||
VIRT case. So if the _do_nonsec_entry call were to fail (not currently
possible) and return you'd end up trying again via the sec path.
I'm not sure that's a bad thing, but it is a difference so it'd be good
to know it was a deliberate choice (or not).
I was under the assumption that do_nonsec_entry would never fail, and would
not return, which is why I wrote this code the way I wrote it.
AFAICT in practice it can't fail today, but if it were somehow modified
in the future to do so this would expose some slightly surprising
behaviour.
I'm not sure
if retrying in secure mode meets the principle of least surprise, so I guess
the #if .. #endif block should probably get an else added before the #endif,
do you agree?
Yes.
BTW, if you put the #ifdef around boot_nonsec() instead and make the
#else case #define boot_nonsec() (0) then does that end up looking
cleaner here at the caller? Maybe that causes knockons with the
prototypes for the unused functions in that case, in which case I doubt
it is worth it.
Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: bootm: Allow booting in secure mode on hyp capable systems
Hi,
On 10/23/2014 11:30 AM, Ian Campbell wrote:
On Thu, 2014-10-23 at 10:22 +0200, Hans de Goede wrote:
Hi Ian,
On 10/22/2014 08:55 PM, Ian Campbell wrote:
On Wed, 2014-10-22 at 15:45 +0200, Hans de Goede wrote:
if (!fake) {
#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
- armv7_init_nonsec();
- secure_ram_addr(_do_nonsec_entry)(kernel_entry,
-0, machid, r2);
-#else
- kernel_entry(0, machid, r2);
+ if (boot_nonsec()) {
+ armv7_init_nonsec();
+ secure_ram_addr(_do_nonsec_entry)(kernel_entry,
+0, machid, r2);
+ }
#endif
+ kernel_entry(0, machid, r2);
There's a subtle different here, which is that this final kernel_entry
call used to be in the #else clause, and so emitted for the NONSEC ||
VIRT case. So if the _do_nonsec_entry call were to fail (not currently
possible) and return you'd end up trying again via the sec path.
I'm not sure that's a bad thing, but it is a difference so it'd be good
to know it was a deliberate choice (or not).
I was under the assumption that do_nonsec_entry would never fail, and would
not return, which is why I wrote this code the way I wrote it.
AFAICT in practice it can't fail today, but if it were somehow modified
in the future to do so this would expose some slightly surprising
behaviour.
I'm not sure
if retrying in secure mode meets the principle of least surprise, so I guess
the #if .. #endif block should probably get an else added before the
#endif,
do you agree?
Yes.
BTW, if you put the #ifdef around boot_nonsec() instead and make the
#else case #define boot_nonsec() (0) then does that end up looking
cleaner here at the caller? Maybe that causes knockons with the
prototypes for the unused functions in that case, in which case I doubt
it is worth it.
The problem there is that do_nonsec_entry is not defined in that case, so
we really need an #ifdef there.
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] ARM: bootm: Allow booting in secure mode on hyp capable systems
Older Linux kernels will not properly boot in hype mode, add support for a
bootm_boot_mode environment variable, which when set to sec will cause
u-boot to boot in secure mode even when build with non-sec (and hyp) support.
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Marc Zyngier marc.zyng...@arm.com
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
--
Changes in v2:
-Allow changing the default boot mode to secure through defining
CONFIG_ARMV7_SEC_BY_DEFAULT, this is useful for archs which have a Kconfig
option for compatibility with older kernels
Changes in v3:
-Add an else at the end of the #ifdef NONSEC block so that if do_nonsec_entry
fails we do not end up re-trying in secure mode
---
arch/arm/lib/bootm.c | 31 ++-
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 39fe7a1..25b941c 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -235,6 +235,26 @@ static void boot_prep_linux(bootm_headers_t *images)
}
}
+#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
+static bool boot_nonsec(void)
+{
+ char *s = getenv(bootm_boot_mode);
+#ifdef CONFIG_ARMV7_SEC_BY_DEFAULT
+ bool nonsec = false;
+#else
+ bool nonsec = true;
+#endif
+
+ if (s !strcmp(s, sec))
+ nonsec = false;
+
+ if (s !strcmp(s, nonsec))
+ nonsec = true;
+
+ return nonsec;
+}
+#endif
+
/* Subcommand: GO */
static void boot_jump_linux(bootm_headers_t *images, int flag)
{
@@ -283,12 +303,13 @@ static void boot_jump_linux(bootm_headers_t *images, int
flag)
if (!fake) {
#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
- armv7_init_nonsec();
- secure_ram_addr(_do_nonsec_entry)(kernel_entry,
- 0, machid, r2);
-#else
- kernel_entry(0, machid, r2);
+ if (boot_nonsec()) {
+ armv7_init_nonsec();
+ secure_ram_addr(_do_nonsec_entry)(kernel_entry,
+ 0, machid, r2);
+ } else
#endif
+ kernel_entry(0, machid, r2);
}
#endif
}
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] net/fm: add 2.5G SGMII support
As auto-negotiation is not supported for 2.5G SGMII, we need
to add a new type PHY_INTERFACE_MODE_SGMII_2500 to differentiate
SGMII-1G and SGMII-2.5G with different setting for auto-negotiation.
Signed-off-by: Shaohui Xie shaohui@freescale.com
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
arch/powerpc/include/asm/fsl_serdes.h | 16
drivers/net/fm/eth.c | 16
include/phy.h | 2 ++
3 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_serdes.h
b/arch/powerpc/include/asm/fsl_serdes.h
index f60cb0a..8e0e190 100644
--- a/arch/powerpc/include/asm/fsl_serdes.h
+++ b/arch/powerpc/include/asm/fsl_serdes.h
@@ -71,6 +71,22 @@ enum srds_prtcl {
INTERLAKEN,
QSGMII_SW1_A, /* Indicates ports on L2 Switch */
QSGMII_SW1_B,
+ SGMII_2500_FM1_DTSEC1,
+ SGMII_2500_FM1_DTSEC2,
+ SGMII_2500_FM1_DTSEC3,
+ SGMII_2500_FM1_DTSEC4,
+ SGMII_2500_FM1_DTSEC5,
+ SGMII_2500_FM1_DTSEC6,
+ SGMII_2500_FM1_DTSEC9,
+ SGMII_2500_FM1_DTSEC10,
+ SGMII_2500_FM2_DTSEC1,
+ SGMII_2500_FM2_DTSEC2,
+ SGMII_2500_FM2_DTSEC3,
+ SGMII_2500_FM2_DTSEC4,
+ SGMII_2500_FM2_DTSEC5,
+ SGMII_2500_FM2_DTSEC6,
+ SGMII_2500_FM2_DTSEC9,
+ SGMII_2500_FM2_DTSEC10,
};
enum srds {
diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index 218a5ed..137886c 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -39,9 +39,14 @@ static void dtsec_configure_serdes(struct fm_eth *priv)
u32 value;
struct mii_dev bus;
bus.priv = priv-mac-phyregs;
+ bool sgmii_2500 = (priv-enet_if ==
+ PHY_INTERFACE_MODE_SGMII_2500) ? true : false;
+
+ /* SGMII IF mode + AN enable only for 1G SGMII, not for 2.5G */
+ value = PHY_SGMII_IF_MODE_SGMII;
+ if (!sgmii_2500)
+ value |= PHY_SGMII_IF_MODE_AN;
- /* SGMII IF mode + AN enable */
- value = PHY_SGMII_IF_MODE_AN | PHY_SGMII_IF_MODE_SGMII;
memac_mdio_write(bus, 0, MDIO_DEVAD_NONE, 0x14, value);
/* Dev ability according to SGMII specification */
@@ -54,7 +59,9 @@ static void dtsec_configure_serdes(struct fm_eth *priv)
memac_mdio_write(bus, 0, MDIO_DEVAD_NONE, 0x12, 0xd40);
/* Restart AN */
- value = PHY_SGMII_CR_DEF_VAL | PHY_SGMII_CR_RESET_AN;
+ value = PHY_SGMII_CR_DEF_VAL;
+ if (!sgmii_2500)
+ value |= PHY_SGMII_CR_RESET_AN;
memac_mdio_write(bus, 0, MDIO_DEVAD_NONE, 0, value);
#else
struct dtsec *regs = priv-mac-base;
@@ -83,7 +90,8 @@ static void dtsec_init_phy(struct eth_device *dev)
out_be32(regs-tbipa, CONFIG_SYS_TBIPA_VALUE);
#endif
- if (fm_eth-enet_if == PHY_INTERFACE_MODE_SGMII)
+ if (fm_eth-enet_if == PHY_INTERFACE_MODE_SGMII ||
+ fm_eth-enet_if == PHY_INTERFACE_MODE_SGMII_2500)
dtsec_configure_serdes(fm_eth);
}
diff --git a/include/phy.h b/include/phy.h
index d3ecd63..3c5f111 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -39,6 +39,7 @@ typedef enum {
PHY_INTERFACE_MODE_MII,
PHY_INTERFACE_MODE_GMII,
PHY_INTERFACE_MODE_SGMII,
+ PHY_INTERFACE_MODE_SGMII_2500,
PHY_INTERFACE_MODE_QSGMII,
PHY_INTERFACE_MODE_TBI,
PHY_INTERFACE_MODE_RMII,
@@ -55,6 +56,7 @@ static const char *phy_interface_strings[] = {
[PHY_INTERFACE_MODE_MII]= mii,
[PHY_INTERFACE_MODE_GMII] = gmii,
[PHY_INTERFACE_MODE_SGMII] = sgmii,
+ [PHY_INTERFACE_MODE_SGMII_2500] = sgmii-2500,
[PHY_INTERFACE_MODE_QSGMII] = qsgmii,
[PHY_INTERFACE_MODE_TBI]= tbi,
[PHY_INTERFACE_MODE_RMII] = rmii,
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] net/fm: add 2.5G SGMII support
-Original Message- From: Shengzhou Liu [mailto:shengzhou@freescale.com] Sent: Thursday, October 23, 2014 5:21 PM To: u-boot@lists.denx.de; Sun York-R58495 Cc: Liu Shengzhou-B36685; Xie Shaohui-B21989 Subject: [PATCH 1/4] net/fm: add 2.5G SGMII support [Shengzhou] This is a single patch, forgot to remove '1/4'. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i2c: designware: Convert driver to multibus/multiadapter framework
In preparation for the SoCFPGA support of the designware I2C driver,
convert this driver to the common CONFIG_SYS_I2C framework.
This patch converts all users of this driver, this is:
- ST spearxxx boards
- AXS101 (ARC700 platform)
I couldn't test this patch on those boards. Only compile tested for all
spear boards. And tested on SoCFPGA.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Marek Vasut ma...@denx.de
Cc: Vipin Kumar vipin.ku...@st.com
Cc: Alexey Brodkin abrod...@synopsys.com
---
arch/arm/cpu/arm926ejs/spear/cpu.c | 2 +-
drivers/i2c/Makefile | 2 +-
drivers/i2c/designware_i2c.c | 294 -
include/configs/axs101.h | 9 +-
include/configs/spear-common.h | 4 +-
include/configs/x600.h | 4 +-
6 files changed, 142 insertions(+), 173 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/spear/cpu.c
b/arch/arm/cpu/arm926ejs/spear/cpu.c
index 3757ffb..697e094 100644
--- a/arch/arm/cpu/arm926ejs/spear/cpu.c
+++ b/arch/arm/cpu/arm926ejs/spear/cpu.c
@@ -38,7 +38,7 @@ int arch_cpu_init(void)
#if defined(CONFIG_DW_UDC)
periph1_clken |= MISC_USBDENB;
#endif
-#if defined(CONFIG_DW_I2C)
+#if defined(CONFIG_SYS_I2C_DW)
periph1_clken |= MISC_I2CENB;
#endif
#if defined(CONFIG_ST_SMI)
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 416ea4f..b38327c 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -6,7 +6,6 @@
#
obj-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o
-obj-$(CONFIG_DW_I2C) += designware_i2c.o
obj-$(CONFIG_I2C_MV) += mv_i2c.o
obj-$(CONFIG_I2C_MXS) += mxs_i2c.o
obj-$(CONFIG_PCA9564_I2C) += pca9564_i2c.o
@@ -15,6 +14,7 @@ obj-$(CONFIG_U8500_I2C) += u8500_i2c.o
obj-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o
obj-$(CONFIG_SYS_I2C) += i2c_core.o
obj-$(CONFIG_SYS_I2C_DAVINCI) += davinci_i2c.o
+obj-$(CONFIG_SYS_I2C_DW) += designware_i2c.o
obj-$(CONFIG_SYS_I2C_FSL) += fsl_i2c.o
obj-$(CONFIG_SYS_I2C_FTI2C010) += fti2c010.o
obj-$(CONFIG_SYS_I2C_IHS) += ihs_i2c.o
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index c891ebd..1a4acdd 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -6,16 +6,34 @@
*/
#include common.h
+#include i2c.h
#include asm/io.h
#include designware_i2c.h
-#ifdef CONFIG_I2C_MULTI_BUS
-static unsigned int bus_initialized[CONFIG_SYS_I2C_BUS_MAX];
-static unsigned int current_bus = 0;
+static struct i2c_regs *i2c_get_base(struct i2c_adapter *adap)
+{
+ switch (adap-hwadapnr) {
+#if CONFIG_SYS_I2C_BUS_MAX = 4
+ case 3:
+ return (struct i2c_regs *)CONFIG_SYS_I2C_BASE3;
+#endif
+#if CONFIG_SYS_I2C_BUS_MAX = 3
+ case 2:
+ return (struct i2c_regs *)CONFIG_SYS_I2C_BASE2;
#endif
+#if CONFIG_SYS_I2C_BUS_MAX = 2
+ case 1:
+ return (struct i2c_regs *)CONFIG_SYS_I2C_BASE1;
+#endif
+ case 0:
+ return (struct i2c_regs *)CONFIG_SYS_I2C_BASE;
-static struct i2c_regs *i2c_regs_p =
-(struct i2c_regs *)CONFIG_SYS_I2C_BASE;
+ default:
+ printf(wrong hwadapnr: %d\n, adap-hwadapnr);
+ }
+
+ return NULL;
+}
/*
* set_speed - Set the i2c speed mode (standard, high, fast)
@@ -23,51 +41,52 @@ static struct i2c_regs *i2c_regs_p =
*
* Set the i2c speed mode (standard, high, fast)
*/
-static void set_speed(int i2c_spd)
+static void set_speed(struct i2c_adapter *adap, int i2c_spd)
{
+ struct i2c_regs *i2c_base = i2c_get_base(adap);
unsigned int cntl;
unsigned int hcnt, lcnt;
unsigned int enbl;
/* to set speed cltr must be disabled */
- enbl = readl(i2c_regs_p-ic_enable);
+ enbl = readl(i2c_base-ic_enable);
enbl = ~IC_ENABLE_0B;
- writel(enbl, i2c_regs_p-ic_enable);
+ writel(enbl, i2c_base-ic_enable);
- cntl = (readl(i2c_regs_p-ic_con) (~IC_CON_SPD_MSK));
+ cntl = (readl(i2c_base-ic_con) (~IC_CON_SPD_MSK));
switch (i2c_spd) {
case IC_SPEED_MODE_MAX:
cntl |= IC_CON_SPD_HS;
hcnt = (IC_CLK * MIN_HS_SCL_HIGHTIME) / NANO_TO_MICRO;
- writel(hcnt, i2c_regs_p-ic_hs_scl_hcnt);
+ writel(hcnt, i2c_base-ic_hs_scl_hcnt);
lcnt = (IC_CLK * MIN_HS_SCL_LOWTIME) / NANO_TO_MICRO;
- writel(lcnt, i2c_regs_p-ic_hs_scl_lcnt);
+ writel(lcnt, i2c_base-ic_hs_scl_lcnt);
break;
case IC_SPEED_MODE_STANDARD:
cntl |= IC_CON_SPD_SS;
hcnt = (IC_CLK * MIN_SS_SCL_HIGHTIME) / NANO_TO_MICRO;
- writel(hcnt, i2c_regs_p-ic_ss_scl_hcnt);
+ writel(hcnt, i2c_base-ic_ss_scl_hcnt);
lcnt = (IC_CLK * MIN_SS_SCL_LOWTIME) / NANO_TO_MICRO;
- writel(lcnt, i2c_regs_p-ic_ss_scl_lcnt);
+ writel(lcnt, i2c_base-ic_ss_scl_lcnt);
break;
case
[U-Boot] [PATCH] musb: fix warning in include/linux/usb/musb.h
Fix the following build warning by including linux/compat.h: include/linux/usb/musb.h:110: warning: 'struct device' declared inside parameter list include/linux/usb/musb.h:110: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- include/linux/usb/musb.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h index 9f65ef9..075d222 100644 --- a/include/linux/usb/musb.h +++ b/include/linux/usb/musb.h @@ -14,6 +14,8 @@ #define __deprecated #endif +#include linux/compat.h + /* The USB role is defined by the connector used on the board, so long as * standards are being followed. (Developer boards sometimes won't.) */ -- 2.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] ot1200: rework card detect for eMMC
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
---
board/bachmann/ot1200/ot1200.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/board/bachmann/ot1200/ot1200.c b/board/bachmann/ot1200/ot1200.c
index 45d761f..2ed8cf7 100644
--- a/board/bachmann/ot1200/ot1200.c
+++ b/board/bachmann/ot1200/ot1200.c
@@ -155,9 +155,10 @@ int board_mmc_getcd(struct mmc *mmc)
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
int ret;
- if (cfg-esdhc_base == USDHC3_BASE_ADDR)
- ret = 1;
- else {
+ if (cfg-esdhc_base == USDHC3_BASE_ADDR) {
+ gpio_direction_input(IMX_GPIO_NR(4, 5));
+ ret = gpio_get_value(IMX_GPIO_NR(4, 5));
+ } else {
gpio_direction_input(IMX_GPIO_NR(1, 4));
ret = !gpio_get_value(IMX_GPIO_NR(1, 4));
}
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] ot1200: add feature pads
The older 'mr' variant and the generic variant of the
OT1200 differ in some places. As the name suggests the
generic variant supports more boot devices.
In order to be compatible with the 'mr' variant we define
some 'feature' GPIOs. On the 'mr' variant this pads are
not connected so we define their state with the help
of the internal pullups.
On the generic variant this GPIOs are connected and
represent the state of the hardware.
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
---
board/bachmann/ot1200/ot1200.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/board/bachmann/ot1200/ot1200.c b/board/bachmann/ot1200/ot1200.c
index acf95cb..a2fb3cf 100644
--- a/board/bachmann/ot1200/ot1200.c
+++ b/board/bachmann/ot1200/ot1200.c
@@ -104,10 +104,25 @@ int board_spi_cs_gpio(unsigned bus, unsigned cs)
return (bus == 2 cs == 0) ? (IMX_GPIO_NR(1, 3)) : -1;
}
+static iomux_v3_cfg_t const feature_pads[] = {
+ /* SD card detect */
+ MX6_PAD_GPIO_4__GPIO1_IO04 | MUX_PAD_CTRL(PAD_CTL_PUS_100K_DOWN),
+
+ /* eMMC soldered? */
+ MX6_PAD_GPIO_19__GPIO4_IO05 | MUX_PAD_CTRL(PAD_CTL_PUS_100K_UP),
+};
+
+static void setup_iomux_features(void)
+{
+ imx_iomux_v3_setup_multiple_pads(feature_pads,
+ ARRAY_SIZE(feature_pads));
+}
+
int board_early_init_f(void)
{
setup_iomux_uart();
setup_iomux_spi();
+ setup_iomux_features();
return 0;
}
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] ot1200: add support for usdhc4
On the 'mr' variant switching to 'mmc dev 1' will result
in MMC: no card present.
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
---
board/bachmann/ot1200/ot1200.c | 54 ++
1 file changed, 49 insertions(+), 5 deletions(-)
diff --git a/board/bachmann/ot1200/ot1200.c b/board/bachmann/ot1200/ot1200.c
index a2fb3cf..45d761f 100644
--- a/board/bachmann/ot1200/ot1200.c
+++ b/board/bachmann/ot1200/ot1200.c
@@ -141,23 +141,67 @@ static iomux_v3_cfg_t const usdhc3_pads[] = {
MX6_PAD_SD3_RST__SD3_RESET | MUX_PAD_CTRL(USDHC_PAD_CTRL),
};
+iomux_v3_cfg_t const usdhc4_pads[] = {
+ MX6_PAD_SD4_CLK__SD4_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD4_CMD__SD4_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD4_DAT0__SD4_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD4_DAT1__SD4_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD4_DAT2__SD4_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD4_DAT3__SD4_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+};
+
int board_mmc_getcd(struct mmc *mmc)
{
- return 1;
+ struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
+ int ret;
+
+ if (cfg-esdhc_base == USDHC3_BASE_ADDR)
+ ret = 1;
+ else {
+ gpio_direction_input(IMX_GPIO_NR(1, 4));
+ ret = !gpio_get_value(IMX_GPIO_NR(1, 4));
+ }
+
+ return ret;
}
-struct fsl_esdhc_cfg usdhc_cfg[] = {
+struct fsl_esdhc_cfg usdhc_cfg[2] = {
{USDHC3_BASE_ADDR},
+ {USDHC4_BASE_ADDR},
};
int board_mmc_init(bd_t *bis)
{
+ s32 status = 0;
+ u32 index = 0;
+
usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
- usdhc_cfg[0].max_bus_width = 8;
+ usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC4_CLK);
- imx_iomux_v3_setup_multiple_pads(usdhc3_pads, ARRAY_SIZE(usdhc3_pads));
+ usdhc_cfg[0].max_bus_width = 8;
+ usdhc_cfg[1].max_bus_width = 4;
+
+ for (index = 0; index CONFIG_SYS_FSL_USDHC_NUM; ++index) {
+ switch (index) {
+ case 0:
+ imx_iomux_v3_setup_multiple_pads(
+ usdhc3_pads, ARRAY_SIZE(usdhc3_pads));
+ break;
+ case 1:
+ imx_iomux_v3_setup_multiple_pads(
+ usdhc4_pads, ARRAY_SIZE(usdhc4_pads));
+ break;
+ default:
+ printf(Warning: you configured more USDHC controllers
+ (%d) then supported by the board (%d)\n,
+ index + 1, CONFIG_SYS_FSL_USDHC_NUM);
+ return status;
+ }
+
+ status |= fsl_esdhc_initialize(bis, usdhc_cfg[index]);
+ }
- return fsl_esdhc_initialize(bis, usdhc_cfg[0]);
+ return status;
}
#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/7] dm-serial: bug fix and refactoring and conversion of Uniphier serial
Hi Simon, On Wed, 22 Oct 2014 21:24:22 -0600 Simon Glass s...@chromium.org wrote: HI Masahiro, On 22 October 2014 03:13, Masahiro Yamada yamad...@jp.panasonic.com wrote: 1/7: bug fix of console serial 2/7 - 3/7: cleanup 4/7: prepare some Kconfig entries 5/7 - 7/7: convert UniPhier serial driver and some cleanups Simon, As I promised before, here is the conversion of driver/serial/serial_uniphier.c into driver model. It has taken some time because I have had a hard time to find 1/7 bug. BTW, lowlevel-debug patches were really helpful to debug driver-model serial. http://patchwork.ozlabs.org/patch/384612/ http://patchwork.ozlabs.org/patch/384615/ http://patchwork.ozlabs.org/patch/384613/ http://patchwork.ozlabs.org/patch/384611/ Did you take a look at the idea of having standard names for the 'init' and 'putc' functions in the UART drivers? We could make that with with DM at least. This would require each driver to have a low-level 'init' function which just takes a UART address, and a 'putc' function that takes an address and a character. Do you mean 'putc' handler should be splited up into some low-level fragments and remove 'static' directive so that we can call it directly? Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mtd: nand: allow to skip BBT scanning during NAND inititialization
Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14), chip-scan_bbt() is called at the end of nand_scan_tail(). It means the first read access happens immediately after the generic NAND initialization process. It causes a problem to some SoCs of UniPhier platform because some of their register values need to be fixed up after the general initialization procedure has been finished. Otherwise, read asccess fails. Such a fix-up is SoC-specific enough to be written in a board file rather than in driver code. One of possible and clean enough ways to work around this issue is postpone the BBT scanning until necessary fix-up is done in board_late_init() or somewhere else. CONFIG_MTD_NAND_SKIP_BBTSCAN, if enabled, allows to skip the BBT scanning at the end of nand_scan_tail(). Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Scott Wood scottw...@freescale.com --- If this patch is accepted, I will turn on this config option for my boards. Changes in v2: - Bug fix ( config was missing from v1) drivers/mtd/nand/Kconfig | 13 + drivers/mtd/nand/nand.c | 4 2 files changed, 17 insertions(+) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 75c2c06..e1d6fbc 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -2,6 +2,19 @@ menu NAND Device Support if !SPL_BUILD +config MTD_NAND_SKIP_BBTSCAN + bool Skip BBT scanning + help + The current implementation of nand_scan_tail() calls scan_bbt handler + at the end of itself to build a bad block table. It means the first + read access happens in the initizalization procedure. It causes a + problem on some SoCs that need some extra SoC-specific settings + before starting read/write access. + + If this option is enabled, bad block scanning is skipped during the + nand device initialization. You are resposible to build a bad block + table lator. + config NAND_DENALI bool Support Denali NAND controller help diff --git a/drivers/mtd/nand/nand.c b/drivers/mtd/nand/nand.c index 4cf4c1c..a249647 100644 --- a/drivers/mtd/nand/nand.c +++ b/drivers/mtd/nand/nand.c @@ -88,6 +88,10 @@ static void nand_init_chip(int i) mtd-priv = nand; nand-IO_ADDR_R = nand-IO_ADDR_W = (void __iomem *)base_addr; +#ifdef CONFIG_MTD_NAND_SKIP_BBTSCAN + nand-options |= NAND_SKIP_BBTSCAN; +#endif + if (board_nand_init(nand)) return; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Collapsing buildman output dir?
Hey, So a common use case for me is building a single board. I've updated my wrapper script from BUILD_DIR=$MACHINE ./MAKEALL $MACHINE (roughly, of course) to: ./tools/buildman/buildman --keep-outputs -dvel --output $MACHINE ^$MACHINE$ Which results in my output being ./$MACHINE/current/current/$MACHINE rather than just $MACHINE. Is there a way we can collapse things down easily when we know we aren't going to be building multiple commits? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sun7i: Set CONFIG_ARMV7_SEC_BY_DEFAULT when CONFIG_OLD_KERNEL_COMPAT is set
On Thu, Oct 23, 2014 at 10:52:23AM +0200, Hans de Goede wrote: Hi Tom, On 10/22/2014 09:24 PM, Tom Rini wrote: On Wed, Oct 22, 2014 at 03:45:23PM +0200, Hans de Goede wrote: Old kernels cannot handle booting in non-secure (hyp) mode, so when CONFIG_OLD_KERNEL_COMPAT is set, also set CONFIG_ARMV7_SEC_BY_DEFAULT. Note that whether to booting secure or non-secure can always be overriden using the bootm_boot_mode environment variable. This belongs in Kconfig. If you want to make it really optional all the same, make modifying it depend on CONFIG_EXPERT too. I understand where your coming from, but the problem is that CONFIG_ARMV7_SEC_BY_DEFAULT as a Kconfig option should depend on CONFIG_ARMV7_VIRT or CONFIG_ARMV7_NONSEC, which depend on CONFIG_ARMV7_PSCI / CONFIG_ARMV7_PSCI_NR_CPUS and CONFIG_ARMV7_SECURE_BASE, all of which are currently set through include/configs/foo.h. True, but lets fix it. Ideally, we would have something to select ARMV7, but we don't yet, and I won't make that your pre-req. All of the above options are only used by sunxi and arndale and vexpress right now. Add arch/arm/cpu/armv7/Kconfig for the above ARMv7 options, source it from arch/arm/Kconfig and make the contents be on if ARNDALE || CA15 || SUNXI with a comment on needing to clean this up further once we have more fine-grained selects on SoC features. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation issue - need help!
Dear Joakim, dear Dirk,
In message
of14c3d470.864842b6-onc1257d7a.002471ac-c1257d7a.0024d...@transmode.se you
wrote:
Ouch, that was a nasty surprise.
Indeed.
In my original mail I referenced this potential solution, at least it
worked for me:
https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
That looks like the correct fix but I presume both .data.rel.ro and
data.rel.ro.local should be added?
I can confirm:
1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
5.5.x].
2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
problem go away.
3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
the problem go away.
4) For the problemativ 4.8.x versions of GCC, the following patch
apparently solves the problem for my (MPC5200 based) board - guess
this would have to be applied to all .lds files...
diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
index cd9e23f..82c86d7 100644
--- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
+++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
@@ -27,6 +27,8 @@ SECTIONS
{
_GOT2_TABLE_ = .;
KEEP(*(.got2))
+KEEP(*(.data.rel.ro))
+KEEP(*(.data.rel.ro.local))
KEEP(*(.got))
PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
_FIXUP_TABLE_ = .;
Given that GCC 4.9.1 apparently solves this issue I wonder which
approach we should take?
Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
doing [1] ?
[1] https://lkml.org/lkml/2014/10/10/272
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I mean, I . . . think to understand you, I just don't know what you
are saying ...- Terry Pratchett, _Soul Music_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sunxi: Add CONFIG_OLD_SUNXI_KERNEL_COMPAT Kconfig option
On Thu, Oct 23, 2014 at 10:40:53AM +0200, Hans de Goede wrote: Add a Kconfig option which users can select when they want to boot older kernels, e.g. the linux-sunxi 3.4 kernels. For now this just forces the pll5 p value to 1 (divide by 2) as that is what those kernels are hardcoded too, in the future this may enable further workarounds. Signed-off-by: Hans de Goede hdego...@redhat.com Reviewed-by: Tom Rini tr...@ti.com -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 7/8] serial: uniphier: move CONFIG_UNIPHIER_SERIAL to Kconfig
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Simon Glass s...@chromium.org --- Changes in v2: None configs/ph1_ld4_defconfig | 1 + configs/ph1_pro4_defconfig | 1 + configs/ph1_sld8_defconfig | 1 + drivers/serial/Kconfig | 6 ++ include/configs/ph1_ld4.h | 4 +--- include/configs/ph1_pro4.h | 4 +--- include/configs/ph1_sld8.h | 4 +--- 7 files changed, 12 insertions(+), 9 deletions(-) diff --git a/configs/ph1_ld4_defconfig b/configs/ph1_ld4_defconfig index c8404f8..e6aba42 100644 --- a/configs/ph1_ld4_defconfig +++ b/configs/ph1_ld4_defconfig @@ -7,4 +7,5 @@ CONFIG_NAND_DENALI=y CONFIG_SYS_NAND_DENALI_64BIT=y CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 CONFIG_DM_SERIAL=y +CONFIG_UNIPHIER_SERIAL=y S:CONFIG_SPL_NAND_DENALI=y diff --git a/configs/ph1_pro4_defconfig b/configs/ph1_pro4_defconfig index 5c051e3..334ec4b 100644 --- a/configs/ph1_pro4_defconfig +++ b/configs/ph1_pro4_defconfig @@ -7,4 +7,5 @@ CONFIG_NAND_DENALI=y CONFIG_SYS_NAND_DENALI_64BIT=y CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 CONFIG_DM_SERIAL=y +CONFIG_UNIPHIER_SERIAL=y S:CONFIG_SPL_NAND_DENALI=y diff --git a/configs/ph1_sld8_defconfig b/configs/ph1_sld8_defconfig index 2c636e6..4e8f354 100644 --- a/configs/ph1_sld8_defconfig +++ b/configs/ph1_sld8_defconfig @@ -7,4 +7,5 @@ CONFIG_NAND_DENALI=y CONFIG_SYS_NAND_DENALI_64BIT=y CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 CONFIG_DM_SERIAL=y +CONFIG_UNIPHIER_SERIAL=y S:CONFIG_SPL_NAND_DENALI=y diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index 6a392ba..a0b6e02 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -4,3 +4,9 @@ config DM_SERIAL help If you want to use driver model for serial drivers, say Y. To use legacy serial drivers, say N. + +config UNIPHIER_SERIAL + bool UniPhier on-chip UART support + depends on ARCH_UNIPHIER DM_SERIAL + help + Support for the on-chip UARTs on the Panasonic UniPhier platform. diff --git a/include/configs/ph1_ld4.h b/include/configs/ph1_ld4.h index a546865..005a853 100644 --- a/include/configs/ph1_ld4.h +++ b/include/configs/ph1_ld4.h @@ -28,9 +28,7 @@ * SoC UART : enable CONFIG_UNIPHIER_SERIAL * On-board UART: enable CONFIG_SYS_NS16550_SERIAL */ -#if 1 -#define CONFIG_UNIPHIER_SERIAL -#else +#if 0 #define CONFIG_SYS_NS16550_SERIAL #endif diff --git a/include/configs/ph1_pro4.h b/include/configs/ph1_pro4.h index 85c14ba..7dd6fd2 100644 --- a/include/configs/ph1_pro4.h +++ b/include/configs/ph1_pro4.h @@ -28,9 +28,7 @@ * SoC UART : enable CONFIG_UNIPHIER_SERIAL * On-board UART: enable CONFIG_SYS_NS16550_SERIAL */ -#if 1 -#define CONFIG_UNIPHIER_SERIAL -#else +#if 0 #define CONFIG_SYS_NS16550_SERIAL #endif diff --git a/include/configs/ph1_sld8.h b/include/configs/ph1_sld8.h index 41e2299..1062aac 100644 --- a/include/configs/ph1_sld8.h +++ b/include/configs/ph1_sld8.h @@ -28,9 +28,7 @@ * SoC UART : enable CONFIG_UNIPHIER_SERIAL * On-board UART: enable CONFIG_SYS_NS16550_SERIAL */ -#if 1 -#define CONFIG_UNIPHIER_SERIAL -#else +#if 0 #define CONFIG_SYS_NS16550_SERIAL #endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/8] dm-serial: bug fix and refactoring and conversion of Uniphier serial
1/8: cleanup 2/8: bug fix 3/8 - 4/8: cleanup 5/8: prepare some Kconfig entries 7/8 - 8/8: convert UniPhier serial driver and some cleanups Masahiro Yamada (8): serial: add static directive to local functions dm: serial: fix console putc dm: serial: remove unnecessary casting dm: serial: consolidate common code more dm: add entries to Kconfig dm: serial: use Driver Model for UniPhier serial driver serial: uniphier: move CONFIG_UNIPHIER_SERIAL to Kconfig serial: remove uniphier_serial_initialize() call arch/arm/cpu/armv7/uniphier/ph1-ld4/Makefile | 1 + arch/arm/cpu/armv7/uniphier/ph1-ld4/platdevice.c | 15 ++ arch/arm/cpu/armv7/uniphier/ph1-pro4/Makefile | 1 + arch/arm/cpu/armv7/uniphier/ph1-pro4/platdevice.c | 15 ++ arch/arm/cpu/armv7/uniphier/ph1-sld8/Makefile | 1 + arch/arm/cpu/armv7/uniphier/ph1-sld8/platdevice.c | 15 ++ arch/arm/include/asm/arch-uniphier/platdevice.h | 24 +++ configs/ph1_ld4_defconfig | 3 + configs/ph1_pro4_defconfig| 3 + configs/ph1_sld8_defconfig| 3 + drivers/core/Kconfig | 6 + drivers/gpio/Kconfig | 6 + drivers/serial/Kconfig| 12 ++ drivers/serial/serial-uclass.c| 83 + drivers/serial/serial.c | 2 - drivers/serial/serial_ns16550.c | 21 +-- drivers/serial/serial_s3c24x0.c | 10 +- drivers/serial/serial_uniphier.c | 199 -- drivers/spi/Kconfig | 6 + include/common.h | 7 - include/configs/ph1_ld4.h | 6 +- include/configs/ph1_pro4.h| 6 +- include/configs/ph1_sld8.h| 6 +- include/configs/uniphier-common.h | 7 +- include/dm/platform_data/serial-uniphier.h| 18 ++ 25 files changed, 261 insertions(+), 215 deletions(-) create mode 100644 arch/arm/cpu/armv7/uniphier/ph1-ld4/platdevice.c create mode 100644 arch/arm/cpu/armv7/uniphier/ph1-pro4/platdevice.c create mode 100644 arch/arm/cpu/armv7/uniphier/ph1-sld8/platdevice.c create mode 100644 arch/arm/include/asm/arch-uniphier/platdevice.h create mode 100644 include/dm/platform_data/serial-uniphier.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 8/8] serial: remove uniphier_serial_initialize() call
The UniPhier serial driver has been converted to driver model. Let's remove uniphier_serial_initialize() call from the old serial driver framework. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Simon Glass s...@chromium.org --- Changes in v2: None drivers/serial/serial.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c index 82fbbd9..bbe60af 100644 --- a/drivers/serial/serial.c +++ b/drivers/serial/serial.c @@ -157,7 +157,6 @@ serial_initfunc(sh_serial_initialize); serial_initfunc(arm_dcc_initialize); serial_initfunc(mxs_auart_initialize); serial_initfunc(arc_serial_initialize); -serial_initfunc(uniphier_serial_initialize); /** * serial_register() - Register serial driver with serial driver core @@ -251,7 +250,6 @@ void serial_initialize(void) arm_dcc_initialize(); mxs_auart_initialize(); arc_serial_initialize(); - uniphier_serial_initialize(); serial_assign(default_serial_console()-name); } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/8] dm: serial: remove unnecessary casting
The type (void *) can be directly passed to a function that
takes a specific pointer type.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Changes in v2:
- Rebase
drivers/serial/serial-uclass.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index f2bc4d8..5767312 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -135,9 +135,7 @@ void serial_stdio_init(void)
static void serial_stub_putc(struct stdio_dev *sdev, const char ch)
{
- struct udevice *dev = sdev-priv;
-
- serial_putc_dev(dev, ch);
+ serial_putc_dev(sdev-priv, ch);
}
void serial_stub_puts(struct stdio_dev *sdev, const char *str)
@@ -148,9 +146,7 @@ void serial_stub_puts(struct stdio_dev *sdev, const char
*str)
int serial_stub_getc(struct stdio_dev *sdev)
{
- struct udevice *dev = sdev-priv;
-
- return serial_getc_dev(dev);
+ return serial_getc_dev(sdev-priv);
}
int serial_stub_tstc(struct stdio_dev *sdev)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/8] dm: serial: fix console putc
Commit b8893327e9d2 (dm: serial: Put common code into separate functions)
consolidated getc() correctly, but introduced another bug to putc();
serial_stub_putc() passes sdev-priv to serial_putc_dev(), but
serial_putc_dev() uses cur_dev instead of the given argument.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Changes in v2:
- Newly added
drivers/serial/serial-uclass.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 1a75950..f2bc4d8 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -73,14 +73,14 @@ void serial_initialize(void)
static void serial_putc_dev(struct udevice *dev, char ch)
{
- struct dm_serial_ops *ops = serial_get_ops(cur_dev);
+ struct dm_serial_ops *ops = serial_get_ops(dev);
int err;
do {
- err = ops-putc(cur_dev, ch);
+ err = ops-putc(dev, ch);
} while (err == -EAGAIN);
if (ch == '\n')
- serial_putc('\r');
+ serial_putc_dev(dev, '\r');
}
void serial_putc(char ch)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/8] dm: serial: consolidate common code more
Commit b8893327e9d2 (dm: serial: Put common code into separate functions)
consolidated getc() and putc(). This commit does more puts() and tsts().
Also rename locally used functions to _serial_*() for clarification
because we have similar functions names here are there in this file.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Changes in v2:
- Rebase
drivers/serial/serial-uclass.c | 75 ++
1 file changed, 39 insertions(+), 36 deletions(-)
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 5767312..8764194 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -71,7 +71,7 @@ void serial_initialize(void)
serial_find_console_or_panic();
}
-static void serial_putc_dev(struct udevice *dev, char ch)
+static void _serial_putc(struct udevice *dev, char ch)
{
struct dm_serial_ops *ops = serial_get_ops(dev);
int err;
@@ -80,53 +80,63 @@ static void serial_putc_dev(struct udevice *dev, char ch)
err = ops-putc(dev, ch);
} while (err == -EAGAIN);
if (ch == '\n')
- serial_putc_dev(dev, '\r');
+ _serial_putc(dev, '\r');
}
-void serial_putc(char ch)
+static void _serial_puts(struct udevice *dev, const char *str)
{
- serial_putc_dev(cur_dev, ch);
+ while (*str)
+ _serial_putc(dev, *str++);
}
-void serial_setbrg(void)
+static int _serial_getc(struct udevice *dev)
{
- struct dm_serial_ops *ops = serial_get_ops(cur_dev);
+ struct dm_serial_ops *ops = serial_get_ops(dev);
+ int err;
- if (ops-setbrg)
- ops-setbrg(cur_dev, gd-baudrate);
-}
+ do {
+ err = ops-getc(dev);
+ } while (err == -EAGAIN);
-void serial_puts(const char *str)
-{
- while (*str)
- serial_putc(*str++);
+ return err = 0 ? err : 0;
}
-int serial_tstc(void)
+static int _serial_tstc(struct udevice *dev)
{
- struct dm_serial_ops *ops = serial_get_ops(cur_dev);
+ struct dm_serial_ops *ops = serial_get_ops(dev);
if (ops-pending)
- return ops-pending(cur_dev, true);
+ return ops-pending(dev, true);
return 1;
}
-static int serial_getc_dev(struct udevice *dev)
+void serial_putc(char ch)
{
- struct dm_serial_ops *ops = serial_get_ops(dev);
- int err;
-
- do {
- err = ops-getc(dev);
- } while (err == -EAGAIN);
+ _serial_putc(cur_dev, ch);
+}
- return err = 0 ? err : 0;
+void serial_puts(const char *str)
+{
+ _serial_puts(cur_dev, str);
}
int serial_getc(void)
{
- return serial_getc_dev(cur_dev);
+ return _serial_getc(cur_dev);
+}
+
+int serial_tstc(void)
+{
+ return _serial_tstc(cur_dev);
+}
+
+void serial_setbrg(void)
+{
+ struct dm_serial_ops *ops = serial_get_ops(cur_dev);
+
+ if (ops-setbrg)
+ ops-setbrg(cur_dev, gd-baudrate);
}
void serial_stdio_init(void)
@@ -135,29 +145,22 @@ void serial_stdio_init(void)
static void serial_stub_putc(struct stdio_dev *sdev, const char ch)
{
- serial_putc_dev(sdev-priv, ch);
+ _serial_putc(sdev-priv, ch);
}
void serial_stub_puts(struct stdio_dev *sdev, const char *str)
{
- while (*str)
- serial_stub_putc(sdev, *str++);
+ _serial_puts(sdev-priv, str);
}
int serial_stub_getc(struct stdio_dev *sdev)
{
- return serial_getc_dev(sdev-priv);
+ return _serial_getc(sdev-priv);
}
int serial_stub_tstc(struct stdio_dev *sdev)
{
- struct udevice *dev = sdev-priv;
- struct dm_serial_ops *ops = serial_get_ops(dev);
-
- if (ops-pending)
- return ops-pending(dev, true);
-
- return 1;
+ return _serial_tstc(sdev-priv);
}
static int serial_post_probe(struct udevice *dev)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/8] dm: add entries to Kconfig
Create entries of CONFIG_DM, CONFIG_DM_SERIAL, CONFIG_DM_GPIO and CONFIG_DM_SPI. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Simon Glass s...@chromium.org --- Changes in v2: - Add CONFIG_DM_SPI drivers/core/Kconfig | 6 ++ drivers/gpio/Kconfig | 6 ++ drivers/serial/Kconfig | 6 ++ drivers/spi/Kconfig| 6 ++ 4 files changed, 24 insertions(+) diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig index e69de29..d2799dc 100644 --- a/drivers/core/Kconfig +++ b/drivers/core/Kconfig @@ -0,0 +1,6 @@ +config DM + bool Enable Driver Model + depends on !SPL_BUILD + help + This config option enables Driver Model. + To use legacy drivers, say N. diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index e69de29..d21302f 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -0,0 +1,6 @@ +config DM_GPIO + bool Enable Driver Model for GPIO drivers + depends on DM + help + If you want to use driver model for GPIO drivers, say Y. + To use legacy GPIO drivers, say N. diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index e69de29..6a392ba 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -0,0 +1,6 @@ +config DM_SERIAL + bool Enable Driver Model for serial drivers + depends on DM + help + If you want to use driver model for serial drivers, say Y. + To use legacy serial drivers, say N. diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index e69de29..e1678e6 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -0,0 +1,6 @@ +config DM_SPI + bool Enable Driver Model for SPI drivers + depends on DM + help + If you want to use driver model for SPI drivers, say Y. + To use legacy SPI drivers, say N. -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/8] dm: serial: use Driver Model for UniPhier serial driver
This commit converts UniPhier on-chip serial driver to driver model. Since UniPhier SoCs do not have Device Tree support, some board files should be added under arch/arm/cpu/armv7/uniphier/ph1-*/ directories. (Device Tree support for UniPhier platform is still under way.) Now the base address and master clock frequency are passed from platform data, so CONFIG_SYS_UNIPHIER_SERIAL_BASE* and CONFIG_SYS_UNIPHIER_UART_CLK should be removed. Tested on UniPhier PH1-LD4 ref board. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Simon Glass s...@chromium.org --- Changes in v2: None arch/arm/cpu/armv7/uniphier/ph1-ld4/Makefile | 1 + arch/arm/cpu/armv7/uniphier/ph1-ld4/platdevice.c | 15 ++ arch/arm/cpu/armv7/uniphier/ph1-pro4/Makefile | 1 + arch/arm/cpu/armv7/uniphier/ph1-pro4/platdevice.c | 15 ++ arch/arm/cpu/armv7/uniphier/ph1-sld8/Makefile | 1 + arch/arm/cpu/armv7/uniphier/ph1-sld8/platdevice.c | 15 ++ arch/arm/include/asm/arch-uniphier/platdevice.h | 24 +++ configs/ph1_ld4_defconfig | 2 + configs/ph1_pro4_defconfig| 2 + configs/ph1_sld8_defconfig| 2 + drivers/serial/serial_uniphier.c | 199 -- include/configs/ph1_ld4.h | 2 - include/configs/ph1_pro4.h| 2 - include/configs/ph1_sld8.h| 2 - include/configs/uniphier-common.h | 7 +- include/dm/platform_data/serial-uniphier.h| 18 ++ 16 files changed, 172 insertions(+), 136 deletions(-) create mode 100644 arch/arm/cpu/armv7/uniphier/ph1-ld4/platdevice.c create mode 100644 arch/arm/cpu/armv7/uniphier/ph1-pro4/platdevice.c create mode 100644 arch/arm/cpu/armv7/uniphier/ph1-sld8/platdevice.c create mode 100644 arch/arm/include/asm/arch-uniphier/platdevice.h create mode 100644 include/dm/platform_data/serial-uniphier.h diff --git a/arch/arm/cpu/armv7/uniphier/ph1-ld4/Makefile b/arch/arm/cpu/armv7/uniphier/ph1-ld4/Makefile index b385e19..781b511 100644 --- a/arch/arm/cpu/armv7/uniphier/ph1-ld4/Makefile +++ b/arch/arm/cpu/armv7/uniphier/ph1-ld4/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_DISPLAY_BOARDINFO) += board_info.o +obj-y += platdevice.o obj-y += boot-mode.o obj-$(CONFIG_BOARD_POSTCLK_INIT) += board_postclk_init.o bcu_init.o \ sbc_init.o sg_init.o pll_init.o clkrst_init.o pinctrl.o diff --git a/arch/arm/cpu/armv7/uniphier/ph1-ld4/platdevice.c b/arch/arm/cpu/armv7/uniphier/ph1-ld4/platdevice.c new file mode 100644 index 000..0047223 --- /dev/null +++ b/arch/arm/cpu/armv7/uniphier/ph1-ld4/platdevice.c @@ -0,0 +1,15 @@ +/* + * Copyright (C) 2014 Panasonic Corporation + * Author: Masahiro Yamada yamad...@jp.panasonic.com + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include asm/arch/platdevice.h + +#define UART_MASTER_CLK36864000 + +SERIAL_DEVICE(0, 0x54006800, UART_MASTER_CLK) +SERIAL_DEVICE(1, 0x54006900, UART_MASTER_CLK) +SERIAL_DEVICE(2, 0x54006a00, UART_MASTER_CLK) +SERIAL_DEVICE(3, 0x54006b00, UART_MASTER_CLK) diff --git a/arch/arm/cpu/armv7/uniphier/ph1-pro4/Makefile b/arch/arm/cpu/armv7/uniphier/ph1-pro4/Makefile index 712afd1..e11f4f6 100644 --- a/arch/arm/cpu/armv7/uniphier/ph1-pro4/Makefile +++ b/arch/arm/cpu/armv7/uniphier/ph1-pro4/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_DISPLAY_BOARDINFO) += board_info.o +obj-y += platdevice.o obj-y += boot-mode.o obj-$(CONFIG_BOARD_POSTCLK_INIT) += board_postclk_init.o sbc_init.o \ sg_init.o pll_init.o clkrst_init.o pinctrl.o diff --git a/arch/arm/cpu/armv7/uniphier/ph1-pro4/platdevice.c b/arch/arm/cpu/armv7/uniphier/ph1-pro4/platdevice.c new file mode 100644 index 000..6da921e --- /dev/null +++ b/arch/arm/cpu/armv7/uniphier/ph1-pro4/platdevice.c @@ -0,0 +1,15 @@ +/* + * Copyright (C) 2014 Panasonic Corporation + * Author: Masahiro Yamada yamad...@jp.panasonic.com + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include asm/arch/platdevice.h + +#define UART_MASTER_CLK73728000 + +SERIAL_DEVICE(0, 0x54006800, UART_MASTER_CLK) +SERIAL_DEVICE(1, 0x54006900, UART_MASTER_CLK) +SERIAL_DEVICE(2, 0x54006a00, UART_MASTER_CLK) +SERIAL_DEVICE(3, 0x54006b00, UART_MASTER_CLK) diff --git a/arch/arm/cpu/armv7/uniphier/ph1-sld8/Makefile b/arch/arm/cpu/armv7/uniphier/ph1-sld8/Makefile index b385e19..781b511 100644 --- a/arch/arm/cpu/armv7/uniphier/ph1-sld8/Makefile +++ b/arch/arm/cpu/armv7/uniphier/ph1-sld8/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_DISPLAY_BOARDINFO) += board_info.o +obj-y += platdevice.o obj-y += boot-mode.o obj-$(CONFIG_BOARD_POSTCLK_INIT) += board_postclk_init.o bcu_init.o \ sbc_init.o sg_init.o pll_init.o clkrst_init.o pinctrl.o diff --git a/arch/arm/cpu/armv7/uniphier/ph1-sld8/platdevice.c b/arch/arm/cpu/armv7/uniphier/ph1-sld8/platdevice.c new file mode 100644 index 000..59d054a --- /dev/null
[U-Boot] [PATCH v2 1/8] serial: add static directive to local functions
The functions _serial_putc, _serial_putc_raw, _serial_puts,
_serial_getc, _serial_tstc, _serial_setbrg are defined and used
locally in each of serial_ns16550.c and serial_s3c24x0.c.
Add static directive to them and remove declarations from
include/common.h.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in v2: None
drivers/serial/serial_ns16550.c | 21 +++--
drivers/serial/serial_s3c24x0.c | 10 +-
include/common.h| 7 ---
3 files changed, 12 insertions(+), 26 deletions(-)
diff --git a/drivers/serial/serial_ns16550.c b/drivers/serial/serial_ns16550.c
index 632da4c..799ef6a 100644
--- a/drivers/serial/serial_ns16550.c
+++ b/drivers/serial/serial_ns16550.c
@@ -119,8 +119,7 @@ static NS16550_t serial_ports[6] = {
.puts = eserial##port##_puts, \
}
-void
-_serial_putc(const char c,const int port)
+static void _serial_putc(const char c, const int port)
{
if (c == '\n')
NS16550_putc(PORT, '\r');
@@ -128,35 +127,29 @@ _serial_putc(const char c,const int port)
NS16550_putc(PORT, c);
}
-void
-_serial_putc_raw(const char c,const int port)
+static void _serial_putc_raw(const char c, const int port)
{
NS16550_putc(PORT, c);
}
-void
-_serial_puts (const char *s,const int port)
+static void _serial_puts(const char *s, const int port)
{
while (*s) {
- _serial_putc (*s++,port);
+ _serial_putc(*s++, port);
}
}
-
-int
-_serial_getc(const int port)
+static int _serial_getc(const int port)
{
return NS16550_getc(PORT);
}
-int
-_serial_tstc(const int port)
+static int _serial_tstc(const int port)
{
return NS16550_tstc(PORT);
}
-void
-_serial_setbrg (const int port)
+static void _serial_setbrg(const int port)
{
int clock_divisor;
diff --git a/drivers/serial/serial_s3c24x0.c b/drivers/serial/serial_s3c24x0.c
index c07f4c9..7afc504 100644
--- a/drivers/serial/serial_s3c24x0.c
+++ b/drivers/serial/serial_s3c24x0.c
@@ -69,7 +69,7 @@ DECLARE_GLOBAL_DATA_PTR;
static int hwflow;
#endif
-void _serial_setbrg(const int dev_index)
+static void _serial_setbrg(const int dev_index)
{
struct s3c24x0_uart *uart = s3c24x0_get_base_uart(dev_index);
unsigned int reg = 0;
@@ -131,7 +131,7 @@ static int serial_init_dev(const int dev_index)
* otherwise. When the function is succesfull, the character read is
* written into its argument c.
*/
-int _serial_getc(const int dev_index)
+static int _serial_getc(const int dev_index)
{
struct s3c24x0_uart *uart = s3c24x0_get_base_uart(dev_index);
@@ -181,7 +181,7 @@ void enable_putc(void)
/*
* Output a single byte to the serial port.
*/
-void _serial_putc(const char c, const int dev_index)
+static void _serial_putc(const char c, const int dev_index)
{
struct s3c24x0_uart *uart = s3c24x0_get_base_uart(dev_index);
#ifdef CONFIG_MODEM_SUPPORT
@@ -212,7 +212,7 @@ static inline void serial_putc_dev(unsigned int dev_index,
const char c)
/*
* Test whether a character is in the RX buffer
*/
-int _serial_tstc(const int dev_index)
+static int _serial_tstc(const int dev_index)
{
struct s3c24x0_uart *uart = s3c24x0_get_base_uart(dev_index);
@@ -224,7 +224,7 @@ static inline int serial_tstc_dev(unsigned int dev_index)
return _serial_tstc(dev_index);
}
-void _serial_puts(const char *s, const int dev_index)
+static void _serial_puts(const char *s, const int dev_index)
{
while (*s) {
_serial_putc(*s++, dev_index);
diff --git a/include/common.h b/include/common.h
index d5020c8..bcf6c7e 100644
--- a/include/common.h
+++ b/include/common.h
@@ -636,13 +636,6 @@ struct stdio_dev;
int serial_stub_getc(struct stdio_dev *sdev);
int serial_stub_tstc(struct stdio_dev *sdev);
-void _serial_setbrg (const int);
-void _serial_putc (const char, const int);
-void _serial_putc_raw(const char, const int);
-void _serial_puts (const char *, const int);
-int_serial_getc (const int);
-int_serial_tstc (const int);
-
/* $(CPU)/speed.c */
intget_clocks (void);
intget_clocks_866 (void);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] dm: serial: fix a bug of console putc
Hi Simon,
On Wed, 22 Oct 2014 17:36:06 -0600
Simon Glass s...@chromium.org wrote:
drivers/serial/serial-uclass.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 6dde4ea..163308b 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -127,8 +127,13 @@ void serial_stub_putc(struct stdio_dev *sdev, const
char ch)
{
struct udevice *dev = sdev-priv;
struct dm_serial_ops *ops = serial_get_ops(dev);
+ int err;
- ops-putc(dev, ch);
+ do {
+ err = ops-putc(cur_dev, ch);
+ } while (err == -EAGAIN);
+ if (ch == '\n')
+ serial_putc('\r');
}
void serial_stub_puts(struct stdio_dev *sdev, const char *str)
--
1.9.1
Sorry for the bug, but I did fix it some weeks OK. Please see this patch:
http://patchwork.ozlabs.org/patch/395725/
Hmm, I checked it out, but I am afraid serial_stub_putc() is still buggy.
Please check this:
http://patchwork.ozlabs.org/patch/402479/
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] spi: sf: ICH SPI driver fix and SST25* changes
This series fix several bugs in current ICH SPI driver as well as adding byte program support for the SST25* flash. Note only SST25* flash params are updated in patch #4 and #5 as an example. Other flash parts are untouched but can be updated after checking all flash parts' datasheets. Simon, I can only test the ICH SPI driver with an ICH 7 compatible chipset. ICH 9 should work and it is appreciated if you could help testing and confirm it really does not break anything. Bin Meng (5): spi/ich.c: Fix a bug of reading from a non-64 bytes aligned address spi/ich.c: Set the rx operation mode for ich 7 spi: sf: Support byte program for sst spi flash sf: Update SST25* flash params of supported read commands sf: Update SST25* flash params of sector size numbers drivers/mtd/spi/sf_internal.h | 2 ++ drivers/mtd/spi/sf_ops.c | 31 +++ drivers/mtd/spi/sf_params.c | 20 ++-- drivers/mtd/spi/sf_probe.c| 8 ++-- drivers/spi/ich.c | 26 +++--- include/spi.h | 1 + include/spi_flash.h | 3 ++- 7 files changed, 63 insertions(+), 28 deletions(-) -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] spi/ich.c: Fix a bug of reading from a non-64 bytes aligned address
The ich spi controller driver spi_xfer() tries to align reading
address to 64 bytes when doing spi data in, which causes a bug of
either infinite loop or a huge size memcpy().
Actually the ich spi controller does not have such requirement of
64 bytes alignment when reading data from spi slave devices.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
drivers/spi/ich.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index f5c6f3e..c4d3a29 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -483,8 +483,6 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
const void *dout,
struct spi_trans *trans = ich-trans;
unsigned type = flags (SPI_XFER_BEGIN | SPI_XFER_END);
int using_cmd = 0;
- /* Align read transactions to 64-byte boundaries */
- char buff[ctlr.databytes];
/* Ee don't support writing partial bytes. */
if (bitlen % 8) {
@@ -632,14 +630,9 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
const void *dout,
*/
while (trans-bytesout || trans-bytesin) {
uint32_t data_length;
- uint32_t aligned_offset;
- uint32_t diff;
-
- aligned_offset = trans-offset ~(ctlr.databytes - 1);
- diff = trans-offset - aligned_offset;
/* SPI addresses are 24 bit only */
- ich_writel(aligned_offset 0x00FF, ctlr.addr);
+ ich_writel(trans-offset 0x00FF, ctlr.addr);
if (trans-bytesout)
data_length = min(trans-bytesout, ctlr.databytes);
@@ -673,13 +666,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
const void *dout,
}
if (trans-bytesin) {
- if (diff) {
- data_length -= diff;
- read_reg(ctlr.data, buff, ctlr.databytes);
- memcpy(trans-in, buff + diff, data_length);
- } else {
- read_reg(ctlr.data, trans-in, data_length);
- }
+ read_reg(ctlr.data, trans-in, data_length);
spi_use_in(trans, data_length);
if (with_address)
trans-offset += data_length;
--
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/5] spi/ich.c: Set the rx operation mode for ich 7
ICH 7 SPI controller only supports array read command (03h). Fast array read command (0Bh) is not supported. Signed-off-by: Bin Meng bmeng...@gmail.com --- drivers/spi/ich.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c index c4d3a29..b356411 100644 --- a/drivers/spi/ich.c +++ b/drivers/spi/ich.c @@ -141,6 +141,10 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs, ich-slave.max_write_size = ctlr.databytes; ich-speed = max_hz; + /* ICH 7 SPI controller only supports array read command */ + if (ctlr.ich_version == 7) + ich-slave.op_mode_rx = SPI_OPM_RX_AS; + return ich-slave; } -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] spi: sf: Support byte program for sst spi flash
Currently if SST flash advertises SST_WP flag in the params table
the word program command (ADh) with auto address increment will be
used for the flash write op. However some SPI controllers do not
support the word program command (like the Intel ICH 7), the byte
programm command (02h) has to be used.
A new TX operation mode SPI_OPM_TX_BP is introduced for such SPI
controller to use byte program op for SST flash.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
drivers/mtd/spi/sf_internal.h | 2 ++
drivers/mtd/spi/sf_ops.c | 31 +++
drivers/mtd/spi/sf_probe.c| 8 ++--
drivers/spi/ich.c | 9 +++--
include/spi.h | 1 +
5 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 19d4914..c185e04 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -77,6 +77,8 @@
int sst_write_wp(struct spi_flash *flash, u32 offset, size_t len,
const void *buf);
+int sst_write_bp(struct spi_flash *flash, u32 offset, size_t len,
+ const void *buf);
#endif
/* Send a single-byte command to the device and read the response */
diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
index 85cf22d..3703acb 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -516,4 +516,35 @@ int sst_write_wp(struct spi_flash *flash, u32 offset,
size_t len,
spi_release_bus(flash-spi);
return ret;
}
+
+int sst_write_bp(struct spi_flash *flash, u32 offset, size_t len,
+ const void *buf)
+{
+ size_t actual;
+ int ret;
+
+ ret = spi_claim_bus(flash-spi);
+ if (ret) {
+ debug(SF: Unable to claim SPI bus\n);
+ return ret;
+ }
+
+ for (actual = 0; actual len; actual++) {
+ ret = sst_byte_write(flash, offset, buf + actual);
+ if (ret) {
+ debug(SF: sst byte program failed\n);
+ break;
+ }
+ offset++;
+ }
+
+ if (!ret)
+ ret = spi_flash_cmd_write_disable(flash);
+
+ debug(SF: sst: program %s %zu bytes @ 0x%zx\n,
+ ret ? failure : success, len, offset - actual);
+
+ spi_release_bus(flash-spi);
+ return ret;
+}
#endif
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 4d148d1..1b48955 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -138,8 +138,12 @@ static struct spi_flash *spi_flash_validate_params(struct
spi_slave *spi,
/* Assign spi_flash ops */
flash-write = spi_flash_cmd_write_ops;
#ifdef CONFIG_SPI_FLASH_SST
- if (params-flags SST_WP)
- flash-write = sst_write_wp;
+ if (params-flags SST_WP) {
+ if (flash-spi-op_mode_tx SPI_OPM_TX_BP)
+ flash-write = sst_write_bp;
+ else
+ flash-write = sst_write_wp;
+ }
#endif
flash-erase = spi_flash_cmd_erase_ops;
flash-read = spi_flash_cmd_read_ops;
diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index b356411..16730ec 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -141,9 +141,14 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
ich-slave.max_write_size = ctlr.databytes;
ich-speed = max_hz;
- /* ICH 7 SPI controller only supports array read command */
- if (ctlr.ich_version == 7)
+ /*
+* ICH 7 SPI controller only supports array read command
+* and byte program command for SST flash
+*/
+ if (ctlr.ich_version == 7) {
ich-slave.op_mode_rx = SPI_OPM_RX_AS;
+ ich-slave.op_mode_tx = SPI_OPM_TX_BP;
+ }
return ich-slave;
}
diff --git a/include/spi.h b/include/spi.h
index ffd6647..a4d3f5f 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -34,6 +34,7 @@
/* SPI TX operation modes */
#define SPI_OPM_TX_QPP 1 0
+#define SPI_OPM_TX_BP 1 1
/* SPI RX operation modes */
#define SPI_OPM_RX_AS 1 0
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] sf: Update SST25* flash params of supported read commands
Explicitly list supported read commands in the flash prarmas table
for SST25* flash parts.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
drivers/mtd/spi/sf_params.c | 20 ++--
include/spi_flash.h | 3 ++-
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 453edf0..d5f3597 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -88,16 +88,16 @@ const struct spi_flash_params spi_flash_params_table[] = {
{N25Q1024A, 0x20bb21, 0x0, 64 * 1024, 2048, RD_FULL,
WR_QPP | E_FSR | SECT_4K},
#endif
#ifdef CONFIG_SPI_FLASH_SST/* SST */
- {SST25VF040B,0xbf258d, 0x0, 64 * 1024, 8, 0,
SECT_4K | SST_WP},
- {SST25VF080B,0xbf258e, 0x0, 64 * 1024,16, 0,
SECT_4K | SST_WP},
- {SST25VF016B,0xbf2541, 0x0, 64 * 1024,32, 0,
SECT_4K | SST_WP},
- {SST25VF032B,0xbf254a, 0x0, 64 * 1024,64, 0,
SECT_4K | SST_WP},
- {SST25VF064C,0xbf254b, 0x0, 64 * 1024, 128, 0,
SECT_4K},
- {SST25WF512, 0xbf2501, 0x0, 64 * 1024, 1, 0,
SECT_4K | SST_WP},
- {SST25WF010, 0xbf2502, 0x0, 64 * 1024, 2, 0,
SECT_4K | SST_WP},
- {SST25WF020, 0xbf2503, 0x0, 64 * 1024, 4, 0,
SECT_4K | SST_WP},
- {SST25WF040, 0xbf2504, 0x0, 64 * 1024, 8, 0,
SECT_4K | SST_WP},
- {SST25WF080, 0xbf2505, 0x0, 64 * 1024,16, 0,
SECT_4K | SST_WP},
+ {SST25VF040B,0xbf258d, 0x0, 64 * 1024, 8, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25VF080B,0xbf258e, 0x0, 64 * 1024,16, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25VF016B,0xbf2541, 0x0, 64 * 1024,32, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25VF032B,0xbf254a, 0x0, 64 * 1024,64, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25VF064C,0xbf254b, 0x0, 64 * 1024, 128, RD_EXTN,
SECT_4K},
+ {SST25WF512, 0xbf2501, 0x0, 64 * 1024, 1, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25WF010, 0xbf2502, 0x0, 64 * 1024, 2, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25WF020, 0xbf2503, 0x0, 64 * 1024, 4, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25WF040, 0xbf2504, 0x0, 64 * 1024, 8, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25WF080, 0xbf2505, 0x0, 64 * 1024,16, RD_SLOW,
SECT_4K | SST_WP},
#endif
#ifdef CONFIG_SPI_FLASH_WINBOND/* WINBOND */
{W25P80, 0xef2014, 0x0, 64 * 1024,16, 0,
0},
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 408a5b4..a75e030 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -46,7 +46,8 @@ enum spi_read_cmds {
QUAD_OUTPUT_FAST = 1 3,
QUAD_IO_FAST = 1 4,
};
-#define RD_EXTNARRAY_SLOW | DUAL_OUTPUT_FAST | DUAL_IO_FAST
+#define RD_SLOWARRAY_SLOW
+#define RD_EXTNRD_SLOW | DUAL_OUTPUT_FAST | DUAL_IO_FAST
#define RD_FULLRD_EXTN | QUAD_OUTPUT_FAST | QUAD_IO_FAST
/* Dual SPI flash memories */
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] sf: Update SST25* flash params of sector size numbers
Change SST25* flash sector size to 4KiB to match SECT_4K. This makes
'sf erase offset +len' work on real 4KiB boundary instead of 64KiB.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
drivers/mtd/spi/sf_params.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index d5f3597..dd3baa4 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -88,16 +88,16 @@ const struct spi_flash_params spi_flash_params_table[] = {
{N25Q1024A, 0x20bb21, 0x0, 64 * 1024, 2048, RD_FULL,
WR_QPP | E_FSR | SECT_4K},
#endif
#ifdef CONFIG_SPI_FLASH_SST/* SST */
- {SST25VF040B,0xbf258d, 0x0, 64 * 1024, 8, RD_SLOW,
SECT_4K | SST_WP},
- {SST25VF080B,0xbf258e, 0x0, 64 * 1024,16, RD_SLOW,
SECT_4K | SST_WP},
- {SST25VF016B,0xbf2541, 0x0, 64 * 1024,32, RD_SLOW,
SECT_4K | SST_WP},
- {SST25VF032B,0xbf254a, 0x0, 64 * 1024,64, RD_SLOW,
SECT_4K | SST_WP},
- {SST25VF064C,0xbf254b, 0x0, 64 * 1024, 128, RD_EXTN,
SECT_4K},
- {SST25WF512, 0xbf2501, 0x0, 64 * 1024, 1, RD_SLOW,
SECT_4K | SST_WP},
- {SST25WF010, 0xbf2502, 0x0, 64 * 1024, 2, RD_SLOW,
SECT_4K | SST_WP},
- {SST25WF020, 0xbf2503, 0x0, 64 * 1024, 4, RD_SLOW,
SECT_4K | SST_WP},
- {SST25WF040, 0xbf2504, 0x0, 64 * 1024, 8, RD_SLOW,
SECT_4K | SST_WP},
- {SST25WF080, 0xbf2505, 0x0, 64 * 1024,16, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25VF040B,0xbf258d, 0x0,4 * 1024, 128, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25VF080B,0xbf258e, 0x0,4 * 1024, 256, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25VF016B,0xbf2541, 0x0,4 * 1024, 512, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25VF032B,0xbf254a, 0x0,4 * 1024, 1024, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25VF064C,0xbf254b, 0x0,4 * 1024, 2048, RD_EXTN,
SECT_4K},
+ {SST25WF512, 0xbf2501, 0x0,4 * 1024,16, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25WF010, 0xbf2502, 0x0,4 * 1024,32, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25WF020, 0xbf2503, 0x0,4 * 1024,64, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25WF040, 0xbf2504, 0x0,4 * 1024, 128, RD_SLOW,
SECT_4K | SST_WP},
+ {SST25WF080, 0xbf2505, 0x0,4 * 1024, 256, RD_SLOW,
SECT_4K | SST_WP},
#endif
#ifdef CONFIG_SPI_FLASH_WINBOND/* WINBOND */
{W25P80, 0xef2014, 0x0, 64 * 1024,16, 0,
0},
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ 0/2] tqma6: trivial fixes
From: Markus Niebel markus.nie...@tq-group.com two trivial fixes for the TQ Systems TQMa6 modules. Thanks to Anatolij Gustschin to bring the first to my attention Markus Niebel (2): tqma6: fix sf detection tqma6: fix typo in header guard define board/tqc/tqma6/tqma6.c| 10 +- board/tqc/tqma6/tqma6_bb.h | 2 +- include/configs/tqma6.h| 19 --- 3 files changed, 26 insertions(+), 5 deletions(-) -- 2.1.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ 2/2] tqma6: fix typo in header guard define
From: Markus Niebel markus.nie...@tq-group.com Signed-off-by: Markus Niebel markus.nie...@tq-group.com --- board/tqc/tqma6/tqma6_bb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/tqc/tqma6/tqma6_bb.h b/board/tqc/tqma6/tqma6_bb.h index 9d072d2..fb7b462 100644 --- a/board/tqc/tqma6/tqma6_bb.h +++ b/board/tqc/tqma6/tqma6_bb.h @@ -6,7 +6,7 @@ */ #ifndef __TQMA6_BB__ -#define __TQMA6_BB +#define __TQMA6_BB__ #include common.h -- 2.1.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ 1/2] tqma6: fix sf detection
From: Markus Niebel markus.nie...@tq-group.com
Commit 155fa9af95ac5be857a7327e7a968a296e60d4c8 changed the way
to define a GPIO line, which can be used to force CS high
across multiple transactions. In order to fix sf detection
change board code to make use of board_spi_cs_gpio(..).
Signed-off-by: Markus Niebel markus.nie...@tq-group.com
---
board/tqc/tqma6/tqma6.c | 10 +-
include/configs/tqma6.h | 19 ---
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c
index b552bb8..fd1bd59 100644
--- a/board/tqc/tqma6/tqma6.c
+++ b/board/tqc/tqma6/tqma6.c
@@ -138,8 +138,10 @@ static iomux_v3_cfg_t const tqma6_ecspi1_pads[] = {
NEW_PAD_CTRL(MX6_PAD_EIM_D18__ECSPI1_MOSI, SPI_PAD_CTRL),
};
+#define TQMA6_SF_CS_GPIO IMX_GPIO_NR(3, 19)
+
static unsigned const tqma6_ecspi1_cs[] = {
- IMX_GPIO_NR(3, 19),
+ TQMA6_SF_CS_GPIO,
};
static void tqma6_iomuxc_spi(void)
@@ -152,6 +154,12 @@ static void tqma6_iomuxc_spi(void)
ARRAY_SIZE(tqma6_ecspi1_pads));
}
+int board_spi_cs_gpio(unsigned bus, unsigned cs)
+{
+ return ((bus == CONFIG_SF_DEFAULT_BUS)
+ (cs == CONFIG_SF_DEFAULT_CS)) ? TQMA6_SF_CS_GPIO : -1;
+}
+
static struct i2c_pads_info tqma6_i2c3_pads = {
/* I2C3: on board LM75, M24C64, */
.scl = {
diff --git a/include/configs/tqma6.h b/include/configs/tqma6.h
index 2705d2c..9ba0155 100644
--- a/include/configs/tqma6.h
+++ b/include/configs/tqma6.h
@@ -9,13 +9,26 @@
#ifndef __CONFIG_H
#define __CONFIG_H
+#define CONFIG_MX6
+
+/* SPL */
+/* #if defined(CONFIG_SPL_BUILD) */
+
+#define CONFIG_SPL_MMC_SUPPORT
+#define CONFIG_SPL_SPI_SUPPORT
+#define CONFIG_SPL_FAT_SUPPORT
+#define CONFIG_SPL_EXT_SUPPORT
+
+/* common IMX6 SPL configuration */
+#include imx6_spl.h
+
+/* #endif */
+
#include mx6_common.h
#include asm/arch/imx-regs.h
#include asm/imx-common/gpio.h
#include linux/sizes.h
-#define CONFIG_MX6
-
#if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
#define PHYS_SDRAM_SIZE(512u * SZ_1M)
#elif defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
@@ -57,7 +70,7 @@
#define CONFIG_CMD_SF
#define CONFIG_SF_DEFAULT_BUS 0
-#define CONFIG_SF_DEFAULT_CS (0 | (IMX_GPIO_NR(3, 19) 8))
+#define CONFIG_SF_DEFAULT_CS 0
#define CONFIG_SF_DEFAULT_SPEED5000
#define CONFIG_SF_DEFAULT_MODE (SPI_MODE_0)
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2014.10 released
Dear Tom, In message 20141014084744.GH25506@bill-the-cat you wrote: I've pushed v2014.10 out to the repository and tarballs should exist soon. Sorry, I nearly forgot about the release statistics (thanks to Fabio for the reminder!); here it comes: Changes since v2014.07: Processed csets from 145 developers 23 employers found A total of 146820 lines added, 58801 removed (delta 88019) Developers with the most changesets Masahiro Yamada149 (13.4%) Simon Glass147 (13.2%) Marek Vasut 59 (5.3%) Hans de Goede 43 (3.9%) Jeroen Hofstee 41 (3.7%) Fabio Estevam 36 (3.2%) Eric Nelson 28 (2.5%) Pavel Machek27 (2.4%) Tom Rini23 (2.1%) Stephen Warren 23 (2.1%) ... Developers with the most changed lines Masahiro Yamada 60281 (32.2%) Heiko Schocher29800 (15.9%) Simon Glass8008 (4.3%) Nobuhiro Iwamatsu 4405 (2.4%) Wang Huan 4171 (2.2%) Fabio Estevam 3098 (1.7%) Steve Rae 3065 (1.6%) Daniel Schwierzeck 2710 (1.4%) Marek Vasut2313 (1.2%) Thomas Chou2207 (1.2%) ... Developers with the most lines removed Thomas Chou 1898 (3.2%) Lijun Pan 924 (1.6%) Stefan Roese 170 (0.3%) Andrew Ruder 161 (0.3%) Enric Balletbo i Serra 135 (0.2%) Matwey V. Kornilov 132 (0.2%) Sonic Zhang127 (0.2%) Sergey Kostanbaev 57 (0.1%) Claudiu Manoil 14 (0.0%) Michal Simek14 (0.0%) ... Developers with the most signoffs (total 237) Minkyu Kang 41 (17.3%) Hans de Goede 30 (12.7%) Marek Vasut 18 (7.6%) Khoronzhuk, Ivan14 (5.9%) Andreas Bießmann13 (5.5%) Alison Wang 11 (4.6%) Stefan Roese 8 (3.4%) Henrik Nordstrom 7 (3.0%) Prafulla Wadaskar6 (2.5%) Tom Rini 6 (2.5%) ... Developers with the most reviews (total 103) York Sun 43 (41.7%) Jagannadha Sutradharudu Teki 19 (18.4%) Marek Vasut 8 (7.8%) Stephen Warren6 (5.8%) Tom Rini 5 (4.9%) Masahiro Yamada 5 (4.9%) Simon Glass 4 (3.9%) Andreas Bießmann 3 (2.9%) Stefan Roese 3 (2.9%) Eric Nelson 2 (1.9%) ... Developers with the most test credits (total 49) Simon Glass 12 (24.5%) Ajay Kumar 6 (12.2%) Masahiro Yamada 5 (10.2%) Luka Perkov 5 (10.2%) Stephen Warren 4 (8.2%) Michal Simek 3 (6.1%) Tom Rini 2 (4.1%) Karsten Merker 2 (4.1%) Fabio Estevam1 (2.0%) Igor Grinberg1 (2.0%) ... Developers who gave the most tested-by credits (total 49) Masahiro Yamada 9 (18.4%) Simon Glass 7 (14.3%) Stefan Roese 7 (14.3%) Ajay Kumar 5 (10.2%) Hans de Goede4 (8.2%) Michal Simek 2 (4.1%) Thierry Reding 2 (4.1%) Bryan Wu 2 (4.1%) Tom Rini 1 (2.0%) Chin Liang See 1 (2.0%) ... Developers with the most report credits (total 21) Tom Rini 3 (14.3%) York Sun 3 (14.3%) Masahiro Yamada 2 (9.5%) Karsten Merker 2 (9.5%) Jeroen Hofstee 2 (9.5%) Steve Rae2 (9.5%) Jonas Karlsson 2 (9.5%) Stephen Warren 1 (4.8%) Otavio Salvador 1 (4.8%) Dirk Zimoch 1 (4.8%) ... Developers who gave the most report credits (total 21) Simon Glass 9 (42.9%) Tom Rini 2 (9.5%) Hans de Goede2 (9.5%) Fabio Estevam2 (9.5%) Thierry Reding 1 (4.8%) Bryan Wu 1 (4.8%) Benoît Thébaudeau1 (4.8%) Ian Campbell 1 (4.8%) Christian Riesch 1 (4.8%) Gerhard Sittig 1 (4.8%) Top changeset contributors by employer (Unknown) 224 (20.2%) Panasonic 149 (13.4%) Google, Inc. 149 (13.4%) Freescale 127 (11.4%) DENX Software Engineering 125 (11.3%) Texas Instruments 73 (6.6%) Red Hat 43 (3.9%) Samsung 38 (3.4%) Boundary Devices33 (3.0%) NVidia 28 (2.5%) ... Top lines changed by employer Panasonic 92757 (49.5%) DENX Software Engineering 33961 (18.1%) (Unknown) 15919 (8.5%) Freescale 11719 (6.3%) Google, Inc. 8704 (4.6%) Broadcom
Re: [U-Boot] Relocation issue - need help!
Hello Wolfgang, 2014-10-23 15:10 GMT+02:00 Wolfgang Denk w...@denx.de: Given that GCC 4.9.1 apparently solves this issue I wonder which approach we should take? Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are doing [1] ? [1] https://lkml.org/lkml/2014/10/10/272 question is: what are the gcc folks going to do with the relro stuff? It seems the sections are not used in 4.9.1, but will this be true for future releases? If we are not absolutely sure they will not be used anymore, adding them to the linker scripts is probably the best option. Anybody with deeper gcc insights following this thread? Cheers Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM SoC trees
Hey all, One of the things that I mentioned at the U-Boot mini-summit was that I had talked with Albert and he's OK with patches that aren't ARM core changes but just SoC centric changes not going into u-boot-arm first. So in that vein, I'm going to start with treating the ARM SoC trees like I do all of the PowerPC SoC trees. That means make your PR be based on master, and send it to me. But please make sure that if your changes aren't self-contained to your SoC families and do touch core things that you have an Ack/Reviewed from Albert, baring truly trivial changes of course. Thanks all! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
On Wed, Oct 22, 2014 at 09:55:47PM -0600, Simon Glass wrote: Hi Tom, These are the last of the x86 patches before it is converted to driver model. The following changes since commit 35d4fed320d577a4446531d7b9350ce40065c4b0: x86: Fix GDT limit in start16.S (2014-10-22 09:03:07 -0600) are available in the git repository at: git://git.denx.de/u-boot-x86.git for you to fetch changes up to 8104f546296a8e1fc1dd6129041e22f508b314f9: net: Display the size when tftpboot finishes (2014-10-22 21:50:33 -0600) Simon Glass (10): x86: config: Enable dhcp on link x86: Add device tree information for Chrome OS EC x86: dts: Add device tree compatible string for Intel IPC x86: cros_ec: Update LPC driver for new cros_ec header x86: cros_ec: Enable cros_ec for link doc: Remove note about auto-complete not working with hush x86: link: Tidy up the command lines options x86: config: link: Display the board model on the screen x86: Enable FIT, ELF on coreboot net: Display the size when tftpboot finishes README | 4 arch/x86/dts/link.dts| 18 ++ board/chromebook-x86/coreboot/Makefile | 2 +- board/chromebook-x86/coreboot/coreboot.c | 16 drivers/misc/cros_ec_lpc.c | 4 ++-- include/configs/coreboot.h | 22 ++ include/fdtdec.h | 1 + lib/fdtdec.c | 1 + net/tftp.c | 2 ++ 9 files changed, 59 insertions(+), 11 deletions(-) create mode 100644 board/chromebook-x86/coreboot/coreboot.c Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-fdt.git
On Wed, Oct 22, 2014 at 09:07:30PM -0600, Simon Glass wrote: Hi Tom, These patches are part of a larger series, but I have already ACKed them and they are independent of that series, so let's bring them in. The following changes since commit a84c8107d9b050fe8a31220d28588abfc2d99aee: Merge branch 'master' of git://git.denx.de/u-boot-fsl-qoriq (2014-10-20 18:17:26 -0400) are available in the git repository at: git://git.denx.de/u-boot-fdt.git for you to fetch changes up to 2f3760428ff3c4d5d1a087d016da5943921f0980: fdt: Add a subnodes iterator macro (2014-10-22 16:56:41 -0600) Thierry Reding (6): fdt: Add a function to count strings fdt: Add a function to get the index of a string fdt: Add functions to retrieve strings fdt: Add resource parsing functions fdt: Add a function to return PCI BDF triplet fdt: Add a subnodes iterator macro include/fdtdec.h| 63 +++ include/libfdt.h| 72 lib/fdtdec.c| 71 +++ lib/libfdt/fdt_ro.c | 76 4 files changed, 282 insertions(+) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] SPI: mxc_spi: remove second reset from ECSPI config handler
From: Markus Niebel markus.nie...@tq-group.com the second reset prevents other registers to be written. This will prevent to have the correct signal levels for SCLK before writing to the config reg in spi_xchg_single. Tested with GPIO based chipselect and SPI_MODE_3 on i.MX6S Signed-off-by: Markus Niebel markus.nie...@tq-group.com --- Changes since v1: - rebase to current master drivers/spi/mxc_spi.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c index 026f680..555b34f 100644 --- a/drivers/spi/mxc_spi.c +++ b/drivers/spi/mxc_spi.c @@ -168,9 +168,6 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned int cs, reg_ctrl = (reg_ctrl ~MXC_CSPICTRL_POSTDIV(0x0F)) | MXC_CSPICTRL_POSTDIV(post_div); - /* We need to disable SPI before changing registers */ - reg_ctrl = ~MXC_CSPICTRL_EN; - if (mode SPI_CS_HIGH) ss_pol = 1; -- 2.1.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] SPI: mxc_spi: slave initialisation fixes
From: Markus Niebel markus.nie...@tq-group.com current implementation of the mxc_spi host driver gives issues, if using more than one slave on the same bus. These patches try to improve this use case. They were tested on a TQMa6S (i.MX6S) with a custom mainboard using two slave devices in SPI MODE 0 and 3, on of the devices uses gpio based chip select the other hardware base chip select. Markus Niebel (2): SPI: mxc_spi: remove second reset from ECSPI config handler SPI: mxc_spi: delay initialisation until claim bus drivers/spi/mxc_spi.c | 40 +--- 1 file changed, 21 insertions(+), 19 deletions(-) -- Changes since v1: - fix typo 2.1.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] SPI: mxc_spi: delay initialisation until claim bus
From: Markus Niebel markus.nie...@tq-group.com
it is not correct to init for a specific slave in spi_setup_slave.
instead buffer the values and delay init until spi_claim_bus.
Signed-off-by: Markus Niebel markus.nie...@tq-group.com
---
Changes since v1:
- rebase to current master
drivers/spi/mxc_spi.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 555b34f..e04a30f 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -48,6 +48,8 @@ struct mxc_spi_slave {
#endif
int gpio;
int ss_pol;
+ unsigned intmax_hz;
+ unsigned intmode;
};
static inline struct mxc_spi_slave *to_mxc_spi_slave(struct spi_slave *slave)
@@ -82,12 +84,13 @@ u32 get_cspi_div(u32 div)
}
#ifdef MXC_CSPI
-static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned int cs,
- unsigned int max_hz, unsigned int mode)
+static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned int cs)
{
unsigned int ctrl_reg;
u32 clk_src;
u32 div;
+ unsigned int max_hz = mxcs-max_hz;
+ unsigned int mode = mxcs-mode;
clk_src = mxc_get_clock(MXC_CSPI_CLK);
@@ -119,19 +122,15 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs,
unsigned int cs,
#endif
#ifdef MXC_ECSPI
-static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned int cs,
- unsigned int max_hz, unsigned int mode)
+static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned int cs)
{
u32 clk_src = mxc_get_clock(MXC_CSPI_CLK);
s32 reg_ctrl, reg_config;
u32 ss_pol = 0, sclkpol = 0, sclkpha = 0, sclkctl = 0;
u32 pre_div = 0, post_div = 0;
struct cspi_regs *regs = (struct cspi_regs *)mxcs-base;
-
- if (max_hz == 0) {
- printf(Error: desired clock is 0\n);
- return -1;
- }
+ unsigned int max_hz = mxcs-max_hz;
+ unsigned int mode = mxcs-mode;
/*
* Reset SPI and set all CSs to master mode, if toggling
@@ -408,6 +407,11 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
if (bus = ARRAY_SIZE(spi_bases))
return NULL;
+ if (max_hz == 0) {
+ printf(Error: desired clock is 0\n);
+ return NULL;
+ }
+
mxcs = spi_alloc_slave(struct mxc_spi_slave, bus, cs);
if (!mxcs) {
puts(mxc_spi: SPI Slave not allocated !\n);
@@ -423,13 +427,9 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
}
mxcs-base = spi_bases[bus];
+ mxcs-max_hz = max_hz;
+ mxcs-mode = mode;
- ret = spi_cfg_mxc(mxcs, cs, max_hz, mode);
- if (ret) {
- printf(mxc_spi: cannot setup SPI controller\n);
- free(mxcs);
- return NULL;
- }
return mxcs-slave;
}
@@ -442,12 +442,17 @@ void spi_free_slave(struct spi_slave *slave)
int spi_claim_bus(struct spi_slave *slave)
{
+ int ret;
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
struct cspi_regs *regs = (struct cspi_regs *)mxcs-base;
reg_write(regs-rxdata, 1);
udelay(1);
- reg_write(regs-ctrl, mxcs-ctrl_reg);
+ ret = spi_cfg_mxc(mxcs, slave-cs);
+ if (ret) {
+ printf(mxc_spi: cannot setup SPI controller\n);
+ return ret;
+ }
reg_write(regs-period, MXC_CSPIPERIOD_32KHZ);
reg_write(regs-intr, 0);
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert common, env: Fix support for environment in i2c eeprom
Hi Valentin, On 10/14/2014 04:21 PM, Valentin Longchamp wrote: Hi Matthias, On 10/14/2014 02:32 PM, Matthias Fuchs wrote: Hi Valentin, my patch fixed environment from i2c eeprom. I am not sure on which board I ran into that trouble. Probably PMC440. So reverting my former patch will break environment in i2c eeprom again on many boards. Good that you have answered to patch. I run into that trouble on our Keymile boards that have the environment in the EEPROM. On our boards, the environment eeprom works with or without your patch. However, with your patch, I cannot directly access ANY eeprom which is not on the CONFIG_I2C_ENV_EEPROM_BUS bus. But perhaps there's a better way to fix that. I think that the proposal that Holger made to actually define CONFIG_I2C_ENV_EEPROM_BUS for your boards is what I would try first. I reverted my former patch and switchedd towards CONFIG_I2C_ENV_EEPROM_BUS. This works fine for me. So I ack your patch to revert mine :-) Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] spi: altera: Use struct-based register access
On Wed 2014-10-22 21:55:58, Marek Vasut wrote: Zap the offset-based register access and use the struct-based one as this is the preferred method. No functional change, but there are some line-over-80 problems in the driver, which will be addressed later. For 1-7: Acked-by: Pavel Machek pa...@denx.de Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] openrd: Undefine CONFIG_CMD_NFS
In order to fit within the current binary size limits, drop the 'nfs' command support. Cc: Prafulla Wadaskar prafu...@marvell.com Signed-off-by: Tom Rini tr...@ti.com --- include/configs/openrd.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/openrd.h b/include/configs/openrd.h index b6f80af..7d666b0 100644 --- a/include/configs/openrd.h +++ b/include/configs/openrd.h @@ -45,6 +45,7 @@ #define CONFIG_SYS_NO_FLASH/* Declare no flash (NOR/SPI) */ #define CONFIG_SYS_MVFS #include config_cmd_default.h +#undef CONFIG_CMD_NFS #define CONFIG_CMD_DHCP #define CONFIG_CMD_ENV #define CONFIG_CMD_MII -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please increase the image size for km boards
Hi York, On 10/01/2014 05:41 PM, York Sun wrote: On 10/01/2014 08:39 AM, Valentin Longchamp wrote: Hi York, On 09/30/2014 05:48 PM, York Sun wrote: Valentin, We are seeing the image size of kmcoge4 and kmlion1 are on the edge. Attempts to add new features cause overflow. Would you consider to increase the image size for km boards. You may have noticed several patches doing this for selected boards (search git log for 768K). I am going to have a look at it and see what the impact is for us. Basically I have nothing against changing this value, especially for kmcoge4/kmlion1. Thanks. I can anticipate some chaos on the flash memory map. The environmental variables are stored before u-boot in flash, if FMan ucode if the SoC requires it. I have finally had time to look at this point. For kmcoge4, we are lucky to have enough space on our boot SPI Flash and I had reserved 1M for u-boot when doing the layout to have some reserve. So in my case I am avoiding the possible flash memory map chaos. If I have understood correctly, for the powerpc boards, the default value was changed from 512K to 768K. What do you think makes more sense, stay on line with the other powerpc boards with 768K or go directly to 1M since this space is avaible ? I prefer to stay on line. Another question: am I right that the two things that need to be adjusted are: - CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MONITOR_LEN or am I missing something ? Thank you very much Valentin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 03/20] arm: marvell: Move arch-kirkwood/spi.h to arch-mvebu/spi.h
On Wed, Oct 22, 2014 at 12:13:07PM +0200, Stefan Roese wrote: This move makes it possible to use this kirkwood SPI driver from other MVEBU platforms as well. This will be used by the upcoming Armada XP support. Signed-off-by: Stefan Roese s...@denx.de Reviewed-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com Tested-by: Luka Perkov l...@openwrt.org Acked-by: Prafulla Wadaskar prafu...@marvell.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 02/20] arm: marvell: Move arch/kirkwood.h to arch/soc.h
On Wed, Oct 22, 2014 at 12:13:06PM +0200, Stefan Roese wrote: This move makes is possible to use this header not only from kirkwood platforms but from all Marvell mvebu platforms. Signed-off-by: Stefan Roese s...@denx.de Tested-by: Luka Perkov l...@openwrt.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 01/20] arm: kirkwood: Move some SoC files into new arch/arm/mvebu-common
On Wed, Oct 22, 2014 at 12:13:05PM +0200, Stefan Roese wrote: By moving some kirkwood files into a Marvell common directory, those files can be used by other Marvell platforms as well. The name mvebu is taken from the Linux kernel source tree. It has been chosen there to represent the SoC's from the Marvell EBU (Engineering Business Unit). Those SoC's currently are: Armada 370/375/XP, Dove, mv78xx0, Kirkwood, Orion5x This will be used by the upcoming Armada XP (MV78460) platform support. Signed-off-by: Stefan Roese s...@denx.de Tested-by: Luka Perkov l...@openwrt.org Acked-by: Prafulla Wadaskar prafu...@marvell.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 05/20] arm: mvebu: Add common mbus functions to use on Marvell SoCs
On Wed, Oct 22, 2014 at 12:13:09PM +0200, Stefan Roese wrote: These mbus functions are ported from Barebox. The Barebox version is ported from Linux. These functions will be first used by the upcoming Armada XP support. Later other Marvell SoC's will be adopted to use these functions as well (Kirkwood, Orion). Signed-off-by: Stefan Roese s...@denx.de Tested-by: Luka Perkov l...@openwrt.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 04/20] arm: marvell: Rework timer.c to make it usable for other MVEBU platforms
On Wed, Oct 22, 2014 at 12:13:08PM +0200, Stefan Roese wrote: This patch does the following: - Rename defines and registers to not use kirkwood - Remove unused defines - Use clrsetbits() accessor functions - Coding style cleanup - Clear 25MHZ bit in timer controller register init for Armada XP There is no functional change for kirkwood. At least not intentionally. This will be used by the upcoming Armada XP support. Signed-off-by: Stefan Roese s...@denx.de Tested-by: Luka Perkov l...@openwrt.org Acked-by: Prafulla Wadaskar prafu...@marvell.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 07/20] arm: marvell: Extract kirkwood gpio functions into new common file gpio.c
On Wed, Oct 22, 2014 at 12:13:11PM +0200, Stefan Roese wrote: This makes is possible to use those gpio functions from other MVEBU SoC's as well. Signed-off-by: Stefan Roese s...@denx.de Tested-by: Luka Perkov l...@openwrt.org Acked-by: Prafulla Wadaskar prafu...@marvell.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 06/20] spi: kirkwood_spi.c: Compile MPP (pin-mux) only for kirkwood SoC's
On Wed, Oct 22, 2014 at 12:13:10PM +0200, Stefan Roese wrote: Compile the pin multiplexing only on Kirkwood platforms. As the Armada XP doesn't need it. Signed-off-by: Stefan Roese s...@denx.de Reviewed-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com Tested-by: Luka Perkov l...@openwrt.org Acked-by: Prafulla Wadaskar prafu...@marvell.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 08/20] spi: kirkwood_spi.c: Change KW_SPI_BASE to MVEBU_SPI_BASE
On Wed, Oct 22, 2014 at 12:13:12PM +0200, Stefan Roese wrote: This makes is possible to use this SPI driver from other MVEBU SoC's as well. As the upcoming Armada XP support will do. Signed-off-by: Stefan Roese s...@denx.de Reviewed-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com Tested-by: Luka Perkov l...@openwrt.org Acked-by: Prafulla Wadaskar prafu...@marvell.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 10/20] net: mvneta.c: Add support for the ethernet controller of the Marvell Armada XP SoC
On Wed, Oct 22, 2014 at 12:13:14PM +0200, Stefan Roese wrote: This patch adds support for the NETA ethernet controller which is integrated in the Marvell Armada XP SoC's. This port is based on the Linux driver which has been stripped of the in U-Boot unused portions. Tested on the Marvell MV78460 eval board db-78460-bp. Signed-off-by: Stefan Roese s...@denx.de Cc: Joe Hershberger joe.hershber...@gmail.com Tested-by: Luka Perkov l...@openwrt.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 09/20] arm: kirkwood: Change naming of dram functions from km_foo() to mvebu_foo()
On Wed, Oct 22, 2014 at 12:13:13PM +0200, Stefan Roese wrote: Additionally the SDRAM address decoding register address is not hard coded in the C code any more. A define is introduced for this base address. This makes is possible to use those gpio functions from other MVEBU SoC's as well. Signed-off-by: Stefan Roese s...@denx.de Tested-by: Luka Perkov l...@openwrt.org Acked-by: Prafulla Wadaskar prafu...@marvell.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 11/20] net: phy.h: Make PHY autonegotiation timeout configurable
On Wed, Oct 22, 2014 at 12:13:15PM +0200, Stefan Roese wrote: The Marvell MV78460 eval board DB-78460-BP seems to need a longer PHY autonegotiation timeout than the standard 4 seconds. So lets make this timeout configurable. If not defined in the board config header the original 4000ms is used. Signed-off-by: Stefan Roese s...@denx.de Cc: Joe Hershberger joe.hershber...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 13/20] arm: armada-xp: Add basic support for Marvell Armada XP SoC
On Wed, Oct 22, 2014 at 12:13:17PM +0200, Stefan Roese wrote: This basic support for the Marvell Armada XP is base on the existing kirkwood support. Which has been generatized by moving some common files into common marvell locations. This is in preparation for the upcoming Armada XP MV78460 support. Signed-off-by: Stefan Roese s...@denx.de Tested-by: Luka Perkov l...@openwrt.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: db-mv784mp-gp/maxbcm Add placeholder bin_hdr file so that linking works
This file should contain the bin_hdr generated by the original Marvell U-Boot implementation. As this is currently not included in this U-Boot version, we have added this placeholder, so that the U-Boot image can be generated without errors. If you have a known to be working bin_hdr for your board, then you just need to replace this text file here with the binary header and recompile U-Boot. In a few weeks, mainline U-Boot will get support to generate the bin_hdr with the DDR training code itself. By implementing this code as SPL U-Boot. Then this file will not be needed any more and will get removed. Signed-off-by: Stefan Roese s...@denx.de --- board/Marvell/db-mv784mp-gp/binary.0 | 17 + board/maxbcm/binary.0| 17 + 2 files changed, 34 insertions(+) create mode 100644 board/Marvell/db-mv784mp-gp/binary.0 create mode 100644 board/maxbcm/binary.0 diff --git a/board/Marvell/db-mv784mp-gp/binary.0 b/board/Marvell/db-mv784mp-gp/binary.0 new file mode 100644 index 000..17bfad9 --- /dev/null +++ b/board/Marvell/db-mv784mp-gp/binary.0 @@ -0,0 +1,17 @@ + +WARNING: + +This file should contain the bin_hdr generated by the original Marvell +U-Boot implementation. As this is currently not included in this +U-Boot version, we have added this placeholder, so that the U-Boot +image can be generated without errors. + +If you have a known to be working bin_hdr for your board, then you +just need to replace this text file here with the binary header +and recompile U-Boot. + +In a few weeks, mainline U-Boot will get support to generate the +bin_hdr with the DDR training code itself. By implementing this code +as SPL U-Boot. Then this file will not be needed any more and will +get removed. + diff --git a/board/maxbcm/binary.0 b/board/maxbcm/binary.0 new file mode 100644 index 000..17bfad9 --- /dev/null +++ b/board/maxbcm/binary.0 @@ -0,0 +1,17 @@ + +WARNING: + +This file should contain the bin_hdr generated by the original Marvell +U-Boot implementation. As this is currently not included in this +U-Boot version, we have added this placeholder, so that the U-Boot +image can be generated without errors. + +If you have a known to be working bin_hdr for your board, then you +just need to replace this text file here with the binary header +and recompile U-Boot. + +In a few weeks, mainline U-Boot will get support to generate the +bin_hdr with the DDR training code itself. By implementing this code +as SPL U-Boot. Then this file will not be needed any more and will +get removed. + -- 2.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 15/20] arm: armada-xp: Add basic support for the maxBCM board
On Wed, Oct 22, 2014 at 12:13:19PM +0200, Stefan Roese wrote: The maxBCM board is equipped with the Marvell Armada-XP MV78460 SoC. It integrates an SPI NOR flash and an Marvell 88E6185 switch. Signed-off-by: Stefan Roese s...@denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 12/20] i2c: mvtwsi: Add support for Marvell Armada XP
On Wed, Oct 22, 2014 at 12:13:16PM +0200, Stefan Roese wrote: To support the Armada XP SoC, we just need to include the correct header. Signed-off-by: Stefan Roese s...@denx.de Acked-by: Heiko Schocher h...@denx.de Tested-by: Luka Perkov l...@openwrt.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 14/20] arm: armada-xp: Add basic support for the Marvell DB-MV784MP-GP board
On Wed, Oct 22, 2014 at 12:13:18PM +0200, Stefan Roese wrote: This patch adds basic support for the Marvell DB-MV784MP-GP evaulation board. This is the first board that uses the recently created Armada XP 78460 SoC support. Signed-off-by: Stefan Roese s...@denx.de Tested-by: Luka Perkov l...@openwrt.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 16/20] arm: kirkwood: Remove some dead code from cpu.c
On Wed, Oct 22, 2014 at 12:13:20PM +0200, Stefan Roese wrote: All those functions removed with this patch are not accessed at all. So lets remove them. Signed-off-by: Stefan Roese s...@denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 18/20] tools: Compile kwboot for Marvell Armada XP as those SoCs are now supported
On Wed, Oct 22, 2014 at 12:13:22PM +0200, Stefan Roese wrote: Signed-off-by: Stefan Roese s...@denx.de Tested-by: Luka Perkov l...@openwrt.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 17/20] tools/kwboot: Sync with latest barebox version to support Armada XP
On Wed, Oct 22, 2014 at 12:13:21PM +0200, Stefan Roese wrote: The barebox version of the kwboot tool has evolved a bit. To support Armada XP and Dove. Additionally a few minor fixes have been applied. So lets sync with the latest barebox version. Please note that the main difference between both versions now is, that the U-Boot version still supports the -p option, to dynamically patch an image for UART boot mode. I didn't test it now though. Signed-off-by: Stefan Roese s...@denx.de Tested-by: Luka Perkov l...@openwrt.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 19/20] tools: kwbimage: Add image version 1 support for Armada XP / 370
On Wed, Oct 22, 2014 at 12:13:23PM +0200, Stefan Roese wrote: This patch integrates the Barebox version of this kwbimage.c file into U-Boot. As this version supports the image version 1 type for the Armada XP / 370 SoCs. It was easier to integrate the existing and known to be working Barebox source than to update the current U-Boot version to support this v1 image header format. Now all Marvell MVEBU SoCs are supported: Image type 0: Kirkwood Dove Image type 1: Armada 370 Armada XP Please note that the current v1 support has this restuction (same as has Barebox version): Not implemented: support for the register headers and secure headers in v1 images Tested on Marvell DB-78460-BP eval board. Signed-off-by: Stefan Roese s...@denx.de Tested-by: Luka Perkov l...@openwrt.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 20/20] Makefile: Add CONFIG_BUILD_TARGET to automatically build an special image
On Wed, Oct 22, 2014 at 12:13:24PM +0200, Stefan Roese wrote: Add target to build it automatically upon make / MAKEALL. This can/should be set by board / cpu specific headers if a special U-Boot image is required for this SoC / board. E.g. used by Marvell Armada XP to automatically build the u-boot.kwb target. Signed-off-by: Stefan Roese s...@denx.de Cc: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert common, env: Fix support for environment in i2c eeprom
On Thu, Oct 23, 2014 at 04:15:24PM +0200, Matthias Fuchs wrote: Hi Valentin, On 10/14/2014 04:21 PM, Valentin Longchamp wrote: Hi Matthias, On 10/14/2014 02:32 PM, Matthias Fuchs wrote: Hi Valentin, my patch fixed environment from i2c eeprom. I am not sure on which board I ran into that trouble. Probably PMC440. So reverting my former patch will break environment in i2c eeprom again on many boards. Good that you have answered to patch. I run into that trouble on our Keymile boards that have the environment in the EEPROM. On our boards, the environment eeprom works with or without your patch. However, with your patch, I cannot directly access ANY eeprom which is not on the CONFIG_I2C_ENV_EEPROM_BUS bus. But perhaps there's a better way to fix that. I think that the proposal that Holger made to actually define CONFIG_I2C_ENV_EEPROM_BUS for your boards is what I would try first. I reverted my former patch and switchedd towards CONFIG_I2C_ENV_EEPROM_BUS. This works fine for me. So I ack your patch to revert mine :-) Can you reply with an Acked-by for patchwork to pick up? And then a patch to update your board to work right as well please. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please increase the image size for km boards
On 10/23/2014 08:02 AM, Valentin Longchamp wrote: Hi York, On 10/01/2014 05:41 PM, York Sun wrote: On 10/01/2014 08:39 AM, Valentin Longchamp wrote: Hi York, On 09/30/2014 05:48 PM, York Sun wrote: Valentin, We are seeing the image size of kmcoge4 and kmlion1 are on the edge. Attempts to add new features cause overflow. Would you consider to increase the image size for km boards. You may have noticed several patches doing this for selected boards (search git log for 768K). I am going to have a look at it and see what the impact is for us. Basically I have nothing against changing this value, especially for kmcoge4/kmlion1. Thanks. I can anticipate some chaos on the flash memory map. The environmental variables are stored before u-boot in flash, if FMan ucode if the SoC requires it. I have finally had time to look at this point. For kmcoge4, we are lucky to have enough space on our boot SPI Flash and I had reserved 1M for u-boot when doing the layout to have some reserve. So in my case I am avoiding the possible flash memory map chaos. If I have understood correctly, for the powerpc boards, the default value was changed from 512K to 768K. What do you think makes more sense, stay on line with the other powerpc boards with 768K or go directly to 1M since this space is avaible ? I prefer to stay on line. I agree. Another question: am I right that the two things that need to be adjusted are: - CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MONITOR_LEN or am I missing something ? You don't have other than NOR flash boot, do you? If yes, you need to take care of them, too. You can find some example by looking into git log, search for 768K. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert common, env: Fix support for environment in i2c eeprom
Hi Valentin, On 10/14/2014 04:21 PM, Valentin Longchamp wrote: Hi Matthias, On 10/14/2014 02:32 PM, Matthias Fuchs wrote: Hi Valentin, my patch fixed environment from i2c eeprom. I am not sure on which board I ran into that trouble. Probably PMC440. So reverting my former patch will break environment in i2c eeprom again on many boards. Good that you have answered to patch. I run into that trouble on our Keymile boards that have the environment in the EEPROM. On our boards, the environment eeprom works with or without your patch. However, with your patch, I cannot directly access ANY eeprom which is not on the CONFIG_I2C_ENV_EEPROM_BUS bus. But perhaps there's a better way to fix that. I think that the proposal that Holger made to actually define CONFIG_I2C_ENV_EEPROM_BUS for your boards is what I would try first. I reverted my former patch and switched towards CONFIG_I2C_ENV_EEPROM_BUS. This works fine for me. I will post a patch soon. So Acked-by: Matthias Fuchs matthias.fu...@esd.eu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Question of dm serial] Is pending handler optional?
Hi Simon,
I have questions of driver model serial.
The comment block in include/serial.h states .pending is optional
8---
* pending() - Check if input/output characters are waiting
*
* This can be used to return an indication of the number of waiting
* characters if the driver knows this (e.g. by looking at the FIFO
* level). It is acceptable to return 1 if an indeterminant number
* of characters is waiting.
*
* This method is optional.
8---
When I was testing my driver model conversion patch,
I noticed ctrlc() function would not work without .pending handler.
The function ctrlc() calls tstc()
and if it returns non-zero value, it also calls getc().
If .pending handler is not implemented,
tstc() function always return 1,
even if no input character is available in UART FIFO;
As a result, getc() function will get stuck in
do {
err = ops-getc(cur_dev);
} while (err == -EAGAIN);
loop.
For example, help command does not work.
So, .pending is mandatory, isn't it?
One more question.
The comment says .pending is:
Check if input/output characters are waiting
Should .pending check output buffer? or input only?
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: update PMC440 board support
- switch to GENERIC_BOARD - fix env support from eeprom Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu --- board/esd/pmc440/cmd_pmc440.c |6 +++--- include/configs/PMC440.h |3 +++ 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/board/esd/pmc440/cmd_pmc440.c b/board/esd/pmc440/cmd_pmc440.c index 3481e46..40b135f 100644 --- a/board/esd/pmc440/cmd_pmc440.c +++ b/board/esd/pmc440/cmd_pmc440.c @@ -347,16 +347,16 @@ int do_painit(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) return 1; } - base = gd-bd-bi_memsize; + base = (u32)gd-ram_size; #if defined(CONFIG_LOGBUFFER) base -= LOGBUFF_LEN + LOGBUFF_OVERHEAD; #endif /* -* gd-bd-bi_memsize == physical ram size - CONFIG_SYS_MEM_TOP_HIDE +* gd-ram_size == physical ram size - CONFIG_SYS_MEM_TOP_HIDE */ param = base - (pram 10); printf(PARAM: @%08x\n, param); - debug(memsize=0x%08x, base=0x%08x\n, (u32)gd-bd-bi_memsize, base); + debug(memsize=0x%08x, base=0x%08x\n, (u32)gd-ram_size, base); /* clear entire PA ram */ memset((void*)param, 0, (pram 10)); diff --git a/include/configs/PMC440.h b/include/configs/PMC440.h index c5e2f16..dc2c976 100644 --- a/include/configs/PMC440.h +++ b/include/configs/PMC440.h @@ -29,6 +29,8 @@ #define CONFIG_SYS_TEXT_BASE 0xFFF9 #endif +#define CONFIG_SYS_GENERIC_BOARD + #define CONFIG_SYS_CLK_FREQ3400 #if 0 /* temporary disabled because OS/9 does not like dcache on startup */ @@ -133,6 +135,7 @@ #endif #ifdef CONFIG_ENV_IS_IN_EEPROM +#define CONFIG_I2C_ENV_EEPROM_BUS 0 #define CONFIG_ENV_OFFSET 0 /* environment starts at the beginning of the EEPROM */ #define CONFIG_ENV_SIZE0x1000 /* 4096 bytes may be used for env vars */ #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: update PMC440 board support
Hi Matthias, On Thu, 23 Oct 2014 17:50:23 +0200 Matthias Fuchs matthias.fu...@esd.eu wrote: ... diff --git a/include/configs/PMC440.h b/include/configs/PMC440.h index c5e2f16..dc2c976 100644 --- a/include/configs/PMC440.h +++ b/include/configs/PMC440.h @@ -29,6 +29,8 @@ #define CONFIG_SYS_TEXT_BASE 0xFFF9 #endif +#define CONFIG_SYS_GENERIC_BOARD you also need #define CONFIG_DISPLAY_BOARDINFO Otherwise the checkboard() won't get called and the board revision detection will be skipped. This will affect reset_phy() later. Please check. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/7] kconfig: Move CONFIG_SYS_HZ and CONFIG_USE_PRIVATE_LIBGCC, bug fixes
Masahiro Yamada (7): kconfig: move CONFIG_SYS_HZ to lib/Kconfig x86: set CONFIG_USE_PRIVATE_LIBGCC to y kbuild: drop CONFIG_USE_PRIVATE_LIBGCC=path/to/libgcc syntax kconfig: move CONFIG_USE_PRIVATE_LIBGCC to Kconfig kbuild: fix a bug of the u-boot-spl link rule kconfig: invoke silentoldconfig if spl,tpl/.config is updated mips: enable CONFIG_USE_PRIVATE_LIBGCC by default Makefile| 4 README | 7 --- arch/Kconfig| 5 + arch/arm/cpu/armv7/tegra-common/Kconfig | 3 +++ arch/mips/Kconfig | 3 +++ arch/x86/Kconfig| 3 +++ arch/x86/config.mk | 3 --- arch/x86/lib/Makefile | 6 +++--- include/config_fallbacks.h | 4 include/configs/cm_fx6.h| 1 - include/configs/edb93xx.h | 1 - include/configs/ks2_evm.h | 1 - include/configs/ls1021aqds.h| 1 - include/configs/ls1021atwr.h| 1 - include/configs/ls2085a_common.h| 2 -- include/configs/sunxi-common.h | 2 -- include/configs/tegra-common.h | 4 include/configs/tqma6.h | 1 - lib/Kconfig | 19 +++ lib/time.c | 4 scripts/Makefile.spl| 8 scripts/multiconfig.sh | 15 +++ 22 files changed, 55 insertions(+), 43 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/7] kconfig: move CONFIG_SYS_HZ to lib/Kconfig
CONFIG_SYS_HZ is always defined as 1000 in config_fallbacks.h (but some boards still have redundant definitions). This commit moves the definition and the document in README to Kconfig. Since lib/Kconfig can assure that CONFIG_SYS_HZ is 1000, the sanity check in lib/time.c should be removed. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Reviewed-by: Marek Vasut ma...@denx.de --- Changes in v2: None README | 7 --- include/config_fallbacks.h | 4 include/configs/cm_fx6.h | 1 - include/configs/edb93xx.h| 1 - include/configs/ks2_evm.h| 1 - include/configs/ls1021aqds.h | 1 - include/configs/ls1021atwr.h | 1 - include/configs/ls2085a_common.h | 2 -- include/configs/sunxi-common.h | 2 -- include/configs/tqma6.h | 1 - lib/Kconfig | 8 lib/time.c | 4 12 files changed, 8 insertions(+), 25 deletions(-) diff --git a/README b/README index 19abe20..f5bc2c2 100644 --- a/README +++ b/README @@ -623,13 +623,6 @@ The following options need to be configured: exists, unlike the similar options in the Linux kernel. Do not set these options unless they apply! -- CPU timer options: - CONFIG_SYS_HZ - - The frequency of the timer returned by get_timer(). - get_timer() must operate in milliseconds and this CONFIG - option must be set to 1000. - - Linux Kernel Interface: CONFIG_CLOCKS_IN_MHZ diff --git a/include/config_fallbacks.h b/include/config_fallbacks.h index 76818f6..7d8daa2 100644 --- a/include/config_fallbacks.h +++ b/include/config_fallbacks.h @@ -79,10 +79,6 @@ #define CONFIG_SYS_PROMPT = #endif -#ifndef CONFIG_SYS_HZ -#define CONFIG_SYS_HZ 1000 -#endif - #ifndef CONFIG_FIT_SIGNATURE #define CONFIG_IMAGE_FORMAT_LEGACY #endif diff --git a/include/configs/cm_fx6.h b/include/configs/cm_fx6.h index a20c373..f7277eb 100644 --- a/include/configs/cm_fx6.h +++ b/include/configs/cm_fx6.h @@ -19,7 +19,6 @@ #define CONFIG_MX6 #define CONFIG_SYS_LITTLE_ENDIAN #define CONFIG_MACH_TYPE 4273 -#define CONFIG_SYS_HZ 1000 #ifndef CONFIG_SPL_BUILD #define CONFIG_DM diff --git a/include/configs/edb93xx.h b/include/configs/edb93xx.h index 37bdcc0..47a8420 100644 --- a/include/configs/edb93xx.h +++ b/include/configs/edb93xx.h @@ -89,7 +89,6 @@ #define CONFIG_EP93XX 1 /* in a Cirrus Logic 93xx SoC */ #define CONFIG_SYS_CLK_FREQ14745600/* EP93xx has a 14.7456 clock */ -#define CONFIG_SYS_HZ 1000/* decr freq: 1 ms ticks */ #undef CONFIG_USE_IRQ /* Don't need IRQ/FIQ */ /* Monitor configuration */ diff --git a/include/configs/ks2_evm.h b/include/configs/ks2_evm.h index 51926f7..137d9b0 100644 --- a/include/configs/ks2_evm.h +++ b/include/configs/ks2_evm.h @@ -23,7 +23,6 @@ #define CONFIG_ARMV7 #define CONFIG_ARCH_CPU_INIT #define CONFIG_SYS_ARCH_TIMER -#define CONFIG_SYS_HZ 1000 #define CONFIG_SYS_TEXT_BASE 0x0c001000 #define CONFIG_SPL_TARGET u-boot-spi.gph #define CONFIG_SYS_DCACHE_OFF diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h index 4221426..d1f6ea7 100644 --- a/include/configs/ls1021aqds.h +++ b/include/configs/ls1021aqds.h @@ -360,7 +360,6 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_SYS_MEMTEST_END 0x9fff #define CONFIG_SYS_LOAD_ADDR 0x8200 -#define CONFIG_SYS_HZ 1000 /* * Stack sizes diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index 5868287..3c73af8 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -261,7 +261,6 @@ #define CONFIG_SYS_MEMTEST_END 0x9fff #define CONFIG_SYS_LOAD_ADDR 0x8200 -#define CONFIG_SYS_HZ 1000 /* * Stack sizes diff --git a/include/configs/ls2085a_common.h b/include/configs/ls2085a_common.h index a72e1f3..6fe032c 100644 --- a/include/configs/ls2085a_common.h +++ b/include/configs/ls2085a_common.h @@ -253,8 +253,6 @@ #define CONFIG_NR_DRAM_BANKS 3 -#define CONFIG_SYS_HZ 1000 - #define CONFIG_HWCONFIG #define HWCONFIG_BUFFER_SIZE 128 diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 1d947d7..0c117bc 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -105,8 +105,6 @@ /* standalone support */ #define CONFIG_STANDALONE_LOAD_ADDR0x4200 -#define CONFIG_SYS_HZ 1000 - /* baudrate */ #define CONFIG_BAUDRATE115200 diff --git a/include/configs/tqma6.h b/include/configs/tqma6.h index 2705d2c..d97a961 100644 --- a/include/configs/tqma6.h +++ b/include/configs/tqma6.h @@ -450,7 +450,6 @@ #define
[U-Boot] [PATCH v2 2/7] x86: set CONFIG_USE_PRIVATE_LIBGCC to y
The motivation of this commit is to change CONFIG_USE_PRIVATE_LIBGCC to a boolean macro so we can move it to Kconfig. In the current implementation, there are two forms of syntax for this macro: - CONFIG_USE_PRIVATE_LIBGCC=y - CONFIG_USE_PRIVATE_LIBGCC=path/to/private/libgcc The latter is only used by x86 architecture. With a little bit refactoring, it can be converted to the former. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Tested-by: Simon Glass s...@chromium.org Acked-by: Simon Glass s...@chromium.org --- Changes in v2: - Rebase on commit 68e80fdda arch/x86/config.mk| 3 --- arch/x86/include/asm/config.h | 2 ++ arch/x86/lib/Makefile | 6 +++--- 3 files changed, 5 insertions(+), 6 deletions(-) diff --git a/arch/x86/config.mk b/arch/x86/config.mk index 3106079..3e7fedb 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -28,6 +28,3 @@ PLATFORM_LDFLAGS += --emit-relocs -Bsymbolic -Bsymbolic-functions -m elf_i386 LDFLAGS_FINAL += --gc-sections -pie LDFLAGS_FINAL += --wrap=__divdi3 --wrap=__udivdi3 LDFLAGS_FINAL += --wrap=__moddi3 --wrap=__umoddi3 - -export NORMAL_LIBGCC = $(shell $(CC) $(PLATFORM_CPPFLAGS) -print-libgcc-file-name) -CONFIG_USE_PRIVATE_LIBGCC := arch/x86/lib diff --git a/arch/x86/include/asm/config.h b/arch/x86/include/asm/config.h index ff15828..fedcaea 100644 --- a/arch/x86/include/asm/config.h +++ b/arch/x86/include/asm/config.h @@ -11,4 +11,6 @@ #define CONFIG_LMB #define CONFIG_SYS_BOOT_RAMDISK_HIGH +#define CONFIG_USE_PRIVATE_LIBGCC + #endif diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index f7303ab..25b672a 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -20,9 +20,9 @@ obj-$(CONFIG_SYS_X86_TSC_TIMER) += tsc_timer.o obj-$(CONFIG_VIDEO_VGA)+= video.o obj-$(CONFIG_CMD_ZBOOT)+= zimage.o -LIBGCC := $(notdir $(NORMAL_LIBGCC)) -extra-y := $(LIBGCC) +extra-$(CONFIG_USE_PRIVATE_LIBGCC) := lib.a +NORMAL_LIBGCC = $(shell $(CC) $(PLATFORM_CPPFLAGS) -print-libgcc-file-name) OBJCOPYFLAGS := --prefix-symbols=__normal_ -$(obj)/$(LIBGCC): $(NORMAL_LIBGCC) FORCE +$(obj)/lib.a: $(NORMAL_LIBGCC) FORCE $(call if_changed,objcopy) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/7] kconfig: invoke silentoldconfig if spl, tpl/.config is updated
When spl/.config is updated by make spl/menuconfig or friends,
spl/include/config/auto.conf, spl/include/generated/autoconf.h
and some other files must be updated by make silentoldconfig.
There is no hook for SPL in the top Makefile, so this commit
touches .config when spl/.config is updated to invoke silentoldconfig.
Likewise for TPL.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Changes in v2: None
scripts/multiconfig.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/scripts/multiconfig.sh b/scripts/multiconfig.sh
index 3a963c7..3e3040b 100644
--- a/scripts/multiconfig.sh
+++ b/scripts/multiconfig.sh
@@ -297,9 +297,24 @@ do_others () {
else
objdir=${1%/*}
check_enabled_subimage $1 $objdir
+
+ if [ -f $objdir/$KCONFIG_CONFIG ]; then
+ timestamp_before=$(stat --printf=%Y \
+ $objdir/$KCONFIG_CONFIG)
+ fi
fi
run_make_config $target $objdir
+
+ if [ $timestamp_before -a -f $objdir/$KCONFIG_CONFIG ]; then
+ timestamp_after=$(stat --printf=%Y $objdir/$KCONFIG_CONFIG)
+
+ if [ $timestamp_after -gt $timestamp_before ]; then
+ # $objdir/.config has been updated.
+ # touch .config to invoke make silentoldconfig
+ touch $KCONFIG_CONFIG
+ fi
+ fi
}
progname=$(basename $0)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
