Re: [PATCH 00/21] Qualcomm generic board support

[Daniel Thompson]

On Tue, Dec 05, 2023 at 10:36:28AM +, ff wrote:
> > Le 5 déc. 2023 à 10:46, Sumit Garg  a écrit :
> >
> > + U-boot custodians list
> >
> >> On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski
> >>  wrote:
> >>
> >> On 05/12/2023 08:13, Sumit Garg wrote:
> > @DT bindings maintainers,
> >
> > Given the ease of maintenance of DT bindings within Linux kernel
> > source tree, I don't have a specific objection there. But can we
> > ease DTS testing for firmware/bootloader projects by providing a
> > versioned release package for DT bindings? Or if someone else
> > has a better idea here please feel free to chime in.
> 
>  This doesn't work for you?:
> 
>  https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
> >>>
> >>> Thanks, this is certainly a good step which I wasn't aware of.
> >>> Further simplification can be done to decouple devicetree source
> >>> files from DT bindings.
> >>
> >> Why?
> >
> > I suppose you are already aware that Linux DTS files are a subset of
> > what could be supported by devicetree schemas. There can be
> > firmware/bootloader specific properties (one example being [1])
> > which Linux kernel can simply ignore. Will you be willing to add all
> > of those DT properties to Linux DTS files and maintain them?
>
> A pre-existing effort to solve the same problem as [1] is System
> Device Tree, discussed in the context of Linaro supported OpenAMP
> project. It is not just about cherry picking devices that have
> bindings in Linux but also information about clock and power domains
> or devices that are not seen by Linux.  It is obvious that the
> resulting bindings should be maintained upstream in the DT repo
> regardless of the communities adopted solution.

This seems to be artificially linking two topics: system DT and DT
schema validation within u-boot. They are somewhat related but one of
not a precondition of the other.


> > However, DT bindings are something which should be common, the
> > hardware description of a device should be universal. IMO, splitting
> > DT bindings alone would ease the compliance process for u-boot
> > drivers in quite similar manner to Linux drivers.
>
> I remember a discussion with ST on that topic related to Framebuffer.
> U-Boot can need a very different representation of the same device to
> use it while Linux need an in-depth description of all shaders and «
> stuff » (another reason why [1] is addressing only a portion of the
> problem) So even if there is a single frame buffer binding, there
> should be two (at least) conformance tests.

I don't follow this, for two reasons.

1. DT describes the hardware, not how it is driven. Having a relationship
   between u-boot and linux DTs with different representation would
   imply that the hardware changes between u-boot and the kernel.

2. Even if we were to accept that there must be two device tree instances
   (beyond transient workarounds for missing features), why would there
   need to be two conformance tests rather than one conformance test run
   on the two DTs?


Daniel.

Re: [PATCH 00/21] Qualcomm generic board support

[Daniel Thompson]

On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
> + Linux kernel DT bindings maintainers, EBBR ML
>
> On Thu, 30 Nov 2023 at 20:05, Tom Rini  wrote:
> > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
> > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong  
> > > wrote:
> > > > > I've been thinking about and hacking on this for the last week or so,
> > > > > sorry for the delayed reply here.
> > > > >
> > > > > The value is in preventing any of the existing bindings from 
> > > > > regressing,
> > >
> > > That is actually best addressed in Linux by checking the DTS against
> > > yaml DT bindings. We don't have that testing available in u-boot and
> > > only depend on careful reviews.
> >
> > I would absolutely love for someone to make another attempt at updating
> > our kbuild infrastucture so that we can run the validation targets.
> >
>
> Given that EBBR requires [1] the platform (firmware/bootloader) and
> not OS to supply the devicetree, it becomes evident that
> firmware/bootloaders import DTS from Linux kernel (where it is
> maintained).
>
> But currently u-boot doesn't have a proper way to validate those DTS
> against DT bindings (maintained in Linux kernel). Although there are
> Devicetree schema tools available here [2], there isn't a versioned
> release package of DT bindings which one should use to validate DTS
> files.

The kernel is regularly released in multiple forms (including git
tags and tarball). Why isn't the kernel itself sufficient to be a
versioned release of the DT bindings directory?


Daniel.

Re: [PATCH 1/8] arm64: dts: sdm845: Remove redundant u-boot DT properties

[Daniel Thompson]

On Tue, Jul 05, 2022 at 11:05:04AM +0530, Sumit Garg wrote:
> Hi Daniel,
> 
> Thanks for your review.
> 
> On Mon, 4 Jul 2022 at 21:28, Daniel Thompson  
> wrote:
> >
> > On Mon, Jul 04, 2022 at 06:28:38PM +0530, Sumit Garg wrote:
> > > U-boot specific DT properties belong to *-uboot.dtsi
> >
> > ... and are already included in starqltechn-uboot.dtsi (which is the
> > only current consumer of sdm845.dtsi).
> >
> >
> > Adding fuller comments, such as the above, makes things much easier to
> > review: it makes clear why you consider the properties redundant rather
> > then misfiled.
> >
> 
> I would rather say that this change is to follow the u-boot DT
> recommendation [1]. I will update the commit message accordingly. BTW,
> it looks like u-boot DT properties are incorrectly specified in
> starqltechn-uboot.dtsi here [2] as there aren't any subnodes for the
> "gcc" node. I will correct that too.

That's fine. The wording was just an example and we written before I
reviewed patch 4 and spotted the inconsistancies there.


Daniel.

Re: [PATCH 4/8] board: qualcomm: Add support for dragonboard845c

[Daniel Thompson]

On Mon, Jul 04, 2022 at 06:28:41PM +0530, Sumit Garg wrote:
> diff --git a/arch/arm/dts/dragonboard845c-uboot.dtsi 
> b/arch/arm/dts/dragonboard845c-uboot.dtsi
> new file mode 100644
> index 00..8b5a7ee573
> --- /dev/null
> +++ b/arch/arm/dts/dragonboard845c-uboot.dtsi
> @@ -0,0 +1,37 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * U-Boot addition to handle Qualcomm Robotics RB3 Development Platform
> + * (dragonboard845c) pins
> + *
> + * (C) Copyright 2022 Sumit Garg 
> + */
> +
> +/
> +{
> + soc {
> + u-boot,dm-pre-reloc;
> +
> + serial@a84000 {
> + u-boot,dm-pre-reloc;
> + };
> +
> + clock-controller@10 {
> + u-boot,dm-pre-reloc;
> + };
> +
> + pinctrl_north@390 {
> + u-boot,dm-pre-reloc;
> + };
> + };
> +};

These additional u-boot,dm-pre-reloc changes are different to the ones
that appear in starqltechn-uboot.dtsi . That suggests that either patch 1
is not actually removing redundant properties or that the DB845C port is
wrong.


> +config TARGET_DRAGONBOARD845C
> + bool "96Boards Dragonboard 845C"
> + help
> +   Support for 96Boards Dragonboard 845C aka Robotics RB3 Development
> +   Platform. This board complies with 96Board Open Platform

Nitpicking but... s/96Board/96Boards/


Daniel.

Re: [PATCH 1/8] arm64: dts: sdm845: Remove redundant u-boot DT properties

[Daniel Thompson]

On Mon, Jul 04, 2022 at 06:28:38PM +0530, Sumit Garg wrote:
> U-boot specific DT properties belong to *-uboot.dtsi

... and are already included in starqltechn-uboot.dtsi (which is the
only current consumer of sdm845.dtsi).


Adding fuller comments, such as the above, makes things much easier to
review: it makes clear why you consider the properties redundant rather
then misfiled.


Daniel.


> , so remove
> corresponding redundant properties.
> 
> Signed-off-by: Sumit Garg 
> ---
>  arch/arm/dts/sdm845.dtsi | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm/dts/sdm845.dtsi b/arch/arm/dts/sdm845.dtsi
> index 6f2fb20d68..88030156d9 100644
> --- a/arch/arm/dts/sdm845.dtsi
> +++ b/arch/arm/dts/sdm845.dtsi
> @@ -18,7 +18,6 @@
>   compatible = "simple-bus";
>  
>   gcc: clock-controller@10 {
> - u-boot,dm-pre-reloc;
>   compatible = "qcom,gcc-sdm845";
>   reg = <0x10 0x1f>;
>   #clock-cells = <1>;
> @@ -27,7 +26,6 @@
>   };
>  
>   gpio_north: gpio_north@390 {
> - u-boot,dm-pre-reloc;
>   #gpio-cells = <2>;
>   compatible = "qcom,sdm845-pinctrl";
>   reg = <0x390 0x40>;
> @@ -38,7 +36,6 @@
>   };
>  
>   tlmm_north: pinctrl_north@390 {
> - u-boot,dm-pre-reloc;
>   compatible = "qcom,tlmm-sdm845";
>   reg = <0x390 0x40>;
>   gpio-count = <150>;
> -- 
> 2.25.1
> 

Modules for carrier boards [Was: Re: Question about extension board used in U-boot]

[Daniel Thompson]

On Sat, Sep 18, 2021 at 08:49:48AM +0200, François Ozog wrote:
> Hi Paul
> 
> Too posting because I think we also need to address this at a higher level.
> 
> i think we discussed this topic quite a while back. I may be wrong but it
> may be Bill Mills who proposed to have an eeprom on the extensions that the
> carrier board can use to detect and fetch proper overlay. Another way would
> be that the contract between the extension board and the carrier board
> includes an i2c accessible storage to fetch an overlay that would identify
> the board and give all details.

What you're describing sounds exactly like Raspberry Pi HATs work:
https://github.com/raspberrypi/hats/blob/master/devicetree-guide.md

Similarly Beagleboard capes use rely on I2C EEPROMs for make them
discoverable, although I don't think all have to have a built-in
overlay (IIRC because they joined the party too early).

In other words there's plenty of prior art here and, as new hardware
standards come out, it should be much easier for them to find this prior
art. However I'm near certain mistakes will still be made...


> Bottom line, a software only solution seems not entirely satisfying.
> In that suboptimal case, U-Boot shall be able to assemble a DT for itself
> and another for OS (may be same in some cases) through scripting. And in
> this case, come your questions  below.

Sub-optimal or not[1] the u-boot extension board code still looks like it
would be a good starting point even for boards with non-discoverable
extensions (96Boards CE 1.0 for example).

If implementing on a board with non-discoverable extensions then I would
consider implementing "extension scan" to report non-discoverable modules
(e.g. from an internal list) and proposing patches to that "extension
apply all" would not enable non-discoverable boards (so that non-
discoverable boards would have to be enabled by injecting a "extension
apply " into the boot scripts).

Of course, I may have overlooked a better existing mechanism in u-boot
but that's what I would start with until I was corrected by
maintainers ;-) .


Daniel.


[1] And also extremely off-topic for Paul since his (a) boards are
discoverable and (b) the extension framework can't fire up early
enough for TPM extensions ;-) .



> Le sam. 18 sept. 2021 à 01:21, Ying-Chun Liu (PaulLiu) 
> a écrit :
> 
> > Hi all,
> >
> >
> > I have some questions about how to implement extension board usage.
> > My case is on imx8mm-cl-iot-gate. It can add three different types of
> > extension boards.
> > One of the extension boards is SPI extension which have 3 empty slots.
> > And you can add
> > some small boards onto it. One of them is a "TPM2" module.
> >
> >
> > My first question is if I want to use tpm2 in U-boot for measured boot.
> > How to implement this right? Currently I just modify the dts used by
> > U-boot to let it drive
> > the extension board. And let it drive the TPM. But it is not good for
> > upstreaming because
> > when other types of extension boards installed then it is not working.
> > Where to implement this? What is the best practice of this?
> 
> 
> > The second question is about extension manager.
> > I have read the extension.rst. I think I'll implement this anyway
> > because then
> > I can have a command to query what type of extension boards I have.
> > And if the extension board is the 3 slots one. I can then detect which
> > slot is the TPM.
> > I'll implement this anyway because the "extension" command is convenient
> > for users.
> > But it seems to me that it only solves the problem for Linux kernel.
> > It can apply a DTB Overlay to Linux DTB to let Linux knows we have that
> > extension board.
> > But it is too late for U-boot itself, right?
> >
> >
> > The third question is I'm also dong SystemReady IR certificate. That means
> > the dtb for Linux is directly provided by U-boot. We use U-boot dtb
> > directly to Linux
> > kernel. In this case, how to modify that dts dynamically to feed to the
> > Linux kernel by
> > the extension manager?
> > What is the best practice if I want to use U-boot dts for Linux in
> > implementation?
> >
> >
> > Thanks a lot.
> >
> >
> > Yours,
> > Paul
> >
> >
> > --
> François-Frédéric Ozog | *Director Business Development*
> T: +33.67221.6485
> francois.o...@linaro.org | Skype: ffozog
> ___
> boot-architecture mailing list
> boot-architect...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Daniel Thompson]

On Fri, Jul 09, 2021 at 09:05:09AM +0200, François Ozog wrote:
> Le ven. 9 juil. 2021 à 03:09, Julius Werner  a écrit :
> 
> > > Of course every project would like not to change...
> > >
> > > For TF-A I wonder whether it will/should in fact use devicetree if there
> > is a lot of complex data? TBD, I suppose.
> >
> > Okay, sorry, now I'm a bit confused -- I thought the discussion in
> > this thread was about which parameter hand-off mechanism to use *for
> > TF-A*? Or did it shift to discuss other projects in the meantime (I
> > didn't always follow it closely)? I think it started with the UEFI
> > guys wanting to implement a HOB format to interface with TF-A, and I
> > think we now concluded that they're okay with using a simple parameter
> > list instead (and wrapping their custom HOBs into a parameter blob
> > that contains their UUID and everything else in the data part).
> >
> > So for TF-A, if the decision is that we want a parameter list, I think
> > it makes sense to keep using the format that has already been there
> > and in use for several years, and define new tags for the UEFI HOB use
> > case in that. I don't really see a reason to switch TF-A and all other
> > projects currently interfacing with it that way (e.g. coreboot) to
> > something only used by U-Boot right now, if they're practically
> > identical in concept.
> 
> Looking at bl_au_params: used by 3 SoCs to deal with gpio and serial.

I presume this analysis only covers those SoCs where someone (vendor,
customer, community) has upstreamed their TF-A implementation?

It is only relatively recently[1] that the TF-A CLA requirements that
inhibited upstreaming were relaxed. Additionally the current silicon
supply crunch is forcing board designers to second (third and forth)
source critical components which can drive usage of firmware parameter
passing.

In short are you confident adopting a mantra of "it doesn't exist
unless it's upstreamed" is sufficient?


Daniel.


[1] Perhaps not that recent if measured in years... but certainly
recent relative to firmware life cycles!


> Migration may not be that a big effort (handful lines of code?).  The
> key thing is that the biggest consumer of them are BL33 and a little
> bit by some OS drivers (OS itself shall not be a consumer).  U-Boot
> has an established mechanism which is used in particular on all chrome
> books in both x86 and Arm environments.  I have the impression that
> U-Boot is the typical BL33 so I would import the mechanism into TFA,
> not the other way round.  EDK2 has typically its own code for TFA
> matters and may just import BL31, so it does not appear a priority in
> that decision. But I may be wrong…
> 
> >
> > --
> François-Frédéric Ozog | *Director Business Development* T:
> +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
> ___ boot-architecture
> mailing list boot-architect...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

[Daniel Thompson]

On Tue, Oct 06, 2020 at 10:00:40AM +0200, François Ozog wrote:
> Le mar. 6 oct. 2020 à 09:21, Ard Biesheuvel  a écrit :
> 
> > On Tue, 6 Oct 2020 at 06:35, Heinrich Schuchardt 
> > wrote:
> > >
> > > Am 6. Oktober 2020 00:37:58 MESZ schrieb Grant Likely <
> > grant.lik...@arm.com>:
> > > >
> > > >
> > > >On 03/10/2020 09:51, Heinrich Schuchardt wrote:
> > > >> Hello Ilias, hello Christian,
> > > >>
> > > >> with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for
> > > >initramfs
> > > >> loading") Ilias provided the possibility to specify a device path
> > > >> (CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
> > > >> served via the EFI_FILE_LOAD2_PROTOCOL.
> > > >>
> > > >> Ard extended the Linux EFI stub to allow loading the initial RAM disk
> > > >> via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.
> > > >>
> > > >> With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
> > > >> IH_OS_EFI") Cristian enabled signed FIT images that contain a device
> > > >> tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).
> > > >>
> > > >> In the DTE calls we have discussed that it is unfortunate that we do
> > > >not
> > > >> have a method to validate initial RAM images in the UEFI context.
> > > >>
> > > >> To me it would look like a good path forward to combine the two
> > > >ideas:
> > > >>
> > > >> * Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
> > > >> * Pass location and size to the UEFI subsystem and serve them via
> > > >>the EFI_FILE_LOAD2_PROTOCOL.
> > > >>
> > > >> We could also extend the bootefi command to be callable as
> > > >>
> > > >> bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
> > > >>
> > > >> like the booti command to serve an initial RAM disk.
> > > >>
> > > >> What are your thoughts?
> > > >
> > > >Hi Heinrich,
> > > >
> > > >I've got concerns about this approach. Even though it uses the UEFI
> > > >infrastructure, images deployed in this way are U-Boot specific and
> > > >won't ever be applicable on EDK2 or other UEFI implementations.
> > > >
> > > >However there is another way to approach it which I think Francois
> > > >touched on. If instead a UEFI stub was added to the FIT image, in the
> > > >same way that the kernel has a UEFI stub, then the logic of decoding
> > > >the
> > > >FIT and choosing the correct DTB & initrd can be part of the image and
> > > >it becomes applicable to any UEFI implementation. It would also address
> > > >
> > > >Ard's concern of loading the FIT into memory, and then copying due to
> > > >the EFI_FILE_LOAD2 path. The FIT stub would already know the image is
> > > >in
> > > >RAM, that is is reserved correctly, and just pass the correct addresses
> > > >
> > > >to the kernel as part of the normal boot flow.
> > > >
> > > >Signing would also be taken care of because the whole FIT can be
> > > >signed,
> > > >and that signature would be checked when it gets loaded.
> > > >
> > > >Thoughts?
> > > >
> > >
> > > The gain of a fit image in U-Boot used for calling the Linux kernel via
> > the EFI stub vs calling the legacy entry point comes down to providing the
> > EFI_RNG_PROTOCOL to be used for KASLR.
> > >
> > > For initrd a stub UEFI binary will work. But if you want to provide a
> > kernel specific  dtb with the same stub binary it will require a new
> > service for device-tree fixups.
> > >
> > > Both approaches are on Francois' DTE slidedeck.
> > >
> > > When thinking of security what really is unclear to me is how we can
> > safely provide the decryption key for the root partition. Without such a
> > means secure boot stops being secure once Linux starts the init process. I
> > would assume that only the secure world can provide the key.
> > >
> >
> > Secure boot only deals with authentication, which does not require any
> > secret keys.
> >
> > Encrypted file systems are a completely separate matter. Typically,
> > this is based on TPM-based local attestation, where the decryption key
> > has been sealed into the TPM, and is only unsealed when all the boot
> > components check out (based on their 'measurements' [aka hashes] that
> > are cumulatively recorded in TPM hardware registers called PCRs)
> >
> > In general, keeping secrets on a device is much more difficult than
> > authenticating executable images, and typically involves some user
> > provided secret, or h/w support. UEFI secure boot only reasons about
> > authentication.
> 
> 
> If SecureBoot is involving Microsoft certificate, a US governmental agency
> could get its code signed and insert itself in a stealth mode (efi apps or
> drivers -> rootkit?)

It is possible that user customizable systems (EBBR booting something
like a normal distro) might choose to ship with Microsoft certificates.
However in the general case there is no good reason to ship a fully
integrated embedded product (e.g. not user modifiable) that trusts the
MS certificate.


> If the set of keys must include this certificate  , then to achieve

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

[Daniel Thompson]

On Mon, Oct 05, 2020 at 04:12:11PM +0200, François Ozog wrote:
> The driving idea is that there is an existing bootflow, non UEFI that
> allows vmlinuz, initrd and DTB to be protected in a single FIT. The
> trustworthiness of the solution is higher that regular distro on pure UEFI
> systems but does not allow initrd changes as you install stuff. We need to
> keep in mind the use cases: most of the cases are for production devices
> where updates are not "calculated" in place but rather deployed with
> various means.
> 
> I'd like to define two EBBR boot flows:
> 1) typical distro (with its weakness)
> 2) typical embedded (as of today, addressing security and mix/match
> protection)
> 
> The 1) is described in slide 4 of the deck
> The 2) is described in slide 5.

It seems these discussion keeps looping back to out-of-band resources.
If we have to keep referring to out-of-band resources to follow
discussion can you ensure there is a link to said out-of-band resources
when citing modifications to them.

It's frustrating to have to go rummaging through my mail archives to find
your doc.


Daniel.


> 
> The UEFI interface is still OS independent but comes with an additional
> opportunity: the ESP File System is "merged" with contents of a FIT (kind
> of overlayfs). This way the content of the FIT can be checked and EFIStub
> with EFI-LOAD_FILE2 the initrd. The boot will still indirectly point to
> the FIT contained .EFI application, the firmware DTB may be overwritten by
> a FIT DTB.
> 
> Is this a better scenario to establish 2)?
> 
> Cheers
> 
> 
> FF
> 
> On Sat, 3 Oct 2020 at 15:12, Ard Biesheuvel  wrote:
> 
> >
> >
> > On Sat, 3 Oct 2020 at 13:16, François Ozog 
> > wrote:
> >
> >>
> >>
> >> Le sam. 3 oct. 2020 à 13:14, François Ozog  a
> >> écrit :
> >>
> >>>
> >>>
> >>> Le sam. 3 oct. 2020 à 10:51, Heinrich Schuchardt  a
> >>> écrit :
> >>>
>  Hello Ilias, hello Christian,
> 
> 
> 
>  with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for initramfs
> 
>  loading") Ilias provided the possibility to specify a device path
> 
>  (CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
> 
>  served via the EFI_FILE_LOAD2_PROTOCOL.
> 
> 
> 
>  Ard extended the Linux EFI stub to allow loading the initial RAM disk
> 
>  via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.
> 
> 
> 
>  With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
> 
>  IH_OS_EFI") Cristian enabled signed FIT images that contain a device
> 
>  tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).
> 
> 
> 
>  In the DTE calls we have discussed that it is unfortunate that we do not
> 
>  have a method to validate initial RAM images in the UEFI context.
> 
> 
> 
>  To me it would look like a good path forward to combine the two ideas:
> 
> 
> 
>  * Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
> 
>  * Pass location and size to the UEFI subsystem and serve them via
> 
>    the EFI_FILE_LOAD2_PROTOCOL.
> 
> 
> 
>  We could also extend the bootefi command to be callable as
> 
> 
> 
> bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
> 
> 
> 
>  like the booti command to serve an initial RAM disk.
> 
> 
> 
>  What are your thoughts?
> >>>
> >>> that looks super interesting.
> >>> I propose something (in the latest desk preparing oct 14th) similar
> >>> except the an efi application boots the FIT.
> >>> I view UEFI as booting a PE coff and pass a set of config tables. Today
> >>> we have DTB, we could just add Initrd (you command line). Bootefi would be
> >>> responsible to valide the containing FIT before pushing initrd (and
> >>> dTB?)into the table. It would be the responsibility of the efi stub to get
> >>> the initrd from the config table (GUID to be defined).
> >>>
> >> the memory attributes of the initrd config table should be such that it
> >> can be recovered for normal use. That may be tricky though.
> >>
> >
> > The purpose of the EFI_FILE_LOAD2_PROTOCOL based initrd loading mechanism
> > is to allow the EFI stub (which is tightly coupled to the kernel
> > arch/version/etc) to allocate the memory for the initrd, and pass it into
> > the LoadFile2() request, using whichever policy it wants to adhere to for
> > alignment, offset and/or vicinity of the kernel image. It also ensures that
> > any measurement performed by the bootloader for attestation or
> > authentication can be delayed to the point where the booting kernel assumes
> > ownership of the initrd contents, preventing potential TOCTOU issues where
> > intermediate boot stages are involved (shim+grub etc)
> >
> > Creating an initrd config table would mean that the bootloader decides
> > where to load the initrd in memory, and only passes the address and size.
> > This is 

Re: [U-Boot] [PATCH] hikey: Take peripherals out of reset during board init

[Daniel Thompson]

On Wed, Mar 20, 2019 at 11:56:58AM +0530, Manivannan Sadhasivam wrote:
> Hi Peter,
> 
> On Tue, Mar 19, 2019 at 11:29:01AM +, Peter Griffin wrote:
> > Hi Mani,
> > 
> > This looks like a bug in the Linux kernel. The kernel driver should be
> > correctly
> > handling the reset lines of the I2C or SPI peripheral rather than replying
> > on
> > the bootloader to have already taken it out of reset.
> > 
> 
> Correct. After sending this patch out, I sent a patchset to LKML [1] for 
> fixing
> the issue in Linux kernel (thanks to Daniel for suggesting the change). But,
> we might need this hack in u-boot to make the old kernel/dts to work properly.
> And that's the reason I didn't abandon this patch.

Hacks like this develop a lot of legacy.

To be honest I don't really have much skin in the game here but even so
I'd prefer to see kernel patches back ported to keep any old kernels
running.


Daniel.

> 
> Thanks,
> Mani
> 
> [1] https://lkml.org/lkml/2019/3/8/878
> 
> > Peter.
> > 
> > On Fri, 8 Mar 2019 at 08:57, Manivannan Sadhasivam <
> > manivannan.sadhasi...@linaro.org> wrote:
> > 
> > > Peripherals like I2C and SPI needs to be taken out of reset during
> > > board init for functioning properly. Hence, add `hi6220_periph_reset`
> > > function for doing the same. For instance without this function, I2C
> > > will fail like below while booting linux:
> > >
> > > [0.608033] i2c_designware f710.i2c: Unknown Synopsys component
> > > type:
> > > 0x
> > > [0.621378] i2c_designware f7101000.i2c: Unknown Synopsys component
> > > type:
> > > 0x
> > > [0.633818] i2c_designware f7102000.i2c: Unknown Synopsys component
> > > type:
> > > 0x
> > >
> > > Signed-off-by: Manivannan Sadhasivam 
> > > ---
> > >  board/hisilicon/hikey/hikey.c | 16 
> > >  1 file changed, 16 insertions(+)
> > >
> > > diff --git a/board/hisilicon/hikey/hikey.c b/board/hisilicon/hikey/hikey.c
> > > index 940ae82c45b..f8b8c372bfd 100644
> > > --- a/board/hisilicon/hikey/hikey.c
> > > +++ b/board/hisilicon/hikey/hikey.c
> > > @@ -364,6 +364,20 @@ static void hi6220_pmussi_init(void)
> > > gpio_direction_output(0, 1);
> > >  }
> > >
> > > +static void hi6220_periph_reset(void)
> > > +{
> > > +   u32 data, bits;
> > > +
> > > +   /* Bring I2C0/I2C1/I2C2/SPI0 out of reset */
> > > +   bits = PERI_RST3_I2C0 | PERI_RST3_I2C1 | PERI_RST3_I2C2 |
> > > PERI_RST3_SSP;
> > > +   writel(bits, _sc->rst3_dis);
> > > +
> > > +   /* Wait until the peripherals are out of reset */
> > > +   do {
> > > +   data = readl(_sc->rst3_dis);
> > > +   } while (data & bits);
> > > +}
> > > +
> > >  int misc_init_r(void)
> > >  {
> > > return 0;
> > > @@ -371,6 +385,8 @@ int misc_init_r(void)
> > >
> > >  int board_init(void)
> > >  {
> > > +   hi6220_periph_reset();
> > > +
> > > return 0;
> > >  }
> > >
> > > --
> > > 2.17.1
> > >
> > >
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] efi_loader: EFI variables

[Daniel Thompson]

On Tue, Feb 12, 2019 at 12:34:29PM +0100, Heinrich Schuchardt wrote:
> On 2/12/19 10:49 AM, Alexander Graf wrote:
> > On 02/03/2019 07:32 PM, Heinrich Schuchardt wrote:
> >> Hello Alex, hello Takahiro,
> >>
> >> this morning I met Daniel Thompson of Linaro. He thinks it would be
> >> quite valuable if U-Boot would at least offer read access to EFI
> >> variables at runtime.
> >>
> >> I think what it takes is only a RAM buffer that we put between our
> >> current storage backend (i.e. synchronization with U-Boot variables)
> >> and the API implementation.
> >>
> >> We will need such a buffer anyway for non-permanent variables once we
> >> have a SPI flash storage.
> > 
> > I think slowly we need to take a critical design decision: Do we want to
> > be in the business of managing runtime UEFI variables?
> > 
> > I don't have a fully cohesive answer to that yet. My gut feeling tells
> > me, that runtime variables would be much better off if they lived in
> > TrustZone. That way we don't have to play relocation tricks, and devices
> > that give you persistency are owned by the secure world anyway, so there
> > is no weird intersection between OS and RTS.
> > 
> > So maybe the path forward would be to implement variable services in ATF
> > (or OP-TEE rather I suppose) and just provide shim stubs to communicate
> > with them from runtime services? That would keep all the variable logic
> > platform agnostic, and we would not have to jump through weird hoops
> > with DM.
> 
> U-Boot' major asset are the many boards supported by drivers. Does ATF
> or OP-TEE have drivers for SPI?

Some ports have SPI drivers and AFAIK it is only really there to
facilitate smartcard communications. I'm not aware of any SPI flash
storage hooked up to the driver.


> Or is your idea that U-Boot would provide a module that is set up as a
> trusted driver or trusted app, cf.
> https://developer.arm.com/-/media/developer/Block%20Diagrams/Architecture-of-TEE%20copy.png

OP-TEE has two implementations of secure storage at present: REE (rich
OS) filesystem and eMMC RPMB.

Things will get very circular when the secure storage is the REE
filesystem because it is not available to OP-TEE until the REE has
booted and started the supplicant. That means u-boot would have to
provide a lot of supplicant infrastructure in order to read from the
variable store.


Daniel.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] qemu-arm: Add persistent environment support

[Daniel Thompson]

On Fri, Dec 14, 2018 at 08:00:11PM +0900, Takahiro Akashi wrote:
> On Thu, Dec 13, 2018 at 02:43:58AM +0200, Tuomas Tynkkynen wrote:
> > Hi Sumit, Takahiro,
> > 
> > On Wed, 12 Dec 2018 10:42:56 +0900
> > Takahiro Akashi  wrote:
> > 
> > > On Tue, Dec 11, 2018 at 06:04:05PM +0530, Sumit Garg wrote:
> > > > On Mon, 26 Nov 2018 at 16:51, Sumit Garg 
> > > > wrote:  
> > > > >
> > > > > Currently on qemu-arm platforms environment is kept in RAM.
> > > > > Instead use pflash device 1 to provide persistent environment
> > > > > support across device reset.
> > > > >
> > > > > Also (optionally) provide support for persistent environment
> > > > > across qemu machine OFF/ON using following instructions:
> > > > >
> > > > > - Create envstore.img using qemu-img:
> > > > > qemu-img create -f raw envstore.img 64M
> > > > > - Add a pflash drive parameter to the command line:
> > > > > -drive if=pflash,format=raw,index=1,file=envstore.img
> > > > >
> > > > > Signed-off-by: Sumit Garg 
> > > > > ---
> > > > >  configs/qemu_arm64_defconfig | 7 +++
> > > > >  configs/qemu_arm_defconfig   | 7 +++
> > > > >  doc/README.qemu-arm  | 6 ++
> > > > >  include/configs/qemu-arm.h   | 8 +++-
> > > > >  4 files changed, 27 insertions(+), 1 deletion(-)
> > > > >  
> > > > 
> > > > Gentle reminder. Please let me know if you have any further
> > > > comments.  
> > 
> > I'm not too familiar with the UEFI/ATF related aspects here, but I
> > think that the read-only parts (aka u-boot.bin) and read-write parts
> > (the U-Boot environment) should belong to different files (which is
> > what this patch series does). Basically, IMO as a normal user I should
> > be able to run QEMU on a distro-provided U-Boot binary with something
> > like:
> 
> So probably I'm not a normal user.
> Tom has already applied this patch, and I would change qemu-arm.h
> in my local repo if necessary. That's fine.

To be honest I think we should seriously consider changing TF-A so that
is doesn't look for the FIP in the non-secure flash. When TF-A and the
secure world payload are part of the FIP then loading them from
non-secure flash is a very odd thing to do (in addition to the
practical problems related to read-only binaries in /usr when firmware
and varstore live in the same pflash).


Daniel.

> 
> > qemu-system-arm -bios /usr/share/u-boot/qemu_arm.bin
> 
> # As u-boot is quite board-specific, I don't think distro's default
> u-boot, if any, won't work on qemu.
> 
> > and not have it fail due to not having write permission to /usr/.
> > 
> > > Another use case is atf + u-boot (although I don't know people are
> > > interested in it). Put bl1.bin in flash0(0x0-0x400) and put
> > > fip.bin in flash1(0x400-0x800). Please note that, with
> > > secure=on, flash0 is in secure and flash1 is in non-secure.
> > > While I admit that your patch is workable, my point is that there are
> > > different use cases and it may not be a good idea to put one
> > > configuration in qemu-arm.h.
> 
> > Can EDK2 in QEMU boot with ATF and if so, how does it lay out things?
> 
> Do you mean UEFI? EDK2 is an implementation, UEFI is the specification/
> interface.
> Just FYI, as I said, I experimentally succeeded to run atf + u-boot
> as BL33, only modifying CONFIG_SYS_TEXT_BASE and CONFIG_SYS_FLASH_BASE
> (and CONFIG_ENV_* if needed).
> 
> > Would it be possible to build U-Boot in such a way that u-boot.bin
> > could be substituted in existing build scripts or instructions in place
> > of the EDK2 binary so that things still work the same?
> > 
> > Or in other words, if EDK2 has already has a working
> > implementation of something (such as the flash layout), IMO we should
> > prefer to use that instead of reimplementing it in a different
> > way.
> 
> It is up to the implementation how efi variables are stored
> in storage while efi variables on u-boot are mapped to corresponding
> u-boot environment variables. So there's no compatibility in flash layout
> between EDK2 and u-boot/UEFI.
> 
> Thanks,
> -Takahiro Akashi
> 
> 
> > - Tuomas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] qemu-arm: Add persistent environment support

[Daniel Thompson]

On Thu, Dec 13, 2018 at 02:43:58AM +0200, Tuomas Tynkkynen wrote:
> > Another use case is atf + u-boot (although I don't know people are
> > interested in it). Put bl1.bin in flash0(0x0-0x400) and put
> > fip.bin in flash1(0x400-0x800). Please note that, with
> > secure=on, flash0 is in secure and flash1 is in non-secure.
> > While I admit that your patch is workable, my point is that there are
> > different use cases and it may not be a good idea to put one
> > configuration in qemu-arm.h.
> 
> Can EDK2 in QEMU boot with ATF and if so, how does it lay out things?
>
> Would it be possible to build U-Boot in such a way that u-boot.bin
> could be substituted in existing build scripts or instructions in place
> of the EDK2 binary so that things still work the same?
> 
> Or in other words, if EDK2 has already has a working
> implementation of something (such as the flash layout), IMO we should
> prefer to use that instead of reimplementing it in a different
> way.

The EDK2 binaries I am using don't include ATF. IIRC qemu with default
arguments boots directly into EL1 so most of the off-the-shelf binaries
will not include a trusted firmware.

EDK2 keeps its varstore on the second pflash.


Daniel.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image

[Daniel Thompson]

On 13/07/17 08:33, Bin Chen wrote:

Hi Tom,

Thanks for the review.

On 13 July 2017 at 04:25, Tom Rini > wrote:


On Tue, Jul 11, 2017 at 03:56:04PM +1000, Bin Chen wrote:

> It's my understanding that we are supposed to use booti, instead of bootm,
> for arm64 image. But booti lacks of android image support. Bootm has
> the andriod image support but lack of the arm64 image handling.
>
> So, what is suppose the right way of booting an android arm64 image?
> or, should we create a separate command?
>
> This patch is an invitation for that discussion.
>
> It *hacked* the booti command and it aslo assume the dtb is in the second 
area
> of android boot image. It also has other belives like u-boot should be
> in control of where to put the kernnel/ramdisk/dtb images so it ignores
> the value specified in the android images.
>
> Signed-off-by: Bin Chen >

So, booti is very much for the "Image" format described in the Linux
kernel in Documentation/arm64/booting.txt.  One can (and people have)
used bootm on aarch64 for "uImage" style kernels and FIT kernels, and I
would see being able to boot an aarch64 Android image with bootm as the
way to go forward. 



Are you suggesting that we should use bootm path, instead of booti?

I have two questions regarding this:

1. currently arm64 kernel don't have a uImage kernel target. And I'm not 
sure

  if adding that will be something that is wanted and/or sensible.


All arm64 kernels are multi-platform (even if for some minimized builds 
only drivers for one platform are actually enabled). That means a uImage 
kernel target is problematic because the kernel build system does not 
know its eventual physical load address. On arm64 that is entirely 
delegated to the bootloader.


That doesn't mean uImage can never be used; just that the kernel build 
system has no business authoring one.





2. bootm path doesn't have the logic that is currently in the booti, 
such as the

kernel relocation.

Also, one other question raised during internal discussion was why the 
booti
was created in the first place, if we could have had that implemented in 
the

bootm path.


The analogy would be that we use bootm for Android
on arm not bootz.  Thanks!

--
Tom




--
Regards,
Bin


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Kconfig: Add support for hash and sha1sum commands

[Daniel Thompson]

On 22/05/17 22:17, Tom Rini wrote:

On Mon, May 22, 2017 at 02:26:57PM -0600, Simon Glass wrote:

Hi Daniel,

On 19 May 2017 at 10:26, Daniel Thompson <daniel.thomp...@linaro.org> wrote:

Currently these (board agnostic) commands cannot be selected using
menuconfig and friends. Fix this the obvious way.

Signed-off-by: Daniel Thompson <daniel.thomp...@linaro.org>
---
  cmd/Kconfig | 27 +++
  1 file changed, 27 insertions(+)


Great to see this. However CMD_HASH is already in progress at
u-boot-dm/kconfig-working. I hope it will make it to mainline soon.
But in the meantime could you please  rebase on that and send v2?


Since this needs moveconfig.py run as well, I'll just v2 it, thanks!


Does that translate into "Daniel, don't worry about the rebase there are 
other things that I'd need to change as well and its quicker and easier 
for me just to do them".


I totally happy with that translation but just want to check it's correct.


Daniel.

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] Kconfig: Add support for hash and sha1sum commands

[Daniel Thompson]

Currently these (board agnostic) commands cannot be selected using
menuconfig and friends. Fix this the obvious way.

Signed-off-by: Daniel Thompson <daniel.thomp...@linaro.org>
---
 cmd/Kconfig | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index d9f7151bacdc..f459f8440346 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -338,6 +338,19 @@ config CMD_CRC32
help
  Compute CRC32.

+config CMD_HASH
+   bool "hash"
+   default n
+   help
+ Compute a hash using any algorithm supported by hash_lookup_algo().
+
+config HASH_VERIFY
+   bool "hash -v"
+   default n
+   depends on CMD_HASH
+   help
+ Add -v option to verify data against a hash.
+
 config CMD_MD5SUM
bool "md5sum"
default n
@@ -352,6 +365,20 @@ config MD5SUM_VERFIY
help
  Add -v option to verify data against an MD5 checksum.

+config CMD_SHA1SUM
+   bool "sha1sum"
+   default n
+   select SHA1
+   help
+ Compute SHA1 checksum.
+
+config SHA1SUM_VERFIY
+   bool "sha1sum -v"
+   default n
+   depends on CMD_SHA1SUM
+   help
+ Add -v option to verify data against an SHA1 checksum.
+
 config LOOPW
bool "loopw"
help
--
2.9.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Daniel Thompson]

On 04/05/17 14:47, Jorge Ramirez-Ortiz wrote:

diff --git a/include/configs/poplar.h b/include/configs/poplar.h
new file mode 100644
index 000..fb0ca19
--- /dev/null
+++ b/include/configs/poplar.h
@@ -0,0 +1,113 @@
+/*
+ * (C) Copyright 2017 Linaro
+ *
+ * Jorge Ramirez-Ortiz 
+ *
+ * Configuration for Poplar 96boards CE. Parts were derived from other ARM
+ * configurations.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _POPLAR_H_
+#define _POPLAR_H_
+
+#include 
+
+/* network config */
+#define CONFIG_NET_MULTI   1
+#define CONFIG_PHY_GIGE1
+#define CONFIG_ARP_TIMEOUT 50L
+#define CONFIG_NET_RETRY_COUNT 50
+#define CONFIG_SYS_FAULT_ECHO_LINK_DOWN1
+#define CONFIG_SYS_RX_ETH_BUFFER   16
+#define CONFIG_NET_RANDOM_ETHADDR
+
+/* memory */
+#define PHYS_SDRAM_1   0x
+#define PHYS_SDRAM_1_SIZE  0x4000
+#define CONFIG_NR_DRAM_BANKS   4
+#define DRAM_BANK_SIZE 0x1000
+
+/* sys */
+#define CONFIG_SYS_BOOTM_LEN   0x140
+#define CONFIG_SYS_INIT_RAM_SIZE   0x10
+#define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM_1
+#define CONFIG_SYS_INIT_SP_ADDR(PHYS_SDRAM_1 + 
0x20)
+#define CONFIG_SYS_LOAD_ADDR   (PHYS_SDRAM_1 + 0x80)
+#define CONFIG_SYS_MALLOC_LEN  (PHYS_SDRAM_1 + SZ_8M)
+
+/* must match bl33.bin load address */
+#define CONFIG_SYS_TEXT_BASE   0x3700
+
+/* generic gimer */
+#define COUNTER_FREQUENCY  1900
+
+/* generic interrupt controller definitions */
+#define GICD_BASE  0xF1001000
+#define GICC_BASE  0xF1002000
+
+/* serial port PL010/PL011 */
+#define CONFIG_PL01X_SERIAL
+
+/* USB configuration */
+#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3
+#define CONFIG_USB_MAX_CONTROLLER_COUNT2
+#define CONFIG_SYS_USB_EVENT_POLL
+#define CONFIG_USB_ETHER_SMSC95XX
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_ASIX
+
+/* SD/MMC configuration */
+#define CONFIG_BOUNCE_BUFFER
+/*
+ *  Initial environment variables
+ */
+
+#define CONFIG_NETMASK 255.255.255.0
+#define CONFIG_SERVERIP192.168.1.4
+#define CONFIG_GATEWAYIP   192.168.1.1
+
+#define BOOT_TARGET_DEVICES(func)  \
+   func(USB, usb, 0)   \
+   func(MMC, mmc, 0)   \
+   func(DHCP, dhcp, na)
+
+#ifndef CONFIG_SPL_BUILD
+#include 
+#include 
+#endif
+
+
+#define CONFIG_EXTRA_ENV_SETTINGS  \
+   "loader_mmc_blknum=0x0\0" \
+   "loader_mmc_nblks=0x780\0"\
+   "env_mmc_blknum=0xF\0"\


Shouldn't this be 0x780 (i.e. a blknum rather than bytes)


+   "env_mmc_nblks=0x80\0"\
+   "kernel_addr_r=0x3000\0"  \
+   "pxefile_addr_r=0x3200\0" \
+   "scriptaddr=0x3200\0" \
+   "fdt_addr_r=0x3220\0" \
+   "ramdisk_addr_r=0x3240\0" \
+   BOOTENV
+
+
+/* Command line configuration */
+#define CONFIG_ENV_IS_IN_MMC   1
+#define CONFIG_SYS_MMC_ENV_DEV 0
+#define CONFIG_ENV_OFFSET  0xF  /* env_mmc_blknum */
+#define CONFIG_ENV_SIZE0x1  /* env_mmc_nblks bytes 
*/


Possibly express these are (0x780 * 512) to make absolutely explicit the 
relationship to the blknum/nblks values?



+#define CONFIG_CMD_ENV
+#define CONFIG_FAT_WRITE
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+
+/* Monitor Command Prompt */
+#define CONFIG_CMDLINE_EDITING
+#define CONFIG_SYS_LONGHELP
+#define CONFIG_SYS_CBSIZE  512
+#define CONFIG_SYS_MAXARGS 64
+#define CONFIG_SYS_PBSIZE  (CONFIG_SYS_CBSIZE + \
+   sizeof(CONFIG_SYS_PROMPT) + 16)
+#define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE
+
+#endif /* _POPLAR_H_ */



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] serial: stm32: Automatically generate CR when LF is observed

[Daniel Thompson]

On 12/05/15 22:56, Tom Rini wrote:

On Tue, May 12, 2015 at 10:35:55PM +0200, Kamil Lulko wrote:


Strange, this was already posted by Kunhua Huang - then reverted in
commit 698a12bef9e782dcd99c555a739c16eec8669f14. Anyway, yes this
carriage return should be added there. I simply forgot it since I had
implicit CR for each LF turned on in my terminal. Never thought this
would cause so much havoc for users ;)


I reverted it since the author said it wasn't needed with the other
patch they did being applied.  Daniel, can you confirm the odd behavior
exists with top of tree? Thanks!


Yes, the odd behavior still exists with top of tree.

That said, I lucked out here.

In truth I had the problem because my git tree was slightly more out of 
date than I thought it was (and because a google search for serial 
u-boot stm32 before posting my patch didn't notice the code from Kunhua).


So... my patch won't apply to HEAD anyway but reverting the revert would 
be very welcome!



Daniel.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] serial: stm32: Automatically generate CR when LF is observed

[Daniel Thompson]

Currently the u-boot output looks rather odd when running the minicom
terminal emulator in its default mode (just a string of random looking
text down the right hand side of the screen).

This is caused by a combination of minicom not automatically wrapping
lines and the stm32 serial driver never sending a carriage return.

Issue is trivially solved by automatically generating a CR whenever a LF
is transmitted, Several other serial drivers implement this behaviour.

Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
Cc: Kamil Lulko re...@wp.pl
---
 drivers/serial/serial_stm32.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/serial/serial_stm32.c b/drivers/serial/serial_stm32.c
index 3c80096..8c613db 100644
--- a/drivers/serial/serial_stm32.c
+++ b/drivers/serial/serial_stm32.c
@@ -81,6 +81,10 @@ static int stm32_serial_getc(void)
 static void stm32_serial_putc(const char c)
 {
struct stm32_serial *usart = (struct stm32_serial *)USART_BASE;
+
+   if (c == '\n')
+   stm32_serial_putc('\r');
+
while ((readl(usart-sr)  USART_SR_FLAG_TXE) == 0)
;
writel(c, usart-dr);
-- 
2.1.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot