April 2017 - U-Boot

[U-Boot] [PATCH 0/7] Add Device Tree for OMAP3 and omap3_logic
by Adam Ford 12 Apr '17

12 Apr '17

This patch series copies the Linux Device trees for the OMAP3 and OMAP3630 platforms as well as some additional device trees to support the Logic PD Torpedo and Logic PD SOM-LV both based on DM3730 (OMAP3630) processors. There are no changes to patches 2-7 from the initial version posted as RFC, but I added "Reviewed-by: Lokesh Vutla <lokeshvutla(a)ti.com>" to patches 2-7 Patch 1 removes the wrong comments I made when mixed up the am33xx datasheet. It should correctly supports the proper offsets on the OMAP34XX platforms and should not break the am33xx and newer boards with the different offset. I don't believe there is any debate on this. Sorry for the noise. This series allows us to eliminate the board detection code as well as move to DM_I2C and DM_MMC and push the DM_SERIAL setup to the OF except when in SPL. This should give enough background for other OMAP3 boards to migrate to device tree. The dm uclass dump is as follows: uclass 0: root - * root_driver @ 8df38028, seq 0, (req -1) uclass 9: simple_bus - * ocp@68000000 @ 8df382e0, seq 0, (req -1) - l4@48000000 @ 8df38348 - scm@2000 @ 8df383b0 - scm_conf@270 @ 8df38418 uclass 19: gpio - gpio_omap @ 8df380b0 - gpio_omap @ 8df38108 - gpio_omap @ 8df38160 - gpio_omap @ 8df381b8 - gpio_omap @ 8df38210 - gpio_omap @ 8df38268 - gpio@48310000 @ 8df38480 - gpio@49050000 @ 8df384e8 - gpio@49052000 @ 8df38550 - * gpio@49054000 @ 8df385b8, seq 0, (req -1) - gpio@49056000 @ 8df38620 - gpio@49058000 @ 8df38688 uclass 20: i2c - * i2c@48070000 @ 8df38880, seq 0, (req 0) - i2c@48072000 @ 8df388d8, seq -1, (req 1) - i2c@48060000 @ 8df38930, seq -1, (req 2) uclass 22: i2c_generic - * generic_4b @ 8df4b178, seq 0, (req -1) uclass 31: mmc - * mmc@4809c000 @ 8df389a8, seq 0, (req -1) - * mmc@480ad000 @ 8df38b80, seq 1, (req -1) uclass 52: serial - * serial@4806a000 @ 8df38710, seq 0, (req 0) - serial@4806c000 @ 8df38780, seq -1, (req 1) - serial@49020000 @ 8df387f0, seq -1, (req 2) - serial@49042000 @ 8df38d58, seq -1, (req 3)

1 0

Re: [U-Boot] generating a script file in FIT_SIGNATURE context
by Nicolas LE BAYON 12 Apr '17

12 Apr '17

From: Nicolas LE BAYON Sent: mardi 11 avril 2017 14:50 To: u-boot(a)lists.denx.de Subject: [U-Boot] generating a script file in FIT_SIGNATURE context Hi all, In my setup, I have activated FIT (without signature in a first step), and I boot using standard script way (boot.scr), which I generate with the following command : mkimage -A arm -T script -C none -n "My boot script" -d boot.txt boot.scr It works fine, and I can "load" and "bootm" the FIT image. Now I would like to activate fit_signature. When I write manually all the boot.txt script commands in the console, it works fine. So it means that the FIT image is well generated, and the u-boot is well-configured. That's a good point. But I have some problems to run the generated boot.scr in that case. I think the script should also be generated with the signature. Do you confirm that? If this is the case, from your point of view, which fields should I add to my previous command? -F ? -k ? -K? others? Thanks in advance for your feedback Best Regards Nicolas Hi again, I think I found the clue. When CONFIG_FIT_SIGNATURE is not enabled, then CONFIG_IMAGE_FORMAT_LEGACY is automatically enabled, this allow to treat correctly the boot.scr. If CONFIG_FIT_SIGNATURE is enabled, we have to set CONFIG_IMAGE_FORMAT_LEGACY to be able to keep that. With this, it seems ok on my side. Best Regards Nicolas

1 0

[U-Boot] [PATCH 0/2] Fix several bugs in qemu-mips configuration
by Kyle Edwards 12 Apr '17

12 Apr '17

I recently played around with the qemu-mips configuration, and encountered several issues. Saving the environment to flash overwrites the U-Boot code, and the malloc pool isn't big enough for initr_malloc_bootparams(). This patchset fixes these issues. Kyle Edwards (2): mips: qemu-mips: Remove obsolete CONFIG_SYS_MONITOR_LEN from config mips: qemu-mips: Expand malloc pool to fit CONFIG_SYS_BOOTPARAMS_LEN include/configs/qemu-mips.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 2.7.4

2 3

Re: [U-Boot] Unbricking process with separate environment binary?
by Lukasz Majewski 12 Apr '17

12 Apr '17

Hi John, > Hi Lukasz, > > On Tue, Apr 11, 2017 at 12:40 AM, Lukasz Majewski <lukma(a)denx.de> > wrote: > > Hi John, > > > >> Instead of having 2 builds of u-boot, one which defaults to > >> fastboot and one for normal booting, is it possible to have one > >> u-boot binary and a separate environment piece (especially for > >> bootcmd, but maybe also for some scripts)? > > > > If I might ask - where your envs are stored? Do they have a separate > > area in NAND or eMMC memory? > > > > If yes, then I suppose that you also have the possibility to write > > data to this memory in the production? > > The production redundant environment will have its own area in eMMC. > The environment could be written to the eMMC from the development host > after running fastboot or ums in u-boot, but the question is how > fastboot/ums gets run when starting with a completely blank, freshly > soldered, non-partitioned board. I've already used two approaches (with TI SoC): - Use "factory" SD card (if the slot is available) with tunned u-boot (by altering envs) - Use serial port (you mentioned that you want to talk with the board with 'expect') to transfer SPL(MLO)/u-boot The above option though is relatively slow, but at least for me it worked reliably. - Maybe you can boot from USB stick (I don't know what is your target SoC). > > > If yes (again) then maybe it would be better to only adjust (and > > replace) the default environment on board? > > > > For example: > > > > 1. You extract envs by using the scripts/get_default_envs.sh - > > modify it and then use mkenvimage to produce new env image. > > > > 2. You store u-boot (with NAND/eMMC not programmed) to your device. > > This u-boot has default environment with instructions for flashing. > > > > 3. You flash your final envs prepared in point 1. > > It seems that flashing the environment binary, or any other piece, > first requires something running on the target to accept the bits and > flash. Yes, correct. > Setting CONFIG_BOOTCOMMAND at compile time will do, but > ideally, I can use the same bootloader binary and decide the bootcmd > at deploy time. Personally, I would go for some script file (like boot.scr), which then would be imported to u-boot envs. That file can be also easily replaced at factory time, by just changing the file content. > > Thanks, > John Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de

1 0

[U-Boot] [PATCH v3 0/3] board: at91sam9x5ek: Convert to support DM and DT
by Wenyou Yang 12 Apr '17

12 Apr '17

The purpose of the patch set is to convert the board to support the driver model and device tree. It is based on the patch set: [PATCH v8 0/2] pinctrl: at91: Add pinctrl driver https://lists.denx.de/pipermail/u-boot/2017-March/284577.html Changes in v3: - Convert Atmel mci driver to support the driver model. - Remain the SPI_SPEED macro. - Add the support of Atmel uart device be used in the board_init_f stage. - Disable the SPL for nand config. - Improve the commit log. - Remove Atmel mci related code. - Use CONFIG_DEBUG_UART_CLOCK as the input clock for the early debug UART. - Drop [PATCH 4/5] configs: at91sam9x5ek: move SYS_NO_FLASH to defconfig. Changes in v2: - Rebase on the patch set: [RESEND PATCH v2] ARM: at91: add default config file for sama5d36ek CMP board http://lists.denx.de/pipermail/u-boot/2017-February/280525.html Wenyou Yang (3): configs: at91sam9x5ek: Update to support DM/DT board: at91sam9x5ek: Clean up code board: at91sam9x5ek: Enable early debug UART board/atmel/at91sam9x5ek/at91sam9x5ek.c | 82 ++++---------------------------- configs/at91sam9x5ek_dataflash_defconfig | 29 ++++++++++- configs/at91sam9x5ek_mmc_defconfig | 29 ++++++++++- configs/at91sam9x5ek_nandflash_defconfig | 35 +++++++++++--- configs/at91sam9x5ek_spiflash_defconfig | 36 ++++++++++---- include/configs/at91sam9x5ek.h | 25 +--------- 6 files changed, 123 insertions(+), 113 deletions(-) -- 2.11.0

1 3

[U-Boot] [PATCH v2 0/2] serial: atmel_usart: Fix uart init and add clk support
by Wenyou Yang 12 Apr '17

12 Apr '17

The patches is rework the uart init to fix the early debug not work in SPL, and add the clock support. Changes in v2: - Fix the DBGU clock handling. - Add Reviewed-by tag. Wenyou Yang (2): serial: atmel_usart: Fix early debug not work in SPL serial: atmel_usart: Add clk support drivers/serial/atmel_usart.c | 84 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 78 insertions(+), 6 deletions(-) -- 2.11.0

1 2

[U-Boot] qemu_mips - CONFIG_SYS_MONITOR_LEN is too small
by Kyle Edwards 11 Apr '17

11 Apr '17

Hi all, I recently tried to use u-boot on the qemu_mips platform, and running the saveenv command causes u-boot to not boot after a reset. I followed these steps: $ git clone git://git.denx.de/u-boot.git $ cd u-boot $ git checkout v2017.05-rc1 $ export CROSS_COMPILE=mips-linux-gnu- $ make qemu_mips_defconfig $ make $ dd if=/dev/zero of=../flash.bin bs=1k count=4k $ dd if=u-boot.bin of=../flash.bin bs=1k conv=notrunc $ qemu-system-mips -nographic -M mips -pflash ../flash.bin At this point I stopped autoboot, ran "saveenv" inside U-Boot, and reset qemu. After reset, U-Boot did not print any messages, and is stuck. I tracked this down to an invalid CONFIG_SYS_MONITOR_LEN. It's currently configured for 196608 (192 << 10), but running "ls -l u-boot.bin" shows a size of 232296. When the environment is being saved, it overwrites part of the U-Boot code. I am willing to write a patch for this bug, but I thought I would report it here first. Kyle

2 1

[U-Boot] [PATCH] sunxi: net: Use net_ops hooks to get the MAC
by Olliver Schinagl 11 Apr '17

11 Apr '17

This patch series is split off from my previous series, [PATCH v3] Retrieve MAC address from EEPROM and only adds, uses and fixes the read/write rom_hwaddr hooks. I changed things around as suggested by Hans. As far as I can tell this should work now as you described. The fdt_fixup_ethernet function should populate the environment as expected.

6 23

[U-Boot] [PATCH RFC 1/7] omap_hsmmc: update struct hsmmc to accommodate omap3 from DT
by Adam Ford 11 Apr '17

11 Apr '17

I am working on porting an OMAP3630 board to support device tree, and I attempted to change enable DM_MMC. Unfortunately, that broke MMC. I discovered that the base addresses were originally updated to reflect a change in the base address when using the device tree for some devices. This was done in 11e1582506c6 ("omap_hsmmc: update struct hsmmc to accomodate base address from DT") Unfortunately, this breaks the base address on an OMAP3630 (and I assume omap34xx) which currently doesn't have OF support yet. Without this patch, the when driver attemps to write to mmc_base->sysconfig at 4809c110 is used instead of mmc_base->sysconfig at 4809c010. This makes any attempt to use the mmc fail. With this patch, I am able to read/write to the MMC device with DM_MMC enabled with OF support. If there is a better solution, I am open to ideas. I verified this against the OMAP3530 TRM and OMAP3630 TRM. Since AM3359 TRM has the same value, it might be helpful for other boards, but I don't have them to test. If there is a better solution, I am perfectly open for suggestions. If this gets reviewed and approved, I can push the OMAP3630 (and OMAP3) device trees which might let more boards move to DM and OF support. Signed-off-by: Adam Ford <aford173(a)gmail.com> diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h index f2bf645..fd9b741 100644 --- a/arch/arm/include/asm/omap_mmc.h +++ b/arch/arm/include/asm/omap_mmc.h @@ -26,7 +26,7 @@ #define OMAP_MMC_H_ struct hsmmc { -#ifdef CONFIG_DM_MMC +#if defined(CONFIG_DM_MMC) && !defined(OMAP34XX) unsigned char res0[0x100]; #endif unsigned char res1[0x10]; -- 2.7.4

2 2

[U-Boot] [PATCH v6 1/3] arm: dts: update Meson GXBB / Odroid-C2 DT with latest Linux version
by felix zihlmann 11 Apr '17

11 Apr '17

Hi, I have tried this patch-set (applied to u-boot-2017.03) on a Odroid-C2. Booting from SD card works fine. However booting form eMMC card (128GB from Hardkernel) produces the following error: => fatload mmc 0:1 ${initrd_loadaddr} ${initrdfile} Card did not respond to voltage select! mmc_init: -95, time 9 ** Bad device mmc 0 ** Setting max-frequency to 60MHz does not help. Booting from the eMMC card using the Hardkernel u-boot and the Hardkernel kernel works fine. Thanks! Felix

2 2