June 2019 - U-Boot

[U-Boot] [PATCH] drivers: mtd: spi: Add flash property for Micron mt25qu512a
by Ashish Kumar 27 Jun '19

27 Jun '19

mt25qu512a is rebranded after its spinoff from STM, so it is different only in term of extended jedec ID, initial JEDEC id is same as that of n25q512a.In order to avoid any confussion with respect to name new entry is added. This flash is tested for Single I/O mode on LS1046FRWY although it also support QUAD I/O. Signed-off-by: Ashish Kumar <Ashish.Kumar(a)nxp.com> --- drivers/mtd/spi/spi-nor-ids.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c index 6164b6e..a992966 100644 --- a/drivers/mtd/spi/spi-nor-ids.c +++ b/drivers/mtd/spi/spi-nor-ids.c @@ -163,6 +163,8 @@ const struct flash_info spi_nor_ids[] = { { INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, SECT_4K | SPI_NOR_QUAD_READ) }, { INFO("n25q256a", 0x20ba19, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) }, { INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) }, + { INFO6("mt25qu512a", 0x20bb20, 0x104400, 64 * 1024, 1024, + SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) }, { INFO("n25q512a", 0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) }, { INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) }, { INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) }, -- 2.7.4

1 0

[U-Boot] [PATCH] drivers: mtd: spi: Add micron mt35xu512g and mt35xu02g flash ID
by Ashish Kumar 27 Jun '19

27 Jun '19

mt35xu512g and mt35xu02g suports Single I/O and OCTAL I/O also enable use of SPI_NOR_4B_OPCODES. These flashes are tested on LX2160ARDB and LS1028ARDB respectively Signed-off-by: Kuldeep Singh <kuldeep.singh(a)nxp.com> Signed-off-by: Ashish Kumar <Ashish.Kumar(a)nxp.com> --- drivers/mtd/spi/spi-nor-ids.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c index a89c191..6164b6e 100644 --- a/drivers/mtd/spi/spi-nor-ids.c +++ b/drivers/mtd/spi/spi-nor-ids.c @@ -168,6 +168,8 @@ const struct flash_info spi_nor_ids[] = { { INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) }, { INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) }, { INFO("mt25qu02g", 0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) }, + { INFO6("mt35xu512g", 0x2c5b1a, 0x104100, 128 * 1024, 512, USE_FSR | SPI_NOR_4B_OPCODES) }, + { INFO("mt35xu02g", 0x2c5b1c, 0x0, 128 * 1024, 2048, USE_FSR | SPI_NOR_4B_OPCODES) }, #endif #ifdef CONFIG_SPI_FLASH_SPANSION /* SPANSION */ /* Spansion/Cypress -- single (large) sector size only, at least -- 2.7.4

1 0

[U-Boot] [nand] [ubi] Discrepancy Between U-Boot and Linux NAND PEBs
by Ken Sloat 27 Jun '19

27 Jun '19

Hello All, I have been working on a system using a NAND flash along with U-Boot 2018.07 and Linux Kernel 4.14. This is an Atmel based system FYI so it uses the Atmel NAND driver. I create a UBI image with 3 separate volumes - 2 of these are a specified fixed size and the third is specified as the minimum needed to hold the current files with the auto resize flag set. As a note, before the first run auto resize operation, there is over 200 MiB of unused space in the NAND - meaning there should be plenty of free space available for UBI to leave overhead when auto-resizing for bad block handling. Another point of note, is that I use UBI within U-Boot as well in order to read the kernel image and dtb out of the UBIFS. I have noticed warnings in Linux when attaching UBI regarding not having enough reserved PEBs for bad block handling (it's short by 2). Upon further investigation into the issue, it appears as though there is a discrepancy between what U-Boot and Linux see in terms of the number of bad blocks: U-Boot: ubi0: good PEBs: 4093, bad PEBs: 3, corrupted PEBs: 0 ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128 Linux: ubi0 warning: ubi_eba_init: cannot reserve enough PEBs for bad PEB handling, reserved 71, need 73 ...... ubi0: good PEBs: 4089, bad PEBs: 7, corrupted PEBs: 0 ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128 After production flashing of a UBI image to NAND (with a "dumb" non UBI aware flasher), U-Boot will be the program to mount UBI. What this means is that it will complete the one time re-size operation. I used a Linux ramdisk image to flash from Linux and mount UBI in Linux for the first time to allow it to complete the auto-resize operation instead and compared: U-Boot: ubi0: attaching mtd1 ubi0: scanning is finished ubi0: volume 1 ("rootfs") re-sized from 1501 to 3385 LEBs ubi0: attached mtd1 (name "mtd=0", size 512 MiB) ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048 ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096 ubi0: good PEBs: 4093, bad PEBs: 3, corrupted PEBs: 0 Linux: ubi0: attaching mtd6 ubi0: scanning is finished ubi0: volume 1 ("rootfs") re-sized from 1501 to 3383 LEBs ubi0: attached mtd6 (name "atmel_nand", size 512 MiB) ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048 ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096 ubi0: good PEBs: 4089, bad PEBs: 7, corrupted PEBs: 0 As you can see, U-Boot resizes the image to 3385 blocks while Linux only 3383 - hence the 2 blocks that Linux would complain about had U-Boot resized the volume. I am not sure exactly what is causing this discrepancy as I just figured this out - but thought I would reach out and discuss it here. Obviously there are ways around this issue (program and mount UBI from Linux initially, don't use autoresize and specify all volume sizes, etc) but was wondering if there is some underlying problem. I noticed an older mailing discussion from several years ago where someone reported a similar issue regarding number of bad PEBs and seems the issue was chalked up to a potential driver problem on one side: https://lists.denx.de/pipermail/u-boot/2015-June/216482.html Any insight would be helpful. Thanks, Ken Sloat

2 2

[U-Boot] [PATCH] apalis_imx6: fix set_emmcargs wrapper
by Igor Opaniuk 27 Jun '19

27 Jun '19

From: Igor Opaniuk <igor.opaniuk(a)toradex.com> Fix set_emmcargs wrapper, which prepares proper bootargs for booting from eMMC. Signed-off-by: Igor Opaniuk <igor.opaniuk(a)toradex.com> --- include/configs/apalis_imx6.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h index 4b0a3fb26b..cffb90a690 100644 --- a/include/configs/apalis_imx6.h +++ b/include/configs/apalis_imx6.h @@ -121,8 +121,8 @@ "imx6q-apalis-cam-eval.dtb fat 0 1" #define EMMC_BOOTCMD \ - "set_emmcargs emmcargs ip=off root=PARTUUID=${uuid} ro,noatime " \ - "rootfstype=ext4 rootwait\0" \ + "set_emmcargs=setenv emmcargs ip=off root=PARTUUID=${uuid} " \ + "ro,noatime rootfstype=ext4 rootwait\0" \ "emmcboot=run setup; run emmcfinduuid; run set_emmcargs; " \ "setenv bootargs ${defargs} ${emmcargs} ${setupargs} " \ "${vidargs}; echo Booting from internal eMMC chip...; " \ -- 2.17.1

3 3

Re: [U-Boot] [PATCH v4 1/2] regulator: bd71837: copy the bd71837 pmic
by Vaittinen, Matti 27 Jun '19

27 Jun '19

Hello Stefano, On Mon, 2019-06-10 at 11:40 +0200, sbabic(a)denx.de wrote: > > https://source.codeaurora.org/external/imx/uboot-imx > > cherry picked, styled and merged commits: > > - MLK-18387 pmic: Add pmic driver for BD71837: e9a3bec2e95a > > - MLK-18590 pmic: bd71837: Change to use new fdt API: acdc5c297a96 > > Signed-off-by: Ye Li <ye.li(a)nxp.com> > > Signed-off-by: Matti Vaittinen <matti.vaittinen(a)fi.rohmeurope.com> > > Reviewed-by: Simon Glass <sjg(a)chromium.org> > > Applied to u-boot-imx, master, thanks ! Thanks for merging the patch :] Do you think the 2/2 could also be taken in? Best regards Matti Vaittinen

2 3

[U-Boot] Upstreaming usb host drivers for iMX8/iMX8M
by Igor Opaniuk 27 Jun '19

27 Jun '19

Hi Peng, Ye, Peter, Currently there in no any usb host/gadget support in the mainline U-boot, and seems that no one has posted anything yet to the mailing list (at least I haven't found anything related to this in the ML archives). I've spent some time testing (usb host, ums etc.) the one in the downstream NXP U-boot (I'm still not sure where is the official NXP downstream rep, because there are no any updates in [1] for the last two years, so I looked into [2], [3]), and just curious if there any plans to get it upstreamed in the near future? Thanks and looking forward to your reply! [1] http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git [2] https://source.codeaurora.org/external/imx/uboot-imx/tree/drivers/usb/host/… [3] https://source.codeaurora.org/external/imx/uboot-imx/tree/drivers/usb/host/… -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opaniuk(a)gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk

3 4

[U-Boot] [PATCH v5 0/2] add command env erase
by Frank Wunderlich 27 Jun '19

27 Jun '19

sometimes it is needed to erase the non-volatile environment e.g. for boot-up with builtin-environment or after resizing env this series add basic functionality for erasing environment from storage as a first storage-driver mmc is introduced, other needs to be added later changes since v4: - rebased to 2019.07-rc4 - changed handling with CONFIG_ENV_OFFSET_REDUND (more similar to saveenv) - quashed last 2 commits to get 2-parts patchset Frank Wunderlich (2): env: register erase command env: mmc: add erase-function cmd/Kconfig | 8 +++++++ cmd/nvedit.c | 20 +++++++++++++++++ env/env.c | 30 +++++++++++++++++++++++++ env/mmc.c | 52 +++++++++++++++++++++++++++++++++++++++++++ include/environment.h | 17 ++++++++++++++ 5 files changed, 127 insertions(+) -- 2.17.1

2 5

[U-Boot] [PATCH] board: atmel: fix pda variable not being reset
by Eugen.Hristev＠microchip.com 27 Jun '19

27 Jun '19

From: Eugen Hristev <eugen.hristev(a)microchip.com> In case someone detects a PDA and u-boot sets the 'pda' variable, and the user does a saveenv, the pda is set in env, and if the screen is removed, u-boot will still have in the env the 'pda' variable, even if no screen is attached. In order to fix this, we have to reset the 'pda' variable, such that it's not just set if the screen is detected, but also unset if no screen is detected. Signed-off-by: Eugen Hristev <eugen.hristev(a)microchip.com> --- board/atmel/common/board.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/board/atmel/common/board.c b/board/atmel/common/board.c index fc300a4..20c3b8c 100644 --- a/board/atmel/common/board.c +++ b/board/atmel/common/board.c @@ -29,7 +29,7 @@ void at91_pda_detect(void) ret = w1_get_bus(AT91_PDA_EEPROM_DEFAULT_BUS, &bus); if (ret) - return; + goto pda_detect_err; for (device_find_first_child(bus, &dev); dev; @@ -41,7 +41,7 @@ void at91_pda_detect(void) ret = w1_eeprom_read_buf(dev, AT91_PDA_EEPROM_ID_OFFSET, (u8 *)buf, AT91_PDA_EEPROM_ID_LENGTH); if (ret) - return; + goto pda_detect_err; break; } } @@ -61,6 +61,8 @@ void at91_pda_detect(void) printf("PDA TM5000 detected\n"); break; } + +pda_detect_err: env_set("pda", (const char *)buf); } #else -- 2.7.4

1 1

[U-Boot] [PATCH] spi-uclass: claim bus before setting speed
by George Hilliard 27 Jun '19

27 Jun '19

The sunxi SPI peripheral driver attempts to interact with the peripheral in the set_speed function. It also resets the device completely (disabling clocks and power) when the bus is released and turns it back on when claiming. So, if the clock was set up before the bus was claimed, the speed change would have no effect, and the peripheral wouldn't work in many cases. This change allows the peripheral driver to initialize the device before attempting to do anything else. Signed-off-by: George Hilliard <thirtythreeforty(a)gmail.com> Cc: Jagan Teki <jteki(a)openedev.com> --- drivers/spi/spi-uclass.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c index 88cb2a12622..88aa883b206 100644 --- a/drivers/spi/spi-uclass.c +++ b/drivers/spi/spi-uclass.c @@ -51,6 +51,7 @@ int dm_spi_claim_bus(struct udevice *dev) struct dm_spi_bus *spi = dev_get_uclass_priv(bus); struct spi_slave *slave = dev_get_parent_priv(dev); int speed; + int ret; speed = slave->max_hz; if (spi->max_hz) { @@ -61,15 +62,22 @@ int dm_spi_claim_bus(struct udevice *dev) } if (!speed) speed = SPI_DEFAULT_SPEED_HZ; + + if (ops->claim_bus) { + ret = ops->claim_bus(dev); + if (ret) + return log_ret(ret); + } + if (speed != slave->speed) { - int ret = spi_set_speed_mode(bus, speed, slave->mode); + ret = spi_set_speed_mode(bus, speed, slave->mode); if (ret) return log_ret(ret); slave->speed = speed; } - return log_ret(ops->claim_bus ? ops->claim_bus(dev) : 0); + return 0; } void dm_spi_release_bus(struct udevice *dev) -- 2.21.0

2 1

[U-Boot] [PATCH 0/6] sunxi: H6: Enable USB (2.0) support
by Andre Przywara 27 Jun '19

27 Jun '19

Hi, this series enables USB support on the H6 boards. This is mostly just adding some missing pieces here and there, the actual controller and PHY are very similar to the previous ones, if not identical. This is for the 2.0 ports only at the moment, USB 3.0 will be done later (started porting Icenowy's Linux driver). The Pine H64 shares a similar problem as the Pine64+ boards regarding the upper USB port. To enable this port, we need the first patch from the series [1] fixing this issue on the A64 boards. Patch 1 is a drive-by patch to bring SUNXI_GPIO to Kconfig, as this was lingering in one of my branches for a while. Patch 2 enables GPIO support for the H6, as this is needed for the Pine H64 to enable the VBUS regulator. Patch 3 adds the clock and reset gates mappings for the USB controller and the PHY, the values are taken from the manual and verified against Linux. Patch 4 adds some code to the PHY driver to skip over not implemented PHYs, as the H6 uses a PHY0/PHY3 combination in the DT. Patch 5 then eventually enables USB in the existing defconfigs. Patch 6 adds the .dts fixes required to get the upper USB port to work on the Pine H64. Clément, can you please verify that this works for the Beelink box? I guess the USB 2.0 port is probably the OTG one, so this setup would look somewhat similar to the PineH64, which would allow you to copy the USB DT nodes from there. Cheers, Andre. [1] https://lists.denx.de/pipermail/u-boot/2019-May/369520.html Andre Przywara (6): sunxi: move SUNXI_GPIO to Kconfig sunxi: gpio: Enable support for H6 pin controller sunxi: clocks: Add H6 USB clock gates and resets sunxi: phy: Add USB PHY support for Allwinner H6 sunxi: H6: Enable USB for existing boards sunxi: Pine64: DTS: enable USB PHY 0 for HCI0 arch/arm/Kconfig | 1 + arch/arm/dts/sun50i-h6-pine-h64.dts | 5 ++++- arch/arm/mach-sunxi/Kconfig | 1 + configs/beelink_gs1_defconfig | 2 ++ configs/orangepi_lite2_defconfig | 2 ++ configs/orangepi_one_plus_defconfig | 2 ++ configs/pine_h64_defconfig | 3 +++ drivers/clk/sunxi/clk_h6.c | 29 +++++++++++++++++++++++++++++ drivers/gpio/Kconfig | 6 ++++++ drivers/gpio/sunxi_gpio.c | 2 ++ drivers/phy/allwinner/phy-sun4i-usb.c | 20 ++++++++++++++++++++ include/configs/sunxi-common.h | 3 --- scripts/config_whitelist.txt | 1 - 13 files changed, 72 insertions(+), 5 deletions(-) -- 2.14.5

7 23