Re: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer
Hi Laurent,
On Tue, Jun 19, 2018 at 4:15 AM Laurent Pinchart
wrote:
> On Sunday, 17 June 2018 03:08:02 EEST Marek Vasut wrote:
> > On 06/16/2018 05:44 PM, Laurent Pinchart wrote:
> > > On Saturday, 16 June 2018 02:42:30 EEST Marek Vasut wrote:
> > >> On 06/16/2018 01:21 AM, Laurent Pinchart wrote:
> > >>> On Friday, 15 June 2018 15:00:31 EEST Marek Vasut wrote:
> > On 06/15/2018 01:43 PM, Marek Vasut wrote:
> > > On 06/15/2018 12:37 PM, Ulrich Hecht wrote:
> > >> On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut wrote:
> > + arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
> > + 0, 0, 0, 0, 0, 0, 0, &res);
> > >>>
> > >>> Will this call work on platforms without patched ATF ?
> > >>> (I think not, don't you need to handle return value?)
> > >>
> > >> I have not actually tested that, but if I understand the ATF code
> > >> correctly, unimplemented calls return
> > >> SMC_UNK (0x), which should be handled by the default case
> > >> (NOP)
> > >> below.
> > >
> > > Which means the board has a memory size of 0 and fails to boot ?
> > >
> > + switch (res.a0) {
> > + case 1:
> > + base[0] = 0x04800ULL;
> > + size[0] = 0x03800ULL;
> > + base[1] = 0x5ULL;
> > + size[1] = 0x04000ULL;
> > + base[2] = 0x6ULL;
> > + size[2] = 0x04000ULL;
> > + base[3] = 0x7ULL;
> > + size[3] = 0x04000ULL;
> > + fdt_fixup_memory_banks(blob, base, size, 4);
> > + break;
> > + case 2:
> > + base[0] = 0x04800ULL;
> > + size[0] = 0x07800ULL;
> > + base[1] = 0x5ULL;
> > + size[1] = 0x08000ULL;
> > + fdt_fixup_memory_banks(blob, base, size, 2);
> > + break;
> > + case 3:
> > + base[0] = 0x04800ULL;
> > + size[0] = 0x07800ULL;
> > + base[1] = 0x5ULL;
> > + size[1] = 0x08000ULL;
> > + base[2] = 0x6ULL;
> > + size[2] = 0x08000ULL;
> > + base[3] = 0x7ULL;
> > + size[3] = 0x08000ULL;
> > + fdt_fixup_memory_banks(blob, base, size, 4);
> > + break;
> > >>>
> > >>> Obvious design question is -- since you're adding new SMC call
> > >>> anyway,
> > >>> can't the call just return the memory layout table itself, so that
> > >>> it
> > >>> won't be duplicated both in U-Boot and ATF ?
> > >>
> > >> My gut feeling was to go with the smallest interface possible.
> > >
> > > But this doesn't scale. The API here uses some ad-hoc constants to
> > > identify memory layout tables which have to be encoded both in ATF and
> > > U-Boot, both of which must be kept in sync.
> > >
> > > The ATF already has those memory layout tables, it's only a matter of
> > > passing them to U-Boot. If you do just that, the ad-hoc constants and
> > > encoding of tables into U-Boot goes away and in fact simplifies the
> > > design.
> > >
> > > Yet, I have to wonder if ATF doesn't already contain some sort of
> > > standard SMC call to get memory topology. It surprises me that it
> > > wouldn't.
> >
> > In fact, Laurent (CCed) was solving some similar issue with lossy
> > decomp
> > and I think this involved some passing of memory layout information
> > from
> > ATF to U-Boot too, or am I mistaken ?
> > >>>
> > >>> That's correct, ATF stores information about the memory layout at a
> > >>> fixed
> > >>> address in system memory, and U-Boot can read it.
> > >>
> > >> Well, that sounds good ! Maybe we can avoid adding SMC call altogether
> > >> then? :)
> > >
> > > I'd prefer that, yes.
> > >
> > > Let's not duplicate the mechanism used to pass FCNL information from ATF
> > > to U- Boot, but instead create a data table format that can store all the
> > > information we need, in an easily extensible way.
> > >
> > > To see how the mechanism is implemented for FCNL, search for 47FD7000 in
> > > the Renesas ATF sources
> > > (git://github.com/renesas-rcar/arm-trusted-firmware.git).
> > For everyone involved, can you explain what FCNL is ? ;-)
>
> FCNL is Frame Compression Near Lossless. It's a way to reduce memory bandwidth
> by transpar
Re: [U-Boot] [PATCH v5 0/3] sunxi: fix eMMC stability issues on A64
On Tue, Jun 19, 2018 at 12:03 PM, Jagan Teki wrote: > On Tue, Jun 19, 2018 at 11:55 AM, Vasily Khoruzhick > wrote: >> On Mon, Jun 18, 2018 at 12:43 AM, Jagan Teki >> wrote: >>> >>> Don't have these hardware with me. >> >> Could you test this patch on your hardware when you get some time? >> >> https://github.com/anarsoul/u-boot-pine64/commit/a3f5d175a5ed0ece7a7720f1e665809c9f140850.patch > > On top of your changes or separately? This what[1] I changed on top of your changes, same issue. [1] https://paste.ubuntu.com/p/NjYyMk68P6/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 0/7] sunxi: sync H3, H5, A64 DTs from mainline Linux
On Wed, May 16, 2018 at 1:30 PM, Andre Przywara wrote: > This is an updated version of the series which brings the exact mainline > Linux device tree files for various Allwinner boards into U-Boot. > Apart from using the usually more correct reference DT files, this offers > the big benefit of being able to use U-Boot's DT copy for directly passing > it to the kernel. This avoids to actually load a .dtb file from somewhere, > and allows seamless and automatic UEFI booting, so distribution installer > images should just work (TM). > > This cover the ARMv8 SoCs (H5, A64), but also all boards with the H3, as > this is somewhat married to the H5 and can only be updated together. > The H3 and H5 DT files have diverged quite a bit, but as U-Boot's own > usage of the DT is (yet) quite limited, there should be no regressions. > The patches are split to first update the SoC .dtsi file, then the board > .dts files in a second patch. They are grouped to handle the A64 first, > then the H5 and H3. I put the respective kernel commit IDs in the commit > messages. > Patch 6 brings in the mainline DT for the SoPine baseboard, for which we > didn't have a separate .dts in U-Boot so far. > Patch 7 adds a separate .dts file for the Pine64-LTS board, which is > virtually identical to the SoPine baseboard, but, due to the SoC being > named differently, deserves a separate file. > > This is based on origin/master (ca70cbabdcd1). > > Maxime, I kept you Acked-by: from the previous posts, as I literally > just updated to the latest Linux master, which went through your review > anyway. Hope that's OK for you. > > Cheers, > Andre. > > Changelog v5 .. v6: > - bring back DT update patches > - update to Linux v4.17-rc5 > > Changelog v4 .. v5: > - drop Linux DT update patches for now > - fix minor checkpatch complaints > > Changelog v3 .. v4: > - remove MMC environment for all Allwinner boards (including 32 bit ones) > - keep MMC environment offset to the old values > - drop DT adjustments to use fixed MMC regulator > > Changelog v2 .. v3: > 01: added, was on the list before > 02: drop redundant H5 line > 03-08: unchanged > 09-20: added > > Changelog v1 .. v2: > 01, 02, 03: unchanged > 04, 05, 06, 07: added > > Andre Przywara (7): > sunxi: DT: A64: update device tree file for Allwinner A64 SoC > sunxi: DT: A64: update board .dts files from Linux > sunxi: DT: update device tree files for Allwinner H3 and H5 SoCs > sunxi: DT: H5: update board .dts files from Linux > sunxi: DT: H3: update board .dts files from Linux > sunxi: DT: A64: add proper SoPine baseboard device tree Reviewed-by: Jagan Teki Please rebase on master and send, files from A64, H5 and H3 has changed a bit. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: denali: Replace the ad-hoc cache management with bouncebuf
Hi Marek,
2018-06-08 5:17 GMT+09:00 Marek Vasut :
> Replace the ad-hoc DMA cache management functions with common bouncebuf,
> since those functions are not handling cases where unaligned buffer is
> passed in,
Were you hit by a problem,
or just-in-case replacement?
I thought I took care of the buffer alignment.
The bounce buffer is allocated by kmalloc():
https://github.com/u-boot/u-boot/blob/v2018.05/drivers/mtd/nand/denali.c#L1348
According to the lib/linux_compat.c implementation,
it returns memory aligned with ARCH_DMA_MINALIGN.
If the buffer is passed from the upper MTD layer,
the NAND core also makes sure the enough alignment:
https://github.com/u-boot/u-boot/blob/v2018.05/drivers/mtd/nand/denali.c#L1273
This is how this driver works in Linux.
I'd rather want to keep the current code
unless this is a real problem,
One possible clean-up is to move dma_(un)map_single to a common place.
> while common bouncebuf does handle all that.
>
> Signed-off-by: Marek Vasut
> Cc: Masahiro Yamada
> Cc: Tom Rini
> ---
> drivers/mtd/nand/denali.c | 41 +++--
> 1 file changed, 7 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index 089ebce6dd..e5e84a58aa 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -5,6 +5,7 @@
> * Copyright (C) 2009-2010, Intel Corporation and its suppliers.
> */
>
> +#include
> #include
> #include
> #include
> @@ -16,31 +17,6 @@
>
> #include "denali.h"
>
> -static dma_addr_t dma_map_single(void *dev, void *ptr, size_t size,
> -enum dma_data_direction dir)
> -{
> - unsigned long addr = (unsigned long)ptr;
> -
> - if (dir == DMA_FROM_DEVICE)
> - invalidate_dcache_range(addr, addr + size);
> - else
> - flush_dcache_range(addr, addr + size);
> -
> - return addr;
> -}
> -
> -static void dma_unmap_single(void *dev, dma_addr_t addr, size_t size,
> -enum dma_data_direction dir)
> -{
> - if (dir != DMA_TO_DEVICE)
> - invalidate_dcache_range(addr, addr + size);
> -}
> -
> -static int dma_mapping_error(void *dev, dma_addr_t addr)
> -{
> - return 0;
> -}
> -
> #define DENALI_NAND_NAME"denali-nand"
>
> /* for Indexed Addressing */
> @@ -563,16 +539,12 @@ static int denali_pio_xfer(struct denali_nand_info
> *denali, void *buf,
> static int denali_dma_xfer(struct denali_nand_info *denali, void *buf,
>size_t size, int page, int raw, int write)
> {
> - dma_addr_t dma_addr;
> uint32_t irq_mask, irq_status, ecc_err_mask;
> - enum dma_data_direction dir = write ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
> + unsigned int bbflags = write ? GEN_BB_READ : GEN_BB_WRITE;
> + struct bounce_buffer bbstate;
> int ret = 0;
>
> - dma_addr = dma_map_single(denali->dev, buf, size, dir);
> - if (dma_mapping_error(denali->dev, dma_addr)) {
> - dev_dbg(denali->dev, "Failed to DMA-map buffer. Trying
> PIO.\n");
> - return denali_pio_xfer(denali, buf, size, page, raw, write);
> - }
> + bounce_buffer_start(&bbstate, buf, size, bbflags);
>
> if (write) {
> /*
> @@ -593,7 +565,8 @@ static int denali_dma_xfer(struct denali_nand_info
> *denali, void *buf,
> iowrite32(DMA_ENABLE__FLAG, denali->reg + DMA_ENABLE);
>
> denali_reset_irq(denali);
> - denali->setup_dma(denali, dma_addr, page, write);
> + denali->setup_dma(denali, virt_to_phys(bbstate.bounce_buffer),
> + page, write);
>
> irq_status = denali_wait_for_irq(denali, irq_mask);
> if (!(irq_status & INTR__DMA_CMD_COMP))
> @@ -603,7 +576,7 @@ static int denali_dma_xfer(struct denali_nand_info
> *denali, void *buf,
>
> iowrite32(0, denali->reg + DMA_ENABLE);
>
> - dma_unmap_single(denali->dev, dma_addr, size, dir);
> + bounce_buffer_stop(&bbstate);
>
> if (irq_status & INTR__ERASED_PAGE)
> memset(buf, 0xff, size);
> --
> 2.16.2
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/3] sunxi: fix eMMC stability issues on A64
On Tue, Jun 19, 2018 at 11:55 AM, Vasily Khoruzhick wrote: > On Mon, Jun 18, 2018 at 12:43 AM, Jagan Teki wrote: >> >> Don't have these hardware with me. > > Could you test this patch on your hardware when you get some time? > > https://github.com/anarsoul/u-boot-pine64/commit/a3f5d175a5ed0ece7a7720f1e665809c9f140850.patch On top of your changes or separately? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/3] sunxi: fix eMMC stability issues on A64
On Mon, Jun 18, 2018 at 12:43 AM, Jagan Teki wrote: > > Don't have these hardware with me. Could you test this patch on your hardware when you get some time? https://github.com/anarsoul/u-boot-pine64/commit/a3f5d175a5ed0ece7a7720f1e665809c9f140850.patch It uses calibration without using new clock mode and it fixes eMMC on Pinebook for me as well. Also works fine on Pine64-LTS. If it works for you I'll clean it up and send it out. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] x86: qemu: do not build car.o with start64.o
On 06/19/2018 04:37 AM, Bin Meng wrote:
> Hi Heinrich,
>
> On Tue, Jun 12, 2018 at 11:50 PM, Heinrich Schuchardt
> wrote:
>> car.o can only be used with start.o, not with start64.o.
>>
>> So on qemu 64bit it should only be built for 32bit SPL but not for u-boot.
>>
>> Without this patch but with an unrelated pending patch
>> ("x86: Add 64-bit setjmp/longjmp implementation") the
>> following error occurred for qemu-x86_64_defconfig:
>>
>
> I don't understand why Ivan's setmp/longjmp patch triggers this build
> issue. Can you elaborate?
Hello Bin,
it was what I observed.
As start.S calls car_init() but start_64.S does not the linker could
eliminate car.o on x86_64. Why it does not eliminate it with the patch I
do not know.
But I still think that building car.o on 64bit does not make sense.
Best regards
Heinrich
>
>> arch/x86/cpu/built-in.o: In function `car_init':
>> arch/x86/cpu/qemu/car.S:25: undefined reference to `car_init_ret'
>>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> arch/x86/cpu/qemu/Makefile | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/cpu/qemu/Makefile b/arch/x86/cpu/qemu/Makefile
>> index e5ea92545e3..b1daffd4a32 100644
>> --- a/arch/x86/cpu/qemu/Makefile
>> +++ b/arch/x86/cpu/qemu/Makefile
>> @@ -2,8 +2,11 @@
>> #
>> # Copyright (C) 2015, Bin Meng
>>
>> +ifndef CONFIG_$(SPL_)X86_64
>> +obj-y += car.o
>> +endif
>> ifndef CONFIG_EFI_STUB
>> -obj-y += car.o dram.o
>> +obj-y += dram.o
>> endif
>> obj-y += qemu.o
>> obj-$(CONFIG_QFW) += cpu.o e820.o
>> --
>
> BTW: the patch does not apply cleanly on latest u-boot/master. Please
> rebase. Thanks!
>
> Regards,
> Bin
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB
On 06/19/2018 07:52 AM, Chee, Tien Fong wrote:
> On Mon, 2018-06-18 at 12:59 -0400, Tom Rini wrote:
>> On Wed, Jun 13, 2018 at 03:32:43PM +0800, tien.fong.c...@intel.com
>> wrote:
>>
>>>
>>> From: Tien Fong Chee
>>>
>>> In ARM 64-bits, memory size can be supported is more than 4GB,
>>> hence increasing save array is needed to cope with testing larger
>>> memory.
>>>
>>> Signed-off-by: Tien Fong Chee
>>> ---
>>> common/memsize.c |2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/common/memsize.c b/common/memsize.c
>>> index 5670e95..b091203 100644
>>> --- a/common/memsize.c
>>> +++ b/common/memsize.c
>>> @@ -26,7 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
>>> long get_ram_size(long *base, long maxsize)
>>> {
>>> volatile long *addr;
>>> - long save[31];
>>> + long save[BITS_PER_LONG];
>>> long save_base;
>>> long cnt;
>>> long val;
>> Since BITS_PER_LONG is 32 or 64, shouldn't we use B_P_L - 1 here? Or
>> are you saying there's also a case where this is wrong on 32bit
>> today?
> As long as the array is large enough to cope with shifting
> implementation, then it should be fine. For 32-bit, only 31 units in
> array required for storing 31 shifting values, and this apply for 64-
> bit also as long as the implementation of first shifting value is not
> change(cnt = (maxsize / sizeof(long)) >> 1).
> IMO, for simplifying and safety purpose(may be one day implementation
> change to "cnt = (maxsize / sizeof(long))", above B_P_L is still
> workable.
That's BS reasoning and just sloppy programming. I agree with Tom.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer
Hi Magnus, On Tuesday, 19 June 2018 08:43:31 EEST Magnus Damm wrote: > On Tue, Jun 19, 2018 at 11:15 AM, Laurent Pinchart wrote: > > On Sunday, 17 June 2018 03:08:02 EEST Marek Vasut wrote: > >> On 06/16/2018 05:44 PM, Laurent Pinchart wrote: > >>> On Saturday, 16 June 2018 02:42:30 EEST Marek Vasut wrote: > On 06/16/2018 01:21 AM, Laurent Pinchart wrote: > > On Friday, 15 June 2018 15:00:31 EEST Marek Vasut wrote: > >> On 06/15/2018 01:43 PM, Marek Vasut wrote: [snip] > >>> Yet, I have to wonder if ATF doesn't already contain some sort of > >>> standard SMC call to get memory topology. It surprises me that it > >>> wouldn't. > >> > >> In fact, Laurent (CCed) was solving some similar issue with lossy > >> decomp and I think this involved some passing of memory layout > >> information from ATF to U-Boot too, or am I mistaken ? > > > > That's correct, ATF stores information about the memory layout at a > > fixed address in system memory, and U-Boot can read it. > > Well, that sounds good ! Maybe we can avoid adding SMC call altogether > then? :) > >>> > >>> I'd prefer that, yes. > >>> > >>> Let's not duplicate the mechanism used to pass FCNL information from > >>> ATF to U- Boot, but instead create a data table format that can store > >>> all the information we need, in an easily extensible way. > >>> > >>> To see how the mechanism is implemented for FCNL, search for 47FD7000 > >>> in the Renesas ATF sources > >>> (git://github.com/renesas-rcar/arm-trusted-firmware.git). > >> > >> For everyone involved, can you explain what FCNL is ? ;-) > > > > FCNL is Frame Compression Near Lossless. It's a way to reduce memory > > bandwidth by transparent compression and decompression of video frames. > > Compression is handled by an IP core called FCP, and decompression is > > handled by the DRAM controller. ATF programs the DRAM controller with > > ranges of memory addresses that will be dynamically decompressed. The > > registers containing those ranges are accessible in secure mode only, so > > neither U-Boot nor Linux can read them. That's why ATF has to pass the > > information to U-Boot, in order to add the ranges as reserved memory in > > DT. > > Thanks for the clarification. I wonder how much of the split between > ATF and "the rest" can be adjusted. It smells like just a software > architecture policy, my gut feeling is that LIFEC can be programmed to > adjust the assignment between secure side and "regular". At least it > can do so for a wide range of bus masters. However if this is the case > for FCNL remains to be seen. > > As a side note, for FCNL I personally would prefer a more dynamic > solution where we manage physically contiguous ranges from Linux > during run time instead of relying of statically setup windows. So would I, but whether we can be allowed to access those registers from Linux isn't my decision :-/ > >> Any yes, I agree this sounds good. I had a discussion on the U-Boot IRC > >> about passing the memory configuration around and the result is > >> basically the same -- pass a table from ATF to U-Boot. If there's > >> already something, great. -- Regards, Laurent Pinchart ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB
On Mon, 2018-06-18 at 12:59 -0400, Tom Rini wrote:
> On Wed, Jun 13, 2018 at 03:32:43PM +0800, tien.fong.c...@intel.com
> wrote:
>
> >
> > From: Tien Fong Chee
> >
> > In ARM 64-bits, memory size can be supported is more than 4GB,
> > hence increasing save array is needed to cope with testing larger
> > memory.
> >
> > Signed-off-by: Tien Fong Chee
> > ---
> > common/memsize.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/common/memsize.c b/common/memsize.c
> > index 5670e95..b091203 100644
> > --- a/common/memsize.c
> > +++ b/common/memsize.c
> > @@ -26,7 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
> > long get_ram_size(long *base, long maxsize)
> > {
> > volatile long *addr;
> > - long save[31];
> > + long save[BITS_PER_LONG];
> > long save_base;
> > long cnt;
> > long val;
> Since BITS_PER_LONG is 32 or 64, shouldn't we use B_P_L - 1 here? Or
> are you saying there's also a case where this is wrong on 32bit
> today?
As long as the array is large enough to cope with shifting
implementation, then it should be fine. For 32-bit, only 31 units in
array required for storing 31 shifting values, and this apply for 64-
bit also as long as the implementation of first shifting value is not
change(cnt = (maxsize / sizeof(long)) >> 1).
IMO, for simplifying and safety purpose(may be one day implementation
change to "cnt = (maxsize / sizeof(long))", above B_P_L is still
workable.
> Thanks!
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: Parse HS400 DT properties
> -Original Message- > From: Marek Vasut [mailto:marek.va...@gmail.com] > Sent: 2018年6月19日 12:23 > To: u-boot@lists.denx.de > Cc: Marek Vasut ; Bin Meng > ; Jaehoon Chung ; > Jean-Jacques Hiblot ; Kishon Vijay Abraham I ; > Peng Fan ; Simon Glass > Subject: [PATCH] mmc: Parse HS400 DT properties > > Add HS400 properties parsing support to mmc_of_parse(). > > Signed-off-by: Marek Vasut > Cc: Bin Meng > Cc: Jaehoon Chung > Cc: Jean-Jacques Hiblot > Cc: Kishon Vijay Abraham I > Cc: Peng Fan > Cc: Simon Glass > --- > drivers/mmc/mmc-uclass.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c index > f73f07254b..76225b7939 100644 > --- a/drivers/mmc/mmc-uclass.c > +++ b/drivers/mmc/mmc-uclass.c > @@ -166,6 +166,10 @@ int mmc_of_parse(struct udevice *dev, struct > mmc_config *cfg) > cfg->host_caps |= MMC_CAP(MMC_HS_200); > if (dev_read_bool(dev, "mmc-hs200-1_2v")) > cfg->host_caps |= MMC_CAP(MMC_HS_200); > + if (dev_read_bool(dev, "mmc-hs400-1_8v")) > + cfg->host_caps |= MMC_CAP(MMC_HS_400); > + if (dev_read_bool(dev, "mmc-hs400-1_2v")) > + cfg->host_caps |= MMC_CAP(MMC_HS_400); > > return 0; > } Reviewed-by: Peng Fan > -- > 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] ax25: Switch to CONFIG_BOOTP_PREFER_SERVERIP
2018-06-16 4:12 GMT+08:00 Joe Hershberger : > On Fri, Jun 15, 2018 at 3:29 AM, Alexander Graf wrote: >> The ax25-ae350 target currently uses CONFIG_BOOTP_SERVERIP which means we >> ignore the DHCP provided TFTP ip address. This breaks every case where we >> do now provide a serverip environment variable. >> >> Instead, let's use the new CONFIG_BOOT_PREFER_SERVERIP option to fall back >> to the DHCP provided TFTP IP if no serverip environment variable is set. >> >> Signed-off-by: Alexander Graf > > Acked-by: Joe Hershberger Acked-by: Rick Chen ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmc: Parse HS400 DT properties
Add HS400 properties parsing support to mmc_of_parse(). Signed-off-by: Marek Vasut Cc: Bin Meng Cc: Jaehoon Chung Cc: Jean-Jacques Hiblot Cc: Kishon Vijay Abraham I Cc: Peng Fan Cc: Simon Glass --- drivers/mmc/mmc-uclass.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c index f73f07254b..76225b7939 100644 --- a/drivers/mmc/mmc-uclass.c +++ b/drivers/mmc/mmc-uclass.c @@ -166,6 +166,10 @@ int mmc_of_parse(struct udevice *dev, struct mmc_config *cfg) cfg->host_caps |= MMC_CAP(MMC_HS_200); if (dev_read_bool(dev, "mmc-hs200-1_2v")) cfg->host_caps |= MMC_CAP(MMC_HS_200); + if (dev_read_bool(dev, "mmc-hs400-1_8v")) + cfg->host_caps |= MMC_CAP(MMC_HS_400); + if (dev_read_bool(dev, "mmc-hs400-1_2v")) + cfg->host_caps |= MMC_CAP(MMC_HS_400); return 0; } -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] pinctrl: renesas: Fix register usage in sh_pfc_{read, write}
The sh_pfc_{read,write}() must operate on the register address directly
rather than on an offset, fix this to prevent illegal access.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
drivers/pinctrl/renesas/pfc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/renesas/pfc.c b/drivers/pinctrl/renesas/pfc.c
index 6aa2e13f3e..90011537a8 100644
--- a/drivers/pinctrl/renesas/pfc.c
+++ b/drivers/pinctrl/renesas/pfc.c
@@ -121,7 +121,7 @@ void sh_pfc_write_raw_reg(void __iomem *mapped_reg,
unsigned int reg_width,
u32 sh_pfc_read(struct sh_pfc *pfc, u32 reg)
{
- return sh_pfc_read_raw_reg(pfc->regs + reg, 32);
+ return sh_pfc_read_raw_reg((void __iomem *)(uintptr_t)reg, 32);
}
void sh_pfc_write(struct sh_pfc *pfc, u32 reg, u32 data)
@@ -132,7 +132,7 @@ void sh_pfc_write(struct sh_pfc *pfc, u32 reg, u32 data)
if (pfc->info->unlock_reg)
sh_pfc_write_raw_reg(unlock_reg, 32, ~data);
- sh_pfc_write_raw_reg(pfc->regs + reg, 32, data);
+ sh_pfc_write_raw_reg((void __iomem *)(uintptr_t)reg, 32, data);
}
static void sh_pfc_config_reg_helper(struct sh_pfc *pfc,
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] x86: qemu: do not build car.o with start64.o
Hi Heinrich,
On Tue, Jun 12, 2018 at 11:50 PM, Heinrich Schuchardt
wrote:
> car.o can only be used with start.o, not with start64.o.
>
> So on qemu 64bit it should only be built for 32bit SPL but not for u-boot.
>
> Without this patch but with an unrelated pending patch
> ("x86: Add 64-bit setjmp/longjmp implementation") the
> following error occurred for qemu-x86_64_defconfig:
>
I don't understand why Ivan's setmp/longjmp patch triggers this build
issue. Can you elaborate?
> arch/x86/cpu/built-in.o: In function `car_init':
> arch/x86/cpu/qemu/car.S:25: undefined reference to `car_init_ret'
>
> Signed-off-by: Heinrich Schuchardt
> ---
> arch/x86/cpu/qemu/Makefile | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/cpu/qemu/Makefile b/arch/x86/cpu/qemu/Makefile
> index e5ea92545e3..b1daffd4a32 100644
> --- a/arch/x86/cpu/qemu/Makefile
> +++ b/arch/x86/cpu/qemu/Makefile
> @@ -2,8 +2,11 @@
> #
> # Copyright (C) 2015, Bin Meng
>
> +ifndef CONFIG_$(SPL_)X86_64
> +obj-y += car.o
> +endif
> ifndef CONFIG_EFI_STUB
> -obj-y += car.o dram.o
> +obj-y += dram.o
> endif
> obj-y += qemu.o
> obj-$(CONFIG_QFW) += cpu.o e820.o
> --
BTW: the patch does not apply cleanly on latest u-boot/master. Please
rebase. Thanks!
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer
On Sunday, 17 June 2018 03:08:02 EEST Marek Vasut wrote:
> On 06/16/2018 05:44 PM, Laurent Pinchart wrote:
> > Hi Marek,
> >
> > On Saturday, 16 June 2018 02:42:30 EEST Marek Vasut wrote:
> >> On 06/16/2018 01:21 AM, Laurent Pinchart wrote:
> >>> On Friday, 15 June 2018 15:00:31 EEST Marek Vasut wrote:
> On 06/15/2018 01:43 PM, Marek Vasut wrote:
> > On 06/15/2018 12:37 PM, Ulrich Hecht wrote:
> >> On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut wrote:
> + arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
> + 0, 0, 0, 0, 0, 0, 0, &res);
> >>>
> >>> Will this call work on platforms without patched ATF ?
> >>> (I think not, don't you need to handle return value?)
> >>
> >> I have not actually tested that, but if I understand the ATF code
> >> correctly, unimplemented calls return
> >> SMC_UNK (0x), which should be handled by the default case
> >> (NOP)
> >> below.
> >
> > Which means the board has a memory size of 0 and fails to boot ?
> >
> + switch (res.a0) {
> + case 1:
> + base[0] = 0x04800ULL;
> + size[0] = 0x03800ULL;
> + base[1] = 0x5ULL;
> + size[1] = 0x04000ULL;
> + base[2] = 0x6ULL;
> + size[2] = 0x04000ULL;
> + base[3] = 0x7ULL;
> + size[3] = 0x04000ULL;
> + fdt_fixup_memory_banks(blob, base, size, 4);
> + break;
> + case 2:
> + base[0] = 0x04800ULL;
> + size[0] = 0x07800ULL;
> + base[1] = 0x5ULL;
> + size[1] = 0x08000ULL;
> + fdt_fixup_memory_banks(blob, base, size, 2);
> + break;
> + case 3:
> + base[0] = 0x04800ULL;
> + size[0] = 0x07800ULL;
> + base[1] = 0x5ULL;
> + size[1] = 0x08000ULL;
> + base[2] = 0x6ULL;
> + size[2] = 0x08000ULL;
> + base[3] = 0x7ULL;
> + size[3] = 0x08000ULL;
> + fdt_fixup_memory_banks(blob, base, size, 4);
> + break;
> >>>
> >>> Obvious design question is -- since you're adding new SMC call
> >>> anyway,
> >>> can't the call just return the memory layout table itself, so that
> >>> it
> >>> won't be duplicated both in U-Boot and ATF ?
> >>
> >> My gut feeling was to go with the smallest interface possible.
> >
> > But this doesn't scale. The API here uses some ad-hoc constants to
> > identify memory layout tables which have to be encoded both in ATF and
> > U-Boot, both of which must be kept in sync.
> >
> > The ATF already has those memory layout tables, it's only a matter of
> > passing them to U-Boot. If you do just that, the ad-hoc constants and
> > encoding of tables into U-Boot goes away and in fact simplifies the
> > design.
> >
> > Yet, I have to wonder if ATF doesn't already contain some sort of
> > standard SMC call to get memory topology. It surprises me that it
> > wouldn't.
>
> In fact, Laurent (CCed) was solving some similar issue with lossy
> decomp
> and I think this involved some passing of memory layout information
> from
> ATF to U-Boot too, or am I mistaken ?
> >>>
> >>> That's correct, ATF stores information about the memory layout at a
> >>> fixed
> >>> address in system memory, and U-Boot can read it.
> >>
> >> Well, that sounds good ! Maybe we can avoid adding SMC call altogether
> >> then? :)
> >
> > I'd prefer that, yes.
> >
> > Let's not duplicate the mechanism used to pass FCNL information from ATF
> > to U- Boot, but instead create a data table format that can store all the
> > information we need, in an easily extensible way.
> >
> > To see how the mechanism is implemented for FCNL, search for 47FD7000 in
> > the Renesas ATF sources
> > (git://github.com/renesas-rcar/arm-trusted-firmware.git).
> For everyone involved, can you explain what FCNL is ? ;-)
FCNL is Frame Compression Near Lossless. It's a way to reduce memory bandwidth
by transparent compression and decompression of video frames. Compression is
handled by an IP core called FCP, and decompression is handled by the DRAM
controller. ATF programs the DRAM controller with ranges of memory addresses
that will be
Re: [U-Boot] [PATCH] Makefile: drop unused cpp_cfg macro
2018-06-18 13:59 GMT+09:00 Baruch Siach : > Commit e19b0fb4851f (kbuild: generate u-boot.cfg as a byproduct of > include/autoconf.mk) removed the use of the cpp_cfg macro in Makefile, > but forgot to remove its definition. > > Cc: Masahiro Yamada > Signed-off-by: Baruch Siach > --- Reviewed-by: Masahiro Yamada > Makefile | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/Makefile b/Makefile > index 61ef84576afa..cbee84249b06 100644 > --- a/Makefile > +++ b/Makefile > @@ -1052,11 +1052,6 @@ ifndef CONFIG_SYS_UBOOT_START > CONFIG_SYS_UBOOT_START := 0 > endif > > -# Create a file containing the configuration options the image was built with > -quiet_cmd_cpp_cfg = CFG $@ > -cmd_cpp_cfg = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) -ansi \ > - -DDO_DEPS_ONLY -D__ASSEMBLY__ -x assembler-with-cpp -P -dM -E -o $@ $< > - > # Boards with more complex image requirments can provide an .its source file > # or a generator script > ifneq ($(CONFIG_SPL_FIT_SOURCE),"") > -- > 2.17.1 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] x86: efi-x86_app: Update MAINTAINERS
Previous rename of efi-x86 target missed the MAINTAINERS update, which caused the buildman warnings: WARNING: no status info for 'efi-x86_app' WARNING: no maintainers for 'efi-x86_app' This updates the board MAINTAINERS to reflect the up-to-date info. Signed-off-by: Bin Meng --- board/efi/efi-x86_app/MAINTAINERS | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/board/efi/efi-x86_app/MAINTAINERS b/board/efi/efi-x86_app/MAINTAINERS index a44c7c6..fb8a6b1 100644 --- a/board/efi/efi-x86_app/MAINTAINERS +++ b/board/efi/efi-x86_app/MAINTAINERS @@ -1,6 +1,6 @@ -EFI-X86 BOARD +EFI-X86_APP BOARD M: Simon Glass S: Maintained -F: board/efi/efi-x86/ -F: include/configs/efi-x86.h -F: configs/efi-x86_defconfig +F: board/efi/efi-x86_app/ +F: include/configs/efi-x86_app.h +F: configs/efi-x86_app_defconfig -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
On 06/18/2018 06:59 PM, Tom Rini wrote: > On Sun, Jun 17, 2018 at 02:02:22AM +0200, Marek Vasut wrote: > >> The following changes since commit acaee30608ce203289a180d664b7f0abb2e64ee7: >> >> ARM: DTS: resync a3517.dtsi with Linux 4.17 (2018-06-13 07:49:14 -0400) >> >> are available in the Git repository at: >> >> git://git.denx.de/u-boot-sh.git master >> >> for you to fetch changes up to 891bf67611e93df3f3a6c451d945a7810435ed13: >> >> ARM: rmobile: Disable 4k SF sectors on V3M Eagle (2018-06-16 04:27:28 >> +0200) >> > > There's still a lot of style errors (related to lack of blank lines > after function/struct/union/enum declarations) in > drivers/pinctrl/renesas/pfc-r8a* but I know that can be addressed in a > follow up patch, so, applied to u-boot/master, thanks! That should be addressed in Linux first, since that's where the PFC tables come from. But I think if that were to happen, the result would be completely unreadable. I am open to suggestions though. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] common: bootm: reserve memory bank
> Actually the DRAM is not only seperated in one
> bank. The DRAM bank information is stored in
> gd->bd->bi_dram, so reserve lmb according to
> gd->bd->bi_dram.
>
> Signed-off-by: Jason Zhu
> ---
> common/bootm.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/common/bootm.c b/common/bootm.c
> index e789f68..46689fa 100644
> --- a/common/bootm.c
> +++ b/common/bootm.c
> @@ -53,16 +53,23 @@ __weak void board_quiesce_devices(void)
> #ifdef CONFIG_LMB
> static void boot_start_lmb(bootm_headers_t *images)
> {
> + lmb_init(&images->lmb);
> +#ifdef CONFIG_NR_DRAM_BANKS
> + int i;
> +
> + for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> + lmb_add(&images->lmb, gd->bd->bi_dram[i].start,
> + gd->bd->bi_dram[i].size);
> + }
> +#else
> ulong mem_start;
> phys_size_t mem_size;
>
> - lmb_init(&images->lmb);
> -
> mem_start = env_get_bootm_low();
> mem_size = env_get_bootm_size();
>
> lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
> -
> +#endif
> arch_lmb_reserve(&images->lmb);
> board_lmb_reserve(&images->lmb);
> }
Can you describe a bit how you ran into this problem? Thanks!
> Run the function dram_init_banksize, then the dram is seperated in several
> banks. Sometimes the bank0's size maybe zero. If we call boot_start_lmb
> to reserve lmb which just only reserve bank0, the lmb's memory size is zero.
> This can cause allocate memory error when we want to reserve lmb for fdt.
> So reserve lmb depend on CONFIG_NR_DRAM_BANKS(function dram_init_banksize
> seperates the dram by CONFIG_NR_DRAM_BANKS) but not just bank0.
> Thanks!
jason@rock-chips.com
From: Tom Rini
Date: 2018-06-19 03:02
To: Jason Zhu
CC: Simon Glass; u-boot; Alexander Graf
Subject: Re: [U-Boot] [PATCH] common: bootm: reserve memory bank
On Thu, Jun 14, 2018 at 03:07:25PM +0800, Jason Zhu wrote:
> Actually the DRAM is not only seperated in one
> bank. The DRAM bank information is stored in
> gd->bd->bi_dram, so reserve lmb according to
> gd->bd->bi_dram.
>
> Signed-off-by: Jason Zhu
> ---
> common/bootm.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/common/bootm.c b/common/bootm.c
> index e789f68..46689fa 100644
> --- a/common/bootm.c
> +++ b/common/bootm.c
> @@ -53,16 +53,23 @@ __weak void board_quiesce_devices(void)
> #ifdef CONFIG_LMB
> static void boot_start_lmb(bootm_headers_t *images)
> {
> + lmb_init(&images->lmb);
> +#ifdef CONFIG_NR_DRAM_BANKS
> + int i;
> +
> + for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> + lmb_add(&images->lmb, gd->bd->bi_dram[i].start,
> + gd->bd->bi_dram[i].size);
> + }
> +#else
> ulong mem_start;
> phys_size_t mem_size;
>
> - lmb_init(&images->lmb);
> -
> mem_start = env_get_bootm_low();
> mem_size = env_get_bootm_size();
>
> lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
> -
> +#endif
> arch_lmb_reserve(&images->lmb);
> board_lmb_reserve(&images->lmb);
> }
Can you describe a bit how you ran into this problem? Thanks!
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] x86: Use microcode update from device tree for all processors
On Mon, Jun 18, 2018 at 8:58 PM, Bin Meng wrote: > On Sat, Jun 16, 2018 at 2:01 AM, Ivan Gorinov wrote: >> Built without a ROM image with FSP (u-boot.rom), the U-Boot loader applies >> the microcode update data block encoded in Device Tree to the bootstrap >> processor but not passed to the other CPUs when multiprocessing is enabled. >> >> If the bootstrap processor successfully performs a microcode update >> from Device Tree, use the same data block for the other processors. >> >> Signed-off-by: Ivan Gorinov >> --- >> arch/x86/cpu/i386/cpu.c | 3 ++- >> arch/x86/cpu/intel_common/car.S | 2 ++ >> arch/x86/cpu/intel_common/microcode.c | 10 +++--- >> arch/x86/include/asm/microcode.h | 1 + >> arch/x86/lib/fsp/fsp_car.S| 4 +++- >> 5 files changed, 15 insertions(+), 5 deletions(-) >> > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] rockchip: Reduce prerequisites from the host
On Wed, 13 Jun 2018 11:51:13 +0800, kever.yang at rock-chips.com wrote: >(snip) >I just not understand why remove the dependency on python is so important, >there already many modules depend on python. On Wed, 13 Jun 2018 11:57:48 +0800, kever.yang at rock-chips.com wrote: >(snip) > Could you share why you don't want to use python, can convert the >script to C? Hi Kever, there are several reasons, here are the ones I can think of: 1.- Python is a ~100MB weight dependency. 2.- Because of (1) I don not have it installed by default. 3.- My Linux distribution of choice defaults to python3 but u-boot requires 'python' to be python2. 4.- "Shall use C language whenever possible." http://www.denx.de/wiki/U-Boot/DesignRequirements 5.- It is not just a dependency on what needs to be installed on the host, is also a dependency on which programming languages u-boot's contributors need to know about. So, it can be considered an entry barrier. I don not have strong feelings on this getting merged and certainly will not get upset if it does not. It is entirely your decision. I have submitted this patch series mostly "for your information" and because Philipp thought that it "looks worthwhile": On Fri, 1 Jun 2018 00:37:17 +0200, philipp.tomsich at theobroma-systems.com wrote: >(snip) >> On 1 Jun 2018, at 00:28, Vicente Bergas wrote: >(snip) >> SPL_FIT_GENERATOR and SPL_OF_PLATDATA require python. >> In order to remove this dependency: >> 1.- I have written a C version for SPL_FIT_GENERATOR. >> 2.- Disabled SPL_OF_PLATDATA, it just works. >> >> MKIMAGE_DTC_PATH requires dtc in the PATH. >> In order to remove this dependency, I have changed it to use the built-in >> one. >> >> If there is interest in those changes, I can post the full patch. > >Please submit a patch--it certainly looks worthwhile. Regards, Vicenç. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86
On Mon, Jun 18, 2018 at 03:37:36PM -0400, Tom Rini wrote: > On Sun, Jun 17, 2018 at 09:21:55PM +0800, Bin Meng wrote: > > > Hi Tom, > > > > The following changes since commit a715415bb5948c84cc44c601b193188990f7238b: > > > > Merge branch 'master' of git://git.denx.de/u-boot-usb (2018-06-16 > > 00:07:37 -0400) > > > > are available in the git repository at: > > > > git://git.denx.de/u-boot-x86.git > > > > for you to fetch changes up to 0102023966558075e52758bd22ffd8f96b093a7e: > > > > x86: efi: app: Display correct CPU info during boot (2018-06-17 > > 21:16:04 +0800) > > > > Applied to u-boot/master, thanks! But please follow up with a fix for: WARNING: no status info for 'efi-x86_app' WARNING: no maintainers for 'efi-x86_app' -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Fw: make config Error
From: Karsten Merker To: Duncan Hare Cc: U-Boot Mailing List Sent: Monday, June 18, 2018 11:43 AM Subject: Re: [U-Boot] Fw: make config Error > > In this repository. It might exist elsewhere. > > I generally use raspbian to compile u-boot for the raspberry > pi, and Debian as a file server. This looks very much like either something in the repository setup on your Raspberry Pi is broken or the package mirror you use has problems. According to http://archive.raspbian.org/raspbian/dists/stable/main/binary-armhf/Packages.xz Raspbian/stable definitely has both flex as well as bison in the main repository: Please refresh your local package information with "sudo apt-get update" and retry installing flex and bison. If that doesn't work, please provide your repository configuration, i.e. the contents of /etc/apt/sources.list and /etc/apt/sources.list.d/*, perhaps we can spot the source of your problem there. Good catch. Raspbian and Debian now fail in identical ways.Thanks Regards, Karsten Werbung sowie der Markt- oder Meinungsforschung. Which is: root@debian:/home/duncan/archive/u-boot# make clean root@debian:/home/duncan/archive/u-boot# make menuconfig... duncan@debian:~/archive/u-boot$ make menuconfig HOSTCC scripts/basic/fixdep scripts/basic/fixdep.c:481:1: fatal error: opening dependency file scripts/basic/.fixdep.d: Permission denied } ^ compilation terminated. scripts/Makefile.host:97: recipe for target 'scripts/basic/fixdep' failed make[1]: *** [scripts/basic/fixdep] Error 1 Makefile:410: recipe for target 'scripts_basic' failed make: *** [scripts_basic] Error 2 duncan@debian:~/archive/u-boot$ ^C duncan@debian:~/archive/u-boot$ There is no .fixdep.d file in pi@raspberrypi:~/server/archive/u-boot/scripts/basic $ ls -al total 44 drwxr-xr-x 2 root root 4096 Jun 15 13:17 . drwxr-xr-x 6 root root 4096 Jun 15 08:39 .. -rwxr-xr-x 1 root root 13992 Jun 15 13:14 fixdep -rw-r--r-- 1 root root 12264 Jun 15 08:39 fixdep.c -rw-r--r-- 1 root root 7 Jun 15 08:39 .gitignore -rw-r--r-- 1 root root 706 Jun 15 08:39 Makefile What content and what permissions does u-boot/scripts/basic/fixdep.d require? Duncan har...@synoia.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: mvneta: dcache flush TX descriptors at init
On Sun, Jun 17, 2018 at 6:55 AM, Baruch Siach wrote: > From: Rabeeh Khoury > > This fixes sporadic timeout on initial packet Tx (usually ARP), with an > error message like: > > timeout: packet not sent > > Signed-off-by: Rabeeh Khoury > Signed-off-by: Baruch Siach Acked-by: Joe Hershberger But yes, make sure it is checkpatch-clean. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: mvneta: zero Tx descriptors on init
On Sun, Jun 17, 2018 at 6:55 AM, Baruch Siach wrote: > From: Rabeeh Khoury > > Make the initialization sequence consistent with the Linux kernel > driver. > > Signed-off-by: Rabeeh Khoury > Signed-off-by: Baruch Siach Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Do not shut down clock in start callback
On Mon, Jun 18, 2018 at 3:07 AM, Marek Vasut wrote: > Do not stop the clock in the start callback in case of failure, keep > them running to also keep the PHY running. The failure could be ie. > PHY failing to negotiate link and if the clock get shut down, another > attempt at bringing the link up would fail. The clock right now are > started in probe function and stopped in remove function, which is > the correct behavior. > > Signed-off-by: Marek Vasut > Cc: Nobuhiro Iwamatsu > Cc: Joe Hershberger Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Filter out supported PHY features
On Sun, Jun 17, 2018 at 10:48 PM, Marek Vasut wrote: > The RAVB only supports 100Full and 1000Full operation, it does not support > 10Full or any Half-duplex modes. The PHY could still advertise those features > though, so filter out the PHY features accordingly. > > Signed-off-by: Marek Vasut > Cc: Nobuhiro Iwamatsu > Cc: Joe Hershberger Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] net: ravb: Support reset GPIO both in mac and phy node
On Sun, Jun 17, 2018 at 9:30 PM, Marek Vasut wrote: > The recent DTs have the PHY reset GPIO in the PHY node rather than > the ethernet MAC node, support extracting the PHY reset GPIO info > from both the PHY node and ethernet MAC node. > > Signed-off-by: Marek Vasut > Cc: Nobuhiro Iwamatsu > Cc: Joe Hershberger Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] net: sh_eth: Support reset GPIO both in mac and phy node
On Sun, Jun 17, 2018 at 9:30 PM, Marek Vasut wrote: > The recent DTs have the PHY reset GPIO in the PHY node rather than > the ethernet MAC node, support extracting the PHY reset GPIO info > from both the PHY node and ethernet MAC node. > > Signed-off-by: Marek Vasut > Cc: Nobuhiro Iwamatsu > Cc: Joe Hershberger Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Default script entry using FIT format scripts
I'm trying to get a build going without the legacy image format, but I need boot scripts (and I'm using distro boot). I'm coming unstuck when trying to boot one as there's no way to pass in the FIT unit name to source with distro boot. Would adding a default property inside /images (like we have inside /configurations for bootable images) be a reasonable approach? Trying to add the full configuration machinery feels over the top (though I'm wondering if down the road we want signed scripts if that might preclude it). -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] rockchip: Reduce prerequisites from the host
Vicente, > On 18 Jun 2018, at 22:07, Vicente Bergas wrote: > > On Wed, 13 Jun 2018 11:51:13 +0800, kever.yang at rock-chips.com wrote: >> (snip) >> I just not understand why remove the dependency on python is so important, >> there already many modules depend on python. > > On Wed, 13 Jun 2018 11:57:48 +0800, kever.yang at rock-chips.com wrote: >> (snip) >> Could you share why you don't want to use python, can convert the >> script to C? > > Hi Kever, > there are several reasons, here are the ones I can think of: > 1.- Python is a ~100MB weight dependency. > 2.- Because of (1) I don not have it installed by default. > 3.- My Linux distribution of choice defaults to python3 but > u-boot requires 'python' to be python2. > 4.- "Shall use C language whenever possible." > http://www.denx.de/wiki/U-Boot/DesignRequirements > 5.- It is not just a dependency on what needs to be installed > on the host, is also a dependency on which programming > languages u-boot's contributors need to know about. > So, it can be considered an entry barrier. Given that most of the recent FDT infrastructure (e.g. tools/dtoc) and binman are Python, the overall opinion on Python seems to have changed (and no-one bothered to update the Wiki). That said: the original python-implementation (i.e. the .py tool in the rockchip subdirectory) is a bit unfortunate as well, as any processing of binaries to build a final bootable image should nowadays be included in binman. > I don not have strong feelings on this getting merged and certainly > will not get upset if it does not. It is entirely your decision. > > I have submitted this patch series mostly "for your information" and > because Philipp thought that it "looks worthwhile”: Just for the record: I want to have this patch in the mailing-list archive, so it is archived and can be found by anyone working on this aspect of our bootup in the future. I still stand by my initial assessment that it’s worthwhile to not lose this info and make sure it’s archived ;-) Thanks, Philipp. > On Fri, 1 Jun 2018 00:37:17 +0200, philipp.tomsich at > theobroma-systems.com wrote: >> (snip) >>> On 1 Jun 2018, at 00:28, Vicente Bergas wrote: >> (snip) >>> SPL_FIT_GENERATOR and SPL_OF_PLATDATA require python. >>> In order to remove this dependency: >>> 1.- I have written a C version for SPL_FIT_GENERATOR. >>> 2.- Disabled SPL_OF_PLATDATA, it just works. >>> >>> MKIMAGE_DTC_PATH requires dtc in the PATH. >>> In order to remove this dependency, I have changed it to use the built-in >>> one. >>> >>> If there is interest in those changes, I can post the full patch. >> >> Please submit a patch--it certainly looks worthwhile. > > Regards, > Vicenç. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86
On Sun, Jun 17, 2018 at 09:21:55PM +0800, Bin Meng wrote: > Hi Tom, > > The following changes since commit a715415bb5948c84cc44c601b193188990f7238b: > > Merge branch 'master' of git://git.denx.de/u-boot-usb (2018-06-16 > 00:07:37 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-x86.git > > for you to fetch changes up to 0102023966558075e52758bd22ffd8f96b093a7e: > > x86: efi: app: Display correct CPU info during boot (2018-06-17 > 21:16:04 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] doc: Replace DocBook with sphinx-based docs
On Thu, Jun 14, 2018 at 10:44:53AM +0200, Mario Six wrote: > The Linux kernel moved to sphinx-based documentation and got rid of the > DocBook based documentation quite a while ago. Hence, the DocBook > documentation for U-Boot should be converted as well. > > To achieve this, import the necessary files from Linux v4.17-r6, and > convert the current DocBook documentation (three files altogether) to > sphinx/reStructuredText. > > For now, all old DocBook documentation was merged into a single > handbook, tentatively named "U-Boot Hacker Manual". > > For some source files, the documentation style was changed to comply > with kernel-doc; no functional changes were applied. > > Signed-off-by: Mario Six I like this idea, thanks for doing it. While I wish more stuff was done for DocBook, and rST isn't my favorite style, it's worth I think strongly considering the switch to as I expect some of my own usage issues to be better by now or be addressed sooner rather than later as more people pick up the tools, find problems, and fix them. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] common: bootm: reserve memory bank
On Thu, Jun 14, 2018 at 03:07:25PM +0800, Jason Zhu wrote:
> Actually the DRAM is not only seperated in one
> bank. The DRAM bank information is stored in
> gd->bd->bi_dram, so reserve lmb according to
> gd->bd->bi_dram.
>
> Signed-off-by: Jason Zhu
> ---
> common/bootm.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/common/bootm.c b/common/bootm.c
> index e789f68..46689fa 100644
> --- a/common/bootm.c
> +++ b/common/bootm.c
> @@ -53,16 +53,23 @@ __weak void board_quiesce_devices(void)
> #ifdef CONFIG_LMB
> static void boot_start_lmb(bootm_headers_t *images)
> {
> + lmb_init(&images->lmb);
> +#ifdef CONFIG_NR_DRAM_BANKS
> + int i;
> +
> + for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> + lmb_add(&images->lmb, gd->bd->bi_dram[i].start,
> + gd->bd->bi_dram[i].size);
> + }
> +#else
> ulong mem_start;
> phys_size_t mem_size;
>
> - lmb_init(&images->lmb);
> -
> mem_start = env_get_bootm_low();
> mem_size = env_get_bootm_size();
>
> lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
> -
> +#endif
> arch_lmb_reserve(&images->lmb);
> board_lmb_reserve(&images->lmb);
> }
Can you describe a bit how you ran into this problem? Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/6] mvebu: support UART boot image
The kwboot utility can use the generated image to boot mvebu SoCs from UART. Signed-off-by: Baruch Siach --- arch/arm/mach-mvebu/Kconfig | 3 +++ arch/arm/mach-mvebu/Makefile | 3 +++ 2 files changed, 6 insertions(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 2ee01e9cff81..38eacb24b388 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -193,6 +193,9 @@ config MVEBU_SPL_BOOT_DEVICE_MMC bool "SDIO/MMC card" select SPL_LIBDISK_SUPPORT +config MVEBU_SPL_BOOT_DEVICE_UART + bool "UART" + endchoice config MVEBU_EFUSE diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile index d907fac3752d..ee2eca913484 100644 --- a/arch/arm/mach-mvebu/Makefile +++ b/arch/arm/mach-mvebu/Makefile @@ -35,6 +35,9 @@ endif ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),) KWB_CFG_BOOT_FROM=sdio endif +ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART),) + KWB_CFG_BOOT_FROM=uart +endif ifneq ($(CONFIG_SECURED_MODE_IMAGE),) KWB_REPLACE += CSK_INDEX -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/6] mvebu: select boot device at SoC level
Move the gdsys Controlcenter DC specific build time kwbimage.cfg
generation code into the mach-mvebu/ directory to be shared by all 32bit
mvebu platforms.
Remove board specific kwbimage.cfg files, and use the generated one
instead. These files are all identical, with two exceptions. Clearfog
and Helios4 use the sdio boot device, whereas all others use spi. Update
the defconfigs for the exceptional boards to generate the same
kwbimage.cfg as before.
Signed-off-by: Baruch Siach
---
.../a38x => arch/arm/mach-mvebu}/.gitignore | 0
arch/arm/mach-mvebu/Makefile | 30 ++
arch/arm/mach-mvebu/include/mach/config.h | 4 +--
.../arm/mach-mvebu}/kwbimage.cfg.in | 0
board/CZ.NIC/turris_omnia/kwbimage.cfg| 12 ---
board/Marvell/db-88f6720/kwbimage.cfg | 12 ---
board/Marvell/db-88f6820-amc/kwbimage.cfg | 12 ---
board/Marvell/db-88f6820-gp/kwbimage.cfg | 12 ---
board/Marvell/db-mv784mp-gp/kwbimage.cfg | 12 ---
board/Synology/ds414/kwbimage.cfg | 12 ---
board/gdsys/a38x/Makefile | 31 ---
board/kobol/helios4/kwbimage.cfg | 13
board/maxbcm/kwbimage.cfg | 12 ---
board/solidrun/clearfog/kwbimage.cfg | 12 ---
board/theadorable/kwbimage.cfg| 12 ---
configs/clearfog_defconfig| 2 +-
configs/helios4_defconfig | 2 +-
17 files changed, 34 insertions(+), 156 deletions(-)
rename {board/gdsys/a38x => arch/arm/mach-mvebu}/.gitignore (100%)
rename {board/gdsys/a38x => arch/arm/mach-mvebu}/kwbimage.cfg.in (100%)
delete mode 100644 board/CZ.NIC/turris_omnia/kwbimage.cfg
delete mode 100644 board/Marvell/db-88f6720/kwbimage.cfg
delete mode 100644 board/Marvell/db-88f6820-amc/kwbimage.cfg
delete mode 100644 board/Marvell/db-88f6820-gp/kwbimage.cfg
delete mode 100644 board/Marvell/db-mv784mp-gp/kwbimage.cfg
delete mode 100644 board/Synology/ds414/kwbimage.cfg
delete mode 100644 board/kobol/helios4/kwbimage.cfg
delete mode 100644 board/maxbcm/kwbimage.cfg
delete mode 100644 board/solidrun/clearfog/kwbimage.cfg
delete mode 100644 board/theadorable/kwbimage.cfg
diff --git a/board/gdsys/a38x/.gitignore b/arch/arm/mach-mvebu/.gitignore
similarity index 100%
rename from board/gdsys/a38x/.gitignore
rename to arch/arm/mach-mvebu/.gitignore
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index ade7b870646f..d907fac3752d 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -25,6 +25,36 @@ obj-$(CONFIG_ARMADA_375) +=
../../../drivers/ddr/marvell/axp/xor.o
obj-$(CONFIG_ARMADA_38X) += ../../../drivers/ddr/marvell/a38x/xor.o
obj-$(CONFIG_ARMADA_XP) += ../../../drivers/ddr/marvell/axp/xor.o
obj-$(CONFIG_MVEBU_EFUSE) += efuse.o
+
+extra-y += kwbimage.cfg
+
+KWB_REPLACE += BOOT_FROM
+ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI),)
+ KWB_CFG_BOOT_FROM=spi
+endif
+ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),)
+ KWB_CFG_BOOT_FROM=sdio
+endif
+
+ifneq ($(CONFIG_SECURED_MODE_IMAGE),)
+KWB_REPLACE += CSK_INDEX
+KWB_CFG_CSK_INDEX = $(CONFIG_SECURED_MODE_CSK_INDEX)
+
+KWB_REPLACE += SEC_BOOT_DEV
+KWB_CFG_SEC_BOOT_DEV=$(patsubst "%",%, \
+ $(if $(findstring BOOT_SPI_NOR_FLASH,$(CONFIG_SPL_BOOT_DEVICE)),0x34) \
+ $(if $(findstring BOOT_SDIO_MMC_CARD,$(CONFIG_SPL_BOOT_DEVICE)),0x31) \
+ )
+
+KWB_REPLACE += SEC_FUSE_DUMP
+KWB_CFG_SEC_FUSE_DUMP = a38x
+endif
+
+$(src)/kwbimage.cfg: $(src)/kwbimage.cfg.in include/autoconf.mk \
+ include/config/auto.conf
+ $(Q)sed -ne '$(foreach V,$(KWB_REPLACE),s/^#@$(V)/$(V)
$(KWB_CFG_$(V))/;)p' \
+ <$< >$(dir $<)$(@F)
+
endif # CONFIG_SPL_BUILD
obj-y += gpio.o
obj-y += mbus.o
diff --git a/arch/arm/mach-mvebu/include/mach/config.h
b/arch/arm/mach-mvebu/include/mach/config.h
index 2acfd3314a68..9f51411e43f1 100644
--- a/arch/arm/mach-mvebu/include/mach/config.h
+++ b/arch/arm/mach-mvebu/include/mach/config.h
@@ -32,12 +32,12 @@
#endif
/*
- * By default kwbimage.cfg from board specific folder is used
+ * By default the generated mvebu kwbimage.cfg is used
* If for some board, different configuration file need to be used,
* CONFIG_SYS_KWD_CONFIG should be defined in board specific header file
*/
#ifndef CONFIG_SYS_KWD_CONFIG
-#defineCONFIG_SYS_KWD_CONFIG $(CONFIG_BOARDDIR)/kwbimage.cfg
+#defineCONFIG_SYS_KWD_CONFIG arch/arm/mach-mvebu/kwbimage.cfg
#endif /* CONFIG_SYS_KWD_CONFIG */
/* Add target to build it automatically upon "make" */
diff --git a/board/gdsys/a38x/kwbimage.cfg.in
b/arch/arm/mach-mvebu/kwbimage.cfg.in
similarity index 100%
rename from board/gdsys/a38x/kwbimage.cfg.in
rename to arch/arm/mach-mvebu/kwbimage.cfg.in
diff --git a/board/CZ.NIC/turris_omnia/kwbimage.cfg
b/board/CZ.NIC/turris_omnia/kwbimage.cfg
deleted file mode 100644
index 1f748db37c1e..
--- a/board/CZ.NI
[U-Boot] [PATCH 6/6] mvebu: clearfog: use kconfig symbols to select boot device
This allows selection of the boot device at build time without source code modification. Signed-off-by: Baruch Siach --- include/configs/clearfog.h | 16 ++-- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h index 1141aee08b6e..7d56dfd86e96 100644 --- a/include/configs/clearfog.h +++ b/include/configs/clearfog.h @@ -70,16 +70,6 @@ "initrd_high=0x1000\0" /* SPL */ -/* - * Select the boot device here - * - * Currently supported are: - * SPL_BOOT_SPI_NOR_FLASH - Booting via SPI NOR flash - * SPL_BOOT_SDIO_MMC_CARD - Booting via SDIO/MMC card (partition 1) - */ -#define SPL_BOOT_SPI_NOR_FLASH 1 -#define SPL_BOOT_SDIO_MMC_CARD 2 -#define CONFIG_SPL_BOOT_DEVICE SPL_BOOT_SDIO_MMC_CARD /* Defines for SPL */ #define CONFIG_SPL_SIZE(140 << 10) @@ -96,13 +86,11 @@ #define CONFIG_SPL_STACK (0x4000 + ((192 - 16) << 10)) #define CONFIG_SPL_BOOTROM_SAVE(CONFIG_SPL_STACK + 4) -#if CONFIG_SPL_BOOT_DEVICE == SPL_BOOT_SPI_NOR_FLASH +#if defined(CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI) /* SPL related SPI defines */ #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x2 #define CONFIG_SYS_U_BOOT_OFFS CONFIG_SYS_SPI_U_BOOT_OFFS -#endif - -#if CONFIG_SPL_BOOT_DEVICE == SPL_BOOT_SDIO_MMC_CARD +#elif defined(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC) /* SPL related MMC defines */ #define CONFIG_SYS_MMC_U_BOOT_OFFS (160 << 10) #define CONFIG_SYS_U_BOOT_OFFS CONFIG_SYS_MMC_U_BOOT_OFFS -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/6] mvebu: consolidate SPL boot device config symbols
Use MVEBU_SPL_BOOT_DEVICE_* to select between SPI and MMC, instead of board specific symbols. This commit enables the boot device selection menu to all mvebu platforms, but it is only effective on Turris Omnia and gdsys Controlcenter DC platforms. A following commit will enable boot selection for other platforms. Signed-off-by: Baruch Siach --- arch/arm/Kconfig | 1 - arch/arm/mach-mvebu/Kconfig| 11 --- board/gdsys/a38x/Kconfig | 24 board/gdsys/a38x/Makefile | 4 ++-- include/configs/turris_omnia.h | 4 ++-- 5 files changed, 8 insertions(+), 36 deletions(-) delete mode 100644 board/gdsys/a38x/Kconfig diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 22234cde2ab6..226ac9979207 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1419,7 +1419,6 @@ source "board/freescale/ls1012ardb/Kconfig" source "board/freescale/ls1012afrdm/Kconfig" source "board/freescale/mx35pdk/Kconfig" source "board/freescale/s32v234evb/Kconfig" -source "board/gdsys/a38x/Kconfig" source "board/grinn/chiliboard/Kconfig" source "board/gumstix/pepper/Kconfig" source "board/h2200/Kconfig" diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 9226511f7f91..2ee01e9cff81 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -183,21 +183,18 @@ config SYS_VENDOR config SYS_SOC default "mvebu" -if TARGET_TURRIS_OMNIA - choice - prompt "Turris Omnia boot method" + prompt "Boot method" -config TURRIS_OMNIA_SPL_BOOT_DEVICE_SPI +config MVEBU_SPL_BOOT_DEVICE_SPI bool "SPI NOR flash" -config TURRIS_OMNIA_SPL_BOOT_DEVICE_MMC +config MVEBU_SPL_BOOT_DEVICE_MMC bool "SDIO/MMC card" + select SPL_LIBDISK_SUPPORT endchoice -endif - config MVEBU_EFUSE bool "Enable eFuse support" default n diff --git a/board/gdsys/a38x/Kconfig b/board/gdsys/a38x/Kconfig deleted file mode 100644 index ff11eb2371e8.. --- a/board/gdsys/a38x/Kconfig +++ /dev/null @@ -1,24 +0,0 @@ -if TARGET_CONTROLCENTERDC - -menu "Controlcenter DC board options" - -choice - prompt "Select boot method" - -config SPL_BOOT_DEVICE_SPI - bool "SPI" - -config SPL_BOOT_DEVICE_MMC - bool "MMC" - select SPL_LIBDISK_SUPPORT - -endchoice - -#config SPL_BOOT_DEVICE -# int -# default 1 if SPL_BOOT_DEVICE_SPI -# default 2 if SPL_BOOT_DEVICE_MMC - -endmenu - -endif diff --git a/board/gdsys/a38x/Makefile b/board/gdsys/a38x/Makefile index 43fec2edbb29..18ecbe5e7979 100644 --- a/board/gdsys/a38x/Makefile +++ b/board/gdsys/a38x/Makefile @@ -13,10 +13,10 @@ obj-$(CONFIG_TARGET_CONTROLCENTERDC) += hydra.o ihs_phys.o extra-$(CONFIG_TARGET_CONTROLCENTERDC) += kwbimage.cfg KWB_REPLACE += BOOT_FROM -ifneq ($(CONFIG_SPL_BOOT_DEVICE_SPI),) +ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI),) KWB_CFG_BOOT_FROM=spi endif -ifneq ($(CONFIG_SPL_BOOT_DEVICE_MMC),) +ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),) KWB_CFG_BOOT_FROM=sdio endif diff --git a/include/configs/turris_omnia.h b/include/configs/turris_omnia.h index 9d4d0dfbb29f..44d5016fbf6f 100644 --- a/include/configs/turris_omnia.h +++ b/include/configs/turris_omnia.h @@ -93,13 +93,13 @@ #define CONFIG_SPL_BOOTROM_SAVE(CONFIG_SPL_STACK + 4) #define CONFIG_SPL_DRIVERS_MISC_SUPPORT -#ifdef CONFIG_TURRIS_OMNIA_SPL_BOOT_DEVICE_SPI +#ifdef CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI /* SPL related SPI defines */ # define CONFIG_SYS_SPI_U_BOOT_OFFS0x24000 # define CONFIG_SYS_U_BOOT_OFFSCONFIG_SYS_SPI_U_BOOT_OFFS #endif -#ifdef CONFIG_TURRIS_OMNIA_SPL_BOOT_DEVICE_MMC +#ifdef CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC /* SPL related MMC defines */ # define CONFIG_SYS_MMC_U_BOOT_OFFS(160 << 10) # define CONFIG_SYS_U_BOOT_OFFS CONFIG_SYS_MMC_U_BOOT_OFFS -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/6] mvebu: a38x: drop duplicate platform id symbols
Use generic mvebu Kconfig symbols like all other mvebu boards. Signed-off-by: Baruch Siach --- arch/arm/mach-mvebu/Kconfig | 3 +++ board/gdsys/a38x/Kconfig| 12 2 files changed, 3 insertions(+), 12 deletions(-) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 5415b5a7bfe2..9226511f7f91 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -148,6 +148,7 @@ config SYS_BOARD default "ds414" if TARGET_DS414 default "maxbcm" if TARGET_MAXBCM default "theadorable" if TARGET_THEADORABLE + default "a38x" if TARGET_CONTROLCENTERDC config SYS_CONFIG_NAME default "clearfog" if TARGET_CLEARFOG @@ -163,6 +164,7 @@ config SYS_CONFIG_NAME default "theadorable" if TARGET_THEADORABLE default "turris_omnia" if TARGET_TURRIS_OMNIA default "turris_mox" if TARGET_TURRIS_MOX + default "controlcenterdc" if TARGET_CONTROLCENTERDC config SYS_VENDOR default "Marvell" if TARGET_DB_MV784MP_GP @@ -176,6 +178,7 @@ config SYS_VENDOR default "Synology" if TARGET_DS414 default "CZ.NIC" if TARGET_TURRIS_OMNIA default "CZ.NIC" if TARGET_TURRIS_MOX + default "gdsys" if TARGET_CONTROLCENTERDC config SYS_SOC default "mvebu" diff --git a/board/gdsys/a38x/Kconfig b/board/gdsys/a38x/Kconfig index 3fdef64b5927..ff11eb2371e8 100644 --- a/board/gdsys/a38x/Kconfig +++ b/board/gdsys/a38x/Kconfig @@ -1,17 +1,5 @@ if TARGET_CONTROLCENTERDC -config SYS_BOARD - default "a38x" - -config SYS_VENDOR - default "gdsys" - -config SYS_SOC - default "mvebu" - -config SYS_CONFIG_NAME - default "controlcenterdc" - menu "Controlcenter DC board options" choice -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/6] mvebu: turris_omnia: use u-boot-spl-dtb.bin
u-boot-spl.bin and u-boot-spl-dtb.bin are identical when building the turris_omnia_defconfig. This commit makes Turris Omnia consistent with all other mvebu boards. Signed-off-by: Baruch Siach --- board/CZ.NIC/turris_omnia/kwbimage.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/CZ.NIC/turris_omnia/kwbimage.cfg b/board/CZ.NIC/turris_omnia/kwbimage.cfg index cc057925566c..1f748db37c1e 100644 --- a/board/CZ.NIC/turris_omnia/kwbimage.cfg +++ b/board/CZ.NIC/turris_omnia/kwbimage.cfg @@ -9,4 +9,4 @@ VERSION 1 BOOT_FROM spi # Binary Header (bin_hdr) with DDR3 training code -BINARY spl/u-boot-spl.bin 005b 0068 +BINARY spl/u-boot-spl-dtb.bin 005b 0068 -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/6] mvebu: allow selection of boot device
Currently the boot device that the generated .kwb image supports is
statically set in two places. The BOOT_FROM directive in the per board
kwbimage.cfg file, and the CONFIG_SPL_BOOT_DEVICE macro in the board
config header file.
The gdsys Controlcenter DC supports build time generation of the
kwbimage.cfg file which allows build time selection of the boot device.
This series extends the idea of kwbimage.cfg generation to all 32bit
mvebu SoCs. In addition, this series makes Clearfog use the kconfig
symbols alone for boot selection, so that no code modification is
needed.
The first three patches are cleanup patches that should not change
existing behavior.
The fourth patch extends the kwbimage.cfg build time generation support
to all mvebu platforms.
The fifth patch adds support for boot from UART.
The last patch removes the static CONFIG_SPL_BOOT_DEVICE definition for
Clearfog.
I tested this series on Clearfog Base, booting from SD card, SPI flash,
and UART. I ran a number of build tests for other platforms. I would
appreciate reports of run tests on affected platforms.
Baruch Siach (6):
mvebu: turris_omnia: use u-boot-spl-dtb.bin
mvebu: a38x: drop duplicate platform id symbols
mvebu: consolidate SPL boot device config symbols
mvebu: select boot device at SoC level
mvebu: support UART boot image
mvebu: clearfog: use kconfig symbols to select boot device
arch/arm/Kconfig | 1 -
.../a38x => arch/arm/mach-mvebu}/.gitignore | 0
arch/arm/mach-mvebu/Kconfig | 17 +
arch/arm/mach-mvebu/Makefile | 33 +
arch/arm/mach-mvebu/include/mach/config.h | 4 +--
.../arm/mach-mvebu}/kwbimage.cfg.in | 0
board/CZ.NIC/turris_omnia/kwbimage.cfg| 12 ---
board/Marvell/db-88f6720/kwbimage.cfg | 12 ---
board/Marvell/db-88f6820-amc/kwbimage.cfg | 12 ---
board/Marvell/db-88f6820-gp/kwbimage.cfg | 12 ---
board/Marvell/db-mv784mp-gp/kwbimage.cfg | 12 ---
board/Synology/ds414/kwbimage.cfg | 12 ---
board/gdsys/a38x/Kconfig | 36 ---
board/gdsys/a38x/Makefile | 31
board/kobol/helios4/kwbimage.cfg | 13 ---
board/maxbcm/kwbimage.cfg | 12 ---
board/solidrun/clearfog/kwbimage.cfg | 12 ---
board/theadorable/kwbimage.cfg| 12 ---
configs/clearfog_defconfig| 2 +-
configs/helios4_defconfig | 2 +-
include/configs/clearfog.h| 16 ++---
include/configs/turris_omnia.h| 4 +--
22 files changed, 51 insertions(+), 216 deletions(-)
rename {board/gdsys/a38x => arch/arm/mach-mvebu}/.gitignore (100%)
rename {board/gdsys/a38x => arch/arm/mach-mvebu}/kwbimage.cfg.in (100%)
delete mode 100644 board/CZ.NIC/turris_omnia/kwbimage.cfg
delete mode 100644 board/Marvell/db-88f6720/kwbimage.cfg
delete mode 100644 board/Marvell/db-88f6820-amc/kwbimage.cfg
delete mode 100644 board/Marvell/db-88f6820-gp/kwbimage.cfg
delete mode 100644 board/Marvell/db-mv784mp-gp/kwbimage.cfg
delete mode 100644 board/Synology/ds414/kwbimage.cfg
delete mode 100644 board/gdsys/a38x/Kconfig
delete mode 100644 board/kobol/helios4/kwbimage.cfg
delete mode 100644 board/maxbcm/kwbimage.cfg
delete mode 100644 board/solidrun/clearfog/kwbimage.cfg
delete mode 100644 board/theadorable/kwbimage.cfg
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] dwc2 USB controller hangs with lan78xx
This bug is the combination of dwc2 USB controller and lan78xx USB ethernet controller, which is the combination in use on the Raspberry Pi Model 3 B+. When the host attempts to receive a packet, but a packet has not arrived, the lan78xx controller responds by setting BIR (Bulk-In Empty Response) to NAK. Unfortunately, this hangs the USB controller and requires the USB controller to be reset. The fix proposed is to have the lan78xx controller respond by setting BIR to ZLP. Signed-off-by: Andrew Thomas --- drivers/usb/eth/lan78xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/eth/lan78xx.c b/drivers/usb/eth/lan78xx.c index c5ff379..e8ee665 100644 --- a/drivers/usb/eth/lan78xx.c +++ b/drivers/usb/eth/lan78xx.c @@ -296,7 +296,7 @@ static int lan78xx_basic_reset(struct usb_device *udev, ret = lan7x_read_reg(udev, LAN78XX_USB_CFG0, &val); if (ret) return ret; - val |= LAN78XX_USB_CFG0_BIR; + val &= ~LAN78XX_USB_CFG0_BIR; return lan7x_write_reg(udev, LAN78XX_USB_CFG0, val); } -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/1] dwc2 USB controller hangs with lan78xx
In testing networking with EFI/u-boot, there is an issue where the dwc2 USB controller will hang -- requiring an USB reset. The issue appears to be the programming of the "Bulk-In Empty Response" in the lan78xx controller. The patch is a suggested fix. However, I am not familiar enough with neither the lan78xx nor the dwc2 to know whether this is the best, or even most appropriate, fix. The issue arises readily with EFI/u-boot programs, such as grub: the uboot EFI code will periodically poll the network adapter to see if it has received a packet. Generally speaking no packet has arrived and the attempt to receive will immediatly hang the dwc2 controller. The console will show this message: Rx: failed to receive: -5 Interestingly, the issue will not arise with request/response protocols, such as u-boot's dhcp command. Andrew Thomas (1): dwc2 USB controller hangs with lan78xx drivers/usb/eth/lan78xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] ARM: Provide workaround setup bits for CVE-2017-5715 (A8/A15)
On Tue, Jun 12, 2018 at 03:24:07PM -0500, Nishanth Menon wrote: > Hi, > > This is a follow on from https://marc.info/?l=u-boot&m=151691688828176&w=2 > (RFC) > > NOTE: > * As per ARM recommendations[2], and discussions in list[1] ARM > Cortex-A9/12/17 do not need additional steps in u-boot to enable the > OS level workarounds. > * This itself is'nt a complete solution and is based on recommendation > This from Arm[2] for variant 2 CVE-2017-5715 -> Kernel changes can be seen > on > linux next (next-20180612) or on linux master (upcoming v4.18-rc1 tag). > * I think it is necessary on older SoCs without firmware support > (such as older OMAPs and AM*) to have kernel support mirroring what we do in > u-boot to support additional cores AND/OR low power states where contexts > are > lost (assuming ACR states are'nt saved). just my 2 cents. > > Few of the tests (with linux next-20180612): > AM571-IDK: https://pastebin.ubuntu.com/p/sr5X6sN3Tr/ (single core A15) > OMAP5-uEVM: https://pastebin.ubuntu.com/p/9yDM22bJ6n/ (dual core A15) > OMAP3-beagle-xm: https://pastebin.ubuntu.com/p/9DfDkpyxym/ (Single A8) > AM335x-Beaglebone-black: https://pastebin.ubuntu.com/p/DczT9jPMwb/ (Single A8) > > Nishanth Menon (4): > ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for > CVE-2017-5715 > ARM: Introduce ability to enable invalidate of BTB with ICIALLU on > Cortex-A15 for CVE-2017-5715 > ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of > BTB) to facilitate CVE_2017-5715 WA in OS > ARM: mach-omap2: omap3/am335x: Enable ACR::IBE on Cortex-A8 SoCs for > CVE-2017-5715 > > arch/arm/Kconfig| 9 + > arch/arm/cpu/armv7/start.S | 15 +-- > arch/arm/mach-omap2/Kconfig | 3 +++ > 3 files changed, 25 insertions(+), 2 deletions(-) > > [1] https://marc.info/?t=15163990652&r=1&w=2 > [2] https://developer.arm.com/support/security-update > [3] https://marc.info/?t=15154379047&r=1&w=2 and the latest in: > https://marc.info/?l=linux-arm-kernel&m=151689379521082&w=2 > [4] > > https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6 > https://www.op-tee.org/security-advisories/ > https://www.linaro.org/blog/meltdown-spectre/ This series of changes for U-Boot, if I can briefly summarize the feedback as I understand it, is that yes, this is correct and is a part of what is required to work around the issues, but only covers as much of the system as U-Boot can cover leaving other parts of the software stack (still) in need of fixes. Yes? If so, is there anything else that should be done before in U-Boot we grab these changes? Would any of the knowledgeable but not usually U-Boot folks on CC feel comfortable adding an ack/reviewed-by to the series? Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] fit: allow fit to call hardware accelerated hash
On Wed, Jun 06, 2018 at 05:03:57PM +0100, Ben Whitten wrote:
> Move to calling the abstraction which allows for hardware acceleration.
> We also remove unneeded defines and only include objects if required.
>
> Signed-off-by: Ben Whitten
[snip]
> diff --git a/common/image-fit.c b/common/image-fit.c
> index 8c15ed1..7d8c961 100644
> --- a/common/image-fit.c
> +++ b/common/image-fit.c
> @@ -1082,26 +1082,17 @@ int fit_set_timestamp(void *fit, int noffset, time_t
> timestamp)
> int calculate_hash(const void *data, int data_len, const char *algo,
> uint8_t *value, int *value_len)
> {
> - if (IMAGE_ENABLE_CRC32 && strcmp(algo, "crc32") == 0) {
> - *((uint32_t *)value) = crc32_wd(0, data, data_len,
> - CHUNKSZ_CRC32);
> - *((uint32_t *)value) = cpu_to_uimage(*((uint32_t *)value));
> - *value_len = 4;
> - } else if (IMAGE_ENABLE_SHA1 && strcmp(algo, "sha1") == 0) {
> - sha1_csum_wd((unsigned char *)data, data_len,
> - (unsigned char *)value, CHUNKSZ_SHA1);
> - *value_len = 20;
> - } else if (IMAGE_ENABLE_SHA256 && strcmp(algo, "sha256") == 0) {
> - sha256_csum_wd((unsigned char *)data, data_len,
> -(unsigned char *)value, CHUNKSZ_SHA256);
> - *value_len = SHA256_SUM_LEN;
> - } else if (IMAGE_ENABLE_MD5 && strcmp(algo, "md5") == 0) {
> - md5_wd((unsigned char *)data, data_len, value, CHUNKSZ_MD5);
> - *value_len = 16;
> - } else {
> + struct hash_algo *hash_algo;
> + int ret;
> +
> + ret = hash_lookup_algo(algo, &hash_algo);
This is unfortunately not code equivalent. There's a little bit missing
to switch this over to using SPL_CRC32_SUPPORT as well. A good test
would be to make sure that a sunxi platform still builds after this (it
doesn't currently with the series) and use buildman -Ssdel to compare
before/after sizes and make sure it's a tiny change in size related to
the code switch and not a huge change due to droppped (or added!)
support. Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB
On Wed, Jun 13, 2018 at 03:32:43PM +0800, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> In ARM 64-bits, memory size can be supported is more than 4GB,
> hence increasing save array is needed to cope with testing larger memory.
>
> Signed-off-by: Tien Fong Chee
> ---
> common/memsize.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/common/memsize.c b/common/memsize.c
> index 5670e95..b091203 100644
> --- a/common/memsize.c
> +++ b/common/memsize.c
> @@ -26,7 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
> long get_ram_size(long *base, long maxsize)
> {
> volatile long *addr;
> - long save[31];
> + long save[BITS_PER_LONG];
> long save_base;
> long cnt;
> long val;
Since BITS_PER_LONG is 32 or 64, shouldn't we use B_P_L - 1 here? Or
are you saying there's also a case where this is wrong on 32bit today?
Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 00/35] phy: sunxi: Add Allwinner sun4i USB PHY
On Sun, Jun 17, 2018 at 11:13:23PM -0700, Vasily Khoruzhick wrote: > On Sun, Jun 17, 2018 at 11:04 PM, Jagan Teki wrote: > >> Do git pull and make sure you are at least at > >> a715415bb5948c84cc44c601b193188990f7238b. > > > > Yes, I even tried on this, can't see any issue? Let me know If I still miss > > any. > > > > U-Boot 2018.07-rc1-00165-ga715415bb5 (Jun 18 2018 - 11:28:28 +0530) > > Allwinner Technology > > > > CPU: Allwinner A64 (SUN50I) > > Model: BananaPi-M64 > > DRAM: 2 GiB > > MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 > > Loading Environment from FAT... Unable to use mmc 1:3... Failed (-5) > > In:serial > > Out: serial > > Err: serial > > Allwinner mUSB OTG (Peripheral) > > Net: > > Warning: usb_ether using MAC address from ROM > > eth0: usb_ether > > starting USB... > > USB0: USB EHCI 1.00 > > USB1: USB OHCI 1.0 > > USB2: USB EHCI 1.00 > > USB3: USB OHCI 1.0 > > scanning bus 0 for devices... 1 USB Device(s) found > > scanning bus 2 for devices... 4 USB Device(s) found > >scanning usb for storage devices... 0 Storage Device(s) found > > Hit any key to stop autoboot: 0 > > => usb info > > 1: Hub, USB Revision 2.0 > > - u-boot EHCI Host Controller > > - Class: Hub > > - PacketSize: 64 Configurations: 1 > > - Vendor: 0x Product 0x Version 1.0 > >Configuration: 1 > >- Interfaces: 1 Self Powered 0mA > > Interface: 0 > > - Alternate Setting 0, Endpoints: 1 > > - Class Hub > > - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms > > > > 1: Hub, USB Revision 2.0 > > - u-boot EHCI Host Controller > > - Class: Hub > > - PacketSize: 64 Configurations: 1 > > - Vendor: 0x Product 0x Version 1.0 > >Configuration: 1 > >- Interfaces: 1 Self Powered 0mA > > Interface: 0 > > - Alternate Setting 0, Endpoints: 1 > > - Class Hub > > - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms > > > > 2: Hub, USB Revision 2.0 > > - USB 2.0 Hub > > - Class: Hub > > - PacketSize: 64 Configurations: 1 > > - Vendor: 0x1a40 Product 0x0101 Version 1.17 > >Configuration: 1 > >- Interfaces: 1 Self Powered Remote Wakeup 100mA > > Interface: 0 > > - Alternate Setting 0, Endpoints: 1 > > - Class Hub > > - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms > > > > 3: Human Interface, USB Revision 1.10 > > - Dell KB216 Wired Keyboard > > - Class: (from Interface) Human Interface > > - PacketSize: 8 Configurations: 1 > > - Vendor: 0x413c Product 0x2113 Version 1.8 > >Configuration: 1 > >- Interfaces: 2 Bus Powered Remote Wakeup 100mA > > Interface: 0 > > - Alternate Setting 0, Endpoints: 1 > > - Class Human Interface, Subclass: Boot Keyboard > > - Endpoint 1 In Interrupt MaxPacket 8 Interval 24ms > > Interface: 1 > > - Alternate Setting 0, Endpoints: 1 > > - Class Human Interface, Subclass: None > > - Endpoint 2 In Interrupt MaxPacket 8 Interval 48ms > > Leave this one plugged in. > > > 4: Human Interface, USB Revision 2.0 > > - Logitech USB Receiver > > - Class: (from Interface) Human Interface > > - PacketSize: 32 Configurations: 1 > > - Vendor: 0x046d Product 0xc52b Version 36.1 > >Configuration: 1 > >- Interfaces: 3 Bus Powered Remote Wakeup 98mA > >- String: "RQR24.01_B0023" > > Interface: 0 > > - Alternate Setting 0, Endpoints: 1 > > - Class Human Interface, Subclass: Boot Keyboard > > - Endpoint 1 In Interrupt MaxPacket 8 Interval 8ms > > Interface: 1 > > - Alternate Setting 0, Endpoints: 1 > > - Class Human Interface, Subclass: Boot Mouse > > - Endpoint 2 In Interrupt MaxPacket 8 Interval 2ms > > Interface: 2 > > - Alternate Setting 0, Endpoints: 1 > > - Class Human Interface, Subclass: None > > - Endpoint 3 In Interrupt MaxPacket 32 Interval 2ms > > Unplug this one. > > Make sure that you have CONFIG_USB_KEYBOARD in your config and then > run 'usb reset' (or try booting Linux). Yes, I would also like to see how this particular case works out. It seems quite possible that in some of the cases where Jagan's tests work we might well be getting by with some previous (partial) initialization being close-to-enough. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
On Sun, Jun 17, 2018 at 02:02:22AM +0200, Marek Vasut wrote: > The following changes since commit acaee30608ce203289a180d664b7f0abb2e64ee7: > > ARM: DTS: resync a3517.dtsi with Linux 4.17 (2018-06-13 07:49:14 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to 891bf67611e93df3f3a6c451d945a7810435ed13: > > ARM: rmobile: Disable 4k SF sectors on V3M Eagle (2018-06-16 04:27:28 > +0200) > There's still a lot of style errors (related to lack of blank lines after function/struct/union/enum declarations) in drivers/pinctrl/renesas/pfc-r8a* but I know that can be addressed in a follow up patch, so, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: sunxi: ohci: make ohci_t the first member in private data
On Mon, Jun 18, 2018 at 11:45:23AM +0530, Jagan Teki wrote:
> On Mon, Jun 18, 2018 at 6:44 AM, Marek Vasut wrote:
> > On 06/17/2018 06:13 PM, Vasily Khoruzhick wrote:
> >> ohci-hcd casts priv_data pointer to (ohci_t *), thus it must be
> >> the first member in private data struct.
> >>
> >> Fixes 831cc98b1 ("usb: sunxi: Simplify ccm reg base code")
> >>
> >> Signed-off-by: Vasily Khoruzhick
> >
> > Sigh, I really wonder how (or if at all!) the original series was
> > tested. And then I get flak for scrutinizing patches, right ...
>
> APAIK, I did basic sanity with possible tests.
>
> But one thing for sure is, you should have to wait for sometime to
> apply this patch. Applying fast (that to during weekend) making
> reviewers or maintainers not giving enough room to work.
It is a custodian's job to pick up what they see as obviously correct
and/or important fixes ASAP. While things are working in your test
cases, there are clearly other hardware combinations that are not
working and that this corrects.
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [UBOOT PATCH v2 1/3] spi: xilinx: Read reg base address from DTS file
On Tue, Jun 12, 2018 at 11:34 AM, Vipul Kumar wrote:
> From: Michal Simek
>
> This patch added support to read register base address
> from DTS file.
This patch also adding fifo_depth apart from reg.
>
> Signed-off-by: Michal Simek
> Signed-off-by: Vipul Kumar
> ---
> drivers/spi/xilinx_spi.c | 24 +---
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
> index 8f0f32f..615106b 100644
> --- a/drivers/spi/xilinx_spi.c
> +++ b/drivers/spi/xilinx_spi.c
> @@ -77,10 +77,6 @@
> #define CONFIG_XILINX_SPI_IDLE_VAL GENMASK(7, 0)
> #endif
>
> -#ifndef CONFIG_SYS_XILINX_SPI_LIST
> -#define CONFIG_SYS_XILINX_SPI_LIST { CONFIG_SYS_SPI_BASE }
> -#endif
> -
> /* xilinx spi register set */
> struct xilinx_spi_regs {
> u32 __space0__[7];
> @@ -105,16 +101,14 @@ struct xilinx_spi_priv {
> struct xilinx_spi_regs *regs;
> unsigned int freq;
> unsigned int mode;
> + unsigned int fifo_depth;
> };
>
> -static unsigned long xilinx_spi_base_list[] = CONFIG_SYS_XILINX_SPI_LIST;
> static int xilinx_spi_probe(struct udevice *bus)
> {
> struct xilinx_spi_priv *priv = dev_get_priv(bus);
> struct xilinx_spi_regs *regs = priv->regs;
>
> - priv->regs = (struct xilinx_spi_regs *)xilinx_spi_base_list[bus->seq];
> -
> writel(SPISSR_RESET_VALUE, ®s->srr);
>
> return 0;
> @@ -285,6 +279,21 @@ static const struct dm_spi_ops xilinx_spi_ops = {
> .set_mode = xilinx_spi_set_mode,
> };
>
> +static int xilinx_spi_ofdata_to_platdata(struct udevice *bus)
> +{
> + struct xilinx_spi_priv *priv = dev_get_priv(bus);
> + struct udevice *dev = dev_get_parent(bus);
> +
> + priv->regs = (struct xilinx_spi_regs *)devfdt_get_addr(bus);
Since the driver has OF_CONTROL support, better to get reg into probe
and skip platdata.
> +
> + debug("%s: regs=%p\n", __func__, priv->regs);
> +
> + priv->fifo_depth = fdtdec_get_int(gd->fdt_blob, dev_of_offset(bus),
> + "fifo-size", 0);
Where this using? better to add it separate patch along with usage code.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] cl-som-imx7: Remove CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
From: Fabio Estevam
Since commit 1da1938d57b3 ("spl: Add default values for ARCH_MX7")
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is selected by default on
i.MX7 platforms, so remove it from the board defconfig.
Signed-off-by: Fabio Estevam
---
configs/cl-som-imx7_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/configs/cl-som-imx7_defconfig b/configs/cl-som-imx7_defconfig
index 6d403ee..38be7db 100644
--- a/configs/cl-som-imx7_defconfig
+++ b/configs/cl-som-imx7_defconfig
@@ -17,7 +17,6 @@
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
CONFIG_SPI_BOOT=y
CONFIG_BOOTDELAY=3
CONFIG_SPL_BOARD_INIT=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x80
CONFIG_SPL_I2C_SUPPORT=y
CONFIG_SPL_SPI_LOAD=y
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 00/21] sandbox: efi_loader support
On 06/18/2018 05:22 PM, Alexander Graf wrote:
This patch set augments Simon's patch set for efi_loader support
in sandbox[1], but cuts off the memory allocation scheme at a different
point.
According to the UEFI spec, efi_allocate_pages() takes a uint64_t *
argument. Via this argument, we get a physical address as input, but
emit a pointer as output.
With this patch set in place, I can successfully run the selftest suite
as well as an aarch64 grub.efi binary. X86_64 grub.efi doesn't work
because that one requires inl instructions to work.
I've assembled a quick grub.efi that does work in sandbox as it no
longer accesses I/O ports directly. Patch for it is below.
http://csgraf.de/tmp2/grub.efi
When building your own, make sure to exclude coreboot (cb*) modules -
they seem to do something dirty and segfault for me. The other modules
seem to work fine for me so far.
Alex
diff --git a/grub-core/kern/i386/tsc.c b/grub-core/kern/i386/tsc.c
index f266eb131..99fc9f7fb 100644
--- a/grub-core/kern/i386/tsc.c
+++ b/grub-core/kern/i386/tsc.c
@@ -68,7 +68,7 @@ grub_tsc_init (void)
#ifdef GRUB_MACHINE_XEN
(void) (grub_tsc_calibrate_from_xen () || calibrate_tsc_hardcode());
#elif defined (GRUB_MACHINE_EFI)
- (void) (grub_tsc_calibrate_from_pmtimer () ||
grub_tsc_calibrate_from_pit () || grub_tsc_calibrate_from_efi() ||
calibrate_tsc_hardcode());
+ (void) (grub_tsc_calibrate_from_efi() || calibrate_tsc_hardcode());
#elif defined (GRUB_MACHINE_COREBOOT)
(void) (grub_tsc_calibrate_from_pmtimer () ||
grub_tsc_calibrate_from_pit () || calibrate_tsc_hardcode());
#else
diff --git a/include/grub/i386/io.h b/include/grub/i386/io.h
index ae12a3e3d..9fbeef916 100644
--- a/include/grub/i386/io.h
+++ b/include/grub/i386/io.h
@@ -26,47 +26,40 @@ typedef unsigned short int grub_port_t;
static __inline unsigned char
grub_inb (unsigned short int port)
{
- unsigned char _v;
+ unsigned char _v = 0;
- __asm__ __volatile__ ("inb %w1,%0":"=a" (_v):"Nd" (port));
return _v;
}
static __inline unsigned short int
grub_inw (unsigned short int port)
{
- unsigned short _v;
+ unsigned short _v = 0;
- __asm__ __volatile__ ("inw %w1,%0":"=a" (_v):"Nd" (port));
return _v;
}
static __inline unsigned int
grub_inl (unsigned short int port)
{
- unsigned int _v;
+ unsigned int _v = 0;
- __asm__ __volatile__ ("inl %w1,%0":"=a" (_v):"Nd" (port));
return _v;
}
static __inline void
grub_outb (unsigned char value, unsigned short int port)
{
- __asm__ __volatile__ ("outb %b0,%w1": :"a" (value), "Nd" (port));
}
static __inline void
grub_outw (unsigned short int value, unsigned short int port)
{
- __asm__ __volatile__ ("outw %w0,%w1": :"a" (value), "Nd" (port));
-
}
static __inline void
grub_outl (unsigned int value, unsigned short int port)
{
- __asm__ __volatile__ ("outl %0,%w1": :"a" (value), "Nd" (port));
}
#endif /* _SYS_IO_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: sunxi: ohci: make ohci_t the first member in private data
On Mon, Jun 18, 2018 at 12:39 AM, Jagan Teki wrote: >> >From what I see in the other thread, the USB never worked with the >> series. If the controller returns 0s as EHCI version, something is >> obviously broken and I don't even understand how that could be an >> acceptable positive test result. The USB HCD version register can NOT >> EVER contain zeroes as per the specification. I am really unhappy here. > > This is untrue, the controller returns 0's only when single node > enabled not with both ehci0 and echi1 atleast on BPI-M64. and we do > enable both controller on dts even with other boards too. having > single node enablement is not a proper test or not with my dts > atleast. Clock for EHCI0 or OHCI0 was never enabled on your series, so reading USB HCD version for EHCI0/OHCI0 always returned 0 and you should have seen 0.0 as version for EHCI0 and OHCI0. With both nodes enabled you had only EHCI1/OHCI1 functional. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 00/21] sandbox: efi_loader support
This patch set augments Simon's patch set for efi_loader support in sandbox[1], but cuts off the memory allocation scheme at a different point. According to the UEFI spec, efi_allocate_pages() takes a uint64_t * argument. Via this argument, we get a physical address as input, but emit a pointer as output. With this patch set in place, I can successfully run the selftest suite as well as an aarch64 grub.efi binary. X86_64 grub.efi doesn't work because that one requires inl instructions to work. Alex [1] https://patchwork.ozlabs.org/project/uboot/list/?series=49832 v1 -> v2: - only compile efi_add_known_memory if efi_loader is enabled - clarify address vs pointer in fs_read patch - include mapmem.h v2 -> v3: - removed: efi_loader: Pass address to fs_read() - new: fs: Convert fs_read/write to take buffer instead of address - new: efi_loader: Introduce ms abi vararg helpers - new: sandbox: Enable 1:1 map - new: distro: Move to compiler based target architecture determination - new: efi_loader: Move to compiler based target architecture determination - new: sandbox: Allow to execute from RAM - new: sandbox: Fix setjmp/longjmp v3 -> v4: - remove 1:1 map again - switch to U-Boot addresses exposed in memory tables - new: elf: Move x86 reloc defines to common elf.h - new: sandbox: Always allocate aligned buffers - new: efi_loader: Expose U-Boot addresses in memory map for sandbox Alexander Graf (16): efi_loader: Use compiler constants for image loader efi_loader: Use map_sysmem() in bootefi command efi.h: Do not use config options efi_loader: Allow SMBIOS tables in highmem sandbox: Map host memory for efi_loader efi_loader: Disable miniapps on sandbox fs: Convert fs_read/write to take buffer instead of address efi_loader: Introduce ms abi vararg helpers distro: Move to compiler based target architecture determination efi_loader: Move to compiler based target architecture determination sandbox: Fix setjmp/longjmp elf: Move x86 reloc defines to common elf.h efi_loader: Use common elf.h reloc defines sandbox: Allow to execute from RAM sandbox: Always allocate aligned buffers efi_loader: Expose U-Boot addresses in memory map for sandbox Heinrich Schuchardt (1): efi_loader: efi_allocate_pages is too restrictive Simon Glass (4): efi: sandbox: Add distroboot support efi: sandbox: Add relocation constants efi: sandbox: Enable EFI loader for sandbox efi: sandbox: Adjust memory usage for sandbox arch/sandbox/cpu/cpu.c| 20 arch/sandbox/cpu/os.c | 39 +++--- arch/sandbox/include/asm/setjmp.h | 4 +++- arch/x86/include/asm/elf.h| 45 --- arch/x86/lib/reloc_ia32_efi.c | 1 - arch/x86/lib/reloc_x86_64_efi.c | 1 - board/BuR/common/common.c | 2 +- board/gdsys/p1022/controlcenterd-id.c | 10 cmd/bootefi.c | 13 ++ cmd/mvebu/bubt.c | 4 ++-- common/splash_source.c| 4 +++- drivers/bootcount/bootcount_ext.c | 12 +- drivers/fpga/zynqpl.c | 8 --- fs/fs.c | 20 include/config_distro_bootcmd.h | 17 - include/efi.h | 25 ++- include/elf.h | 35 +++ include/fs.h | 12 +- include/os.h | 19 +++ lib/efi/Makefile | 4 ++-- lib/efi_loader/Kconfig| 2 +- lib/efi_loader/efi_boottime.c | 36 ++-- lib/efi_loader/efi_file.c | 6 ++--- lib/efi_loader/efi_image_loader.c | 12 +- lib/efi_loader/efi_memory.c | 28 ++ lib/efi_loader/efi_runtime.c | 21 lib/efi_loader/efi_smbios.c | 11 +++-- lib/efi_selftest/Makefile | 2 +- 28 files changed, 228 insertions(+), 185 deletions(-) delete mode 100644 arch/x86/include/asm/elf.h -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 10/21] fs: Convert fs_read/write to take buffer instead of address
The fs_read() and fs_write() functions are internal interfaces that
naturally want to get pointers as arguments. Most users so far even
have pointers and explicitly cast them into integers just to be able
to pass them into the function.
Convert them over to instead take a pointer argument for the buffer.
That way any sandbox mapping gets greatly simplified and users of
the API intuitively know what to do.
Signed-off-by: Alexander Graf
---
board/BuR/common/common.c | 2 +-
board/gdsys/p1022/controlcenterd-id.c | 10 +-
cmd/mvebu/bubt.c | 4 ++--
common/splash_source.c| 4 +++-
drivers/bootcount/bootcount_ext.c | 12 ++--
drivers/fpga/zynqpl.c | 8 +---
fs/fs.c | 20 ++--
include/fs.h | 12 ++--
lib/efi_loader/efi_file.c | 6 ++
9 files changed, 40 insertions(+), 38 deletions(-)
diff --git a/board/BuR/common/common.c b/board/BuR/common/common.c
index 9df19791c2..ab9d9c51cf 100644
--- a/board/BuR/common/common.c
+++ b/board/BuR/common/common.c
@@ -269,7 +269,7 @@ static int load_devicetree(void)
puts("load_devicetree: set_blk_dev failed.\n");
return -1;
}
- rc = fs_read(dtbname, (u32)dtbaddr, 0, 0, &dtbsize);
+ rc = fs_read(dtbname, (u_char *)dtbaddr, 0, 0, &dtbsize);
#endif
if (rc == 0) {
gd->fdt_blob = (void *)dtbaddr;
diff --git a/board/gdsys/p1022/controlcenterd-id.c
b/board/gdsys/p1022/controlcenterd-id.c
index 7e082dff05..2f01f7b7eb 100644
--- a/board/gdsys/p1022/controlcenterd-id.c
+++ b/board/gdsys/p1022/controlcenterd-id.c
@@ -874,7 +874,7 @@ static struct key_program *load_key_chunk(const char
*ifname,
if (fs_set_blk_dev(ifname, dev_part_str, fs_type))
goto failure;
- if (fs_read(path, (ulong)buf, 0, 12, &i) < 0)
+ if (fs_read(path, buf, 0, 12, &i) < 0)
goto failure;
if (i < 12)
goto failure;
@@ -890,7 +890,7 @@ static struct key_program *load_key_chunk(const char
*ifname,
goto failure;
if (fs_set_blk_dev(ifname, dev_part_str, fs_type))
goto failure;
- if (fs_read(path, (ulong)result, 0,
+ if (fs_read(path, result, 0,
sizeof(struct key_program) + header.code_size, &i) < 0)
goto failure;
if (i <= 0)
@@ -1019,7 +1019,7 @@ static int second_stage_init(void)
struct key_program *hmac_blob = NULL;
const char *image_path = "/ccdm.itb";
char *mac_path = NULL;
- ulong image_addr;
+ u8 *image_addr;
loff_t image_size;
uint32_t err;
@@ -1059,7 +1059,7 @@ static int second_stage_init(void)
strcat(mac_path, mac_suffix);
/* read image from mmcdev (ccdm.itb) */
- image_addr = (ulong)get_image_location();
+ image_addr = get_image_location();
if (fs_set_blk_dev("mmc", mmcdev, FS_TYPE_EXT))
goto failure;
if (fs_read(image_path, image_addr, 0, 0, &image_size) < 0)
@@ -1077,7 +1077,7 @@ static int second_stage_init(void)
puts("corrupted mac file\n");
goto failure;
}
- if (check_hmac(hmac_blob, (u8 *)image_addr, image_size)) {
+ if (check_hmac(hmac_blob, image_addr, image_size)) {
puts("image integrity could not be verified\n");
goto failure;
}
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index b4d371f305..29fff898fa 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -209,7 +209,7 @@ static size_t mmc_read_file(const char *file_name)
}
/* Perfrom file read */
- rc = fs_read(file_name, get_load_addr(), 0, 0, &act_read);
+ rc = fs_read(file_name, (void *)get_load_addr(), 0, 0, &act_read);
if (rc)
return 0;
@@ -392,7 +392,7 @@ static size_t usb_read_file(const char *file_name)
}
/* Perfrom file read */
- rc = fs_read(file_name, get_load_addr(), 0, 0, &act_read);
+ rc = fs_read(file_name, (void *)get_load_addr(), 0, 0, &act_read);
if (rc)
return 0;
diff --git a/common/splash_source.c b/common/splash_source.c
index 62763b9ebd..79dbea12fc 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -252,7 +253,8 @@ static int splash_load_fs(struct splash_location *location,
u32 bmp_load_addr)
}
splash_select_fs_dev(location);
- res = fs_read(splash_file, bmp_load_addr, 0, 0, &actread);
+ res = fs_read(splash_file, map_sysmem(bmp_load_addr, bmp_size),
+ 0, 0, &actread);
out:
if (location->ubivol != NULL)
diff --git a/drivers/bootcount/bootcount_ext.c
b/drivers/bootcount/bootcount_ext.c
index 075e590896..
[U-Boot] [PATCH v4 12/21] efi: sandbox: Enable EFI loader for sandbox
From: Simon Glass This allows this feature to build within sandbox. This is for testing purposes only since it is not possible for sandbox to load native code. Signed-off-by: Simon Glass Signed-off-by: Alexander Graf --- lib/efi_loader/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index df58e633d1..d471e6f4a4 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,6 +1,6 @@ config EFI_LOADER bool "Support running EFI Applications in U-Boot" - depends on (ARM || X86 || RISCV) && OF_LIBFDT + depends on (ARM || X86 || RISCV || SANDBOX) && OF_LIBFDT # We do not support bootefi booting ARMv7 in non-secure mode depends on !ARMV7_NONSEC # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 09/21] efi_loader: Disable miniapps on sandbox
In the sandbox environment we can not easily build efi stub binaries right now, so let's disable the respective test cases for the efi selftest suite. Signed-off-by: Alexander Graf Reviewed-by: Simon Glass --- lib/efi_selftest/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile index 4fe404d88d..bf5c8199cb 100644 --- a/lib/efi_selftest/Makefile +++ b/lib/efi_selftest/Makefile @@ -41,7 +41,7 @@ endif # TODO: As of v2018.01 the relocation code for the EFI application cannot # be built on x86_64. -ifeq ($(CONFIG_X86_64),) +ifeq ($(CONFIG_X86_64)$(CONFIG_SANDBOX),) ifneq ($(CONFIG_CMD_BOOTEFI_SELFTEST),) -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 18/21] efi: sandbox: Adjust memory usage for sandbox
From: Simon Glass
With sandbox the U-Boot code is not mapped into the sandbox memory range
so does not need to be excluded when allocating EFI memory. Update the EFI
memory init code to take account of that.
Signed-off-by: Simon Glass
[agraf: Remove map_sysmem() call]
Signed-off-by: Alexander Graf
---
lib/efi_loader/efi_memory.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index ce29bcc6a3..19492df518 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -496,14 +497,13 @@ __weak void efi_add_known_memory(void)
}
}
-int efi_memory_init(void)
+/* Add memory regions for U-Boot's memory and for the runtime services code */
+static void add_u_boot_and_runtime(void)
{
unsigned long runtime_start, runtime_end, runtime_pages;
unsigned long uboot_start, uboot_pages;
unsigned long uboot_stack_size = 16 * 1024 * 1024;
- efi_add_known_memory();
-
/* Add U-Boot */
uboot_start = (gd->start_addr_sp - uboot_stack_size) & ~EFI_PAGE_MASK;
uboot_pages = (gd->ram_top - uboot_start) >> EFI_PAGE_SHIFT;
@@ -516,6 +516,14 @@ int efi_memory_init(void)
runtime_pages = (runtime_end - runtime_start) >> EFI_PAGE_SHIFT;
efi_add_memory_map(runtime_start, runtime_pages,
EFI_RUNTIME_SERVICES_CODE, false);
+}
+
+int efi_memory_init(void)
+{
+ efi_add_known_memory();
+
+ if (!IS_ENABLED(CONFIG_SANDBOX))
+ add_u_boot_and_runtime();
#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
/* Request a 32bit 64MB bounce buffer region */
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 21/21] efi_loader: Expose U-Boot addresses in memory map for sandbox
We currently expose host addresses in the EFI memory map. That can be
bad if we ever want to use sandbox to boot strap a real kernel, because
then the kernel would fetch its memory table from our host virtual address
map. But to make that use case work, we would need to have full control
over the address space the EFI application sees.
So let's expose only U-Boot addresses to the guest until we get to the
point of allocation. EFI's allocation functions are fun - they can take
U-Boot addresses as input values for hints and return host addresses as
allocation results through the same uint64_t * parameter. So we need to
be extra careful on what to pass in when.
With this patch I am successfully able to run the efi selftest suite as
well as grub.efi on aarch64.
Signed-off-by: Alexander Graf
---
arch/sandbox/cpu/cpu.c | 19 ---
lib/efi_loader/efi_memory.c | 12 ++--
2 files changed, 6 insertions(+), 25 deletions(-)
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 641b66a0a7..be88ab2f1c 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -176,25 +176,6 @@ void longjmp(jmp_buf jmp, int ret)
#if CONFIG_IS_ENABLED(EFI_LOADER)
-/*
- * In sandbox, we don't have a 1:1 map, so we need to expose
- * process addresses instead of U-Boot addresses
- */
-void efi_add_known_memory(void)
-{
- u64 ram_start = (uintptr_t)map_sysmem(0, gd->ram_size);
- u64 ram_size = gd->ram_size;
- u64 start = (ram_start + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
- u64 pages = (ram_size + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
-
- efi_add_memory_map(start, pages, EFI_CONVENTIONAL_MEMORY,
- false);
-}
-
-#endif
-
-#if CONFIG_IS_ENABLED(EFI_LOADER)
-
void allow_unaligned(void)
{
int r;
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 19492df518..64d2b8f7fa 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -326,7 +326,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
/* Reserve that map in our memory maps */
ret = efi_add_memory_map(addr, pages, memory_type, true);
if (ret == addr) {
- *memory = addr;
+ *memory = (uintptr_t)map_sysmem(addr, pages *
EFI_PAGE_SIZE);
} else {
/* Map would overlap, bail out */
r = EFI_OUT_OF_RESOURCES;
@@ -360,11 +360,12 @@ void *efi_alloc(uint64_t len, int memory_type)
efi_status_t efi_free_pages(uint64_t memory, efi_uintn_t pages)
{
uint64_t r = 0;
+ uint64_t addr = map_to_sysmem((void*)(uintptr_t)memory);
- r = efi_add_memory_map(memory, pages, EFI_CONVENTIONAL_MEMORY, false);
+ r = efi_add_memory_map(addr, pages, EFI_CONVENTIONAL_MEMORY, false);
/* Merging of adjacent free regions is missing */
- if (r == memory)
+ if (r == addr)
return EFI_SUCCESS;
return EFI_NOT_FOUND;
@@ -381,9 +382,9 @@ efi_status_t efi_free_pages(uint64_t memory, efi_uintn_t
pages)
efi_status_t efi_allocate_pool(int pool_type, efi_uintn_t size, void **buffer)
{
efi_status_t r;
- efi_physical_addr_t t;
u64 num_pages = (size + sizeof(struct efi_pool_allocation) +
EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
+ struct efi_pool_allocation *alloc;
if (size == 0) {
*buffer = NULL;
@@ -391,10 +392,9 @@ efi_status_t efi_allocate_pool(int pool_type, efi_uintn_t
size, void **buffer)
}
r = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES, pool_type, num_pages,
- &t);
+ (uint64_t*)&alloc);
if (r == EFI_SUCCESS) {
- struct efi_pool_allocation *alloc = (void *)(uintptr_t)t;
alloc->num_pages = num_pages;
*buffer = alloc->data;
}
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 07/21] sandbox: Map host memory for efi_loader
With efi_loader we do not control payload applications, so we can not
teach them about the difference between virtual and physical addresses.
Instead, let's just always map host virtual addresses in the efi memory
map. That way we can be sure that all memory allocation functions always
return consumable pointers.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- only compile efi_add_known_memory if efi_loader is enabled
v3 -> v4:
- don't compile efi mapping code in for spl
---
arch/sandbox/cpu/cpu.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index cde0b055a6..29dac8dfda 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -5,6 +5,7 @@
#define DEBUG
#include
#include
+#include
#include
#include
#include
@@ -177,3 +178,22 @@ void longjmp(jmp_buf jmp, int ret)
while (1)
;
}
+
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+
+/*
+ * In sandbox, we don't have a 1:1 map, so we need to expose
+ * process addresses instead of U-Boot addresses
+ */
+void efi_add_known_memory(void)
+{
+ u64 ram_start = (uintptr_t)map_sysmem(0, gd->ram_size);
+ u64 ram_size = gd->ram_size;
+ u64 start = (ram_start + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
+ u64 pages = (ram_size + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
+
+ efi_add_memory_map(start, pages, EFI_CONVENTIONAL_MEMORY,
+ false);
+}
+
+#endif
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 11/21] efi_loader: Introduce ms abi vararg helpers
Varargs differ between sysv and ms abi. On x86_64 we have to follow the ms
abi though, so we also need to make sure we use x86_64 varargs helpers.
This patch introduces generic efi vararg helpers that adhere to the
respective EFI ABI. That way we can deal with them properly from efi
loader code and properly interpret variable arguments.
This fixes the InstallMultipleProtocolInterfaces tests in the efi selftests
on x86_64 for me.
Signed-off-by: Alexander Graf
---
include/efi.h | 8
lib/efi_loader/efi_boottime.c | 36 ++--
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/include/efi.h b/include/efi.h
index 826d484977..7be7798d8d 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -22,8 +22,16 @@
/* EFI on x86_64 uses the Microsoft ABI which is not the default for GCC */
#ifdef __x86_64__
#define EFIAPI __attribute__((ms_abi))
+#define efi_va_list __builtin_ms_va_list
+#define efi_va_start __builtin_ms_va_start
+#define efi_va_arg __builtin_va_arg
+#define efi_va_end __builtin_ms_va_end
#else
#define EFIAPI asmlinkage
+#define efi_va_list va_list
+#define efi_va_start va_start
+#define efi_va_arg va_arg
+#define efi_va_end va_end
#endif /* __x86_64__ */
struct efi_device_path;
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 50d311548e..404743fe01 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -2273,7 +2273,7 @@ static efi_status_t EFIAPI
efi_install_multiple_protocol_interfaces(
{
EFI_ENTRY("%p", handle);
- va_list argptr;
+ efi_va_list argptr;
const efi_guid_t *protocol;
void *protocol_interface;
efi_status_t r = EFI_SUCCESS;
@@ -2282,12 +2282,12 @@ static efi_status_t EFIAPI
efi_install_multiple_protocol_interfaces(
if (!handle)
return EFI_EXIT(EFI_INVALID_PARAMETER);
- va_start(argptr, handle);
+ efi_va_start(argptr, handle);
for (;;) {
- protocol = va_arg(argptr, efi_guid_t*);
+ protocol = efi_va_arg(argptr, efi_guid_t*);
if (!protocol)
break;
- protocol_interface = va_arg(argptr, void*);
+ protocol_interface = efi_va_arg(argptr, void*);
r = EFI_CALL(efi_install_protocol_interface(
handle, protocol,
EFI_NATIVE_INTERFACE,
@@ -2296,19 +2296,19 @@ static efi_status_t EFIAPI
efi_install_multiple_protocol_interfaces(
break;
i++;
}
- va_end(argptr);
+ efi_va_end(argptr);
if (r == EFI_SUCCESS)
return EFI_EXIT(r);
/* If an error occurred undo all changes. */
- va_start(argptr, handle);
+ efi_va_start(argptr, handle);
for (; i; --i) {
- protocol = va_arg(argptr, efi_guid_t*);
- protocol_interface = va_arg(argptr, void*);
+ protocol = efi_va_arg(argptr, efi_guid_t*);
+ protocol_interface = efi_va_arg(argptr, void*);
EFI_CALL(efi_uninstall_protocol_interface(handle, protocol,
protocol_interface));
}
- va_end(argptr);
+ efi_va_end(argptr);
return EFI_EXIT(r);
}
@@ -2332,7 +2332,7 @@ static efi_status_t EFIAPI
efi_uninstall_multiple_protocol_interfaces(
{
EFI_ENTRY("%p", handle);
- va_list argptr;
+ efi_va_list argptr;
const efi_guid_t *protocol;
void *protocol_interface;
efi_status_t r = EFI_SUCCESS;
@@ -2341,12 +2341,12 @@ static efi_status_t EFIAPI
efi_uninstall_multiple_protocol_interfaces(
if (!handle)
return EFI_EXIT(EFI_INVALID_PARAMETER);
- va_start(argptr, handle);
+ efi_va_start(argptr, handle);
for (;;) {
- protocol = va_arg(argptr, efi_guid_t*);
+ protocol = efi_va_arg(argptr, efi_guid_t*);
if (!protocol)
break;
- protocol_interface = va_arg(argptr, void*);
+ protocol_interface = efi_va_arg(argptr, void*);
r = EFI_CALL(efi_uninstall_protocol_interface(
handle, protocol,
protocol_interface));
@@ -2354,20 +2354,20 @@ static efi_status_t EFIAPI
efi_uninstall_multiple_protocol_interfaces(
break;
i++;
}
- va_end(argptr);
+ efi_va_end(argptr);
if (r == EFI_SUCCESS)
return EFI_EXIT(r);
/* If an error occurred undo all changes. */
- va_start(argptr, handle);
+ efi_va_start(argptr, handle);
for (; i; --i) {
- protocol = va_arg(argptr, efi_guid_t*);
- protocol
[U-Boot] [PATCH v4 13/21] distro: Move to compiler based target architecture determination
Thanks to CONFIG_SANDBOX, we can not rely on config options to tell us what CPU architecture we're running on. The compiler however does know that, so let's just move the ifdefs over to compiler based defines rather than kconfig based options. Signed-off-by: Alexander Graf --- v3 -> v4: - Compile fix for dts --- include/config_distro_bootcmd.h | 30 +++--- 1 file changed, 11 insertions(+), 19 deletions(-) diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index 1bd79ae3b8..c35a42f6c5 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -245,35 +245,27 @@ #if defined(CONFIG_CMD_DHCP) #if defined(CONFIG_EFI_LOADER) /* http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml */ -#if defined(CONFIG_ARM64) +#if defined(__aarch64__) #define BOOTENV_EFI_PXE_ARCH "0xb" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00011:UNDI:003000" -#elif defined(CONFIG_ARM) +#elif defined(__arm__) #define BOOTENV_EFI_PXE_ARCH "0xa" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00010:UNDI:003000" - -/* For sandbox we only support 64-bit x86 at present */ -#elif defined(CONFIG_X86) -/* Always assume we're running 64bit */ +#elif defined(__x86_64__) #define BOOTENV_EFI_PXE_ARCH "0x7" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:7:UNDI:003000" -#elif defined(CONFIG_CPU_RISCV_32) +#elif defined(__i386__) +#define BOOTENV_EFI_PXE_ARCH "0x0" +#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:0:UNDI:003000" +#elif defined(__riscv) && (__riscv_xlen == 32) #define BOOTENV_EFI_PXE_ARCH "0x19" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00025:UNDI:003000" -#elif defined(CONFIG_CPU_RISCV_64) +#elif defined(__riscv) && (__riscv_xlen == 64) #define BOOTENV_EFI_PXE_ARCH "0x1b" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00027:UNDI:003000" -#elif defined(CONFIG_SANDBOX) -/* - * TODO(s...@chromium.org): Consider providing a way to enable sandbox features - * based on the host architecture - */ -# ifndef __x86_64__ -# warning "sandbox EFI support is only tested on 64-bit x86" -# endif -/* To support other *host* architectures this should be changed */ -#define BOOTENV_EFI_PXE_ARCH "0x7" -#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:7:UNDI:003000" +#elif defined(__ASSEMBLY__) +#define BOOTENV_EFI_PXE_ARCH "0xff" +#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00255:UNDI:003000" #else #error Please specify an EFI client identifier #endif -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 17/21] efi_loader: Use common elf.h reloc defines
Now that elf.h contains relocation defines for all architectures we care about, let's just include it unconditionally and refer to the defines. Signed-off-by: Alexander Graf --- lib/efi_loader/efi_runtime.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c index bc44e43745..dd3ff8ad23 100644 --- a/lib/efi_loader/efi_runtime.c +++ b/lib/efi_loader/efi_runtime.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include @@ -33,18 +34,16 @@ static efi_status_t __efi_runtime EFIAPI efi_invalid_parameter(void); * header for each arch (or a generic header) rather than being repeated here. */ #if defined(__aarch64__) -#define R_RELATIVE 1027 +#define R_RELATIVE R_AARCH64_RELATIVE #define R_MASK 0xULL #define IS_RELA1 #elif defined(__arm__) -#define R_RELATIVE 23 +#define R_RELATIVE R_ARM_RELATIVE #define R_MASK 0xffULL #elif defined(__x86_64__) || defined(__i386__) -#include #define R_RELATIVE R_386_RELATIVE #define R_MASK 0xffULL #elif defined(__riscv) -#include #define R_RELATIVE R_RISCV_RELATIVE #define R_MASK 0xffULL #define IS_RELA1 -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 15/21] sandbox: Fix setjmp/longjmp
In sandbox, longjmp returns to itself in an endless loop. Cut this through
by calling the real OS function.
Setjmp on the other hand must not return. So here we have to call the OS
setjmp function straight from the code where the setjmp call happens.
Signed-off-by: Alexander Graf
---
arch/sandbox/cpu/cpu.c| 5 -
arch/sandbox/cpu/os.c | 20 ++--
arch/sandbox/include/asm/setjmp.h | 4 +++-
3 files changed, 5 insertions(+), 24 deletions(-)
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 29dac8dfda..9087026d71 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -167,11 +167,6 @@ ulong timer_get_boot_us(void)
return (count - base_count) / 1000;
}
-int setjmp(jmp_buf jmp)
-{
- return os_setjmp((ulong *)jmp, sizeof(*jmp));
-}
-
void longjmp(jmp_buf jmp, int ret)
{
os_longjmp((ulong *)jmp, ret);
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 5839932b00..9cfdc9f31f 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -630,24 +630,8 @@ void os_localtime(struct rtc_time *rt)
rt->tm_isdst = tm->tm_isdst;
}
-int os_setjmp(ulong *jmp, int size)
-{
- jmp_buf dummy;
-
- /*
-* We cannot rely on the struct name that jmp_buf uses, so use a
-* local variable here
-*/
- if (size < sizeof(dummy)) {
- printf("setjmp: jmpbuf is too small (%d bytes, need %d)\n",
- size, sizeof(jmp_buf));
- return -ENOSPC;
- }
-
- return setjmp((struct __jmp_buf_tag *)jmp);
-}
-
void os_longjmp(ulong *jmp, int ret)
{
- longjmp((struct __jmp_buf_tag *)jmp, ret);
+ /* Call the OS longjmp function directly */
+ _longjmp((struct __jmp_buf_tag *)jmp, ret);
}
diff --git a/arch/sandbox/include/asm/setjmp.h
b/arch/sandbox/include/asm/setjmp.h
index 1fe37c91cc..e103d170e0 100644
--- a/arch/sandbox/include/asm/setjmp.h
+++ b/arch/sandbox/include/asm/setjmp.h
@@ -24,7 +24,9 @@ struct jmp_buf_data {
typedef struct jmp_buf_data jmp_buf[1];
-int setjmp(jmp_buf jmp);
+/* Call the OS setjmp function directly, so that we don't introduce returns */
+#define setjmp _setjmp
+int _setjmp(jmp_buf jmp);
__noreturn void longjmp(jmp_buf jmp, int ret);
#endif /* _SETJMP_H_ */
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 20/21] sandbox: Always allocate aligned buffers
In some code paths we check whether host virtual addresses are sane.
That only works if at least alignments between host and U-Boot address
spaces match.
So let's always map U-Boot addresses with 64kb alignment. That should
be enough to ensure that the actual RAM ends up in a different page
from the header on all architectures.
Signed-off-by: Alexander Graf
---
arch/sandbox/cpu/os.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 9fa79a8843..4dc6483922 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -143,14 +143,15 @@ void os_tty_raw(int fd, bool allow_sigs)
void *os_malloc(size_t length)
{
struct os_mem_hdr *hdr;
+ size_t alloc_length = length + (64 * 1024);
- hdr = mmap(NULL, length + sizeof(*hdr), PROT_READ | PROT_WRITE,
+ hdr = mmap(NULL, alloc_length, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (hdr == MAP_FAILED)
return NULL;
hdr->length = length;
- return hdr + 1;
+ return (void*)hdr + (64 * 1024);
}
void os_free(void *ptr)
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 05/21] efi.h: Do not use config options
Currently efi.h determines a few bits of its environment according to
config options. This falls apart with the efi stub support which may
result in efi.h getting pulled into the stub as well as real U-Boot
code. In that case, one may be 32bit while the other one is 64bit.
This patch changes the conditionals to use compiler provided defines
instead. That way we always adhere to the build environment we're in
and the definitions adjust automatically.
Signed-off-by: Alexander Graf
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Signed-off-by: Bin Meng
---
include/efi.h| 17 -
lib/efi/Makefile | 4 ++--
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/include/efi.h b/include/efi.h
index e30a3c51c6..826d484977 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -19,12 +19,12 @@
#include
#include
-#if CONFIG_EFI_STUB_64BIT || (!defined(CONFIG_EFI_STUB) && defined(__x86_64__))
-/* EFI uses the Microsoft ABI which is not the default for GCC */
+/* EFI on x86_64 uses the Microsoft ABI which is not the default for GCC */
+#ifdef __x86_64__
#define EFIAPI __attribute__((ms_abi))
#else
#define EFIAPI asmlinkage
-#endif
+#endif /* __x86_64__ */
struct efi_device_path;
@@ -32,16 +32,7 @@ typedef struct {
u8 b[16];
} efi_guid_t;
-#define EFI_BITS_PER_LONG BITS_PER_LONG
-
-/*
- * With 64-bit EFI stub, EFI_BITS_PER_LONG has to be 64. EFI_STUB is set
- * in lib/efi/Makefile, when building the stub.
- */
-#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB)
-#undef EFI_BITS_PER_LONG
-#define EFI_BITS_PER_LONG 64
-#endif
+#define EFI_BITS_PER_LONG (sizeof(long) * 8)
/* Bit mask for EFI status code with error */
#define EFI_ERROR_MASK (1UL << (EFI_BITS_PER_LONG - 1))
diff --git a/lib/efi/Makefile b/lib/efi/Makefile
index 18d081ac46..ece7907227 100644
--- a/lib/efi/Makefile
+++ b/lib/efi/Makefile
@@ -7,9 +7,9 @@ obj-$(CONFIG_EFI_STUB) += efi_info.o
CFLAGS_REMOVE_efi_stub.o := -mregparm=3 \
$(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
-CFLAGS_efi_stub.o := -fpic -fshort-wchar -DEFI_STUB
+CFLAGS_efi_stub.o := -fpic -fshort-wchar
CFLAGS_REMOVE_efi.o := -mregparm=3 \
$(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
-CFLAGS_efi.o := -fpic -fshort-wchar -DEFI_STUB
+CFLAGS_efi.o := -fpic -fshort-wchar
extra-$(CONFIG_EFI_STUB) += efi_stub.o efi.o
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 08/21] efi_loader: efi_allocate_pages is too restrictive
From: Heinrich Schuchardt
When running on the sandbox the stack is not necessarily at a higher memory
address than the highest free memory.
There is no reason why the checking of the highest memory address should be
more restrictive for EFI_ALLOCATE_ANY_PAGES than for
EFI_ALLOCATE_MAX_ADDRESS.
Signed-off-by: Heinrich Schuchardt
[agraf: use -1ULL instead]
Signed-off-by: Alexander Graf
---
lib/efi_loader/efi_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index ec66af98ea..ce29bcc6a3 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -295,7 +295,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
switch (type) {
case EFI_ALLOCATE_ANY_PAGES:
/* Any page */
- addr = efi_find_free_memory(len, gd->start_addr_sp);
+ addr = efi_find_free_memory(len, -1ULL);
if (!addr) {
r = EFI_NOT_FOUND;
break;
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 19/21] sandbox: Allow to execute from RAM
With efi_loader, we may want to execute payloads from RAM. By default,
permissions on the RAM region don't allow us to execute from there though.
So whenever we get into the efi_loader case, let's mark RAM as executable.
That way we still protect normal cases, but allow for efi binaries to
directly get executed from within RAM.
For this, we hook into the already existing allow_unaligned() call which
also transitions the system over into semantics required by the UEFI
specification.
Signed-off-by: Alexander Graf
---
arch/sandbox/cpu/cpu.c | 14 ++
arch/sandbox/cpu/os.c | 14 ++
include/os.h | 19 +++
3 files changed, 47 insertions(+)
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 9087026d71..641b66a0a7 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -192,3 +192,17 @@ void efi_add_known_memory(void)
}
#endif
+
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+
+void allow_unaligned(void)
+{
+ int r;
+
+ r = os_mprotect(gd->arch.ram_buf, gd->ram_size,
+ OS_PROT_READ | OS_PROT_WRITE | OS_PROT_EXEC);
+
+ assert(!r);
+}
+
+#endif
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 9cfdc9f31f..9fa79a8843 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -183,6 +183,20 @@ void *os_realloc(void *ptr, size_t length)
return buf;
}
+int os_mprotect(void *ptr, size_t length, int prot)
+{
+ int p = 0;
+
+ if (prot & OS_PROT_READ)
+ p |= PROT_READ;
+ if (prot & OS_PROT_WRITE)
+ p |= PROT_WRITE;
+ if (prot & OS_PROT_EXEC)
+ p |= PROT_EXEC;
+
+ return mprotect(ptr, length, p);
+}
+
void os_usleep(unsigned long usec)
{
usleep(usec);
diff --git a/include/os.h b/include/os.h
index c8e0f52d30..d451e12064 100644
--- a/include/os.h
+++ b/include/os.h
@@ -157,6 +157,25 @@ void os_free(void *ptr);
void *os_realloc(void *ptr, size_t length);
/**
+ * Modify protection of a memory region
+ *
+ * This function changes the memory protection scheme of a given memory
+ * region. Using it you can for example allow execution of memory that
+ * would otherwise prohibit it.
+ *
+ * \param ptr Pointer to memory region to modify
+ * \param length New length for memory block
+ * \param prot New protection scheme (ORed OS_PROT_ values)
+ * \return 0 on success, -1 otherwise.
+ */
+int os_mprotect(void *ptr, size_t length, int prot);
+
+/* Defines for "prot" in os_mprotect() */
+#define OS_PROT_READ 0x1
+#define OS_PROT_WRITE 0x2
+#define OS_PROT_EXEC 0x4
+
+/**
* Access to the usleep function of the os
*
* \param usec Time to sleep in micro seconds
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 14/21] efi_loader: Move to compiler based target architecture determination
Thanks to CONFIG_SANDBOX, we can not rely on config options to tell us
what CPU architecture we're running on.
The compiler however does know that, so let's just move the ifdefs over
to compiler based defines rather than kconfig based options.
Signed-off-by: Alexander Graf
---
lib/efi_loader/efi_runtime.c | 26 --
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 388dfb9840..bc44e43745 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -32,18 +32,18 @@ static efi_status_t __efi_runtime EFIAPI
efi_invalid_parameter(void);
* TODO(s...@chromium.org): These defines and structs should come from the elf
* header for each arch (or a generic header) rather than being repeated here.
*/
-#if defined(CONFIG_ARM64)
+#if defined(__aarch64__)
#define R_RELATIVE 1027
#define R_MASK 0xULL
#define IS_RELA1
-#elif defined(CONFIG_ARM)
+#elif defined(__arm__)
#define R_RELATIVE 23
#define R_MASK 0xffULL
-#elif defined(CONFIG_X86)
+#elif defined(__x86_64__) || defined(__i386__)
#include
#define R_RELATIVE R_386_RELATIVE
#define R_MASK 0xffULL
-#elif defined(CONFIG_RISCV)
+#elif defined(__riscv)
#include
#define R_RELATIVE R_RISCV_RELATIVE
#define R_MASK 0xffULL
@@ -55,25 +55,15 @@ struct dyn_sym {
u32 foo2;
u32 foo3;
};
-#ifdef CONFIG_CPU_RISCV_32
+#if (__riscv_xlen == 32)
#define R_ABSOLUTE R_RISCV_32
#define SYM_INDEX 8
-#else
+#elif (__riscv_xlen == 64)
#define R_ABSOLUTE R_RISCV_64
#define SYM_INDEX 32
+#else
+#error unknown riscv target
#endif
-
-/* For sandbox we only support 64-bit x86 at present */
-#elif defined(CONFIG_SANDBOX)
-/*
- * TODO(s...@chromium.org): Consider providing a way to enable sandbox features
- * based on the host architecture
- */
-# ifndef __x86_64__
-# warning "sandbox EFI support is only tested on 64-bit x86"
-# endif
-#define R_RELATIVE 8
-#define R_MASK 0xULL
#else
#error Need to add relocation awareness
#endif
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 04/21] efi_loader: Use map_sysmem() in bootefi command
The bootefi command gets a few addresses as values passed in. In sandbox,
these values are in U-Boot address space, so we need to make sure we
explicitly call map_sysmem() on them to be able to access them.
Signed-off-by: Alexander Graf
Reviewed-by: Simon Glass
---
cmd/bootefi.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index f55a40dc84..a86a2bd4a9 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -389,7 +390,8 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
unsigned long addr;
char *saddr;
efi_status_t r;
- void *fdt_addr;
+ unsigned long fdt_addr;
+ void *fdt;
/* Allow unaligned memory access */
allow_unaligned();
@@ -406,11 +408,12 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
return CMD_RET_USAGE;
if (argc > 2) {
- fdt_addr = (void *)simple_strtoul(argv[2], NULL, 16);
+ fdt_addr = simple_strtoul(argv[2], NULL, 16);
if (!fdt_addr && *argv[2] != '0')
return CMD_RET_USAGE;
/* Install device tree */
- r = efi_install_fdt(fdt_addr);
+ fdt = map_sysmem(fdt_addr, 0);
+ r = efi_install_fdt(fdt);
if (r != EFI_SUCCESS) {
printf("ERROR: failed to install device tree\n");
return CMD_RET_FAILURE;
@@ -429,7 +432,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
addr = simple_strtoul(saddr, NULL, 16);
else
addr = CONFIG_SYS_LOAD_ADDR;
- memcpy((char *)addr, __efi_helloworld_begin, size);
+ memcpy(map_sysmem(addr, size), __efi_helloworld_begin, size);
} else
#endif
#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
@@ -475,7 +478,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
printf("## Starting EFI application at %08lx ...\n", addr);
- r = do_bootefi_exec((void *)addr, bootefi_device_path,
+ r = do_bootefi_exec(map_sysmem(addr, 0), bootefi_device_path,
bootefi_image_path);
printf("## Application terminated, r = %lu\n",
r & ~EFI_ERROR_MASK);
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 16/21] elf: Move x86 reloc defines to common elf.h
We need to know about x86 relocation definitions even in cases where we don't officially build against the x86 target, such as with sandbox. So let's move the x86 definitions into the common elf header, where all other architectures already have them. Signed-off-by: Alexander Graf --- arch/x86/include/asm/elf.h | 45 - arch/x86/lib/reloc_ia32_efi.c | 1 - arch/x86/lib/reloc_x86_64_efi.c | 1 - include/elf.h | 35 4 files changed, 35 insertions(+), 47 deletions(-) delete mode 100644 arch/x86/include/asm/elf.h diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h deleted file mode 100644 index 7ae9c7d6da..00 --- a/arch/x86/include/asm/elf.h +++ /dev/null @@ -1,45 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0+ */ -/* - * Brought in from Linux 4.1, removed things not useful to U-Boot. - * The definitions perhaps came from the GNU Library which is GPL. - */ - -#ifndef _ASM_X86_ELF_H -#define _ASM_X86_ELF_H - -/* ELF register definitions */ -#define R_386_NONE 0 -#define R_386_32 1 -#define R_386_PC32 2 -#define R_386_GOT323 -#define R_386_PLT324 -#define R_386_COPY 5 -#define R_386_GLOB_DAT 6 -#define R_386_JMP_SLOT 7 -#define R_386_RELATIVE 8 -#define R_386_GOTOFF 9 -#define R_386_GOTPC10 -#define R_386_NUM 11 - -/* x86-64 relocation types */ -#define R_X86_64_NONE 0 /* No reloc */ -#define R_X86_64_641 /* Direct 64 bit */ -#define R_X86_64_PC32 2 /* PC relative 32 bit signed */ -#define R_X86_64_GOT32 3 /* 32 bit GOT entry */ -#define R_X86_64_PLT32 4 /* 32 bit PLT address */ -#define R_X86_64_COPY 5 /* Copy symbol at runtime */ -#define R_X86_64_GLOB_DAT 6 /* Create GOT entry */ -#define R_X86_64_JUMP_SLOT 7 /* Create PLT entry */ -#define R_X86_64_RELATIVE 8 /* Adjust by program base */ -/* 32 bit signed pc relative offset to GOT */ -#define R_X86_64_GOTPCREL 9 -#define R_X86_64_3210 /* Direct 32 bit zero extended */ -#define R_X86_64_32S 11 /* Direct 32 bit sign extended */ -#define R_X86_64_1612 /* Direct 16 bit zero extended */ -#define R_X86_64_PC16 13 /* 16 bit sign extended pc relative */ -#define R_X86_64_8 14 /* Direct 8 bit sign extended */ -#define R_X86_64_PC8 15 /* 8 bit sign extended pc relative */ - -#define R_X86_64_NUM 16 - -#endif diff --git a/arch/x86/lib/reloc_ia32_efi.c b/arch/x86/lib/reloc_ia32_efi.c index e838af3b70..f0bd2dbd57 100644 --- a/arch/x86/lib/reloc_ia32_efi.c +++ b/arch/x86/lib/reloc_ia32_efi.c @@ -10,7 +10,6 @@ #include #include #include -#include efi_status_t _relocate(long ldbase, Elf32_Dyn *dyn, efi_handle_t image, struct efi_system_table *systab) diff --git a/arch/x86/lib/reloc_x86_64_efi.c b/arch/x86/lib/reloc_x86_64_efi.c index 34c5b2ed3f..adc80ea82a 100644 --- a/arch/x86/lib/reloc_x86_64_efi.c +++ b/arch/x86/lib/reloc_x86_64_efi.c @@ -12,7 +12,6 @@ #include #include #include -#include efi_status_t _relocate(long ldbase, Elf64_Dyn *dyn, efi_handle_t image, struct efi_system_table *systab) diff --git a/include/elf.h b/include/elf.h index 0d3845e063..6802428ac4 100644 --- a/include/elf.h +++ b/include/elf.h @@ -550,6 +550,41 @@ unsigned long elf_hash(const unsigned char *name); #endif /* __ASSEMBLER */ +/* ELF register definitions */ +#define R_386_NONE 0 +#define R_386_32 1 +#define R_386_PC32 2 +#define R_386_GOT323 +#define R_386_PLT324 +#define R_386_COPY 5 +#define R_386_GLOB_DAT 6 +#define R_386_JMP_SLOT 7 +#define R_386_RELATIVE 8 +#define R_386_GOTOFF 9 +#define R_386_GOTPC10 +#define R_386_NUM 11 + +/* x86-64 relocation types */ +#define R_X86_64_NONE 0 /* No reloc */ +#define R_X86_64_641 /* Direct 64 bit */ +#define R_X86_64_PC32 2 /* PC relative 32 bit signed */ +#define R_X86_64_GOT32 3 /* 32 bit GOT entry */ +#define R_X86_64_PLT32 4 /* 32 bit PLT address */ +#define R_X86_64_COPY 5 /* Copy symbol at runtime */ +#define R_X86_64_GLOB_DAT 6 /* Create GOT entry */ +#define R_X86_64_JUMP_SLOT 7 /* Create PLT entry */ +#define R_X86_64_RELATIVE 8 /* Adjust by program base */ +/* 32 bit signed pc relative offset to GOT */ +#define R_X86_64_GOTPCREL 9 +#define R_X86_64_3210 /* Direct 32 bit zero extended */ +#define R_X86_64_32S 11 /* Direct 32 bit sign extended */ +#define R_X86_64_1612 /* Direct 16 bit zero extended */ +#define R_X86_64_PC16 13 /* 16 bit sign extended pc relative */ +#define R_X86_64_8 14 /* Direct 8 bit sign extended */ +#define R_X86_64_
[U-Boot] [PATCH v4 03/21] efi_loader: Use compiler constants for image loader
The EFI image loader tries to determine which target architecture we're
working with to only load PE binaries that match.
So far this has worked based on CONFIG defines, because the target CPU
was always indicated by a config define. With sandbox however, this is
not longer true as all sandbox targets only encompass a single CONFIG
option and so we need to use compiler defines to determine the CPU
architecture.
Signed-off-by: Alexander Graf
---
lib/efi_loader/efi_image_loader.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index ecdb77e5b6..fdf40a62c8 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -19,25 +19,25 @@ const efi_guid_t efi_simple_file_system_protocol_guid =
const efi_guid_t efi_file_info_guid = EFI_FILE_INFO_GUID;
static int machines[] = {
-#if defined(CONFIG_ARM64)
+#if defined(__aarch64__)
IMAGE_FILE_MACHINE_ARM64,
-#elif defined(CONFIG_ARM)
+#elif defined(__arm__)
IMAGE_FILE_MACHINE_ARM,
IMAGE_FILE_MACHINE_THUMB,
IMAGE_FILE_MACHINE_ARMNT,
#endif
-#if defined(CONFIG_X86_64)
+#if defined(__x86_64__)
IMAGE_FILE_MACHINE_AMD64,
-#elif defined(CONFIG_X86)
+#elif defined(__i386__)
IMAGE_FILE_MACHINE_I386,
#endif
-#if defined(CONFIG_CPU_RISCV_32)
+#if defined(__riscv) && (__riscv_xlen == 32)
IMAGE_FILE_MACHINE_RISCV32,
#endif
-#if defined(CONFIG_CPU_RISCV_64)
+#if defined(__riscv) && (__riscv_xlen == 64)
IMAGE_FILE_MACHINE_RISCV64,
#endif
0 };
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 02/21] efi: sandbox: Add relocation constants
From: Simon Glass
Add these so that we can build the EFI loader for sandbox. The values are
for x86_64 so potentially bogus. But we don't support relocation within
sandbox anyway.
Signed-off-by: Simon Glass
Signed-off-by: Alexander Graf
---
lib/efi_loader/efi_runtime.c | 12
1 file changed, 12 insertions(+)
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 4874eb602f..388dfb9840 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -62,6 +62,18 @@ struct dyn_sym {
#define R_ABSOLUTE R_RISCV_64
#define SYM_INDEX 32
#endif
+
+/* For sandbox we only support 64-bit x86 at present */
+#elif defined(CONFIG_SANDBOX)
+/*
+ * TODO(s...@chromium.org): Consider providing a way to enable sandbox features
+ * based on the host architecture
+ */
+# ifndef __x86_64__
+# warning "sandbox EFI support is only tested on 64-bit x86"
+# endif
+#define R_RELATIVE 8
+#define R_MASK 0xULL
#else
#error Need to add relocation awareness
#endif
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 06/21] efi_loader: Allow SMBIOS tables in highmem
We try hard to make sure that SMBIOS tables live in the lower 32bit.
However, when we can not find any space at all there, we should not
error out but instead just fall back to map them in the full address
space instead.
Signed-off-by: Alexander Graf
---
lib/efi_loader/efi_smbios.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
index 7c3fc8af0b..932f7582ec 100644
--- a/lib/efi_loader/efi_smbios.c
+++ b/lib/efi_loader/efi_smbios.c
@@ -26,8 +26,15 @@ efi_status_t efi_smbios_register(void)
/* Reserve 4kiB page for SMBIOS */
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
EFI_RUNTIME_SERVICES_DATA, 1, &dmi);
- if (ret != EFI_SUCCESS)
- return ret;
+
+ if (ret != EFI_SUCCESS) {
+ /* Could not find space in lowmem, use highmem instead */
+ ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
+EFI_RUNTIME_SERVICES_DATA, 1, &dmi);
+
+ if (ret != EFI_SUCCESS)
+ return ret;
+ }
/*
* Generate SMBIOS tables - we know that efi_allocate_pages() returns
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 01/21] efi: sandbox: Add distroboot support
From: Simon Glass With sandbox these values depend on the host system. Let's assume that it is x86_64 for now. Signed-off-by: Simon Glass Signed-off-by: Alexander Graf --- include/config_distro_bootcmd.h | 13 + 1 file changed, 13 insertions(+) diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index d672e8ebe6..1bd79ae3b8 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -251,6 +251,8 @@ #elif defined(CONFIG_ARM) #define BOOTENV_EFI_PXE_ARCH "0xa" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00010:UNDI:003000" + +/* For sandbox we only support 64-bit x86 at present */ #elif defined(CONFIG_X86) /* Always assume we're running 64bit */ #define BOOTENV_EFI_PXE_ARCH "0x7" @@ -261,6 +263,17 @@ #elif defined(CONFIG_CPU_RISCV_64) #define BOOTENV_EFI_PXE_ARCH "0x1b" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00027:UNDI:003000" +#elif defined(CONFIG_SANDBOX) +/* + * TODO(s...@chromium.org): Consider providing a way to enable sandbox features + * based on the host architecture + */ +# ifndef __x86_64__ +# warning "sandbox EFI support is only tested on 64-bit x86" +# endif +/* To support other *host* architectures this should be changed */ +#define BOOTENV_EFI_PXE_ARCH "0x7" +#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:7:UNDI:003000" #else #error Please specify an EFI client identifier #endif -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 29/30] efi_loader: Pass address to fs_read()
On 06/18/2018 04:08 PM, Simon Glass wrote:
From: Alexander Graf
The fs_read() function wants to get an address rather than the
pointer to a buffer.
So let's convert the passed buffer from pointer back a the address
to make efi_loader on sandbox happier.
Signed-off-by: Alexander Graf
Reviewed-by: Simon Glass
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
lib/efi_loader/efi_file.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index e6a15bcb52..2107730ba5 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
/* GUID for file system information */
@@ -232,8 +233,10 @@ static efi_status_t file_read(struct file_handle *fh, u64
*buffer_size,
void *buffer)
{
loff_t actread;
+ /* fs_read expects buffer address, not pointer */
+ uintptr_t buffer_addr = (uintptr_t)map_to_sysmem(buffer);
As you've seen with your patch on the stack based map_to_sysmem()
calculation, map_to_sysmem() really should only be used on pointers that
we are sure come from RAM. With EFI binaries, that isn't true because of
the stack, but it might be true due to other reasons too on real
hardware, such as direct read/write to/from flash.
I think it's much safer to stay in pointer land once we passed the addr
-> ptr boundary. Going from ptr -> addr is usually a recipe for disaster.
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 25/30] efi: Add more debugging for memory allocations
On 06/18/2018 04:08 PM, Simon Glass wrote: Add some more verbose debugging when doing memory allocations. This might help to find bugs later. Signed-off-by: Simon Glass Very useful indeed. Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 24/30] efi: Adjust memory handling to support sandbox
On 06/18/2018 04:08 PM, Simon Glass wrote: Sandbox does not support direct casts between addresses and pointers, since it uses an emulated RAM buffer rather than directly using host RAM. The current EFI code uses an integer type for addresses, but treats them like pointers. Update the code to maintain a (reasonably) clear separation between the two, so that sandbox can work. Unfortunately there remains an inconsistency between the arguments of allocate_pages() and allocate_pool(). One takes an address and one takes a pointer. Partly this seems to be defined by the boot services API itself but it would be fairly easy to update the functions in efi_memory.c to be consistent. However, this is a larger change and needs discussion. Signed-off-by: Simon Glass This also seems to be fallout of a misinterpretation of the API :) Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 23/30] efi: Drop error return in efi_carve_out_dt_rsv()
On 06/18/2018 04:08 PM, Simon Glass wrote: This function currently returns an error code, but never uses it. There is no function comment so it is not obvious why. Presuambly the error is not important. Update the function to explain its purpose and why it ignores the error. Drop the useful error return value. Signed-off-by: Simon Glass Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 22/30] efi: sandbox: Tidy up copy_fdt() to work with sandbox
On 06/18/2018 04:08 PM, Simon Glass wrote: At present this function takes a pointer as its argument, then passes this to efi_allocate_pages(), which actually takes an address. It uses casts, which are not supported on sandbox. I think this is the big API misunderstanding that caused our disagreements: efi_allocate_pages(uint64_t *memory) gets a uint64_t *address as input parameter, but uses the same field to actually return a void * pointer. This is the function that really converts between virtual and physical address space. This is the explicit wording of the spec[1] page 168: The AllocatePages() function allocates the requested number of pages and returns a pointer to the base address of the page range in the location referenced by Memory. So yes, we have to cast. There is no other way around it without completely creating a trainwreck of the API. Alex [1] http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 19/30] efi: Relocate FDT to 127MB instead of 128MB
On 06/18/2018 04:08 PM, Simon Glass wrote:
Sandbox only has 128MB of memory so we cannot relocate the device tree up
to start at 128MB. Use 127MB instead, which should be safe.
Signed-off-by: Simon Glass
We should just drop into the fallback case if allocation fails, no?
Alex
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
cmd/bootefi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 3fa4f181ba..d2458e2397 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -141,8 +141,8 @@ static void *copy_fdt(void *fdt)
fdt_size = ALIGN(fdt_size + 4096, EFI_PAGE_SIZE);
fdt_pages = fdt_size >> EFI_PAGE_SHIFT;
- /* Safe fdt location is at 128MB */
- new_fdt_addr = fdt_ram_start + (128 * 1024 * 1024) + fdt_size;
+ /* Safe fdt location is at 127MB */
+ new_fdt_addr = fdt_ram_start + (127 * 1024 * 1024) + fdt_size;
if (efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
EFI_RUNTIME_SERVICES_DATA, fdt_pages,
&new_fdt_addr) != EFI_SUCCESS) {
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 18/30] efi: Add a call to exit() along with why we can't use it
On 06/18/2018 04:08 PM, Simon Glass wrote: The test should exit like any other EFI application, by calling exit() in the boot services API. But this crashes at present on sandbox. For now, add in the placeholder code. Signed-off-by: Simon Glass It crashes because setjmp/longjmp are broken. See my patch set. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 17/30] sandbox: Enhance map_to_sysmem() to handle foreign pointers
On 06/18/2018 04:08 PM, Simon Glass wrote:
At present map_sysmem() maps an address into the sandbox RAM buffer,
return a pointer, while map_to_sysmem() goes the other way.
The mapping is currently just 1:1 since a case was not found where a more
flexible mapping was needed. PCI does have a separate and more complex
mapping, but uses its own mechanism.
However this arrange cannot handle one important case, which is where a
test declares a stack variable and passes a pointer to it into a U-Boot
function which uses map_to_sysmem() to turn it into a address. Since the
pointer is not inside emulated DRAM, this will fail.
Add a mapping feature which can handle any such pointer, mapping it to a
simple tag value which can be passed around in U-Boot as an address.
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/sandbox/cpu/cpu.c | 141 +--
arch/sandbox/cpu/state.c | 8 ++
arch/sandbox/include/asm/state.h | 21 +
3 files changed, 161 insertions(+), 9 deletions(-)
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index cde0b055a6..fd77603ebf 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -57,14 +57,104 @@ int cleanup_before_linux_select(int flags)
return 0;
}
+/**
+ * is_in_sandbox_mem() - Checks if a pointer is within sandbox's emulated DRAM
+ *
+ * This provides a way to check if a pointer is owned by sandbox (and is within
+ * its RAM) or not. Sometimes pointers come from a test which conceptually runs
+ * output sandbox, potentially with direct access to the C-library malloc()
+ * function, or the sandbox stack (which is not actually within the emulated
+ * DRAM.
+ *
+ * Such pointers obviously cannot be mapped into sandbox's DRAM, so we must
+ * detect them an process them separately, by recording a mapping to a tag,
+ * which we can use to map back to the pointer later.
+ *
+ * @ptr: Pointer to check
+ * @return true if this is within sandbox emulated DRAM, false if not
+ */
+static bool is_in_sandbox_mem(const void *ptr)
+{
+ return (const uint8_t *)ptr >= gd->arch.ram_buf &&
+ (const uint8_t *)ptr < gd->arch.ram_buf + gd->ram_size;
Greater/Less comparisons on pointers are invalid (albeit used) C IIRC.
You should cast to uintptr_t instead and compare those.
+}
+
+/**
+ * phys_to_virt() - Converts a sandbox RAM address to a pointer
+ *
+ * Sandbox uses U-Boot addresses from 0 to the size of DRAM. These index into
+ * the emulated DRAM buffer used by sandbox. This function converts such an
+ * address to a pointer into thi sbuffer, which can be used to access the
this
...
Thinking about this, wouldn't it be easier to just allocate the stack
inside U-Boot RAM?
Alex
+ * memory.
+ *
+ * If the address is outside this range, it is assumed to be a tag
+ */
void *phys_to_virt(phys_addr_t paddr)
{
- return (void *)(gd->arch.ram_buf + paddr);
+ struct sandbox_mapmem_entry *mentry;
+ struct sandbox_state *state;
+
+ /* If the address is within emulated DRAM, calculate the value */
+ if (paddr < gd->ram_size)
+ return (void *)(gd->arch.ram_buf + paddr);
+
+ /*
+* Otherwise search out list of tags for the correct pointer previously
+* created by map_to_sysmem()
+*/
+ state = state_get_current();
+ list_for_each_entry(mentry, &state->mapmem_head, sibling_node) {
+ if (mentry->tag == paddr) {
+ printf("%s: Used map from %lx to %p\n", __func__,
+ (ulong)paddr, mentry->ptr);
+ return mentry->ptr;
+ }
+ }
+
+ printf("%s: Cannot map sandbox address %lx (SDRAM from 0 to %lx)\n",
+ __func__, (ulong)paddr, (ulong)gd->ram_size);
+ os_abort();
+
+ /* Not reached */
+ return NULL;
+}
+
+struct sandbox_mapmem_entry *find_tag(const void *ptr)
+{
+ struct sandbox_mapmem_entry *mentry;
+ struct sandbox_state *state = state_get_current();
+
+ list_for_each_entry(mentry, &state->mapmem_head, sibling_node) {
+ if (mentry->ptr == ptr) {
+ debug("%s: Used map from %p to %lx\n", __func__, ptr,
+ mentry->tag);
+ return mentry;
+ }
+ }
+ return NULL;
}
-phys_addr_t virt_to_phys(void *vaddr)
+phys_addr_t virt_to_phys(void *ptr)
{
- return (phys_addr_t)((uint8_t *)vaddr - gd->arch.ram_buf);
+ struct sandbox_mapmem_entry *mentry;
+
+ /*
+* If it is in emulated RAM, don't bother looking for a tag. Just
+* calculate the pointer using the provides offset into the RAM buffer.
+*/
+ if (is_in_sandbox_mem(ptr))
+ return (phys_addr_t)((uint8_t *)ptr - gd->ar
Re: [U-Boot] [PATCH] board: engicam: spl: match icore-mipi fit-config
On 02/06/2018 13:55, Jagan Teki wrote: > Match imx6q-icore-mipi and imx6dl-icore-mipi dtb in > board_fit_config_name_match. > > Signed-off-by: Jagan Teki > --- > board/engicam/common/spl.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/board/engicam/common/spl.c b/board/engicam/common/spl.c > index 470d96aaed..1a1fe6c66a 100644 > --- a/board/engicam/common/spl.c > +++ b/board/engicam/common/spl.c > @@ -43,10 +43,14 @@ int board_fit_config_name_match(const char *name) > return 0; > else if (is_mx6dq() && !strcmp(name, "imx6q-icore-rqs")) > return 0; > +else if (is_mx6dq() && !strcmp(name, "imx6q-icore-mipi")) > +return 0; > else if ((is_mx6dl() || is_mx6solo()) && !strcmp(name, > "imx6dl-icore")) > return 0; > else if ((is_mx6dl() || is_mx6solo()) && !strcmp(name, > "imx6dl-icore-rqs")) > return 0; > +else if ((is_mx6dl() || is_mx6solo()) && !strcmp(name, > "imx6dl-icore-mipi")) > +return 0; > else > return -1; > } > Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mxs: let boards override entire dram parameter table
Hi Mans, On 27/04/2018 11:45, Mans Rullgard wrote: > If many values differ from the defaults, overriding the full table > is simpler and more space efficient than tweaking it through > mxs_adjust_memory_params(). > > Signed-off-by: Mans Rullgard > --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 15/30] vsprintf: Handle NULL with %pU
On 06/18/2018 04:08 PM, Simon Glass wrote: At present a NULL pointer passed to printf for a %pU argument will cause U-Boot to access memory at 0. Fix this by adding a check, and print "(null)" instead. Signed-off-by: Simon Glass Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 14/30] efi: Don't build sandbox with __attribute__((ms_abi))
On 06/18/2018 04:08 PM, Simon Glass wrote: There appears to be a bug [1] in gcc when using varargs with this attribute. Disable it for sandbox so that functions which use that can work correctly, such as install_multiple_protocol_interfaces(). [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 Signed-off-by: Simon Glass See my patch instead please. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 12/30] sandbox: Try to start the RAM buffer at a particular address
On 06/18/2018 04:08 PM, Simon Glass wrote: Use a starting address of 256MB which should be available. This helps to make sandbox RAM buffers pointers more recognisable. Signed-off-by: Simon Glass Nak, this has a non-0 chance of failing, in case something else is already mapped at that address. You don't want to have your CI blow up 1% of the time due to this. Alex --- Changes in v8: None Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/sandbox/cpu/os.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c index a1a982af2d..1553aa687d 100644 --- a/arch/sandbox/cpu/os.c +++ b/arch/sandbox/cpu/os.c @@ -145,7 +145,12 @@ void *os_malloc(size_t length) struct os_mem_hdr *hdr; int page_size = getpagesize(); - hdr = mmap(NULL, length + page_size, + /* +* Use an address that is hopefully available to us so that pointers +* to this memory are fairly obvious. If we end up with a different +* address, that's fine too. +*/ + hdr = mmap((void *)0x1000, length + page_size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (hdr == MAP_FAILED) return NULL; ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] wandboard: Remove hardcoded baudrate from "console" variable
On 11/06/2018 20:08, Otavio Salvador wrote: > We should use the baudrate variable available inside U-Boot > environment to allow it to be changed dynamically. > > Signed-off-by: Otavio Salvador > --- > > include/configs/wandboard.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h > index 1edd7a8827..cb32cd11f9 100644 > --- a/include/configs/wandboard.h > +++ b/include/configs/wandboard.h > @@ -78,7 +78,7 @@ > #endif > > #define CONFIG_EXTRA_ENV_SETTINGS \ > - "console=ttymxc0,115200\0" \ > + "console=ttymxc0\0" \ > "splashpos=m,m\0" \ > "fdtfile=undefined\0" \ > "fdt_high=0x\0" \ > Series applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
On Fri, Jun 15, 2018 at 5:42 AM, Tom Rini wrote: > On Thu, Jun 14, 2018 at 10:58:22PM +0200, Marek Vasut wrote: >> On 06/14/2018 03:07 PM, Tom Rini wrote: >> > On Thu, Jun 14, 2018 at 01:35:05PM +0200, Marek Vasut wrote: >> >> On 06/14/2018 01:19 PM, Tom Rini wrote: >> >>> On Wed, Jun 13, 2018 at 06:05:08AM +0200, Marek Vasut wrote: >> >>> >> The following changes since commit >> 813d1fb56dc0af9567feb86cd71c49f14662044b: >> >> Merge branch 'master' of git://git.denx.de/u-boot-ubi (2018-06-08 >> 10:08:20 -0400) >> >> are available in the Git repository at: >> >> git://git.denx.de/u-boot-sh.git master >> >> for you to fetch changes up to 0a52b00627c4fb6b100745c97910b75c99f3f4a9: >> >> ARM: rmobile: Fix environment placement on Draak (2018-06-10 16:34:43 >> +0200) >> >> >>> >> >>> NAK. First, there are a lot of should be fix style errors in >> >>> the new files in drivers/pinctrl/renesas/. Second, you have build >> >>> failures: >> >>> https://travis-ci.org/trini/u-boot/jobs/391819805 >> >>> https://travis-ci.org/trini/u-boot/jobs/391819826 >> >> >> >> Great, thanks! >> >> >> >> If the travis didn't vomit constant false positives recently, I'd trust >> >> it. With what it does now, I cannot trust it anymore. >> > >> > Can you elaborate? >> >> Don't you see the constant random timeouts during builds for some >> targets? I cannot get a successful build on the first try almost never >> these days, I have to keep restarting until I see that different targets >> failed during each build with a timeout and then extrapolate that the >> build is actually fine from that. It's annoying. > > I see maybe 2-5 of those per day when I'm busy, which is annoying, but > I've never had it fail a second time in a row. > I guess the instability came from "The command "sudo apt-get install libisl15 -y" failed and exited with 100 during". I saw this almost every build. And even some build wass restarted for the 2nd time, it still failed. >> And then there is the other category of boards which indicate "red" >> failure marker due to ie. DT problems, which if you pull DTs from Linux >> is something you cannot really fix on the U-Boot side right away, but >> rather fix in Linux and then resync. > > Yes, there are DT warnings that should be fixed. But they aren't travis > errors, only actual fail to builds (like in the above, which indeed are > confusingly DT related, but not a travis problem at all, I see them > locally too) and new C warnings. > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 28/30] efi_loader: Disable miniapps on sandbox
From: Alexander Graf In the sandbox environment we can not easily build efi stub binaries right now, so let's disable the respective test cases for the efi selftest suite. Signed-off-by: Alexander Graf Reviewed-by: Simon Glass Signed-off-by: Simon Glass --- Changes in v8: None Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None lib/efi_selftest/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile index 4fe404d88d..bf5c8199cb 100644 --- a/lib/efi_selftest/Makefile +++ b/lib/efi_selftest/Makefile @@ -41,7 +41,7 @@ endif # TODO: As of v2018.01 the relocation code for the EFI application cannot # be built on x86_64. -ifeq ($(CONFIG_X86_64),) +ifeq ($(CONFIG_X86_64)$(CONFIG_SANDBOX),) ifneq ($(CONFIG_CMD_BOOTEFI_SELFTEST),) -- 2.18.0.rc1.244.gcf134e6275-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Fw: make config Error
From: Joe Hershberger To: Duncan Hare Cc: Simon Glass ; Joe Hershberger ; u-boot Sent: Friday, June 15, 2018 12:54 PM Subject: Re: [U-Boot] make config Error On Fri, Jun 15, 2018 at 10:56 AM, wrote: > installed bison++ I just "sudo apt-get install flex bison" and it worked great. > > Cloned most recent u-boot 2018.06.14 > ___ Not so much for me: Debian, with flex ncurses5-dev and bison++ root@debian:/home/duncan/archive/u-boot# make clean root@debian:/home/duncan/archive/u-boot# make menuconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/mconf.o YACC scripts/kconfig/zconf.tab.c scripts/kconfig/zconf.y:44 parser name defined to default :"parse" <---? "scripts/kconfig/zconf.y", line 97: junk after `%%' in definition section Segmentation fault scripts/Makefile.lib:228: recipe for target 'scripts/kconfig/zconf.tab.c' failed make[1]: *** [scripts/kconfig/zconf.tab.c] Error 139 Makefile:491: recipe for target 'menuconfig' failed make: *** [menuconfig] Error 2 root@debian:/home/duncan/archive/u-boot# ^C root@debian:/home/duncan/archive/u-boot# Raspbian no flex :-( pi@raspberrypi:~/server/archive/u-boot $ sudo apt install flex Reading package lists... Done Building dependency tree Reading state information... Done Package flex is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'flex' has no installation candidate In this repository. It might exist elsewhere. I generally use raspbian to compile u-boot for the raspberry pi, and Debian as a file server. The 06.15.2018 version works. Instead of installing bits and pieces of the toolchain, how about reverting to the previous version? Is there link to updated documentation for pre-regs? Duncan Hare 714 931 7952 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 25/30] efi: Add more debugging for memory allocations
Add some more verbose debugging when doing memory allocations. This might
help to find bugs later.
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
lib/efi_loader/efi_boottime.c | 18 ++
lib/efi_loader/efi_memory.c | 22 +-
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index aefafc3fba..2a41eb13aa 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -315,8 +315,12 @@ static efi_status_t EFIAPI efi_allocate_pages_ext(int
type, int memory_type,
map_to_sysmem((void *)(uintptr_t)*memory);
else
addr = 0;
+ debug(" input ptr %lx, addr %lx\n", (unsigned long)*memory,
+ (unsigned long)addr);
r = efi_allocate_pages(type, memory_type, pages, &addr);
*memory = (uintptr_t)map_sysmem(addr, pages << EFI_PAGE_SHIFT);
+ debug("* output addr %lx, ptr %lx\n", (unsigned long)addr,
+ (unsigned long)*memory);
return EFI_EXIT(r);
}
@@ -364,11 +368,25 @@ static efi_status_t EFIAPI efi_get_memory_map_ext(
uint32_t *descriptor_version)
{
efi_status_t r;
+ int i, entries;
EFI_ENTRY("%p, %p, %p, %p, %p", memory_map_size, memory_map,
map_key, descriptor_size, descriptor_version);
r = efi_get_memory_map(memory_map_size, memory_map, map_key,
descriptor_size, descriptor_version);
+ entries = *memory_map_size / sizeof(struct efi_mem_desc);
+ debug(" memory_map_size=%zx (%lx entries)\n", *memory_map_size,
+ (ulong)(*memory_map_size / sizeof(struct efi_mem_desc)));
+ if (memory_map) {
+ for (i = 0; i < entries; i++) {
+ struct efi_mem_desc *desc = &memory_map[i];
+
+ debug(" type %d, phys %lx, virt %lx, num_pages %lx,
attribute %lx\n",
+ desc->type, (ulong)desc->physical_start,
+ (ulong)desc->virtual_start,
+ (ulong)desc->num_pages, (ulong)desc->attribute);
+ }
+ }
return EFI_EXIT(r);
}
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index ad61b723e6..856caa4a40 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -149,6 +149,24 @@ static s64 efi_mem_carve_out(struct efi_mem_list *map,
return EFI_CARVE_LOOP_AGAIN;
}
+static void efi_mem_print(const char *name)
+{
+ struct list_head *lhandle;
+
+ debug(" %s: memory map\n", name);
+ list_for_each(lhandle, &efi_mem) {
+ struct efi_mem_list *lmem = list_entry(lhandle,
+ struct efi_mem_list, link);
+ struct efi_mem_desc *desc = &lmem->desc;
+
+ debug(" type %d, phys %lx, virt %lx, num_pages %lx, attribute
%lx\n",
+ desc->type, (ulong)desc->physical_start,
+ (ulong)desc->virtual_start, (ulong)desc->num_pages,
+ (ulong)desc->attribute);
+ }
+ debug("\n");
+}
+
uint64_t efi_add_memory_map(uint64_t start, uint64_t pages, int memory_type,
bool overlap_only_ram)
{
@@ -237,6 +255,7 @@ uint64_t efi_add_memory_map(uint64_t start, uint64_t pages,
int memory_type,
/* And make sure memory is listed in descending order */
efi_mem_sort();
+ efi_mem_print(__func__);
return start;
}
@@ -453,7 +472,8 @@ efi_status_t efi_get_memory_map(efi_uintn_t
*memory_map_size,
map_entries++;
map_size = map_entries * sizeof(struct efi_mem_desc);
-
+ debug("%s: map_size %lx, provided_map_size %lx\n", __func__,
+ (ulong)map_size, (ulong)provided_map_size);
*memory_map_size = map_size;
if (provided_map_size < map_size)
--
2.18.0.rc1.244.gcf134e6275-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 10/30] efi: Rename bootefi_test_finish() to bootefi_run_finish()
This function can be used from do_bootefi_exec() so that we use mostly the
same code for a normal EFI application and an EFI test.
Rename the function and use it in both places.
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in v7:
- Drop patch "efi: Init the 'rows' and 'cols' variables"
- Drop patches previous applied
Changes in v6: None
Changes in v5:
- Rebase to master
Changes in v4:
- Rebase to master
Changes in v3:
- Add new patch to rename bootefi_test_finish() to bootefi_run_finish()
Changes in v2: None
cmd/bootefi.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index c174e5e8fc..3fa4f181ba 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -273,6 +273,20 @@ static efi_status_t bootefi_run_prepare(struct
efi_loaded_image *image,
return 0;
}
+/**
+ * bootefi_run_finish() - finish up after running an EFI test
+ *
+ * @image: Pointer to a struct which holds the loaded image info
+ * @obj: Pointer to a struct which holds the loaded image object
+ */
+static void bootefi_run_finish(struct efi_loaded_image *image,
+ struct efi_object *obj)
+{
+ efi_restore_gd();
+ free(image->load_options);
+ list_del(&obj->link);
+}
+
/*
* Load an EFI payload into a newly allocated piece of memory, register all
* EFI objects it would want to access and jump to it.
@@ -362,8 +376,7 @@ static efi_status_t do_bootefi_exec(void *efi,
ret = efi_do_enter(obj.handle, &systab, entry);
exit:
- /* image has returned, loaded-image obj goes *poof*: */
- list_del(&obj.link);
+ bootefi_run_finish(&image, &obj);
if (mem_obj.handle)
list_del(&mem_obj.link);
@@ -400,20 +413,6 @@ static efi_status_t bootefi_test_prepare(struct
efi_loaded_image *image,
bootefi_device_path, bootefi_image_path);
}
-/**
- * bootefi_test_finish() - finish up after running an EFI test
- *
- * @image: Pointer to a struct which holds the loaded image info
- * @obj: Pointer to a struct which holds the loaded image object
- */
-static void bootefi_test_finish(struct efi_loaded_image *image,
- struct efi_object *obj)
-{
- efi_restore_gd();
- free(image->load_options);
- list_del(&obj->link);
-}
-
static int do_bootefi_bootmgr_exec(void)
{
struct efi_device_path *device_path, *file_path;
@@ -500,7 +499,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return CMD_RET_FAILURE;
ret = efi_test(&image, &systab);
- bootefi_test_finish(&image, &obj);
+ bootefi_run_finish(&image, &obj);
if (ret) {
printf("Test failed: err=%d\n", ret);
return CMD_RET_FAILURE;
@@ -518,7 +517,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
/* Execute the test */
r = efi_selftest(obj.handle, &systab);
- bootefi_test_finish(&image, &obj);
+ bootefi_run_finish(&image, &obj);
return r != EFI_SUCCESS;
} else
#endif
--
2.18.0.rc1.244.gcf134e6275-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: Enable ACTLR.SMP bit for all i.MX cortex-a7 platforms
On 14/05/2018 14:44, Fabio Estevam wrote:
> From: Ye Li
>
> According to the Cortex-A7 TRM, for ACTLR.SMP bit "You must ensure this bit
> is set to 1 before the caches and MMU are enabled, or any cache and TLB
> maintenance operations are performed".
> ROM sets this bit in normal boot flow, but when in serial download mode,
> it is not set.
> Here we add it in u-boot as a common flow for all i.MX cortex-a7 platforms,
> including mx7d, mx6ul/ull and mx7ulp.
>
> Signed-off-by: Ye Li
> [fabio: adapted to U-Boot mainline codebase and make checkpatch happy]
> Signed-off-by: Fabio Estevam
> ---
> arch/arm/mach-imx/cache.c | 42 ++
> arch/arm/mach-imx/mx7/soc.c | 7 ---
> 2 files changed, 42 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-imx/cache.c b/arch/arm/mach-imx/cache.c
> index c5279a7..86205cf 100644
> --- a/arch/arm/mach-imx/cache.c
> +++ b/arch/arm/mach-imx/cache.c
> @@ -10,6 +10,34 @@
> #include
> #include
>
> +static void enable_ca7_smp(void)
> +{
> + u32 val;
> +
> + /* Read MIDR */
> + asm volatile ("mrc p15, 0, %0, c0, c0, 0\n\t" : "=r"(val));
> + val = (val >> 4);
> + val &= 0xf;
> +
> + /* Only set the SMP for Cortex A7 */
> + if (val == 0x7) {
> + /* Read auxiliary control register */
> + asm volatile ("mrc p15, 0, %0, c1, c0, 1\n\t" : "=r"(val));
> +
> + if (val & (1 << 6))
> + return;
> +
> + /* Enable SMP */
> + val |= (1 << 6);
> +
> + /* Write auxiliary control register */
> + asm volatile ("mcr p15, 0, %0, c1, c0, 1\n\t" : : "r"(val));
> +
> + DSB;
> + ISB;
> + }
> +}
> +
> #ifndef CONFIG_SYS_DCACHE_OFF
> void enable_caches(void)
> {
> @@ -21,6 +49,9 @@ void enable_caches(void)
> /* Avoid random hang when download by usb */
> invalidate_dcache_all();
>
> + /* Set ACTLR.SMP bit for Cortex-A7 */
> + enable_ca7_smp();
> +
> /* Enable D-cache. I-cache is already enabled in start.S */
> dcache_enable();
>
> @@ -32,6 +63,17 @@ void enable_caches(void)
> IRAM_SIZE,
> option);
> }
> +#else
> +void enable_caches(void)
> +{
> + /*
> + * Set ACTLR.SMP bit for Cortex-A7, even if the caches are
> + * disabled by u-boot
> + */
> + enable_ca7_smp();
> +
> + puts("WARNING: Caches not enabled\n");
> +}
> #endif
>
> #ifndef CONFIG_SYS_L2CACHE_OFF
> diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
> index 3ceeeff..83bcd2d 100644
> --- a/arch/arm/mach-imx/mx7/soc.c
> +++ b/arch/arm/mach-imx/mx7/soc.c
> @@ -281,13 +281,6 @@ const struct boot_mode soc_boot_modes[] = {
>
> void s_init(void)
> {
> -#if !defined CONFIG_SPL_BUILD
> - /* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */
> - asm volatile(
> - "mrc p15, 0, r0, c1, c0, 1\n"
> - "orr r0, r0, #1 << 6\n"
> - "mcr p15, 0, r0, c1, c0, 1\n");
> -#endif
> /* clock configuration. */
> clock_init();
>
>
Applied to u-boot-imx, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 24/30] efi: Adjust memory handling to support sandbox
Sandbox does not support direct casts between addresses and pointers,
since it uses an emulated RAM buffer rather than directly using host
RAM.
The current EFI code uses an integer type for addresses, but treats them
like pointers.
Update the code to maintain a (reasonably) clear separation between the
two, so that sandbox can work.
Unfortunately there remains an inconsistency between the arguments of
allocate_pages() and allocate_pool(). One takes an address and one takes
a pointer. Partly this seems to be defined by the boot services API itself
but it would be fairly easy to update the functions in efi_memory.c to be
consistent. However, this is a larger change and needs discussion.
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
lib/efi_loader/efi_boottime.c | 13 +++--
lib/efi_loader/efi_image_loader.c | 3 ++-
lib/efi_loader/efi_memory.c | 17 +
3 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 50d311548e..aefafc3fba 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
@@ -305,9 +306,17 @@ static efi_status_t EFIAPI efi_allocate_pages_ext(int
type, int memory_type,
uint64_t *memory)
{
efi_status_t r;
+ uint64_t addr;
EFI_ENTRY("%d, %d, 0x%zx, %p", type, memory_type, pages, memory);
- r = efi_allocate_pages(type, memory_type, pages, memory);
+ if (memory_type == EFI_ALLOCATE_MAX_ADDRESS ||
+ memory_type == EFI_ALLOCATE_ADDRESS)
+ addr = *memory == -1ULL ? *memory :
+ map_to_sysmem((void *)(uintptr_t)*memory);
+ else
+ addr = 0;
+ r = efi_allocate_pages(type, memory_type, pages, &addr);
+ *memory = (uintptr_t)map_sysmem(addr, pages << EFI_PAGE_SHIFT);
return EFI_EXIT(r);
}
@@ -328,7 +337,7 @@ static efi_status_t EFIAPI efi_free_pages_ext(uint64_t
memory,
efi_status_t r;
EFI_ENTRY("%" PRIx64 ", 0x%zx", memory, pages);
- r = efi_free_pages(memory, pages);
+ r = efi_free_pages(map_to_sysmem((void *)memory), pages);
return EFI_EXIT(r);
}
diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index ecdb77e5b6..d5dd8864d7 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
const efi_guid_t efi_global_variable_guid = EFI_GLOBAL_VARIABLE_GUID;
@@ -301,7 +302,7 @@ void *efi_load_pe(void *efi, struct efi_loaded_image
*loaded_image_info)
/* Run through relocations */
if (efi_loader_relocate(rel, rel_size, efi_reloc,
(unsigned long)image_base) != EFI_SUCCESS) {
- efi_free_pages((uintptr_t) efi_reloc,
+ efi_free_pages(map_to_sysmem(efi_reloc),
(virt_size + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT);
return NULL;
}
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index c6410613c7..ad61b723e6 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -345,7 +345,7 @@ void *efi_alloc(uint64_t len, int memory_type)
r = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES, memory_type, pages,
&ret);
if (r == EFI_SUCCESS)
- return (void*)(uintptr_t)ret;
+ return map_sysmem(ret, len);
return NULL;
}
@@ -412,15 +412,17 @@ efi_status_t efi_free_pool(void *buffer)
{
efi_status_t r;
struct efi_pool_allocation *alloc;
+ uintptr_t addr;
if (buffer == NULL)
return EFI_INVALID_PARAMETER;
alloc = container_of(buffer, struct efi_pool_allocation, data);
/* Sanity check, was the supplied address returned by allocate_pool */
- assert(((uintptr_t)alloc & EFI_PAGE_MASK) == 0);
+ addr = map_to_sysmem(alloc);
+ assert((addr & EFI_PAGE_MASK) == 0);
- r = efi_free_pages((uintptr_t)alloc, alloc->num_pages);
+ r = efi_free_pages(addr, alloc->num_pages);
return r;
}
@@ -471,7 +473,14 @@ efi_status_t efi_get_memory_map(efi_uintn_t
*memory_map_size,
struct efi_mem_list *lmem;
lmem = list_entry(lhandle, struct efi_mem_list, link);
- *memory_map = lmem->desc;
+ memory_map->type = lmem->desc.type;
+ memory_map->reserved = 0;
+ memory_map->physical_start = (uintptr_t)map_sysmem(
+ lmem->desc.physical_start,
+
[U-Boot] [PATCH v8 21/30] efi_loader: Use map_sysmem() in bootefi command
From: Alexander Graf
The bootefi command gets a few addresses as values passed in. In sandbox,
these values are in U-Boot address space, so we need to make sure we
explicitly call map_sysmem() on them to be able to access them.
Signed-off-by: Alexander Graf
Reviewed-by: Simon Glass
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
cmd/bootefi.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index c89f83fb33..b62635f448 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -452,7 +453,8 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
char *saddr;
unsigned long addr;
efi_status_t r;
- void *fdt_addr;
+ unsigned long fdt_addr;
+ void *fdt;
/* Allow unaligned memory access */
allow_unaligned();
@@ -469,11 +471,12 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
return CMD_RET_USAGE;
if (argc > 2) {
- fdt_addr = (void *)simple_strtoul(argv[2], NULL, 16);
+ fdt_addr = simple_strtoul(argv[2], NULL, 16);
if (!fdt_addr && *argv[2] != '0')
return CMD_RET_USAGE;
/* Install device tree */
- r = efi_install_fdt(fdt_addr);
+ fdt = map_sysmem(fdt_addr, 0);
+ r = efi_install_fdt(fdt);
if (r != EFI_SUCCESS) {
printf("ERROR: failed to install device tree\n");
return CMD_RET_FAILURE;
@@ -492,7 +495,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
addr = simple_strtoul(saddr, NULL, 16);
else
addr = CONFIG_SYS_LOAD_ADDR;
- memcpy((char *)addr, __efi_helloworld_begin, size);
+ memcpy(map_sysmem(addr, size), __efi_helloworld_begin, size);
} else
#endif
if (IS_ENABLED(CONFIG_BOOTEFI_TEST) && !strcmp(argv[1], "test")) {
@@ -538,7 +541,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
printf("## Starting EFI application at %08lx ...\n", addr);
- r = do_bootefi_exec((void *)addr, bootefi_device_path,
+ r = do_bootefi_exec(map_sysmem(addr, 0), bootefi_device_path,
bootefi_image_path);
printf("## Application terminated, r = %lu\n",
r & ~EFI_ERROR_MASK);
--
2.18.0.rc1.244.gcf134e6275-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 13/30] sandbox: Add support for calling abort()
This function is useful to signal that the application needs to exit
immediate. It can be caught with a debugger (e.g. gdb). Add a stub for it
so that it can be called from within sandbox when an internal error
occurs.
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/sandbox/cpu/os.c | 5 +
include/os.h | 4
2 files changed, 9 insertions(+)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 1553aa687d..f8d87df7b6 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -657,3 +657,8 @@ void os_longjmp(ulong *jmp, int ret)
{
longjmp((struct __jmp_buf_tag *)jmp, ret);
}
+
+void os_abort(void)
+{
+ abort();
+}
diff --git a/include/os.h b/include/os.h
index c8e0f52d30..e850f879ec 100644
--- a/include/os.h
+++ b/include/os.h
@@ -351,4 +351,8 @@ int os_setjmp(ulong *jmp, int size);
*/
void os_longjmp(ulong *jmp, int ret);
+/**
+ * os_abort() - Raise SIGABRT to exit sandbox (e.g. to debugger)
+ */
+void os_abort(void);
#endif
--
2.18.0.rc1.244.gcf134e6275-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v8 27/30] efi_loader: efi_allocate_pages is too restrictive
From: Heinrich Schuchardt
When running on the sandbox the stack is not necessarily at a higher memory
address than the highest free memory.
There is no reason why the checking of the highest memory address should be
more restrictive for EFI_ALLOCATE_ANY_PAGES than for
EFI_ALLOCATE_MAX_ADDRESS.
Signed-off-by: Heinrich Schuchardt
[agraf: use -1ULL instead]
Signed-off-by: Alexander Graf
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
lib/efi_loader/efi_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 856caa4a40..7804adacd2 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -315,7 +315,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
switch (type) {
case EFI_ALLOCATE_ANY_PAGES:
/* Any page */
- addr = efi_find_free_memory(len, gd->start_addr_sp);
+ addr = efi_find_free_memory(len, -1ULL);
if (!addr) {
r = EFI_NOT_FOUND;
break;
--
2.18.0.rc1.244.gcf134e6275-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
