July 2016 - U-Boot

[U-Boot] [PATCH] serial: ns16550: Add support for the BayTrail internal HS UART
by Stefan Roese 18 Jul '16

18 Jul '16

To support the BayTrail internal SIO HS UART, the internal UART clock needs to get configured. This patch adds support for this clock configuration which will be done, if a compatible DT node is found. Signed-off-by: Stefan Roese <sr(a)denx.de> Cc: Simon Glass <sjg(a)chromium.org> Cc: Bin Meng <bmeng.cn(a)gmail.com> --- drivers/serial/ns16550.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index c6cb3eb..12499ec 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -94,6 +94,13 @@ static inline int serial_in_shift(void *addr, int shift) #define CONFIG_SYS_NS16550_CLK 0 #endif +/* Intel BayTrail defines */ +#define BYT_PRV_CLK 0x800 +#define BYT_PRV_CLK_EN (1 << 0) +#define BYT_PRV_CLK_M_VAL_SHIFT 1 +#define BYT_PRV_CLK_N_VAL_SHIFT 16 +#define BYT_PRV_CLK_UPDATE (1 << 31) + static void ns16550_writeb(NS16550_t port, int offset, int value) { struct ns16550_platdata *plat = port->plat; @@ -381,6 +388,25 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev) return ret; addr = bar; + + /* Setup BayTrail UART clock */ + ret = fdt_node_check_compatible(gd->fdt_blob, dev->of_offset, + "baytrail-hs-uart"); + if (ret == 0) { + u32 m, n, reg; + + /* + * Configure the BayTrail UART clock for the internal + * HS UARTs (PCI devices) to 58982400 Hz + */ + m = 0x2400; + n = 0x3d09; + reg = (m << BYT_PRV_CLK_M_VAL_SHIFT) | + (n << BYT_PRV_CLK_N_VAL_SHIFT); + writel(reg, bar + BYT_PRV_CLK); + reg |= BYT_PRV_CLK_EN | BYT_PRV_CLK_UPDATE; + writel(reg, bar + BYT_PRV_CLK); + } } #endif -- 2.9.1

3 4

[U-Boot] xHCI on x86
by Stefan Roese 18 Jul '16

18 Jul '16

Hi! I'm currently trying to get xHCI working on some BayTrail based x86 boards. For this I've added DM support to xhci-pci and made a small change to cache.h to enable compilation of the xhci driver on x86 (please find those 2 patches attached - I'll send then to the list once this is resolved). But I noticed that the xhci driver hangs in xhci_queue_command() in this line: xhci_writel(&ctrl->dba->doorbell[0], DB_VALUE_HOST); when first writing to the doorbell register. Reading from this doorbell register still works just fine. IIRC, Simon has mentioned that xHCI still has some "issues" on x86. Simon, is this what you have seen as well? Does anyone have some ideas how to solve this? Thanks, Stefan

2 2

[U-Boot] PCIe bridges on Jetson TK1
by Andreas Färber 18 Jul '16

18 Jul '16

Hi, When I boot my Jetson TK1, by default I get this from lspci: 00:02.0 PCI bridge: NVIDIA Corporation TegraK1 PCIe x1 Bridge (rev a1) 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) If however I plug some mini PCIe card, I get this instead: 00:01.0 PCI bridge: NVIDIA Corporation TegraK1 PCIe x4 Bridge (rev a1) 00:02.0 PCI bridge: NVIDIA Corporation TegraK1 PCIe x1 Bridge (rev a1) 01:00.0 Network controller: MEDIATEK Corp. Device 7612 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) I.e., there is a new Tegra PCIe x4 bridge and the number of the previous x1 bridge changed. That is ugly because it changes the ID of the on-board PCI NIC from 01:00.0 to 02:00.0, which on openSUSE renames the network interface from enp1s0 to enp2s0, so that my /etc/sysconfig/network/ifcfg-enp1s0 does not take effect and the network interface doesn't come up. Tested with U-Boot v2016.05 and v2016.07 and kernel 4.6.2 and 4.7-rc6. Shouldn't U-Boot or the kernel driver always configure the PCIe ports the same way (both bridges available) since the slot is always there on this board? Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)

2 2

[U-Boot] [PATCH 0/4] tools/env: minor refactorings
by Andreas Fenkart 18 Jul '16

18 Jul '16

various patches, see individual patch descriptions Andreas Fenkart (4): tools/env: return with error if redundant environments have unequal size tools/env: javadoc for fw_printenv, fw_getenv and fw_parse_script tools/env: move envmatch further up in file to avoid forward declarations tools/env: reuse fw_getenv in fw_printenv function tools/env/fw_env.c | 105 ++++++++++++++++++++++++----------------------------- tools/env/fw_env.h | 75 +++++++++++++++++++++++++++++++++++++- 2 files changed, 121 insertions(+), 59 deletions(-) -- 2.8.1

4 10

[U-Boot] [PATCH 1/1] mtd: nand-base: fix bug writing 1 byte less than page size
by Hector Palacios 18 Jul '16

18 Jul '16

nand_do_write_ops() determines if it is writing a partial page with the formula: if (column || (writelen < mtd->writesize - 1)) When 'writelen' is exactly 1 byte less than the NAND page size the formula equates to zero, so the code doesn't process it as a partial write, although it should. As a consequence the function remains in the while(1) loop with 'writelen' becoming 0xffffffff and iterating until the watchdog timeout triggers. To reproduce the issue on a NAND with 2K page (0x800): => nand erase.part <partition> => nand write $loadaddr <partition> 7ff Signed-off-by: Hector Palacios <hector.palacios(a)digi.com> https://jira.digi.com/browse/DUB-619 --- drivers/mtd/nand/nand_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index c0e381ad2d15..cb15bb21e2f0 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2524,7 +2524,7 @@ static int nand_do_write_ops(struct mtd_info *mtd, loff_t to, WATCHDOG_RESET(); /* Partial page write? */ - if (unlikely(column || writelen < (mtd->writesize - 1))) { + if (unlikely(column || writelen < mtd->writesize)) { cached = 0; bytes = min_t(int, bytes - column, (int) writelen); chip->pagebuf = -1;

1 1

[U-Boot] [PATCH v2 1/1] mtd: nand: fix bug writing 1 byte less than page size
by Hector Palacios 18 Jul '16

18 Jul '16

nand_do_write_ops() determines if it is writing a partial page with the formula: part_pagewr = (column || writelen < (mtd->writesize - 1)) When 'writelen' is exactly 1 byte less than the NAND page size the formula equates to zero, so the code doesn't process it as a partial write, although it should. As a consequence the function remains in the while(1) loop with 'writelen' becoming 0xffffffff and iterating until the watchdog timeout triggers. To reproduce the issue on a NAND with 2K page (0x800): => nand erase.part <partition> => nand write $loadaddr <partition> 7ff Signed-off-by: Hector Palacios <hector.palacios(a)digi.com> --- Changes in v2 - v1 was wronly generated over U-Boot v2015.04 drivers/mtd/nand/nand_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 689716753ae6..8280288a5ea1 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2411,7 +2411,7 @@ static int nand_do_write_ops(struct mtd_info *mtd, loff_t to, int cached = writelen > bytes && page != blockmask; uint8_t *wbuf = buf; int use_bufpoi; - int part_pagewr = (column || writelen < (mtd->writesize - 1)); + int part_pagewr = (column || writelen < mtd->writesize); if (part_pagewr) use_bufpoi = 1;

1 0

[U-Boot] [RFC PATCH 0/1] bug writing to NAND 1 byte less than page size
by Hector Palacios 18 Jul '16

18 Jul '16

Hi, I found this bug on v2015.04 but I guess it happens also in v2016.07 as I believe it has been there since 2007. It is so strange that nobody caught this before that I fear I'm doing something wrong or not taking something into account on the suggested fix, so I'd like to know if others can reproduce it and if the fix looks correct. I reproduced it on an i.MX6UL platform and on an i.MX28 platform but it is a bug on the NAND core driver, so it should be reproducible with any architecture. In fact, it is reproducible with any size, as long as it is a multiple of the page size, less one byte. Thanks in advance for your comments. Hector Palacios (1): mtd: nand: fix bug writing 1 byte less than page size drivers/mtd/nand/nand_base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

2 3

[U-Boot] [PATCH 0/5]
by Kever Yang 18 Jul '16

18 Jul '16

This patchset add support for rk3399 with ATF based on Rockchip miniloader as secondary bootloader instead of u-boot SPL. Rockchip miniloader init the DRAM and load the ATF and u-boot to runing address, and then jump to ATF, ATM do some init and switch to EL2/EL1 mode before jump to next loader which is u-boot here. Pls reference board/rockchip/evb_rk3399/README to setup the board. Will migrate to SPL once its ready for ATF. This patch set is based on below patch: "board: move all the rockchip board in one folder" This patch set has been test on rk3399 evb board. Kever Yang (5): dts: add support for rkchichip rk3399 soc ARM64: rockchip: add support for rk3399 SoC based evb-board config: add config file for evb-rk3399 mmc: rockchip: add SDHCI driver support for rockchip soc ARM64: evb-rk3399: add a README for this board setup arch/arm/Kconfig | 3 - arch/arm/dts/Makefile | 3 +- arch/arm/dts/rk3399-evb.dts | 104 ++++ arch/arm/dts/rk3399.dtsi | 1028 ++++++++++++++++++++++++++++++++ arch/arm/mach-rockchip/Kconfig | 25 +- arch/arm/mach-rockchip/Makefile | 2 +- arch/arm/mach-rockchip/rk3399/Kconfig | 19 + arch/arm/mach-rockchip/rk3399/Makefile | 5 + board/rockchip/evb_rk3399/Kconfig | 15 + board/rockchip/evb_rk3399/MAINTAINERS | 0 board/rockchip/evb_rk3399/Makefile | 7 + board/rockchip/evb_rk3399/README | 73 +++ board/rockchip/evb_rk3399/evb-rk3399.c | 41 ++ configs/evb-rk3399_defconfig | 32 + drivers/mmc/Kconfig | 6 + drivers/mmc/Makefile | 1 + drivers/mmc/rockchip_sdhci.c | 58 ++ include/configs/evb_rk3399.h | 24 + include/configs/rk3399_common.h | 84 +++ include/dt-bindings/clock/rk3399-cru.h | 746 +++++++++++++++++++++++ 20 files changed, 2270 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/rk3399-evb.dts create mode 100644 arch/arm/dts/rk3399.dtsi create mode 100644 arch/arm/mach-rockchip/rk3399/Kconfig create mode 100644 arch/arm/mach-rockchip/rk3399/Makefile create mode 100644 board/rockchip/evb_rk3399/Kconfig create mode 100644 board/rockchip/evb_rk3399/MAINTAINERS create mode 100644 board/rockchip/evb_rk3399/Makefile create mode 100644 board/rockchip/evb_rk3399/README create mode 100644 board/rockchip/evb_rk3399/evb-rk3399.c create mode 100644 configs/evb-rk3399_defconfig create mode 100644 drivers/mmc/rockchip_sdhci.c create mode 100644 include/configs/evb_rk3399.h create mode 100644 include/configs/rk3399_common.h create mode 100644 include/dt-bindings/clock/rk3399-cru.h -- 1.9.1

2 10

Re: [U-Boot] MPC8347 Initial Boot problems
by Gardner, Austin (GE Transportation) 17 Jul '16

17 Jul '16

Still hoping for a response. I have not had any luck trying to get this up and running. Any advice would be very helpful. Thanks, Austin From: Gardner, Austin (GE Transportation) Sent: Friday, June 17, 2016 8:57 AM To: 'u-boot(a)lists.denx.de' <u-boot(a)lists.denx.de> Subject: MPC8347 Initial Boot problems Hello, I am currently trying to get my MPC8347EA board up and running by porting the MPC8349EMDS configuration that is currently available. This is my first time working with uboot, so naturally I am having some issues. My issue is that I can't get any response from the board after we flash it with the binary image. I don't know if I am flashing it in the wrong location, or if it is because the configurations in the header files that I changed are wrong. I have tried flashing it in various locations such as start of memory, CONFIG_SYS_TEXT_BASE location (changed to our needs of 0xFF8000000), etc. I also have changed a lot of the memory configurations from the MPC8349EMDS such as the timing configs, ddrlawbar and ddrlawar, sdram configs and modes, etc. After getting the uboot to actually launch to a command line, the next step will be to have it launch to our QNX os. Any help with this would be greatly appreciated. I apologize if I use the wrong terminology at any point, I am still very new to this. Thanks, Austin

2 1

[U-Boot] MinnowBoard Turbot U-boot is in 64-bit mode or 32-bit mode
by vinoth eswaran 17 Jul '16

17 Jul '16

Hi Mr.Simon Glass, Currently I am working on an embedded project with Minnowmax Turbot. I am checking the performance of different compression algorithms that can be employed in FIT image. I came across Brotli and felt that it might suit my use case. I had integrated the Brotli to U-Boot and tested the compression algorithm performance. It doesn't work as expected and I had contacted the Brotli group with the test report: https://groups.google.com/forum/#!topic/brotli/dg2gNlo61yI There are certain configurations which I can enable to optimize the algorithm, - BROTLI_BUILD_32_BIT disables 64-bit optimizations - BROTLI_BUILD_64_BIT forces to use 64-bit optimizations With the BROTLI_BUILD_64_BIT , I am getting the following error messages : [1.399921 0.114735] 4782061 bytes read in 115 ms (39.7 MiB/s) [1.403965 0.004044] Uncompressing Kernel Image ... [1.407913 0.003948] [1.407983 0.000070] brotli decompression start [1.411025 0.003042] General Protection [1.412884 0.001859] EIP: 0010:[<7b568599>] EFLAGS: 00010002 [1.416906 0.004022] Original EIP :[<fff13599>] [1.419852 0.002946] EAX: 00000001 EBX: 7833e748 ECX: 00000000 EDX: fffffff9 [1.425035 0.005183] ESI: 00000001 EDI: 01000000 EBP: 7833e848 ESP: 7833e6bc [1.430915 0.005880] DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018 [1.435062 0.004147] CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000600 [1.440859 0.005797] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [1.446064 0.005205] DR6: ffff0ff0 DR7: 00000400 [1.449103 0.003039] Stack: [1.449966 0.000863] 0x7833e6fc : 0x7833e848 [1.452891 0.002925] 0x7833e6f8 : 0x5c391d06 [1.455755 0.002864] 0x7833e6f4 : 0x7833fae8 [1.458056 0.002301] 0x7833e6f0 : 0x7833e750 [1.461008 0.002952] 0x7833e6ec : 0x7833fae4 [1.463962 0.002954] 0x7833e6e8 : 0x7833fae0 [1.466876 0.002914] 0x7833e6e4 : 0xf9ad562e [1.469842 0.002966] 0x7833e6e0 : 0x6eb7781b [1.472083 0.002241] 0x7833e6dc : 0xe3d562de [1.475045 0.002962] 0x7833e6d8 : 0x0756abd8 [1.477961 0.002916] 0x7833e6d4 : 0x875fabcb [1.480914 0.002953] 0x7833e6d0 : 0x957d8f8e [1.483862 0.002948] 0x7833e6cc : 0x7b58085f [1.486759 0.002897] 0x7833e6c8 : 0x7833e848 [1.489059 0.002300] 0x7833e6c4 : 0x01000000 [1.492064 0.003005] 0x7833e6c0 : 0x00000001 [1.494956 0.002892] --->0x7833e6bc : 0x7833e748 [1.497860 0.002904] 0x7833e6b8 : 0x00010002 [1.500719 0.002859] 0x7833e6b4 : 0x00000010 [1.503109 0.002390] 0x7833e6b0 : 0x7b568599 [1.505943 0.002834] ### ERROR ### Please RESET the board ### My kernel image is X86_64. I am not sure what is happening in u-boot(32-bit or 64-bit). I had gone though the following discussion in U-boot mailing list but not understanding what is happening, http://lists.denx.de/pipermail/u-boot/2016-February/244191.html Mit Freundlichen Grüßen VinothKumar +49 1798909072

2 1