[U-Boot] [PATCH] fs/fat: fix unaligned access regression

[Jonathan Gray]

Since
2460098cffacd18729262e3ed36656e6943783ed (fs/fat: Reduce stack usage)
Trying to load a file off a FAT fs on i.MX 6 based CuBox-i4Pro fails:

switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468
...

Switching the malloc() calls to malloc_cache_aligned() avoids
the alignment errors and allows booting to continue.

Signed-off-by: Jonathan Gray 
---
 fs/fat/fat.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 3d3e17e8fa..d299f317a9 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -1038,7 +1038,7 @@ int fat_exists(const char *filename)
fat_itr *itr;
int ret;
 
-   itr = malloc(sizeof(fat_itr));
+   itr = malloc_cache_aligned(sizeof(fat_itr));
ret = fat_itr_root(itr, );
if (ret)
return 0;
@@ -1055,7 +1055,7 @@ int fat_size(const char *filename, loff_t *size)
fat_itr *itr;
int ret;
 
-   itr = malloc(sizeof(fat_itr));
+   itr = malloc_cache_aligned(sizeof(fat_itr));
ret = fat_itr_root(itr, );
if (ret)
return ret;
@@ -1089,7 +1089,7 @@ int file_fat_read_at(const char *filename, loff_t pos, 
void *buffer,
fat_itr *itr;
int ret;
 
-   itr = malloc(sizeof(fat_itr));
+   itr = malloc_cache_aligned(sizeof(fat_itr));
ret = fat_itr_root(itr, );
if (ret)
return ret;
-- 
2.14.2

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

Re: [U-Boot] [PATCH 031/080] serial: ns16550: Fix address translation

[Dr. Philipp Tomsich]

> On 9 Oct 2017, at 14:45, Mario Six  wrote:
> 
> (adding Philipp since he converted lots of drivers to livetree recently)
> 
> On Mon, Oct 9, 2017 at 6:48 AM, Simon Glass  wrote:
>> Hi Mario,
>> 
>> On 29 September 2017 at 06:51, Mario Six  wrote:
>>> The dev_read_addr function does not do any bus translations, and just
>>> returns the raw address read from the device tree, which makes the
>>> driver not work on systems that need bus translations to get the actual
>>> memory address of the device's register space.
>> 
>> Aside from any current functionality, what is the correct thing for
>> dev_read_addr() to do? I worry that the two parts (live/flat tree)
>> might do different things.
>> 
> 
> I took a closer look, and indeed, the two parts of dev_read_addr behave
> differently: dev_read_addr calls dev_read_addr_index, which calls either
> ofnode_get_addr_index when live tree is active, or devfdt_get_addr_index when
> it's not. devfdt_get_addr_index applies bus translations, but
> ofnode_get_addr_index returns the untranslated address using of_read_number
> (the else part doesn't run, since we have an active live tree if
> ofnode_get_addr_index was called).

Good point. I would expect the livetree case to use translated addresses
during runtime, as dev_read_addr_index calls either ofnode_get_addr_index
or devfdt_get_addr_index.

In other words: are we missing an address translation from ofnode_get_addr_index
or should the address retrieved via ofnode_get_addr_index have been
translated by earlier processing?

> 
> We could fix this by running of_translate_address on the value returned by
> of_read_number, so that dev_get_addr would then always return a translated
> address.
> 
> But what I think is strange is that most live tree conversion patches (e.g.
> a9d3037 ("usb: dwc2: convert to livetree") or 4aac33f ("dm: mmc: fsl_esdhc:
> Update to support livetree")) simply replaced devfdt_get_addr (which does 
> apply
> bus translations) with dev_read_addr (which does not apply bus translations in
> the live tree case). Shouldn't the converted driver have failed in the live
> tree case? Or were all drivers converted until now not depending on any bus
> translations?
> 
>> In any case, we should not compound the problem if dev_read_addr() is wrong.
>> 
>>> 
>>> Since the dev_read_addr function is widely used, we refrain from
>>> modifying it, and instead read the raw address from the device tree, and
>>> apply the bus translations using the recently introduced
>>> dev_translate_address function.
>>> 
>>> Signed-off-by: Mario Six 
>>> ---
>>> drivers/serial/ns16550.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>> 
>> REgards,
>> Simon
> 
> Best regards,
> 
> Mario

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

Re: [U-Boot] [PATCH v5 0/4] Allwinner SimpleFB Kconfig cleanup and DE2 SimpleFB support

[icenowy]

在 2017-09-21 00:18，Icenowy Zheng 写道：

This patchset is mainly for Allwinner DE2 HDMI SimpleFB support.

The framebuffer initialized by the Allwinner DE2 driver can be
passed by to the kernel as simplefb, and this can enable the
kernel to display graphics without having full DE2 driver.

Add the suppot of simplefb in DE2 code.

The code to find a simplefb with sunxi extension and a suitable
pipeline is extracted to a new source file in video/sunxi/.

An option is added for device tree simplefb, and furtherly other
simplefb support code should also be converted to it. The
current only user to the CONFIG_VIDEO_DT_SIMPLEFB, Allwinner
DE1 legacy video, has already converted to use the Kconfig
option in this patchset. A cleanup commit is introduced for
this conversion.

Icenowy Zheng (4):
  sunxi: change the DE1 video option to CONFIG_VIDEO_SUNXI
  video: sunxi: extract simplefb match code to a new file
  video: add an option for video simplefb via DT
  sunxi: setup simplefb for Allwinner DE2


Hello Anatolij,

Could you look at this patchset?

I used to think it as a sunxi-only patchset, so I sent it to the
sunxi maintainers. However, Maxime says that he needs feedback
from video maintainers.

Thanks!



 arch/arm/mach-sunxi/Kconfig   | 31 ---
 drivers/video/Kconfig |  8 
 drivers/video/sunxi/Makefile  |  4 +-
 drivers/video/sunxi/simplefb_common.c | 30 +++
 drivers/video/sunxi/simplefb_common.h | 22 +++
 drivers/video/sunxi/sunxi_de2.c   | 72 
+++

 drivers/video/sunxi/sunxi_display.c   | 13 +--
 include/configs/sunxi-common.h|  9 +
 scripts/config_whitelist.txt  |  1 -
 9 files changed, 155 insertions(+), 35 deletions(-)
 create mode 100644 drivers/video/sunxi/simplefb_common.c
 create mode 100644 drivers/video/sunxi/simplefb_common.h

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

Re: [U-Boot] Edison's U-Boot Architecture

[Andy Shevchenko]

On Mon, 2017-10-09 at 14:45 +0300, Andy Shevchenko wrote:
> On Mon, 2017-10-09 at 08:10 +0200, Zoran Stojsavljevic wrote:
> > 
> > Andy/Andrej,
> 
> Andy is okay :-)
> 
> > Question here: Did I get the correct idea how Edison works with U-
> > Boot? Could you, please, elaborate how this is done with Edison? 
> 
> See above
> 
> > (Vopros sdes6: Ja praviljno ugadal kak eto sdelano/rabotaet? Mozno
> > bolee dannih kad celaja eta arhitectura rabotaet so Edisonom?)
> 
> Ne ugadal :-) Smotri vyshe.

Btw, I'm going to attend ELC2017 Europe (in Prague), anyone who has
questions, comments, anything to discuss or just have a dinner, are
welcome!

-- 
Andy Shevchenko 
Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

[Rob Clark]

On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
> On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
>> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
>> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
>> >> This fixes an issue with OpenBSD's bootloader, and I think should also
>> >> fix a similar issue with grub2 on legacy devices.  In the legacy case
>> >> we were creating disk objects for the partitions, but not also the
>> >> parent device.
>> >>
>> >> Reported-by: Jonathan Gray 
>> >> Signed-off-by: Rob Clark 
>> >
>> > Thanks for looking into this.  While this lets armv7/bootarm.efi
>> > boot again on cubox-i and bbb it doesn't help rpi3.
>> >
>> > What is the easiest way to get U-Boot to display these paths
>> > to be able to compare the current behaviour to 2017.09?
>> >
>>
>> in grub, there is the lsefi command, not sure if the OpenBSD
>> bootloader has something similar?
>>
>> u-boot implements that device-path to text protocol, so it should be
>> pretty easy to implement something like this if not.
>>
>> BR,
>> -R
>
> With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
> is no longer seen.  Is it possible having U-Boot on mmc but directing
> it to load off usb is somehow involved here?

There is no requirement that efi payload and u-boot are on the same
device.  The distro bootcmd stuff will just look for
/efi/boot/bootxyz.efi on all the devices/partitions until it finds
one.

The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
or legacy boards, in the former case we can construct something more
realistic.  Although the bootloader shouldn't really care.

> efi_bootdp obtained from the loaded image protocol
>
> 2017.09
>
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> reading efi/boot/bootaa64.efi
> 78959 bytes read in 76 ms (1013.7 KiB/s)
> ## Starting EFI application at 0100 ...
> Scanning disk sd...@7e30.blk...
> Scanning disk usb_mass_storage.lun0...
> Found 2 disks
> efi_diskprobe
> efi_device_path_depth looking for type 4 i=0 type 4
> depth=0
> i=0
> efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
> i=1
> efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
>>> OpenBSD/arm64 BOOTAA64 0.8
> boot>
> booting sd0a:/bsd: 3871708+578596+509352+803952 
> [283845+96+451968+239920]=0x82f330
>
> git + patch


I assume you are referring to this patch?  It should only add
additional per-partion "disk" objects.  (In UEFI terminology each
partition is a "disk" object.)

BR,
-R

> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> reading efi/boot/bootaa64.efi
> 78959 bytes read in 86 ms (896.5 KiB/s)
> ## Starting EFI application at 0100 ...
> Scanning disk sd...@7e30.blk...
> Scanning disk usb_mass_storage.lun0...
> Found 2 disks
> efi_diskprobe
> efi_device_path_depth looking for type 4 i=0 type 1
> efi_device_path_depth looking for type 4 i=1 type 3
> efi_device_path_depth looking for type 4 i=2 type 3
> efi_device_path_depth looking for type 4 i=3 type 3
> efi_device_path_depth no match for type 4
> depth=-1
> i=0
> i=1
> i=2
> i=3
>>> OpenBSD/arm64 BOOTAA64 0.8
> boot>
> cannot open sd0a:/etc/random.seed: Device not configured
> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Broadwell-DE bare metal

[Simon Glass]

Hi,

On 3 October 2017 at 08:58, vnktux  wrote:
> Hi all,
>
> For my graduation project my company asked to use U-Boot as bare metal 
> boot-loader on one of their product. The product in an embedded board with a 
> Xeon Broadwell-DE D-1527 Quad Core. The current boot-loader consist of 
> Coreboot + U-Boot, but of course they want to get rid of Coreboot. I have 
> almost no experience with U-Boot (Just with ARM processor a little bit) and 
> so far I don't even know if it's possible or not to achieve the final goal. 
> What I have understood is that I need the following binary blobs to work: 
> fsp.bin, vga.bin, descriptor.bin, me.bin, microcode.bin. Is it true? Can 
> somebody point me in the right direction because I am a little bit lost?  
> Plus I don't see many x86 boards implemented in the source code of U-Boot.

The original U-Boot payload support was done with Broadwell-DE (I'm
not sure which one though). It allows U-Boot to boot from EFI.

For what you want, yes you will need to obtain various binary blobs.
Hopefully you can get the FSP from Intel, and with that the work
required in U-Boot is probably not too large. Although I'm sure that
the FSP API will have changed a little.

Regards,
Simon

>
> Best regards,
> Vincenzo
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] mmc: stm32_sdmmc2: increase polling status register delay

[patrice.chotard]

From: Christophe Kerello 

MMC commands like MMC_CMD_ALL_SEND_CID or MMC_CMD_SEND_CSD can reach
500 us. This patch increases the polling status register delay to avoid
a timeout on a command.

Signed-off-by: Christophe Kerello 
Signed-off-by: Patrice Chotard 
---
 drivers/mmc/stm32_sdmmc2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
index 0e1f40b..fd49d42 100644
--- a/drivers/mmc/stm32_sdmmc2.c
+++ b/drivers/mmc/stm32_sdmmc2.c
@@ -276,7 +276,7 @@ static int stm32_sdmmc2_end_cmd(struct stm32_sdmmc2_priv 
*priv,
 
/* Polling status register */
ret = readl_poll_timeout(priv->base + SDMMC_STA, status, status & mask,
-300);
+1);
 
if (ret < 0) {
debug("%s: timeout reading SDMMC_STA register\n", __func__);
-- 
1.9.1

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

Re: [U-Boot] [PATCH 031/080] serial: ns16550: Fix address translation

[Mario Six]

(adding Philipp since he converted lots of drivers to livetree recently)

On Mon, Oct 9, 2017 at 6:48 AM, Simon Glass  wrote:
> Hi Mario,
>
> On 29 September 2017 at 06:51, Mario Six  wrote:
>> The dev_read_addr function does not do any bus translations, and just
>> returns the raw address read from the device tree, which makes the
>> driver not work on systems that need bus translations to get the actual
>> memory address of the device's register space.
>
> Aside from any current functionality, what is the correct thing for
> dev_read_addr() to do? I worry that the two parts (live/flat tree)
> might do different things.
>

I took a closer look, and indeed, the two parts of dev_read_addr behave
differently: dev_read_addr calls dev_read_addr_index, which calls either
ofnode_get_addr_index when live tree is active, or devfdt_get_addr_index when
it's not. devfdt_get_addr_index applies bus translations, but
ofnode_get_addr_index returns the untranslated address using of_read_number
(the else part doesn't run, since we have an active live tree if
ofnode_get_addr_index was called).

We could fix this by running of_translate_address on the value returned by
of_read_number, so that dev_get_addr would then always return a translated
address.

But what I think is strange is that most live tree conversion patches (e.g.
a9d3037 ("usb: dwc2: convert to livetree") or 4aac33f ("dm: mmc: fsl_esdhc:
Update to support livetree")) simply replaced devfdt_get_addr (which does apply
bus translations) with dev_read_addr (which does not apply bus translations in
the live tree case). Shouldn't the converted driver have failed in the live
tree case? Or were all drivers converted until now not depending on any bus
translations?

> In any case, we should not compound the problem if dev_read_addr() is wrong.
>
>>
>> Since the dev_read_addr function is widely used, we refrain from
>> modifying it, and instead read the raw address from the device tree, and
>> apply the bus translations using the recently introduced
>> dev_translate_address function.
>>
>> Signed-off-by: Mario Six 
>> ---
>>  drivers/serial/ns16550.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> REgards,
> Simon

Best regards,

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

Re: [U-Boot] [PATCH 031/080] serial: ns16550: Fix address translation

[Simon Glass]

Hi,

On 9 October 2017 at 06:55, Dr. Philipp Tomsich
 wrote:
>
>> On 9 Oct 2017, at 14:45, Mario Six  wrote:
>>
>> (adding Philipp since he converted lots of drivers to livetree recently)
>>
>> On Mon, Oct 9, 2017 at 6:48 AM, Simon Glass  wrote:
>>> Hi Mario,
>>>
>>> On 29 September 2017 at 06:51, Mario Six  wrote:
 The dev_read_addr function does not do any bus translations, and just
 returns the raw address read from the device tree, which makes the
 driver not work on systems that need bus translations to get the actual
 memory address of the device's register space.
>>>
>>> Aside from any current functionality, what is the correct thing for
>>> dev_read_addr() to do? I worry that the two parts (live/flat tree)
>>> might do different things.
>>>
>>
>> I took a closer look, and indeed, the two parts of dev_read_addr behave
>> differently: dev_read_addr calls dev_read_addr_index, which calls either
>> ofnode_get_addr_index when live tree is active, or devfdt_get_addr_index when
>> it's not. devfdt_get_addr_index applies bus translations, but
>> ofnode_get_addr_index returns the untranslated address using of_read_number
>> (the else part doesn't run, since we have an active live tree if
>> ofnode_get_addr_index was called).
>
> Good point. I would expect the livetree case to use translated addresses
> during runtime, as dev_read_addr_index calls either ofnode_get_addr_index
> or devfdt_get_addr_index.
>
> In other words: are we missing an address translation from 
> ofnode_get_addr_index
> or should the address retrieved via ofnode_get_addr_index have been
> translated by earlier processing?

Thank you both. Yes it seems like the right answer is to add the
missing translation in. There is a CONFIG_OF_TRANSLATE which enables
this. I think most boards don't use it, which is probably why there
are no problems without it, but I think it is becoming more common as
boards become more complex.

>
>>
>> We could fix this by running of_translate_address on the value returned by
>> of_read_number, so that dev_get_addr would then always return a translated
>> address.
>>
>> But what I think is strange is that most live tree conversion patches (e.g.
>> a9d3037 ("usb: dwc2: convert to livetree") or 4aac33f ("dm: mmc: fsl_esdhc:
>> Update to support livetree")) simply replaced devfdt_get_addr (which does 
>> apply
>> bus translations) with dev_read_addr (which does not apply bus translations 
>> in
>> the live tree case). Shouldn't the converted driver have failed in the live
>> tree case? Or were all drivers converted until now not depending on any bus
>> translations?
>>
>>> In any case, we should not compound the problem if dev_read_addr() is wrong.
>>>

 Since the dev_read_addr function is widely used, we refrain from
 modifying it, and instead read the raw address from the device tree, and
 apply the bus translations using the recently introduced
 dev_translate_address function.

 Signed-off-by: Mario Six 
 ---
 drivers/serial/ns16550.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> REgards,
>>> Simon
>>
>> Best regards,
>>
>> Mario
>

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

Re: [U-Boot] Antwort: Re: QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Goldschmidt Simon]

Hi Clémént,

> Did you also test the saveenv and sf unlock ?

I did test saveenv and it works. I did not test sf protection.

> Did you get some strange behaviors after a "warm reboot" from linux ?

Indeed, warm reboot fails. When rebooting via "reboot" command from
linux, the last thing I see is SPL writing "Trying to boot from SPI".

I haven't been able to debug this further, yet.

Also, I still can't sf read without disabling the data cache :-(

Regards,
Simon

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

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

[Jonathan Gray]

On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
> >> >> This fixes an issue with OpenBSD's bootloader, and I think should also
> >> >> fix a similar issue with grub2 on legacy devices.  In the legacy case
> >> >> we were creating disk objects for the partitions, but not also the
> >> >> parent device.
> >> >>
> >> >> Reported-by: Jonathan Gray 
> >> >> Signed-off-by: Rob Clark 
> >> >
> >> > Thanks for looking into this.  While this lets armv7/bootarm.efi
> >> > boot again on cubox-i and bbb it doesn't help rpi3.
> >> >
> >> > What is the easiest way to get U-Boot to display these paths
> >> > to be able to compare the current behaviour to 2017.09?
> >> >
> >>
> >> in grub, there is the lsefi command, not sure if the OpenBSD
> >> bootloader has something similar?
> >>
> >> u-boot implements that device-path to text protocol, so it should be
> >> pretty easy to implement something like this if not.
> >>
> >> BR,
> >> -R
> >
> > With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
> > is no longer seen.  Is it possible having U-Boot on mmc but directing
> > it to load off usb is somehow involved here?
> 
> There is no requirement that efi payload and u-boot are on the same
> device.  The distro bootcmd stuff will just look for
> /efi/boot/bootxyz.efi on all the devices/partitions until it finds
> one.
> 
> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
> or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
> or legacy boards, in the former case we can construct something more
> realistic.  Although the bootloader shouldn't really care.

I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
in master only gives types of 1 (Hardware Device Path) and
3 (Messaging Device Path).

It is DM in this case:

U-Boot> dm tree
 Class  Probed  Driver  Name

 root   [ + ]   root_drive  root_driver
 simple_bus [ + ]   generic_si  |-- soc
 gpio   [ + ]   gpio_bcm28  |   |-- gpio@7e20
 serial [ + ]   serial_bcm  |   |-- serial@7e215040
 mmc[ + ]   sdhci-bcm2  |   |-- sdhci@7e30
 blk[ + ]   mmc_blk |   |   `-- sd...@7e30.blk
 video  [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
 vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
 usb[ + ]   dwc2_usb|   `-- usb@7e98
 usb_hub[ + ]   usb_hub |   `-- usb_hub
 usb_hub[ + ]   usb_hub |   `-- usb_hub
 eth[ + ]   smsc95xx_e  |   |-- smsc95xx_eth
 usb_mass_s [ + ]   usb_mass_s  |   `-- usb_mass_storage
 blk[   ]   usb_storag  |   `-- usb_mass_storage.lun0
 simple_bus [   ]   generic_si  `-- clocks

> 
> > efi_bootdp obtained from the loaded image protocol
> >
> > 2017.09
> >
> > Scanning usb 0:1...
> > Found EFI removable media binary efi/boot/bootaa64.efi
> > reading efi/boot/bootaa64.efi
> > 78959 bytes read in 76 ms (1013.7 KiB/s)
> > ## Starting EFI application at 0100 ...
> > Scanning disk sd...@7e30.blk...
> > Scanning disk usb_mass_storage.lun0...
> > Found 2 disks
> > efi_diskprobe
> > efi_device_path_depth looking for type 4 i=0 type 4
> > depth=0
> > i=0
> > efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
> > i=1
> > efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
> >>> OpenBSD/arm64 BOOTAA64 0.8
> > boot>
> > booting sd0a:/bsd: 3871708+578596+509352+803952 
> > [283845+96+451968+239920]=0x82f330
> >
> > git + patch
> 
> 
> I assume you are referring to this patch?  It should only add
> additional per-partion "disk" objects.  (In UEFI terminology each
> partition is a "disk" object.)

Yes, "efi_loader: Fix disk dp's for pre-DM/legacy devices".
The problem seems to be elsewhere as dropping that I still see:

## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
Scanning disk usb_mass_storage.lun0...
Found 2 disks
efi_diskprobe
efi_device_path_depth looking for type 4 i=0 type 1
efi_device_path_depth looking for type 4 i=1 type 3
efi_device_path_depth looking for type 4 i=2 type 3
efi_device_path_depth looking for type 4 i=3 type 3
efi_device_path_depth no match for type 4
depth=-1
i=0
i=1
i=2
i=3
>> OpenBSD/arm64 BOOTAA64 0.8
boot> 
cannot open sd0a:/etc/random.seed: Device not configured
booting sd0a:/bsd: open sd0a:/bsd: Device not configured
 failed(6). will try /bsd

od1000 (edk2) booting off sata:

INFO:PSCI Power Domain Map:
INFO:  Domain Node : Level 1, parent_node -1, State ON (0x0)
INFO:  Domain Node : Level 1, parent_node -1, State OFF (0x2)
INFO:  Domain Node : Level 1, parent_node -1, State OFF (0x2)
INFO:  Domain Node 

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

[Heinrich Schuchardt]

On 10/09/2017 06:06 PM, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
>> On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
>>> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
 On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
>> On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
>>> This fixes an issue with OpenBSD's bootloader, and I think should also
>>> fix a similar issue with grub2 on legacy devices.  In the legacy case
>>> we were creating disk objects for the partitions, but not also the
>>> parent device.
>>>
>>> Reported-by: Jonathan Gray 
>>> Signed-off-by: Rob Clark 
>>
>> Thanks for looking into this.  While this lets armv7/bootarm.efi
>> boot again on cubox-i and bbb it doesn't help rpi3.
>>
>> What is the easiest way to get U-Boot to display these paths
>> to be able to compare the current behaviour to 2017.09?
>>
>
> in grub, there is the lsefi command, not sure if the OpenBSD
> bootloader has something similar?
>
> u-boot implements that device-path to text protocol, so it should be
> pretty easy to implement something like this if not.
>
> BR,
> -R

 With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
 is no longer seen.  Is it possible having U-Boot on mmc but directing
 it to load off usb is somehow involved here?
>>>
>>> There is no requirement that efi payload and u-boot are on the same
>>> device.  The distro bootcmd stuff will just look for
>>> /efi/boot/bootxyz.efi on all the devices/partitions until it finds
>>> one.
>>>
>>> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
>>> or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
>>> or legacy boards, in the former case we can construct something more
>>> realistic.  Although the bootloader shouldn't really care.
>>
>> I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
>> in master only gives types of 1 (Hardware Device Path) and
>> 3 (Messaging Device Path).
>>
>> It is DM in this case:
> 
> Possibly something weird with your partition table?  In
> efi_disk_register() it should create objects for the disk itself
> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
> partition (part>=1, which would have same dp as the disk but
> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
> 
> If part_get_info() fails for part==1 then you won't get any of the
> partition devices.  I suppose this could happen if you an unknown
> partition table type, or u-boot is not built w/ the correct partition
> driver.
> 
> BR,
> -R
> 
> 
>> U-Boot> dm tree
>>  Class  Probed  Driver  Name
>> 
>>  root   [ + ]   root_drive  root_driver
>>  simple_bus [ + ]   generic_si  |-- soc
>>  gpio   [ + ]   gpio_bcm28  |   |-- gpio@7e20
>>  serial [ + ]   serial_bcm  |   |-- serial@7e215040
>>  mmc[ + ]   sdhci-bcm2  |   |-- sdhci@7e30
>>  blk[ + ]   mmc_blk |   |   `-- sd...@7e30.blk
>>  video  [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
>>  vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
>>  usb[ + ]   dwc2_usb|   `-- usb@7e98
>>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>>  eth[ + ]   smsc95xx_e  |   |-- smsc95xx_eth
>>  usb_mass_s [ + ]   usb_mass_s  |   `-- usb_mass_storage
>>  blk[   ]   usb_storag  |   `-- usb_mass_storage.lun0
>>  simple_bus [   ]   generic_si  `-- clocks
>>
>>>
 efi_bootdp obtained from the loaded image protocol

 2017.09

 Scanning usb 0:1...
 Found EFI removable media binary efi/boot/bootaa64.efi
 reading efi/boot/bootaa64.efi
 78959 bytes read in 76 ms (1013.7 KiB/s)
 ## Starting EFI application at 0100 ...
 Scanning disk sd...@7e30.blk...
 Scanning disk usb_mass_storage.lun0...
 Found 2 disks
 efi_diskprobe
 efi_device_path_depth looking for type 4 i=0 type 4
 depth=0
 i=0
 efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
 i=1
 efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
>> OpenBSD/arm64 BOOTAA64 0.8
 boot>
 booting sd0a:/bsd: 3871708+578596+509352+803952 
 [283845+96+451968+239920]=0x82f330

 git + patch
>>>
>>>
>>> I assume you are referring to this patch?  It should only add
>>> additional per-partion "disk" objects.  (In UEFI terminology each
>>> partition is a "disk" object.)
>>
>> Yes, "efi_loader: Fix disk dp's for pre-DM/legacy devices".
>> The problem seems to be elsewhere as dropping that I still see:
>>
>> ## Starting EFI application at 0100 ...
>> 

Re: [U-Boot] [PATCH 2/2] dm: clk: fix PWR_CR3 register's bit 2 name

[Vikas MANOCHA]

Hi,

> -Original Message-
> From: Patrice CHOTARD
> Sent: Monday, October 09, 2017 2:41 AM
> To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; s...@chromium.org; Vikas 
> MANOCHA 
> Cc: Patrice CHOTARD ; Patrick DELAUNAY 
> ; Christophe KERELLO
> 
> Subject: [PATCH 2/2] dm: clk: fix PWR_CR3 register's bit 2 name
> 
> From: Patrice Chotard 
> 
> Fix bit 2 name of PWR_CR3 register to match with the last STM32H7 reference 
> manual available here :
> 
> http://www.st.com/content/st_com/en/support/resources/
> resource-selector.html?querycriteria=productId=SS1951$$
> resourceCategory=technical_literature$$resourceType=reference_manual
> 
> Update also comment about voltage scaling 1 values
> 
> Signed-off-by: Patrice Chotard 

Reviewed-by: Vikas Manocha 

Cheers,
Vikas

> ---
>  drivers/clk/clk_stm32h7.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/clk_stm32h7.c b/drivers/clk/clk_stm32h7.c index 
> 9ca497a..ffa902d 100644
> --- a/drivers/clk/clk_stm32h7.c
> +++ b/drivers/clk/clk_stm32h7.c
> @@ -109,7 +109,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define  QSPISRC_PER_CK  3
> 
>  #define PWR_CR3  0x0c
> -#define PWR_CR3_SDEN BIT(2)
> +#define PWR_CR3_SCUENBIT(2)
>  #define PWR_D3CR 0x18
>  #define PWR_D3CR_VOS_MASKGENMASK(15, 14)
>  #define PWR_D3CR_VOS_SHIFT   14
> @@ -361,11 +361,11 @@ int configure_clocks(struct udevice *dev)
>   writel(0x0, >d2ccip1r);
>   writel(0x0, >d2ccip2r);
> 
> - /* Set voltage scaling at scale 1 */
> + /* Set voltage scaling at scale 1 (1,15 - 1,26 Volts) */
>   clrsetbits_le32(pwr_base + PWR_D3CR, PWR_D3CR_VOS_MASK,
>   VOS_SCALE_1 << PWR_D3CR_VOS_SHIFT);
> - /* disable step down converter */
> - clrbits_le32(pwr_base + PWR_CR3, PWR_CR3_SDEN);
> + /* Lock supply configuration update */
> + clrbits_le32(pwr_base + PWR_CR3, PWR_CR3_SCUEN);
>   while (!(readl(pwr_base + PWR_D3CR) & PWR_D3CR_VOSREADY))
>   ;
> 
> --
> 1.9.1

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

Re: [U-Boot] [U-Boot, v1, 4/6] serial: stm32x7: add fifo support for STM32H7

[Tom Rini]

On Wed, Sep 27, 2017 at 03:44:51PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Add fifo mode support for rx and tx.
> As only STM32H7 supports this feature, add has_fifo flag
> to uart configuration to use fifo only when possible.
> 
> Signed-off-by: Patrice Chotard 

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] [U-Boot, 5/7] configs: stm32h743-disco: enable SDMMC support

[Tom Rini]

On Tue, Oct 03, 2017 at 03:55:00PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Enable CMD_MMC, DM_MMC and STM32_SDMMC2 flags
> 
> Signed-off-by: Patrice Chotard 

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] efi_loader: Fix disk dp's for pre-DM/legacy devices

[Jonathan Gray]

On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray  wrote:
> > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote:
> >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
> >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
> >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
> >> >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
> >> >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  
> >> >> >> wrote:
> >> >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
> >> >> >> >> This fixes an issue with OpenBSD's bootloader, and I think should 
> >> >> >> >> also
> >> >> >> >> fix a similar issue with grub2 on legacy devices.  In the legacy 
> >> >> >> >> case
> >> >> >> >> we were creating disk objects for the partitions, but not also the
> >> >> >> >> parent device.
> >> >> >> >>
> >> >> >> >> Reported-by: Jonathan Gray 
> >> >> >> >> Signed-off-by: Rob Clark 
> >> >> >> >
> >> >> >> > Thanks for looking into this.  While this lets armv7/bootarm.efi
> >> >> >> > boot again on cubox-i and bbb it doesn't help rpi3.
> >> >> >> >
> >> >> >> > What is the easiest way to get U-Boot to display these paths
> >> >> >> > to be able to compare the current behaviour to 2017.09?
> >> >> >> >
> >> >> >>
> >> >> >> in grub, there is the lsefi command, not sure if the OpenBSD
> >> >> >> bootloader has something similar?
> >> >> >>
> >> >> >> u-boot implements that device-path to text protocol, so it should be
> >> >> >> pretty easy to implement something like this if not.
> >> >> >>
> >> >> >> BR,
> >> >> >> -R
> >> >> >
> >> >> > With git + your patch a node with type 4 
> >> >> > (DEVICE_PATH_TYPE_MEDIA_DEVICE)
> >> >> > is no longer seen.  Is it possible having U-Boot on mmc but directing
> >> >> > it to load off usb is somehow involved here?
> >> >>
> >> >> There is no requirement that efi payload and u-boot are on the same
> >> >> device.  The distro bootcmd stuff will just look for
> >> >> /efi/boot/bootxyz.efi on all the devices/partitions until it finds
> >> >> one.
> >> >>
> >> >> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
> >> >> or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
> >> >> or legacy boards, in the former case we can construct something more
> >> >> realistic.  Although the bootloader shouldn't really care.
> >> >
> >> > I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
> >> > in master only gives types of 1 (Hardware Device Path) and
> >> > 3 (Messaging Device Path).
> >> >
> >> > It is DM in this case:
> >>
> >> Possibly something weird with your partition table?  In
> >> efi_disk_register() it should create objects for the disk itself
> >> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
> >> partition (part>=1, which would have same dp as the disk but
> >> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
> >>
> >> If part_get_info() fails for part==1 then you won't get any of the
> >> partition devices.  I suppose this could happen if you an unknown
> >> partition table type, or u-boot is not built w/ the correct partition
> >> driver.
> >>
> >> BR,
> >> -R
> >
> > It is partitioned mbr style.
> >
> > U-Boot> part list mmc 0
> >
> > Partition Map for MMC device 0  --   Partition Type: DOS
> >
> > PartStart SectorNum Sectors UUIDType
> >   1 81928192-01 0c Boot
> >   4 16384   26624   -04 a6
> > U-Boot> part list usb 0
> 
> perhaps jumping from partition #1 to #4 is what is confusing things
> here?  It's possible you end up with a partition "diskobj" for
> partition #1 but not #4?
> 
> Try adding a print in efi_disk_register() and see how many times we go
> thru the while(!part_get_info()) loop.

Indeed, it seems to only end up calling efi_disk_add_dev() for
part 1 in that loop:

## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
## Valid DOS partition found ##
efi_disk_register calling efi_disk_add_dev for part 1
## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ##
efi_disk_register calling efi_disk_add_dev for part 1
## Valid DOS partition found ##
Found 2 disks

If I change the code there to match other callers of part_get_info()
I get a MEDIA_DEVICE type and can boot.

## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
## Valid DOS partition found ##
efi_disk_register calling efi_disk_add_dev for part 1
## Valid DOS partition found ##
## Valid DOS partition found ##
efi_disk_register calling efi_disk_add_dev for part 4
## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ##
efi_disk_register calling efi_disk_add_dev for part 1
## Valid DOS 

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

[Rob Clark]

On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
> On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
>> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
>> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
>> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
>> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
>> >> >> This fixes an issue with OpenBSD's bootloader, and I think should also
>> >> >> fix a similar issue with grub2 on legacy devices.  In the legacy case
>> >> >> we were creating disk objects for the partitions, but not also the
>> >> >> parent device.
>> >> >>
>> >> >> Reported-by: Jonathan Gray 
>> >> >> Signed-off-by: Rob Clark 
>> >> >
>> >> > Thanks for looking into this.  While this lets armv7/bootarm.efi
>> >> > boot again on cubox-i and bbb it doesn't help rpi3.
>> >> >
>> >> > What is the easiest way to get U-Boot to display these paths
>> >> > to be able to compare the current behaviour to 2017.09?
>> >> >
>> >>
>> >> in grub, there is the lsefi command, not sure if the OpenBSD
>> >> bootloader has something similar?
>> >>
>> >> u-boot implements that device-path to text protocol, so it should be
>> >> pretty easy to implement something like this if not.
>> >>
>> >> BR,
>> >> -R
>> >
>> > With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
>> > is no longer seen.  Is it possible having U-Boot on mmc but directing
>> > it to load off usb is somehow involved here?
>>
>> There is no requirement that efi payload and u-boot are on the same
>> device.  The distro bootcmd stuff will just look for
>> /efi/boot/bootxyz.efi on all the devices/partitions until it finds
>> one.
>>
>> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
>> or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
>> or legacy boards, in the former case we can construct something more
>> realistic.  Although the bootloader shouldn't really care.
>
> I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
> in master only gives types of 1 (Hardware Device Path) and
> 3 (Messaging Device Path).
>
> It is DM in this case:

Possibly something weird with your partition table?  In
efi_disk_register() it should create objects for the disk itself
(part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
partition (part>=1, which would have same dp as the disk but
additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).

If part_get_info() fails for part==1 then you won't get any of the
partition devices.  I suppose this could happen if you an unknown
partition table type, or u-boot is not built w/ the correct partition
driver.

BR,
-R


> U-Boot> dm tree
>  Class  Probed  Driver  Name
> 
>  root   [ + ]   root_drive  root_driver
>  simple_bus [ + ]   generic_si  |-- soc
>  gpio   [ + ]   gpio_bcm28  |   |-- gpio@7e20
>  serial [ + ]   serial_bcm  |   |-- serial@7e215040
>  mmc[ + ]   sdhci-bcm2  |   |-- sdhci@7e30
>  blk[ + ]   mmc_blk |   |   `-- sd...@7e30.blk
>  video  [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
>  vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
>  usb[ + ]   dwc2_usb|   `-- usb@7e98
>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>  eth[ + ]   smsc95xx_e  |   |-- smsc95xx_eth
>  usb_mass_s [ + ]   usb_mass_s  |   `-- usb_mass_storage
>  blk[   ]   usb_storag  |   `-- usb_mass_storage.lun0
>  simple_bus [   ]   generic_si  `-- clocks
>
>>
>> > efi_bootdp obtained from the loaded image protocol
>> >
>> > 2017.09
>> >
>> > Scanning usb 0:1...
>> > Found EFI removable media binary efi/boot/bootaa64.efi
>> > reading efi/boot/bootaa64.efi
>> > 78959 bytes read in 76 ms (1013.7 KiB/s)
>> > ## Starting EFI application at 0100 ...
>> > Scanning disk sd...@7e30.blk...
>> > Scanning disk usb_mass_storage.lun0...
>> > Found 2 disks
>> > efi_diskprobe
>> > efi_device_path_depth looking for type 4 i=0 type 4
>> > depth=0
>> > i=0
>> > efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
>> > i=1
>> > efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
>> >>> OpenBSD/arm64 BOOTAA64 0.8
>> > boot>
>> > booting sd0a:/bsd: 3871708+578596+509352+803952 
>> > [283845+96+451968+239920]=0x82f330
>> >
>> > git + patch
>>
>>
>> I assume you are referring to this patch?  It should only add
>> additional per-partion "disk" objects.  (In UEFI terminology each
>> partition is a "disk" object.)
>
> Yes, "efi_loader: Fix disk dp's for pre-DM/legacy devices".
> The problem seems to be elsewhere as dropping that I still see:
>
> ## Starting EFI application at 0100 ...
> Scanning disk sd...@7e30.blk...
> Scanning disk usb_mass_storage.lun0...
> Found 2 disks
> efi_diskprobe
> 

Re: [U-Boot] [U-Boot, v2, 1/2] fs/fat: Fix 'CACHE: Misaligned operation at range' warnings

[Tom Rini]

On Sun, Oct 01, 2017 at 02:25:21AM +0300, Tuomas Tynkkynen wrote:

> The 'block' field of fat_itr needs to be properly aligned for DMA and
> while it does have '__aligned(ARCH_DMA_MINALIGN)', the fat_itr structure
> itself needs to be properly aligned as well.
> 
> While at it use malloc_cache_aligned() for the other aligned allocations
> in the file as well.
> 
> Fixes: 2460098cffacd1 ("fs/fat: Reduce stack usage")
> Signed-off-by: Tuomas Tynkkynen 
> Reviewed-by: Tom Rini 

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] [U-Boot, v1, 6/6] serial: stm32x7: remove useless CONFIG_CLK and OF_CONTROL flag

[Tom Rini]

On Wed, Sep 27, 2017 at 03:44:53PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> This driver is currently used by STM32F7 and STM32H7 SoCs.
> As CONFIG_CLK and OF_CONTROL flags are set by default for these
> 2 SoCs, this flag becomes useless in this driver, so remove it.
> 
> Signed-off-by: Patrice Chotard 

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] [U-Boot, 1/7] ARM: DTS: stm32: add SDMMC support for stm32h743 disco

[Tom Rini]

On Tue, Oct 03, 2017 at 03:54:56PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Add pinctrl and sdmmc nodes to add MMC support for
> STM32H743 discovery board.
> 
> Signed-off-by: Patrice Chotard 

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] ARM: stm32f7: fix prescaler calculation of timer

[Tom Rini]

On Mon, Oct 02, 2017 at 10:47:59PM -0700, Bo Shen wrote:

> As the timer 2 is on APB1 bus, the maximum of clock frequency of APB1 timer
> clock is half of SYSCLK. Then to calculate the timer prescaler for timer 2
> which need to be divided by 2.
> 
> Signed-off-by: Bo Shen 
> Reviewed-by: Vikas Manocha 

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] efi_loader: Fix disk dp's for pre-DM/legacy devices

[Rob Clark]

On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray  wrote:
> On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote:
>> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
>> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
>> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
>> >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
>> >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
>> >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
>> >> >> >> This fixes an issue with OpenBSD's bootloader, and I think should 
>> >> >> >> also
>> >> >> >> fix a similar issue with grub2 on legacy devices.  In the legacy 
>> >> >> >> case
>> >> >> >> we were creating disk objects for the partitions, but not also the
>> >> >> >> parent device.
>> >> >> >>
>> >> >> >> Reported-by: Jonathan Gray 
>> >> >> >> Signed-off-by: Rob Clark 
>> >> >> >
>> >> >> > Thanks for looking into this.  While this lets armv7/bootarm.efi
>> >> >> > boot again on cubox-i and bbb it doesn't help rpi3.
>> >> >> >
>> >> >> > What is the easiest way to get U-Boot to display these paths
>> >> >> > to be able to compare the current behaviour to 2017.09?
>> >> >> >
>> >> >>
>> >> >> in grub, there is the lsefi command, not sure if the OpenBSD
>> >> >> bootloader has something similar?
>> >> >>
>> >> >> u-boot implements that device-path to text protocol, so it should be
>> >> >> pretty easy to implement something like this if not.
>> >> >>
>> >> >> BR,
>> >> >> -R
>> >> >
>> >> > With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
>> >> > is no longer seen.  Is it possible having U-Boot on mmc but directing
>> >> > it to load off usb is somehow involved here?
>> >>
>> >> There is no requirement that efi payload and u-boot are on the same
>> >> device.  The distro bootcmd stuff will just look for
>> >> /efi/boot/bootxyz.efi on all the devices/partitions until it finds
>> >> one.
>> >>
>> >> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
>> >> or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
>> >> or legacy boards, in the former case we can construct something more
>> >> realistic.  Although the bootloader shouldn't really care.
>> >
>> > I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
>> > in master only gives types of 1 (Hardware Device Path) and
>> > 3 (Messaging Device Path).
>> >
>> > It is DM in this case:
>>
>> Possibly something weird with your partition table?  In
>> efi_disk_register() it should create objects for the disk itself
>> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
>> partition (part>=1, which would have same dp as the disk but
>> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
>>
>> If part_get_info() fails for part==1 then you won't get any of the
>> partition devices.  I suppose this could happen if you an unknown
>> partition table type, or u-boot is not built w/ the correct partition
>> driver.
>>
>> BR,
>> -R
>
> It is partitioned mbr style.
>
> U-Boot> part list mmc 0
>
> Partition Map for MMC device 0  --   Partition Type: DOS
>
> PartStart SectorNum Sectors UUIDType
>   1 81928192-01 0c Boot
>   4 16384   26624   -04 a6
> U-Boot> part list usb 0

perhaps jumping from partition #1 to #4 is what is confusing things
here?  It's possible you end up with a partition "diskobj" for
partition #1 but not #4?

Try adding a print in efi_disk_register() and see how many times we go
thru the while(!part_get_info()) loop.

BR,
-R

> Partition Map for USB device 0  --   Partition Type: DOS
>
> PartStart SectorNum Sectors UUIDType
>   1 819232768   -01 0c Boot
>   4 40960   60021540-04 a6
>
> I changed the part_get_info() debug messages to normal printfs and no
> error paths trigger:
>
> U-Boot 2017.11-rc1-00111-g97b86e3342-dirty (Oct 10 2017 - 03:28:40 +1100)
>
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> MMC:   sdhci@7e30: 0
> ## Valid DOS partition found ##
> reading uboot.env
> In:serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> USB0:   Core Release: 2.80a
> scanning bus 0 for devices... 4 USB Device(s) found
>scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
>
> Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
> Type: Removable Hard Disk
> Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
> ... is now current device
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> Scanning usb 0:1...
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid 

Re: [U-Boot] [U-Boot, 7/7] configs: stm32h743-eval: enable filesystem related flags

[Tom Rini]

On Tue, Oct 03, 2017 at 03:55:02PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Enable CMD_GPT/EXT2/EXT4/EXT4_WRITE/FAT_FS_GENERIC flags
> 
> Signed-off-by: Patrice Chotard 

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

[U-Boot] [PATCH] ARM: Add documentation for the qemu-arm board

[Tuomas Tynkkynen]

Add brief documentation for the recently merged qemu-arm board.

Signed-off-by: Tuomas Tynkkynen 
---
 doc/README.qemu-arm | 54 +
 1 file changed, 54 insertions(+)
 create mode 100644 doc/README.qemu-arm

diff --git a/doc/README.qemu-arm b/doc/README.qemu-arm
new file mode 100644
index 00..2895e3b97f
--- /dev/null
+++ b/doc/README.qemu-arm
@@ -0,0 +1,54 @@
+#
+# Copyright (C) 2017, Tuomas Tynkkynen 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+U-Boot on QEMU's 'virt' machine on ARM
+==
+
+QEMU for ARM supports a special 'virt' machine designed for emulation and
+virtualization purposes. This document describes how to run U-Boot under it.
+
+The 'virt' platform provides the following as the basic functionality:
+
+- A freely configurable amount of CPU cores
+- U-Boot loaded and executing in the emulated flash at address 0x0
+- A generated device tree blob placed at the start of RAM
+- A freely configurable amount of RAM, described by the DTB
+- A PL011 serial port, discoverable via the DTB
+- An ARMv7 architected timer
+- PSCI for rebooting the system
+- A generic ECAM-based PCI host controller, discoverable via the DTB
+
+Additionally, a number of optional peripherals can be added to the PCI bus.
+
+Building U-Boot
+---
+Set the CROSS_COMPILE and ARCH=arm environment variables as usual, and run:
+
+make qemu_arm_defconfig
+make
+
+Running U-Boot
+--
+The minimal QEMU command line to get U-Boot up and running is:
+
+qemu-system-arm -machine virt,highmem=off -bios u-boot.bin
+
+The 'highmem=off' parameter to the 'virt' machine is required for PCI to work
+in U-Boot.
+
+Additional peripherals that have been tested to work in both U-Boot and Linux
+can be enabled with the following command line parameters:
+
+- To add a Serial ATA disk via an Intel ICH9 AHCI controller, pass e.g.:
+-drive if=none,file=disk.img,id=mydisk -device ich9-ahci,id=ahci -device 
ide-drive,drive=mydisk,bus=ahci.0
+- To add an Intel E1000 network adapter, pass e.g.:
+-netdev user,id=net0 -device e1000,netdev=net0
+- To add an EHCI-compliant USB host controller, pass e.g.:
+-device usb-ehci,id=ehci
+- To add a NVMe disk, pass e.g.:
+-drive if=none,file=disk.img,id=mydisk -device nvme,drive=mydisk,serial=foo
+
+These have been tested in QEMU 2.9.0 but should work in at least 2.5.0 as well.
-- 
2.14.2

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

Re: [U-Boot] [PATCH 1/2] dm: clk: remove CLK() macro for clk_stm32h7

[Vikas MANOCHA]

Hi,

> -Original Message-
> From: Patrice CHOTARD
> Sent: Monday, October 09, 2017 2:41 AM
> To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; s...@chromium.org; Vikas 
> MANOCHA 
> Cc: Patrice CHOTARD ; Patrick DELAUNAY 
> ; Christophe KERELLO
> 
> Subject: [PATCH 1/2] dm: clk: remove CLK() macro for clk_stm32h7
> 
> From: Patrice Chotard 
> 
> CLK() macro is a residue of a previously reworked patch, remove it.
> 
> Signed-off-by: Patrice Chotard 

Reviewed-by: Vikas Manocha 

Cheers,
Vikas

> ---
>  drivers/clk/clk_stm32h7.c | 223 
> ++
>  1 file changed, 108 insertions(+), 115 deletions(-)
> 
> diff --git a/drivers/clk/clk_stm32h7.c b/drivers/clk/clk_stm32h7.c index 
> fd0e3ab..9ca497a 100644
> --- a/drivers/clk/clk_stm32h7.c
> +++ b/drivers/clk/clk_stm32h7.c
> @@ -195,13 +195,6 @@ struct clk_cfg {
>   const char *name;
>  };
> 
> -#define CLK(_gate_offset, _bit_idx, _name) \ -{ \
> - .gate_offset = _gate_offset,\
> - .gate_bit_idx = _bit_idx,\
> - .name = _name,\
> -}
> -
>  /*
>   * the way all these entries are sorted in this array could seem
>   * unlogical, but we are dependant of kernel DT_bindings, @@ -210,114 
> +203,114 @@ struct clk_cfg {
>   */
> 
>  static const struct clk_cfg clk_map[] = {
> - CLK(RCC_AHB3ENR,  31, "d1sram1"),   /* peripheral clocks */
> - CLK(RCC_AHB3ENR,  30, "itcm"),
> - CLK(RCC_AHB3ENR,  29, "dtcm2"),
> - CLK(RCC_AHB3ENR,  28, "dtcm1"),
> - CLK(RCC_AHB3ENR,   8, "flitf"),
> - CLK(RCC_AHB3ENR,   5, "jpgdec"),
> - CLK(RCC_AHB3ENR,   4, "dma2d"),
> - CLK(RCC_AHB3ENR,   0, "mdma"),
> - CLK(RCC_AHB1ENR,  28, "usb2ulpi"),
> - CLK(RCC_AHB1ENR,  17, "eth1rx"),
> - CLK(RCC_AHB1ENR,  16, "eth1tx"),
> - CLK(RCC_AHB1ENR,  15, "eth1mac"),
> - CLK(RCC_AHB1ENR,  14, "art"),
> - CLK(RCC_AHB1ENR,  26, "usb1ulpi"),
> - CLK(RCC_AHB1ENR,   1, "dma2"),
> - CLK(RCC_AHB1ENR,   0, "dma1"),
> - CLK(RCC_AHB2ENR,  31, "d2sram3"),
> - CLK(RCC_AHB2ENR,  30, "d2sram2"),
> - CLK(RCC_AHB2ENR,  29, "d2sram1"),
> - CLK(RCC_AHB2ENR,   5, "hash"),
> - CLK(RCC_AHB2ENR,   4, "crypt"),
> - CLK(RCC_AHB2ENR,   0, "camitf"),
> - CLK(RCC_AHB4ENR,  28, "bkpram"),
> - CLK(RCC_AHB4ENR,  25, "hsem"),
> - CLK(RCC_AHB4ENR,  21, "bdma"),
> - CLK(RCC_AHB4ENR,  19, "crc"),
> - CLK(RCC_AHB4ENR,  10, "gpiok"),
> - CLK(RCC_AHB4ENR,   9, "gpioj"),
> - CLK(RCC_AHB4ENR,   8, "gpioi"),
> - CLK(RCC_AHB4ENR,   7, "gpioh"),
> - CLK(RCC_AHB4ENR,   6, "gpiog"),
> - CLK(RCC_AHB4ENR,   5, "gpiof"),
> - CLK(RCC_AHB4ENR,   4, "gpioe"),
> - CLK(RCC_AHB4ENR,   3, "gpiod"),
> - CLK(RCC_AHB4ENR,   2, "gpioc"),
> - CLK(RCC_AHB4ENR,   1, "gpiob"),
> - CLK(RCC_AHB4ENR,   0, "gpioa"),
> - CLK(RCC_APB3ENR,   6, "wwdg1"),
> - CLK(RCC_APB1LENR, 29, "dac12"),
> - CLK(RCC_APB1LENR, 11, "wwdg2"),
> - CLK(RCC_APB1LENR,  8, "tim14"),
> - CLK(RCC_APB1LENR,  7, "tim13"),
> - CLK(RCC_APB1LENR,  6, "tim12"),
> - CLK(RCC_APB1LENR,  5, "tim7"),
> - CLK(RCC_APB1LENR,  4, "tim6"),
> - CLK(RCC_APB1LENR,  3, "tim5"),
> - CLK(RCC_APB1LENR,  2, "tim4"),
> - CLK(RCC_APB1LENR,  1, "tim3"),
> - CLK(RCC_APB1LENR,  0, "tim2"),
> - CLK(RCC_APB1HENR,  5, "mdios"),
> - CLK(RCC_APB1HENR,  4, "opamp"),
> - CLK(RCC_APB1HENR,  1, "crs"),
> - CLK(RCC_APB2ENR,  18, "tim17"),
> - CLK(RCC_APB2ENR,  17, "tim16"),
> - CLK(RCC_APB2ENR,  16, "tim15"),
> - CLK(RCC_APB2ENR,   1, "tim8"),
> - CLK(RCC_APB2ENR,   0, "tim1"),
> - CLK(RCC_APB4ENR,  26, "tmpsens"),
> - CLK(RCC_APB4ENR,  16, "rtcapb"),
> - CLK(RCC_APB4ENR,  15, "vref"),
> - CLK(RCC_APB4ENR,  14, "comp12"),
> - CLK(RCC_APB4ENR,   1, "syscfg"),
> - CLK(RCC_AHB3ENR,  16, "sdmmc1"),/* kernel clocks */
> - CLK(RCC_AHB3ENR,  14, "quadspi"),
> - CLK(RCC_AHB3ENR,  12, "fmc"),
> - CLK(RCC_AHB1ENR,  27, "usb2otg"),
> - CLK(RCC_AHB1ENR,  25, "usb1otg"),
> - CLK(RCC_AHB1ENR,   5, "adc12"),
> - CLK(RCC_AHB2ENR,   9, "sdmmc2"),
> - CLK(RCC_AHB2ENR,   6, "rng"),
> - CLK(RCC_AHB4ENR,  24, "adc3"),
> - CLK(RCC_APB3ENR,   4, "dsi"),
> - CLK(RCC_APB3ENR,   3, "ltdc"),
> - CLK(RCC_APB1LENR, 31, "usart8"),
> - CLK(RCC_APB1LENR, 30, "usart7"),
> - CLK(RCC_APB1LENR, 27, "hdmicec"),
> - CLK(RCC_APB1LENR, 23, "i2c3"),
> - CLK(RCC_APB1LENR, 22, "i2c2"),
> - CLK(RCC_APB1LENR, 21, "i2c1"),
> - CLK(RCC_APB1LENR, 20, "uart5"),
> - CLK(RCC_APB1LENR, 19, "uart4"),
> - CLK(RCC_APB1LENR, 18, "usart3"),
> - CLK(RCC_APB1LENR, 17, "usart2"),
> - CLK(RCC_APB1LENR, 16, "spdifrx"),
> - CLK(RCC_APB1LENR, 15, "spi3"),
> - CLK(RCC_APB1LENR, 14, "spi2"),
> - CLK(RCC_APB1LENR,  9, 

Re: [U-Boot] cmd: Make CMD_LZMA / CMD_UNZIP default y if CMD_BOOTI

[Tom Rini]

On Fri, Sep 29, 2017 at 02:32:44PM -0400, Tom Rini wrote:

> In the Linux Kernel on ARM64, the Image.COMPRESSION file is not
> self-extracting in the way that x86 and ARM images are.  So when
> CMD_BOOTI is enabled we should also default to enabling CMD_UNZIP and
> CONFIG_LZMA in order for the user to be able to decompress many of the
> common compressions that will be done to an Image file.
> 
> Signed-off-by: Tom Rini 

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] U-Boot sunxi pinctrl

[Dr. Philipp Tomsich]

Joonas,

> On 9 Oct 2017, at 17:49, Joonas Kylmälä  wrote:
> 
> I see you have been working on pinctrl for sunxi in U-Boot:
> .
> But I have no idea how old the patches you have send are so I thought to
> ask whether you are still working on this?

These were a complete patch-set against master on the day the patches
were submitted (i.e. please check the mailing-list archive for the details).
Our internal GIT has these changes on 2017.03-rc3 (i.e. not that old) and
I don’t see a reason why these changes should not easily integrate into
today’s code base.

Our in-house U-Boot for our Allwinner boards is frozen, so there’s no active
development on those branches at the moment.  As of now, my team and I
are focussed on our Rockchip boards (I am one of the u-boot-rockchip
custodians days)…

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

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

[Jonathan Gray]

On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
> >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
> >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
> >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
> >> >> >> This fixes an issue with OpenBSD's bootloader, and I think should 
> >> >> >> also
> >> >> >> fix a similar issue with grub2 on legacy devices.  In the legacy case
> >> >> >> we were creating disk objects for the partitions, but not also the
> >> >> >> parent device.
> >> >> >>
> >> >> >> Reported-by: Jonathan Gray 
> >> >> >> Signed-off-by: Rob Clark 
> >> >> >
> >> >> > Thanks for looking into this.  While this lets armv7/bootarm.efi
> >> >> > boot again on cubox-i and bbb it doesn't help rpi3.
> >> >> >
> >> >> > What is the easiest way to get U-Boot to display these paths
> >> >> > to be able to compare the current behaviour to 2017.09?
> >> >> >
> >> >>
> >> >> in grub, there is the lsefi command, not sure if the OpenBSD
> >> >> bootloader has something similar?
> >> >>
> >> >> u-boot implements that device-path to text protocol, so it should be
> >> >> pretty easy to implement something like this if not.
> >> >>
> >> >> BR,
> >> >> -R
> >> >
> >> > With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
> >> > is no longer seen.  Is it possible having U-Boot on mmc but directing
> >> > it to load off usb is somehow involved here?
> >>
> >> There is no requirement that efi payload and u-boot are on the same
> >> device.  The distro bootcmd stuff will just look for
> >> /efi/boot/bootxyz.efi on all the devices/partitions until it finds
> >> one.
> >>
> >> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
> >> or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
> >> or legacy boards, in the former case we can construct something more
> >> realistic.  Although the bootloader shouldn't really care.
> >
> > I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
> > in master only gives types of 1 (Hardware Device Path) and
> > 3 (Messaging Device Path).
> >
> > It is DM in this case:
> 
> Possibly something weird with your partition table?  In
> efi_disk_register() it should create objects for the disk itself
> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
> partition (part>=1, which would have same dp as the disk but
> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
> 
> If part_get_info() fails for part==1 then you won't get any of the
> partition devices.  I suppose this could happen if you an unknown
> partition table type, or u-boot is not built w/ the correct partition
> driver.
> 
> BR,
> -R

It is partitioned mbr style.

U-Boot> part list mmc 0

Partition Map for MMC device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 81928192-01 0c Boot
  4 16384   26624   -04 a6
U-Boot> part list usb 0

Partition Map for USB device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 819232768   -01 0c Boot
  4 40960   60021540-04 a6

I changed the part_get_info() debug messages to normal printfs and no
error paths trigger:

U-Boot 2017.11-rc1-00111-g97b86e3342-dirty (Oct 10 2017 - 03:28:40 +1100)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   sdhci@7e30: 0
## Valid DOS partition found ##
reading uboot.env
In:serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0 

Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
Type: Removable Hard Disk
Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
... is now current device
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
Scanning usb 0:1...
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
Found EFI removable media binary efi/boot/bootaa64.efi
## Valid DOS partition found ##
## Valid DOS partition found ##
reading efi/boot/bootaa64.efi
78959 bytes read in 86 ms (896.5 KiB/s)
## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
## Valid DOS partition found 

Re: [U-Boot] [U-Boot,1/1] ARMv8: fix error in freeing stack frame

[Tom Rini]

On Sat, Sep 23, 2017 at 01:30:58PM +0800, zijun_hu wrote:

> From: zijun_hu 
> 
> relocate_code() allocates 32 bytes stack frame but only 16 bytes are
> freed before return. it will cause errors to possible previous frames
> and doesn't make relocate_code() look like a function.
> 
> fix by freeing 32 bytes stack space
> 
> Signed-off-by: zijun_hu 
> Reviewed-by: Simon Glass 

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] [U-Boot,v3,2/3] board: STiH410-B2260: fix sdram size

[Tom Rini]

On Mon, Sep 25, 2017 at 09:14:19AM +0200, patrice.chot...@st.com wrote:

> From: Nicolas Le Bayon 
> 
> 32MB are reserved for TrustZone purpose
> 
> Signed-off-by: Nicolas Le Bayon 

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] [U-Boot, 3/7] dm: mmc: remove DM_MMC_OPS for STM32_SDMMC

[Tom Rini]

On Tue, Oct 03, 2017 at 03:54:58PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Since e7881d85 "dm: mmc: Drop CONFIG_DM_MMC_OPS" DM_MMC_OPS
> is no more used, remove it from STM32_SDMMC2 dependencies
> 
> Signed-off-by: Patrice Chotard 

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] armv8: configs: ls1012a: correct the generic timer frequency issue

[York Sun]

On 10/08/2017 11:48 PM, andy.t...@nxp.com wrote:
> From: Yuantian Tang 
> 
> Generic Timer frequency should be 25Mhz. Current setting is
> CONFIG_SYS_CLK_FREQ/4 which is about 31Mhz, which is not correct.
> So correct it.
> 
> Signed-off-by: Tang Yuantian 
> ---
>  include/configs/ls1012a_common.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/ls1012a_common.h 
> b/include/configs/ls1012a_common.h
> index 096799eb64..a4e78f335f 100644
> --- a/include/configs/ls1012a_common.h
> +++ b/include/configs/ls1012a_common.h
> @@ -32,7 +32,7 @@
>  #define CONFIG_SYS_DDR_BLOCK2_BASE 0x88000ULL
>  
>  /* Generic Timer Definitions */
> -#define COUNTER_FREQUENCYCONFIG_SYS_CLK_FREQ/4   /* 25MHz */
> +#define COUNTER_FREQUENCY2500/* 25MHz */
>  


Yuantian,

LS1012A use fixed 25MHz clock, doesn't it? If so, that's the reason a
fixed value should be used, not because CONFIG_SYS_CLK_FREQ/4 isn't
correct. It is correct for many other platform. Please update the commit
message.

York


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

Re: [U-Boot] [U-Boot, v3, 3/3] board: STiH410-B2260: set ramdisk_addr_r to 0x48000000

[Tom Rini]

On Mon, Sep 25, 2017 at 09:14:20AM +0200, patrice.chot...@st.com wrote:

> From: Lee Jones 
> 
> Add missing ramdisk_addr_r param and set it to 0x4800
> 
> Signed-off-by: Lee Jones 
> Reviewed-by: Simon Glass 

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] [U-Boot,v1,5/6] serial: stm32x7: add STM32F4 support

[Tom Rini]

On Wed, Sep 27, 2017 at 03:44:52PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> stm32f4 doesn't support FIFO and OVERRUN feature.
> The enable bit is not at the same location in CR1
> register than for STM32F7 and STM32H7.
> 
> Signed-off-by: Patrice Chotard 

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] [U-Boot, v1, 3/6] serial: stm32x7: prepare the ground to STM32F4 support

[Tom Rini]

On Wed, Sep 27, 2017 at 03:44:50PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> STM32F4 serial IP is similar to F7 and H7, but registers
> are not located at the same offset and some feature are
> only supported by F7 and H7 version.
> 
> Registers offset must be added for each version and also
> some flags indicated the supported feature.
> 
> Update registers name to match with datasheet (sr to isr,
> rx_dr to rdr and tx_dr to tdr) and remove unused regs
> (cr2, gtpr, rtor, and rqr).
> 
> Signed-off-by: Patrice Chotard 

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] [U-Boot, 1/1] ARMv8: make master CPU checking logic more clear

[Tom Rini]

On Mon, Sep 25, 2017 at 03:28:50PM +0800, zijun_hu wrote:

> From: zijun_hu 
> 
> macro branch_if_master checks master CPU via (Aff3 & (Aff2:Aff1:Aff0))
> it is simple but a little obscure.
> 
> fix by checking Affx fields within MPIDR_EL1 directly.
> 
> Signed-off-by: zijun_hu 

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] [U-Boot, 6/7] configs: stm32h743-disco: enable filesystem related flags

[Tom Rini]

On Tue, Oct 03, 2017 at 03:55:01PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Enable CMD_GPT/EXT2/EXT4/EXT4_WRITE/FAT_FS_GENERIC flags
> 
> Signed-off-by: Patrice Chotard 

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] [U-Boot, 4/7] configs: stm32h743-eval: enable SDMMC support

[Tom Rini]

On Tue, Oct 03, 2017 at 03:54:59PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Enable CMD_MMC, DM_MMC and STM32_SDMMC2 flags
> 
> Signed-off-by: Patrice Chotard 

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] Broadwell-DE bare metal

[Zoran Stojsavljevic]

 > It allows U-Boot to boot from EFI.

This is a true art of overkill... Really.

Full EFI (around 1 to 2 million lines of code: SEC, PEI, DXE phases, with
ME HECI involved, altogether) -> U-Boot -> YOCTO. Wow. ;-)

Zoran

On Mon, Oct 9, 2017 at 4:43 PM, Simon Glass  wrote:

> Hi,
>
> On 3 October 2017 at 08:58, vnktux  wrote:
> > Hi all,
> >
> > For my graduation project my company asked to use U-Boot as bare metal
> boot-loader on one of their product. The product in an embedded board with
> a Xeon Broadwell-DE D-1527 Quad Core. The current boot-loader consist of
> Coreboot + U-Boot, but of course they want to get rid of Coreboot. I have
> almost no experience with U-Boot (Just with ARM processor a little bit) and
> so far I don't even know if it's possible or not to achieve the final goal.
> What I have understood is that I need the following binary blobs to work:
> fsp.bin, vga.bin, descriptor.bin, me.bin, microcode.bin. Is it true? Can
> somebody point me in the right direction because I am a little bit lost?
> Plus I don't see many x86 boards implemented in the source code of U-Boot.
>
> The original U-Boot payload support was done with Broadwell-DE (I'm
> not sure which one though). It allows U-Boot to boot from EFI.
>
> For what you want, yes you will need to obtain various binary blobs.
> Hopefully you can get the FSP from Intel, and with that the work
> required in U-Boot is probably not too large. Although I'm sure that
> the FSP API will have changed a little.
>
> Regards,
> Simon
>
> >
> > Best regards,
> > Vincenzo
> >
> > Sent with [ProtonMail](https://protonmail.com) Secure Email.
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/1] ARMv8: get new GD address from gd->new_gd directly

[Tom Rini]

On Fri, Sep 22, 2017 at 02:39:13PM +0800, zijun_hu wrote:

> From: zijun_hu 
> 
> the new GD address is calculated via board data BD currently
> it require the new GD area locates below BD tightly, so a strict
> constraint is imposed on memory layout which maybe make special
> platform unpleasant.
> 
> fix it by getting new GD address from gd->new_gd directly.
> 
> Signed-off-by: zijun_hu 
> Reviewed-by: Simon Glass 

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 RESEND] DW SPI: Get clock value from Device Tree

[Eugeniy Paltsev]

Hi,

Maybe you have any comments or remarks about this patch? And if you don't could 
you please apply it. 

Thanks!

On Tue, 2017-09-26 at 16:10 +0300, Eugeniy Paltsev wrote:
> Add option to set spi controller clock frequency via device tree
> using standard clock bindings.
> Old way of setting spi controller clock frequency (via implementation
> of 'cm_get_spi_controller_clk_hz' function in platform specific code)
> remains supported.
> 
> Signed-off-by: Eugeniy Paltsev 
> ---
>  Resending due to previously sent one was discarded by mailing list.
> 
>  drivers/spi/designware_spi.c | 68 
> +++-
>  1 file changed, 67 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
> index 5aa507b..c70697e 100644
> --- a/drivers/spi/designware_spi.c
> +++ b/drivers/spi/designware_spi.c
> @@ -11,6 +11,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -94,6 +95,7 @@ struct dw_spi_priv {
>   void __iomem *regs;
>   unsigned int freq;  /* Default frequency */
>   unsigned int mode;
> + unsigned long bus_clk_rate;
>  
>   int bits_per_word;
>   u8 cs;  /* chip select pin */
> @@ -176,14 +178,78 @@ static void spi_hw_init(struct dw_spi_priv *priv)
>   debug("%s: fifo_len=%d\n", __func__, priv->fifo_len);
>  }
>  
> +/*
> + * cm_get_spi_controller_clk_hz function is old way to set spi controller
> + * frequency. If it isn't implemented and spi controller frequency isn't set 
> via
> + * device tree we will get into next default function.
> + */
> +__weak unsigned int cm_get_spi_controller_clk_hz(void)
> +{
> + error("SPI clock is defined neither via device tree nor via 
> cm_get_spi_controller_clk_hz!");
> +
> + return 0;
> +}
> +
> +static int dw_spi_of_get_clk(struct udevice *bus)
> +{
> +#if CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(CLK)
> + struct dw_spi_priv *priv = dev_get_priv(bus);
> + unsigned long clk_rate;
> + struct clk clk;
> + int ret;
> +
> + ret = clk_get_by_index(bus, 0, );
> + if (ret)
> + return -EINVAL;
> +
> + ret = clk_enable();
> + if (ret && ret != -ENOSYS)
> + return ret;
> +
> + clk_rate = clk_get_rate();
> + if (!clk_rate)
> + return -EINVAL;
> +
> + priv->bus_clk_rate = clk_rate;
> +
> + clk_free();
> +
> + return 0;
> +#endif
> +
> + return -ENOSYS;
> +}
> +
> +static int dw_spi_get_clk(struct udevice *bus)
> +{
> + struct dw_spi_priv *priv = dev_get_priv(bus);
> +
> + /* Firstly try to get clock frequency from device tree */
> + if (!dw_spi_of_get_clk(bus))
> + return 0;
> +
> + /* In case of failure rollback to cm_get_spi_controller_clk_hz */
> + priv->bus_clk_rate = cm_get_spi_controller_clk_hz();
> +
> + if (!priv->bus_clk_rate)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
>  static int dw_spi_probe(struct udevice *bus)
>  {
>   struct dw_spi_platdata *plat = dev_get_platdata(bus);
>   struct dw_spi_priv *priv = dev_get_priv(bus);
> + int ret;
>  
>   priv->regs = plat->regs;
>   priv->freq = plat->frequency;
>  
> + ret = dw_spi_get_clk(bus);
> + if (ret)
> + return ret;
> +
>   /* Currently only bits_per_word == 8 supported */
>   priv->bits_per_word = 8;
>  
> @@ -369,7 +435,7 @@ static int dw_spi_set_speed(struct udevice *bus, uint 
> speed)
>   spi_enable_chip(priv, 0);
>  
>   /* clk_div doesn't support odd number */
> - clk_div = cm_get_spi_controller_clk_hz() / speed;
> + clk_div = priv->bus_clk_rate / speed;
>   clk_div = (clk_div + 1) & 0xfffe;
>   dw_writel(priv, DW_SPI_BAUDR, clk_div);
>  
-- 
 Eugeniy Paltsev
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 1/3] board: STiH410-B2260: update environment variable

[Tom Rini]

On Mon, Sep 25, 2017 at 09:14:18AM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Update environment variable by updating:
>  _ BOOT_TARGET_DEVICE
>  _ CONFIGS_BOOTARGS
>  _ kernel_addr_r, fdtfile, fdt_addr_r, scriptaddr, fdt_high, intird_high
> 
> Signed-off-by: Patrice Chotard 
> Reviewed-by: Simon Glass 

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] [U-Boot, v1, 2/6] serial: stm32x7: remove stm32f7-usart and stm32h7-usart compatible

[Tom Rini]

On Wed, Sep 27, 2017 at 03:44:49PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> This patch remove the extra compatibility string "st,stm32h7-usart"
> and "st,stm32f7-usart" to avoid confusion, save some time & space.
> 
> Signed-off-by: Patrice Chotard 
> Reviewed-by: Vikas Manocha 

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] configs: stm32: update SRAM address for STM32H7 disco and eval

[Tom Rini]

On Tue, Oct 03, 2017 at 03:47:59PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> As suggested by Vikas Manocha, update embedded SRAM address
> to use AXI SRAM available on D1 domain instead of using
> AHB SRAM (D2 domain).
> On some STM32H743 SoCs, D2 domain SRAM is accessible even if
> SRAMxEN bit in AHB2ENR bits are not set whereas on others SoCs
> version it's not accessible.
> 
> Signed-off-by: Patrice Chotard 
> Reviewed-by: Vikas Manocha 

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] [U-Boot, 2/7] ARM: DTS: stm32: add SDMMC support fo stm32h743-eval

[Tom Rini]

On Tue, Oct 03, 2017 at 03:54:57PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Add pinctrl and sdmmc nodes to add MMC support for
> STM32H743 evaluation board.
> 
> Evaluation board needs a second pinctrl node
> "pinctrl_sdmmc1_level_shifter" to drive a level shifter
> on MMC bus.
> 
> Signed-off-by: Patrice Chotard 

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] scripts: Move Kconfig contents to cmd/Kconfig

[Tom Rini]

On Thu, Sep 28, 2017 at 12:33:45PM -0700, Sam Protsenko wrote:

> On case-insensitive file systems we have collision between
> scripts/kconfig/ directory and scripts/Kconfig file. This patch moves
> scripts/Kcofnig contents to cmd/Kconfig to fix that.
> 
> Signed-off-by: Sam Protsenko 
> Acked-by: Masahiro Yamada 

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] [U-Boot,v1,1/6] serial: stm32x7: cleanup code

[Tom Rini]

On Wed, Sep 27, 2017 at 03:44:48PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Use BIT() macro and GENMASK() macro
> 
> Signed-off-by: Patrice Chotard 
> Reviewed-by: Vikas Manocha 

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] efi_loader: Fix disk dp's for pre-DM/legacy devices

[Rob Clark]

On Mon, Oct 9, 2017 at 12:22 PM, Heinrich Schuchardt  wrote:
> On 10/09/2017 06:06 PM, Rob Clark wrote:
>> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
>>> On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
 On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
> On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
>> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
>>> On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
 This fixes an issue with OpenBSD's bootloader, and I think should also
 fix a similar issue with grub2 on legacy devices.  In the legacy case
 we were creating disk objects for the partitions, but not also the
 parent device.

 Reported-by: Jonathan Gray 
 Signed-off-by: Rob Clark 
>>>
>>> Thanks for looking into this.  While this lets armv7/bootarm.efi
>>> boot again on cubox-i and bbb it doesn't help rpi3.
>>>
>>> What is the easiest way to get U-Boot to display these paths
>>> to be able to compare the current behaviour to 2017.09?
>>>
>>
>> in grub, there is the lsefi command, not sure if the OpenBSD
>> bootloader has something similar?
>>
>> u-boot implements that device-path to text protocol, so it should be
>> pretty easy to implement something like this if not.
>>
>> BR,
>> -R
>
> With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
> is no longer seen.  Is it possible having U-Boot on mmc but directing
> it to load off usb is somehow involved here?

 There is no requirement that efi payload and u-boot are on the same
 device.  The distro bootcmd stuff will just look for
 /efi/boot/bootxyz.efi on all the devices/partitions until it finds
 one.

 The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
 or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
 or legacy boards, in the former case we can construct something more
 realistic.  Although the bootloader shouldn't really care.
>>>
>>> I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
>>> in master only gives types of 1 (Hardware Device Path) and
>>> 3 (Messaging Device Path).
>>>
>>> It is DM in this case:
>>
>> Possibly something weird with your partition table?  In
>> efi_disk_register() it should create objects for the disk itself
>> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
>> partition (part>=1, which would have same dp as the disk but
>> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
>>
>> If part_get_info() fails for part==1 then you won't get any of the
>> partition devices.  I suppose this could happen if you an unknown
>> partition table type, or u-boot is not built w/ the correct partition
>> driver.
>>
>> BR,
>> -R
>>
>>
>>> U-Boot> dm tree
>>>  Class  Probed  Driver  Name
>>> 
>>>  root   [ + ]   root_drive  root_driver
>>>  simple_bus [ + ]   generic_si  |-- soc
>>>  gpio   [ + ]   gpio_bcm28  |   |-- gpio@7e20
>>>  serial [ + ]   serial_bcm  |   |-- serial@7e215040
>>>  mmc[ + ]   sdhci-bcm2  |   |-- sdhci@7e30
>>>  blk[ + ]   mmc_blk |   |   `-- sd...@7e30.blk
>>>  video  [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
>>>  vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
>>>  usb[ + ]   dwc2_usb|   `-- usb@7e98
>>>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>>>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>>>  eth[ + ]   smsc95xx_e  |   |-- smsc95xx_eth
>>>  usb_mass_s [ + ]   usb_mass_s  |   `-- usb_mass_storage
>>>  blk[   ]   usb_storag  |   `-- 
>>> usb_mass_storage.lun0
>>>  simple_bus [   ]   generic_si  `-- clocks
>>>

> efi_bootdp obtained from the loaded image protocol
>
> 2017.09
>
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> reading efi/boot/bootaa64.efi
> 78959 bytes read in 76 ms (1013.7 KiB/s)
> ## Starting EFI application at 0100 ...
> Scanning disk sd...@7e30.blk...
> Scanning disk usb_mass_storage.lun0...
> Found 2 disks
> efi_diskprobe
> efi_device_path_depth looking for type 4 i=0 type 4
> depth=0
> i=0
> efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
> i=1
> efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
>>> OpenBSD/arm64 BOOTAA64 0.8
> boot>
> booting sd0a:/bsd: 3871708+578596+509352+803952 
> [283845+96+451968+239920]=0x82f330
>
> git + patch


 I assume you are referring to this patch?  It should only add
 additional per-partion "disk" objects.  (In UEFI terminology each
 partition is a "disk" 

Re: [U-Boot] [U-Boot, v2, 2/2] fs/fat: Check malloc return values and fix memory leaks

[Tom Rini]

On Sun, Oct 01, 2017 at 02:25:22AM +0300, Tuomas Tynkkynen wrote:

> Check malloc() return values and properly unwind on errors so
> memory allocated for fat_itr structures get freed properly.
> 
> Also fixes a leak of fsdata.fatbuf in fat_size().
> 
> Fixes: 2460098cffacd1 ("fs/fat: Reduce stack usage")
> Reported-by: Coverity (CID: 167225, 167233, 167234)
> Signed-off-by: Tuomas Tynkkynen 
> Reviewed-by: Tom Rini 

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

[U-Boot] [PATCH V2] ARM: imx6: Add DHCOM i.MX6 PDK board support

[Marek Vasut]

Add support for the DHCOM i.MX6 PDK board. This board has:
- FEC ethernet
- EHCI USB host
- 3x SDMMC

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
---
V2: Use get_cpu_type() and imx_get_mac_from_fuse()
---
 arch/arm/mach-imx/mx6/Kconfig |  10 +
 board/dhelectronics/dh_imx6/Kconfig   |  12 +
 board/dhelectronics/dh_imx6/MAINTAINERS   |   7 +
 board/dhelectronics/dh_imx6/Makefile  |  11 +
 board/dhelectronics/dh_imx6/dh_imx6.c | 437 ++
 board/dhelectronics/dh_imx6/dh_imx6_spl.c | 399 +++
 configs/dh_imx6_defconfig |  51 
 include/configs/dh_imx6.h | 191 +
 8 files changed, 1118 insertions(+)
 create mode 100644 board/dhelectronics/dh_imx6/Kconfig
 create mode 100644 board/dhelectronics/dh_imx6/MAINTAINERS
 create mode 100644 board/dhelectronics/dh_imx6/Makefile
 create mode 100644 board/dhelectronics/dh_imx6/dh_imx6.c
 create mode 100644 board/dhelectronics/dh_imx6/dh_imx6_spl.c
 create mode 100644 configs/dh_imx6_defconfig
 create mode 100644 include/configs/dh_imx6.h

diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index 540f2b29b1..b82db3af22 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -129,6 +129,15 @@ config TARGET_COLIBRI_IMX6
select DM_SERIAL
select DM_THERMAL
 
+config TARGET_DHCOMIMX6
+   bool "dh_imx6"
+   select BOARD_LATE_INIT
+   select BOARD_EARLY_INIT_F
+   select SUPPORT_SPL
+   select DM
+   select DM_THERMAL
+   imply CMD_SPL
+
 config TARGET_EMBESTMX6BOARDS
bool "embestmx6boards"
select BOARD_LATE_INIT
@@ -428,6 +437,7 @@ source "board/boundary/nitrogen6x/Kconfig"
 source "board/ccv/xpress/Kconfig"
 source "board/compulab/cm_fx6/Kconfig"
 source "board/congatec/cgtqmx6eval/Kconfig"
+source "board/dhelectronics/dh_imx6/Kconfig"
 source "board/el/el6x/Kconfig"
 source "board/embest/mx6boards/Kconfig"
 source "board/engicam/geam6ul/Kconfig"
diff --git a/board/dhelectronics/dh_imx6/Kconfig 
b/board/dhelectronics/dh_imx6/Kconfig
new file mode 100644
index 00..0cfef9b097
--- /dev/null
+++ b/board/dhelectronics/dh_imx6/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_DHCOMIMX6
+
+config SYS_BOARD
+   default "dh_imx6"
+
+config SYS_VENDOR
+   default "dhelectronics"
+
+config SYS_CONFIG_NAME
+   default "dh_imx6"
+
+endif
diff --git a/board/dhelectronics/dh_imx6/MAINTAINERS 
b/board/dhelectronics/dh_imx6/MAINTAINERS
new file mode 100644
index 00..e54bd60adb
--- /dev/null
+++ b/board/dhelectronics/dh_imx6/MAINTAINERS
@@ -0,0 +1,7 @@
+DH_IMX6 BOARD
+M: Andreas Geisreiter , Ludwig Zenz 

+S: Maintained
+F: board/dhelectronics/dh_imx6/
+F: include/configs/dh_imx6.h
+F: configs/dh_mx6q_defconfig
+F: configs/dh_mx6dl_defconfig
diff --git a/board/dhelectronics/dh_imx6/Makefile 
b/board/dhelectronics/dh_imx6/Makefile
new file mode 100644
index 00..bddc8d8568
--- /dev/null
+++ b/board/dhelectronics/dh_imx6/Makefile
@@ -0,0 +1,11 @@
+#
+# Copyright (C) 2017 Marek Vasut 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+ifdef CONFIG_SPL_BUILD
+obj-y  := dh_imx6_spl.o
+else
+obj-y  := dh_imx6.o
+endif
diff --git a/board/dhelectronics/dh_imx6/dh_imx6.c 
b/board/dhelectronics/dh_imx6/dh_imx6.c
new file mode 100644
index 00..c76da4d2af
--- /dev/null
+++ b/board/dhelectronics/dh_imx6/dh_imx6.c
@@ -0,0 +1,437 @@
+/*
+ * DHCOM DH-iMX6 PDK board support
+ *
+ * Copyright (C) 2017 Marek Vasut 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define I2C_PAD_CTRL   \
+   (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm |  \
+   PAD_CTL_HYS | PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+
+#define EEPROM_I2C_ADDRESS 0x50
+
+#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+
+static struct i2c_pads_info dh6sdl_i2c_pad_info0 = {
+   .scl = {
+   .i2c_mode  = MX6DL_PAD_EIM_D21__I2C1_SCL | PC,
+   .gpio_mode = MX6DL_PAD_EIM_D21__GPIO3_IO21 | PC,
+   .gp = IMX_GPIO_NR(3, 21)
+   },
+   .sda = {
+.i2c_mode = MX6DL_PAD_EIM_D28__I2C1_SDA | PC,
+.gpio_mode = MX6DL_PAD_EIM_D28__GPIO3_IO28 | PC,
+.gp = IMX_GPIO_NR(3, 28)
+}
+};
+
+static struct i2c_pads_info dh6sdl_i2c_pad_info1 = {
+   .scl = {
+   .i2c_mode  = MX6DL_PAD_KEY_COL3__I2C2_SCL | PC,
+   .gpio_mode = MX6DL_PAD_KEY_COL3__GPIO4_IO12 | PC,
+   .gp = IMX_GPIO_NR(4, 

[U-Boot] [PATCH v2 1/1] efi_loader: MAX_UTF8_PER_UTF16 = 3

[Heinrich Schuchardt]

The constant MAX_UTF8_PER_UTF16 is used to calculated
required memory when converting from UTF-16 to UTF-8.
If this constant is too big we waste memory.

A code point encoded by one UTF-16 symbol is converted to a
maximum of three UTF-8 symbols, e.g.

0x could be encoded as 0xef 0xbf 0xbf.
The first byte carries four bits, the second and third byte
carry six bits each.

A code point encoded by two UTF-16 symbols is converted to four
UTF-8 symbols.

So in this case we need a maximum of two UTF-8 symbols per
UTF-16 symbol.

As the overall maximum is three UTF-8 symobls per UTF-8 symbol
we need MAX_UTF8_PER_UTF16 = 3.

Fixes: 78178bb0c9d lib: add some utf16 handling helpers
Signed-off-by: Heinrich Schuchardt 
---
The code is only used by efi_loader.
So this patch should go via efi-next.

v2
rework the commit message
---
 include/charset.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/charset.h b/include/charset.h
index 9c2866bbe6..2f7f7eacc9 100644
--- a/include/charset.h
+++ b/include/charset.h
@@ -9,7 +9,7 @@
 #ifndef __CHARSET_H_
 #define __CHARSET_H_
 
-#define MAX_UTF8_PER_UTF16 4
+#define MAX_UTF8_PER_UTF16 3
 
 /**
  * utf16_strlen() - Get the length of an utf16 string
@@ -52,7 +52,7 @@ uint16_t *utf16_strdup(const uint16_t *s);
  * Converts 'size' characters of the utf16 string 'src' to utf8
  * written to the 'dest' buffer.
  *
- * NOTE that a single utf16 character can generate up to 4 utf8
+ * NOTE that a single utf16 character can generate up to 3 utf8
  * characters.  See MAX_UTF8_PER_UTF16.
  *
  * @dest   the destination buffer to write the utf8 characters
-- 
2.14.1

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

[U-Boot] [PATCH v3 1/1] efi_loader: MAX_UTF8_PER_UTF16 = 3

[Heinrich Schuchardt]

The constant MAX_UTF8_PER_UTF16 is used to calculated
required memory when converting from UTF-16 to UTF-8.
If this constant is too big we waste memory.

A code point encoded by one UTF-16 symbol is converted to a
maximum of three UTF-8 symbols, e.g.

0x could be encoded as 0xef 0xbf 0xbf.
The first byte carries four bits, the second and third byte
carry six bits each.

A code point encoded by two UTF-16 symbols is converted to four
UTF-8 symbols.

So in this case we need a maximum of two UTF-8 symbols per
UTF-16 symbol.

As the overall maximum is three UTF-8 symobls per UTF-16 symbol
we need MAX_UTF8_PER_UTF16 = 3.

Fixes: 78178bb0c9d lib: add some utf16 handling helpers
Signed-off-by: Heinrich Schuchardt 
---
The code is only used by efi_loader.
So this patch should go via efi-next.

v3
fix typo
v2
rework the commit message
---
 include/charset.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/charset.h b/include/charset.h
index 9c2866bbe6..2f7f7eacc9 100644
--- a/include/charset.h
+++ b/include/charset.h
@@ -9,7 +9,7 @@
 #ifndef __CHARSET_H_
 #define __CHARSET_H_
 
-#define MAX_UTF8_PER_UTF16 4
+#define MAX_UTF8_PER_UTF16 3
 
 /**
  * utf16_strlen() - Get the length of an utf16 string
@@ -52,7 +52,7 @@ uint16_t *utf16_strdup(const uint16_t *s);
  * Converts 'size' characters of the utf16 string 'src' to utf8
  * written to the 'dest' buffer.
  *
- * NOTE that a single utf16 character can generate up to 4 utf8
+ * NOTE that a single utf16 character can generate up to 3 utf8
  * characters.  See MAX_UTF8_PER_UTF16.
  *
  * @dest   the destination buffer to write the utf8 characters
-- 
2.14.1

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

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

[Rob Clark]

On Mon, Oct 9, 2017 at 1:48 PM, Jonathan Gray  wrote:
> On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote:
>> On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray  wrote:
>> > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote:
>> >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
>> >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
>> >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
>> >> >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
>> >> >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  
>> >> >> >> wrote:
>> >> >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
>> >> >> >> >> This fixes an issue with OpenBSD's bootloader, and I think 
>> >> >> >> >> should also
>> >> >> >> >> fix a similar issue with grub2 on legacy devices.  In the legacy 
>> >> >> >> >> case
>> >> >> >> >> we were creating disk objects for the partitions, but not also 
>> >> >> >> >> the
>> >> >> >> >> parent device.
>> >> >> >> >>
>> >> >> >> >> Reported-by: Jonathan Gray 
>> >> >> >> >> Signed-off-by: Rob Clark 
>> >> >> >> >
>> >> >> >> > Thanks for looking into this.  While this lets armv7/bootarm.efi
>> >> >> >> > boot again on cubox-i and bbb it doesn't help rpi3.
>> >> >> >> >
>> >> >> >> > What is the easiest way to get U-Boot to display these paths
>> >> >> >> > to be able to compare the current behaviour to 2017.09?
>> >> >> >> >
>> >> >> >>
>> >> >> >> in grub, there is the lsefi command, not sure if the OpenBSD
>> >> >> >> bootloader has something similar?
>> >> >> >>
>> >> >> >> u-boot implements that device-path to text protocol, so it should be
>> >> >> >> pretty easy to implement something like this if not.
>> >> >> >>
>> >> >> >> BR,
>> >> >> >> -R
>> >> >> >
>> >> >> > With git + your patch a node with type 4 
>> >> >> > (DEVICE_PATH_TYPE_MEDIA_DEVICE)
>> >> >> > is no longer seen.  Is it possible having U-Boot on mmc but directing
>> >> >> > it to load off usb is somehow involved here?
>> >> >>
>> >> >> There is no requirement that efi payload and u-boot are on the same
>> >> >> device.  The distro bootcmd stuff will just look for
>> >> >> /efi/boot/bootxyz.efi on all the devices/partitions until it finds
>> >> >> one.
>> >> >>
>> >> >> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
>> >> >> or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
>> >> >> or legacy boards, in the former case we can construct something more
>> >> >> realistic.  Although the bootloader shouldn't really care.
>> >> >
>> >> > I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
>> >> > in master only gives types of 1 (Hardware Device Path) and
>> >> > 3 (Messaging Device Path).
>> >> >
>> >> > It is DM in this case:
>> >>
>> >> Possibly something weird with your partition table?  In
>> >> efi_disk_register() it should create objects for the disk itself
>> >> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
>> >> partition (part>=1, which would have same dp as the disk but
>> >> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
>> >>
>> >> If part_get_info() fails for part==1 then you won't get any of the
>> >> partition devices.  I suppose this could happen if you an unknown
>> >> partition table type, or u-boot is not built w/ the correct partition
>> >> driver.
>> >>
>> >> BR,
>> >> -R
>> >
>> > It is partitioned mbr style.
>> >
>> > U-Boot> part list mmc 0
>> >
>> > Partition Map for MMC device 0  --   Partition Type: DOS
>> >
>> > PartStart SectorNum Sectors UUIDType
>> >   1 81928192-01 0c Boot
>> >   4 16384   26624   -04 a6
>> > U-Boot> part list usb 0
>>
>> perhaps jumping from partition #1 to #4 is what is confusing things
>> here?  It's possible you end up with a partition "diskobj" for
>> partition #1 but not #4?
>>
>> Try adding a print in efi_disk_register() and see how many times we go
>> thru the while(!part_get_info()) loop.
>
> Indeed, it seems to only end up calling efi_disk_add_dev() for
> part 1 in that loop:
>
> ## Starting EFI application at 0100 ...
> Scanning disk sd...@7e30.blk...
> ## Valid DOS partition found ##
> efi_disk_register calling efi_disk_add_dev for part 1
> ## Valid DOS partition found ##
> Scanning disk usb_mass_storage.lun0...
> ## Valid DOS partition found ##
> efi_disk_register calling efi_disk_add_dev for part 1
> ## Valid DOS partition found ##
> Found 2 disks
>
> If I change the code there to match other callers of part_get_info()
> I get a MEDIA_DEVICE type and can boot.

Ok, this makes sense now.  There is one more loop to fix in the
non-DM/BLK case (well, the one added by this patch, which I think
agraf has already applied).

Care to send a patch?

BR,
-R

> ## Starting EFI application at 0100 ...
> Scanning disk 

[U-Boot] [PATCH 1/1] efi_loader: MAX_UTF8_PER_UTF16 = 3

[Heinrich Schuchardt]

A code point encoded by one UTF-16 symbol is converted to a
maximum of three UTF-8 symbols.

0x could be encoded as 0xef 0xbf 0xbf.
The first byte carries four bits, the second and third byte
carry six bits each.

A code point encoded by two UTF-16 symbols is converted to four
UTF-8 symbols.

Fixes: 78178bb0c9d lib: add some utf16 handling helpers
Signed-off-by: Heinrich Schuchardt 
---
The code is only used by efi_loader.
So this patch should go via efi-next.
---
 include/charset.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/charset.h b/include/charset.h
index 9c2866bbe6..2f7f7eacc9 100644
--- a/include/charset.h
+++ b/include/charset.h
@@ -9,7 +9,7 @@
 #ifndef __CHARSET_H_
 #define __CHARSET_H_
 
-#define MAX_UTF8_PER_UTF16 4
+#define MAX_UTF8_PER_UTF16 3
 
 /**
  * utf16_strlen() - Get the length of an utf16 string
@@ -52,7 +52,7 @@ uint16_t *utf16_strdup(const uint16_t *s);
  * Converts 'size' characters of the utf16 string 'src' to utf8
  * written to the 'dest' buffer.
  *
- * NOTE that a single utf16 character can generate up to 4 utf8
+ * NOTE that a single utf16 character can generate up to 3 utf8
  * characters.  See MAX_UTF8_PER_UTF16.
  *
  * @dest   the destination buffer to write the utf8 characters
-- 
2.14.1

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

Re: [U-Boot] [PATCH 1/1] efi_loader: MAX_UTF8_PER_UTF16 = 3

[Heinrich Schuchardt]

On 10/09/2017 08:43 PM, Alexander Graf wrote:
> 
> 
>> Am 09.10.2017 um 20:39 schrieb Heinrich Schuchardt :
>>
>> A code point encoded by one UTF-16 symbol is converted to a
>> maximum of three UTF-8 symbols.
>>
>> 0x could be encoded as 0xef 0xbf 0xbf.
>> The first byte carries four bits, the second and third byte
>> carry six bits each.
>>
>> A code point encoded by two UTF-16 symbols is converted to four
>> UTF-8 symbols.
> 
> Yes, so why do you set it to 3?

The constant is not bytes per code point but bytes per UTF-16.

4 / 2 = 2 < 3

Cheers

Heinrich

> 
> Please also explain what exactly this actually fixes :).
> 
> 
> Alex
> 
>>
>> Fixes: 78178bb0c9d lib: add some utf16 handling helpers
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>> The code is only used by efi_loader.
>> So this patch should go via efi-next.
>> ---
>> include/charset.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/charset.h b/include/charset.h
>> index 9c2866bbe6..2f7f7eacc9 100644
>> --- a/include/charset.h
>> +++ b/include/charset.h
>> @@ -9,7 +9,7 @@
>> #ifndef __CHARSET_H_
>> #define __CHARSET_H_
>>
>> -#define MAX_UTF8_PER_UTF16 4
>> +#define MAX_UTF8_PER_UTF16 3
>>
>> /**
>>  * utf16_strlen() - Get the length of an utf16 string
>> @@ -52,7 +52,7 @@ uint16_t *utf16_strdup(const uint16_t *s);
>>  * Converts 'size' characters of the utf16 string 'src' to utf8
>>  * written to the 'dest' buffer.
>>  *
>> - * NOTE that a single utf16 character can generate up to 4 utf8
>> + * NOTE that a single utf16 character can generate up to 3 utf8
>>  * characters.  See MAX_UTF8_PER_UTF16.
>>  *
>>  * @dest   the destination buffer to write the utf8 characters
>> -- 
>> 2.14.1
>>
> 

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

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

[Peter Robinson]

On Mon, Oct 9, 2017 at 7:20 PM, Rob Clark  wrote:
> On Mon, Oct 9, 2017 at 1:48 PM, Jonathan Gray  wrote:
>> On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote:
>>> On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray  wrote:
>>> > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote:
>>> >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
>>> >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
>>> >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
>>> >> >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
>>> >> >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  
>>> >> >> >> wrote:
>>> >> >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
>>> >> >> >> >> This fixes an issue with OpenBSD's bootloader, and I think 
>>> >> >> >> >> should also
>>> >> >> >> >> fix a similar issue with grub2 on legacy devices.  In the 
>>> >> >> >> >> legacy case
>>> >> >> >> >> we were creating disk objects for the partitions, but not also 
>>> >> >> >> >> the
>>> >> >> >> >> parent device.
>>> >> >> >> >>
>>> >> >> >> >> Reported-by: Jonathan Gray 
>>> >> >> >> >> Signed-off-by: Rob Clark 
>>> >> >> >> >
>>> >> >> >> > Thanks for looking into this.  While this lets armv7/bootarm.efi
>>> >> >> >> > boot again on cubox-i and bbb it doesn't help rpi3.
>>> >> >> >> >
>>> >> >> >> > What is the easiest way to get U-Boot to display these paths
>>> >> >> >> > to be able to compare the current behaviour to 2017.09?
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >> in grub, there is the lsefi command, not sure if the OpenBSD
>>> >> >> >> bootloader has something similar?
>>> >> >> >>
>>> >> >> >> u-boot implements that device-path to text protocol, so it should 
>>> >> >> >> be
>>> >> >> >> pretty easy to implement something like this if not.
>>> >> >> >>
>>> >> >> >> BR,
>>> >> >> >> -R
>>> >> >> >
>>> >> >> > With git + your patch a node with type 4 
>>> >> >> > (DEVICE_PATH_TYPE_MEDIA_DEVICE)
>>> >> >> > is no longer seen.  Is it possible having U-Boot on mmc but 
>>> >> >> > directing
>>> >> >> > it to load off usb is somehow involved here?
>>> >> >>
>>> >> >> There is no requirement that efi payload and u-boot are on the same
>>> >> >> device.  The distro bootcmd stuff will just look for
>>> >> >> /efi/boot/bootxyz.efi on all the devices/partitions until it finds
>>> >> >> one.
>>> >> >>
>>> >> >> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
>>> >> >> or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
>>> >> >> or legacy boards, in the former case we can construct something more
>>> >> >> realistic.  Although the bootloader shouldn't really care.
>>> >> >
>>> >> > I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
>>> >> > in master only gives types of 1 (Hardware Device Path) and
>>> >> > 3 (Messaging Device Path).
>>> >> >
>>> >> > It is DM in this case:
>>> >>
>>> >> Possibly something weird with your partition table?  In
>>> >> efi_disk_register() it should create objects for the disk itself
>>> >> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
>>> >> partition (part>=1, which would have same dp as the disk but
>>> >> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
>>> >>
>>> >> If part_get_info() fails for part==1 then you won't get any of the
>>> >> partition devices.  I suppose this could happen if you an unknown
>>> >> partition table type, or u-boot is not built w/ the correct partition
>>> >> driver.
>>> >>
>>> >> BR,
>>> >> -R
>>> >
>>> > It is partitioned mbr style.
>>> >
>>> > U-Boot> part list mmc 0
>>> >
>>> > Partition Map for MMC device 0  --   Partition Type: DOS
>>> >
>>> > PartStart SectorNum Sectors UUIDType
>>> >   1 81928192-01 0c Boot
>>> >   4 16384   26624   -04 a6
>>> > U-Boot> part list usb 0
>>>
>>> perhaps jumping from partition #1 to #4 is what is confusing things
>>> here?  It's possible you end up with a partition "diskobj" for
>>> partition #1 but not #4?
>>>
>>> Try adding a print in efi_disk_register() and see how many times we go
>>> thru the while(!part_get_info()) loop.
>>
>> Indeed, it seems to only end up calling efi_disk_add_dev() for
>> part 1 in that loop:
>>
>> ## Starting EFI application at 0100 ...
>> Scanning disk sd...@7e30.blk...
>> ## Valid DOS partition found ##
>> efi_disk_register calling efi_disk_add_dev for part 1
>> ## Valid DOS partition found ##
>> Scanning disk usb_mass_storage.lun0...
>> ## Valid DOS partition found ##
>> efi_disk_register calling efi_disk_add_dev for part 1
>> ## Valid DOS partition found ##
>> Found 2 disks
>>
>> If I change the code there to match other callers of part_get_info()
>> I get a MEDIA_DEVICE type and can boot.
>
> Ok, this makes sense now.  There is one 

Re: [U-Boot] [PATCH 1/1] efi_loader: MAX_UTF8_PER_UTF16 = 3

[Alexander Graf]

> Am 09.10.2017 um 20:39 schrieb Heinrich Schuchardt :
> 
> A code point encoded by one UTF-16 symbol is converted to a
> maximum of three UTF-8 symbols.
> 
> 0x could be encoded as 0xef 0xbf 0xbf.
> The first byte carries four bits, the second and third byte
> carry six bits each.
> 
> A code point encoded by two UTF-16 symbols is converted to four
> UTF-8 symbols.

Yes, so why do you set it to 3?

Please also explain what exactly this actually fixes :).


Alex

> 
> Fixes: 78178bb0c9d lib: add some utf16 handling helpers
> Signed-off-by: Heinrich Schuchardt 
> ---
> The code is only used by efi_loader.
> So this patch should go via efi-next.
> ---
> include/charset.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/charset.h b/include/charset.h
> index 9c2866bbe6..2f7f7eacc9 100644
> --- a/include/charset.h
> +++ b/include/charset.h
> @@ -9,7 +9,7 @@
> #ifndef __CHARSET_H_
> #define __CHARSET_H_
> 
> -#define MAX_UTF8_PER_UTF16 4
> +#define MAX_UTF8_PER_UTF16 3
> 
> /**
>  * utf16_strlen() - Get the length of an utf16 string
> @@ -52,7 +52,7 @@ uint16_t *utf16_strdup(const uint16_t *s);
>  * Converts 'size' characters of the utf16 string 'src' to utf8
>  * written to the 'dest' buffer.
>  *
> - * NOTE that a single utf16 character can generate up to 4 utf8
> + * NOTE that a single utf16 character can generate up to 3 utf8
>  * characters.  See MAX_UTF8_PER_UTF16.
>  *
>  * @dest   the destination buffer to write the utf8 characters
> -- 
> 2.14.1
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: imx6: Add DHCOM i.MX6 PDK board support

[Marek Vasut]

On 10/09/2017 09:28 PM, Stefano Babic wrote:
> Hi Marek,

Hi,

clip please ...

[...]

>> +static int setup_dhcom_mac_from_fuse(void)
>> +{
>> +unsigned char enetaddr[6];
>> +u32 fuseval[2];
>> +int ret;
>> +
>> +ret = eth_env_get_enetaddr("ethaddr", enetaddr);
>> +if (ret)/* ethaddr is already set */
>> +return 0;
>> +
>> +ret = fuse_read(4, 2, [0]);
>> +if (ret) {
>> +printf("Error reading the eFUSE0 with MAC address\n");
>> +return ret;
>> +}
>> +
>> +ret = fuse_read(4, 3, [1]);
>> +if (ret) {
>> +printf("Error reading the eFUSE1 with MAC address\n");
>> +return ret;
>> +}
>> +
>> +enetaddr[0] = fuseval[1] >> 8;
>> +enetaddr[1] = fuseval[1] >> 0;
>> +enetaddr[2] = fuseval[0] >> 24;
>> +enetaddr[3] = fuseval[0] >> 16;
>> +enetaddr[4] = fuseval[0] >> 8;
>> +enetaddr[5] = fuseval[0] >> 0;
>> +
> 
> 
> Is the first part different as imx_get_mac_from_fuse() ?  It looks like
> to me that MAC is stored as usually in bank 4, address 2.
> 
> If yes, you can call the function instead reading yourself from fuses.

Cool, that's what I was looking for, thanks.

>> +if (is_valid_ethaddr(enetaddr)) {
>> +eth_env_set_enetaddr("ethaddr", enetaddr);
>> +return 0;
>> +}
>> +
>> +ret = i2c_set_bus_num(2);
>> +if (ret) {
>> +printf("Error switching I2C bus!\n");
>> +return ret;
>> +}
>> +
>> +ret = i2c_read(EEPROM_I2C_ADDRESS, 0xfa, 0x1, enetaddr, 0x6);
>> +if (ret) {
>> +printf("Error reading configuration EEPROM!\n");
>> +return ret;
>> +}
>> +
>> +if (is_valid_ethaddr(enetaddr))
>> +eth_env_set_enetaddr("ethaddr", enetaddr);
>> +
>> +return 0;
>> +}
>> +
>> +int board_early_init_f(void)
>> +{
>> +#ifdef CONFIG_USB_EHCI_MX6
>> +setup_usb();
>> +#endif
>> +
>> +return 0;
>> +}
>> +
>> +#ifdef CONFIG_MXC_SPI
>> +int board_spi_cs_gpio(unsigned bus, unsigned cs)
>> +{
>> +if (bus == 0 && cs == 0)
>> +return IMX_GPIO_NR(2, 30);
>> +else
>> +return -1;
>> +}
>> +#endif
>> +
>> +int board_init(void)
>> +{
>> +struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
>> +
>> +/* address of boot parameters */
>> +gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
>> +
>> +/* Enable eim_slow clocks */
>> +setbits_le32(_ccm->CCGR6, 0x1 << MXC_CCM_CCGR6_EMI_SLOW_OFFSET);
>> +
>> +#ifdef CONFIG_SYS_I2C_MXC
>> +if (is_mx6dq()) {
>> +setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info0);
>> +setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info1);
>> +setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info2);
>> +} else {
>> +setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info0);
>> +setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info1);
>> +setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, _i2c_pad_info2);
>> +}
>> +#endif
>> +
>> +#ifdef CONFIG_SATA
>> +setup_sata();
>> +#endif
>> +
>> +setup_dhcom_mac_from_fuse();
>> +
>> +return 0;
>> +}
>> +
>> +#ifdef CONFIG_CMD_BMODE
>> +static const struct boot_mode board_boot_modes[] = {
>> +/* 4 bit bus width */
>> +{"sd2",  MAKE_CFGVAL(0x40, 0x28, 0x00, 0x00)},
>> +{"sd3",  MAKE_CFGVAL(0x40, 0x30, 0x00, 0x00)},
>> +/* 8 bit bus width */
>> +{"emmc", MAKE_CFGVAL(0x40, 0x38, 0x00, 0x00)},
>> +{NULL,   0},
>> +};
>> +#endif
>> +
>> +#define HW_CODE_BIT_0   IMX_GPIO_NR(2, 19)
>> +#define HW_CODE_BIT_1   IMX_GPIO_NR(6, 6)
>> +#define HW_CODE_BIT_2   IMX_GPIO_NR(2, 16)
>> +
>> +static int board_get_hwcode(void)
>> +{
>> +int hw_code;
>> +
>> +gpio_direction_input(HW_CODE_BIT_0);
>> +gpio_direction_input(HW_CODE_BIT_1);
>> +gpio_direction_input(HW_CODE_BIT_2);
>> +
>> +/* HW 100 + HW 200 = 00b; HW 300 = 01b */
>> +hw_code = ((gpio_get_value(HW_CODE_BIT_2) << 2) |
>> +   (gpio_get_value(HW_CODE_BIT_1) << 1) |
>> +gpio_get_value(HW_CODE_BIT_0)) + 2;
>> +
>> +return hw_code;
>> +}
>> +
>> +int board_late_init(void)
>> +{
>> +u32 hw_code, cpu_rev;
>> +char buf[16];
>> +
>> +cpu_rev = get_cpu_rev();
>> +hw_code = board_get_hwcode();
>> +
>> +switch (cpu_rev >> 12) {
> 
> Nitpick: there is a macro for it, get_cpu_type()

Fixed

>> +case MXC_CPU_MX6SOLO:
>> +snprintf(buf, sizeof(buf), "imx6s-dhcom%1d", hw_code);
>> +break;
>> +case MXC_CPU_MX6DL:
>> +snprintf(buf, sizeof(buf), "imx6dl-dhcom%1d", hw_code);
>> +break;
>> +case MXC_CPU_MX6D:
>> +snprintf(buf, sizeof(buf), "imx6d-dhcom%1d", hw_code);
>> +break;
>> +case MXC_CPU_MX6Q:
>> +snprintf(buf, sizeof(buf), "imx6q-dhcom%1d", hw_code);
>> +break;
>> +default:
>> +snprintf(buf, sizeof(buf), "UNKNOWN%1d", 

Re: [U-Boot] [PATCH] ARM: imx6: Add DHCOM i.MX6 PDK board support

[Stefano Babic]

Hi Marek,

On 09/10/2017 20:13, Marek Vasut wrote:
> Add support for the DHCOM i.MX6 PDK board. This board has:
> - FEC ethernet
> - EHCI USB host
> - 3x SDMMC
> 
> Signed-off-by: Marek Vasut 
> Cc: Stefano Babic 
> ---
>  arch/arm/mach-imx/mx6/Kconfig |  10 +
>  board/dhelectronics/dh_imx6/Kconfig   |  12 +
>  board/dhelectronics/dh_imx6/MAINTAINERS   |   7 +
>  board/dhelectronics/dh_imx6/Makefile  |  11 +
>  board/dhelectronics/dh_imx6/dh_imx6.c | 456 
> ++
>  board/dhelectronics/dh_imx6/dh_imx6_spl.c | 399 ++
>  configs/dh_imx6_defconfig |  51 
>  include/configs/dh_imx6.h | 191 +
>  8 files changed, 1137 insertions(+)
>  create mode 100644 board/dhelectronics/dh_imx6/Kconfig
>  create mode 100644 board/dhelectronics/dh_imx6/MAINTAINERS
>  create mode 100644 board/dhelectronics/dh_imx6/Makefile
>  create mode 100644 board/dhelectronics/dh_imx6/dh_imx6.c
>  create mode 100644 board/dhelectronics/dh_imx6/dh_imx6_spl.c
>  create mode 100644 configs/dh_imx6_defconfig
>  create mode 100644 include/configs/dh_imx6.h
> 
> diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
> index 540f2b29b1..b82db3af22 100644
> --- a/arch/arm/mach-imx/mx6/Kconfig
> +++ b/arch/arm/mach-imx/mx6/Kconfig
> @@ -129,6 +129,15 @@ config TARGET_COLIBRI_IMX6
>   select DM_SERIAL
>   select DM_THERMAL
>  
> +config TARGET_DHCOMIMX6
> + bool "dh_imx6"
> + select BOARD_LATE_INIT
> + select BOARD_EARLY_INIT_F
> + select SUPPORT_SPL
> + select DM
> + select DM_THERMAL
> + imply CMD_SPL
> +
>  config TARGET_EMBESTMX6BOARDS
>   bool "embestmx6boards"
>   select BOARD_LATE_INIT
> @@ -428,6 +437,7 @@ source "board/boundary/nitrogen6x/Kconfig"
>  source "board/ccv/xpress/Kconfig"
>  source "board/compulab/cm_fx6/Kconfig"
>  source "board/congatec/cgtqmx6eval/Kconfig"
> +source "board/dhelectronics/dh_imx6/Kconfig"
>  source "board/el/el6x/Kconfig"
>  source "board/embest/mx6boards/Kconfig"
>  source "board/engicam/geam6ul/Kconfig"
> diff --git a/board/dhelectronics/dh_imx6/Kconfig 
> b/board/dhelectronics/dh_imx6/Kconfig
> new file mode 100644
> index 00..0cfef9b097
> --- /dev/null
> +++ b/board/dhelectronics/dh_imx6/Kconfig
> @@ -0,0 +1,12 @@
> +if TARGET_DHCOMIMX6
> +
> +config SYS_BOARD
> + default "dh_imx6"
> +
> +config SYS_VENDOR
> + default "dhelectronics"
> +
> +config SYS_CONFIG_NAME
> + default "dh_imx6"
> +
> +endif
> diff --git a/board/dhelectronics/dh_imx6/MAINTAINERS 
> b/board/dhelectronics/dh_imx6/MAINTAINERS
> new file mode 100644
> index 00..e54bd60adb
> --- /dev/null
> +++ b/board/dhelectronics/dh_imx6/MAINTAINERS
> @@ -0,0 +1,7 @@
> +DH_IMX6 BOARD
> +M:   Andreas Geisreiter , Ludwig Zenz 
> 
> +S:   Maintained
> +F:   board/dhelectronics/dh_imx6/
> +F:   include/configs/dh_imx6.h
> +F:   configs/dh_mx6q_defconfig
> +F:   configs/dh_mx6dl_defconfig
> diff --git a/board/dhelectronics/dh_imx6/Makefile 
> b/board/dhelectronics/dh_imx6/Makefile
> new file mode 100644
> index 00..bddc8d8568
> --- /dev/null
> +++ b/board/dhelectronics/dh_imx6/Makefile
> @@ -0,0 +1,11 @@
> +#
> +# Copyright (C) 2017 Marek Vasut 
> +#
> +# SPDX-License-Identifier:   GPL-2.0+
> +#
> +
> +ifdef CONFIG_SPL_BUILD
> +obj-y:= dh_imx6_spl.o
> +else
> +obj-y:= dh_imx6.o
> +endif
> diff --git a/board/dhelectronics/dh_imx6/dh_imx6.c 
> b/board/dhelectronics/dh_imx6/dh_imx6.c
> new file mode 100644
> index 00..e372fbad32
> --- /dev/null
> +++ b/board/dhelectronics/dh_imx6/dh_imx6.c
> @@ -0,0 +1,456 @@
> +/*
> + * DHCOM DH-iMX6 PDK board support
> + *
> + * Copyright (C) 2017 Marek Vasut 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define I2C_PAD_CTRL \
> + (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm |  \
> + PAD_CTL_HYS | PAD_CTL_ODE | PAD_CTL_SRE_FAST)
> +
> +#define EEPROM_I2C_ADDRESS   0x50
> +
> +#define PC   MUX_PAD_CTRL(I2C_PAD_CTRL)
> +
> +static struct i2c_pads_info dh6sdl_i2c_pad_info0 = {
> + .scl = {
> + .i2c_mode  = MX6DL_PAD_EIM_D21__I2C1_SCL | PC,
> + .gpio_mode = MX6DL_PAD_EIM_D21__GPIO3_IO21 | PC,
> + .gp = IMX_GPIO_NR(3, 21)
> + },
> + .sda = {
> +  .i2c_mode = MX6DL_PAD_EIM_D28__I2C1_SDA | PC,
> +  .gpio_mode = MX6DL_PAD_EIM_D28__GPIO3_IO28 | PC,
> +  .gp = 

Re: [U-Boot] fsl_esdhc driver is broken with DM

[Jagan Teki]

On Mon, Oct 2, 2017 at 4:36 PM, Fabio Estevam  wrote:
> Hi Jagan,
>
> On Mon, Oct 2, 2017 at 7:23 AM, Jagan Teki  wrote:
>
>> Yes, currently I'm using DM_MMC for U-Boot proper and recently I've
>> moved SPL as well [1].  But I've seen an issue with i.MX6UL while
>> moving to OF_SPL
>
> What exactly is the MX6UL issue you see?

I didn't dig much, but the i.MX6UL case has rebooting with DM_MMC for
both SPL and U-Boot proper.

Log:
-
U-Boot SPL 2017.09-00371-ga81bf43 (Oct 09 2017 - 22:55:26)
Trying to boot from MMC1


U-Boot 2017.09-00371-ga81bf43 (Oct 09 2017 - 22:55:26 +0530)

CPU:   Freescale i.MX6UL rev1.1 528 MHz (running at 396 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 33C
Reset cause: POR
Model: Engicam GEAM6UL
DRAM:  128 MiB

U-Boot SPL 2017.09-00371-ga81bf43 (Oct 09 2017 - 22:55:26)
Trying to boot from MMC1


U-Boot 2017.09-00371-ga81bf43 (Oct 09 2017 - 22:55:26 +0530)

CPU:   Freescale i.MX6UL rev1.1 528 MHz (running at 396 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 36C
Reset cause: unknown reset
Model: Engicam GEAM6UL
DRAM:  128 MiB

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: imx6: Add DHCOM i.MX6 PDK board support

[Marek Vasut]

Add support for the DHCOM i.MX6 PDK board. This board has:
- FEC ethernet
- EHCI USB host
- 3x SDMMC

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
---
 arch/arm/mach-imx/mx6/Kconfig |  10 +
 board/dhelectronics/dh_imx6/Kconfig   |  12 +
 board/dhelectronics/dh_imx6/MAINTAINERS   |   7 +
 board/dhelectronics/dh_imx6/Makefile  |  11 +
 board/dhelectronics/dh_imx6/dh_imx6.c | 456 ++
 board/dhelectronics/dh_imx6/dh_imx6_spl.c | 399 ++
 configs/dh_imx6_defconfig |  51 
 include/configs/dh_imx6.h | 191 +
 8 files changed, 1137 insertions(+)
 create mode 100644 board/dhelectronics/dh_imx6/Kconfig
 create mode 100644 board/dhelectronics/dh_imx6/MAINTAINERS
 create mode 100644 board/dhelectronics/dh_imx6/Makefile
 create mode 100644 board/dhelectronics/dh_imx6/dh_imx6.c
 create mode 100644 board/dhelectronics/dh_imx6/dh_imx6_spl.c
 create mode 100644 configs/dh_imx6_defconfig
 create mode 100644 include/configs/dh_imx6.h

diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index 540f2b29b1..b82db3af22 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -129,6 +129,15 @@ config TARGET_COLIBRI_IMX6
select DM_SERIAL
select DM_THERMAL
 
+config TARGET_DHCOMIMX6
+   bool "dh_imx6"
+   select BOARD_LATE_INIT
+   select BOARD_EARLY_INIT_F
+   select SUPPORT_SPL
+   select DM
+   select DM_THERMAL
+   imply CMD_SPL
+
 config TARGET_EMBESTMX6BOARDS
bool "embestmx6boards"
select BOARD_LATE_INIT
@@ -428,6 +437,7 @@ source "board/boundary/nitrogen6x/Kconfig"
 source "board/ccv/xpress/Kconfig"
 source "board/compulab/cm_fx6/Kconfig"
 source "board/congatec/cgtqmx6eval/Kconfig"
+source "board/dhelectronics/dh_imx6/Kconfig"
 source "board/el/el6x/Kconfig"
 source "board/embest/mx6boards/Kconfig"
 source "board/engicam/geam6ul/Kconfig"
diff --git a/board/dhelectronics/dh_imx6/Kconfig 
b/board/dhelectronics/dh_imx6/Kconfig
new file mode 100644
index 00..0cfef9b097
--- /dev/null
+++ b/board/dhelectronics/dh_imx6/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_DHCOMIMX6
+
+config SYS_BOARD
+   default "dh_imx6"
+
+config SYS_VENDOR
+   default "dhelectronics"
+
+config SYS_CONFIG_NAME
+   default "dh_imx6"
+
+endif
diff --git a/board/dhelectronics/dh_imx6/MAINTAINERS 
b/board/dhelectronics/dh_imx6/MAINTAINERS
new file mode 100644
index 00..e54bd60adb
--- /dev/null
+++ b/board/dhelectronics/dh_imx6/MAINTAINERS
@@ -0,0 +1,7 @@
+DH_IMX6 BOARD
+M: Andreas Geisreiter , Ludwig Zenz 

+S: Maintained
+F: board/dhelectronics/dh_imx6/
+F: include/configs/dh_imx6.h
+F: configs/dh_mx6q_defconfig
+F: configs/dh_mx6dl_defconfig
diff --git a/board/dhelectronics/dh_imx6/Makefile 
b/board/dhelectronics/dh_imx6/Makefile
new file mode 100644
index 00..bddc8d8568
--- /dev/null
+++ b/board/dhelectronics/dh_imx6/Makefile
@@ -0,0 +1,11 @@
+#
+# Copyright (C) 2017 Marek Vasut 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+ifdef CONFIG_SPL_BUILD
+obj-y  := dh_imx6_spl.o
+else
+obj-y  := dh_imx6.o
+endif
diff --git a/board/dhelectronics/dh_imx6/dh_imx6.c 
b/board/dhelectronics/dh_imx6/dh_imx6.c
new file mode 100644
index 00..e372fbad32
--- /dev/null
+++ b/board/dhelectronics/dh_imx6/dh_imx6.c
@@ -0,0 +1,456 @@
+/*
+ * DHCOM DH-iMX6 PDK board support
+ *
+ * Copyright (C) 2017 Marek Vasut 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define I2C_PAD_CTRL   \
+   (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm |  \
+   PAD_CTL_HYS | PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+
+#define EEPROM_I2C_ADDRESS 0x50
+
+#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+
+static struct i2c_pads_info dh6sdl_i2c_pad_info0 = {
+   .scl = {
+   .i2c_mode  = MX6DL_PAD_EIM_D21__I2C1_SCL | PC,
+   .gpio_mode = MX6DL_PAD_EIM_D21__GPIO3_IO21 | PC,
+   .gp = IMX_GPIO_NR(3, 21)
+   },
+   .sda = {
+.i2c_mode = MX6DL_PAD_EIM_D28__I2C1_SDA | PC,
+.gpio_mode = MX6DL_PAD_EIM_D28__GPIO3_IO28 | PC,
+.gp = IMX_GPIO_NR(3, 28)
+}
+};
+
+static struct i2c_pads_info dh6sdl_i2c_pad_info1 = {
+   .scl = {
+   .i2c_mode  = MX6DL_PAD_KEY_COL3__I2C2_SCL | PC,
+   .gpio_mode = MX6DL_PAD_KEY_COL3__GPIO4_IO12 | PC,
+   .gp = IMX_GPIO_NR(4, 12)
+   },
+   .sda = {
+

Re: [U-Boot] [PATCH v2 01/14] arm: socfpga: stratix10: Add base address map for Statix10 SoC

[Dinh Nguyen]

On Thu, Oct 5, 2017 at 8:07 AM,   wrote:
> From: Chin Liang See 
>
> Add the base address map for Statix10 SoC
>
> Signed-off-by: Chin Liang See 
> ---
>  arch/arm/mach-socfpga/include/mach/base_addr_s10.h | 56 
> ++
>  1 file changed, 56 insertions(+)
>  create mode 100644 arch/arm/mach-socfpga/include/mach/base_addr_s10.h
>
> diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_s10.h 
> b/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
> new file mode 100644
> index 000..2fdc917
> --- /dev/null
> +++ b/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
> @@ -0,0 +1,56 @@
> +/*
> + * Copyright (C) 2016-2017 Intel Corporation 
> + *
> + * SPDX-License-Identifier:GPL-2.0
> + */
> +
> +#ifndef _SOCFPGA_S10_BASE_HARDWARE_H_
> +#define _SOCFPGA_S10_BASE_HARDWARE_H_
> +
> +#define SOCFPGA_SDR_SCHEDULER_ADDRESS  0xf8000400
> +#define SOCFPGA_HMC_MMR_IO48_ADDRESS   0xf801
> +#define SOCFPGA_SDR_ADDRESS0xf8011000
> +#define SOCFPGA_SMMU_ADDRESS   0xfa00
> +#define SOCFPGA_MAILBOX_ADDRESS0xffA3
> +#define SOCFPGA_USB0_ADDRESS   0xffb0
> +#define SOCFPGA_USB1_ADDRESS   0xffb4

USB address is obtainable from DT.

> +#define SOCFPGA_NANDREGS_ADDRESS   0xffb8
> +#define SOCFPGA_NANDDATA_ADDRESS   0xffb9
> +#define SOCFPGA_UART0_ADDRESS  0xffc02000
> +#define SOCFPGA_UART1_ADDRESS  0xffc02100
> +#define SOCFPGA_I2C0_ADDRESS   0xffc02800
> +#define SOCFPGA_I2C1_ADDRESS   0xffc02900
> +#define SOCFPGA_I2C2_ADDRESS   0xffc02a00
> +#define SOCFPGA_I2C3_ADDRESS   0xffc02b00
> +#define SOCFPGA_I2C4_ADDRESS   0xffc02c00

I2C is also obtainabled

Please check the other peripherals.

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

Re: [U-Boot] [PATCH v1 1/3] test/py: gpt: update test_gpt

[Stephen Warren]

On 10/09/2017 01:47 AM, Patrick Delaunay wrote:

- copy the reference gpt binary file as it is modified during the test
   to avoid issue if the test fail: the test always restart with clean file
- update tests to highlight detected issues on gpt swap command
   (offset and size of partition are modified)
- add test for gpt verfiy, gpt read and gpt write


It might be nice to split this into separate patches for separate 
logical changes.



diff --git a/test/py/tests/test_gpt.py b/test/py/tests/test_gpt.py



  These tests rely on a 4 MB disk image, which is automatically created by
-the test.
+the test, but as we expect specific content and it is modified by the gpt
+commands executed during the test, it is not safe be reused it directly


That's a bit of an internal detail. I'm not sure it's necessary to spell 
it out in the documentation?



  class GptTestDiskImage(object):
@@ -28,26 +29,31 @@ class GptTestDiskImage(object):
  """
  
  filename = 'test_gpt_disk_image.bin'

+
  self.path = u_boot_console.config.persistent_data_dir + '/' + filename
+ref_path = u_boot_console.config.persistent_data_dir + '/ref_' + 
filename


Can we put self.path somewhere other than persistent_data_dir? Since it 
gets re-created every time, it's not persistent. Other tests use 
u_boot_console.config.result_dir for temporary files.



@@ -64,6 +70,30 @@ def state_disk_image(u_boot_console):
  @pytest.mark.boardspec('sandbox')
  @pytest.mark.buildconfigspec('cmd_gpt')
  @pytest.mark.requiredtool('sgdisk')
+def test_gpt_read(state_disk_image, u_boot_console):
+"""Test the gpt read command."""
+
+u_boot_console.run_command('host bind 0 ' + state_disk_image.path)
+output = u_boot_console.run_command('gpt read host 0')
+assert 'Start 1MiB, size 0MiB' in output
+assert 'Start 2MiB, size 0MiB' in output
+output = u_boot_console.run_command('part list host 0')


I think this test should also be:
@pytest.mark.buildconfigspec('cmd_part')

Some of the other diffs in this path add use of the part command for the 
first time, so I think you need to add that decorator to a few other 
functions too.



@@ -109,9 +142,29 @@ def test_gpt_swap_partitions(state_disk_image, 
u_boot_console):
  
  u_boot_console.run_command('host bind 0 ' + state_disk_image.path)

  output = u_boot_console.run_command('part list host 0')
-assert '0x07ff "first"' in output
-assert '0x17ff "second"' in output
+assert '0x0800 0x0a00  "first"' in output
+assert '0x1000 0x1200  "second"' in output


I'm not sure why this change is required. I can see two separate changes 
here:


1) Verifies the value of 3 columns of data not just 2. That seems fine.

2) Changes the expected value in the column before the partition name. 
I'm not sure about this; shouldn't the value stay the same, or is the 
test failing right now?

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

Re: [U-Boot] [PATCH v3] sun50i: h5: Add NanoPi Neo Plus2 DT initial support

[Maxime Ripard]

On Mon, Oct 09, 2017 at 07:31:37AM +, Antony Antony wrote:
> On Mon, Oct 09, 2017 at 09:22:03AM +0200, Maxime Ripard wrote:
> > On Fri, Oct 06, 2017 at 09:11:22AM +, Antony Antony wrote:
> > > Hi
> > > 
> > > Thanks Chen-Yu and Maxime.
> > > 
> > > On Tue, Oct 03, 2017 at 10:11:00AM +0800, Chen-Yu Tsai wrote:
> > > > On Mon, Oct 2, 2017 at 1:34 AM, Antony Antony  
> > > > wrote:
> > > > > Hi Maxime,
> > > > >
> > > > > sorry for the delayed response.
> > > > >
> > > > > On Mon, Sep 25, 2017 at 01:12:23PM +0200, Maxime Ripard wrote:
> > > > >> On Sat, Sep 23, 2017 at 05:59:15PM +, Antony Antony wrote:
> > > > >> > Add initial DT for NanoPi NEO Plus2 by FriendlyARM
> > > > >> > - Allwinner quad core H5 Cortex A53 with an ARM Mali-450MP GPU
> > > > >> > - 1 GB DDR3 RAM
> > > > >> > - 8GB eMMC flash (Samsung KLM8G1WEPD-B031)
> > > > >> > - micro SD card slot
> > > > >> > - Gigabit Ethernet (external RTL8211E-VB-CG chip)
> > > > >> > - 802.11 b/g/n WiFi, Bluetooth 4.0 (Ampak AP6212A module)
> > > > >> > - 2x USB 2.0 host ports
> > > > >> >
> > > > >> > Signed-off-by: Antony Antony 
> > > > >> > ---
> > > > >> > Changes v1->v2
> > > > >> >  removed memory {}, compatible ="allwinner,sun5i-a13-mmc"
> > > > >> >  remove CONFIG_SPL_SPI_FLASH_SUPPORT=y and CONFIG_SPL_SPI_SUNXI=y 
> > > > >> > (no SPI)
> > > > >> >  remove CONFIG_SD_BOOT=y
> > > > >> > Changes v2->v3
> > > > >> >  removed compatible ="allwinner,sun50i-a64-mmc"
> > > > >> > ---
> > > > >> >  arch/arm/dts/Makefile   |   1 +
> > > > >> >  arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts | 107 
> > > > >> > 
> > > > >> >  configs/nanopi_neo_plus2_defconfig  |  18 +
> > > > >> >  3 files changed, 126 insertions(+)
> > > > >> >  create mode 100644 arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > > > >> >  create mode 100644 configs/nanopi_neo_plus2_defconfig
> > > > >> >
> > > > >> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > > >> > index fee4680..295a675 100644
> > > > >> > --- a/arch/arm/dts/Makefile
> > > > >> > +++ b/arch/arm/dts/Makefile
> > > > >> > @@ -333,6 +333,7 @@ dtb-$(CONFIG_MACH_SUN8I_V3S) += \
> > > > >> > sun8i-v3s-licheepi-zero.dtb
> > > > >> >  dtb-$(CONFIG_MACH_SUN50I_H5) += \
> > > > >> > sun50i-h5-nanopi-neo2.dtb \
> > > > >> > +   sun50i-h5-nanopi-neo-plus2.dtb \
> > > > >> > sun50i-h5-orangepi-pc2.dtb \
> > > > >> > sun50i-h5-orangepi-prime.dtb \
> > > > >> > sun50i-h5-orangepi-zero-plus2.dtb
> > > > >> > diff --git a/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts 
> > > > >> > b/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > > > >> > new file mode 100644
> > > > >> > index 000..8ac098e
> > > > >> > --- /dev/null
> > > > >> > +++ b/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > > > >> > @@ -0,0 +1,107 @@
> > > > >> > +/*
> > > > >> > + * Copyright (C) 2017 Antony Antony 
> > > > >> > + * Copyright (c) 2016 ARM Ltd.
> > > > >> > + *
> > > > >> > + * This file is dual-licensed: you can use it either under the 
> > > > >> > terms
> > > > >> > + * of the GPL or the X11 license, at your option. Note that this 
> > > > >> > dual
> > > > >> > + * licensing only applies to this file, and not this project as a
> > > > >> > + * whole.
> > > > >> > + *
> > > > >> > + *  a) This library is free software; you can redistribute it 
> > > > >> > and/or
> > > > >> > + * modify it under the terms of the GNU General Public 
> > > > >> > License as
> > > > >> > + * published by the Free Software Foundation; either version 
> > > > >> > 2 of the
> > > > >> > + * License, or (at your option) any later version.
> > > > >> > + *
> > > > >> > + * This library is distributed in the hope that it will be 
> > > > >> > useful,
> > > > >> > + * but WITHOUT ANY WARRANTY; without even the implied 
> > > > >> > warranty of
> > > > >> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See 
> > > > >> > the
> > > > >> > + * GNU General Public License for more details.
> > > > >> > + *
> > > > >> > + * Or, alternatively,
> > > > >> > + *
> > > > >> > + *  b) Permission is hereby granted, free of charge, to any person
> > > > >> > + * obtaining a copy of this software and associated 
> > > > >> > documentation
> > > > >> > + * files (the "Software"), to deal in the Software without
> > > > >> > + * restriction, including without limitation the rights to 
> > > > >> > use,
> > > > >> > + * copy, modify, merge, publish, distribute, sublicense, 
> > > > >> > and/or
> > > > >> > + * sell copies of the Software, and to permit persons to whom 
> > > > >> > the
> > > > >> > + * Software is furnished to do so, subject to the following
> > > > >> > + * conditions:
> > > > >> > + *
> > > > >> > + * The above copyright notice and this permission notice 
> > > > >> > shall be
> > > > >> > + * included in all copies or substantial portions of 

Re: [U-Boot] [PATCH] fs/fat: fix unaligned access regression

[Fabio Estevam]

On Mon, Oct 9, 2017 at 9:39 AM, Jonathan Gray  wrote:
> Since
> 2460098cffacd18729262e3ed36656e6943783ed (fs/fat: Reduce stack usage)
> Trying to load a file off a FAT fs on i.MX 6 based CuBox-i4Pro fails:
>
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
> CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
> CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
> CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468
> ...
>
> Switching the malloc() calls to malloc_cache_aligned() avoids
> the alignment errors and allows booting to continue.
>
> Signed-off-by: Jonathan Gray 

Tom has just applied the same fix:
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=09fa964bba80c45432660f0e64362181900a5aef;hp=99e46dfc6a9176f6f0680c9dfdf33c97d56336ce
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] fs/fat: fix unaligned access regression

[Tom Rini]

On Mon, Oct 09, 2017 at 06:49:02PM -0300, Fabio Estevam wrote:
> On Mon, Oct 9, 2017 at 9:39 AM, Jonathan Gray  wrote:
> > Since
> > 2460098cffacd18729262e3ed36656e6943783ed (fs/fat: Reduce stack usage)
> > Trying to load a file off a FAT fs on i.MX 6 based CuBox-i4Pro fails:
> >
> > switch to partitions #0, OK
> > mmc0 is current device
> > Scanning mmc 0:1...
> > CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> > CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> > ERROR: v7_outer_cache_inval_range - start address is not aligned - 
> > 0x8f89da30
> > ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
> > CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> > CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> > ERROR: v7_outer_cache_inval_range - start address is not aligned - 
> > 0x8f89da30
> > ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
> > CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> > CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> > CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> > CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> > CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
> > CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
> > ERROR: v7_outer_cache_inval_range - start address is not aligned - 
> > 0x8f89dc68
> > ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468
> > ...
> >
> > Switching the malloc() calls to malloc_cache_aligned() avoids
> > the alignment errors and allows booting to continue.
> >
> > Signed-off-by: Jonathan Gray 
> 
> Tom has just applied the same fix:
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=09fa964bba80c45432660f0e64362181900a5aef;hp=99e46dfc6a9176f6f0680c9dfdf33c97d56336ce

Oh heck, now I'm embarrassed for not recalling we had the same issue
with a fix in the queue, sorry!

-- 
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] Broadwell-DE bare metal

[Simon Glass]

Hi,

On 9 October 2017 at 10:32, Zoran Stojsavljevic
 wrote:
>
>  > It allows U-Boot to boot from EFI.
>
> This is a true art of overkill... Really.
>
> Full EFI (around 1 to 2 million lines of code: SEC, PEI, DXE phases, with ME 
> HECI involved, altogether) -> U-Boot -> YOCTO. Wow. ;-)


Yes but at the time there was no FSP. I suspect now it would not be needed.

(BTW as this is a mailing list, please avoid top-posting)

Regards,
Simon

>
>
> Zoran
>
> On Mon, Oct 9, 2017 at 4:43 PM, Simon Glass  wrote:
>>
>> Hi,
>>
>> On 3 October 2017 at 08:58, vnktux  wrote:
>> > Hi all,
>> >
>> > For my graduation project my company asked to use U-Boot as bare metal 
>> > boot-loader on one of their product. The product in an embedded board with 
>> > a Xeon Broadwell-DE D-1527 Quad Core. The current boot-loader consist of 
>> > Coreboot + U-Boot, but of course they want to get rid of Coreboot. I have 
>> > almost no experience with U-Boot (Just with ARM processor a little bit) 
>> > and so far I don't even know if it's possible or not to achieve the final 
>> > goal. What I have understood is that I need the following binary blobs to 
>> > work: fsp.bin, vga.bin, descriptor.bin, me.bin, microcode.bin. Is it true? 
>> > Can somebody point me in the right direction because I am a little bit 
>> > lost?  Plus I don't see many x86 boards implemented in the source code of 
>> > U-Boot.
>>
>> The original U-Boot payload support was done with Broadwell-DE (I'm
>> not sure which one though). It allows U-Boot to boot from EFI.
>>
>> For what you want, yes you will need to obtain various binary blobs.
>> Hopefully you can get the FSP from Intel, and with that the work
>> required in U-Boot is probably not too large. Although I'm sure that
>> the FSP API will have changed a little.
>>
>> Regards,
>> Simon
>>
>> >
>> > Best regards,
>> > Vincenzo
>> >
>> > Sent with [ProtonMail](https://protonmail.com) Secure Email.
>> > ___
>> > U-Boot mailing list
>> > U-Boot@lists.denx.de
>> > https://lists.denx.de/listinfo/u-boot
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Please pull u-boot-dm (take 2)

[Simon Glass]

Hi Tom,

Sorry for the delay with v2.


The following changes since commit 0d3aaa35b87573c229d65bc79050ab13f39d8ec2:

  Travis-CI: Fix microblaze and xilinx jobs (2017-10-07 15:54:18 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-dm.git

for you to fetch changes up to 04d0da51578e12bd7c490aa70ed581ee5f9dcfea:

  sandbox: avoid memory leak in os_dirent_ls (2017-10-08 20:41:09 -0600)


Faiz Abbas (1):
  dm: core: Round up size when allocating so that it is cache line
aligned

Heinrich Schuchardt (1):
  sandbox: avoid memory leak in os_dirent_ls

Klaus Goger (1):
  dm: ofnode: query correct property in livetree ofnode_get_addr_size

Rob Clark (1):
  test: print_ut: Add test for %ls strings

Simon Glass (4):
  dm: gpio: vybrid_gpio: Correct driver's use of bind() method
  dm: gpio: Add a comment about not copying some drivers
  dm: gpio: Correct use of -ENODEV in drivers
  dm: gpio: pca953x: Drop pointless data structure checks

 arch/sandbox/cpu/os.c   | 20 ++--
 drivers/core/device.c   |  1 +
 drivers/core/ofnode.c   |  4 +++-
 drivers/gpio/adi_gpio2.c|  2 +-
 drivers/gpio/atmel_pio4.c   | 12 ++--
 drivers/gpio/imx_rgpio2p.c  |  7 ++-
 drivers/gpio/mxc_gpio.c |  7 ++-
 drivers/gpio/omap_gpio.c|  8 ++--
 drivers/gpio/pca953x_gpio.c | 11 ---
 drivers/gpio/tegra186_gpio.c|  2 +-
 drivers/gpio/vybrid_gpio.c  | 25 ++---
 drivers/i2c/imx_lpi2c.c |  2 +-
 drivers/i2c/mxc_i2c.c   | 12 ++--
 drivers/i2c/tegra186_bpmp_i2c.c |  2 +-
 test/print_ut.c |  3 +++
 15 files changed, 61 insertions(+), 57 deletions(-)


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

Re: [U-Boot] Please pull u-boot-video/master

[Tom Rini]

On Mon, Oct 09, 2017 at 10:17:29AM +0200, Anatolij Gustschin wrote:

> Hi Tom,
> 
> The following changes since commit ec4e99a4a24c84069c710df3202ecb1e501ff60f:
> 
>   Merge git://git.denx.de/u-boot-mmc (2017-09-28 23:31:11 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-video.git master
> 
> for you to fetch changes up to 40186ee213794d1a6e47e787aa424b3587711289:
> 
>   video: test: Add ANSI escape sequence tests (2017-09-29 17:59:58 +0200)
> 

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] efi_loader: Decouple EFI input/output from stdin/stdout

[Rob Clark]

On Mon, Sep 11, 2017 at 10:04 AM, Rob Clark  wrote:
> In some cases, it is quite useful to have (for example) EFI on screen
> but u-boot on serial port.
>
> Signed-off-by: Rob Clark 
> ---
> Applies on top of my previous efi_loader patchset.
>
>  lib/efi_loader/efi_console.c | 104 
> +--
>  1 file changed, 80 insertions(+), 24 deletions(-)
>
> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index 139f7ea55b..e2b1b88ecf 100644
> --- a/lib/efi_loader/efi_console.c
> +++ b/lib/efi_loader/efi_console.c
> @@ -47,6 +47,38 @@ static struct cout_mode efi_cout_modes[] = {
>
>  const efi_guid_t efi_guid_console_control = CONSOLE_CONTROL_GUID;
>
> +static struct stdio_dev *efiin, *efiout;
> +
> +static int efi_tstc(void)
> +{
> +   return efiin->tstc(efiin);
> +}
> +
> +static int efi_getc(void)
> +{
> +   return efiin->getc(efiin);
> +}
> +
> +static int efi_printf(const char *fmt, ...)
> +{
> +   va_list args;
> +   uint i;
> +   char printbuffer[CONFIG_SYS_PBSIZE];
> +
> +   va_start(args, fmt);
> +
> +   /*
> +* For this to work, printbuffer must be larger than
> +* anything we ever want to print.
> +*/
> +   i = vsnprintf(printbuffer, sizeof(printbuffer), fmt, args);
> +   va_end(args);
> +
> +   /* Print the string */
> +   efiout->puts(efiout, printbuffer);
> +   return i;
> +}
> +
>  #define cESC '\x1b'
>  #define ESC "\x1b"
>
> @@ -111,16 +143,16 @@ static int term_read_reply(int *n, int maxnum, char 
> end_char)
> char c;
> int i = 0;
>
> -   c = getc();
> +   c = efi_getc();
> if (c != cESC)
> return -1;
> -   c = getc();
> +   c = efi_getc();
> if (c != '[')
> return -1;
>
> n[0] = 0;
> while (1) {
> -   c = getc();
> +   c = efi_getc();
> if (c == ';') {
> i++;
> if (i >= maxnum)
> @@ -164,7 +196,7 @@ static efi_status_t EFIAPI efi_cout_output_string(
>
> *utf16_to_utf8((u8 *)buf, string, n16) = '\0';
>
> -   fputs(stdout, buf);
> +   efiout->puts(efiout, buf);
>
> for (p = buf; *p; p++) {
> switch (*p) {
> @@ -217,14 +249,14 @@ static int query_console_serial(int *rows, int *cols)
> u64 timeout;
>
> /* Empty input buffer */
> -   while (tstc())
> -   getc();
> +   while (efi_tstc())
> +   efi_getc();
>
> -   printf(ESC"[18t");
> +   efi_printf(ESC"[18t");
>
> /* Check if we have a terminal that understands */
> timeout = timer_get_us() + 100;
> -   while (!tstc())
> +   while (!efi_tstc())
> if (timer_get_us() > timeout)
> return -1;
>
> @@ -348,9 +380,9 @@ static efi_status_t EFIAPI efi_cout_set_attribute(
> EFI_ENTRY("%p, %lx", this, attribute);
>
> if (attribute)
> -   printf(ESC"[%u;%um", color[fg].fg, color[bg].bg);
> +   efi_printf(ESC"[%u;%um", color[fg].fg, color[bg].bg);
> else
> -   printf(ESC"[37;40m");
> +   efi_printf(ESC"[37;40m");
>
> /* Just ignore attributes (colors) for now */
> return EFI_EXIT(EFI_UNSUPPORTED);
> @@ -361,7 +393,7 @@ static efi_status_t EFIAPI efi_cout_clear_screen(
>  {
> EFI_ENTRY("%p", this);
>
> -   printf(ESC"[2J");
> +   efi_printf(ESC"[2J");
>
> return EFI_EXIT(EFI_SUCCESS);
>  }
> @@ -372,7 +404,7 @@ static efi_status_t EFIAPI efi_cout_set_cursor_position(
>  {
> EFI_ENTRY("%p, %ld, %ld", this, column, row);
>
> -   printf(ESC"[%d;%df", (int)row, (int)column);
> +   efi_printf(ESC"[%d;%df", (int)row, (int)column);
> efi_con_mode.cursor_column = column;
> efi_con_mode.cursor_row = row;
>
> @@ -385,7 +417,7 @@ static efi_status_t EFIAPI efi_cout_enable_cursor(
>  {
> EFI_ENTRY("%p, %d", this, enable);
>
> -   printf(ESC"[?25%c", enable ? 'h' : 'l');
> +   efi_printf(ESC"[?25%c", enable ? 'h' : 'l');
>
> return EFI_EXIT(EFI_SUCCESS);
>  }
> @@ -427,27 +459,27 @@ static efi_status_t read_key_stroke(struct efi_key_data 
> *key_data)
> /* We don't do interrupts, so check for timers cooperatively */
> efi_timer_check();
>
> -   if (!tstc()) {
> +   if (!efi_tstc()) {
> /* No key pressed */
> return EFI_NOT_READY;
> }
>
> -   ch = getc();
> +   ch = efi_getc();
> if (ch == cESC) {
> /* Escape Sequence */
> -   ch = getc();
> +   ch = efi_getc();
> switch (ch) {
> case cESC: /* ESC */
> pressed_key.scan_code = 23;
> break;
> case 'O': /* F1 - F4 */
> -   

Re: [U-Boot] [PATCH] armv8: configs: ls1012a: correct the generic timer frequency issue

[Andy Tang]

Hi York,

Ls1012a uses the fixed 25Mhz clock, I will update the commit message and resend 
the patch. 

Thanks,
Andy

> -Original Message-
> From: York Sun
> Sent: Tuesday, October 10, 2017 12:00 AM
> To: Andy Tang 
> Cc: s...@chromium.org; u-boot@lists.denx.de
> Subject: Re: [PATCH] armv8: configs: ls1012a: correct the generic timer
> frequency issue
> 
> On 10/08/2017 11:48 PM, andy.t...@nxp.com wrote:
> > From: Yuantian Tang 
> >
> > Generic Timer frequency should be 25Mhz. Current setting is
> > CONFIG_SYS_CLK_FREQ/4 which is about 31Mhz, which is not correct.
> > So correct it.
> >
> > Signed-off-by: Tang Yuantian 
> > ---
> >  include/configs/ls1012a_common.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/configs/ls1012a_common.h
> > b/include/configs/ls1012a_common.h
> > index 096799eb64..a4e78f335f 100644
> > --- a/include/configs/ls1012a_common.h
> > +++ b/include/configs/ls1012a_common.h
> > @@ -32,7 +32,7 @@
> >  #define CONFIG_SYS_DDR_BLOCK2_BASE 0x88000ULL
> >
> >  /* Generic Timer Definitions */
> > -#define COUNTER_FREQUENCY  CONFIG_SYS_CLK_FREQ/4
>   /* 25MHz */
> > +#define COUNTER_FREQUENCY  2500/* 25MHz */
> >
> 
> 
> Yuantian,
> 
> LS1012A use fixed 25MHz clock, doesn't it? If so, that's the reason a fixed
> value should be used, not because CONFIG_SYS_CLK_FREQ/4 isn't correct. It
> is correct for many other platform. Please update the commit message.
> 
> York
> 

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

Re: [U-Boot] [PATCH] Powerpc: Make pcie link state judge more specific

[York Sun]

On 09/24/2017 08:44 PM, Bao Xiaowei wrote:
> For some special reset times for longer pcie devices, in this case, the
> pcie device may on polling compliance state, the RC considers the pcie
> device is link up, but the pcie device is not link up, only the L0 state
> is link up state. So add the link up status judgement mechanisms.
> 
> Signed-off-by: Bao Xiaowei 
> ---
> v2:
>  - Detailed function module
>  - Adjust the code structure
> 

Xiaowei,

Can you revise the commit message? I don't quite understand it. It is
similar but not the same as the change you made for Layerscape, isn't it?

While you respin this patch, please consider my comments earlier.

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

[U-Boot] [PATCH] armv8: configs: ls1012a: correct the generic timer frequency issue

[andy.tang]

From: Yuantian Tang 

Generic Timer frequency should be 25Mhz. Current setting is
CONFIG_SYS_CLK_FREQ/4 which is about 31Mhz, which is not correct.
So correct it.

Signed-off-by: Tang Yuantian 
---
 include/configs/ls1012a_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h
index 096799eb64..a4e78f335f 100644
--- a/include/configs/ls1012a_common.h
+++ b/include/configs/ls1012a_common.h
@@ -32,7 +32,7 @@
 #define CONFIG_SYS_DDR_BLOCK2_BASE 0x88000ULL
 
 /* Generic Timer Definitions */
-#define COUNTER_FREQUENCY  CONFIG_SYS_CLK_FREQ/4   /* 25MHz */
+#define COUNTER_FREQUENCY  2500/* 25MHz */
 
 /* CSU */
 #define CONFIG_LAYERSCAPE_NS_ACCESS
-- 
2.14.1

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

Re: [U-Boot] [PATCH 08/11] efi_selftest: allow to select a single test for exexution

[Alexander Graf]

On 09.10.17 08:14, Heinrich Schuchardt wrote:
> On 10/09/2017 06:46 AM, Alexander Graf wrote:
>>
>>
>> On 08.10.17 06:57, Heinrich Schuchardt wrote:
>>> The second argument of bootefi is passed as a configuration
>>> table to the selftest application. It is used to select
>>> a single test to be executed.
>>>
>>> Tests get an on_request property. If this property is set
>>> the tests are only executed if explicitly requested.
>>>
>>> A new command 'bootefi selftest list' is added that allows to list
>>> all tests.
>>>
>>> The invocation of efi_selftest is changed to reflect that
>>> bootefi selftest list will call the Exit bootservice.
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>
>> Wouldn't it make more sense to just pass "bootargs" to the EFI payload
>> as command line arguments?
>>
>> We could then just
>>
>>   U-Boot# setenv bootargs list
>>   U-Boot# bootefi selftest
>>
>> to list the available self tests. Same for selecting them.
> 
> Why bootargs?
> 

Because bootargs is the variable that "bootm" pushes into a payload as
command line arguments.

>>
>> That way we would also be able to directly load Linux as EFI binary and
>> pass command line arguments to it without jumping through fdt patching
>> hoops.
> 
> Does the Linux EFI stub or grub.efi have a capability to receive the
> command line?

Linux does:


https://github.com/torvalds/linux/blob/master/drivers/firmware/efi/libstub/efi-stub-helper.c#L773

I don't think grub implements it today, but I don't see why it should.
Any UEFI application that expects to be executed from the UEFI Shell
certainly interprets the passed in command line.


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

Re: [U-Boot] [PATCH 06/11] efi_loader: implement SetWatchdogTimer

[Alexander Graf]

On 09.10.17 08:05, Heinrich Schuchardt wrote:
> On 10/09/2017 06:42 AM, Alexander Graf wrote:
>>
>>
>> On 08.10.17 06:57, Heinrich Schuchardt wrote:
>>> The watchdog is initialized with a 5 minute timeout period.
>>> It can be reset by SetWatchdogTimer.
>>> It is stopped by ExitBoottimeServices.
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>>  cmd/bootefi.c |  1 +
>>>  include/efi_loader.h  |  4 +++
>>>  lib/efi_loader/Makefile   |  2 +-
>>>  lib/efi_loader/efi_boottime.c | 15 ++-
>>>  lib/efi_loader/efi_watchdog.c | 59 
>>> +++
>>>  5 files changed, 67 insertions(+), 14 deletions(-)
>>>  create mode 100644 lib/efi_loader/efi_watchdog.c
>>>
>>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>>> index b7087e3da8..24958ada46 100644
>>> --- a/cmd/bootefi.c
>>> +++ b/cmd/bootefi.c
>>> @@ -43,6 +43,7 @@ static void efi_init_obj_list(void)
>>>  #ifdef CONFIG_GENERATE_SMBIOS_TABLE
>>> efi_smbios_register();
>>>  #endif
>>> +   efi_watchdog_register();
>>>  
>>> /* Initialize EFI runtime services */
>>> efi_reset_system_init();
>>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>>> index e1179b7dcd..223d8d8222 100644
>>> --- a/include/efi_loader.h
>>> +++ b/include/efi_loader.h
>>> @@ -163,6 +163,8 @@ int efi_disk_register(void);
>>>  int efi_gop_register(void);
>>>  /* Called by bootefi to make the network interface available */
>>>  int efi_net_register(void);
>>> +/* Called by bootefi to make the watchdog available */
>>> +int efi_watchdog_register(void);
>>>  /* Called by bootefi to make SMBIOS tables available */
>>>  void efi_smbios_register(void);
>>>  
>>> @@ -171,6 +173,8 @@ efi_fs_from_path(struct efi_device_path *fp);
>>>  
>>>  /* Called by networking code to memorize the dhcp ack package */
>>>  void efi_net_set_dhcp_ack(void *pkt, int len);
>>> +/* Called by efi_set_watchdog_timer to reset the timer */
>>> +efi_status_t efi_set_watchdog(unsigned long timeout);
>>>  
>>>  /* Called from places to check whether a timer expired */
>>>  void efi_timer_check(void);
>>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>>> index ddb978f650..83d879b686 100644
>>> --- a/lib/efi_loader/Makefile
>>> +++ b/lib/efi_loader/Makefile
>>> @@ -17,7 +17,7 @@ endif
>>>  obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
>>>  obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
>>>  obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
>>> -obj-y += efi_file.o efi_variable.o efi_bootmgr.o
>>> +obj-y += efi_file.o efi_variable.o efi_bootmgr.o efi_watchdog.o
>>>  obj-$(CONFIG_LCD) += efi_gop.o
>>>  obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>>>  obj-$(CONFIG_PARTITIONS) += efi_disk.o
>>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>>> index 30577f717e..81e7d818fc 100644
>>> --- a/lib/efi_loader/efi_boottime.c
>>> +++ b/lib/efi_loader/efi_boottime.c
>>> @@ -155,18 +155,6 @@ void efi_signal_event(struct efi_event *event)
>>> event->is_queued = false;
>>>  }
>>>  
>>> -/*
>>> - * Write a debug message for an EPI API service that is not implemented 
>>> yet.
>>> - *
>>> - * @funcname   function that is not yet implemented
>>> - * @return EFI_UNSUPPORTED
>>> - */
>>> -static efi_status_t efi_unsupported(const char *funcname)
>>> -{
>>> -   debug("EFI: App called into unimplemented function %s\n", funcname);
>>> -   return EFI_EXIT(EFI_UNSUPPORTED);
>>> -}
>>> -
>>>  /*
>>>   * Raise the task priority level.
>>>   *
>>> @@ -1454,6 +1442,7 @@ static efi_status_t EFIAPI 
>>> efi_exit_boot_services(void *image_handle,
>>> bootm_disable_interrupts();
>>>  
>>> /* Give the payload some time to boot */
>>> +   efi_set_watchdog(0);
>>> WATCHDOG_RESET();
>>>  
>>> return EFI_EXIT(EFI_SUCCESS);
>>> @@ -1514,7 +1503,7 @@ static efi_status_t EFIAPI 
>>> efi_set_watchdog_timer(unsigned long timeout,
>>>  {
>>> EFI_ENTRY("%ld, 0x%"PRIx64", %ld, %p", timeout, watchdog_code,
>>>   data_size, watchdog_data);
>>> -   return efi_unsupported(__func__);
>>> +   return EFI_EXIT(efi_set_watchdog(timeout));
>>>  }
>>>  
>>>  /*
>>> diff --git a/lib/efi_loader/efi_watchdog.c b/lib/efi_loader/efi_watchdog.c
>>> new file mode 100644
>>> index 00..50e95290ea
>>> --- /dev/null
>>> +++ b/lib/efi_loader/efi_watchdog.c
>>> @@ -0,0 +1,59 @@
>>> +/*
>>> + *  EFI device path interface
>>
>> Not quite I guess?
>>
>>> + *
>>> + *  Copyright (c) 2017 Heinrich Schuchardt
>>> + *
>>> + *  SPDX-License-Identifier: GPL-2.0+
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +static struct efi_event *watchdog_timer_event;
>>> +
>>> +static void EFIAPI efi_watchdog_timer_notify(struct efi_event *event,
>>> +void *context)
>>> +{
>>> +   EFI_ENTRY("%p, %p", event, context);
>>> +
>>> +   printf("\nEFI: Watchdog timeout\n");
>>> +   

Re: [U-Boot] [PATCH] usb: xhci: Add Renesas R-Car xHCI driver

[Bin Meng]

Hi Marek,

On Mon, Oct 9, 2017 at 2:34 AM, Marek Vasut  wrote:
> Add firmware V3, firmware loader and XHCI glue for the Renesas R-Car
> Gen3 SoCs XHCI controller. Thus far only the R-Car Gen3 R8A7795 ES2.0+
> and R8A7796 are supported.
>
> Signed-off-by: Marek Vasut 
> Cc: Nobuhiro Iwamatsu 
> ---
>  Licenses/r8a779x_usb3.txt|  26 ++
>  drivers/usb/host/Kconfig |   8 +
>  drivers/usb/host/Makefile|   1 +
>  drivers/usb/host/xhci-rcar-r8a779x_usb3_v3.h | 643 
> +++
>  drivers/usb/host/xhci-rcar.c | 161 +++
>  5 files changed, 839 insertions(+)
>  create mode 100644 Licenses/r8a779x_usb3.txt
>  create mode 100644 drivers/usb/host/xhci-rcar-r8a779x_usb3_v3.h
>  create mode 100644 drivers/usb/host/xhci-rcar.c
>
> diff --git a/Licenses/r8a779x_usb3.txt b/Licenses/r8a779x_usb3.txt
> new file mode 100644
> index 00..e2afcc9e81
> --- /dev/null
> +++ b/Licenses/r8a779x_usb3.txt
> @@ -0,0 +1,26 @@
> +Copyright (c) 2014, Renesas Electronics Corporation
> +All rights reserved.
> +
> +Redistribution and use in binary form, without modification, are permitted
> +provided that the following conditions are met:
> +
> +1. Redistribution in binary form must reproduce the above copyright notice,
> +   this list of conditions and the following disclaimer in the documentation
> +   and/or other materials provided with the distribution.
> +2. The name of Renesas Electronics Corporation may not be used to endorse or
> +   promote products derived from this software without specific prior written
> +   permission.
> +3. Reverse engineering, decompilation, or disassembly of this software is
> +   not permitted.
> +
> +THIS SOFTWARE IS PROVIDED "AS IS" AND RENESAS ELECTRONICS CORPORATION 
> DISCLAIMS
> +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND
> +NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL RENESAS ELECTRONICS
> +CORPORATION BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 
> EXEMPLARY,
> +OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> +ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> +POSSIBILITY OF SUCH DAMAGE.

Is there any SPDX form of this license?

> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index f5f19ed775..cad9af6977 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -47,6 +47,14 @@ config USB_XHCI_ROCKCHIP
> help
>   Enables support for the on-chip xHCI controller on Rockchip SoCs.
>
> +config USB_XHCI_RCAR
> +   bool "Renesas RCar USB 3.0 support"
> +   default y
> +   depends on ARCH_RMOBILE
> +   help
> + Choose this option to add support for USB 3.0 driver on Renesas
> + RCar Gen3 SoCs.
> +
>  config USB_XHCI_STI
> bool "Support for STMicroelectronics STiH407 family on-chip xHCI USB 
> controller"
> depends on ARCH_STI
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index 83903fcf99..79df888fce 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -59,6 +59,7 @@ obj-$(CONFIG_USB_XHCI_FSL) += xhci-fsl.o
>  obj-$(CONFIG_USB_XHCI_MVEBU) += xhci-mvebu.o
>  obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o
>  obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
> +obj-$(CONFIG_USB_XHCI_RCAR) += xhci-rcar.o
>  obj-$(CONFIG_USB_XHCI_STI) += dwc3-sti-glue.o
>
>  # designware
> diff --git a/drivers/usb/host/xhci-rcar-r8a779x_usb3_v3.h 
> b/drivers/usb/host/xhci-rcar-r8a779x_usb3_v3.h
> new file mode 100644
> index 00..f0f48a3354
> --- /dev/null
> +++ b/drivers/usb/host/xhci-rcar-r8a779x_usb3_v3.h
> @@ -0,0 +1,643 @@
> +/*
> + * Renesas RCar xHCI controller firmware version 3
> + *
> + * Copyright (c) 2014, Renesas Electronics Corporation
> + * All rights reserved.
> + *
> + * Redistribution and use in binary form, without modification, are permitted
> + * provided that the following conditions are met:
> + *
> + * 1. Redistribution in binary form must reproduce the above copyright 
> notice,
> + *this list of conditions and the following disclaimer in the 
> documentation
> + *and/or other materials provided with the distribution.
> + * 2. The name of Renesas Electronics Corporation may not be used to endorse 
> or
> + *promote products derived from this software without specific prior 
> written
> + *permission.
> + * 3. Reverse engineering, decompilation, or disassembly of this software is
> + *not permitted.
> + *
> + * THIS SOFTWARE IS PROVIDED "AS IS" AND 

Re: [U-Boot] [PATCH v3] sun50i: h5: Add NanoPi Neo Plus2 DT initial support

[Maxime Ripard]

On Fri, Oct 06, 2017 at 09:11:22AM +, Antony Antony wrote:
> Hi
> 
> Thanks Chen-Yu and Maxime.
> 
> On Tue, Oct 03, 2017 at 10:11:00AM +0800, Chen-Yu Tsai wrote:
> > On Mon, Oct 2, 2017 at 1:34 AM, Antony Antony  wrote:
> > > Hi Maxime,
> > >
> > > sorry for the delayed response.
> > >
> > > On Mon, Sep 25, 2017 at 01:12:23PM +0200, Maxime Ripard wrote:
> > >> On Sat, Sep 23, 2017 at 05:59:15PM +, Antony Antony wrote:
> > >> > Add initial DT for NanoPi NEO Plus2 by FriendlyARM
> > >> > - Allwinner quad core H5 Cortex A53 with an ARM Mali-450MP GPU
> > >> > - 1 GB DDR3 RAM
> > >> > - 8GB eMMC flash (Samsung KLM8G1WEPD-B031)
> > >> > - micro SD card slot
> > >> > - Gigabit Ethernet (external RTL8211E-VB-CG chip)
> > >> > - 802.11 b/g/n WiFi, Bluetooth 4.0 (Ampak AP6212A module)
> > >> > - 2x USB 2.0 host ports
> > >> >
> > >> > Signed-off-by: Antony Antony 
> > >> > ---
> > >> > Changes v1->v2
> > >> >  removed memory {}, compatible ="allwinner,sun5i-a13-mmc"
> > >> >  remove CONFIG_SPL_SPI_FLASH_SUPPORT=y and CONFIG_SPL_SPI_SUNXI=y (no 
> > >> > SPI)
> > >> >  remove CONFIG_SD_BOOT=y
> > >> > Changes v2->v3
> > >> >  removed compatible ="allwinner,sun50i-a64-mmc"
> > >> > ---
> > >> >  arch/arm/dts/Makefile   |   1 +
> > >> >  arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts | 107 
> > >> > 
> > >> >  configs/nanopi_neo_plus2_defconfig  |  18 +
> > >> >  3 files changed, 126 insertions(+)
> > >> >  create mode 100644 arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > >> >  create mode 100644 configs/nanopi_neo_plus2_defconfig
> > >> >
> > >> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > >> > index fee4680..295a675 100644
> > >> > --- a/arch/arm/dts/Makefile
> > >> > +++ b/arch/arm/dts/Makefile
> > >> > @@ -333,6 +333,7 @@ dtb-$(CONFIG_MACH_SUN8I_V3S) += \
> > >> > sun8i-v3s-licheepi-zero.dtb
> > >> >  dtb-$(CONFIG_MACH_SUN50I_H5) += \
> > >> > sun50i-h5-nanopi-neo2.dtb \
> > >> > +   sun50i-h5-nanopi-neo-plus2.dtb \
> > >> > sun50i-h5-orangepi-pc2.dtb \
> > >> > sun50i-h5-orangepi-prime.dtb \
> > >> > sun50i-h5-orangepi-zero-plus2.dtb
> > >> > diff --git a/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts 
> > >> > b/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > >> > new file mode 100644
> > >> > index 000..8ac098e
> > >> > --- /dev/null
> > >> > +++ b/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > >> > @@ -0,0 +1,107 @@
> > >> > +/*
> > >> > + * Copyright (C) 2017 Antony Antony 
> > >> > + * Copyright (c) 2016 ARM Ltd.
> > >> > + *
> > >> > + * This file is dual-licensed: you can use it either under the terms
> > >> > + * of the GPL or the X11 license, at your option. Note that this dual
> > >> > + * licensing only applies to this file, and not this project as a
> > >> > + * whole.
> > >> > + *
> > >> > + *  a) This library is free software; you can redistribute it and/or
> > >> > + * modify it under the terms of the GNU General Public License as
> > >> > + * published by the Free Software Foundation; either version 2 of 
> > >> > the
> > >> > + * License, or (at your option) any later version.
> > >> > + *
> > >> > + * This library is distributed in the hope that it will be useful,
> > >> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > >> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > >> > + * GNU General Public License for more details.
> > >> > + *
> > >> > + * Or, alternatively,
> > >> > + *
> > >> > + *  b) Permission is hereby granted, free of charge, to any person
> > >> > + * obtaining a copy of this software and associated documentation
> > >> > + * files (the "Software"), to deal in the Software without
> > >> > + * restriction, including without limitation the rights to use,
> > >> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > >> > + * sell copies of the Software, and to permit persons to whom the
> > >> > + * Software is furnished to do so, subject to the following
> > >> > + * conditions:
> > >> > + *
> > >> > + * The above copyright notice and this permission notice shall be
> > >> > + * included in all copies or substantial portions of the Software.
> > >> > + *
> > >> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > >> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> > >> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > >> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > >> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > >> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > >> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > >> > + * OTHER DEALINGS IN THE SOFTWARE.
> > >> > + */
> > >> > +
> > >> > +/dts-v1/;
> > 

Re: [U-Boot] [PATCH v3] sun50i: h5: Add NanoPi Neo Plus2 DT initial support

[Antony Antony]

On Mon, Oct 09, 2017 at 09:22:03AM +0200, Maxime Ripard wrote:
> On Fri, Oct 06, 2017 at 09:11:22AM +, Antony Antony wrote:
> > Hi
> > 
> > Thanks Chen-Yu and Maxime.
> > 
> > On Tue, Oct 03, 2017 at 10:11:00AM +0800, Chen-Yu Tsai wrote:
> > > On Mon, Oct 2, 2017 at 1:34 AM, Antony Antony  wrote:
> > > > Hi Maxime,
> > > >
> > > > sorry for the delayed response.
> > > >
> > > > On Mon, Sep 25, 2017 at 01:12:23PM +0200, Maxime Ripard wrote:
> > > >> On Sat, Sep 23, 2017 at 05:59:15PM +, Antony Antony wrote:
> > > >> > Add initial DT for NanoPi NEO Plus2 by FriendlyARM
> > > >> > - Allwinner quad core H5 Cortex A53 with an ARM Mali-450MP GPU
> > > >> > - 1 GB DDR3 RAM
> > > >> > - 8GB eMMC flash (Samsung KLM8G1WEPD-B031)
> > > >> > - micro SD card slot
> > > >> > - Gigabit Ethernet (external RTL8211E-VB-CG chip)
> > > >> > - 802.11 b/g/n WiFi, Bluetooth 4.0 (Ampak AP6212A module)
> > > >> > - 2x USB 2.0 host ports
> > > >> >
> > > >> > Signed-off-by: Antony Antony 
> > > >> > ---
> > > >> > Changes v1->v2
> > > >> >  removed memory {}, compatible ="allwinner,sun5i-a13-mmc"
> > > >> >  remove CONFIG_SPL_SPI_FLASH_SUPPORT=y and CONFIG_SPL_SPI_SUNXI=y 
> > > >> > (no SPI)
> > > >> >  remove CONFIG_SD_BOOT=y
> > > >> > Changes v2->v3
> > > >> >  removed compatible ="allwinner,sun50i-a64-mmc"
> > > >> > ---
> > > >> >  arch/arm/dts/Makefile   |   1 +
> > > >> >  arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts | 107 
> > > >> > 
> > > >> >  configs/nanopi_neo_plus2_defconfig  |  18 +
> > > >> >  3 files changed, 126 insertions(+)
> > > >> >  create mode 100644 arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > > >> >  create mode 100644 configs/nanopi_neo_plus2_defconfig
> > > >> >
> > > >> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > >> > index fee4680..295a675 100644
> > > >> > --- a/arch/arm/dts/Makefile
> > > >> > +++ b/arch/arm/dts/Makefile
> > > >> > @@ -333,6 +333,7 @@ dtb-$(CONFIG_MACH_SUN8I_V3S) += \
> > > >> > sun8i-v3s-licheepi-zero.dtb
> > > >> >  dtb-$(CONFIG_MACH_SUN50I_H5) += \
> > > >> > sun50i-h5-nanopi-neo2.dtb \
> > > >> > +   sun50i-h5-nanopi-neo-plus2.dtb \
> > > >> > sun50i-h5-orangepi-pc2.dtb \
> > > >> > sun50i-h5-orangepi-prime.dtb \
> > > >> > sun50i-h5-orangepi-zero-plus2.dtb
> > > >> > diff --git a/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts 
> > > >> > b/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > > >> > new file mode 100644
> > > >> > index 000..8ac098e
> > > >> > --- /dev/null
> > > >> > +++ b/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > > >> > @@ -0,0 +1,107 @@
> > > >> > +/*
> > > >> > + * Copyright (C) 2017 Antony Antony 
> > > >> > + * Copyright (c) 2016 ARM Ltd.
> > > >> > + *
> > > >> > + * This file is dual-licensed: you can use it either under the terms
> > > >> > + * of the GPL or the X11 license, at your option. Note that this 
> > > >> > dual
> > > >> > + * licensing only applies to this file, and not this project as a
> > > >> > + * whole.
> > > >> > + *
> > > >> > + *  a) This library is free software; you can redistribute it and/or
> > > >> > + * modify it under the terms of the GNU General Public License 
> > > >> > as
> > > >> > + * published by the Free Software Foundation; either version 2 
> > > >> > of the
> > > >> > + * License, or (at your option) any later version.
> > > >> > + *
> > > >> > + * This library is distributed in the hope that it will be 
> > > >> > useful,
> > > >> > + * but WITHOUT ANY WARRANTY; without even the implied warranty 
> > > >> > of
> > > >> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > >> > + * GNU General Public License for more details.
> > > >> > + *
> > > >> > + * Or, alternatively,
> > > >> > + *
> > > >> > + *  b) Permission is hereby granted, free of charge, to any person
> > > >> > + * obtaining a copy of this software and associated 
> > > >> > documentation
> > > >> > + * files (the "Software"), to deal in the Software without
> > > >> > + * restriction, including without limitation the rights to use,
> > > >> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > > >> > + * sell copies of the Software, and to permit persons to whom 
> > > >> > the
> > > >> > + * Software is furnished to do so, subject to the following
> > > >> > + * conditions:
> > > >> > + *
> > > >> > + * The above copyright notice and this permission notice shall 
> > > >> > be
> > > >> > + * included in all copies or substantial portions of the 
> > > >> > Software.
> > > >> > + *
> > > >> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY 
> > > >> > KIND,
> > > >> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE 
> > > >> > WARRANTIES
> > > >> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > > >> > + * NONINFRINGEMENT. 

Re: [U-Boot] Broadwell-DE bare metal

[Zoran Stojsavljevic]

> Yes but at the time there was no FSP. I suspect now it would not be
needed.

What about booting times? How long it'll take to boot EFI -> U-Boot -> OS
loader -> init process on x86?

My best guess at least/minimum 10s. Did anybody measure the booting time?

Thank you,
Zoran

On Tue, Oct 10, 2017 at 1:29 AM, Simon Glass  wrote:

> Hi,
>
> On 9 October 2017 at 10:32, Zoran Stojsavljevic
>  wrote:
> >
> >  > It allows U-Boot to boot from EFI.
> >
> > This is a true art of overkill... Really.
> >
> > Full EFI (around 1 to 2 million lines of code: SEC, PEI, DXE phases,
> with ME HECI involved, altogether) -> U-Boot -> YOCTO. Wow. ;-)
>
>
> Yes but at the time there was no FSP. I suspect now it would not be needed.
>
> (BTW as this is a mailing list, please avoid top-posting)
>
> Regards,
> Simon
>
> >
> >
> > Zoran
> >
> > On Mon, Oct 9, 2017 at 4:43 PM, Simon Glass  wrote:
> >>
> >> Hi,
> >>
> >> On 3 October 2017 at 08:58, vnktux  wrote:
> >> > Hi all,
> >> >
> >> > For my graduation project my company asked to use U-Boot as bare
> metal boot-loader on one of their product. The product in an embedded board
> with a Xeon Broadwell-DE D-1527 Quad Core. The current boot-loader consist
> of Coreboot + U-Boot, but of course they want to get rid of Coreboot. I
> have almost no experience with U-Boot (Just with ARM processor a little
> bit) and so far I don't even know if it's possible or not to achieve the
> final goal. What I have understood is that I need the following binary
> blobs to work: fsp.bin, vga.bin, descriptor.bin, me.bin, microcode.bin. Is
> it true? Can somebody point me in the right direction because I am a little
> bit lost?  Plus I don't see many x86 boards implemented in the source code
> of U-Boot.
> >>
> >> The original U-Boot payload support was done with Broadwell-DE (I'm
> >> not sure which one though). It allows U-Boot to boot from EFI.
> >>
> >> For what you want, yes you will need to obtain various binary blobs.
> >> Hopefully you can get the FSP from Intel, and with that the work
> >> required in U-Boot is probably not too large. Although I'm sure that
> >> the FSP API will have changed a little.
> >>
> >> Regards,
> >> Simon
> >>
> >> >
> >> > Best regards,
> >> > Vincenzo
> >> >
> >> > Sent with [ProtonMail](https://protonmail.com) Secure Email.
> >> > ___
> >> > U-Boot mailing list
> >> > U-Boot@lists.denx.de
> >> > https://lists.denx.de/listinfo/u-boot
> >> ___
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de
> >> https://lists.denx.de/listinfo/u-boot
> >
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Broadwell-DE bare metal

[Bin Meng]

Hi Zoran,

On Tue, Oct 10, 2017 at 11:34 AM, Zoran Stojsavljevic
 wrote:
>> Yes but at the time there was no FSP. I suspect now it would not be
> needed.
>
> What about booting times? How long it'll take to boot EFI -> U-Boot -> OS
> loader -> init process on x86?
>
> My best guess at least/minimum 10s. Did anybody measure the booting time?
>

I thought we were discussing U-Boot running as bare metal on the x86
processor. Booting U-Boot from a UEFI BIOS is nice, but that's not the
main usage for U-Boot x86.

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

Re: [U-Boot] Broadwell-DE bare metal

[Zoran Stojsavljevic]

Hello Bin,

You understood me, seems, perfectly. And this is what I am talking about
here.

The whole story told by Andy (Shevchenko) as RE: to my other thread does
not stand, just because of the booting times.

But I need Andy's story (further) to investigate, and have currently no any
spare/free time. But I will later.

And, BTW, you addressed me (wrongly). You should address Simon. To be
politically correct. ;-)

Thank you,
Zoran

On Tue, Oct 10, 2017 at 5:40 AM, Bin Meng  wrote:

> Hi Zoran,
>
> On Tue, Oct 10, 2017 at 11:34 AM, Zoran Stojsavljevic
>  wrote:
> >> Yes but at the time there was no FSP. I suspect now it would not be
> > needed.
> >
> > What about booting times? How long it'll take to boot EFI -> U-Boot -> OS
> > loader -> init process on x86?
> >
> > My best guess at least/minimum 10s. Did anybody measure the booting time?
> >
>
> I thought we were discussing U-Boot running as bare metal on the x86
> processor. Booting U-Boot from a UEFI BIOS is nice, but that's not the
> main usage for U-Boot x86.
>
> Regards,
> Bin
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Powerpc: Make pcie link state judge more specific

[Xiaowei Bao]

Hi York,

I will revise the commit message later.

Best regards
xiaowei

-Original Message-
From: York Sun 
Sent: Monday, October 09, 2017 11:44 PM
To: Xiaowei Bao ; M.h. Lian ; Z.q. 
Hou ; Mingkai Hu ; 
u-boot@lists.denx.de
Subject: Re: [PATCH] Powerpc: Make pcie link state judge more specific

On 09/24/2017 08:44 PM, Bao Xiaowei wrote:
> For some special reset times for longer pcie devices, in this case, 
> the pcie device may on polling compliance state, the RC considers the 
> pcie device is link up, but the pcie device is not link up, only the 
> L0 state is link up state. So add the link up status judgement mechanisms.
> 
> Signed-off-by: Bao Xiaowei 
> ---
> v2:
>  - Detailed function module
>  - Adjust the code structure
> 

Xiaowei,

Can you revise the commit message? I don't quite understand it. It is similar 
but not the same as the change you made for Layerscape, isn't it?

While you respin this patch, please consider my comments earlier.

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

Re: [U-Boot] [PATCH 06/11] efi_loader: implement SetWatchdogTimer

[Heinrich Schuchardt]

On 10/09/2017 06:42 AM, Alexander Graf wrote:
> 
> 
> On 08.10.17 06:57, Heinrich Schuchardt wrote:
>> The watchdog is initialized with a 5 minute timeout period.
>> It can be reset by SetWatchdogTimer.
>> It is stopped by ExitBoottimeServices.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  cmd/bootefi.c |  1 +
>>  include/efi_loader.h  |  4 +++
>>  lib/efi_loader/Makefile   |  2 +-
>>  lib/efi_loader/efi_boottime.c | 15 ++-
>>  lib/efi_loader/efi_watchdog.c | 59 
>> +++
>>  5 files changed, 67 insertions(+), 14 deletions(-)
>>  create mode 100644 lib/efi_loader/efi_watchdog.c
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index b7087e3da8..24958ada46 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -43,6 +43,7 @@ static void efi_init_obj_list(void)
>>  #ifdef CONFIG_GENERATE_SMBIOS_TABLE
>>  efi_smbios_register();
>>  #endif
>> +efi_watchdog_register();
>>  
>>  /* Initialize EFI runtime services */
>>  efi_reset_system_init();
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index e1179b7dcd..223d8d8222 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -163,6 +163,8 @@ int efi_disk_register(void);
>>  int efi_gop_register(void);
>>  /* Called by bootefi to make the network interface available */
>>  int efi_net_register(void);
>> +/* Called by bootefi to make the watchdog available */
>> +int efi_watchdog_register(void);
>>  /* Called by bootefi to make SMBIOS tables available */
>>  void efi_smbios_register(void);
>>  
>> @@ -171,6 +173,8 @@ efi_fs_from_path(struct efi_device_path *fp);
>>  
>>  /* Called by networking code to memorize the dhcp ack package */
>>  void efi_net_set_dhcp_ack(void *pkt, int len);
>> +/* Called by efi_set_watchdog_timer to reset the timer */
>> +efi_status_t efi_set_watchdog(unsigned long timeout);
>>  
>>  /* Called from places to check whether a timer expired */
>>  void efi_timer_check(void);
>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>> index ddb978f650..83d879b686 100644
>> --- a/lib/efi_loader/Makefile
>> +++ b/lib/efi_loader/Makefile
>> @@ -17,7 +17,7 @@ endif
>>  obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
>>  obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
>>  obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
>> -obj-y += efi_file.o efi_variable.o efi_bootmgr.o
>> +obj-y += efi_file.o efi_variable.o efi_bootmgr.o efi_watchdog.o
>>  obj-$(CONFIG_LCD) += efi_gop.o
>>  obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>>  obj-$(CONFIG_PARTITIONS) += efi_disk.o
>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index 30577f717e..81e7d818fc 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -155,18 +155,6 @@ void efi_signal_event(struct efi_event *event)
>>  event->is_queued = false;
>>  }
>>  
>> -/*
>> - * Write a debug message for an EPI API service that is not implemented yet.
>> - *
>> - * @funcnamefunction that is not yet implemented
>> - * @return  EFI_UNSUPPORTED
>> - */
>> -static efi_status_t efi_unsupported(const char *funcname)
>> -{
>> -debug("EFI: App called into unimplemented function %s\n", funcname);
>> -return EFI_EXIT(EFI_UNSUPPORTED);
>> -}
>> -
>>  /*
>>   * Raise the task priority level.
>>   *
>> @@ -1454,6 +1442,7 @@ static efi_status_t EFIAPI efi_exit_boot_services(void 
>> *image_handle,
>>  bootm_disable_interrupts();
>>  
>>  /* Give the payload some time to boot */
>> +efi_set_watchdog(0);
>>  WATCHDOG_RESET();
>>  
>>  return EFI_EXIT(EFI_SUCCESS);
>> @@ -1514,7 +1503,7 @@ static efi_status_t EFIAPI 
>> efi_set_watchdog_timer(unsigned long timeout,
>>  {
>>  EFI_ENTRY("%ld, 0x%"PRIx64", %ld, %p", timeout, watchdog_code,
>>data_size, watchdog_data);
>> -return efi_unsupported(__func__);
>> +return EFI_EXIT(efi_set_watchdog(timeout));
>>  }
>>  
>>  /*
>> diff --git a/lib/efi_loader/efi_watchdog.c b/lib/efi_loader/efi_watchdog.c
>> new file mode 100644
>> index 00..50e95290ea
>> --- /dev/null
>> +++ b/lib/efi_loader/efi_watchdog.c
>> @@ -0,0 +1,59 @@
>> +/*
>> + *  EFI device path interface
> 
> Not quite I guess?
> 
>> + *
>> + *  Copyright (c) 2017 Heinrich Schuchardt
>> + *
>> + *  SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +
>> +static struct efi_event *watchdog_timer_event;
>> +
>> +static void EFIAPI efi_watchdog_timer_notify(struct efi_event *event,
>> + void *context)
>> +{
>> +EFI_ENTRY("%p, %p", event, context);
>> +
>> +printf("\nEFI: Watchdog timeout\n");
>> +EFI_CALL_VOID(efi_runtime_services.reset_system(EFI_RESET_COLD,
>> +EFI_SUCCESS, 0, NULL));
>> +
>> +EFI_EXIT(EFI_UNSUPPORTED);
>> +}
>> +
>> +efi_status_t 

[U-Boot] Edison's U-Boot Architecture

[Zoran Stojsavljevic]

Hello Andy,

Thank you very much for the reply. Instead reply-ing to you in Open Source
fashion, I'll answer to you in the form of the new @. Easier and more
clean/clear approach.

Nevertheless, Edison is cancelled. But since it is already out there, and
you do it, and using it as the test vehicle  Let me start asking in the
Edison/Tangier core design light the similar questions, I already have
asked on this list about U-Boot E3900 and BDW-DX  architectures.

We all know (or I assume U-Boot list knows about Coreboot) and I also
assume majority of the people heard how x86 does work for Coreboot. Quick
recap:
https://www.intel.com/content/www/us/en/intelligent-systems/
intel-firmware-support-package/intel-fsp-overview.html

And we have here in nutshell the following peculiar architecture as the
result of FSP: FSP/Coreboot inter-mingled with U-Boot as a Coreboot's
payload!? Practically three boot-loaders to bring x86 architecture to
YOCTO... FSP being binary blob, actually translating to three binary blobs
in FSP 2.0 spec.

And we know that U-Boot maintainers do not allow binary blobs in U-Boot.
Not like this.

So, what we really want: independent U-Boot on x86, don't we?

I am curious about the following x86 HW/FW configuration with regards to
the U-Boot?

In order to protect INTEL Intellectual Properly (IP), FSP is invented.
Seems that FSP did NOT solve any of the issues. Furthermore, I have no idea
how big projects/players are using x86 with U-Boot (example: BMW, their Ulm
and Munich IT Car depts.) are using YOCTO with x86.

My best guess is that they have private U-Boot (NOT public one), already
adjusted to work as two stage boot-loader, with very clean division of the
layers. Something like this (in the lieu of Tangier, as an example):

Edison/Tangier cores -> IFWI -> MBR -> U-Boot -> eLinux/YOCTO ?!

Here are some explanations regarding the terms/context:

*IFWI is the Intel FirmWare Interface, a binary blob loaded from the eMMC
boot partition that executes a secondary loader (in this case U-Boot) from
the main eMMC. IFWI blobs for the x86 are provided by Intel.*
*Normal IFWI eMMC boot process*

   1. *On-chip boot rom inits eMMC and loads IFWI from the MMC boot
   partitions*
   2. *IFWI looks for OSIP header at top of eMMC (MBR boot block)*
   3. *The header directs IFWI to the start, size, load address, and entry
   of U-Boot in eMMC*
   4. *(need clarification) If u-boot is not found, try the alt u-boot
   image at 5MB into the eMMC*
   5. *U-Boot is loaded into RAM and executed*

*OSIP stands for OS Image Profile, and it is nothing more and less than
INTEL name for very known old fashion MBR, considering DATA structure.*

Andy/Andrej,

Question here: Did I get the correct idea how Edison works with U-Boot?
Could you, please, elaborate how this is done with Edison? (Vopros sdes6:
Ja praviljno ugadal kak eto sdelano/rabotaet? Mozno bolee dannih kad celaja
eta arhitectura rabotaet so Edisonom?)

(I da, esli est6 informacii na Russkom, davaite ih... Rasberus6! Ja boltaju
Russij jazik tocno kak Russkie rozdennie). ;-)

Thank you in advance,
Zoran
___

On Sun, Oct 8, 2017 at 3:45 PM, Andy Shevchenko  wrote:

> On Sat, 2017-10-07 at 16:32 +0800, Bin Meng wrote:
>
> +Cc: Ferry (he might be interested in this thread)
>
> > > Edison?! Edison is dead (end), as I know it...
>
> Some people don't think so, there are ones who like the board.
>
> Actually, while working for Linux kernel at Intel I'm using that board
> on almost daily basis to do many tests which are not related strictly to
> Edison or even Tangier.
>
> > >  The project is cancelled.
>
> That's correct [1].
>
> But be honest, don't you like the idea to have an example of the board,
> which was never designed to be ACPI compatible, actually to become one
> (as much as hardware and ACPI specification allow to, of course)?
>
> Besides that I have started looking into Edison's stuff around spring
> time of 2015. You may see my progress here [2] (first article dated
> 27.03.2015, the chapter "6 What is working and what doesn't" shows
> progress of upstreaming). U-Boot was appeared on my radar when the stock
> one stopped working with vanilla kernels.
>
> > > Correct me if I am wrong!
>
> See above.
>
> > I don't know that story. Loop Andy in to comment.
>
> Thanks, Bin, for including me in the loop.
>
> >  But my understanding
> > is that these are pretty much Intel Tangier SoC related,
>
> ...and Merrifield as a platform, which had been used in some x86-based
> phones.
>
> >  and Edison is
> > just a reference board.
>
> Edison is one of the Intel's IoT boards, but the only board from Intel
> MID family [3].
>
> > > Much more important INTEL U-Boot businesses are ATOM E3900/APL-I
> > > family and
> > > CORE-5 BDW-DE (possible also BDW-DE NS),
> > >
> > > What about these?
>
> I can't answer on this. Work on Edison stuff may be considered as my
> hobby project (I have never been a part of an official team which 

Re: [U-Boot] [PATCH 08/11] efi_selftest: allow to select a single test for exexution

[Heinrich Schuchardt]

On 10/09/2017 06:46 AM, Alexander Graf wrote:
> 
> 
> On 08.10.17 06:57, Heinrich Schuchardt wrote:
>> The second argument of bootefi is passed as a configuration
>> table to the selftest application. It is used to select
>> a single test to be executed.
>>
>> Tests get an on_request property. If this property is set
>> the tests are only executed if explicitly requested.
>>
>> A new command 'bootefi selftest list' is added that allows to list
>> all tests.
>>
>> The invocation of efi_selftest is changed to reflect that
>> bootefi selftest list will call the Exit bootservice.
>>
>> Signed-off-by: Heinrich Schuchardt 
> 
> Wouldn't it make more sense to just pass "bootargs" to the EFI payload
> as command line arguments?
> 
> We could then just
> 
>   U-Boot# setenv bootargs list
>   U-Boot# bootefi selftest
> 
> to list the available self tests. Same for selecting them.

Why bootargs?

> 
> That way we would also be able to directly load Linux as EFI binary and
> pass command line arguments to it without jumping through fdt patching
> hoops.

Does the Linux EFI stub or grub.efi have a capability to receive the
command line?

Regards

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

Re: [U-Boot] [PATCH 10/11] test/py: test reboot by EFI watchdog

[Heinrich Schuchardt]

On 10/09/2017 06:49 AM, Simon Glass wrote:
> On 7 October 2017 at 22:57, Heinrich Schuchardt  wrote:
>> Provide a test verifying that the EFI watchdog
>> reboots the system upon timeout.
>>
>> The test depends on CONFIG_CMD_EFI_SELFTEST=y.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  test/py/tests/test_efi_selftest.py | 11 ++-
>>  1 file changed, 10 insertions(+), 1 deletion(-)Reviewed-by: Simon Glass 
>> 
> 
> Reviewed-by: Simon Glass 
> 
> But why are you removing the NVIDIA copyright?

It was only by a copy mistake that it got in.
It is all my code.

Regards

Heinrich

> 
>>
>> diff --git a/test/py/tests/test_efi_selftest.py 
>> b/test/py/tests/test_efi_selftest.py
>> index 76e282a6c7..b0a86ea8b8 100644
>> --- a/test/py/tests/test_efi_selftest.py
>> +++ b/test/py/tests/test_efi_selftest.py
>> @@ -1,4 +1,3 @@
>> -# Copyright (c) 2016, NVIDIA CORPORATION. All rights reserved.
>>  # Copyright (c) 2017, Heinrich Schuchardt 
>>  #
>>  # SPDX-License-Identifier: GPL-2.0
>> @@ -23,3 +22,13 @@ def test_efi_selftest(u_boot_console):
>> if m != 0:
>> raise Exception('Reset failed during the EFI selftest')
>> u_boot_console.restart_uboot();
>> +
>> +@pytest.mark.buildconfigspec('cmd_bootefi_selftest')
>> +def test_efi_selftest_watchdog_reboot(u_boot_console):
>> +   output = u_boot_console.run_command('bootefi selftest list')
>> +   assert '\'watchdog reboot\'' in output
>> +   u_boot_console.run_command(cmd='bootefi selftest \'watchdog 
>> reboot\'', wait_for_prompt=False)
>> +   m = u_boot_console.p.expect(['resetting', 'U-Boot'])
>> +   if m != 0:
>> +   raise Exception('Reset failed in \'watchdog reboot\' test')
>> +   u_boot_console.restart_uboot();
>> --
>> 2.14.1
>>
> 

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

Re: [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Jonathan Gray]

On Sun, Oct 08, 2017 at 11:12:28PM -0400, Tom Rini wrote:
> On Sun, Oct 08, 2017 at 10:56:26PM -0300, Fabio Estevam wrote:
> > On Sun, Oct 8, 2017 at 11:04 AM, Jonathan Gray  wrote:
> > 
> > > It turns out to be
> > >
> > > commit 2460098cffacd18729262e3ed36656e6943783ed
> > > Author: Tom Rini 
> > > Date:   Fri Sep 22 07:37:43 2017 -0400
> > >
> > > fs/fat: Reduce stack usage
> > >
> > > We have limited stack in SPL builds.  Drop itrblock and move to
> > > malloc/free of itr to move this off of the stack.  As part of this 
> > > fix a
> > > double-free issue in fat_size().
> > >
> > > Signed-off-by: Tom Rini 
> > > ---
> > > Rework to use malloc/free as moving this to a global overflows some SH
> > > targets.
> > >
> > >  fs/fat/fat.c | 14 ++
> > >  1 file changed, 10 insertions(+), 4 deletions(-)
> > >
> > > With that reverted I just get the efi loader problem, no alignment errors.
> > 
> > Thanks for doing the bisect.
> > 
> > Tom, can you prepare a fix for this?
> 
> No, this is a required fix for other platforms.  Why is this failing in
> the particular case that it's failing in?

Switching the malloc calls for malloc_cache_aligned also avoids the problem.

U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47)
Trying to boot from MMC1


U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 34C
Reset cause: WDOG
Board: MX6 Cubox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

No panel detected: default to HDMI
Display: HDMI (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468
CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0
CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0
CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8
CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8
CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470
CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470
CACHE: Misaligned operation at range [8f89e488, 8f89ec88]
CACHE: Misaligned operation at range [8f89e488, 8f89ec88]
ERROR: v7_outer_cache_inval_range 

Re: [U-Boot] [PATCH] armv8: configs: ls1012a: correct the generic timer frequency issue

[Prabhakar Kushwaha]

Hi York,


> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Andy Tang
> Sent: Tuesday, October 10, 2017 6:36 AM
> To: York Sun 
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] armv8: configs: ls1012a: correct the generic 
> timer
> frequency issue
> 
> Hi York,
> 
> Ls1012a uses the fixed 25Mhz clock, I will update the commit message and
> resend the patch.
> 
> Thanks,
> Andy
> 
> > -Original Message-
> > From: York Sun
> > Sent: Tuesday, October 10, 2017 12:00 AM
> > To: Andy Tang 
> > Cc: s...@chromium.org; u-boot@lists.denx.de
> > Subject: Re: [PATCH] armv8: configs: ls1012a: correct the generic timer
> > frequency issue
> >
> > On 10/08/2017 11:48 PM, andy.t...@nxp.com wrote:
> > > From: Yuantian Tang 
> > >
> > > Generic Timer frequency should be 25Mhz. Current setting is
> > > CONFIG_SYS_CLK_FREQ/4 which is about 31Mhz, which is not correct.
> > > So correct it.
> > >
> > > Signed-off-by: Tang Yuantian 
> > > ---
> > >  include/configs/ls1012a_common.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/configs/ls1012a_common.h
> > > b/include/configs/ls1012a_common.h
> > > index 096799eb64..a4e78f335f 100644
> > > --- a/include/configs/ls1012a_common.h
> > > +++ b/include/configs/ls1012a_common.h
> > > @@ -32,7 +32,7 @@
> > >  #define CONFIG_SYS_DDR_BLOCK2_BASE 0x88000ULL
> > >
> > >  /* Generic Timer Definitions */
> > > -#define COUNTER_FREQUENCYCONFIG_SYS_CLK_FREQ/4
> > /* 25MHz */
> > > +#define COUNTER_FREQUENCY2500/* 25MHz */
> > >
> >
> >
> > Yuantian,
> >
> > LS1012A use fixed 25MHz clock, doesn't it? If so, that's the reason a fixed
> > value should be used, not because CONFIG_SYS_CLK_FREQ/4 isn't correct. It
> > is correct for many other platform. Please update the commit message.
> >


LS1012A has fixed external clock 25MHz which generates following 2 internal 
clocks
- Core clock (100MHz)
- Platform clock (133MHz)

System counter run with  Core clock i.e. 100MHz. 

So patch description should mention reference of Core Clock instead of external 
25MHz fix clock. 

--pk


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

Re: [U-Boot] Broadwell-DE bare metal

[Bin Meng]

Hi Zoran,

On Tue, Oct 10, 2017 at 11:53 AM, Zoran Stojsavljevic
 wrote:
> Hello Bin,
>
> You understood me, seems, perfectly. And this is what I am talking about
> here.
>
> The whole story told by Andy (Shevchenko) as RE: to my other thread does not
> stand, just because of the booting times.
>
> But I need Andy's story (further) to investigate, and have currently no any
> spare/free time. But I will later.
>
> And, BTW, you addressed me (wrongly). You should address Simon. To be
> politically correct. ;-)
>

Please avoid top-posting..

What project are you doing currently for the investigation?

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

Re: [U-Boot] [PATCH] dwc: ep0: Allocate and flush dwc->ep0_trb in a cache aligned manner

[Faiz Abbas]

+Kishon

On Friday 06 October 2017 05:03 PM, Faiz Abbas wrote:
> Hi,
> 
> On Thursday 05 October 2017 04:57 PM, Marek Vasut wrote:
>> On 10/04/2017 03:11 PM, Faiz Abbas wrote:
>>> Hi,
>>>
>>> On Wednesday 04 October 2017 06:01 PM, Marek Vasut wrote:
 On 10/04/2017 12:51 PM, Faiz Abbas wrote:
> Hi,
> On Tuesday 03 October 2017 06:48 PM, Marek Vasut wrote:
>> On 10/03/2017 03:17 PM, Faiz Abbas wrote:
>>> Hi,
>>> On Tuesday 03 October 2017 05:34 PM, Marek Vasut wrote:
 On 09/19/2017 01:15 PM, Faiz Abbas wrote:
>  
> - dwc3_flush_cache((uintptr_t)trb, sizeof(*trb));
> + dwc3_flush_cache((uintptr_t)dwc->ep0_trb_addr, sizeof(*trb) * 
> 2);

 Why *2 ?
>>>
>>> Because its allocated as sizeof(*dwc->ep0_trb) * 2 below. This is not
>>> strictly required as dwc3_flush_cache() rounds up the size to
>>> CACHELINE_SIZE but from a caller POV, flush everything we allocated.
>>
>> Can the other TRB be in use ? Maybe aligning the TRBs to cacheline size
>> would be better ?
>>
> A single trb is 16 bytes in size and two of them are allocated
> contiguously.

 Why are two allocated continuously ? (I am not dwc3 expert)
>>>
>>> Neither am I. I did try to pad to the dwc_trb structure such that each
>>> trb is 64 bytes in size but this leads to failures when testing. I
>>> didn't get a chance to debug this though. I suspect its because the code
>>> expects the trbs to be contiguous and/or 16 bytes in size.
>>
>> Maybe that's something you need to check -- why it fails if aligned . Do
>> the TRBs need to be stored back-to-back ?
> 
> Sure. Will check that and submit another version with fixes.
> 
> Thanks,
> Faiz
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] ARM: zynq: Add support for SYZYGY Hub board

[Michal Simek]

On 28.9.2017 02:53, Tom McLeod wrote:
> Add the Zynq-based SYZYGY Hub board from Opal Kelly. The board
> contains a Xilinx Zynq xc7z012s SoC, 1GB DDR3 RAM, and supports
> booting from SD.
> 
> Signed-off-by: Tom McLeod <tom.mcl...@opalkelly.com>
> Cc: Michal Simek <mon...@monstr.eu>
> CC: Albert Aribaud <albert.u.b...@aribaud.net>
> ---
> Changes for v2:
>   - Append syzygy-hub dtb to the end of the Zynq section in the dts Makefile
> as this appears to be the convention, if desired I can change this
>   - Add an opalkelly,syzygy-hub compatible line to the syzygy hub dts
>   - Clean up the ps7_init_gpl sources, removing old/unnecessary/unused code
> and eliminating all checkpatch warnings/errors
> 
>  arch/arm/dts/Makefile  |   3 +-
>  arch/arm/dts/zynq-syzygy-hub.dts   |  72 
>  board/opalkelly/zynq/MAINTAINERS   |   6 +
>  board/opalkelly/zynq/Makefile  |   9 +
>  board/opalkelly/zynq/board.c   |   1 +
>  .../opalkelly/zynq/zynq-syzygy-hub/ps7_init_gpl.c  | 431 
> +
>  .../opalkelly/zynq/zynq-syzygy-hub/ps7_init_gpl.h  |  82 
>  configs/syzygy_hub_defconfig   |  57 +++
>  include/configs/syzygy_hub.h   |  72 
>  9 files changed, 732 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/zynq-syzygy-hub.dts
>  create mode 100644 board/opalkelly/zynq/MAINTAINERS
>  create mode 100644 board/opalkelly/zynq/Makefile
>  create mode 100644 board/opalkelly/zynq/board.c
>  create mode 100644 board/opalkelly/zynq/zynq-syzygy-hub/ps7_init_gpl.c
>  create mode 100644 board/opalkelly/zynq/zynq-syzygy-hub/ps7_init_gpl.h
>  create mode 100644 configs/syzygy_hub_defconfig
>  create mode 100644 include/configs/syzygy_hub.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 762429c..1a6a8ff 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -135,7 +135,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
>   zynq-zc770-xm010.dtb \
>   zynq-zc770-xm011.dtb \
>   zynq-zc770-xm012.dtb \
> - zynq-zc770-xm013.dtb
> + zynq-zc770-xm013.dtb \
> + zynq-syzygy-hub.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += \
>   zynqmp-ep108.dtb\
>   zynqmp-zcu102-revA.dtb  \
> diff --git a/arch/arm/dts/zynq-syzygy-hub.dts 
> b/arch/arm/dts/zynq-syzygy-hub.dts
> new file mode 100644
> index 000..ebd08b4
> --- /dev/null
> +++ b/arch/arm/dts/zynq-syzygy-hub.dts
> @@ -0,0 +1,72 @@
> +/*
> + * SYZYGY Hub DTS
> + *
> + *  Copyright (C) 2011 - 2015 Xilinx
> + *  Copyright (C) 2017 Opal Kelly Inc.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +/dts-v1/;
> +/include/ "zynq-7000.dtsi"
> +
> +/ {
> + model = "SYZYGY Hub";
> + compatible = "opalkelly,syzygy-hub", "xlnx,zynq-7000";

Patch looks good but only this prefix needs to be added to the Linux
kernel. It should be present in this file. Please send the patch and
when it is added to linux-next I will add your patch

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/vendor-prefixes.txt?h=next-20171009

Thanks,
Michal
-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs




signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] moveconfig: Fix error message for a missing toolchain

[Masahiro Yamada]

2017-10-08 19:31 GMT+09:00 Tuomas Tynkkynen :
> Due to misplaced quote the error message is literally e.g.:
>
> MigoR_defconfig
> Tool chain for '%s' is missing.  Do nothing.
>  % arch
>
> Fix it to correctly show the architecture:
>
> MigoR_defconfig
> Tool chain for 'sh' is missing.  Do nothing.
>
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  tools/moveconfig.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/moveconfig.py b/tools/moveconfig.py
> index e3116461ba..bdd4899fcd 100755
> --- a/tools/moveconfig.py
> +++ b/tools/moveconfig.py
> @@ -1170,7 +1170,7 @@ class Slot:
>  toolchain = self.toolchains.Select(arch)
>  except ValueError:
>  self.log += color_text(self.options.color, COLOR_YELLOW,
> -"Tool chain for '%s' is missing.  Do nothing.\n % arch")
> +"Tool chain for '%s' is missing.  Do nothing.\n" % arch)
>  self.finish(False)
>  return
> env = toolchain.MakeEnvironment(False)


Acked-by: Masahiro Yamada 



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

[U-Boot] [PATCH] efi_loader: search all possible disk partitions

[Jonathan Gray]

When searching for partitions don't stop if a partition is not present
for a given partition number as there may be valid partitions after.

Search for up to MAX_SEARCH_PARTITIONS matching the other callers of
part_get_info().

This allows OpenBSD to boot via the efi_loader on rpi_3 again after
changes made after U-Boot 2017.09.  With MBR partitioning OpenBSD will
by default use the fourth partition for the 0xA6 (OpenBSD) partition.

Signed-off-by: Jonathan Gray 
---
 lib/efi_loader/efi_disk.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 47b487aa30..6b192701a8 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -254,18 +254,19 @@ static int efi_disk_create_eltorito(struct blk_desc *desc,
 #if CONFIG_IS_ENABLED(ISO_PARTITION)
char devname[32] = { 0 }; /* dp->str is u16[32] long */
disk_partition_t info;
-   int part = 1;
+   int part;
 
if (desc->part_type != PART_TYPE_ISO)
return 0;
 
/* and devices for each partition: */
-   while (!part_get_info(desc, part, )) {
+   for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
+   if (part_get_info(desc, part, ))
+   continue;
snprintf(devname, sizeof(devname), "%s:%d", pdevname,
 part);
efi_disk_add_dev(devname, if_typename, desc, diskid,
 info.start, part);
-   part++;
disks++;
}
 
@@ -299,15 +300,16 @@ int efi_disk_register(void)
struct blk_desc *desc = dev_get_uclass_platdata(dev);
const char *if_typename = dev->driver->name;
disk_partition_t info;
-   int part = 1;
+   int part;
 
printf("Scanning disk %s...\n", dev->name);
 
/* add devices for each partition: */
-   while (!part_get_info(desc, part, )) {
+   for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
+   if (part_get_info(desc, part, ))
+   continue;
efi_disk_add_dev(dev->name, if_typename, desc,
 desc->devnum, 0, part);
-   part++;
}
 
/* ... and add block device: */
@@ -341,7 +343,7 @@ int efi_disk_register(void)
struct blk_desc *desc;
char devname[32] = { 0 }; /* dp->str is u16[32] long */
disk_partition_t info;
-   int part = 1;
+   int part;
 
desc = blk_get_devnum_by_type(if_type, i);
if (!desc)
@@ -353,7 +355,9 @@ int efi_disk_register(void)
 if_typename, i);
 
/* add devices for each partition: */
-   while (!part_get_info(desc, part, )) {
+   for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
+   if (part_get_info(desc, part, ))
+   continue;
efi_disk_add_dev(devname, if_typename, desc,
 i, 0, part);
part++;
-- 
2.14.2

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

Re: [U-Boot] efi_loader: enough-uefi-for-shell: [PATCH 06/11] efi_loader: implement SetWatchdogTimer

[Rob Clark]

On Sun, Oct 8, 2017 at 6:14 PM, Heinrich Schuchardt  wrote:
> On 10/08/2017 06:57 AM, Heinrich Schuchardt wrote:
>> The watchdog is initialized with a 5 minute timeout period.
>> It can be reset by SetWatchdogTimer.
>> It is stopped by ExitBoottimeServices.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  cmd/bootefi.c |  1 +
>>  include/efi_loader.h  |  4 +++
>>  lib/efi_loader/Makefile   |  2 +-
>>  lib/efi_loader/efi_boottime.c | 15 ++-
>>  lib/efi_loader/efi_watchdog.c | 59 
>> +++
>>  5 files changed, 67 insertions(+), 14 deletions(-)
>>  create mode 100644 lib/efi_loader/efi_watchdog.c
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index b7087e3da8..24958ada46 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -43,6 +43,7 @@ static void efi_init_obj_list(void)
>>  #ifdef CONFIG_GENERATE_SMBIOS_TABLE
>>   efi_smbios_register();
>>  #endif
>> + efi_watchdog_register();
>>
>>   /* Initialize EFI runtime services */
>>   efi_reset_system_init();
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index e1179b7dcd..223d8d8222 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -163,6 +163,8 @@ int efi_disk_register(void);
>>  int efi_gop_register(void);
>>  /* Called by bootefi to make the network interface available */
>>  int efi_net_register(void);
>> +/* Called by bootefi to make the watchdog available */
>> +int efi_watchdog_register(void);
>>  /* Called by bootefi to make SMBIOS tables available */
>>  void efi_smbios_register(void);
>>
>> @@ -171,6 +173,8 @@ efi_fs_from_path(struct efi_device_path *fp);
>>
>>  /* Called by networking code to memorize the dhcp ack package */
>>  void efi_net_set_dhcp_ack(void *pkt, int len);
>> +/* Called by efi_set_watchdog_timer to reset the timer */
>> +efi_status_t efi_set_watchdog(unsigned long timeout);
>>
>>  /* Called from places to check whether a timer expired */
>>  void efi_timer_check(void);
>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>> index ddb978f650..83d879b686 100644
>> --- a/lib/efi_loader/Makefile
>> +++ b/lib/efi_loader/Makefile
>> @@ -17,7 +17,7 @@ endif
>>  obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
>>  obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
>>  obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
>> -obj-y += efi_file.o efi_variable.o efi_bootmgr.o
>> +obj-y += efi_file.o efi_variable.o efi_bootmgr.o efi_watchdog.o
>>  obj-$(CONFIG_LCD) += efi_gop.o
>>  obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>>  obj-$(CONFIG_PARTITIONS) += efi_disk.o
>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index 30577f717e..81e7d818fc 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -155,18 +155,6 @@ void efi_signal_event(struct efi_event *event)
>>   event->is_queued = false;
>>  }
>>
>> -/*
>> - * Write a debug message for an EPI API service that is not implemented yet.
>> - *
>> - * @funcname function that is not yet implemented
>> - * @return   EFI_UNSUPPORTED
>> - */
>> -static efi_status_t efi_unsupported(const char *funcname)
>> -{
>> - debug("EFI: App called into unimplemented function %s\n", funcname);
>> - return EFI_EXIT(EFI_UNSUPPORTED);
>> -}
>> -
>>  /*
>>   * Raise the task priority level.
>>   *
>> @@ -1454,6 +1442,7 @@ static efi_status_t EFIAPI efi_exit_boot_services(void 
>> *image_handle,
>>   bootm_disable_interrupts();
>>
>>   /* Give the payload some time to boot */
>> + efi_set_watchdog(0);
>>   WATCHDOG_RESET();
>>
>>   return EFI_EXIT(EFI_SUCCESS);
>> @@ -1514,7 +1503,7 @@ static efi_status_t EFIAPI 
>> efi_set_watchdog_timer(unsigned long timeout,
>>  {
>>   EFI_ENTRY("%ld, 0x%"PRIx64", %ld, %p", timeout, watchdog_code,
>> data_size, watchdog_data);
>> - return efi_unsupported(__func__);
>> + return EFI_EXIT(efi_set_watchdog(timeout));
>>  }
>>
>>  /*
>> diff --git a/lib/efi_loader/efi_watchdog.c b/lib/efi_loader/efi_watchdog.c
>> new file mode 100644
>> index 00..50e95290ea
>> --- /dev/null
>> +++ b/lib/efi_loader/efi_watchdog.c
>> @@ -0,0 +1,59 @@
>> +/*
>> + *  EFI device path interface
>> + *
>> + *  Copyright (c) 2017 Heinrich Schuchardt
>> + *
>> + *  SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +
>> +static struct efi_event *watchdog_timer_event;
>> +
>> +static void EFIAPI efi_watchdog_timer_notify(struct efi_event *event,
>> +  void *context)
>> +{
>> + EFI_ENTRY("%p, %p", event, context);
>> +
>> + printf("\nEFI: Watchdog timeout\n");
>> + EFI_CALL_VOID(efi_runtime_services.reset_system(EFI_RESET_COLD,
>> + EFI_SUCCESS, 0, NULL));
>
> Hello Rob,
>
> referring to:
> 

Re: [U-Boot] [PATCH 08/11] efi_selftest: allow to select a single test for exexution

[Alexander Graf]

On 09.10.17 12:54, Heinrich Schuchardt wrote:
> On 10/09/2017 08:57 AM, Alexander Graf wrote:
>>
>>
>> On 09.10.17 08:14, Heinrich Schuchardt wrote:
>>> On 10/09/2017 06:46 AM, Alexander Graf wrote:


 On 08.10.17 06:57, Heinrich Schuchardt wrote:
> The second argument of bootefi is passed as a configuration
> table to the selftest application. It is used to select
> a single test to be executed.
>
> Tests get an on_request property. If this property is set
> the tests are only executed if explicitly requested.
>
> A new command 'bootefi selftest list' is added that allows to list
> all tests.
>
> The invocation of efi_selftest is changed to reflect that
> bootefi selftest list will call the Exit bootservice.
>
> Signed-off-by: Heinrich Schuchardt 

 Wouldn't it make more sense to just pass "bootargs" to the EFI payload
 as command line arguments?

 We could then just

   U-Boot# setenv bootargs list
   U-Boot# bootefi selftest

 to list the available self tests. Same for selecting them.
>>>
>>> Why bootargs?
>>>
>>
>> Because bootargs is the variable that "bootm" pushes into a payload as
>> command line arguments.
>>

 That way we would also be able to directly load Linux as EFI binary and
 pass command line arguments to it without jumping through fdt patching
 hoops.
>>>
>>> Does the Linux EFI stub or grub.efi have a capability to receive the
>>> command line?
>>
>> Linux does:
>>
>>
>> https://github.com/torvalds/linux/blob/master/drivers/firmware/efi/libstub/efi-stub-helper.c#L773
>>
>> I don't think grub implements it today, but I don't see why it should.
>> Any UEFI application that expects to be executed from the UEFI Shell
>> certainly interprets the passed in command line.
>>
>>
>> Alex
>>
> 
> Thanks for pointing me at fields LoadOptionsSize and LoadOptions in the
> EFI_Loaded_Image_Protocol. Yes it makes sense to use this mechanism.
> 
> I guess efi_setup_loaded_image would be a good place to set the fields.

I'm not sure about that. efi_setup_loaded_image gets called from payload
context too. Imagine a bootefi on a UEFI Shell which then runs Linux.
That Linux binary should not see our bootargs arguments.

I think it really belongs in do_bootefi_exec.


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

Re: [U-Boot] the boot process breaks.

[nabil efrin]

Hello 

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

[U-Boot] [PATCH 9/9] configs: ls1012a: add pfe configuration for LS1012A

[Calvin Johnson]

Signed-off-by: Calvin Johnson 
Signed-off-by: Anjaneyulu Jagarlmudi 
---
 configs/ls1012afrdm_qspi_defconfig |  1 +
 configs/ls1012aqds_qspi_defconfig  |  1 +
 configs/ls1012ardb_qspi_defconfig  |  1 +
 drivers/net/Kconfig|  1 +
 drivers/net/Makefile   |  1 +
 drivers/net/pfe_eth/Kconfig| 23 ++-
 include/configs/ls1012a_common.h   |  6 +++---
 include/configs/ls1012afrdm.h  |  7 +++
 include/configs/ls1012aqds.h   | 14 ++
 include/configs/ls1012ardb.h   |  8 
 10 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/configs/ls1012afrdm_qspi_defconfig 
b/configs/ls1012afrdm_qspi_defconfig
index 84b5577..7db7a18 100644
--- a/configs/ls1012afrdm_qspi_defconfig
+++ b/configs/ls1012afrdm_qspi_defconfig
@@ -32,6 +32,7 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
+CONFIG_FSL_PFE=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
diff --git a/configs/ls1012aqds_qspi_defconfig 
b/configs/ls1012aqds_qspi_defconfig
index 2124273..4b9fdf5 100644
--- a/configs/ls1012aqds_qspi_defconfig
+++ b/configs/ls1012aqds_qspi_defconfig
@@ -37,6 +37,7 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
+CONFIG_FSL_PFE=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
diff --git a/configs/ls1012ardb_qspi_defconfig 
b/configs/ls1012ardb_qspi_defconfig
index 40349ce..d63e736 100644
--- a/configs/ls1012ardb_qspi_defconfig
+++ b/configs/ls1012ardb_qspi_defconfig
@@ -35,6 +35,7 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
+CONFIG_FSL_PFE=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 736aab2..c82c63b 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -304,4 +304,5 @@ config FEC2_PHY_NORXERR
  The PHY does not have a RXERR line (RMII only).
  (so program the FEC to ignore it).
 
+source "drivers/net/pfe_eth/Kconfig"
 endif # NETDEVICES
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 94a4fd8..0572cde 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -75,3 +75,4 @@ obj-$(CONFIG_FSL_MEMAC) += fm/memac_phy.o
 obj-$(CONFIG_VSC9953) += vsc9953.o
 obj-$(CONFIG_PIC32_ETH) += pic32_mdio.o pic32_eth.o
 obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o
+obj-$(CONFIG_FSL_PFE) += pfe_eth/
diff --git a/drivers/net/pfe_eth/Kconfig b/drivers/net/pfe_eth/Kconfig
index b9996df..c05aeda 100644
--- a/drivers/net/pfe_eth/Kconfig
+++ b/drivers/net/pfe_eth/Kconfig
@@ -1,8 +1,29 @@
+menuconfig FSL_PFE
+   bool "Freescale PFE driver"
+   help
+ This driver provides support for Freescale PFE.
+
+if FSL_PFE
+
 config UTIL_PE_DISABLED
bool
help
  Disable UTIL processor engine of PFE
 
-config SYS_FSL_PPFE_ADDR
+config SYS_FSL_PFE_ADDR
hex "PFE base address"
default 0x0400
+
+config SYS_LS_PFE_FW_ADDR
+   hex "Flash address of PFE firmware"
+   default 0x40a0
+
+config DDR_PFE_PHYS_BASEADDR
+   hex "PFE DDR physical base address"
+   default 0x0380
+
+config DDR_PFE_BASEADDR
+   hex "PFE DDR base address"
+   default 0x8380
+
+endif
diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h
index 52c2c3a..3df5586 100644
--- a/include/configs/ls1012a_common.h
+++ b/include/configs/ls1012a_common.h
@@ -113,9 +113,9 @@
 #define CONFIG_BOOTARGS"console=ttyS0,115200 root=/dev/ram0 " \
"earlycon=uart8250,mmio,0x21c0500 quiet 
lpj=25"
 #undef CONFIG_BOOTCOMMAND
-#define CONFIG_BOOTCOMMAND "sf probe 0:0; sf read $kernel_load "\
-   "$kernel_start $kernel_size && "\
-   "bootm $kernel_load"
+#define CONFIG_BOOTCOMMAND "pfe stop; sf probe 0:0; sf read $kernel_load "\
+   "$kernel_start $kernel_size && "\
+   "bootm $kernel_load"
 
 /* Monitor Command Prompt */
 #define CONFIG_SYS_CBSIZE  512 /* Console I/O Buffer Size */
diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h
index 544dea0..a3f8824 100644
--- a/include/configs/ls1012afrdm.h
+++ b/include/configs/ls1012afrdm.h
@@ -9,6 +9,13 @@
 
 #include "ls1012a_common.h"
 
+#ifdef CONFIG_FSL_PFE
+#define EMAC1_PHY_ADDR  0x2
+#define EMAC2_PHY_ADDR  0x1
+#define CONFIG_PHYLIB
+#define CONFIG_PHY_REALTEK
+#endif
+
 /* DDR */
 #define CONFIG_DIMM_SLOTS_PER_CTLR 1
 #define CONFIG_CHIP_SELECTS_PER_CTRL   1
diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h
index 16714bb..9873339 100644
--- a/include/configs/ls1012aqds.h
+++ b/include/configs/ls1012aqds.h
@@ -9,6 +9,20 @@
 
 #include "ls1012a_common.h"
 
+/* PFE Ethernet */
+#ifdef CONFIG_FSL_PFE
+#define 

[U-Boot] [PATCH][v2] driver: fsl-mc: memset pointers after malloc

[Prabhakar Kushwaha]

Memory allocated via malloc is not guaranteed to be zeroized.

So explicitly memset the memory allocated via malloc.

Signed-off-by: Prabhakar Kushwaha 
---
Changes for v2: Replaced malloc/memset with calloc

 drivers/net/fsl-mc/mc.c | 39 +--
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index 458c458..05d3358 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -725,9 +725,9 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
 * Initialize the global default MC portal
 * And check that the MC firmware is responding portal commands:
 */
-   root_mc_io = (struct fsl_mc_io *)malloc(sizeof(struct fsl_mc_io));
+   root_mc_io = (struct fsl_mc_io *)calloc(sizeof(struct fsl_mc_io), 1);
if (!root_mc_io) {
-   printf(" No memory: malloc() failed\n");
+   printf(" No memory: calloc() failed\n");
return -ENOMEM;
}
 
@@ -877,11 +877,12 @@ static int dpio_init(void)
struct dpio_cfg dpio_cfg;
int err = 0;
 
-   dflt_dpio = (struct fsl_dpio_obj *)malloc(sizeof(struct fsl_dpio_obj));
+   dflt_dpio = (struct fsl_dpio_obj *)calloc(
+   sizeof(struct fsl_dpio_obj), 1);
if (!dflt_dpio) {
-   printf("No memory: malloc() failed\n");
+   printf("No memory: calloc() failed\n");
err = -ENOMEM;
-   goto err_malloc;
+   goto err_calloc;
}
 
dpio_cfg.channel_mode = DPIO_LOCAL_CHANNEL;
@@ -946,7 +947,7 @@ err_get_attr:
dpio_destroy(dflt_mc_io, MC_CMD_NO_FLAGS, dflt_dpio->dpio_handle);
 err_create:
free(dflt_dpio);
-err_malloc:
+err_calloc:
return err;
 }
 
@@ -1028,11 +1029,11 @@ static int dprc_init(void)
goto err_create;
}
 
-   dflt_mc_io = (struct fsl_mc_io *)malloc(sizeof(struct fsl_mc_io));
+   dflt_mc_io = (struct fsl_mc_io *)calloc(sizeof(struct fsl_mc_io), 1);
if (!dflt_mc_io) {
err  = -ENOMEM;
-   printf(" No memory: malloc() failed\n");
-   goto err_malloc;
+   printf(" No memory: calloc() failed\n");
+   goto err_calloc;
}
 
child_portal_id = MC_PORTAL_OFFSET_TO_PORTAL_ID(mc_portal_offset);
@@ -1057,7 +1058,7 @@ static int dprc_init(void)
return 0;
 err_child_open:
free(dflt_mc_io);
-err_malloc:
+err_calloc:
dprc_destroy_container(root_mc_io, MC_CMD_NO_FLAGS,
   root_dprc_handle, child_dprc_id);
 err_create:
@@ -1108,11 +1109,12 @@ static int dpbp_init(void)
struct dpbp_attr dpbp_attr;
struct dpbp_cfg dpbp_cfg;
 
-   dflt_dpbp = (struct fsl_dpbp_obj *)malloc(sizeof(struct fsl_dpbp_obj));
+   dflt_dpbp = (struct fsl_dpbp_obj *)calloc(
+   sizeof(struct fsl_dpbp_obj), 1);
if (!dflt_dpbp) {
-   printf("No memory: malloc() failed\n");
+   printf("No memory: calloc() failed\n");
err = -ENOMEM;
-   goto err_malloc;
+   goto err_calloc;
}
 
dpbp_cfg.options = 512;
@@ -1162,7 +1164,7 @@ err_get_attr:
dpbp_close(dflt_mc_io, MC_CMD_NO_FLAGS, dflt_dpbp->dpbp_handle);
dpbp_destroy(dflt_mc_io, MC_CMD_NO_FLAGS, dflt_dpbp->dpbp_handle);
 err_create:
-err_malloc:
+err_calloc:
return err;
 }
 
@@ -1204,11 +1206,12 @@ static int dpni_init(void)
struct dpni_extended_cfg dpni_extended_cfg;
struct dpni_cfg dpni_cfg;
 
-   dflt_dpni = (struct fsl_dpni_obj *)malloc(sizeof(struct fsl_dpni_obj));
+   dflt_dpni = (struct fsl_dpni_obj *)calloc(
+   sizeof(struct fsl_dpni_obj), 1);
if (!dflt_dpni) {
-   printf("No memory: malloc() failed\n");
+   printf("No memory: calloc() failed\n");
err = -ENOMEM;
-   goto err_malloc;
+   goto err_calloc;
}
 
memset(_extended_cfg, 0, sizeof(dpni_extended_cfg));
@@ -1270,7 +1273,7 @@ err_get_attr:
 err_create:
 err_prepare_extended_cfg:
free(dflt_dpni);
-err_malloc:
+err_calloc:
return err;
 }
 
-- 
2.7.4

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

Re: [U-Boot] BUG: Environment is in SPI flash does not even compile (at least for Orange PI PC2

[Jagan Teki]

On Wed, Sep 27, 2017 at 12:43 PM,   wrote:
>
> Hi,
>
> I'm trying to compile u-boot with Environment in SPI flash
> (CONFIG_ENV_IS_IN_SPI_FLASH?) for Orange PI PC2.
>
> Compilation ends with an error:
>   CC  env/sf.o
> env/sf.c: In function ‘env_sf_save’:
> env/sf.c:266:6: error: ‘CONFIG_ENV_SECT_SIZE’ undeclared (first use in this
> function); did you mean ‘CONFIG_ENV_SIZE’?

Need to defined SPI_FLASH and respective VENDOR FLASH configs, better
to send a patch for further discussion if any.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 016/080] spi: Remove spi_flash_probe_fdt

[Jagan Teki]

On Fri, Sep 29, 2017 at 6:21 PM, Mario Six  wrote:
> Commit ba45756 ("dm: x86: spi: Convert ICH SPI driver to driver model")
> removed the last usage of the spi_flash_probe_fdt function, rendering it
> obsolete.
>
> This patch removes the function.
>
> Signed-off-by: Mario Six 
> ---

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot