April 2019 - U-Boot

[U-Boot] [PATCH] cros: Expand the Chromium OS documentation
by Simon Glass 13 Aug '19

13 Aug '19

The current documentation only covers how to chain-load U-Boot on a Chromebook. Add more information about the other ways to use U-Boot on Chromebooks. In particular it is again possible to build it with Chromium OS verified boot. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- doc/README.chromium | 296 ++++++++++++++-------------------- doc/README.chromium-chainload | 239 +++++++++++++++++++++++++++ 2 files changed, 356 insertions(+), 179 deletions(-) create mode 100644 doc/README.chromium-chainload diff --git a/doc/README.chromium b/doc/README.chromium index 45eaeced2d..096bc4f1f7 100644 --- a/doc/README.chromium +++ b/doc/README.chromium @@ -1,239 +1,177 @@ -Running U-Boot from coreboot on Chromebooks -=========================================== +Chromium OS Support in U-Boot +============================= -U-Boot can be used as a secondary boot loader in a few situations such as from -UEFI and coreboot (see README.x86). Recent Chromebooks use coreboot even on -ARM platforms to start up the machine. +Introduction +------------ -This document aims to provide a guide to booting U-Boot on a Chromebook. It -is only a starting point, and there are many guides on the interwebs. But -placing this information in the U-Boot tree should make it easier to find for -those who use U-Boot habitually. +This describes how to use U-Boot with Chromium OS. Several options are +available: -Most of these platforms are supported by U-Boot natively, but it is risky to -replace the ROM unless you have a servo board and cable to restore it with. + - Running U-Boot from the 'altfw' feature, which is available on selected + Chromebooks from 2019 onwards (initially Grunt). Press '1' from the + developer-mode screen to get into U-Boot. See here for details: + https://sites.google.com/a/chromium.org/dev/chromium-os/poking-around-your-… + - Running U-Boot from the disk partition. This involves signing U-Boot and + placing it on the disk, for booting as a 'kernel'. See + README.chromium-chainload for information on this. This is the only + option on non-U-Boot Chromebooks from 2013 to 2018 and is somewhat + more involved. -For all of these the standard U-Boot build instructions apply. For example on -ARM: + - Running U-Boot with Chromium OS verified boot. This allows U-Boot to be + used instead of either or both of depthcharge (a bootloader which forked + from U-Boot in 2013) and coreboot. See below for more information on + this. - sudo apt install gcc-arm-linux-gnueabi - mkdir b - make O=b/nyan_big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all -You can obtain the vbutil_kernel utility here: +U-Boot with Chromium OS verified boot +------------------------------------- - https://drive.google.com/open?id=0B7WYZbZ9zd-3dHlVVXo4VXE2T0U +To obtain: + git clone https://github.com/sglass68/u-boot.git + cd u-boot + git checkout cros-master -Snow (Samsung ARM Chromebook) ------------------------------ +To build for sandbox: -See here: + UB=/tmp/b/chromeos_sandbox # U-Boot build directory + CROS=/home/sglass/cosarm # Chromium OS directory + make O=$UB/chromeos_sandbox_defconfig + make O=$UB -j20 -s VBOOT_SOURCE=$CROS/src/platform/vboot_reference \ + MAKEFLAGS_VBOOT=DEBUG=1 QUIET=1 -https://www.chromium.org/chromium-os/firmware-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook +Replace sandbox with another supported target. +This produces $UB/image.bin which contains the firmware binaries in a SPI +flash image. -Nyan-big --------- - -Compiled based on information here: -https://lists.denx.de/pipermail/u-boot/2015-March/209530.html -https://git.collabora.com/cgit/user/tomeu/u-boot.git/commit/?h=nyan-big -https://lists.denx.de/pipermail/u-boot/2017-May/289491.html -https://github.com/chromeos-nvidia-androidtv/gnu-linux-on-acer-chromebook-13#copy-data-to-the-sd-card - -1. Build U-Boot - - mkdir b - make -j8 O=b/nyan-big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all - - -2. Select a .its file - -Select something from doc/chromium which matches your board, or create your -own. - -Note that the device tree node is required, even though it is not actually -used by U-Boot. This is because the Chromebook expects to pass it to the -kernel, and crashes if it is not present. - - -3. Build and sign an image - - ./b/nyan-big/tools/mkimage -f doc/chromium/nyan-big.its u-boot-chromium.fit - echo test >dummy.txt - vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \ - --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \ - --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \ - --bootloader dummy.txt --pack u-boot.kpart - - -4. Prepare an SD card - - DISK=/dev/sdc # Replace with your actual SD card device - sudo cgpt create $DISK - sudo cgpt add -b 34 -s 32768 -P 1 -S 1 -t kernel $DISK - sudo cgpt add -b 32802 -s 2000000 -t rootfs $DISK - sudo gdisk $DISK # Enter command 'w' to write a protective MBR to the disk - - -5. Write U-Boot to the SD card +To run on sandbox: - sudo dd if=u-boot.kpart of=/dev/sdc1; sync + $UB/tpl/u-boot-tpl -d $UB/u-boot.dtb.out \ + -L6 -c "host bind 0 $CROS/src/build/images/cheza/latest/chromiumos_image.bin; vboot go auto" \ + -l -w -s state.dtb -r +To run on other boards: + Install image.bin in the SPI flash of your device + Boot your system -6. Start it up -Reboot the device in dev mode. Make sure that you have USB booting enabled. To -do this, login as root (via Ctrl-Alt-forward_arrow) and type -'enable_dev_usb_boot'. You only need to do this once. +Sandbox +------- -Reboot the device with the SD card inserted. Press Clrl-U at the developer -mode screen. It should show something like the following on the display: +Most Chromium OS development with U-Boot is undertaken using sandbox. There is +a sandbox target available (chromeos_sandbox) which allows running U-Boot on +a Linux machine completion with emulations of the display, TPM, disk, etc. - U-Boot 2017.07-00637-g242eb42-dirty (May 22 2017 - 06:14:21 -0600) +Running sandbox starts TPL, which contains the first phase of vboot, providing +a device tree and binding a Chromium OS disk image for use to find kernels +(any Chromium OS image will do). It also saves driver state between U-Boot +phases into state.dtb and will automatically ensure that memory is shared +between all phases. TPL will jump to SPL and then on to U-Boot proper. - Model: Acer Chromebook 13 CB5-311 - Board: Google/NVIDIA Nyan-big, ID: 1 +It is possible to run with debugging on, e.g. - Net: No ethernet found. - Hit any key to stop autoboot: 0 - Tegra124 (Nyan-big) # + gdb --args $UB/tpl/u-boot-tpl -d .... +Breakpoints can be set in any U-Boot phase. Overall this is a good debugging +environment for new verified-boot features. -7. Known problems -On the serial console the word MMC is chopped at the start of the line: +Samus +----- -C: sdhci@700b0000: 2, sdhci@700b0400: 1, sdhci@700b0600: 0 +Basic support is available for samus, using the chromeos_samus target. If you +have an em100, use: -This is likely due to some problem with change-over of the serial driver -during relocation (or perhaps updating the clock setup in board_init()). + sudo em100 -s -c W25Q128FW -d $UB/image.bin -t -r +to write the image and then boot samus (Power-Refresh). -9. Notes -To check that you copied the u-boot.its file correctly, use these commands. -You should see that the data at 0x100 in u-boot-chromium.fit is the first few -bytes of U-Boot: +Boot flow +--------- - hd u-boot-chromium.fit |head -20 - ... - 00000100 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| +Verified boot starts in TPL, which selects the A or B SPL, which in turn selects +the A or B U-Boot. Then this jumps to the selected kernel. If anything goes +wrong, the device reboots and the recovery SPL and U-Boot are used instead. - hd b/nyan-big/u-boot.bin |head - 00000000 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| +More details are available here: + https://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-a… -The 'data' property of the FIT is set up to start at offset 0x100 bytes into -the file. The change to CONFIG_SYS_TEXT_BASE is also an offset of 0x100 bytes -from the load address. If this changes, you either need to modify U-Boot to be -fully relocatable, or expect it to hang. +New uclasses +------------ -chromebook_jerry ----------------- +Several uclasses are provided in cros/: -The instruction are similar to those for Nyan with changes as noted below: + UCLASS_CROS_AUX_FW Chrome OS auxiliary firmware + UCLASS_CROS_FWSTORE Chrome OS firmware storage + UCLASS_CROS_NVDATA Chrome OS non-volatile data device + UCLASS_CROS_VBOOT_EC Chrome OS vboot EC operations + UCLASS_CROS_VBOOT_FLAG Chrome OS verified boot flag -1. Patch U-Boot +The existing UCLASS_CROS_EC is also used. -Open include/configs/rk3288_common.h -Change: - -#define CONFIG_SYS_TEXT_BASE 0x00100000 - -to: - -#define CONFIG_SYS_TEXT_BASE 0x02000100 - - - -2. Build U-Boot - - mkdir b - make -j8 O=b/chromebook_jerry CROSS_COMPILE=arm-linux-gnueabi- \ - chromebook_jerry_defconfig all - - -3. See above - -4. Build and sign an image - - ./b/chromebook_jerry/tools/mkimage -f doc/chromium/chromebook_jerry.its \ - u-boot-chromium.fit - echo test >dummy.txt - vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \ - --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \ - --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \ - --bootloader dummy.txt --pack u-boot.kpart - - -5. See above +Commands +-------- -6. See above +A new 'vboot' command is provided to run particular vboot stages. The most +useful command is 'vboot go auto', which continues where the last stage left +off. -7. Start it up +Note that TPL and SPL do not supports commands as yet, so the vboot code is +called directly from the SPL boot devices (BOOT_DEVICE_CROS_VBOOT). See +cros_load_image_tpl() and cros_load_image_spl() which both call +vboot_run_auto(). -Reboot the device in dev mode. Make sure that you have USB booting enabled. To -do this, login as root (via Ctrl-Alt-forward_arrow) and type -'enable_dev_usb_boot'. You only need to do this once. -Reboot the device with the SD card inserted. Press Clrl-U at the developer -mode screen. It should show something like the following on the display: +Config options +-------------- - U-Boot 2017.05-00649-g72acdbf-dirty (May 29 2017 - 14:57:05 -0600) +The main option is CONFIG_CHROMEOS, which enables a wide array of other options +so that the required features are present. - Model: Google Jerry - Net: Net Initialization Skipped - No ethernet found. - Hit any key to stop autoboot: 0 +Device-tree config +------------------ -8. Known problems +Various options are available which control the operation of verified boot. +See cros/dts/bindings/config.txt for details. Most config is handled at run- +time, although build-time config (with Kconfig) could also be added fairly +easily. -None as yet. +Porting to other hardware +------------------------- -9. Notes +A basic port to samus (Chromebook Pixel 2015) is in a basic working state, +using the chromeos_samus target. Patches will likely be forthcoming in early +2019. Ports to an ARM board and coreboot (for x86 Chromebooks) are in the +dreaming state. -None as yet. +Tests +----- -Other notes -=========== +Chromium OS firmware has a very limited set of tests. The tests that originally +existed in U-Boot were not brought over to coreboot or depthcharge. -flashrom --------- +The U-Boot tests ('make check') do operate, but at present there are no +Chromium OS tests available. These will hopefully come together over time. Of +course the above sandbox feature provides a sort of functional test and can +detecte problems that affect the flow or particular vboot features. - Used to make a backup of your firmware, or to replace it. - See: https://www.chromium.org/chromium-os/packages/cros-flashrom +TO DO +----- +- Support for booting from coreboot (patches expected March 2019) +- Support for booting from an ARM board, e.g. bob -coreboot --------- -Coreboot itself is not designed to actually boot an OS. Instead, a program -called Depthcharge is used. This originally came out of U-Boot and was then -heavily hacked and modified such that is is almost unrecognisable. It does -include a very small part of the U-Boot command-line interface but is not -usable as a general-purpose boot loader. - -In addition, it has a very unusual design in that it does not do device init -itself, but instead relies on coreboot. This is similar to (in U-Boot) having -a SPI driver with an empty probe() method, relying on whatever was set up -beforehand. It can be quite hard to figure out between these two code bases -what settings are actually used. When chain-loading into U-Boot we must be -careful to reinit anything that U-Boot expects. If not, some peripherals (or -the whole machine) may not work. This makes the process of chainloading more -complicated than it could be on some platforms. - -Finally, it supports only a subset of the U-Boot's FIT format. In particular -it uses a fixed address to load the FIT and does not support load/exec -addresses. This means that U-Boot must be able to boot from whatever -address Depthcharge happens to use (it is the CONFIG_KERNEL_START setting -in Depthcharge). In practice this means that the data in the kernel@1 FIT node -(see above) must start at the same address as U-Boot's CONFIG_SYS_TEXT_BASE. +Simon Glass +sjg(a)chromium.org +7 October 2018 diff --git a/doc/README.chromium-chainload b/doc/README.chromium-chainload new file mode 100644 index 0000000000..45eaeced2d --- /dev/null +++ b/doc/README.chromium-chainload @@ -0,0 +1,239 @@ +Running U-Boot from coreboot on Chromebooks +=========================================== + +U-Boot can be used as a secondary boot loader in a few situations such as from +UEFI and coreboot (see README.x86). Recent Chromebooks use coreboot even on +ARM platforms to start up the machine. + +This document aims to provide a guide to booting U-Boot on a Chromebook. It +is only a starting point, and there are many guides on the interwebs. But +placing this information in the U-Boot tree should make it easier to find for +those who use U-Boot habitually. + +Most of these platforms are supported by U-Boot natively, but it is risky to +replace the ROM unless you have a servo board and cable to restore it with. + + +For all of these the standard U-Boot build instructions apply. For example on +ARM: + + sudo apt install gcc-arm-linux-gnueabi + mkdir b + make O=b/nyan_big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all + +You can obtain the vbutil_kernel utility here: + + https://drive.google.com/open?id=0B7WYZbZ9zd-3dHlVVXo4VXE2T0U + + +Snow (Samsung ARM Chromebook) +----------------------------- + +See here: + +https://www.chromium.org/chromium-os/firmware-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook + + +Nyan-big +-------- + +Compiled based on information here: +https://lists.denx.de/pipermail/u-boot/2015-March/209530.html +https://git.collabora.com/cgit/user/tomeu/u-boot.git/commit/?h=nyan-big +https://lists.denx.de/pipermail/u-boot/2017-May/289491.html +https://github.com/chromeos-nvidia-androidtv/gnu-linux-on-acer-chromebook-13#copy-data-to-the-sd-card + +1. Build U-Boot + + mkdir b + make -j8 O=b/nyan-big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all + + +2. Select a .its file + +Select something from doc/chromium which matches your board, or create your +own. + +Note that the device tree node is required, even though it is not actually +used by U-Boot. This is because the Chromebook expects to pass it to the +kernel, and crashes if it is not present. + + +3. Build and sign an image + + ./b/nyan-big/tools/mkimage -f doc/chromium/nyan-big.its u-boot-chromium.fit + echo test >dummy.txt + vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \ + --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \ + --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \ + --bootloader dummy.txt --pack u-boot.kpart + + +4. Prepare an SD card + + DISK=/dev/sdc # Replace with your actual SD card device + sudo cgpt create $DISK + sudo cgpt add -b 34 -s 32768 -P 1 -S 1 -t kernel $DISK + sudo cgpt add -b 32802 -s 2000000 -t rootfs $DISK + sudo gdisk $DISK # Enter command 'w' to write a protective MBR to the disk + + +5. Write U-Boot to the SD card + + sudo dd if=u-boot.kpart of=/dev/sdc1; sync + + +6. Start it up + +Reboot the device in dev mode. Make sure that you have USB booting enabled. To +do this, login as root (via Ctrl-Alt-forward_arrow) and type +'enable_dev_usb_boot'. You only need to do this once. + +Reboot the device with the SD card inserted. Press Clrl-U at the developer +mode screen. It should show something like the following on the display: + + U-Boot 2017.07-00637-g242eb42-dirty (May 22 2017 - 06:14:21 -0600) + + Model: Acer Chromebook 13 CB5-311 + Board: Google/NVIDIA Nyan-big, ID: 1 + + Net: No ethernet found. + Hit any key to stop autoboot: 0 + Tegra124 (Nyan-big) # + + +7. Known problems + +On the serial console the word MMC is chopped at the start of the line: + +C: sdhci@700b0000: 2, sdhci@700b0400: 1, sdhci@700b0600: 0 + +This is likely due to some problem with change-over of the serial driver +during relocation (or perhaps updating the clock setup in board_init()). + + +9. Notes + +To check that you copied the u-boot.its file correctly, use these commands. +You should see that the data at 0x100 in u-boot-chromium.fit is the first few +bytes of U-Boot: + + hd u-boot-chromium.fit |head -20 + ... + 00000100 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| + + hd b/nyan-big/u-boot.bin |head + 00000000 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| + + +The 'data' property of the FIT is set up to start at offset 0x100 bytes into +the file. The change to CONFIG_SYS_TEXT_BASE is also an offset of 0x100 bytes +from the load address. If this changes, you either need to modify U-Boot to be +fully relocatable, or expect it to hang. + + +chromebook_jerry +---------------- + +The instruction are similar to those for Nyan with changes as noted below: + +1. Patch U-Boot + +Open include/configs/rk3288_common.h + +Change: + +#define CONFIG_SYS_TEXT_BASE 0x00100000 + +to: + +#define CONFIG_SYS_TEXT_BASE 0x02000100 + + + +2. Build U-Boot + + mkdir b + make -j8 O=b/chromebook_jerry CROSS_COMPILE=arm-linux-gnueabi- \ + chromebook_jerry_defconfig all + + +3. See above + +4. Build and sign an image + + ./b/chromebook_jerry/tools/mkimage -f doc/chromium/chromebook_jerry.its \ + u-boot-chromium.fit + echo test >dummy.txt + vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \ + --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \ + --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \ + --bootloader dummy.txt --pack u-boot.kpart + + +5. See above + +6. See above + +7. Start it up + +Reboot the device in dev mode. Make sure that you have USB booting enabled. To +do this, login as root (via Ctrl-Alt-forward_arrow) and type +'enable_dev_usb_boot'. You only need to do this once. + +Reboot the device with the SD card inserted. Press Clrl-U at the developer +mode screen. It should show something like the following on the display: + + U-Boot 2017.05-00649-g72acdbf-dirty (May 29 2017 - 14:57:05 -0600) + + Model: Google Jerry + Net: Net Initialization Skipped + No ethernet found. + Hit any key to stop autoboot: 0 + + +8. Known problems + +None as yet. + + +9. Notes + +None as yet. + + +Other notes +=========== + +flashrom +-------- + + Used to make a backup of your firmware, or to replace it. + + See: https://www.chromium.org/chromium-os/packages/cros-flashrom + + +coreboot +-------- + +Coreboot itself is not designed to actually boot an OS. Instead, a program +called Depthcharge is used. This originally came out of U-Boot and was then +heavily hacked and modified such that is is almost unrecognisable. It does +include a very small part of the U-Boot command-line interface but is not +usable as a general-purpose boot loader. + +In addition, it has a very unusual design in that it does not do device init +itself, but instead relies on coreboot. This is similar to (in U-Boot) having +a SPI driver with an empty probe() method, relying on whatever was set up +beforehand. It can be quite hard to figure out between these two code bases +what settings are actually used. When chain-loading into U-Boot we must be +careful to reinit anything that U-Boot expects. If not, some peripherals (or +the whole machine) may not work. This makes the process of chainloading more +complicated than it could be on some platforms. + +Finally, it supports only a subset of the U-Boot's FIT format. In particular +it uses a fixed address to load the FIT and does not support load/exec +addresses. This means that U-Boot must be able to boot from whatever +address Depthcharge happens to use (it is the CONFIG_KERNEL_START setting +in Depthcharge). In practice this means that the data in the kernel@1 FIT node +(see above) must start at the same address as U-Boot's CONFIG_SYS_TEXT_BASE. -- 2.20.1.495.gaa96b0ce6b-goog

2 4

[U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine
by Anup Patel 07 Aug '19

07 Aug '19

This patchset enables Cadance MACB ethernet driver for QEMU sifive_u machine. The Cadance MACB ethernet driver works fine for QEMU sifive_u machince in both M-mode and S-mode with some minor fixes. The patches are based upon latest RISC-V U-Boot tree (git://git.denx.de/u-boot-riscv.git) at commit id 9deb8d2fcd13d4a40a4e63c396fe4376af46efac To try on QEMU, please ensure following patches are applied to QEMU sources: https://patchwork.kernel.org/patch/10729579/ https://patchwork.kernel.org/patch/10729581/ Anup Patel (3): riscv: Add asm/dma-mapping.h for DMA mappings net: macb: Fix clk API usage for RISC-V systems riscv: qemu: Imply MACB ethernet for emulation arch/riscv/include/asm/dma-mapping.h | 37 ++++++++++++++++++++++++++++ board/emulation/qemu-riscv/Kconfig | 4 +++ drivers/net/macb.c | 4 ++- 3 files changed, 44 insertions(+), 1 deletion(-) create mode 100644 arch/riscv/include/asm/dma-mapping.h -- 2.17.1

2 25

[U-Boot] [PATCH 2/2] efi_loader: set the dhcp ack received flag
by Patrick Wildt 06 Aug '19

06 Aug '19

The PXE object contains a flag that specifies whether or not a DHCP ACK has been received. This can be used by EFI Applications to find out whether or not it is worth to read the DHCP information from our object. Signed-off-by: Patrick Wildt <patrick(a)blueri.se> --- lib/efi_loader/efi_net.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c index 8c5d5b492c..0b9c7b9345 100644 --- a/lib/efi_loader/efi_net.c +++ b/lib/efi_loader/efi_net.c @@ -332,8 +332,10 @@ int efi_net_register(void) netobj->net_mode.max_packet_size = PKTSIZE; netobj->pxe.mode = &netobj->pxe_mode; - if (dhcp_ack) + if (dhcp_ack) { netobj->pxe_mode.dhcp_ack = *dhcp_ack; + netobj->pxe_mode.dhcp_ack_received = 1; + } /* * Create WaitForPacket event. -- 2.14.3 (Apple Git-98)

5 19

[U-Boot] [PATCH 0/10] x86: Add generic VESA video driver
by Simon Glass 01 Aug '19

01 Aug '19

This series introduces a generic VESA video driver and adjusts the generic PCI ROM support to support it. It also fixes up some problems which prevent this from working on PowerPC at present. It is now possible to use VESA graphics: - On PowerPC, using the x86 emulator - On x86, using either the x86 emulator or native code execution As it turns out, on the only platform I have tested (link), the x86 emulator is only slightly slower that native code execution (200ms difference). Still, we may as well leave this feature in there. VGA ROMs are a very old technology but they are still used by modern platforms, including at least link and some Atom designs. Simon Glass (10): bios_emulator: Fix an #ifdef typo in the header file x86: Correct endianness isues in pci_rom x86: Support ROMs on other archs bios_emulator: Don't display error when emulator terminates bios_emulator: Add some VESA interface debugging x86: pci: Don't stop when we get a vendor/device mismatch x86: Add a VESA video driver x86: Drop the x86_fb driver x86: Access the VGA ROM when needed RFC: Test code for glacier PCI video support arch/x86/include/asm/u-boot-x86.h | 2 + drivers/bios_emulator/atibios.c | 161 +++++++++++++++++++++++---- drivers/bios_emulator/include/x86emu/debug.h | 2 +- drivers/bios_emulator/x86emu/ops.c | 2 +- drivers/pci/pci_auto.c | 28 ++++- drivers/pci/pci_rom.c | 40 ++++--- drivers/video/Makefile | 2 +- drivers/video/vesa_fb.c | 64 +++++++++++ drivers/video/x86_fb.c | 38 ------- include/configs/canyonlands.h | 31 ++++++ include/configs/chromebook_link.h | 2 +- include/pci.h | 9 ++ include/pci_rom.h | 1 - include/vbe.h | 9 +- 14 files changed, 312 insertions(+), 79 deletions(-) create mode 100644 drivers/video/vesa_fb.c delete mode 100644 drivers/video/x86_fb.c -- 2.2.0.rc0.207.ga3a616c

3 42

[U-Boot] [PATCH 0/4] Veyron Speedy / ASUS C201 fixes
by Urja Rannikko 30 Jul '19

30 Jul '19

Hi, Just saying: I'm not familiar with this stuff so i might've misunderstood something in my commit messages, but anyways i managed to make it boot. There's more stuff than just these, but i decided I'd keep it short... If you want to know my full setup, you can check out my gh repo for now: https://github.com/urjaman/u-boot/commits/c201-stuff Notably I did include http://patchwork.ozlabs.org/patch/1040541/ in my tree when testing (rk3288 pinctrl patch that was linked to on the previous thread i found about the veyron speedy being broken). The one thing that I havent yet fixed is that the USB host port on the otg-capable controller (near screen) doesn't work - one guess i have is that the dwc2 host driver doesn't force it into host mode... (It doesn't even read dr_mode ...) Urja Rannikko (4): pinctrl: exit pinconfig_post_bind if there are no subnodes rk3288-board: remove pinctrl call for debug uart rk3288-board: cosmetic: document selecting RK PWM dw_mmc: turn on the IO supply arch/arm/mach-rockchip/rk3288-board.c | 13 +------------ drivers/mmc/dw_mmc.c | 15 +++++++++++++++ drivers/pinctrl/pinctrl-uclass.c | 3 +++ 3 files changed, 19 insertions(+), 12 deletions(-) -- 2.21.0

7 30

[U-Boot] [PATCH v2 0/4] efi_loader: rework loading and starting of images
by Heinrich Schuchardt 19 Jul '19

19 Jul '19

This patch series starts the necessary changes needed to correctly implement the unloading of images in Exit(). If we want to properly unload images in Exit() the memory should always be allocated in the same way. As we allocate memory when reading from file we should do the same when the original image is in memory. Up to now efi_load_pe() returns the entry point or NULL in case of an error. This does not allow to return correct error codes from LoadImage(). Let efi_load_pe() return a status code and fill in the entry point in the corresponding field of the image object. Remove the duplicate code in efi_do_enter() and use efi_start_image() to start the image invoked by the bootefi command. Clean up bootefi_test_prepare(). Further patches will be needed: - use LoadImage() in bootefi and bootmgr - implement correct unloading of images in Exit() Heinrich Schuchardt (4): efi_loader: LoadImage: always allocate new pages efi_loader: set entry point in efi_load_pe() efi_loader: use efi_start_image() for bootefi efi_loader: clean up bootefi_test_prepare() cmd/bootefi.c | 91 ++++++++++-------------- include/efi_loader.h | 10 ++- lib/efi_loader/efi_bootmgr.c | 2 +- lib/efi_loader/efi_boottime.c | 112 ++++++++++++++++++++---------- lib/efi_loader/efi_image_loader.c | 37 +++++----- 5 files changed, 141 insertions(+), 111 deletions(-) -- 2.20.1

4 16

[U-Boot] [PATCH] arm: ti: boot: Increase system partition size
by Sam Protsenko 16 Jul '19

16 Jul '19

Android code base is growing, so since Android "Pie" the size of system.img grew up to be about 740 MiB. Let's increase system.img to 1 GiB to accommodate for those changes and leave some margin for future changes. We don't want to make it more than 1 GiB, because we should keep userdata partition big enough (for user files, like media etc.), and eMMC size on BeagleBoard-X15 is only 3.5 GiB. Signed-off-by: Sam Protsenko <semen.protsenko(a)linaro.org> --- include/environment/ti/boot.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/environment/ti/boot.h b/include/environment/ti/boot.h index 5891009a5a..86ff6d3ea7 100644 --- a/include/environment/ti/boot.h +++ b/include/environment/ti/boot.h @@ -41,7 +41,7 @@ "name=crypto,size=16K,uuid=${uuid_gpt_crypto};" \ "name=recovery,size=40M,uuid=${uuid_gpt_recovery};" \ "name=boot,size=10M,uuid=${uuid_gpt_boot};" \ - "name=system,size=768M,uuid=${uuid_gpt_system};" \ + "name=system,size=1024M,uuid=${uuid_gpt_system};" \ "name=vendor,size=256M,uuid=${uuid_gpt_vendor};" \ "name=cache,size=256M,uuid=${uuid_gpt_cache};" \ "name=ipu1,size=1M,uuid=${uuid_gpt_ipu1};" \ -- 2.19.1

4 7

[U-Boot] [PATCH] arm: ti: boot: Remove legacy Android partitions
by Sam Protsenko 16 Jul '19

16 Jul '19

Remove unused Android partitions: - efs, crypto, cache: we don't use it anymore (images are not built in AOSP - ipu1, ipu2: IPU firmware is now a part of vendor image and doesn't reside as a separate partition While at it, rename "reserved" partition to "uboot-env", as it's actually stores U-Boot environment. Signed-off-by: Sam Protsenko <semen.protsenko(a)linaro.org> --- include/environment/ti/boot.h | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/include/environment/ti/boot.h b/include/environment/ti/boot.h index 86ff6d3ea7..05bdbbc23e 100644 --- a/include/environment/ti/boot.h +++ b/include/environment/ti/boot.h @@ -35,17 +35,12 @@ "uuid_disk=${uuid_gpt_disk};" \ "name=xloader,start=128K,size=256K,uuid=${uuid_gpt_xloader};" \ "name=bootloader,size=2048K,uuid=${uuid_gpt_bootloader};" \ - "name=reserved,start=2432K,size=256K,uuid=${uuid_gpt_reserved};" \ + "name=uboot-env,start=2432K,size=256K,uuid=${uuid_gpt_reserved};" \ "name=misc,size=128K,uuid=${uuid_gpt_misc};" \ - "name=efs,size=16M,uuid=${uuid_gpt_efs};" \ - "name=crypto,size=16K,uuid=${uuid_gpt_crypto};" \ "name=recovery,size=40M,uuid=${uuid_gpt_recovery};" \ "name=boot,size=10M,uuid=${uuid_gpt_boot};" \ "name=system,size=1024M,uuid=${uuid_gpt_system};" \ "name=vendor,size=256M,uuid=${uuid_gpt_vendor};" \ - "name=cache,size=256M,uuid=${uuid_gpt_cache};" \ - "name=ipu1,size=1M,uuid=${uuid_gpt_ipu1};" \ - "name=ipu2,size=1M,uuid=${uuid_gpt_ipu2};" \ VBMETA_PART \ "name=userdata,size=-,uuid=${uuid_gpt_userdata}" #endif /* PARTS_DEFAULT */ -- 2.19.2

4 3

[U-Boot] [PATCH] phy: sun4i-usb: Fix PHY0 routing and passby configuration for MUSB
by Paul Kocialkowski 15 Jul '19

15 Jul '19

Recent Allwinner platforms (starting with the H3) only use the MUSB controller for peripheral mode and use HCI for host mode. As a result, extra steps need to be taken to properly route USB signals to one or the other. More precisely, the following is required: * Routing the pins to either HCI/MUSB (controlled by PHY); * Enabling USB PHY passby in HCI mode (controlled by PMU). The current code will enable passby for each PHY and reroute PHY0 to MUSB, which is inconsistent and results in broken USB peripheral support. Passby on PHY0 must only be enabled when we want to use HCI. Since host/device mode detection is not available from the PHY code and because U-Boot does not support changing the mode dynamically anyway, we can just mux the controller to MUSB if it is enabled and mux it to HCI otherwise. This fixes USB peripheral support for platforms with PHY0 dual-route, especially H3/H5 and V3s. Signed-off-by: Paul Kocialkowski <paul.kocialkowski(a)bootlin.com> --- drivers/phy/allwinner/phy-sun4i-usb.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c index f206fa3f5d48..4f1c7e519d71 100644 --- a/drivers/phy/allwinner/phy-sun4i-usb.c +++ b/drivers/phy/allwinner/phy-sun4i-usb.c @@ -302,9 +302,21 @@ static int sun4i_usb_phy_init(struct phy *phy) data->cfg->disc_thresh, PHY_DISCON_TH_LEN); } +#ifdef CONFIG_USB_MUSB_SUNXI + /* Needed for HCI and conflicts with MUSB, keep PHY0 on MUSB */ + if (usb_phy->id != 0) + sun4i_usb_phy_passby(phy, true); + + /* Route PHY0 to MUSB to allow USB gadget */ + if (data->cfg->phy0_dual_route) + sun4i_usb_phy0_reroute(data, true); +#else sun4i_usb_phy_passby(phy, true); - sun4i_usb_phy0_reroute(data, true); + /* Route PHY0 to HCI to allow USB host */ + if (data->cfg->phy0_dual_route) + sun4i_usb_phy0_reroute(data, false); +#endif return 0; } -- 2.20.1

4 10

[U-Boot] [PATCH 1/2] board: pm9261: Convert to CONFIG_DM_USB and CONFIG_DM_VIDEO
by Ilko Iliev 14 Jul '19

14 Jul '19

Convert the board to support the USB and video driver model and remove the unnecessary code. --- board/ronetix/pm9261/pm9261.c | 105 ---------------------------------- configs/pm9261_defconfig | 3 + 2 files changed, 3 insertions(+), 105 deletions(-) diff --git a/board/ronetix/pm9261/pm9261.c b/board/ronetix/pm9261/pm9261.c index 0c7b4ee415..f1e7aab629 100644 --- a/board/ronetix/pm9261/pm9261.c +++ b/board/ronetix/pm9261/pm9261.c @@ -17,9 +17,6 @@ #include <asm/arch/at91_matrix.h> #include <asm/arch/clk.h> #include <asm/arch/gpio.h> - -#include <lcd.h> -#include <atmel_lcdc.h> #if defined(CONFIG_RESET_PHY_R) && defined(CONFIG_DRIVER_DM9000) #include <net.h> #endif @@ -110,105 +107,6 @@ static void pm9261_dm9000_hw_init(void) } #endif -#ifdef CONFIG_LCD -vidinfo_t panel_info = { - .vl_col = 240, - .vl_row = 320, - .vl_clk = 4965000, - .vl_sync = ATMEL_LCDC_INVLINE_INVERTED | - ATMEL_LCDC_INVFRAME_INVERTED, - .vl_bpix = 3, - .vl_tft = 1, - .vl_hsync_len = 5, - .vl_left_margin = 1, - .vl_right_margin = 33, - .vl_vsync_len = 1, - .vl_upper_margin = 1, - .vl_lower_margin = 0, - .mmio = ATMEL_BASE_LCDC, -}; - -void lcd_enable(void) -{ - at91_set_pio_value(AT91_PIO_PORTA, 22, 0); /* power up */ -} - -void lcd_disable(void) -{ - at91_set_pio_value(AT91_PIO_PORTA, 22, 1); /* power down */ -} - -static void pm9261_lcd_hw_init(void) -{ - at91_set_a_periph(AT91_PIO_PORTB, 1, 0); /* LCDHSYNC */ - at91_set_a_periph(AT91_PIO_PORTB, 2, 0); /* LCDDOTCK */ - at91_set_a_periph(AT91_PIO_PORTB, 3, 0); /* LCDDEN */ - at91_set_a_periph(AT91_PIO_PORTB, 4, 0); /* LCDCC */ - at91_set_a_periph(AT91_PIO_PORTB, 7, 0); /* LCDD2 */ - at91_set_a_periph(AT91_PIO_PORTB, 8, 0); /* LCDD3 */ - at91_set_a_periph(AT91_PIO_PORTB, 9, 0); /* LCDD4 */ - at91_set_a_periph(AT91_PIO_PORTB, 10, 0); /* LCDD5 */ - at91_set_a_periph(AT91_PIO_PORTB, 11, 0); /* LCDD6 */ - at91_set_a_periph(AT91_PIO_PORTB, 12, 0); /* LCDD7 */ - at91_set_a_periph(AT91_PIO_PORTB, 15, 0); /* LCDD10 */ - at91_set_a_periph(AT91_PIO_PORTB, 16, 0); /* LCDD11 */ - at91_set_a_periph(AT91_PIO_PORTB, 17, 0); /* LCDD12 */ - at91_set_a_periph(AT91_PIO_PORTB, 18, 0); /* LCDD13 */ - at91_set_a_periph(AT91_PIO_PORTB, 19, 0); /* LCDD14 */ - at91_set_a_periph(AT91_PIO_PORTB, 20, 0); /* LCDD15 */ - at91_set_b_periph(AT91_PIO_PORTB, 23, 0); /* LCDD18 */ - at91_set_b_periph(AT91_PIO_PORTB, 24, 0); /* LCDD19 */ - at91_set_b_periph(AT91_PIO_PORTB, 25, 0); /* LCDD20 */ - at91_set_b_periph(AT91_PIO_PORTB, 26, 0); /* LCDD21 */ - at91_set_b_periph(AT91_PIO_PORTB, 27, 0); /* LCDD22 */ - at91_set_b_periph(AT91_PIO_PORTB, 28, 0); /* LCDD23 */ - - at91_system_clk_enable(AT91_PMC_HCK1); - - gd->fb_base = ATMEL_BASE_SRAM; -} - -#ifdef CONFIG_LCD_INFO -#include <nand.h> -#include <version.h> - -extern flash_info_t flash_info[]; - -void lcd_show_board_info(void) -{ - ulong dram_size, nand_size, flash_size; - int i; - char temp[32]; - - lcd_printf ("%s\n", U_BOOT_VERSION); - lcd_printf ("(C) 2009 Ronetix GmbH\n"); - lcd_printf ("support(a)ronetix.at\n"); - lcd_printf ("%s CPU at %s MHz", - CONFIG_SYS_AT91_CPU_NAME, - strmhz(temp, get_cpu_clk_rate())); - - dram_size = 0; - for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) - dram_size += gd->bd->bi_dram[i].size; - - nand_size = 0; - for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++) - nand_size += get_nand_dev_by_index(i)->size; - - flash_size = 0; - for (i = 0; i < CONFIG_SYS_MAX_FLASH_BANKS; i++) - flash_size += flash_info[i].size; - - lcd_printf ("%ld MB SDRAM, %ld MB NAND\n%ld MB NOR Flash\n" - "%ld MB DataFlash\n", - dram_size >> 20, - nand_size >> 20, - flash_size >> 20); -} -#endif /* CONFIG_LCD_INFO */ - -#endif /* CONFIG_LCD */ - int board_early_init_f(void) { return 0; @@ -227,9 +125,6 @@ int board_init(void) #endif #ifdef CONFIG_DRIVER_DM9000 pm9261_dm9000_hw_init(); -#endif -#ifdef CONFIG_LCD - pm9261_lcd_hw_init(); #endif return 0; } diff --git a/configs/pm9261_defconfig b/configs/pm9261_defconfig index d2c4c25672..34e05f0395 100644 --- a/configs/pm9261_defconfig +++ b/configs/pm9261_defconfig @@ -30,6 +30,7 @@ CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="at91sam9261ek" CONFIG_ENV_IS_IN_FLASH=y CONFIG_DM=y +CONFIG_BLK=y CONFIG_CLK=y CONFIG_CLK_AT91=y CONFIG_DM_GPIO=y @@ -51,5 +52,7 @@ CONFIG_ATMEL_USART=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_USB=y +CONFIG_DM_USB=y CONFIG_USB_STORAGE=y CONFIG_LCD=y +CONFIG_DM_VIDEO=y -- 2.17.1

2 3