Re: [U-Boot] [PATCH 1/1] efi_loader: use built-in device tree in bootefi command

[Alexander Graf]

On 01/20/2018 01:56 PM, Heinrich Schuchardt wrote:

The bootefi command has two parameters: the address of the executable and
the address of the flattened device tree.

When executing the devicetree command in grub this command can only
replace an existing device tree. So we always want to pass a device tree.

With the patch the device tree defaults to the internal one. But of cause
the user still can supply his one via the second parameter.

One use case is booting via iPXE from an iSCSI drive. As we may be able
to choose between different operating systems in the iPXE menu we cannot
know the correct device tree when invoking bootefi. The dtb might not even
be installed on a local device.

Signed-off-by: Heinrich Schuchardt 


All of this logic is already implemented in the distro boot script, so 
if you load your iPXE EFI binary via dhcp boot, from a block device or 
something similar, it will by default already get $fdtcontroladdr passed 
in. I'm not sure I'm terribly happy to have additional magic in the 
bootefi command. If you want to spawn an EFI binary without device tree 
table, you should be able to do so IMHO.


How do you invoke iPXE?


Alex

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

Re: [U-Boot] [PATCH v4 1/2] efi_driver: EFI block driver

[Alexander Graf]

On 01/21/2018 07:29 PM, Heinrich Schuchardt wrote:

This patch provides
* a uclass for EFI drivers
* a EFI driver for block devices

For each EFI driver the uclass
* creates a handle
* adds the driver binding protocol

The uclass provides the bind, start, and stop entry points for the driver
binding protocol.

In bind() and stop() it checks if the controller implements the protocol
supported by the EFI driver. In the start() function it calls the bind()
function of the EFI driver. In the stop() function it destroys the child
controllers.

The EFI block driver binds to controllers implementing the block io
protocol.

When the bind function of the EFI block driver is called it creates a
new U-Boot block device. It installs child handles for all partitions and
installs the simple file protocol on these.

The read and write functions of the EFI block driver delegate calls to the
controller that it is bound to.

A usage example is as following:

U-Boot loads the iPXE snp.efi executable. iPXE connects an iSCSI drive and
exposes a handle with the block IO protocol. It calls ConnectController.

Now the EFI block driver installs the partitions with the simple file
protocol.

iPXE uses the simple file protocol to load Grub or the Linux Kernel.

Signed-off-by: Heinrich Schuchardt 
---
v4
Use the priv area instead for platdata.
Use calloc() instead of passing a stack address.
Use blk_find_max_devnum() to get next free device number.
v3
Initalize EFI uclass from bootefi command.
Fix typos.
v2
Print to console only in debug mode.
Provide more comments.
Add commit message.
---
  cmd/bootefi.c |   3 +
  drivers/block/blk-uclass.c|   4 +-
  include/blk.h |   1 +
  include/config_fallbacks.h|   1 +
  include/dm/uclass-id.h|   1 +
  include/efi_driver.h  |  30 
  include/efi_loader.h  |   2 +
  lib/Makefile  |   1 +
  lib/efi_driver/Makefile   |  13 ++
  lib/efi_driver/efi_block_device.c | 210 
  lib/efi_driver/efi_uclass.c   | 330 ++
  11 files changed, 595 insertions(+), 1 deletion(-)
  create mode 100644 include/efi_driver.h
  create mode 100644 lib/efi_driver/Makefile
  create mode 100644 lib/efi_driver/efi_block_device.c
  create mode 100644 lib/efi_driver/efi_uclass.c

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index a30259c4c1..51213c0293 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -32,6 +32,9 @@ static void efi_init_obj_list(void)
  {
efi_obj_list_initalized = 1;
  
+	/* Initialize EFI driver uclass */

+   efi_driver_init();
+
efi_console_register();
  #ifdef CONFIG_PARTITIONS
efi_disk_register();
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index 010ed32d3a..bfda2211f0 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -24,6 +24,7 @@ static const char *if_typename_str[IF_TYPE_COUNT] = {
[IF_TYPE_HOST]  = "host",
[IF_TYPE_SYSTEMACE] = "ace",
[IF_TYPE_NVME]  = "nvme",
+   [IF_TYPE_EFI]   = "efi",
  };
  
  static enum uclass_id if_type_uclass_id[IF_TYPE_COUNT] = {

@@ -36,8 +37,9 @@ static enum uclass_id if_type_uclass_id[IF_TYPE_COUNT] = {
[IF_TYPE_SD]= UCLASS_INVALID,
[IF_TYPE_SATA]  = UCLASS_AHCI,
[IF_TYPE_HOST]  = UCLASS_ROOT,
-   [IF_TYPE_NVME]  = UCLASS_NVME,
[IF_TYPE_SYSTEMACE] = UCLASS_INVALID,
+   [IF_TYPE_NVME]  = UCLASS_NVME,
+   [IF_TYPE_EFI]   = UCLASS_EFI,
  };
  
  static enum if_type if_typename_to_iftype(const char *if_typename)

diff --git a/include/blk.h b/include/blk.h
index 41b4d7efa8..69b5a98e56 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -34,6 +34,7 @@ enum if_type {
IF_TYPE_HOST,
IF_TYPE_SYSTEMACE,
IF_TYPE_NVME,
+   IF_TYPE_EFI,
  
  	IF_TYPE_COUNT,			/* Number of interface types */

  };
diff --git a/include/config_fallbacks.h b/include/config_fallbacks.h
index 2c4d43d672..524313d5aa 100644
--- a/include/config_fallbacks.h
+++ b/include/config_fallbacks.h
@@ -52,6 +52,7 @@
defined(CONFIG_MMC) || \
defined(CONFIG_NVME) || \
defined(CONFIG_SYSTEMACE) || \
+   (defined(CONFIG_EFI_LOADER) && !defined(CONFIG_SPL_BUILD)) || \
defined(CONFIG_SANDBOX)
  #define HAVE_BLOCK_DEVICE
  #endif
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 3fc20834ae..07fabc3ce6 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -34,6 +34,7 @@ enum uclass_id {
UCLASS_CROS_EC, /* Chrome OS EC */
UCLASS_DISPLAY, /* Display (e.g. DisplayPort, HDMI) */
UCLASS_DMA, /* Direct Memory Access */
+   UCLASS_EFI, /* EFI managed devices */
UCLASS_ETH,  

Re: [U-Boot] [PATCH] dm: spi: prevent setting a speed of 0 Hz

[Simon Goldschmidt]

On 22.01.2018 07:01, Jagan Teki wrote:

On Thu, Jan 18, 2018 at 1:45 PM, Simon Goldschmidt
 wrote:

When the device tree is missing a correct spi slave description below
the bus, the 'set_speed' callback can be called with 'speed' == 0 Hz.
At least with cadence qspi, this leads to a division by zero.

Prevent this by initializing speed to 100 kHz in this case, as is
done in 'dm_spi_claim_bus'.

Better go-with default baudrate if speed == 0 this what usually does
in remaining drivers.


That's what I did. I set a default value of 100 kHz. The difference 
seems to me that the remaining drivers are host drivers whereas I was 
trying to fix an invalid declaration of a df chip.


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

Re: [U-Boot] [PATCH] dm: spi: prevent setting a speed of 0 Hz

[Simon Goldschmidt]

On 22.01.2018 06:04, Vignesh R wrote:

On Thursday 18 January 2018 01:45 PM, Simon Goldschmidt wrote:

When the device tree is missing a correct spi slave description below
the bus, the 'set_speed' callback can be called with 'speed' == 0 Hz.
At least with cadence qspi, this leads to a division by zero.

Prevent this by initializing speed to 100 kHz in this case, as is
done in 'dm_spi_claim_bus'.


As per doc/device-tree-bindings/spi/spi-bus.txt,
spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz

IMO, the correct fix would be to error out with proper warning, if
spi-max-frequency property is absent in DT.


By now, I think so, too. Fallback to 100.000 Hz really hurts when 
loading a 16 MByte fit image from qspi. A warning is required at least, 
but completely failing might be better indeed...


Regards,
Simon




Signed-off-by: Simon Goldschmidt 
---

  drivers/spi/spi-uclass.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index e06a603ab1..41ecef77db 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -325,6 +325,8 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int 
mode,
if (!speed) {
speed = plat->max_hz;
mode = plat->mode;
+   if (!speed)
+   speed = 10;
}
ret = spi_set_speed_mode(bus, speed, mode);
if (ret)



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

Re: [U-Boot] [PATCH v2] ARM: dts: Freescale: re-license device tree files under GPLv2+/X11

[Tom Rini]

On Mon, Jan 22, 2018 at 10:02:58AM +, Pankaj Bansal wrote:
> 
> > -Original Message-
> > From: Tom Rini [mailto:tr...@konsulko.com]
> > Sent: Friday, January 19, 2018 10:33 PM
> > To: York Sun 
> > Cc: Pankaj Bansal ; u-boot@lists.denx.de;
> > albert.u.b...@aribaud.net; Varun Sethi ; Leo Li
> > ; Priyanka Jain ; Mingkai Hu
> > 
> > Subject: Re: [PATCH v2] ARM: dts: Freescale: re-license device tree files 
> > under
> > GPLv2+/X11
> > 
> > On Fri, Jan 19, 2018 at 05:01:14PM +, York Sun wrote:
> > > On 01/18/2018 06:45 AM, Pankaj Bansal wrote:
> > > >>
> > > >> OK, good.  But there's
> > > >> http://www.denx.de/wiki/view/U-
> > > >> Boot/Patches#Attributing_Code_Copyrights_Sign
> > > >> and you need to say what kernel you're syncing this file against
> > > >> (since there shouldn't be anything U-Boot specific in any of these
> > > >> files) so it's clear for the next person to come along and sync them.
> > Thanks!
> > > >>
> > > >
> > > > I am not syncing the files from linux to u-boot. I am just changing the
> > license similar to commit 13b2ba1a11. There is no functional change in the
> > commit.
> > > >
> > >
> > > Tom,
> > >
> > > This is the case I explained in another email. These dts files are a
> > > subset of the those in Linux. This patch is not syncing with Linux to
> > > get the identical files, but to change the license to GPLv2 and X11.
> > >
> > > We have been maintaining these dts files in U-Boot and they have been
> > > different from Linux from the beginning. If you don't disagree, I tend
> > > to accept this patch for dual licensing.
> > 
> > OK.  While I would encourage use of the same dts in both cases, it's not my
> > maintenance burden here, so if that's how you want to go, that's OK with
> > me.  And so long as only NXP/Freescale/etc people have made changes to the
> > dts/dtsi files, it would be fine for NXP/Freescale/etc to update the license
> > terms.
> 
> Thanks Tom. I have checked in git logs that freescale/nxp employees
> are the only one who have made changes to these dts/dtsi files.
> Can you please merge these changes in mainline ?

I am fine with the change coming in via the regular tree, 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] dm: spi: prevent setting a speed of 0 Hz

[Simon Goldschmidt]

On 22.01.2018 01:29, Simon Glass wrote:

Hi Simon,

On 18 January 2018 at 01:15, Simon Goldschmidt
 wrote:

When the device tree is missing a correct spi slave description below
the bus, the 'set_speed' callback can be called with 'speed' == 0 Hz.
At least with cadence qspi, this leads to a division by zero.

Prevent this by initializing speed to 100 kHz in this case, as is
done in 'dm_spi_claim_bus'.

Signed-off-by: Simon Goldschmidt 
---

  drivers/spi/spi-uclass.c | 2 ++
  1 file changed, 2 insertions(+)


Another option is to have a sensible default when reading from the DT
fails. See spi_slave_ofdata_to_platdata() - you can add the default
there.

Would that work?


This seems like a good idea, but I'm not sure it fixes my 
'divide-by-zero' bug because that bug also triggered if the  subnode of 
my spi controller was missing the compatible field for 'spi-flash'. I'd 
have to check that.


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

Re: [U-Boot] [PATCH V5 00/31] imx: add i.MX8M support and i.MX8MQ EVK

[Diego Dorta]

Hi Peng,

2018-01-10 3:20 GMT-02:00 Peng Fan :
> This patchset is to add i.MX8M and i.MX8MQ-EVK support
>
> V5:
>  Drop wait_mask_set/clr_timeout and switch to use readl_poll_timeout in
>  the patchset.
>
> V4:
>  Regenerate patchset based on Tom's master tree.
>  In this patchset, https://patchwork.ozlabs.org/patch/855027/
>  "arm: imx: Rework i.MX specific commands to be excluded from SPL" from
>  Tom is included to avoid merge conflicts because the i.mx8m change
>  also has some modification to bootaux and arch/arm/mach-imx/Makefile.
>  Because CONFIG_GPT_TIMER change, I did a small modification to apply
>  Tom's patch, no function change.
>
>  Include ATF link in README.
>
> V3:
>  This patchset based on https://patchwork.ozlabs.org/patch/855027/
>  "arm: imx: Rework i.MX specific commands to be excluded from SPL" from
>  Tom to avoid this patchset fail apply after Tom's patch merged.
>
>  Previously "power: pmic/regulator allow dm be omited by SPL" broke other
>  boards, in V3 patchset, only touch pfuze100 related options.
>
>  Sharing code about get mac from fuse between mx7/mx8m
>  Sharing code about bootaux between mx6/7/mx8m
>  Sharing code about cpu speed grade between mx7/mx8m
>  Sharing code about get boot device between mx7/mx8m
>  Sharding code about mmc env between mx7/mx8m
>
>  Introduce wait_mask_set/clr_timeout to avoid deadloop in clock pll 
> configuration
>
>  Correct authorship of fix building warning on fec arm64, patch 27/31.
>
>  Switch to use structure for DDR Controller. For DDR PHY registers,
>  there are about more than 10 thousands registers, I could not convert
>  them with detailed register name, and the script is generated from IC team,
>  So I use regs[0x] arrays here fo easily converting between IC team
>  released script and uboot ddr phy cod.
>
>  Improve REAMME file to include where to download firmware and imx-mkimage
>  and how to build
>
>  Add review tags on the V2 patchset.
>
>  Hope this patchset could catch up next release :)
>
> V2:
>
>  patch 02/23: convert to structure, drop is_boot_from_usb and
>   disconnect_from_usb
>  patch 04/23: conver to use structure for the clock driver, removed the
>   CCM_xxx macros. Add static for local functons.
>   Add init_usdhc_clk, init_uart_clk and etc to not enable
>   them all at default.
>  patch 05/23: Add more commit msg for the sip part.
>  patch 08/23: Merge the spl boot device with i.MX7
>  patch 12/23: Typo fix and return error fix from Heiko for the SoC related 
> part
>  patch 22/23: Use a weak function ddr_init. If patch 23/23 could not be
>   accepted at current stage, to make others still be could be
>   compiled.
>
> The patchset depends on
> https://patchwork.ozlabs.org/patch/841934/
> https://patchwork.ozlabs.org/patch/841958/
> to be tested on real hardware.
>
> V1:
>
> patch: "power: pmic.h: include dm/ofnode.h" and
> "power: pmic/regulator allow dm be omited by SPL" is previously reviewed
> in mailist to not merged. If no issue, you may pick it up.
>
> The board support is a large patch because of the ddr related code.
> If it is not good, please first review/pick-up other patches if they
> are ok.
>
>
>
> Peng Fan (29):
>   imx: add i.MX8M into Kconfig
>   imx: mx8m: add register definition header file
>   imx: mx8m: add pin header file
>   imx: mx8m: add clock driver
>   imx: add sip function
>   imx: boot_mode: add USB_BOOT entry
>   imx: cpu: update cpu file to support i.MX8M
>   imx: spl: implement spl_boot_device for i.MX8M
>   imx: add i.MX8MQ SoC Revision and is_mx8m helper
>   imx: add pad settings bit definition for i.MX8M
>   imx: cpu: move speed/temp to common cpu
>   imx: cpu: add cpu speed/grade for i.MX8M
>   imx: refactor imx_get_mac_from_fuse
>   imx: cleanup bootaux
>   imx: bootaux: support i.MX8M
>   imx: mx7: move get_boot_device to cpu.c
>   imx: cpu: support get_boot_device for i.MX8M
>   imx: mx7: move mmc env code to mmc_env.c
>   imx: mx8m: add soc related settings and files
>   imx: makefile: compile files for i.MX8M
>   misc: ocotp: add i.MX8M support
>   mmc: fsl_esdhc: support i.MX8M
>   imx: lcdif: include i.MX8M
>   gpio: mxc: add i.MX8M support
>   net: fec: do not access reserved register for i.MX8M
>   imx: imx8mq: add dtsi file
>   power: pmic/regulator allow dm be omitted by SPL
>   imx: mx8m: add ddr controller memory map
>   imx: add i.MX8MQ EVK support
>
> Tom Rini (1):
>   arm: imx: Rework i.MX specific commands to be excluded from SPL
>
> Ye Li (1):
>   net: fec: fix build warnings for 64bits support
>

I was able to run your patchset on my board.

For the whole series:

Tested-by: Diego Dorta 

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

Re: [U-Boot] Pull request: u-boot-spi/master

[Tom Rini]

On Mon, Jan 22, 2018 at 11:20:56AM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR.
> 
> thanks!
> Jagan.
> 
> The following changes since commit 98691a60abffb44303d7dae6e9e699d0daded930:
> 
>   Merge git://git.denx.de/u-boot-rockchip (2018-01-09 13:28:51 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-spi.git master
> 
> for you to fetch changes up to b23c685c6f295da3c01dd487f0e003b70299af91:
> 
>   mips: bmips: enable the SPI flash on the Comtrend AR-5387un (2018-01-22 
> 10:39:13 +0530)
> 

NAK:

commit 19e3a4856c1cba751a9ecb3931ff0d96a7f169be
Author: Álvaro Fernández Rojas 
Date:   Sat Jan 20 02:11:34 2018 +0100

wait_bit: add 8/16/32 BE/LE versions of wait_for_bit

Add 8/16/32 bits and BE/LE versions of wait_for_bit.
This is needed for reading registers that are not aligned to 32 bits, and 
for
Big Endian platforms.

Signed-off-by: Álvaro Fernández Rojas 
Reviewed-by: Daniel Schwierzeck 
Reviewed-by: Jagan Teki 

Adds warnings on almost all platforms:
w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
?wait_for_bit_be16?:
w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h:76:31: warning: implicit 
declaration of function ?readw_be? [-Wimplicit-function-declaration]
w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function 
?wait_for_bit_be32?: w+(ls1088ardb_qspi_SECURE_BOOT) 
../include/wait_bit.h:78:31: warning: implicit declaration of function 
?readl_be? [-Wimplicit-function-declaration]

-- 
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 v6 2/2] common: Generic firmware loader for file system

[Marek Vasut]

On 01/22/2018 08:11 AM, Chee, Tien Fong wrote:

[...]

>>> This is last line code of the function, so it's always return the
>>> result regardless error or not.
>> You are rewriting the true error code with -ENODEV instead of
>> propagating it.
>>
> Ohhare you saying to change the codes as shown in below:
> 
> err = usb_stor_scan(1);
> if (err)
> return err;

Right

[...]
> +static int umount_ubifs(void)
> +{
> + return run_command("ubifsumount", 0);
 Just call the function directly ?

>>> There are some checking like ubifs_initialized in the cmd/ubifs.c.
>>> Direct callng the function would bypass those checking.
>> Then factor those out into a function you can all and call that
>> function.
>>
> Just for curious, is it worth to factor those into a function? Does it
> help to boost the performance or for other purpose?

It just makes no sense to involve the whole command machinery if you can
call a function which does exactly the same.

[...]

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 13/15] env: Mark env_get_location as weak

[Tom Rini]

On Mon, Jan 22, 2018 at 01:46:46PM +0100, Maxime Ripard wrote:
> Hi,
> 
> On Sun, Jan 21, 2018 at 05:29:56PM -0700, Simon Glass wrote:
> > > On Wed, Jan 17, 2018 at 03:07:58PM -0700, Simon Glass wrote:
> > >> On 16 January 2018 at 01:16, Maxime Ripard
> > >>  wrote:
> > >> > Allow boards and architectures to override the default environment 
> > >> > lookup
> > >> > code by overriding env_get_location.
> > >> >
> > >> > Reviewed-by: Andre Przywara 
> > >> > Reviewed-by: Lukasz Majewski 
> > >> > Signed-off-by: Maxime Ripard 
> > >> > ---
> > >> >  env/env.c | 20 +++-
> > >> >  1 file changed, 19 insertions(+), 1 deletion(-)
> > >> >
> > >>
> > >> I still don't really understand why this needs to be a weak function.
> > >> If the board knows the priority order, can it not put it into
> > >> global_data? We could have a little u8 array of 4 items with a
> > >> terminator?
> > >
> > > Sure that would be simpler, but that would also prevent us from doing
> > > "smart" things based on data other than just whether the previous
> > > environment is usable. Things based for example on a GPIO state, or a
> > > custom algorithm to transition (or duplicate) the environment.
> > 
> > In that case the board could read the GPIO state, or the algorithm,
> > and then set up the value.
> > 
> > Basically I am saying it could set up the priority order in advance of
> > it being needed, rather than having a callback.
> 
> Aren't we kind of stuck here?
> 
> On the previous iterations, we already discussed this and Tom
> eventually told he was in favour of __weak functions, and the
> discussion stopped there. I assumed you were ok with it.
> 
> I'd really want to move forward on that. This is something that is
> really biting us *now* and I'd hate to miss yet another merge window
> because of debates like this.

Yes, I think this is where we want things to be weak, with a reasonable
default.  If we start to see that "everyone" does the same thing by and
large we can re-evaluate.

-- 
Tom


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

Re: [U-Boot] [PATCH v2 13/15] env: Mark env_get_location as weak

[Maxime Ripard]

Hi,

On Sun, Jan 21, 2018 at 05:29:56PM -0700, Simon Glass wrote:
> > On Wed, Jan 17, 2018 at 03:07:58PM -0700, Simon Glass wrote:
> >> On 16 January 2018 at 01:16, Maxime Ripard
> >>  wrote:
> >> > Allow boards and architectures to override the default environment lookup
> >> > code by overriding env_get_location.
> >> >
> >> > Reviewed-by: Andre Przywara 
> >> > Reviewed-by: Lukasz Majewski 
> >> > Signed-off-by: Maxime Ripard 
> >> > ---
> >> >  env/env.c | 20 +++-
> >> >  1 file changed, 19 insertions(+), 1 deletion(-)
> >> >
> >>
> >> I still don't really understand why this needs to be a weak function.
> >> If the board knows the priority order, can it not put it into
> >> global_data? We could have a little u8 array of 4 items with a
> >> terminator?
> >
> > Sure that would be simpler, but that would also prevent us from doing
> > "smart" things based on data other than just whether the previous
> > environment is usable. Things based for example on a GPIO state, or a
> > custom algorithm to transition (or duplicate) the environment.
> 
> In that case the board could read the GPIO state, or the algorithm,
> and then set up the value.
> 
> Basically I am saying it could set up the priority order in advance of
> it being needed, rather than having a callback.

Aren't we kind of stuck here?

On the previous iterations, we already discussed this and Tom
eventually told he was in favour of __weak functions, and the
discussion stopped there. I assumed you were ok with it.

I'd really want to move forward on that. This is something that is
really biting us *now* and I'd hate to miss yet another merge window
because of debates like this.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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] mmc: Poll for broken card detection case

[Jun Nie]

2018-01-22 13:03 GMT+08:00 Jaehoon Chung :
> Hi,
>
> On 01/02/2018 01:25 PM, Jun Nie wrote:
>> Poll for broken card detection case instead of return
>> no card detected.
>
> Sorry for late. i didn't see this patch in my mailbox.
>
> Does it need to add the new config?

Yes, a new config, CONFIG_MMC_BROKEN_CD is needed for board that does
not support card detection pin. Not sure whether you mean this.
Without this config, the logic is not changed so no board is impacted
by this config.

Jun

>
> Best Regards,
> Jaehoon Chung
>
>>
>> Signed-off-by: Jun Nie 
>> ---
>>  drivers/mmc/Kconfig | 5 +
>>  drivers/mmc/mmc.c   | 4 
>>  2 files changed, 9 insertions(+)
>>
>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>> index 8fbeaa7..ed194a3 100644
>> --- a/drivers/mmc/Kconfig
>> +++ b/drivers/mmc/Kconfig
>> @@ -10,6 +10,11 @@ config MMC
>> If you want MMC/SD/SDIO support, you should say Y here and
>> also to your specific host controller driver.
>>
>> +config MMC_BROKEN_CD
>> + bool "Poll for broken card detection case"
>> + help
>> +   If card  detection feature is broken, just poll to detect.
>> +
>>  config DM_MMC
>>   bool "Enable MMC controllers using Driver Model"
>>   depends on DM
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index 38d2e07..13c5bf5 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -1650,8 +1650,12 @@ int mmc_start_init(struct mmc *mmc)
>>   bool no_card;
>>   int err;
>>
>> +#if !defined(CONFIG_MMC_BROKEN_CD)
>>   /* we pretend there's no card when init is NULL */
>>   no_card = mmc_getcd(mmc) == 0;
>> +#else
>> + no_card = 0;
>> +#endif
>>  #if !CONFIG_IS_ENABLED(DM_MMC)
>>   no_card = no_card || (mmc->cfg->ops->init == NULL);
>>  #endif
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-dm

[Tom Rini]

On Sun, Jan 21, 2018 at 06:09:23PM -0700, Simon Glass wrote:

> Hi Tom.
> 
> The following changes since commit 557767ed29968af0294e3aae48433e5d5a298e0b:
> 
>   Merge git://git.denx.de/u-boot-marvell (2018-01-20 08:39:47 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-dm.git
> 
> for you to fetch changes up to b79221a7d9132fd7bfd81cad9ebdc37acb39f69e:
> 
>   lib: fdtdec: Fix some style violations (2018-01-21 10:01:02 -0700)
> 

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 v6 2/2] common: Generic firmware loader for file system

[Simon Goldschmidt]

On 22.01.2018 09:08, Chee, Tien Fong wrote:

On Thu, 2018-01-18 at 06:57 +0100, Simon Goldschmidt wrote:

On 27.12.2017 06:04, tien.fong.c...@intel.com wrote:

From: Tien Fong Chee 

This is file system generic loader which can be used to load
the file image from the storage into target such as memory.
The consumer driver would then use this loader to program whatever,
ie. the FPGA device.

Signed-off-by: Tien Fong Chee 
---
   common/Makefile|   1 +
   common/fs_loader.c | 309
+
   doc/README.firmware_loader |  76 +++
   include/fs_loader.h|  28 
   4 files changed, 414 insertions(+)
   create mode 100644 common/fs_loader.c
   create mode 100644 doc/README.firmware_loader
   create mode 100644 include/fs_loader.h




+#if defined(CONFIG_SPL_MMC_SUPPORT) && defined(CONFIG_SPL_BUILD)
+static int init_mmc(void)
+{
+   /* Just for the case MMC is not yet initialized */
+   struct mmc *mmc = NULL;
+   int err;
+
+   spl_mmc_find_device(, spl_boot_device());
+
+   err = mmc_init(mmc);
+   if (err) {
+   printf("spl: mmc init failed with error: %d\n",
err);
+   return err;
+   }
+
+   return err;
+}

I see two problems here: First, you're ignoring the return value of
spl_mmc_find_device() and initialize 'mmc' to NULL instead. Wouldn't
it
be better to let 'mmc' be uninitialized and return the error code
returned by spl_mmc_find_device() if there is one?


Yeah, you are right, i should add the check on the return value. I
think that would better to initialize NULL to mmc, because there is no
checking on the mmc in spl_mmc_find_device(), so that is possible
memory access violation/abort can be happended if unknown value in mmc
pointer.


Second, using spl_boot_device() would prevent making the loader work
on
mach-socfpga when spl is not loaded from mmc, right?

E.g. for the case I'm currently trying to fix (boot from qspi), this
loader would not work although there's technically no reason since
the
platform only has one mmc. The call to spl_boot_device() could be
replaced by the exact value here for platforms that only have one
mmc. I
don't know how to fix that, though.


The main purpose here is to initialize the mmc driver. So which storage
user wants to load the file is totally depend what storage such as mmc
user defines in location->name. Loader would init the storage based on
the storage defined in location->name before accessing it. Since the
loader only support file system at this moment, i would suggest FAT fs
for mmc and ubi fs for qspi.


What I meant to say is this: at least on mach-socfpga, from reading the 
code, I cannot load a file from mmc when booting from qspi, as 
'spl_boot_device' returns 'BOOT_DEVICE_SPI' in that case, although I 
need to pass 'BOOT_DEVICE_MMC1' to 'spl_mmc_find_device'. Or am I wrong 
here?


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

Re: [U-Boot] [PATCH 1/2] sunxi: fix i2c support for sunxi H3/H5

[Nuno Gonçalves]

On Fri, Jan 19, 2018 at 9:35 PM, Jernej Škrabec  wrote:
> Hi,
>
> Dne petek, 19. januar 2018 ob 19:38:52 CET je Nuno Gonçalves napisal(a):
>> Sorry, there is only 1 patch in this series.
>>
>> I would like comments regarding removing DM_I2C for MACH_SUNXI_H3_H5,
>> as I didn't found a reason for it to be defined.
>
> there is good reason to be there. When H3/H5 board has DE2/HDMI enabled,
> warning is shown when configuring, if DM_I2C is not selected. Since there
> should be no warning, DM_I2C has to stay.
>
> This means that whatever you want to have attached to I2C, you have to have an
> entry in DT for it. Since there is no DM pinctrl driver, you have to put code
> somewhere, like you already done.
>
> Besides, U-Boot wants to migrate towards DM drivers, no other way around. Last
> time I checked, DM I2C driver for H3/H5 should work, although it wasn't
> thoroughly tested from my side. So if there are issues with DM I2C driver, you
> have to fix it.
>
> Best regards,
> Jernej
>

Thanks Jernej. In fact I didn't manage to get it working with DM_I2C,
even after adding the devices to the DT.

Maybe you can give me some hints to bring it to work, as I am a uboot ousider.

Is DM_I2C_COMPAT supposed to be defined?

The i2c device should be in the DT but since there is no pinctrl
driver I must also include the  "sunxi_gpio_set_cfgpin()" already in
my patch?

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

Re: [U-Boot] [PATCH] sunxi: Add support for the Beelink-x2 STB

[Code Kipper]

On 22 January 2018 at 09:04, Maxime Ripard
 wrote:
> Hi,
>
> On Sun, Jan 21, 2018 at 07:06:49PM +0100, codekip...@gmail.com wrote:
>> From: Marcus Cooper 
>>
>> The Beelink X2 is an STB based on the Allwinner H3 SoC with a uSD slot,
>> 2 USB ports( 1 * USB-2 Host, 1 USB OTG), a 10/100M ethernet port using
>> the SoC's integrated PHY, Wifi via an sdio wifi chip, HDMI, a dual
>> colour LED, an IR receiver and an optical S/PDIF connector.
>>
>> Signed-off-by: Marcus Cooper 
>> ---
>>  arch/arm/dts/Makefile|   1 +
>>  arch/arm/dts/sun8i-h3-beelink-x2.dts | 155 
>> +++
>>  board/sunxi/MAINTAINERS  |   5 ++
>>  configs/beelink_x2_defconfig |  18 
>>  4 files changed, 179 insertions(+)
>>  create mode 100644 arch/arm/dts/sun8i-h3-beelink-x2.dts
>>  create mode 100644 configs/beelink_x2_defconfig
>>
>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>> index 9540ba4313..f899cef7ac 100644
>> --- a/arch/arm/dts/Makefile
>> +++ b/arch/arm/dts/Makefile
>> @@ -335,6 +335,7 @@ dtb-$(CONFIG_MACH_SUN8I_A83T) += \
>>  dtb-$(CONFIG_MACH_SUN8I_H3) += \
>>   sun8i-h2-plus-orangepi-zero.dtb \
>>   sun8i-h3-bananapi-m2-plus.dtb \
>> + sun8i-h3-beelink-x2.dtb \
>>   sun8i-h3-libretech-all-h3-cc.dtb \
>>   sun8i-h3-orangepi-2.dtb \
>>   sun8i-h3-orangepi-lite.dtb \
>> diff --git a/arch/arm/dts/sun8i-h3-beelink-x2.dts 
>> b/arch/arm/dts/sun8i-h3-beelink-x2.dts
>> new file mode 100644
>> index 00..43f67eb8db
>> --- /dev/null
>> +++ b/arch/arm/dts/sun8i-h3-beelink-x2.dts
>> @@ -0,0 +1,155 @@
>> +/*
>> + * Copyright (C) 2017 Marcus Cooper 
>> + *
>> + * 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 file 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 file 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/;
>> +#include "sun8i-h3.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include 
>> +#include 
>> +
>> +/ {
>> + model = "Beelink X2";
>> + compatible = "roofull,beelink-x2", "allwinner,sun8i-h3";
>> +
>> + aliases {
>> + serial0 = 
>> + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
>> + ethernet1 = 
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> +
>> + blue {
>> + label = "beelink-x2:blue:pwr";
>> + gpios = <_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
>> + default-state = "on";
>> + };
>> +
>> + red {
>> + label = "beelink-x2:red:standby";
>> + gpios = < 0 15 GPIO_ACTIVE_HIGH>; /* PA15 */
>> + };
>> + };
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-simple";
>> + reset-gpios = <_pio 0 7 GPIO_ACTIVE_LOW>; /* PL7 */
>> + };
>> +};
>> +
>> 

[U-Boot] [PATCH v2] arm: add support for PDU001

[Felix Brack]

This patch adds support for the PDU001 board.

Signed-off-by: Felix Brack 
---

Changes in v2:
- use DT to configure the board
- use new single-register pin controller
- use new TPS65910 PMIC driver
- eliminate the need of CONFIG_DM_I2C_COMPAT, i.e. use DM for i2c
- clarify the function of the 'Run LED'
- fix ordering of include files
- replace deprecated SPDX license identifiers

 arch/arm/Kconfig   |   1 +
 arch/arm/dts/Makefile  |   3 +-
 arch/arm/dts/am335x-pdu001.dts | 612 +
 arch/arm/mach-omap2/am33xx/Kconfig |   9 +
 board/eets/pdu001/Kconfig  |  66 
 board/eets/pdu001/MAINTAINERS  |   6 +
 board/eets/pdu001/Makefile |  13 +
 board/eets/pdu001/README   |  35 +++
 board/eets/pdu001/board.c  | 276 +
 board/eets/pdu001/board.h  |  38 +++
 board/eets/pdu001/mux.c| 120 
 configs/am335x_pdu001_defconfig|  55 
 include/configs/pdu001.h   |  87 ++
 13 files changed, 1320 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/am335x-pdu001.dts
 create mode 100644 board/eets/pdu001/Kconfig
 create mode 100644 board/eets/pdu001/MAINTAINERS
 create mode 100644 board/eets/pdu001/Makefile
 create mode 100644 board/eets/pdu001/README
 create mode 100644 board/eets/pdu001/board.c
 create mode 100644 board/eets/pdu001/board.h
 create mode 100644 board/eets/pdu001/mux.c
 create mode 100644 configs/am335x_pdu001_defconfig
 create mode 100644 include/configs/pdu001.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f6d57f5..15349b3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1339,6 +1339,7 @@ source "board/vscom/baltos/Kconfig"
 source "board/woodburn/Kconfig"
 source "board/work-microwave/work_92105/Kconfig"
 source "board/zipitz2/Kconfig"
+source "board/eets/pdu001/Kconfig"
 
 source "arch/arm/Kconfig.debug"
 
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9540ba4..02b3c36 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -161,7 +161,8 @@ dtb-$(CONFIG_AM33XX) += am335x-boneblack.dtb 
am335x-bone.dtb \
am335x-bonegreen.dtb \
am335x-icev2.dtb \
am335x-pxm50.dtb \
-   am335x-rut.dtb
+   am335x-rut.dtb \
+   am335x-pdu001.dtb
 dtb-$(CONFIG_AM43XX) += am437x-gp-evm.dtb am437x-sk-evm.dtb\
am43x-epos-evm.dtb \
am437x-idk-evm.dtb
diff --git a/arch/arm/dts/am335x-pdu001.dts b/arch/arm/dts/am335x-pdu001.dts
new file mode 100644
index 000..0967e82
--- /dev/null
+++ b/arch/arm/dts/am335x-pdu001.dts
@@ -0,0 +1,612 @@
+/*
+ * pdu001.dts
+ *
+ * EETS GmbH PDU001 board device tree file
+ *
+ * Copyright (C) 2018 EETS GmbH - http://www.eets.ch/
+ *
+ * Copyright (C) 2011, Texas Instruments, Incorporated - http://www.ti.com/
+ *
+ * SPDX-License-Identifier:  GPL-2.0-or-later
+ */
+
+/dts-v1/;
+
+#include "am33xx.dtsi"
+#include 
+#include 
+
+/ {
+   model = "EETS,PDU001";
+   compatible = "eets,pdu001", "ti,am33xx";
+
+   chosen {
+   stdout-path = 
+   };
+
+   cpus {
+   cpu@0 {
+   cpu0-supply = <_reg>;
+   };
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256 MB */
+   };
+
+   vbat: fixedregulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vbat";
+   regulator-min-microvolt = <360>;
+   regulator-max-microvolt = <360>;
+   regulator-boot-on;
+   };
+
+   lis3_reg: fixedregulator@1 {
+   compatible = "regulator-fixed";
+   regulator-name = "lis3_reg";
+   regulator-boot-on;
+   };
+
+   panel {
+   compatible = "ti,tilcdc,panel";
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_s0>;
+   panel-info {
+   ac-bias   = <255>;
+   ac-bias-intrpt= <0>;
+   dma-burst-sz  = <16>;
+   bpp   = <16>;
+   fdd   = <0x80>;
+   sync-edge = <0>;
+   sync-ctrl = <1>;
+   raster-order  = <0>;
+   fifo-th   = <0>;
+   };
+
+   display-timings {
+   240x320p16 {
+   clock-frequency = <650>;
+   hactive = <240>;
+   vactive = <320>;
+   hfront-porch = <6>;
+   hback-porch = <6>;
+   hsync-len = <1>;
+   vback-porch = <6>;
+   vfront-porch = <6>;
+  

Re: [U-Boot] [RFC PATCH] mmc: Skipping the MMC initialization at the boot time

[Siva Durga Prasad Paladugu]

Hi Jaehoon,

> -Original Message-
> From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
> Sent: Thursday, January 18, 2018 1:46 PM
> To: Siva Durga Prasad Paladugu ; u-
> b...@lists.denx.de
> Cc: Vipul Kumar ; Vipul Kumar ;
> Siva Durga Prasad Paladugu 
> Subject: Re: [RFC PATCH] mmc: Skipping the MMC initialization at the boot
> time
> 
> On 01/18/2018 02:40 PM, Siva Durga Prasad Paladugu wrote:
> > From: Vipul Kumar 
> >
> > By enabling CONFIG_SKIP_EARLY_MMC_INIT config, user can skip the
> MMC
> > initialization at the boot time. After getting the u-boot console,
> > user can select the device using mmc dev and can communicate with that.
> > This is useful where user don't want to perform mmc initialization
> > while booting and can do explicitly later as per choice.
> 
> Is there any use-case? What benefit can user have with this config?
> According to commit-msg, user will choose the mmc device later.
> Is it same with initializing at booting time?
Yes, there may be case, where we have both controllers enabled but user would 
like to
Communicate with only one at u-boot and this selection also depends on 
environment
Or something which will be updated from external world then in this case, user 
will initialize
Later as per his wish. This may save bootime as it initializes only the 
required one and choice of 
which one to initialize

Thanks,
Siva

> 
> >
> > Signed-off-by: Vipul Kumar 
> > Signed-off-by: Siva Durga Prasad Paladugu 
> > ---
> >  common/board_r.c| 4 ++--
> >  drivers/mmc/Kconfig | 7 +++
> >  2 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/common/board_r.c b/common/board_r.c index
> > 2a9df6b..8727b93 100644
> > --- a/common/board_r.c
> > +++ b/common/board_r.c
> > @@ -421,7 +421,7 @@ static int initr_onenand(void)  }  #endif
> >
> > -#ifdef CONFIG_MMC
> > +#if defined(CONFIG_MMC) &&
> !defined(CONFIG_SKIP_EARLY_MMC_INIT)
> >  static int initr_mmc(void)
> >  {
> > puts("MMC:   ");
> > @@ -768,7 +768,7 @@ static init_fnc_t init_sequence_r[] = {  #ifdef
> > CONFIG_CMD_ONENAND
> > initr_onenand,
> >  #endif
> > -#ifdef CONFIG_MMC
> > +#if defined(CONFIG_MMC) &&
> !defined(CONFIG_SKIP_EARLY_MMC_INIT)
> > initr_mmc,
> >  #endif
> > initr_env,
> > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index
> > ab0627a..05b1503 100644
> > --- a/drivers/mmc/Kconfig
> > +++ b/drivers/mmc/Kconfig
> > @@ -40,6 +40,13 @@ config SPL_DM_MMC
> >
> >  if MMC
> >
> > +config SKIP_EARLY_MMC_INIT
> > +   bool "Skip the MMC initialization at boot time"
> > +   help
> > + Skip the MMC initialization at the boot time. After getting the u-
> boot
> > + console, user need to set mmc device and after setting the mmc
> dev, user
> > + can communicate with that device.
> > +
> >  config ARM_PL180_MMCI
> > bool "ARM AMBA Multimedia Card Interface and compatible
> support"
> > depends on DM_MMC && OF_CONTROL
> > --
> > 2.7.4
> >
> > This email and any attachments are intended for the sole use of the
> named recipient(s) and contain(s) confidential information that may be
> proprietary, privileged or copyrighted under applicable law. If you are not
> the intended recipient, do not read, copy, or forward this email message or
> any attachments. Delete this email message and any attachments
> immediately.
> >
> >
> >

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

Re: [U-Boot] [PATCH v2] ARM: dts: Freescale: re-license device tree files under GPLv2+/X11

[Pankaj Bansal]

> -Original Message-
> From: Tom Rini [mailto:tr...@konsulko.com]
> Sent: Friday, January 19, 2018 10:33 PM
> To: York Sun 
> Cc: Pankaj Bansal ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; Varun Sethi ; Leo Li
> ; Priyanka Jain ; Mingkai Hu
> 
> Subject: Re: [PATCH v2] ARM: dts: Freescale: re-license device tree files 
> under
> GPLv2+/X11
> 
> On Fri, Jan 19, 2018 at 05:01:14PM +, York Sun wrote:
> > On 01/18/2018 06:45 AM, Pankaj Bansal wrote:
> > >>
> > >> OK, good.  But there's
> > >> http://www.denx.de/wiki/view/U-
> > >> Boot/Patches#Attributing_Code_Copyrights_Sign
> > >> and you need to say what kernel you're syncing this file against
> > >> (since there shouldn't be anything U-Boot specific in any of these
> > >> files) so it's clear for the next person to come along and sync them.
> Thanks!
> > >>
> > >
> > > I am not syncing the files from linux to u-boot. I am just changing the
> license similar to commit 13b2ba1a11. There is no functional change in the
> commit.
> > >
> >
> > Tom,
> >
> > This is the case I explained in another email. These dts files are a
> > subset of the those in Linux. This patch is not syncing with Linux to
> > get the identical files, but to change the license to GPLv2 and X11.
> >
> > We have been maintaining these dts files in U-Boot and they have been
> > different from Linux from the beginning. If you don't disagree, I tend
> > to accept this patch for dual licensing.
> 
> OK.  While I would encourage use of the same dts in both cases, it's not my
> maintenance burden here, so if that's how you want to go, that's OK with
> me.  And so long as only NXP/Freescale/etc people have made changes to the
> dts/dtsi files, it would be fine for NXP/Freescale/etc to update the license
> terms.

Thanks Tom. I have checked in git logs that freescale/nxp employees are the 
only one who have made changes to these dts/dtsi files.
Can you please merge these changes in mainline ?

Thanks & Regards,
Pankaj Bansal

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

Re: [U-Boot] [PATCH v4] spi: kirkwood_spi: implement workaround for FE-9144572

[Jagan Teki]

On Mon, Jan 22, 2018 at 3:14 PM, Chris Packham  wrote:
> Erratum NO. FE-9144572: The device SPI interface supports frequencies of
> up to 50 MHz.  However, due to this erratum, when the device core clock
> is 250 MHz and the SPI interfaces is configured for 50MHz SPI clock and
> CPOL=CPHA=1 there might occur data corruption on reads from the SPI
> device.
>
> Implement the workaround by setting the TMISO_SAMPLE value to 0x2
> in the timing1 register.
>
> Signed-off-by: Chris Packham 
> Reviewed-by: Stefan Roese 
> Reviewed-by: Jagan Teki 
> ---

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

[U-Boot] [PATCH v4] spi: kirkwood_spi: implement workaround for FE-9144572

[Chris Packham]

Erratum NO. FE-9144572: The device SPI interface supports frequencies of
up to 50 MHz.  However, due to this erratum, when the device core clock
is 250 MHz and the SPI interfaces is configured for 50MHz SPI clock and
CPOL=CPHA=1 there might occur data corruption on reads from the SPI
device.

Implement the workaround by setting the TMISO_SAMPLE value to 0x2
in the timing1 register.

Signed-off-by: Chris Packham 
Reviewed-by: Stefan Roese 
Reviewed-by: Jagan Teki 
---
I've based this as much as I can on the equivalent implementation in the
Linux kernel[1], but there are differences in the u-boot spi
infrastructure that means I can't be as specific when qualifying whether
the workaround is needed.

[1] - 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi-orion.c#n248

Changes in v4:
- move comment to function to match equivalent linux code
- collect review from Jagan

Changes in v3:
- initialise drv_data for Armada XP and 375

Changes in v2:
- collect reviewed-by from Stefan
- remove mvebu_spi_type
- describe errata above mvebu_spi_50mhz_ac_timing_erratum

 arch/arm/include/asm/arch-mvebu/spi.h |  6 +++
 drivers/spi/kirkwood_spi.c| 69 +--
 2 files changed, 72 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/arch-mvebu/spi.h 
b/arch/arm/include/asm/arch-mvebu/spi.h
index 3545aed17347..1de510ea6da9 100644
--- a/arch/arm/include/asm/arch-mvebu/spi.h
+++ b/arch/arm/include/asm/arch-mvebu/spi.h
@@ -57,6 +57,12 @@ struct kwspi_registers {
 #define KWSPI_TXLSBF   (1 << 13)
 #define KWSPI_RXLSBF   (1 << 14)
 
+/* Timing Parameters 1 Register */
+#define KW_SPI_TMISO_SAMPLE_OFFSET 6
+#define KW_SPI_TMISO_SAMPLE_MASK   (0x3 << KW_SPI_TMISO_SAMPLE_OFFSET)
+#define KW_SPI_TMISO_SAMPLE_1  (1 << KW_SPI_TMISO_SAMPLE_OFFSET)
+#define KW_SPI_TMISO_SAMPLE_2  (2 << KW_SPI_TMISO_SAMPLE_OFFSET)
+
 #define KWSPI_IRQUNMASK1 /* unmask SPI interrupt */
 #define KWSPI_IRQMASK  0 /* mask SPI interrupt */
 #define KWSPI_SMEMRDIRQ1 /* SerMem data xfer ready irq */
diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
index 0c6bd295cde9..1ad8cdee6491 100644
--- a/drivers/spi/kirkwood_spi.c
+++ b/drivers/spi/kirkwood_spi.c
@@ -243,6 +243,10 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
 
 /* Here now the DM part */
 
+struct mvebu_spi_dev {
+   boolis_errata_50mhz_ac;
+};
+
 struct mvebu_spi_platdata {
struct kwspi_registers *spireg;
 };
@@ -269,10 +273,44 @@ static int mvebu_spi_set_speed(struct udevice *bus, uint 
hz)
return 0;
 }
 
+static void mvebu_spi_50mhz_ac_timing_erratum(struct udevice *bus, uint mode)
+{
+   struct mvebu_spi_platdata *plat = dev_get_platdata(bus);
+   struct kwspi_registers *reg = plat->spireg;
+   u32 data;
+
+   /*
+* Erratum description: (Erratum NO. FE-9144572) The device
+* SPI interface supports frequencies of up to 50 MHz.
+* However, due to this erratum, when the device core clock is
+* 250 MHz and the SPI interfaces is configured for 50MHz SPI
+* clock and CPOL=CPHA=1 there might occur data corruption on
+* reads from the SPI device.
+* Erratum Workaround:
+* Work in one of the following configurations:
+* 1. Set CPOL=CPHA=0 in "SPI Interface Configuration
+* Register".
+* 2. Set TMISO_SAMPLE value to 0x2 in "SPI Timing Parameters 1
+* Register" before setting the interface.
+*/
+   data = readl(>timing1);
+   data &= ~KW_SPI_TMISO_SAMPLE_MASK;
+
+   if (CONFIG_SYS_TCLK == 25000 &&
+   mode & SPI_CPOL &&
+   mode & SPI_CPHA)
+   data |= KW_SPI_TMISO_SAMPLE_2;
+   else
+   data |= KW_SPI_TMISO_SAMPLE_1;
+
+   writel(data, >timing1);
+}
+
 static int mvebu_spi_set_mode(struct udevice *bus, uint mode)
 {
struct mvebu_spi_platdata *plat = dev_get_platdata(bus);
struct kwspi_registers *reg = plat->spireg;
+   const struct mvebu_spi_dev *drvdata;
u32 data = readl(>cfg);
 
data &= ~(KWSPI_CPHA | KWSPI_CPOL | KWSPI_RXLSBF | KWSPI_TXLSBF);
@@ -286,6 +324,10 @@ static int mvebu_spi_set_mode(struct udevice *bus, uint 
mode)
 
writel(data, >cfg);
 
+   drvdata = (struct mvebu_spi_dev *)dev_get_driver_data(bus);
+   if (drvdata->is_errata_50mhz_ac)
+   mvebu_spi_50mhz_ac_timing_erratum(bus, mode);
+
return 0;
 }
 
@@ -343,10 +385,31 @@ static const struct dm_spi_ops mvebu_spi_ops = {
 */
 };
 
+static const struct mvebu_spi_dev armada_xp_spi_dev_data = {
+   .is_errata_50mhz_ac = false,
+};
+
+static const struct mvebu_spi_dev armada_375_spi_dev_data = {
+   .is_errata_50mhz_ac = false,
+};
+
+static const struct mvebu_spi_dev 

Re: [U-Boot] UDP packet sender

[Gaëtan Carlier]

Hi,
On 01/18/2018 11:56 AM, Gaëtan Carlier wrote:
> Hi,
> I would like to implement a new command and submit it to the mailing list.
> The command will have the following format:
> udpsend send>
> 
> udpsend 255.255.255.255 4040 0 hello world
> 
> If source port is 0, a random port will be used (11000 + (get_timer(0) % 
> 4096))
> 
> Where do I have to place my code : cmd or net directory ?
> For me cmd will be the better directory to keep it away from all more complex 
> stuff like DHCP, TFTP, ...
> 
> Thank you for these informations.
> Regards,
> Gaëtan.
> 

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

Re: [U-Boot] [PATCH 1/2] serial: mxc: support DTE mode

[Ryan Harkin]

Hi Simon,

On 22 January 2018 at 00:29, Simon Glass  wrote:

> Hi Ryan,
>
> On 19 January 2018 at 06:21, Ryan Harkin  wrote:
> > Hi Stefan,
> >
> > Thanks for looking so quickly.
> >
> > On 19 January 2018 at 12:23, Stefan Agner 
> wrote:
> >>
> >> Hi Ryan,
> >>
> >>
> >> On 19.01.2018 10:53, Ryan Harkin wrote:
> >> > Add DTE mode support via Kconfig on the MXC uart.
> >>
> >> Make use of the driver model, there DTE is supported already today:
> >> https://lists.denx.de/pipermail/u-boot/2016-July/259573.html
> >
> >
> > My change would be useful for other non-DM users of serial_mxc.c, of
> course.
> > Not just WaRP7.
> >
> > I don't have any objection to WaRP7 moving to DM, although that isn't my
> > call, but moving using the driver model is not a straight-forward
> change, is
> > it? WaRP7 today doesn't use it.
>
> We are planning to require that board use CONFIG_BLK fairly soon, and
> that likely means conversion to device tree I don't think it makes
> sense to accept patches like this. If the board can be converted, then
> let's do it!
>

I'm not the maintainer of this board. I'm only making this patch so I can
put it into our test farm. But I'm interested in giving it a go. In fact, I
started already after Stefan's email. And bricked my board :-)


> >
> > Do you have an example of a board using this driver that switched using
> the
> > driver model? I'd like to see the scale of the changes needed.
>
> It probably requires:
>
> - Adding a DT (with u-boot,dm-pre-reloc as needed)
>

I take it we add the DT from the upstream linux kernel? The upstream DT
doesn't define UART6, the one I want to use. I have a patch for the kernel
that I have not attempted to send upstream yet.

What approach should I take?
- upstream my patch to the kernel first
- use the DT from upstream kernel as-is and add a separate patch in the
u-boot tree
- use the DT from upstream kernel as-is and squash in my patch

Or something else?

Updating the DT from upstream will possibly mean updating the DTs for all
other iMX7 boards [1], because the include/dt-bindings stuff has changed
slightly, as well as the imx7s.dtsi file. I have no way of testing the
other boards, but I guess their maintainers can help there.


- Checking that stdio-path is correct
>

That's probably what bricked my board...

Cheers,
Ryan.

[1] There only appear to be two iMX7 board in u-boot already:
arch/arm/dts/imx7d.dtsi:44:#include "imx7s.dtsi"
arch/arm/dts/imx7-colibri.dts:9:#include "imx7d.dtsi"
arch/arm/dts/imx7d-sdb.dts:9:#include "imx7d.dtsi"



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

Re: [U-Boot] [PATCH] sunxi: Add support for the Beelink-x2 STB

[Maxime Ripard]

On Mon, Jan 22, 2018 at 09:20:06AM +0100, Code Kipper wrote:
> On 22 January 2018 at 09:04, Maxime Ripard
>  wrote:
> > Hi,
> >
> > On Sun, Jan 21, 2018 at 07:06:49PM +0100, codekip...@gmail.com wrote:
> >> From: Marcus Cooper 
> >>
> >> The Beelink X2 is an STB based on the Allwinner H3 SoC with a uSD slot,
> >> 2 USB ports( 1 * USB-2 Host, 1 USB OTG), a 10/100M ethernet port using
> >> the SoC's integrated PHY, Wifi via an sdio wifi chip, HDMI, a dual
> >> colour LED, an IR receiver and an optical S/PDIF connector.
> >>
> >> Signed-off-by: Marcus Cooper 
> >> ---
> >>  arch/arm/dts/Makefile|   1 +
> >>  arch/arm/dts/sun8i-h3-beelink-x2.dts | 155 
> >> +++
> >>  board/sunxi/MAINTAINERS  |   5 ++
> >>  configs/beelink_x2_defconfig |  18 
> >>  4 files changed, 179 insertions(+)
> >>  create mode 100644 arch/arm/dts/sun8i-h3-beelink-x2.dts
> >>  create mode 100644 configs/beelink_x2_defconfig
> >>
> >> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> >> index 9540ba4313..f899cef7ac 100644
> >> --- a/arch/arm/dts/Makefile
> >> +++ b/arch/arm/dts/Makefile
> >> @@ -335,6 +335,7 @@ dtb-$(CONFIG_MACH_SUN8I_A83T) += \
> >>  dtb-$(CONFIG_MACH_SUN8I_H3) += \
> >>   sun8i-h2-plus-orangepi-zero.dtb \
> >>   sun8i-h3-bananapi-m2-plus.dtb \
> >> + sun8i-h3-beelink-x2.dtb \
> >>   sun8i-h3-libretech-all-h3-cc.dtb \
> >>   sun8i-h3-orangepi-2.dtb \
> >>   sun8i-h3-orangepi-lite.dtb \
> >> diff --git a/arch/arm/dts/sun8i-h3-beelink-x2.dts 
> >> b/arch/arm/dts/sun8i-h3-beelink-x2.dts
> >> new file mode 100644
> >> index 00..43f67eb8db
> >> --- /dev/null
> >> +++ b/arch/arm/dts/sun8i-h3-beelink-x2.dts
> >> @@ -0,0 +1,155 @@
> >> +/*
> >> + * Copyright (C) 2017 Marcus Cooper 
> >> + *
> >> + * 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 file 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 file 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/;
> >> +#include "sun8i-h3.dtsi"
> >> +#include "sunxi-common-regulators.dtsi"
> >> +
> >> +#include 
> >> +#include 
> >> +
> >> +/ {
> >> + model = "Beelink X2";
> >> + compatible = "roofull,beelink-x2", "allwinner,sun8i-h3";
> >> +
> >> + aliases {
> >> + serial0 = 
> >> + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
> >> + ethernet1 = 
> >> + };
> >> +
> >> + chosen {
> >> + stdout-path = "serial0:115200n8";
> >> + };
> >> +
> >> + leds {
> >> + compatible = "gpio-leds";
> >> +
> >> + blue {
> >> + label = "beelink-x2:blue:pwr";
> >> + gpios = <_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
> >> + default-state = "on";
> >> + };
> >> +
> >> + red {
> >> + label = 

Re: [U-Boot] [PATCH] tools/mrvl_uart.sh: Tidy script output

[Stefan Roese]

On 20.01.2018 13:18, Andreas Färber wrote:

Fix a typo in help output (awailable -> available).
Tidy the grammar - not the board connects to a port, we do.

While at it, be consistent in upper-casing the comments.

Fixes: eee4835d22 ("tools: Add Marvell recovery image download script")
Cc: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Igal Liberman 
Signed-off-by: Andreas Färber 
---
  tools/mrvl_uart.sh | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/mrvl_uart.sh b/tools/mrvl_uart.sh
index 500fa117eb..6824208902 100755
--- a/tools/mrvl_uart.sh
+++ b/tools/mrvl_uart.sh
@@ -46,13 +46,13 @@ then
  echo -e "\nMarvell recovery image downloader for Armada SoC family."
  echo -e "Command syntax:"
  echo -e "\t$(basename $0)   [2|4|8]"
-echo -e "\tport  - serial port the target board connected to"
+echo -e "\tport  - serial port the target board is connected to"
  echo -e "\tfile  - recovery boot image for target download"
  echo -e "\t2|4|8 - times to increase the default serial port speed by"
  echo -e "For example - load the image over ttyUSB0 @ 460800 baud:"
  echo -e "$(basename $0) /dev/ttyUSB0 /tmp/flash-image.bin 4\n"
  echo -e "=WARNING="
-echo -e "- The speed-up option is not awailable in SoC families prior to 
A8K+"
+echo -e "- The speed-up option is not available in SoC families prior to 
A8K+"
  echo -e "- This utility is not compatible with Armada 37xx SoC family\n"
  fi
  
@@ -111,7 +111,7 @@ stty -F $port raw ignbrk time 5 $fast_baudrate

  sx -vv $file > $port < $port
  #sx-at91 $port $file
  
-# return the port to the default speed

+# Return the port to the default speed
  stty -F $port raw ignbrk time 5 $default_baudrate
  
  # Optional - fire up Minicom




Reviewed-by: Stefan Roese 

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

Re: [U-Boot] [PATCH] tools/mrvl_uart.sh: Fix minicom baudrate

[Stefan Roese]

On 20.01.2018 13:07, Andreas Färber wrote:

minicom doesn't inherit the baudrate from stty but uses its own
defaults, such as for example 57600, whereas we expect 115200 here.
Explicitly tell minicom which baudrate to use.

Fixes: eee4835d22 ("tools: Add Marvell recovery image download script")
Cc: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Igal Liberman 
Signed-off-by: Andreas Färber 
---
  tools/mrvl_uart.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/mrvl_uart.sh b/tools/mrvl_uart.sh
index 6b04d7ae2c..500fa117eb 100755
--- a/tools/mrvl_uart.sh
+++ b/tools/mrvl_uart.sh
@@ -115,5 +115,5 @@ sx -vv $file > $port < $port
  stty -F $port raw ignbrk time 5 $default_baudrate
  
  # Optional - fire up Minicom

-minicom -D $port
+minicom -D $port -b $default_baudrate
  



Reviewed-by: Stefan Roese 

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

Re: [U-Boot] [PATCH v6 2/2] common: Generic firmware loader for file system

[Lothar Waßmann]

Hi,

On Mon, 22 Jan 2018 07:11:37 + Chee, Tien Fong wrote:
> On Thu, 2018-01-18 at 12:12 +0100, Marek Vasut wrote:
> > On 01/18/2018 05:33 AM, Chee, Tien Fong wrote:
> > > 
> > > On Tue, 2018-01-16 at 15:41 +0100, Marek Vasut wrote:
> > > > 
> > > > On 12/27/2017 06:04 AM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > Whoa, this improved substantially since last time I checked.
> > > > Minor
> > > > nitpicks below.
> > > > 
> > > > [...]
> > > > 
> > > > > 
> > > > > 
> > > > > +/* USB build is not supported yet in SPL */
> > > > > +#ifndef CONFIG_SPL_BUILD
> > > > > +#ifdef CONFIG_USB_STORAGE
> > > > > +static int init_usb(void)
> > > > > +{
> > > > > + int err;
> > > > > +
> > > > > + err = usb_init();
> > > > > + if (err)
> > > > > + return err;
> > > > > +
> > > > > +#ifndef CONFIG_DM_USB
> > > > > + err = usb_stor_scan(1) < 0 ? -ENODEV : 0;
> > > > if (err)
> > > > return err;
> > > > ?
> > > > 
> > > This is last line code of the function, so it's always return the
> > > result regardless error or not.
> > You are rewriting the true error code with -ENODEV instead of
> > propagating it.
> > 
> Ohhare you saying to change the codes as shown in below:
> 
> err = usb_stor_scan(1);
> if (err)
> return err;
> 
usb_stor_scan() does not return a sensible error code, but '-1' if no
device was found. This should be changed to -ENODEV then!


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

Re: [U-Boot] [PATCH v3 2/2] Enable test case with A20-OLinuXino-Lime2

[Jagan Teki]

On Tue, Jan 2, 2018 at 4:31 PM, Stefan Mavrodiev
 wrote:
> On 12/26/2017 11:47 AM, Jagan Teki wrote:
>>
>> On Fri, Dec 22, 2017 at 3:30 PM, Stefan Mavrodiev 
>> wrote:
>>>
>>> Driver testing is done with A20-OLinuXino-Lime2. Testing
>>> requirements are:
>>>- Exposing spi0 alternative pins in the dts file
>>>- Add alias node, enabling driver probing
>>>- Enable spi flash related options in the defconfig file
>>>
>>> The testing log is:
>>>U-Boot SPL 2018.01-rc2-00023-gfa13cb3-dirty (Dec 22 2017 - 11:39:48)
>>>DRAM: 1024 MiB
>>>CPU: 91200Hz, AXI/AHB/APB: 3/2/2
>>>Trying to boot from sunxi SPI
>>>
>>>
>>>U-Boot 2018.01-rc2-00023-gfa13cb3-dirty (Dec 22 2017 - 11:39:48 +0200)
>>> Allwinner Technology
>>>
>>>CPU:   Allwinner A20 (SUN7I)
>>>Model: Olimex A20-OLinuXino-LIME2
>>
>> Lime2 doen't have in-built spi-nor is it?
>
> We have some prototypes with this option.

I've Rev.6 does it have spi-nor?

>>
>>
>>>I2C:   ready
>>>DRAM:  1 GiB
>>>MMC:   SUNXI SD/MMC: 0
>>>MMC: no card present
>>>mmc_init: -123, time 1
>>>*** Warning - MMC init failed, using default environment
>>
>> you lost the env? since it's spi-nor better to use flash env.
>
> What's the point since this is only test case?

this can be an issue if we boot the system from spi-nor, where we can
get saved env.

>>
>>
>>>In:serial
>>>Out:   serial
>>>Err:   serial
>>>Allwinner mUSB OTG (Peripheral)
>>>SCSI:  SATA link 0 timeout.
>>>AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
>>>flags: ncq stag pm led clo only pmp pio slum part ccc apst
>>>Net:   No ethernet found.
>>>starting USB...
>>>USB0:   USB EHCI 1.00
>>>USB1:   USB OHCI 1.0
>>>USB2:   USB EHCI 1.00
>>>USB3:   USB OHCI 1.0
>>>scanning bus 0 for devices... 1 USB Device(s) found
>>>scanning bus 2 for devices... 1 USB Device(s) found
>>>   scanning usb for storage devices... 0 Storage Device(s) found
>>>Hit any key to stop autoboot:  0
>>>=> sspi
>>>
>>>=> sf probe
>>>SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB,
>>> total 16 MiB
>>
>> try to use erase/write and read commands to verify
>
> # Erase one sector
> => sf erase 0x1000 0x100
> SF: 256 bytes @ 0x1000 Erased: ERROR
> => sf erase 0x1000 0x1000
> SF: 4096 bytes @ 0x1000 Erased: OK
>
> # Get some random data
> => md.b 0x5000 0x100
> 5000: d6 4d d0 7e 93 d8 0f 48 1b ef 7f 7e be 4e a8 5d .M.~...H...~.N.]
> 5010: fd 9f e5 7f 2f 7b 5b 19 ed de d8 58 99 7a 24 da /{[X.z$.
> 5020: ef dd 9c 45 d7 97 ab 4f e7 fb ee 61 bc de 6a 1a ...E...O...a..j.
> 5030: 9a 9f f4 3a be 4b 2f f3 ce 77 87 7e 07 23 af ff ...:.K/..w.~.#..
> 5040: e5 e5 c0 fa 65 e2 78 9b 16 38 42 52 e5 6c 52 0d e.x..8BR.lR.
> 5050: f5 ff da 94 7f 98 96 d7 f0 9d 66 ae 9b b9 a2 cd ..f.
> 5060: 0b dd f1 c9 1d 3b fe 5b cf ef d6 ce 8b c5 fd 56 .;.[...V
> 5070: e2 52 eb 78 d4 f1 bf 57 56 6a 57 58 52 f1 0e 9d .R.x...WVjWXR...
> 5080: df be f8 19 bf cf d7 ac 4b 3e 86 21 3f c3 fe 3e K>.!?..>
> 5090: ea 27 52 ca 1f 79 bd 7b ef bf 96 c9 9d f6 81 d3 .'R..y.{
> 50a0: cc 2e 8b c8 34 7f c5 2f 29 19 a8 dc 54 7a 07 1d 4../)...Tz..
> 50b0: f4 e6 db ed 38 03 59 bb 31 ee b3 dd 5c e6 be 58 8.Y.1...\..X
> 50c0: a6 7c 87 61 84 47 e0 b1 a1 fc 6e d3 d5 93 bf 8a .|.a.Gn.
> 50d0: 5d a3 be 4b cf 07 1d 92 ff 36 f9 46 fb 5a cb 8f ]..K.6.F.Z..
> 50e0: f9 27 7a b8 7b 07 2e 22 a1 ee 56 bc a7 de 57 6a .'z.{.."..V...Wj
> 50f0: da d4 7d 7f ee db 7a e2 bc 5c 44 64 b7 fc ea 3e ..}...z..\Dd...
>
> # Write one page to spi-nor
> => sf write 0x5000 0x1000 0x100
> device 0 offset 0x1000, size 0x100
> SF: 256 bytes @ 0x1000 Written: OK
>
> # Readback data
> => sf read 0x5100 0x1000 0x100
> device 0 offset 0x1000, size 0x100
> SF: 256 bytes @ 0x1000 Read: OK
>
> # Compare data
> => cmp.b 0x5000 0x5100 0x100
> Total of 256 byte(s) were the same
>
>>
>>>=> sf test 0 10
>>>SPI flash test:
>>>0 erase: 11407 ticks, 89 KiB/s 0.712 Mbps
>>>1 check: 8881 ticks, 115 KiB/s 0.920 Mbps
>>>2 write: 10824 ticks, 94 KiB/s 0.752 Mbps
>>>3 read: 8872 ticks, 115 KiB/s 0.920 Mbps
>>>Test passed
>>>0 erase: 11407 ticks, 89 KiB/s 0.712 Mbps
>>>1 check: 8881 ticks, 115 KiB/s 0.920 Mbps
>>>2 write: 10824 ticks, 94 KiB/s 0.752 Mbps
>>>3 read: 8872 ticks, 115 KiB/s 0.920 Mbps
>>>=>
>>>
>>> Signed-off-by: Stefan Mavrodiev 
>>> ---
>>>   arch/arm/dts/sun7i-a20-olinuxino-lime2.dts | 21 +
>>>   configs/A20-OLinuXino-Lime2_defconfig  |  8 
>>>   2 files changed, 29 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/sun7i-a20-olinuxino-lime2.dts
>>> b/arch/arm/dts/sun7i-a20-olinuxino-lime2.dts
>>> index d5c796c..3c708da 100644
>>> --- a/arch/arm/dts/sun7i-a20-olinuxino-lime2.dts
>>> 

Re: [U-Boot] [PATCH v3 1/2] arm: sunxi: Allwinner A10 SPI driver

[Jagan Teki]

On Fri, Dec 22, 2017 at 3:30 PM, Stefan Mavrodiev  wrote:
> Add spi driver for sun4i, sun5i and sun7i SoCs. The driver is
> adapted from mailine kernel.
>
> Signed-off-by: Stefan Mavrodiev 
> ---
>  Changes for v3:
> - Add required changes in dts and defeconfig file for testing
>
>  Changes for v2:
> - Updated copyright including original owners
> - Remove write/read register function. They are replaced with direct opts
> - Some coding style changes
>
>  drivers/spi/Kconfig |   5 +
>  drivers/spi/Makefile|   1 +
>  drivers/spi/sun4i_spi.c | 456 
> 
>  3 files changed, 462 insertions(+)
>  create mode 100644 drivers/spi/sun4i_spi.c
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 494639f..9001182 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -132,6 +132,11 @@ config STM32_QSPI
>   used to access the SPI NOR flash chips on platforms embedding
>   this ST IP core.
>
> +config SUN4I_SPI
> +   bool "Allwinner A10 SoCs SPI controller"
> +   help
> + SPI driver for Allwinner sun4i, sun5i and sun7i SoCs
> +
>  config TEGRA114_SPI
> bool "nVidia Tegra114 SPI driver"
> help
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index e3184db..aa7645a 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -42,6 +42,7 @@ obj-$(CONFIG_SANDBOX_SPI) += sandbox_spi.o
>  obj-$(CONFIG_SH_SPI) += sh_spi.o
>  obj-$(CONFIG_SH_QSPI) += sh_qspi.o
>  obj-$(CONFIG_STM32_QSPI) += stm32_qspi.o
> +obj-$(CONFIG_SUN4I_SPI) += sun4i_spi.o
>  obj-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o
>  obj-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o
>  obj-$(CONFIG_TEGRA20_SLINK) += tegra20_slink.o
> diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
> new file mode 100644
> index 000..4f4cca6
> --- /dev/null
> +++ b/drivers/spi/sun4i_spi.c
> @@ -0,0 +1,456 @@
> +/*
> + * (C) Copyright 2017 Whitebox Systems / Northend Systems B.V.
> + * S.J.R. van Schaik 
> + * M.B.W. Wajer 
> + *
> + * (C) Copyright 2017 Olimex Ltd..
> + * Stefan Mavrodiev 
> + *
> + *

remove exctra line

> + * Based on linux spi driver. Original copyright follows:
> + * linux/drivers/spi/spi-sun4i.c
> + *
> + * Copyright (C) 2012 - 2014 Allwinner Tech
> + * Pan Nan 
> + *
> + * Copyright (C) 2014 Maxime Ripard
> + * Maxime Ripard 
> + *
> + *

ditto

> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define SUN4I_FIFO_DEPTH   64
> +
> +#define SUN4I_RXDATA_REG   0x00
> +
> +#define SUN4I_TXDATA_REG   0x04
> +
> +#define SUN4I_CTL_REG  0x08
> +#define SUN4I_CTL_ENABLE   BIT(0)
> +#define SUN4I_CTL_MASTER   BIT(1)
> +#define SUN4I_CTL_CPHA BIT(2)
> +#define SUN4I_CTL_CPOL BIT(3)
> +#define SUN4I_CTL_CS_ACTIVE_LOWBIT(4)
> +#define SUN4I_CTL_LMTF BIT(6)
> +#define SUN4I_CTL_TF_RST   BIT(8)
> +#define SUN4I_CTL_RF_RST   BIT(9)
> +#define SUN4I_CTL_XCH_MASK 0x0400
> +#define SUN4I_CTL_XCH  BIT(10)
> +#define SUN4I_CTL_CS_MASK  0x3000
> +#define SUN4I_CTL_CS(cs)   (((cs) << 12) & SUN4I_CTL_CS_MASK)
> +#define SUN4I_CTL_DHB  BIT(15)
> +#define SUN4I_CTL_CS_MANUALBIT(16)
> +#define SUN4I_CTL_CS_LEVEL BIT(17)
> +#define SUN4I_CTL_TP   BIT(18)
> +
> +#define SUN4I_INT_CTL_REG  0x0c
> +#define SUN4I_INT_CTL_RF_F34   BIT(4)
> +#define SUN4I_INT_CTL_TF_E34   BIT(12)
> +#define SUN4I_INT_CTL_TC   BIT(16)
> +
> +#define SUN4I_INT_STA_REG  0x10
> +
> +#define SUN4I_DMA_CTL_REG  0x14
> +
> +#define SUN4I_WAIT_REG 0x18
> +
> +#define SUN4I_CLK_CTL_REG  0x1c
> +#define SUN4I_CLK_CTL_CDR2_MASK0xff
> +#define SUN4I_CLK_CTL_CDR2(div)((div) & 
> SUN4I_CLK_CTL_CDR2_MASK)
> +#define SUN4I_CLK_CTL_CDR1_MASK0xf
> +#define SUN4I_CLK_CTL_CDR1(div)(((div) & 
> SUN4I_CLK_CTL_CDR1_MASK) << 8)
> +#define SUN4I_CLK_CTL_DRS  BIT(12)
> +
> +#define SUN4I_MAX_XFER_SIZE0xff
> +
> +#define SUN4I_BURST_CNT_REG0x20
> +#define SUN4I_BURST_CNT(cnt)   ((cnt) & SUN4I_MAX_XFER_SIZE)
> +
> +#define SUN4I_XMIT_CNT_REG 0x24
> +#define SUN4I_XMIT_CNT(cnt)((cnt) & SUN4I_MAX_XFER_SIZE)
> +
> +#define SUN4I_FIFO_STA_REG 0x28
> +#define SUN4I_FIFO_STA_RF_CNT_MASK 0x7f
> +#define SUN4I_FIFO_STA_RF_CNT_BITS 0
> +#define SUN4I_FIFO_STA_TF_CNT_MASK 0x7f
> +#define SUN4I_FIFO_STA_TF_CNT_BITS 16
> +
> 

Re: [U-Boot] [PATCH 1/2] sunxi: fix i2c support for sunxi H3/H5

[Maxime Ripard]

On Fri, Jan 19, 2018 at 09:35:58PM +0100, Jernej Škrabec wrote:
> Hi,
> 
> Dne petek, 19. januar 2018 ob 19:38:52 CET je Nuno Gonçalves napisal(a):
> > Sorry, there is only 1 patch in this series.
> > 
> > I would like comments regarding removing DM_I2C for MACH_SUNXI_H3_H5,
> > as I didn't found a reason for it to be defined.
> 
> there is good reason to be there. When H3/H5 board has DE2/HDMI enabled, 
> warning is shown when configuring, if DM_I2C is not selected. Since there 
> should be no warning, DM_I2C has to stay.
> 
> This means that whatever you want to have attached to I2C, you have to have 
> an 
> entry in DT for it. Since there is no DM pinctrl driver, you have to put code 
> somewhere, like you already done.
> 
> Besides, U-Boot wants to migrate towards DM drivers, no other way
> around. Last time I checked, DM I2C driver for H3/H5 should work,
> although it wasn't thoroughly tested from my side. So if there are
> issues with DM I2C driver, you have to fix it.

I should have looked closer, yes, you should keep the select on DM_I2C
here.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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 1/2] sunxi: fix i2c support for sunxi H3/H5

[Maxime Ripard]

On Fri, Jan 19, 2018 at 07:35:59PM +0100, Nuno Goncalves wrote:
> Tested to work in a Orange Pi Zero (H2+/H3), and checked against H5 datasheet.
> 
> Signed-off-by: Nuno Goncalves 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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] sunxi: Fix display timing flags

[Jagan Teki]

On Wed, Jan 17, 2018 at 1:08 PM, Maxime Ripard
 wrote:
> On Tue, Jan 16, 2018 at 05:43:48PM +0100, Giulio Benetti wrote:
>> flags member of struct timing was not initialized,
>> this took to unpredictable behaviour of display flags,
>> such DISPLAY_FLAGS_HSYNC_HIGH instead of _LOW etc.
>>
>> Init timing->flags = 0
>>
>> Signed-off-by: Giulio Benetti 
>
> Acked-by: Maxime Ripard 

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

Re: [U-Boot] [PATCH v2] spi: kirkwood_spi: implement workaround for FE-9144572

[Jagan Teki]

On Tue, Oct 17, 2017 at 4:15 AM, Chris Packham  wrote:
> On Tue, Oct 17, 2017 at 10:46 AM, Jagan Teki  wrote:
>> On Tue, Oct 17, 2017 at 3:07 AM, Chris Packham  
>> wrote:
>>> Erratum NO. FE-9144572: The device SPI interface supports frequencies of
>>> up to 50 MHz.  However, due to this erratum, when the device core clock
>>> is 250 MHz and the SPI interfaces is configured for 50MHz SPI clock and
>>> CPOL=CPHA=1 there might occur data corruption on reads from the SPI
>>> device.
>>>
>>> Implement the workaround by setting the TMISO_SAMPLE value to 0x2
>>> in the timing1 register.
>>>
>>> Signed-off-by: Chris Packham 
>>> Reviewed-by: Stefan Roese 
>>> ---
>>> I've based this as much as I can on the equivalent implementation in the
>>> Linux kernel[1], but there are differences in the u-boot spi
>>> infrastructure that means I can't be as specific when qualifying whether
>>> the workaround is needed.
>>>
>>> [1] - 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi-orion.c#n248
>>>
>>> Changes in v2:
>>> - collect reviewed-by from Stefan
>>> - remove mvebu_spi_type
>>> - describe errata above mvebu_spi_50mhz_ac_timing_erratum
>>>
>>>  arch/arm/include/asm/arch-mvebu/spi.h |  6 
>>>  drivers/spi/kirkwood_spi.c| 61 
>>> +--
>>>  2 files changed, 64 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/arch-mvebu/spi.h 
>>> b/arch/arm/include/asm/arch-mvebu/spi.h
>>> index 3545aed17347..1de510ea6da9 100644
>>> --- a/arch/arm/include/asm/arch-mvebu/spi.h
>>> +++ b/arch/arm/include/asm/arch-mvebu/spi.h
>>> @@ -57,6 +57,12 @@ struct kwspi_registers {
>>>  #define KWSPI_TXLSBF   (1 << 13)
>>>  #define KWSPI_RXLSBF   (1 << 14)
>>>
>>> +/* Timing Parameters 1 Register */
>>> +#define KW_SPI_TMISO_SAMPLE_OFFSET 6
>>> +#define KW_SPI_TMISO_SAMPLE_MASK   (0x3 << KW_SPI_TMISO_SAMPLE_OFFSET)
>>> +#define KW_SPI_TMISO_SAMPLE_1  (1 << KW_SPI_TMISO_SAMPLE_OFFSET)
>>> +#define KW_SPI_TMISO_SAMPLE_2  (2 << KW_SPI_TMISO_SAMPLE_OFFSET)
>>> +
>>>  #define KWSPI_IRQUNMASK1 /* unmask SPI interrupt */
>>>  #define KWSPI_IRQMASK  0 /* mask SPI interrupt */
>>>  #define KWSPI_SMEMRDIRQ1 /* SerMem data xfer ready irq */
>>> diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
>>> index 0c6bd295cde9..5b1ac0eed634 100644
>>> --- a/drivers/spi/kirkwood_spi.c
>>> +++ b/drivers/spi/kirkwood_spi.c
>>> @@ -243,6 +243,10 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
>>> bitlen,
>>>
>>>  /* Here now the DM part */
>>>
>>> +struct mvebu_spi_dev {
>>> +   boolis_errata_50mhz_ac;
>>> +};
>>> +
>>>  struct mvebu_spi_platdata {
>>> struct kwspi_registers *spireg;
>>>  };
>>> @@ -269,10 +273,38 @@ static int mvebu_spi_set_speed(struct udevice *bus, 
>>> uint hz)
>>> return 0;
>>>  }
>>>
>>> +/*
>>> + * FE-9144572: The device SPI interface supports frequencies of up to 50 
>>> MHz.
>>> + * However, due to this erratum, when the device core clock is 250 MHz and 
>>> the
>>> + * SPI interfaces is configured for 50MHz SPI clock and CPOL=CPHA=1 there 
>>> might
>>> + * occur data corruption on reads from the SPI device.
>>> + *
>>> + * Workaround: Set the TMISO_SAMPLE value to 0x2 in the SPI Timing 
>>> Parameters 1
>>> + * register
>>> + */

Move the comments on function definition like Linux and make sure
comments should be similar.

>>> +static void mvebu_spi_50mhz_ac_timing_erratum(struct udevice *bus, uint 
>>> mode)
>>> +{
>>> +   struct mvebu_spi_platdata *plat = dev_get_platdata(bus);
>>> +   struct kwspi_registers *reg = plat->spireg;
>>> +   u32 data = readl(>timing1);
>>> +
>>> +   data &= ~KW_SPI_TMISO_SAMPLE_MASK;
>>> +
>>> +   if (CONFIG_SYS_TCLK == 25000 &&
>>> +   mode & SPI_CPOL &&
>>> +   mode & SPI_CPHA)
>>> +   data |= KW_SPI_TMISO_SAMPLE_2;
>>> +   else
>>> +   data |= KW_SPI_TMISO_SAMPLE_1;
>>> +
>>> +   writel(data, >timing1);
>>> +}
>>> +

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

Re: [U-Boot] [PATCH v6 2/2] common: Generic firmware loader for file system

[Chee, Tien Fong]

On Thu, 2018-01-18 at 06:57 +0100, Simon Goldschmidt wrote:
> On 27.12.2017 06:04, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This is file system generic loader which can be used to load
> > the file image from the storage into target such as memory.
> > The consumer driver would then use this loader to program whatever,
> > ie. the FPGA device.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >   common/Makefile|   1 +
> >   common/fs_loader.c | 309
> > +
> >   doc/README.firmware_loader |  76 +++
> >   include/fs_loader.h|  28 
> >   4 files changed, 414 insertions(+)
> >   create mode 100644 common/fs_loader.c
> >   create mode 100644 doc/README.firmware_loader
> >   create mode 100644 include/fs_loader.h
> 
> 
> > 
> > +#if defined(CONFIG_SPL_MMC_SUPPORT) && defined(CONFIG_SPL_BUILD)
> > +static int init_mmc(void)
> > +{
> > +   /* Just for the case MMC is not yet initialized */
> > +   struct mmc *mmc = NULL;
> > +   int err;
> > +
> > +   spl_mmc_find_device(, spl_boot_device());
> > +
> > +   err = mmc_init(mmc);
> > +   if (err) {
> > +   printf("spl: mmc init failed with error: %d\n",
> > err);
> > +   return err;
> > +   }
> > +
> > +   return err;
> > +}
> I see two problems here: First, you're ignoring the return value of 
> spl_mmc_find_device() and initialize 'mmc' to NULL instead. Wouldn't
> it 
> be better to let 'mmc' be uninitialized and return the error code 
> returned by spl_mmc_find_device() if there is one?
> 
Yeah, you are right, i should add the check on the return value. I
think that would better to initialize NULL to mmc, because there is no
checking on the mmc in spl_mmc_find_device(), so that is possible
memory access violation/abort can be happended if unknown value in mmc
pointer.

> Second, using spl_boot_device() would prevent making the loader work
> on 
> mach-socfpga when spl is not loaded from mmc, right?
> 
> E.g. for the case I'm currently trying to fix (boot from qspi), this 
> loader would not work although there's technically no reason since
> the 
> platform only has one mmc. The call to spl_boot_device() could be 
> replaced by the exact value here for platforms that only have one
> mmc. I 
> don't know how to fix that, though.
> 
The main purpose here is to initialize the mmc driver. So which storage
user wants to load the file is totally depend what storage such as mmc
user defines in location->name. Loader would init the storage based on
the storage defined in location->name before accessing it. Since the
loader only support file system at this moment, i would suggest FAT fs 
for mmc and ubi fs for qspi.

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

Re: [U-Boot] [PATCH] sunxi: Add support for the Beelink-x2 STB

[Maxime Ripard]

Hi,

On Sun, Jan 21, 2018 at 07:06:49PM +0100, codekip...@gmail.com wrote:
> From: Marcus Cooper 
> 
> The Beelink X2 is an STB based on the Allwinner H3 SoC with a uSD slot,
> 2 USB ports( 1 * USB-2 Host, 1 USB OTG), a 10/100M ethernet port using
> the SoC's integrated PHY, Wifi via an sdio wifi chip, HDMI, a dual
> colour LED, an IR receiver and an optical S/PDIF connector.
> 
> Signed-off-by: Marcus Cooper 
> ---
>  arch/arm/dts/Makefile|   1 +
>  arch/arm/dts/sun8i-h3-beelink-x2.dts | 155 
> +++
>  board/sunxi/MAINTAINERS  |   5 ++
>  configs/beelink_x2_defconfig |  18 
>  4 files changed, 179 insertions(+)
>  create mode 100644 arch/arm/dts/sun8i-h3-beelink-x2.dts
>  create mode 100644 configs/beelink_x2_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 9540ba4313..f899cef7ac 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -335,6 +335,7 @@ dtb-$(CONFIG_MACH_SUN8I_A83T) += \
>  dtb-$(CONFIG_MACH_SUN8I_H3) += \
>   sun8i-h2-plus-orangepi-zero.dtb \
>   sun8i-h3-bananapi-m2-plus.dtb \
> + sun8i-h3-beelink-x2.dtb \
>   sun8i-h3-libretech-all-h3-cc.dtb \
>   sun8i-h3-orangepi-2.dtb \
>   sun8i-h3-orangepi-lite.dtb \
> diff --git a/arch/arm/dts/sun8i-h3-beelink-x2.dts 
> b/arch/arm/dts/sun8i-h3-beelink-x2.dts
> new file mode 100644
> index 00..43f67eb8db
> --- /dev/null
> +++ b/arch/arm/dts/sun8i-h3-beelink-x2.dts
> @@ -0,0 +1,155 @@
> +/*
> + * Copyright (C) 2017 Marcus Cooper 
> + *
> + * 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 file 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 file 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/;
> +#include "sun8i-h3.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include 
> +#include 
> +
> +/ {
> + model = "Beelink X2";
> + compatible = "roofull,beelink-x2", "allwinner,sun8i-h3";
> +
> + aliases {
> + serial0 = 
> + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
> + ethernet1 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + blue {
> + label = "beelink-x2:blue:pwr";
> + gpios = <_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
> + default-state = "on";
> + };
> +
> + red {
> + label = "beelink-x2:red:standby";
> + gpios = < 0 15 GPIO_ACTIVE_HIGH>; /* PA15 */
> + };
> + };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <_pio 0 7 GPIO_ACTIVE_LOW>; /* PL7 */
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + phy = <>;
> + phy-mode = "mii";
> + allwinner,use-internal-phy;
> + allwinner,leds-active-low;
> + status = "okay";
> + phy1: