From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: masami.hiramatsu@linaro.org, u-boot@lists.denx.de,
sjg@chromium.org, ilias.apalodimas@linaro.org,
Tom Rini <trini@konsulko.com>
Subject: Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
Date: Wed, 27 Apr 2022 12:26:09 +0900 [thread overview]
Message-ID: <20220427032609.GA34649@laputa> (raw)
In-Reply-To: <3e6309ed-7899-aa91-b0fb-a46ea3fa4743@gmx.de>
Heinrich,
On Tue, Apr 26, 2022 at 07:02:46PM +0200, Heinrich Schuchardt wrote:
> On 4/26/22 16:44, AKASHI Takahiro wrote:
> > On Tue, Apr 26, 2022 at 03:57:26PM +0200, Heinrich Schuchardt wrote:
> >> On 4/26/22 01:44, AKASHI Takahiro wrote:
> >> I expect that boards that booted with previous versions of U-Boot using
> >> the respective defconfig still boot. But they don't. Here is one example
> >> (orangepi_pc_defconfig):
> >>
> >> Found U-Boot script /boot.scr.uimg
> >> 189 bytes read in 2 ms (91.8 KiB/s)
> >> ## Executing script at 43100000
> >> 22979 bytes read in 8 ms (2.7 MiB/s)
> >> 98304 bytes read in 8 ms (11.7 MiB/s)
> >> Booting /EFI\debian\grubarm.efi
> >> Welcome to GRUB!
> >>
> >> error: disk `,msdos2' not found.
> >> grub rescue>
> >>
> >> In U-Boot v2022.04 function efi_disk_register() ensured that all block
> >> devices and their partitions were added as EFI handles.
> > Not the all block devices, but the block devices which have already
> > enumerated when efi_init_obj_list() is called.
> >
> >> But that
> >> function is missing now.
> > What (boot) device are you using here?
> >
> > Please show me the values of env variables, particularly, "boot_targets".
> >
> > Please show me the content of boot.scr.uimg, too.
> >
> > Please show me the output from
> > => dm tree
> > => efidebug devices
> > for 2022.04 and 2022.07-rc1.
> >
> > -Takahiro Akashi
> >
> >
> >
>
>
> I am booting from mmc. Boot.scr just loads the device-tree from mmc-
>
> mmcblk0 179:0 0 29.8G 0 disk
> ├─mmcblk0p1 179:1 0 1G 0 part /boot/efi
> ├─mmcblk0p2 179:2 0 1G 0 part /boot
> └─mmcblk0p3 179:3 0 27.8G 0 part /
Okay.
>
> U-Boot 2022.04 (Apr 26 2022 - 16:02:27 +0000) Allwinner Technology
> ------------------------------------------------------------------
>
> grub> ls
> (hd0) (hd0,msdos1) (hd1) (hd1,msdos3) (hd1,msdos2) (hd1,msdos1)
>
> hd0 is a USB stick
> hd1 is the SD card
>
> boot.scr
> --------
>
> #
> # flash-kernel: bootscr.sunxi
> #
>
> # boot script for Allwinner SunXi-based devices
>
> # Mainline u-boot v2014.10 introduces a new default environment and
> # a new common bootcmd handling for all platforms, which is not fully
> # compatible with the old-style environment used by u-boot-sunxi.
> # This script therefore needs to check in which environment it
> # is running and set some variables accordingly.
>
> # On u-boot-sunxi, this script assumes that ${device} and ${partition}
> # are set.
>
> # The new-style environment predefines ${boot_targets}, the old-style
> # environment does not.
> if test -n "${boot_targets}"
> then
> echo "Mainline u-boot / new-style environment detected."
> # Mainline u-boot v2014.10 uses ${devtype}, ${devnum} and
> # ${bootpart} where u-boot-sunxi uses ${device} and ${partition}.
> # ${distro_bootpart} replaced ${bootpart} in u-boot v2016.01.
> if test -z "${device}"; then setenv device "${devtype}"; fi
> if test -z "${partition}${distro_bootpart}"; then setenv partition
> "${devnum}:${bootpart}"; fi
> if test -z "${partition}"; then setenv partition
> "${devnum}:${distro_bootpart}"; fi
> else
> echo "U-boot-sunxi / old-style environment detected."
> # U-boot-sunxi does not predefine kernel_addr_r, fdt_addr_r and
> # ramdisk_addr_r, so they have to be manually set. Use the values
> # from mainline u-boot v2014.10, except for ramdisk_addr_r,
> # which is set to 0x44300000 to allow for initrds larger than
> # 13MB on u-boot-sunxi.
> setenv kernel_addr_r 0x42000000
> setenv fdt_addr_r 0x43000000
> setenv ramdisk_addr_r 0x44300000
> fi
>
> if test -n "${console}"; then
> setenv bootargs "${bootargs} console=${console}"
> fi
>
> setenv bootargs ${bootargs} quiet
>
>
> if test -z "${image_locations}"; then
> setenv image_locations ${prefix}
> fi
> if test -z "${image_locations}"; then
> setenv image_locations /boot/ /
> fi
>
> if test -z "${fk_kvers}"; then
> setenv fk_kvers '5.16.0-4-armmp-lpae'
> fi
>
> if test -n "${fdtfile}"; then
> setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
> else
> setenv fdtpath dtb-${fk_kvers}
> fi
>
> for pathprefix in ${image_locations}
> do
> if test -e ${device} ${partition} ${pathprefix}vmlinuz-${fk_kvers}
> then
> load ${device} ${partition} ${kernel_addr_r}
> ${pathprefix}vmlinuz-${fk_kvers} \
> && load ${device} ${partition} ${fdt_addr_r} ${pathprefix}${fdtpath} \
> && load ${device} ${partition} ${ramdisk_addr_r}
> ${pathprefix}initrd.img-${fk_kvers} \
> && echo "Booting Debian ${fk_kvers} from ${device} ${partition}..." \
> && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
> fi
> done
Nothing special done here.
>
> U-Boot 2022.04 (Apr 26 2022 - 16:02:27 +0000) Allwinner Technology
>
> => echo $boot_targets
> fel mmc0 usb0 pxe dhcp
>
> => dm tree
> Class Index Probed Driver Name
> -----------------------------------------------------------
> root 0 [ + ] root_driver root_driver
> video 0 [ ] sunxi_de2 |-- sunxi_de2
> display 0 [ ] sunxi_dw_hdmi |-- sunxi_dw_hdmi
> simple_bus 0 [ + ] simple_bus |-- soc
> mmc 0 [ + ] sunxi_mmc | |-- mmc@1c0f000
> blk 0 [ + ] mmc_blk | | `-- mmc@1c0f000.blk
> phy 0 [ + ] sun4i_usb_phy | |-- phy@1c19400
> usb 0 [ + ] ehci_generic | |-- usb@1c1a000
> usb_hub 0 [ + ] usb_hub | | `-- usb_hub
> usb 1 [ + ] ohci_generic | |-- usb@1c1a400
> usb_hub 1 [ + ] usb_hub | | `-- usb_hub
> usb 2 [ + ] ehci_generic | |-- usb@1c1b000
> usb_hub 2 [ + ] usb_hub | | `-- usb_hub
> usb 3 [ + ] ohci_generic | |-- usb@1c1b400
> usb_hub 3 [ + ] usb_hub | | `-- usb_hub
> usb 4 [ + ] ehci_generic | |-- usb@1c1c000
> usb_hub 4 [ + ] usb_hub | | `-- usb_hub
> usb_mass_s 0 [ + ] usb_mass_storage | | `--
> usb_mass_storage
> blk 1 [ ] usb_storage_blk | | `--
> usb_mass_storage.lun0
> usb 5 [ + ] ohci_generic | |-- usb@1c1c400
> usb_hub 5 [ + ] usb_hub | | `-- usb_hub
> usb 6 [ + ] ehci_generic | |-- usb@1c1d000
> usb_hub 6 [ + ] usb_hub | | `-- usb_hub
> usb 7 [ + ] ohci_generic | |-- usb@1c1d400
> usb_hub 7 [ + ] usb_hub | | `-- usb_hub
> clk 0 [ + ] sun8i_h3_ccu | |-- clock@1c20000
> reset 0 [ + ] sunxi_reset | | `-- reset
> gpio 0 [ + ] gpio_sunxi | |-- pinctrl@1c20800
> gpio 1 [ + ] gpio_sunxi | | |-- PA
> gpio 2 [ + ] gpio_sunxi | | |-- PB
> gpio 3 [ + ] gpio_sunxi | | |-- PC
> gpio 4 [ + ] gpio_sunxi | | |-- PD
> gpio 5 [ + ] gpio_sunxi | | |-- PE
> gpio 6 [ + ] gpio_sunxi | | |-- PF
> gpio 7 [ + ] gpio_sunxi | | |-- PG
> gpio 8 [ + ] gpio_sunxi | | |-- PH
> gpio 9 [ + ] gpio_sunxi | | `-- PI
> ethernet 0 [ + ] eth_sun8i_emac | |-- ethernet@1c30000
> watchdog 0 [ + ] sunxi_wdt | |-- watchdog@1c20ca0
> sysreset 0 [ ] wdt_reboot | | `-- watchdog@1c20ca0
> serial 0 [ + ] ns16550_serial | |-- serial@1c28000
> clk 1 [ + ] clk_sun6i_rtc | |-- rtc@1f00000
> clk 2 [ ] sun6i_a31_r_ccu | |-- clock@1f01400
> reset 1 [ ] sunxi_reset | | `-- reset
> i2c 0 [ ] i2c_mvtwsi | |-- i2c@1f02400
> gpio 10 [ + ] gpio_sunxi | `-- pinctrl@1f02c00
> gpio 11 [ + ] gpio_sunxi | `-- PL
> clk 3 [ + ] fixed_clock |-- osc24M_clk
> clk 4 [ ] fixed_clock `-- osc32k_clk
>
>
>
> U-Boot 2022.07-rc1 (Apr 26 2022 - 07:00:52 +0000) Allwinner Technology
>
> => echo $boot_targets
> fel mmc0 usb0 pxe dhcp
>
> => dm tree
> Class Index Probed Driver Name
> -----------------------------------------------------------
> root 0 [ + ] root_driver root_driver
> video 0 [ ] sunxi_de2 |-- sunxi_de2
> display 0 [ ] sunxi_dw_hdmi |-- sunxi_dw_hdmi
> simple_bus 0 [ + ] simple_bus |-- soc
> mmc 0 [ + ] sunxi_mmc | |-- mmc@1c0f000
> blk 0 [ + ] mmc_blk | | |-- mmc@1c0f000.blk
A block device detected here.
> partition 0 [ + ] blk_partition | | | |--
> mmc@1c0f000.blk:1
> partition 1 [ + ] blk_partition | | | |--
> mmc@1c0f000.blk:2
> partition 2 [ + ] blk_partition | | | `--
> mmc@1c0f000.blk:3
Apparently, there are three partition devices,
then we should definitely have corresponding efi_disk objects
as an efi_loader hook is registered against *POST_PROBE* event
(of a *block* device).
In my patch c822c1a50bd7 ("mmc: call device_probe() after scanning"),
device_probe() has already been installed to mmc_blk_probe().
Thinking of those circumstances, the natural guess is a *probe* function
for "mmc@1c0f000.blk" device has never been called in your use case
(even when loading an image from a specific partition, /boot/efi?).
To confirm this, you may simply try the followings:
=> mmc list
...
=> mmc dev 0 (<- the device number from 'mmc list')
=> efi devices
Then you will find three more efi_disk objects now that the parent
block device is *probed*.
> bootdev 0 [ ] mmc_bootdev | | `--
> mmc@1c0f000.bootdev
> phy 0 [ + ] sun4i_usb_phy | |-- phy@1c19400
> usb 0 [ + ] ehci_generic | |-- usb@1c1a000
> usb_hub 0 [ + ] usb_hub | | `-- usb_hub
> usb 1 [ + ] ohci_generic | |-- usb@1c1a400
> usb_hub 1 [ + ] usb_hub | | `-- usb_hub
> usb 2 [ + ] ehci_generic | |-- usb@1c1b000
> usb_hub 2 [ + ] usb_hub | | `-- usb_hub
> usb 3 [ + ] ohci_generic | |-- usb@1c1b400
> usb_hub 3 [ + ] usb_hub | | `-- usb_hub
> usb 4 [ + ] ehci_generic | |-- usb@1c1c000
> usb_hub 4 [ + ] usb_hub | | `-- usb_hub
> usb_mass_s 0 [ + ] usb_mass_storage | | `--
> usb_mass_storage
> blk 1 [ + ] usb_storage_blk | | |--
> usb_mass_storage.lun0
> partition 3 [ + ] blk_partition | | | `--
> usb_mass_storage.lun0:1
> bootdev 3 [ ] usb_bootdev | | `--
> usb_mass_storage.lun0.bootdev
> usb 5 [ + ] ohci_generic | |-- usb@1c1c400
> usb_hub 5 [ + ] usb_hub | | `-- usb_hub
> usb 6 [ + ] ehci_generic | |-- usb@1c1d000
> usb_hub 6 [ + ] usb_hub | | `-- usb_hub
> usb 7 [ + ] ohci_generic | |-- usb@1c1d400
> usb_hub 7 [ + ] usb_hub | | `-- usb_hub
> clk 0 [ + ] sun8i_h3_ccu | |-- clock@1c20000
> reset 0 [ + ] sunxi_reset | | `-- reset
> pinctrl 0 [ + ] sunxi-pinctrl | |-- pinctrl@1c20800
> gpio 0 [ + ] gpio_sunxi | | |-- pinctrl@1c20800
> gpio 1 [ + ] gpio_sunxi | | | |-- PA
> gpio 2 [ + ] gpio_sunxi | | | |-- PB
> gpio 3 [ + ] gpio_sunxi | | | |-- PC
> gpio 4 [ + ] gpio_sunxi | | | |-- PD
> gpio 5 [ + ] gpio_sunxi | | | |-- PE
> gpio 6 [ + ] gpio_sunxi | | | |-- PF
> gpio 7 [ + ] gpio_sunxi | | | `-- PG
> pinconfig 0 [ ] pinconfig | | |-- csi-pins
> pinconfig 1 [ ] pinconfig | | |-- emac-rgmii-pins
> pinconfig 2 [ ] pinconfig | | |-- i2c0-pins
> pinconfig 3 [ ] pinconfig | | |-- i2c1-pins
> pinconfig 4 [ ] pinconfig | | |-- i2c2-pins
> pinconfig 5 [ + ] pinconfig | | |-- mmc0-pins
> pinconfig 6 [ ] pinconfig | | |-- mmc1-pins
> pinconfig 7 [ ] pinconfig | | |-- mmc2-8bit-pins
> pinconfig 8 [ ] pinconfig | | |-- spdif-tx-pin
> pinconfig 9 [ ] pinconfig | | |-- spi0-pins
> pinconfig 10 [ ] pinconfig | | |-- spi1-pins
> pinconfig 11 [ + ] pinconfig | | |-- uart0-pa-pins
> pinconfig 12 [ ] pinconfig | | |-- uart1-pins
> pinconfig 13 [ ] pinconfig | | |--
> uart1-rts-cts-pins
> pinconfig 14 [ ] pinconfig | | |-- uart2-pins
> pinconfig 15 [ ] pinconfig | | |--
> uart2-rts-cts-pins
> pinconfig 16 [ ] pinconfig | | |-- uart3-pins
> pinconfig 17 [ ] pinconfig | | |--
> uart3-rts-cts-pins
> pinconfig 18 [ ] pinconfig | | |-- ahci_pwr_pin@0
> pinconfig 19 [ ] pinconfig | | |-- usb0_vbus_pin@0
> pinconfig 20 [ ] pinconfig | | |-- usb1_vbus_pin@0
> pinconfig 21 [ ] pinconfig | | `-- usb2_vbus_pin@0
> ethernet 0 [ + ] eth_sun8i_emac | |-- ethernet@1c30000
> bootdev 1 [ ] eth_bootdev | | `--
> ethernet@1c30000.bootdev
> watchdog 0 [ + ] sunxi_wdt | |-- watchdog@1c20ca0
> sysreset 0 [ ] wdt_reboot | | `-- watchdog@1c20ca0
> serial 0 [ + ] ns16550_serial | |-- serial@1c28000
> clk 1 [ + ] clk_sun6i_rtc | |-- rtc@1f00000
> clk 2 [ + ] sun6i_a31_r_ccu | |-- clock@1f01400
> reset 1 [ ] sunxi_reset | | `-- reset
> i2c 0 [ ] i2c_mvtwsi | |-- i2c@1f02400
> pinctrl 1 [ + ] sunxi-pinctrl | `-- pinctrl@1f02c00
> gpio 8 [ + ] gpio_sunxi | |-- pinctrl@1f02c00
> gpio 9 [ + ] gpio_sunxi | | `-- PL
> pinconfig 22 [ ] pinconfig | |-- r-ir-rx-pin
> pinconfig 23 [ ] pinconfig | |-- r-i2c-pins
> pinconfig 24 [ ] pinconfig | `-- r-pwm-pin
> clk 3 [ + ] fixed_clock |-- osc24M_clk
> clk 4 [ ] fixed_clock |-- osc32k_clk
> bootstd 0 [ ] bootstd_drv `-- bootstd
> bootmeth 0 [ ] bootmeth_distro |-- distro
> bootmeth 1 [ ] bootmeth_efi |-- efi
> bootmeth 2 [ ] bootmeth_pxe |-- pxe
> bootdev 2 [ ] system_bootdev `-- system-bootdev
>
> grub rescue> ls
> (hd0)
>
> Grub does not see any partition at all.
>
> Loading a device from a partition does not create a handle for the device:
Actually, loading an image does *not* invoke a probe function at all
under the current implementation (of either "part" command,
scan_dev_for_boot_part or even mmc drivers?).
I think that this is weird as the purpose of "probe" is to activate
the device, or "probe - make a device ready for use" according to
doc/develop/driver-model/design.rst
So my conclusion is that the current implementation has already broken
the driver model even before my patch was applied.
-> Simon, you should have a comment here?
That said, fixing a problem is a different matter.
Probably, we will have to modify "part" command or mmc drivers themselves.
-Takahiro Akashi
> => efidebug devices
> ** Unable to read file ubootefi.var **
> Failed to load EFI variables
> Device Device Path
> ======== ====================
> 79f80f08 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> 7dffc7ec /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Uart(0,0,D,D)
> 79f7f1f8
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)
> 79f7f2a0
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)/HD(1,MBR,0x0c449046,0x800,0x800)
> 79fdc188 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(0281431d5371,1)
> => bootefi $kernel_addr_r
> Booting /helloworld.efi
> invalid image type: 0
> Hello, world!
> => efidebug devices
> Device Device Path
> ======== ====================
> 79f80f08 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> 7dffc7ec /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Uart(0,0,D,D)
> 79f7f1f8
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)
> 79f7f2a0
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)/HD(1,MBR,0x0c449046,0x800,0x800)
> 79fdc188 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(0281431d5371,1)
> =>
>
> So the current state is a complete mess.
>
> Best regards
>
> Heinrich
next prev parent reply other threads:[~2022-04-27 3:26 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-19 1:05 [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model AKASHI Takahiro
2022-04-19 1:05 ` [PATCH v5 01/12] dm: tag: change ENOSPC to ENOMEM AKASHI Takahiro
2022-04-19 1:05 ` [PATCH v5 02/12] dm: tag: add some document AKASHI Takahiro
2022-04-19 1:05 ` [PATCH v5 03/12] test: dm: add tests for tag support AKASHI Takahiro
2022-04-19 1:05 ` [PATCH v5 04/12] dm: disk: add UCLASS_PARTITION AKASHI Takahiro
2022-04-19 1:05 ` [PATCH v5 05/12] dm: blk: add a device-probe hook for scanning disk partitions AKASHI Takahiro
2022-04-19 1:05 ` [PATCH v5 06/12] efi_loader: split efi_init_obj_list() into two stages AKASHI Takahiro
2022-04-19 1:05 ` [PATCH v5 07/12] efi_loader: disk: a helper function to create efi_disk objects from udevice AKASHI Takahiro
2022-04-30 18:44 ` Johan Jonker
2022-05-18 9:23 ` Neil Armstrong
2022-05-19 5:04 ` AKASHI Takahiro
2022-06-01 0:25 ` AKASHI Takahiro
2022-08-24 9:00 ` Vyacheslav
2022-08-24 9:29 ` Vyacheslav
2022-06-13 19:54 ` Fabio Estevam
2022-06-13 20:10 ` Tom Rini
2022-06-13 22:21 ` Mark Kettenis
2022-06-13 22:48 ` Fabio Estevam
2022-06-13 23:39 ` Heinrich Schuchardt
2022-06-13 23:54 ` Fabio Estevam
2022-06-14 3:59 ` Heiko Thiery
2022-06-13 23:39 ` AKASHI, Takahiro
2022-04-19 1:05 ` [PATCH v5 08/12] efi_loader: disk: not create BLK device for BLK(IF_TYPE_EFI_LOADER) devices AKASHI Takahiro
2022-04-19 1:05 ` [PATCH v5 09/12] efi_loader: disk: a helper function to delete efi_disk objects AKASHI Takahiro
2022-04-19 1:05 ` [PATCH v5 10/12] efi_loader: disk: not delete BLK device for BLK(IF_TYPE_EFI_LOADER) devices AKASHI Takahiro
2022-04-19 1:05 ` [PATCH v5 11/12] dm: disk: add read/write interfaces with udevice AKASHI Takahiro
2022-04-19 1:05 ` [PATCH v5 12/12] efi_loader: disk: use udevice instead of blk_desc AKASHI Takahiro
2022-04-25 20:43 ` [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model Heinrich Schuchardt
2022-04-25 23:44 ` AKASHI Takahiro
2022-04-26 13:57 ` Heinrich Schuchardt
2022-04-26 14:44 ` AKASHI Takahiro
2022-04-26 17:02 ` Heinrich Schuchardt
2022-04-26 17:18 ` Mark Kettenis
2022-04-26 17:23 ` Tom Rini
2022-04-27 3:26 ` AKASHI Takahiro [this message]
2022-04-28 4:52 ` AKASHI Takahiro
2022-04-28 6:45 ` Heinrich Schuchardt
2022-04-28 9:09 ` Mark Kettenis
2022-04-28 9:42 ` Heinrich Schuchardt
2022-04-28 10:11 ` Mark Kettenis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220427032609.GA34649@laputa \
--to=takahiro.akashi@linaro.org \
--cc=ilias.apalodimas@linaro.org \
--cc=masami.hiramatsu@linaro.org \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox