Re: [PATCH] x86: p2sb: Drop 'apl' prefix

2020-02-27 Thread Bin Meng
On Thu, Feb 27, 2020 at 5:40 PM Bin Meng  wrote:
>
> On Tue, Feb 18, 2020 at 10:32 PM Wolfgang Wallner
>  wrote:
> >
> > Drop the Apollo Lake prefix 'apl' from the functions, types and
> > variables in the P2SB driver.
> >
> > The P2SB is not Apollo Lake specific, and as such it was moved in
> > commit 2999846c1127 ("x86: Move P2SB from Apollo Lake to a more generic
> > location") from the Apollo Lake folder to the intel_common folder.
> >
> > Signed-off-by: Wolfgang Wallner 
> >
> > ---
> > This patch follows a similar rational for P2SB as commit 03fe85a27b23
> > ("x86: itss: Remove apl-prefix") for the ITSS.
> >
> >  arch/x86/cpu/intel_common/p2sb.c  | 30 +--
> >  arch/x86/dts/chromebook_coral.dts |  2 +-
> >  .../gpio/intel,apl-gpio.txt   |  2 +-
> >  .../pinctrl/intel,apl-pinctrl.txt |  2 +-
> >  4 files changed, 18 insertions(+), 18 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [RFC PATCH] serial: ns16550: Move PCI access from ofdata_to_platdata() to probe()

2020-02-27 Thread Bin Meng
On Thu, Feb 27, 2020 at 5:36 PM Bin Meng  wrote:
>
> On Tue, Feb 18, 2020 at 8:36 PM Wolfgang Wallner
>  wrote:
> >
> > Currently the ofdata_to_platdata() method calls dev_read_addr_pci(),
> > which potentially accesses the parent PCI bus. If this happens before
> > the parent PCI bus is probed the resulting address will be wrong.
> >
> > This behavior was triggered by commit 82de42fa1468 ("dm: core:
> > Allocate parent data separate from probing parent").
> >
> > According to a comment in drivers/pci/pci-uclass.c [1] accessing
> > the PCI parent bus in ofdata_to_platdata() is not allowed, and the
> > access should be moved to the probe() function.
> >
> > Move the call to dev_read_addr_pci() and the related handling of the
> > 'addr' value from the ofdata_to_platdata() to the probe() method.
> >
> > While moving the code, the comment /* try Processor Local Bus device
> > first */ was dropped. It was initially added with commit 3db886a5bf38
> > ("serial: ns16550: Support ns16550 compatible pci uart devices") and
> > later made obsolete with commit 33c215af4b9d ("dm: pci: Add a function
> > to read a PCI BAR").
> >
> > [1] Comment in drivers/pci/pci-uclass.c:
> > "A common cause of this problem is that this function is called in the
> > ofdata_to_platdata() method of @dev. Accessing the PCI bus in that
> > method is not allowed, since it has not yet been probed. To fix this,
> > move that access to the probe() method of @dev instead."
> >
> > Signed-off-by: Wolfgang Wallner 
> >
> > Fixes: 82de42fa1468 ("dm: core: Allocate parent data separate from
> > probing parent")
> >
> > ---
> > The discussion leading to this patch is located at
> > https://lists.denx.de/pipermail/u-boot/2020-February/399811.html
> >
> >  drivers/serial/ns16550.c | 26 +-
> >  1 file changed, 13 insertions(+), 13 deletions(-)
> >
>
> Reviewed-by: Bin Meng 
>
> This fixed the boot failure of Intel Galileo
>
> Tested on Intel Galileo
> Tested-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v2 10/21] arm: socfpga: Add secure register access helper functions for SoC 64bits

2020-02-27 Thread Simon Goldschmidt
Ang, Chee Hong  schrieb am Fr., 28. Feb. 2020,
03:53:

> > > On 2/24/20 3:21 AM, Ang, Chee Hong wrote:
> > > [...]
> > >
> > > > Currently, we have like 20+ secure registers allowed access by
> > > > drivers running in non-secure mode (U-Boot proper / Linux).
> > > > I don't think we want to define and maintain those high level
> > > > interfaces for each of those secure register accesses in ATF and
> U-Boot.
> > > 
> > >  See above.
> > > >>> OK. Then these secure access register should be set up in SPL
> (EL3).
> > > >>> U-Boot drivers shouldn't access them at all because the driver may
> > > >>> be running in SPL(EL3) and in U-Boot proper (EL2) too.
> > > >>> I can take a look at those drivers accessing secure registers and
> > > >>> try to move/decouple those secure access from U-Boot drivers to
> > > >>> SPL
> > > >>> (EL3) then we no longer need those secure register access
> functions.
> > > >>
> > > >> I think that would be great, no ?
> > > > Since the SDMMC/DWMAC drivers read the device tree to configure the
> > > > behaviour of the hardware via the secure registers. I think it
> > > > should still be part of the driver instead of configuring the
> > > > hardware in different places. I have proposed using ATF's high-level
> > > > APIs to achieve this
> > > when the driver is running in EL2.
> > > > I have already proposed this in other email threads.
> > > > Are you OK with this approach ?
> > >
> > > I think something more high level might be a good idea here.
> > What do you mean by 'more high level' ?
> > We handle this in SPL (EL3) ?
> >
> > Since you are the author of this 'drivers/net/dwmac_socfpga.c':
> > https://gitlab.denx.de/u-boot/u-
> > boot/blob/master/drivers/net/dwmac_socfpga.c#L101
> > https://gitlab.denx.de/u-boot/u-
> > boot/blob/master/arch/arm/dts/socfpga_stratix10.dtsi#L98
> >
> > Your driver selects the PHY interface (RGMII/RMII and etc) using the
> following
> > register (part of System Manager):
> > https://www.intel.com/content/www/us/en/programmable/hps/stratix-
> > 10/hps.html#topic/jng1505406892594.html
> >
> > I personally think this PHY interface select for EMACx shouldn't be part
> of
> > System Manager.
> > I don't see the security benefits here by making this PHY interface
> select as
> > 'secure zone' register.
> >
> > Same applies to DW MMC driver as well:
> > https://gitlab.denx.de/u-boot/u-
> > boot/blob/master/drivers/mmc/socfpga_dw_mmc.c#L60
> >
> > It sets the following register in System Manager (secure zone) to
> configure the
> > SDMMC clocks:
> > https://www.intel.com/content/www/us/en/programmable/hps/stratix-
> > 10/hps.html#topic/gil1505406886282.html
> >
> > Don't you think these things should be part of driver itself as what we
> are doing
> > now instead of removing these from drivers and place them in SPL (EL3)?
>
> These 2 drivers that access the system manager:
> drivers/mmc/socfpga_dw_mmc.c
> - MMC driver access System Manager's 'SDMMC' register to set clock phase
>
> https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/topic/gil1505406886282.html
>
> drivers/net/dwmac_socfpga.c
> - MAC driver access System Manager's 'EMACx' registers to set MAC's PHY
> interface:
>
> https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/hps.html#topic/jng1505406892594.html
>
> Gen5/Arria10/Stratix10 & Agilex all using these drivers.
> They do not cause any issue in Gen5/Arria10 because there is no 'secure
> zone' in System Manager.
> For Stratix10 & Agilex, it has issue with U-Boot proper running in EL2.
>
> I don't think is good idea to separate those System Manager access from
> these 2 drivers and move them to SPL as they are shared by all SOCFPGA
> platforms.
>
> I think the proper way to resolve this is we add a new System Manager
> driver under 'drivers/misc'.
> The device type should be 'UCLASS_MISC'.


I have a pending patchset that adds such a sysmgr driver at least for gen5.
I haven't published it yet because the whole series as one makes gen5 SRAM
overlow, but maybe that part can be split out...

Regards,
Simon


Then we make changes to those drivers (SDMMC/MAC) to access the System
> Manager through the System Manager driver by using 'misc_read(dev...)' &
> 'misc_write(dev...)'
> The System Manager driver should decide whether to access those 'secure
> zone' registers directly in EL3 or making SMC call to ATF to access the
> System Manager if it's running in EL2.
>
> Linux has similar MAC driver running in EL1 (non-secure) accessing System
> Manager:
>
> https://elixir.bootlin.com/linux/v5.5/source/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c#L302
>
> Linux MAC driver access System Manager via this 'altr,system_manager'
> driver:
>
> https://elixir.bootlin.com/linux/v5.5/source/drivers/mfd/altera-sysmgr.c#L44
> System Manager driver will make SMC/PSCI call to ATF to access the System
> Manager's registers.
>


RE: [PATCH] x86: Cache write back at 32-bit entry point

2020-02-27 Thread Park, Aiden
Hi Bin,

> -Original Message-
> From: Bin Meng 
> Sent: Thursday, February 27, 2020 9:27 PM
> To: Park, Aiden 
> Cc: masahi...@kernel.org; s...@chromium.org; s...@denx.de; ag...@suse.de; u-
> b...@lists.denx.de
> Subject: Re: [PATCH] x86: Cache write back at 32-bit entry point
> 
> Hi Aiden,
> 
> On Fri, Feb 28, 2020 at 12:54 PM Park, Aiden  wrote:
> >
> > In a certain condition, invd causes cache coherence issue.
> >   1. Pre-stage boot code passes memory address to U-Boot
> >   2. The data of the memory address is still in data cache line
> >   3. The invd marks data cache line as invalid without write back
> >   4. U-Boot accesses the memory address
> >   5. Data is invalid
> >
> > Therefore, wbinvd is recommended at the 32-bit entry point even though
> > it consumes extra cpu clock cycles.
> >
> > Signed-off-by: Aiden Park 
> > ---
> >  arch/x86/cpu/start.S | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> 
> This is already fixed (reverted) in the x86 tree. Would you please double 
> check?
> 
Thank you for letting me know that. I think I missed some emails. Thanks again.
Andy, appreciate your commit. I had the same issue on Slim Bootloader due to 
this cache coherence.

> Regards,
> Bin

Best Regards,
Aiden


Re: [PATCH] x86: Cache write back at 32-bit entry point

2020-02-27 Thread Bin Meng
Hi Aiden,

On Fri, Feb 28, 2020 at 12:54 PM Park, Aiden  wrote:
>
> In a certain condition, invd causes cache coherence issue.
>   1. Pre-stage boot code passes memory address to U-Boot
>   2. The data of the memory address is still in data cache line
>   3. The invd marks data cache line as invalid without write back
>   4. U-Boot accesses the memory address
>   5. Data is invalid
>
> Therefore, wbinvd is recommended at the 32-bit entry point even though
> it consumes extra cpu clock cycles.
>
> Signed-off-by: Aiden Park 
> ---
>  arch/x86/cpu/start.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

This is already fixed (reverted) in the x86 tree. Would you please double check?

Regards,
Bin


[PATCH] x86: Cache write back at 32-bit entry point

2020-02-27 Thread Park, Aiden
In a certain condition, invd causes cache coherence issue.
  1. Pre-stage boot code passes memory address to U-Boot
  2. The data of the memory address is still in data cache line
  3. The invd marks data cache line as invalid without write back
  4. U-Boot accesses the memory address
  5. Data is invalid

Therefore, wbinvd is recommended at the 32-bit entry point even though
it consumes extra cpu clock cycles.

Signed-off-by: Aiden Park 
---
 arch/x86/cpu/start.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S
index 26cf995db2..01524635e9 100644
--- a/arch/x86/cpu/start.S
+++ b/arch/x86/cpu/start.S
@@ -50,7 +50,7 @@ _x86boot_start:
movl%cr0, %eax
orl $(X86_CR0_NW | X86_CR0_CD), %eax
movl%eax, %cr0
-   invd
+   wbinvd
 
/*
 * Zero the BIST (Built-In Self Test) value since we don't have it.
-- 
2.20.1



RE: [PATCH v2 10/21] arm: socfpga: Add secure register access helper functions for SoC 64bits

2020-02-27 Thread Ang, Chee Hong
> > On 2/24/20 3:21 AM, Ang, Chee Hong wrote:
> > [...]
> >
> > > Currently, we have like 20+ secure registers allowed access by
> > > drivers running in non-secure mode (U-Boot proper / Linux).
> > > I don't think we want to define and maintain those high level
> > > interfaces for each of those secure register accesses in ATF and 
> > > U-Boot.
> > 
> >  See above.
> > >>> OK. Then these secure access register should be set up in SPL (EL3).
> > >>> U-Boot drivers shouldn't access them at all because the driver may
> > >>> be running in SPL(EL3) and in U-Boot proper (EL2) too.
> > >>> I can take a look at those drivers accessing secure registers and
> > >>> try to move/decouple those secure access from U-Boot drivers to
> > >>> SPL
> > >>> (EL3) then we no longer need those secure register access functions.
> > >>
> > >> I think that would be great, no ?
> > > Since the SDMMC/DWMAC drivers read the device tree to configure the
> > > behaviour of the hardware via the secure registers. I think it
> > > should still be part of the driver instead of configuring the
> > > hardware in different places. I have proposed using ATF's high-level
> > > APIs to achieve this
> > when the driver is running in EL2.
> > > I have already proposed this in other email threads.
> > > Are you OK with this approach ?
> >
> > I think something more high level might be a good idea here.
> What do you mean by 'more high level' ?
> We handle this in SPL (EL3) ?
> 
> Since you are the author of this 'drivers/net/dwmac_socfpga.c':
> https://gitlab.denx.de/u-boot/u-
> boot/blob/master/drivers/net/dwmac_socfpga.c#L101
> https://gitlab.denx.de/u-boot/u-
> boot/blob/master/arch/arm/dts/socfpga_stratix10.dtsi#L98
> 
> Your driver selects the PHY interface (RGMII/RMII and etc) using the following
> register (part of System Manager):
> https://www.intel.com/content/www/us/en/programmable/hps/stratix-
> 10/hps.html#topic/jng1505406892594.html
> 
> I personally think this PHY interface select for EMACx shouldn't be part of
> System Manager.
> I don't see the security benefits here by making this PHY interface select as
> 'secure zone' register.
> 
> Same applies to DW MMC driver as well:
> https://gitlab.denx.de/u-boot/u-
> boot/blob/master/drivers/mmc/socfpga_dw_mmc.c#L60
> 
> It sets the following register in System Manager (secure zone) to configure 
> the
> SDMMC clocks:
> https://www.intel.com/content/www/us/en/programmable/hps/stratix-
> 10/hps.html#topic/gil1505406886282.html
> 
> Don't you think these things should be part of driver itself as what we are 
> doing
> now instead of removing these from drivers and place them in SPL (EL3)?

These 2 drivers that access the system manager:
drivers/mmc/socfpga_dw_mmc.c
- MMC driver access System Manager's 'SDMMC' register to set clock phase
https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/topic/gil1505406886282.html

drivers/net/dwmac_socfpga.c
- MAC driver access System Manager's 'EMACx' registers to set MAC's PHY 
interface:
https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/hps.html#topic/jng1505406892594.html

Gen5/Arria10/Stratix10 & Agilex all using these drivers.
They do not cause any issue in Gen5/Arria10 because there is no 'secure zone' 
in System Manager.
For Stratix10 & Agilex, it has issue with U-Boot proper running in EL2.

I don't think is good idea to separate those System Manager access from these 2 
drivers and move them to SPL as they are shared by all SOCFPGA platforms.

I think the proper way to resolve this is we add a new System Manager driver 
under 'drivers/misc'.
The device type should be 'UCLASS_MISC'. Then we make changes to those drivers 
(SDMMC/MAC) to access the System Manager through the System Manager driver by 
using 'misc_read(dev...)' & 'misc_write(dev...)'
The System Manager driver should decide whether to access those 'secure zone' 
registers directly in EL3 or making SMC call to ATF to access the System 
Manager if it's running in EL2.

Linux has similar MAC driver running in EL1 (non-secure) accessing System 
Manager:
https://elixir.bootlin.com/linux/v5.5/source/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c#L302

Linux MAC driver access System Manager via this 'altr,system_manager' driver:
https://elixir.bootlin.com/linux/v5.5/source/drivers/mfd/altera-sysmgr.c#L44
System Manager driver will make SMC/PSCI call to ATF to access the System 
Manager's registers.


[PATCH] patman: Apply the cc limit to the cover letter also

2020-02-27 Thread Simon Glass
Quite often on a series that has clean-up patches, the individual patches
may fit within the cc limit but the cover letter does not. Apply the same
limit to the cover letter.

Signed-off-by: Simon Glass 
---

 tools/patman/series.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/patman/series.py b/tools/patman/series.py
index a15f7625ed..6d9d48b123 100644
--- a/tools/patman/series.py
+++ b/tools/patman/series.py
@@ -249,8 +249,10 @@ class Series(dict):
 if cover_fname:
 cover_cc = gitutil.BuildEmailList(self.get('cover_cc', ''))
 cover_cc = [tools.FromUnicode(m) for m in cover_cc]
-cc_list = '\0'.join([tools.ToUnicode(x)
- for x in sorted(set(cover_cc + all_ccs))])
+cover_cc = list(set(cover_cc + all_ccs))
+if limit is not None:
+cover_cc = cover_cc[:limit]
+cc_list = '\0'.join([tools.ToUnicode(x) for x in sorted(cover_cc)])
 print(cover_fname, cc_list, file=fd)
 
 fd.close()
-- 
2.25.1.481.gfbce0eb801-goog



Re: Re: dm: core: Board failing to boot since commit 82de42fa1468 (parent data/probe)

2020-02-27 Thread Bin Meng
Hi Simon,

On Fri, Feb 28, 2020 at 7:41 AM Simon Glass  wrote:
>
> Hi Wolfgang,
>
> On Mon, 17 Feb 2020 at 03:39, Wolfgang Wallner
>  wrote:
> >
> > Hi Bin, Simon,
> >
> > -"Bin Meng"  schrieb: -
> > > Hi Wolfgang,
> > >
> > > On Wed, Feb 12, 2020 at 1:14 AM Simon Glass  wrote:
> > > >
> > > > +Bin
> > > >
> > > > Hi Wolfgang,
> > > >
> > > > On Tue, 11 Feb 2020 at 06:59, Wolfgang Wallner
> > > >  wrote:
> > > > >
> > > > > Hello Simon,
> > > > >
> > > > > Since commit 82de42fa1468 ("dm: core: Allocate parent data separate 
> > > > > from
> > > > > probing parent") I have trouble booting my board (a custom Apollo 
> > > > > Lake design
> > > > > booted via Coreboot + U-Boot).
> > > > >
> > > > > I think this is because the function 
> > > > > ns16550_serial_ofdata_to_platdata() of
> > > > > the UART driver noew tries to access the PCI bus before it is probed.
> > > > > I'm aware of the comment which you have added to pci-uclass.c [1].
> > > > >
> > > > > So the correct way to fix this would be to adapt the uart driver in 
> > > > > ns16550.c?
> > > >
> > > > Why is the UART being used so early?
> >
> > board_init_f() calls serial_init(), because it is part of init_sequence_f.
> > This leads to device_probe() being called for my UART.
> >
> > The detailed call stack looks as follows:
> >
> > FileFunction
> > -
> > board_f.c   board_init_f()
> > serial-uclass.c serial_init()
> > serial_find_console_or_panic()
> > serial_check_stdout()
> > // stdout-path is set to serial0:115200n8
> > // serial0 is an alias for the device pciuart2,
> > // which is called uart@18,2 in my device tree
> > // This device is similar to what is called
> > // serial@18,2 in chromebook_coral.dts
> > uclass.cuclass_get_device_by_of_offset()
> > uclass_get_device_tail()
> > device.cdevice_probe()
> > // device_probe calls drv->ofdata_to_platdata(),
> > // which points to
> > // ns16550_serial_ofdata_to_platdata in my case
> > ns16550.c   ns16550_serial_ofdata_to_platdata()
> > // This is where the PCI access to the
> > // uninitialized bus 'pci' happens
> >
> > > > Also, if you are booting from
> > > > coreboot you really shouldn't need to auto-config PCI at all, so
> > > > perhaps just disable CONFIG_PCI_PNP?
> >
> > CONFIG_PCI_PNP is already disabled in my configuration.
> >
> > > > But I understand that that
> > > > changes the build.
> > > >
> > > > The way I fixed it is to allow the UART to stay at a fixed PCI address:
> > > >
> > > > 9e11293319 dm: pci: Allow disabling auto-config for a device
> >
> > I think commit 9e11293319 would be a solution if the problem would be
> > CONFIG_PCI_PNP, but that is not the case here.
> >
> > Just to be sure I have cherry-picked 9e11293319 and added 
> > "pci,no-autoconfig;"
> > to my UART, but that does not solve my issue.
> >
> > > Please suggest whether I should get the above patch applied to fix the
> > > issue you saw on your board.
> >
> > I think the issue I see is something different.
> >
> > And I can't provide a proper review for commit 9e11293319 as I don't
> > know the PCI subsystem in U-Boot well enough.
>
> It looks like the dev_read_addr_pci() needs to move into a probe()
> function in that driver.

This is http://patchwork.ozlabs.org/patch/1239995/ already in the queue.

Regards,
Bin


[PATCH] common: update_tftp: remove unnecessary build check

2020-02-27 Thread AKASHI Takahiro
Logically, the current update_tftp() should and does compile and work
correctly even without satisfying the following condition:

> #if defined(CONFIG_UPDATE_TFTP) && !defined(CONFIG_MTD_NOR_FLASH)
> #error "CONFIG_UPDATE_TFTP and !CONFIG_MTD_NOR_FLASH needed for
>  legacy behaviour"
> #endif

It would be better to just drop it so that this function will be
used on wider range of platforms.

Signed-off-by: AKASHI Takahiro 
---
 common/update.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/common/update.c b/common/update.c
index c8dd346a0956..ade029851dbd 100644
--- a/common/update.c
+++ b/common/update.c
@@ -14,10 +14,6 @@
 #error "CONFIG_FIT and CONFIG_OF_LIBFDT are required for auto-update feature"
 #endif
 
-#if defined(CONFIG_UPDATE_TFTP) && !defined(CONFIG_MTD_NOR_FLASH)
-#error "CONFIG_UPDATE_TFTP and !CONFIG_MTD_NOR_FLASH needed for legacy 
behaviour"
-#endif
-
 #include 
 #include 
 #include 
@@ -210,8 +206,9 @@ static int update_flash(ulong addr_source, ulong 
addr_first, ulong size)
printf("Error: could not protect flash sectors\n");
return 1;
}
+#else
+   return -1;
 #endif
-   return 0;
 }
 
 static int update_fit_getparams(const void *fit, int noffset, ulong *addr,
-- 
2.24.0



[PATCH] efi_loader: file: set a backend block device for file operations

2020-02-27 Thread AKASHI Takahiro
In the current implementation, set_blk_dev() is called in opening a file,
but not in opening a directory. This will cause failures at succeeding
directory operations as the "current" block device remains nullified.
Adding set_blk_dev() fixes this issue.

Signed-off-by: AKASHI Takahiro 
---
 lib/efi_loader/efi_file.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index 140116ddc4ac..ba55b2829e03 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -235,6 +235,9 @@ static struct efi_file_handle *file_open(struct file_system 
*fs,
} else {
fh->isdir = 1;
strcpy(fh->path, "");
+
+   if (set_blk_dev(fh))
+   goto error;
}
 
return >base;
-- 
2.24.0



[PATCH] cmd: efidebug: fix a failure of "boot rm" sub-command

2020-02-27 Thread AKASHI Takahiro
There is a wrong usage of utf8_utf16_strncpy() in "boot rm" command, and
then it will end up with a failure of this command due to a wrong
value of an interim variable ("var_name16").

Signed-off-by: AKASHI Takahiro 
---
 cmd/efidebug.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index 576e95b395dc..3a50dafbbca6 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -641,7 +641,7 @@ static int do_efi_boot_rm(cmd_tbl_t *cmdtp, int flag,
int id, i;
char *endp;
char var_name[9];
-   u16 var_name16[9];
+   u16 var_name16[9], *p;
efi_status_t ret;
 
if (argc == 1)
@@ -654,7 +654,8 @@ static int do_efi_boot_rm(cmd_tbl_t *cmdtp, int flag,
return CMD_RET_FAILURE;
 
sprintf(var_name, "Boot%04X", id);
-   utf8_utf16_strncpy((u16 **)_name16, var_name, 9);
+   p = var_name16;
+   utf8_utf16_strncpy(, var_name, 9);
 
ret = EFI_CALL(RT->set_variable(var_name16, , 0, 0, NULL));
if (ret) {
-- 
2.24.0



Re: [PATCH v5 2/6] log: syslog driver

2020-02-27 Thread Simon Glass
On Wed, 26 Feb 2020 at 12:48, Heinrich Schuchardt  wrote:
>
> Provide a log driver that broadcasts RFC 3164 messages to syslog servers.
> rsyslog is one implementation of such a server.
>
> The messages are sent to the local broadcast address 255.255.255.255 on
> port 514.
>
> The environment variable log_hostname can be used to provide the HOSTNAME
> field for the messages. The optional TIMESTAMP field of RFC 3164 is not
> provided.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v5:
> do not build syslog driver in SPL
> v4:
> no change
> ---
>  MAINTAINERS |   2 +-
>  common/Kconfig  |   7 +++
>  common/Makefile |   1 +
>  common/log_syslog.c | 117 
>  doc/README.log  |   3 ++
>  5 files changed, 129 insertions(+), 1 deletion(-)
>  create mode 100644 common/log_syslog.c
>

Reviewed-by: Simon Glass 


Re: [PATCH 3/4] lib/hashtable.c: don't test ->callback in SPL

2020-02-27 Thread Simon Glass
On Thu, 27 Feb 2020 at 05:56, Rasmus Villemoes
 wrote:
>
> In SPL, environment callbacks are not supported, so e->callback is
> always NULL. Removing this makes the SPL a little smaller (about 400
> bytes in my ppc build) with no functional change.
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  lib/hashtable.c | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Simon Glass 

>
> diff --git a/lib/hashtable.c b/lib/hashtable.c
> index 574ec6af86..c4e1e2bd45 100644
> --- a/lib/hashtable.c
> +++ b/lib/hashtable.c
> @@ -226,8 +226,10 @@ static int
>  do_callback(const struct env_entry *e, const char *name, const char *value,
> enum env_op op, int flags)
>  {
> +#ifndef CONFIG_SPL_BUILD
> if (e->callback)
> return e->callback(name, value, op, flags);
> +#endif

blank line before return

> return 0;
>  }


>
> --
> 2.23.0
>


Re: [PATCH 2/4] lib/hashtable.c: create helper for calling env_entry::callback

2020-02-27 Thread Simon Glass
On Thu, 27 Feb 2020 at 05:56, Rasmus Villemoes
 wrote:
>
> This is preparation for compiling out the "call the callback" code and
> associated error handling for SPL, where ->callback is always NULL.
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  lib/hashtable.c | 23 +++
>  1 file changed, 15 insertions(+), 8 deletions(-)

Reviewed-by: Simon Glass 


Re: sandbox: CONFIG_SYS_RELOC_GD_ENV_ADDR?

2020-02-27 Thread Simon Glass
Hi AKASHI,

On Sun, 16 Feb 2020 at 22:01, AKASHI Takahiro
 wrote:
>
> Tom, Simon,
>
> On Fri, Feb 14, 2020 at 12:16:33PM -0700, Simon Glass wrote:
> > Hi AKASHI,
> >
> > On Thu, 13 Feb 2020 at 18:39, AKASHI Takahiro
> >  wrote:
> > >
> > > Tom, Simon,
> > >
> > > Is CONFIG_SYS_RELOC_GD_ENV_ADDR really needed on sandbox?
> > >
> > > When I try to have a variable environment on emulated SPI flash,
> > > the U-Boot binary always crashes: (NOTE: assuming CONFIG_ENV_ADDR == 0)
> > > $ dd if=/dev/zero of=./spi.bin bs=1M count=4
> > > $ u-boot -T
> > > U-Boot 2020.04-rc2-00015-gc9afef2b1938-dirty (Feb 14 2020 - 10:24:59 
> > > +0900)
> > >
> > > Model: sandbox
> > > DRAM:  128 MiB
> > > WDT:   Started with servicing (60s timeout)
> > > MMC:   mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD)
> > > Loading Environment from SPI Flash... SF: Detected m25p16 with page 
> > > size 256 Bytes, erase size 64 KiB, total 2 MiB
> > > *** Warning - bad CRC, using default environment
> > >
> > > Segmentation fault (core dumped)
> > >
> > > If this configuration is disabled, panic doesn't happen.
> > > I think that it should be turned off in any sandbox*_defconfig.
> > >
> > > In addition, please update
> > > - doc/arch/sandbox.rst
> > > - doc/SPI/README.sandbox-spi
> > > Both two still mention already-removed command line option, --spi_sf.
> > > It is confusing.
> >
> > I'm not an expert on this, but I can't see any use for this in
> > sandbox. One problem might be that it should be using map_sysmem()
> > instead of a cast.
>
> No, map_sysmem() doesn't make sense here because gd->env_addr will be
> set to _environment[0], which is a global variable, not any
> (emulated) physical memory address, in env_init().
>
> Please note that 'CONFIG_ENV_ADDR != 0' case doesn't make sense for SPI flash
> because it is not a "memory-mapped" memory in general.

OK I see, thank you. Yes it seems like this should not be used on sandbox.

Regards,
Simon
[..]


Re: Re: dm: core: Board failing to boot since commit 82de42fa1468 (parent data/probe)

2020-02-27 Thread Simon Glass
Hi Wolfgang,

On Mon, 17 Feb 2020 at 03:39, Wolfgang Wallner
 wrote:
>
> Hi Bin, Simon,
>
> -"Bin Meng"  schrieb: -
> > Hi Wolfgang,
> >
> > On Wed, Feb 12, 2020 at 1:14 AM Simon Glass  wrote:
> > >
> > > +Bin
> > >
> > > Hi Wolfgang,
> > >
> > > On Tue, 11 Feb 2020 at 06:59, Wolfgang Wallner
> > >  wrote:
> > > >
> > > > Hello Simon,
> > > >
> > > > Since commit 82de42fa1468 ("dm: core: Allocate parent data separate from
> > > > probing parent") I have trouble booting my board (a custom Apollo Lake 
> > > > design
> > > > booted via Coreboot + U-Boot).
> > > >
> > > > I think this is because the function 
> > > > ns16550_serial_ofdata_to_platdata() of
> > > > the UART driver noew tries to access the PCI bus before it is probed.
> > > > I'm aware of the comment which you have added to pci-uclass.c [1].
> > > >
> > > > So the correct way to fix this would be to adapt the uart driver in 
> > > > ns16550.c?
> > >
> > > Why is the UART being used so early?
>
> board_init_f() calls serial_init(), because it is part of init_sequence_f.
> This leads to device_probe() being called for my UART.
>
> The detailed call stack looks as follows:
>
> FileFunction
> -
> board_f.c   board_init_f()
> serial-uclass.c serial_init()
> serial_find_console_or_panic()
> serial_check_stdout()
> // stdout-path is set to serial0:115200n8
> // serial0 is an alias for the device pciuart2,
> // which is called uart@18,2 in my device tree
> // This device is similar to what is called
> // serial@18,2 in chromebook_coral.dts
> uclass.cuclass_get_device_by_of_offset()
> uclass_get_device_tail()
> device.cdevice_probe()
> // device_probe calls drv->ofdata_to_platdata(),
> // which points to
> // ns16550_serial_ofdata_to_platdata in my case
> ns16550.c   ns16550_serial_ofdata_to_platdata()
> // This is where the PCI access to the
> // uninitialized bus 'pci' happens
>
> > > Also, if you are booting from
> > > coreboot you really shouldn't need to auto-config PCI at all, so
> > > perhaps just disable CONFIG_PCI_PNP?
>
> CONFIG_PCI_PNP is already disabled in my configuration.
>
> > > But I understand that that
> > > changes the build.
> > >
> > > The way I fixed it is to allow the UART to stay at a fixed PCI address:
> > >
> > > 9e11293319 dm: pci: Allow disabling auto-config for a device
>
> I think commit 9e11293319 would be a solution if the problem would be
> CONFIG_PCI_PNP, but that is not the case here.
>
> Just to be sure I have cherry-picked 9e11293319 and added "pci,no-autoconfig;"
> to my UART, but that does not solve my issue.
>
> > Please suggest whether I should get the above patch applied to fix the
> > issue you saw on your board.
>
> I think the issue I see is something different.
>
> And I can't provide a proper review for commit 9e11293319 as I don't
> know the PCI subsystem in U-Boot well enough.

It looks like the dev_read_addr_pci() needs to move into a probe()
function in that driver.

Regards,
Simon


Re: [PATCH] dm: make uclass_find_first_device() return error when no defice is found

2020-02-27 Thread Simon Glass
Hi Masahiro,

On Thu, 27 Feb 2020 at 09:57, Masahiro Yamada  wrote:
>
> Hi Simon,
>
> On Thu, Feb 27, 2020 at 12:33 AM Simon Glass  wrote:
> >
> > Hi Masahiro,
> >
> > On Mon, 24 Feb 2020 at 23:58, Masahiro Yamada
> >  wrote:
> > >
> > > uclass_find_first_device() succeeds even if it cannot find any device.
> > > So, the caller must check the return code and also *devp is not NULL.
> > >
> > > Returning -ENODEV will be sensible in this case.
> > >
> > > Signed-off-by: Masahiro Yamada 
> > > ---
> > >
> > > If this patch is acceptable, I want to fold this
> > > into my pull request because it need it
> > > for my another patch:
> > > http://patchwork.ozlabs.org/patch/1238000/
> > >
> > >  drivers/core/uclass.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > I sort-of agree and have thought about this a lot.
> >
> > But what are you doing in the case of uclass_find_next_device()?
> >
> > Also what about the tests and other code that expects the current behaviour?
>
>
> OK, I will change my caller side.
>
>
>
> I would probably design these functions as follows:
>
> struct udevice *uclass_find_first_device(enum uclass_id id);
>
> struct udevice *uclass_find_next_device(struct udevice *dev);
>
>
> Return the pointer to the device, or NULL if not found.

I think that is fine, since we don't support any other error than -ENODEV.

I did intend to add checks that the structs are correct (by adding
type information into each struct conditional on a DM_DEBUG option)
and returning a special error when something goes wrong. But even then
I think we could just return NULL and -ENODEV in the caller would be
good enough.

Regards,
Simon


Re: [PATCH 1/2] block: ide: use definitions from include/libata.h

2020-02-27 Thread Simon Glass
On Thu, 27 Feb 2020 at 09:28, Heinrich Schuchardt  wrote:
>
> Currently ATA commands are defined both in include/libata.h and
> include/ata.h. Use the command definitions from include/libata.h where
> applicable.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> Resent
> ---
>  drivers/block/ide.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH 2/2] ide: remove duplicate defines form include/ata.h

2020-02-27 Thread Simon Glass
On Thu, 27 Feb 2020 at 09:28, Heinrich Schuchardt  wrote:
>
> ATA commands are already defined in include/libata.h. There is no need to
> duplicate them in include/ata.h.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/ata.h | 34 --
>  1 file changed, 34 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v1 2/3] serial: ns16550: Provide UART base clock speed in ->getinfo()

2020-02-27 Thread Simon Glass
On Thu, 27 Feb 2020 at 07:22, Andy Shevchenko
 wrote:
>
> Some callers may need the UART base clock speed value.
> Provide it in the ->getinfo() callback.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/serial/ns16550.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

>
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index 1fcbc35015..386b5e04c8 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -476,6 +476,7 @@ static int ns16550_serial_getinfo(struct udevice *dev,
> info->reg_width = plat->reg_width;
> info->reg_shift = plat->reg_shift;
> info->reg_offset = plat->reg_offset;
> +   info->clock = plat->clock;

blank line before return

> return 0;
>  }

>
> --
> 2.25.0
>


Re: [PATCH 4/4] make env_entry::callback conditional on !CONFIG_SPL_BUILD

2020-02-27 Thread Simon Glass
On Thu, 27 Feb 2020 at 05:56, Rasmus Villemoes
 wrote:
>
> The callback member of struct env_entry is always NULL for an SPL
> build. Removing it thus saves a bit of run-time memory in the
> SPL (when CONFIG_SPL_ENV_SUPPORT=y) since struct env_entry is embedded
> in struct env_entry_node - i.e. about 2KB for the normal case of
> 512+change hash table entries.
>
> Two small fixups are needed for this, all other references to the
> callback member are already under !CONFIG_SPL_BUILD: Don't initialize
> .callback in set_flags() - hsearch_r doesn't use that value
> anyway. And make env_callback_init() initialize ->callback to NULL for
> a new entry instead of relying on an unused or deleted entry having
> NULL in ->callback.
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  env/callback.c   | 2 ++
>  env/flags.c  | 1 -
>  include/search.h | 2 ++
>  lib/hashtable.c  | 1 -
>  4 files changed, 4 insertions(+), 2 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v5 5/6] test: log: test syslog logging driver

2020-02-27 Thread Simon Glass
On Wed, 26 Feb 2020 at 12:48, Heinrich Schuchardt  wrote:
>
> Provide unit tests for the syslog logging driver.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v5:
> no change
> v4:
> provide more comments
> move uts and expected to a common structure
> expect 'uboot:' not 'uboot[1]:' in syslog message
> v3:
> new patch
> ---
>  test/log/Makefile  |   4 +
>  test/log/syslog_test.c | 280 +
>  2 files changed, 284 insertions(+)
>  create mode 100644 test/log/syslog_test.c

Reviewed-by: Simon Glass 


See below

>
> diff --git a/test/log/Makefile b/test/log/Makefile
> index 98178f5e2b..4c92550f6e 100644
> --- a/test/log/Makefile
> +++ b/test/log/Makefile
> @@ -8,6 +8,10 @@ ifdef CONFIG_UT_LOG
>
>  obj-y += test-main.o
>
> +ifdef CONFIG_SANDBOX
> +obj-$(CONFIG_LOG_SYSLOG) += syslog_test.o
> +endif
> +
>  ifndef CONFIG_LOG
>  obj-$(CONFIG_CONSOLE_RECORD) += nolog_test.o
>  endif
> diff --git a/test/log/syslog_test.c b/test/log/syslog_test.c
> new file mode 100644
> index 00..6ca5760eac
> --- /dev/null
> +++ b/test/log/syslog_test.c
> @@ -0,0 +1,280 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2020, Heinrich Schuchardt 
> + *
> + * Logging function tests for CONFIG_LOG_SYSLOG=y.
> + *
> + * Invoke the test with: ./u-boot -d arch/sandbox/dts/test.dtb
> + */
> +
> +/* Override CONFIG_LOG_MAX_LEVEL */
> +#define LOG_DEBUG
> +
> +#include 
> +#include 

That should be at the end


> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

test/ comes after asm/


Re: [PATCH v1 1/3] dm: serial: Add clock member to struct serial_device_info

2020-02-27 Thread Simon Glass
On Thu, 27 Feb 2020 at 07:22, Andy Shevchenko
 wrote:
>
> Some callers of serial_getinfo() would like to know the UART base
> clock speed in order to make decision what to pass to OS in some
> cases. In particular, ACPI SPCR table expects only certain base
> clock speed and thus we have to act accordingly.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/serial/sandbox.c | 1 +
>  include/serial.h | 3 +++
>  test/dm/serial.c | 1 +
>  3 files changed, 5 insertions(+)

Reviewed-by: Simon Glass 


Re: [PATCH] common/board_f.c: use #ifdefs a little more consistently

2020-02-27 Thread Simon Glass
Hi Rasmus,

On Thu, 27 Feb 2020 at 00:18, Rasmus Villemoes
 wrote:
>
> Some init functions, e.g. print_resetinfo(), are conditionally defined
> depending on some config options, and are correspondingly
> conditionally included in the init_sequence_f[] array.
>
> Others are unconditionally defined and included in init_sequence_f[],
> but have their entire body, sans a mandatory "return 0", conditionally
> compiled.
>
> For the simple cases, switch to the former model, making it a bit more
> consistent. This also makes the U-Boot image very slightly smaller and
> avoids a few useless calls to no-op functions during board_init_f.

Can you check if it definitely does change the size? The reason I ask
is that it inlines those function calls in the normal case, at least
from my inspection.

Using if() is preferable to #if if there is no cost.

>
> Signed-off-by: Rasmus Villemoes 
> ---
>  common/board_f.c | 54 
>  1 file changed, 36 insertions(+), 18 deletions(-)

Regards,
Simon


Re: [PATCH 1/4] env: remove callback.o for an SPL build

2020-02-27 Thread Simon Glass
On Thu, 27 Feb 2020 at 05:56, Rasmus Villemoes
 wrote:
>
> env.h says this about about callback declarations (U_BOOT_ENV_CALLBACK):
>
>  * For SPL these are silently dropped to reduce code size, since environment
>  * callbacks are not supported with SPL.
>
> So env_callback_init() does a lot of work to not find anything in the
> guaranteed empty env_clbk list. Drop callback.o entirely from the link
> and stub out the only public function defined in callback.o. This cuts
> about 600 bytes from the SPL on my ppc build.
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  env/Makefile   | 2 +-
>  include/env_callback.h | 6 ++
>  2 files changed, 7 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 


Re: [PATCH 1/1] doc: driver-model: there is no UCLASS_ETHERNET

2020-02-27 Thread Simon Glass
On Wed, 26 Feb 2020 at 11:19, Heinrich Schuchardt  wrote:
>
> %s/UCLASS_ETHERNET/UCLASS_ETH/g
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> Resenct cc u-boot@lists.denx.de
> ---
>  doc/driver-model/design.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 


Re: [PATCH v1] x86: acpi: Refactor XSDT handling in acpi_add_table()

2020-02-27 Thread Simon Glass
Hi Andy,

On Thu, 27 Feb 2020 at 06:00, Andy Shevchenko
 wrote:
>
> There is no need to have an assignment to NULL for XSDT pointer.
> Therefore, no need to assign it when rsdt_address is not set.
> Because of above changes we may decrease indentation level as well.
>
> While here, drop unnecessary parentheses.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/lib/acpi_table.c | 37 +++--
>  1 file changed, 19 insertions(+), 18 deletions(-)

Could you take a look at the ACPI series?

It was sent out about a month ago and has a refactor to this function.

u-boot-dm/coral-working

Regards,
Simon


>
> diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
> index efc4edf801..421456fc2e 100644
> --- a/arch/x86/lib/acpi_table.c
> +++ b/arch/x86/lib/acpi_table.c
> @@ -109,14 +109,11 @@ static void acpi_add_table(struct acpi_rsdp *rsdp, void 
> *table)
>  {
> int i, entries_num;
> struct acpi_rsdt *rsdt;
> -   struct acpi_xsdt *xsdt = NULL;
> +   struct acpi_xsdt *xsdt;
>
> /* The RSDT is mandatory while the XSDT is not */
> rsdt = (struct acpi_rsdt *)rsdp->rsdt_address;
>
> -   if (rsdp->xsdt_address)
> -   xsdt = (struct acpi_xsdt *)((u32)rsdp->xsdt_address);
> -
> /* This should always be MAX_ACPI_TABLES */
> entries_num = ARRAY_SIZE(rsdt->entry);
>
> @@ -135,30 +132,34 @@ static void acpi_add_table(struct acpi_rsdp *rsdp, void 
> *table)
>
> /* Fix RSDT length or the kernel will assume invalid entries */
> rsdt->header.length = sizeof(struct acpi_table_header) +
> -   (sizeof(u32) * (i + 1));
> +   sizeof(u32) * (i + 1);
>
> /* Re-calculate checksum */
> rsdt->header.checksum = 0;
> rsdt->header.checksum = table_compute_checksum((u8 *)rsdt,
> rsdt->header.length);
>
> +   /* The RSDT is mandatory while the XSDT is not */
> +   if (!rsdp->xsdt_address)
> +   return;
> +
> /*
>  * And now the same thing for the XSDT. We use the same index as for
>  * now we want the XSDT and RSDT to always be in sync in U-Boot
>  */
> -   if (xsdt) {
> -   /* Add table to the XSDT */
> -   xsdt->entry[i] = (u64)(u32)table;
> -
> -   /* Fix XSDT length */
> -   xsdt->header.length = sizeof(struct acpi_table_header) +
> -   (sizeof(u64) * (i + 1));
> -
> -   /* Re-calculate checksum */
> -   xsdt->header.checksum = 0;
> -   xsdt->header.checksum = table_compute_checksum((u8 *)xsdt,
> -   xsdt->header.length);
> -   }
> +   xsdt = (struct acpi_xsdt *)((u32)rsdp->xsdt_address);
> +
> +   /* Add table to the XSDT */
> +   xsdt->entry[i] = (u64)(u32)table;
> +
> +   /* Fix XSDT length */
> +   xsdt->header.length = sizeof(struct acpi_table_header) +
> +   sizeof(u64) * (i + 1);
> +
> +   /* Re-calculate checksum */
> +   xsdt->header.checksum = 0;
> +   xsdt->header.checksum = table_compute_checksum((u8 *)xsdt,
> +   xsdt->header.length);
>  }
>
>  static void acpi_create_facs(struct acpi_facs *facs)
> --
> 2.25.0
>


[v1 PATCH 0/1] Add boot hartid to a Device tree

2020-02-27 Thread Atish Patra
The RISC-V booting protocol requires the hart id to be present in "a0"
register. This is not a problem for bootm/booti commands as they directly
jump to Linux kernel. However, bootefi jumps to a EFI boot stub code in
Linux kernel which acts a loader and jumps to real Linux after terminating
the boot services. This boot stub code has to be aware of the boot hart id
so that it can set it in "a0" before jumping to Linux kernel. Currently,
UEFI protocol doesn't have any mechanism to pass the boot hart id to an
EFI executable. We should keep it this way as this is a RISC-V specific
requirement rather than a UEFI requirement. Out of the all possible options,
device tree seemed to be the best choice to do this job.
The detailed discussion can be found in the following thread (the patch in
discussion is no longer required) 

https://patchwork.ozlabs.org/patch/1233664/

This patch updates the device tree in arch_fixup_fdt() which is common for
all booting commands. As a result, the DT modification doesn't require any
efi related arch specific functions and all DT related modifications are
contained at one place. However, the hart id node will be available for
Linux even if the kernel is booted using bootm command.

Changes from previous version:
1. Renamed the DT node property to "boot-hartid" from "efi-boot-hartid".
2. Changed the property type to u32 instead of u64 for RV32 compatibility.

Atish Patra (1):
riscv: Add boot hartid to Device tree

arch/riscv/lib/bootm.c | 13 +
1 file changed, 13 insertions(+)

--
2.24.0



[v1 PATCH 1/1] riscv: Add boot hartid to Device tree

2020-02-27 Thread Atish Patra
Linux booting protocol mandates that register "a0" contains the hartid.
However, U-boot can not pass the hartid via a0 during via standard UEFI
protocol. DT nodes are commonly used to pass such information to the OS.

Add a DT node under chosen node to indicate the boot hartid. EFI stub
in Linux kernel will parse this node and pass it to the real kernel
in "a0" before jumping to it.

Signed-off-by: Atish Patra 
---
 arch/riscv/lib/bootm.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index fad16901c5f2..dd359a45c2e1 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -28,6 +28,19 @@ __weak void board_quiesce_devices(void)
 
 int arch_fixup_fdt(void *blob)
 {
+   u32 size;
+   int chosen_offset, err;
+
+   size = fdt_totalsize(blob);
+   err  = fdt_open_into(blob, blob, size + 32);
+   if (err < 0) {
+   printf("Device Tree can't be expanded to accommodate new node");
+   return -1;
+   }
+   chosen_offset = fdt_path_offset(blob, "/chosen");
+   fdt_setprop_u32(blob, chosen_offset, "boot-hartid",
+  gd->arch.boot_hart);
+
return 0;
 }
 
-- 
2.24.0



Re: [PATCH 03/18] clk: imx: clk-imxrt1050: setup PLL5 for video in non-SPL

2020-02-27 Thread Fabio Estevam
Hi Giulio,

On Wed, Feb 26, 2020 at 3:16 PM Giulio Benetti
 wrote:

> Oh, I've seen now, need to study it before, but now in my mind it's
> getting more clear how that works. But will this work even if shrinked
> CCF in u-boot can't set parent clocks(at least this is what I've

I haven't checked whether 'assigned-clock-parents' works in U-Boot.

> understood)? I mean, basically here for LCDIF I see that only last
> divider get set for achieving pixel-clock, while all parents are get
> only to recalcute the "last divider parent clock".
>
> Also, I can't understand, is it ok setting PLL5 to 650Mhz and un-bypass
> it? The problem is only about clk_set_parent() for LCDIF?

The problem I saw was about hard coding the parent of LCDIF inside the
clock driver.

> Because if a peripheral would set a PLL5 frequency and another
> peripheral use it as parent, then it would set it again.

Yes, but if we leave the correct clock parent decision to be made in
the board dts, we are safe.


[PATCH 1/2] mx7dsabresd: Add myself as maintainer

2020-02-27 Thread Fabio Estevam
I would like to help co-maintaining this board.

Signed-off-by: Fabio Estevam 
---
 board/freescale/mx7dsabresd/MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/freescale/mx7dsabresd/MAINTAINERS 
b/board/freescale/mx7dsabresd/MAINTAINERS
index 5f805afc58..721321c9cc 100644
--- a/board/freescale/mx7dsabresd/MAINTAINERS
+++ b/board/freescale/mx7dsabresd/MAINTAINERS
@@ -1,5 +1,6 @@
 MX7DSABRESD BOARD
 M: Adrian Alonso 
+M: Fabio Estevam 
 S: Maintained
 F: board/freescale/mx7dsabresd
 F: include/configs/mx7dsabresd.h
-- 
2.17.1



[PATCH 2/2] imx8qxp_mek: Add myself as maintainer

2020-02-27 Thread Fabio Estevam
I would like to help co-maintaining this board.

Signed-off-by: Fabio Estevam 
---
 board/freescale/imx8qxp_mek/MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/freescale/imx8qxp_mek/MAINTAINERS 
b/board/freescale/imx8qxp_mek/MAINTAINERS
index e9bf0b35a3..3a21f5521d 100644
--- a/board/freescale/imx8qxp_mek/MAINTAINERS
+++ b/board/freescale/imx8qxp_mek/MAINTAINERS
@@ -1,5 +1,6 @@
 i.MX8QXP MEK BOARD
 M: Peng Fan 
+M: Fabio Estevam 
 S: Maintained
 F: board/freescale/imx8qxp_mek/
 F: include/configs/imx8qxp_mek.h
-- 
2.17.1



Re: [PATCH] dm: make uclass_find_first_device() return error when no defice is found

2020-02-27 Thread Masahiro Yamada
Hi Simon,

On Thu, Feb 27, 2020 at 12:33 AM Simon Glass  wrote:
>
> Hi Masahiro,
>
> On Mon, 24 Feb 2020 at 23:58, Masahiro Yamada
>  wrote:
> >
> > uclass_find_first_device() succeeds even if it cannot find any device.
> > So, the caller must check the return code and also *devp is not NULL.
> >
> > Returning -ENODEV will be sensible in this case.
> >
> > Signed-off-by: Masahiro Yamada 
> > ---
> >
> > If this patch is acceptable, I want to fold this
> > into my pull request because it need it
> > for my another patch:
> > http://patchwork.ozlabs.org/patch/1238000/
> >
> >  drivers/core/uclass.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> I sort-of agree and have thought about this a lot.
>
> But what are you doing in the case of uclass_find_next_device()?
>
> Also what about the tests and other code that expects the current behaviour?


OK, I will change my caller side.



I would probably design these functions as follows:

struct udevice *uclass_find_first_device(enum uclass_id id);

struct udevice *uclass_find_next_device(struct udevice *dev);


Return the pointer to the device, or NULL if not found.









> >
> > diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
> > index 58b19a421091..3580974f3b85 100644
> > --- a/drivers/core/uclass.c
> > +++ b/drivers/core/uclass.c
> > @@ -227,7 +227,7 @@ int uclass_find_first_device(enum uclass_id id, struct 
> > udevice **devp)
> > if (ret)
> > return ret;
> > if (list_empty(>dev_head))
> > -   return 0;
> > +   return -ENODEV;
> >
> > *devp = list_first_entry(>dev_head, struct udevice, 
> > uclass_node);
> >
> > --
> > 2.17.1
> >
>
> Regards,
> Simon



--
Best Regards
Masahiro Yamada


Re: [PATCH v1 0/2] Add roc-rk3328-cc support

2020-02-27 Thread Peter Geis
On Fri, Feb 14, 2020 at 9:47 AM Loic Devulder  wrote:
>
> This serie add support for roc-rk33239 board from Firefly/Libre
> Computer:
>   - add missing L2 cache entry in rk3328 dts
>   - add roc-rk3328-cc board support
>
> With this we can successfully boot the board with mainline U-Boot and
> binary blob firmwares. Boot with ATF and TPL/SPL partially works: TPL
> works fine but SPL fails to find a bootable device.

I have tpl/spl fully enabled on this device privately.
The SPL fails to find a boot device when booted from the sdcard.
It successfully boots from emmc though.
I believe this is due to the 3.3/1.8 mode switch.

Have you tested off emmc with your patch?

>
> I didn't used the DTS from Linux kernel: USB2 fails in that case, this
> should be corrected but maybe later?
>
> Note: sorry if this serie has been send twice, but I had issue with my
> email server...
>
>
> Loic Devulder (2):
>   rockchip: rk3328: dts: add L2 cache entry
>   rockchip: rk3328: add roc-rk3328-cc support
>
>  arch/arm/dts/Makefile  |   3 +-
>  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi |  16 ++
>  arch/arm/dts/rk3328-roc-cc.dts | 260 +
>  arch/arm/dts/rk3328.dtsi   |  25 ++-
>  arch/arm/mach-rockchip/rk3328/Kconfig  |   1 -
>  board/rockchip/evb_rk3328/MAINTAINERS  |   6 +
>  configs/roc-cc-rk3328_defconfig|  95 +
>  doc/README.rockchip|   9 +-
>  8 files changed, 408 insertions(+), 7 deletions(-)
>  create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3328-roc-cc.dts
>  create mode 100644 configs/roc-cc-rk3328_defconfig
>
> --
> 2.25.0
>


Re: [PATCH 3/3] ARM: uniphier: detect the base of micro support card at run-time

2020-02-27 Thread Masahiro Yamada
On Fri, Feb 14, 2020 at 8:55 PM Masahiro Yamada
 wrote:
>
> The base address 0x43f0 is no longer true for the future SoC.
> Extract the base address from the device tree.
>
> Signed-off-by: Masahiro Yamada 
> ---


Applied to u-boot-uniphier.


>  arch/arm/mach-uniphier/micro-support-card.c | 43 +++--
>  1 file changed, 31 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-uniphier/micro-support-card.c 
> b/arch/arm/mach-uniphier/micro-support-card.c
> index 46879019fdaa..c71470a20429 100644
> --- a/arch/arm/mach-uniphier/micro-support-card.c
> +++ b/arch/arm/mach-uniphier/micro-support-card.c
> @@ -1,39 +1,58 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Copyright (C) 2012-2015 Panasonic Corporation
> - * Copyright (C) 2015-2016 Socionext Inc.
> + * Copyright (C) 2015-2020 Socionext Inc.
>   *   Author: Masahiro Yamada 
>   */
>
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>
>  #include "micro-support-card.h"
>
> -#define MICRO_SUPPORT_CARD_BASE0x43f0
> -#define SMC911X_BASE   ((MICRO_SUPPORT_CARD_BASE) + 0x0)
> -#define LED_BASE   ((MICRO_SUPPORT_CARD_BASE) + 0x9)
> -#define NS16550A_BASE  ((MICRO_SUPPORT_CARD_BASE) + 0xb)
> -#define MICRO_SUPPORT_CARD_RESET   ((MICRO_SUPPORT_CARD_BASE) + 0xd0034)
> -#define MICRO_SUPPORT_CARD_REVISION((MICRO_SUPPORT_CARD_BASE) + 0xd00E0)
> +#define SMC911X_OFFSET 0x0
> +#define LED_OFFSET 0x9
> +#define NS16550A_OFFSET0xb
> +#define MICRO_SUPPORT_CARD_RESET   0xd0034
> +#define MICRO_SUPPORT_CARD_REVISION0xd00e0
>
>  static bool support_card_found;
> +static void __iomem *support_card_base;
>
>  static void support_card_detect(void)
>  {
> DECLARE_GLOBAL_DATA_PTR;
> const void *fdt = gd->fdt_blob;
> int offset;
> +   u64 addr, addr2;
>
> offset = fdt_node_offset_by_compatible(fdt, 0, "smsc,lan9118");
> if (offset < 0)
> return;
>
> +   addr = fdt_get_base_address(fdt, offset);
> +   if (addr == OF_BAD_ADDR)
> +   return;
> +   addr -= SMC911X_OFFSET;
> +
> offset = fdt_node_offset_by_compatible(fdt, 0, "ns16550a");
> if (offset < 0)
> return;
>
> +   addr2 = fdt_get_base_address(fdt, offset);
> +   if (addr2 == OF_BAD_ADDR)
> +   return;
> +   addr2 -= NS16550A_OFFSET;
> +
> +   /* sanity check */
> +   if (addr != addr2)
> +   return;
> +
> +   support_card_base = ioremap(addr, 0x10);
> +
> support_card_found = true;
>  }
>
> @@ -45,19 +64,19 @@ static void support_card_detect(void)
>   */
>  static void support_card_reset_deassert(void)
>  {
> -   writel(0x0001, MICRO_SUPPORT_CARD_RESET);
> +   writel(0x0001, support_card_base + MICRO_SUPPORT_CARD_RESET);
>  }
>
>  static void support_card_reset(void)
>  {
> -   writel(0x00020003, MICRO_SUPPORT_CARD_RESET);
> +   writel(0x00020003, support_card_base + MICRO_SUPPORT_CARD_RESET);
>  }
>
>  static int support_card_show_revision(void)
>  {
> u32 revision;
>
> -   revision = readl(MICRO_SUPPORT_CARD_REVISION);
> +   revision = readl(support_card_base + MICRO_SUPPORT_CARD_REVISION);
> revision &= 0xff;
>
> /* revision 3.6.x card changed the revision format */
> @@ -94,7 +113,7 @@ int board_eth_init(bd_t *bis)
> if (!support_card_found)
> return 0;
>
> -   return smc911x_initialize(0, SMC911X_BASE);
> +   return smc911x_initialize(0, (unsigned long)support_card_base + 
> SMC911X_OFFSET);
>  }
>  #endif
>
> @@ -264,5 +283,5 @@ void led_puts(const char *s)
> s++;
> }
>
> -   writel(~val, LED_BASE);
> +   writel(~val, support_card_base + LED_OFFSET);
>  }
> --
> 2.17.1
>


-- 
Best Regards
Masahiro Yamada


Re: [PATCH 2/3] ARM: uniphier: remove workaround for the NAND write protect

2020-02-27 Thread Masahiro Yamada
On Fri, Feb 14, 2020 at 8:55 PM Masahiro Yamada
 wrote:
>
> This workaround was previously needed for LD4, Pro4, sLD8, Pro5
> SoCs. The boot ROM does not touch this register for PXs2/LD6b or
> later.
>
> Now that the reset signal of the Denali NAND controller is always
> asserted in board_init() then deasserted in the driver, the
> WRITE_PROTECT register gets back to the default value, which means
> the write protect is deasserted.
>
> This workaround can go away entirely.
>
> Signed-off-by: Masahiro Yamada 
> ---

Applied to u-boot-uniphier.



>  arch/arm/mach-uniphier/board_late_init.c | 17 -
>  1 file changed, 17 deletions(-)
>
> diff --git a/arch/arm/mach-uniphier/board_late_init.c 
> b/arch/arm/mach-uniphier/board_late_init.c
> index 793283058c35..378aad0c9c45 100644
> --- a/arch/arm/mach-uniphier/board_late_init.c
> +++ b/arch/arm/mach-uniphier/board_late_init.c
> @@ -14,25 +14,9 @@
>  #include 
>  #include 
>  #include 
> -#include <../drivers/mtd/nand/raw/denali.h>
>
>  #include "init.h"
>
> -static void nand_denali_wp_disable(void)
> -{
> -#ifdef CONFIG_NAND_DENALI
> -   /*
> -* Since the boot rom enables the write protection for NAND boot mode,
> -* it must be disabled somewhere for "nand write", "nand erase", etc.
> -* The workaround is here to not disturb the Denali NAND controller
> -* driver just for a really SoC-specific thing.
> -*/
> -   void __iomem *denali_reg = (void __iomem *)CONFIG_SYS_NAND_REGS_BASE;
> -
> -   writel(WRITE_PROTECT__FLAG, denali_reg + WRITE_PROTECT);
> -#endif
> -}
> -
>  static void uniphier_set_env_fdt_file(void)
>  {
> DECLARE_GLOBAL_DATA_PTR;
> @@ -114,7 +98,6 @@ int board_late_init(void)
> case BOOT_DEVICE_NAND:
> printf("NAND Boot");
> env_set("bootdev", "nand");
> -   nand_denali_wp_disable();
> break;
> case BOOT_DEVICE_NOR:
> printf("NOR Boot");
> --
> 2.17.1
>


-- 
Best Regards
Masahiro Yamada


Re: [PATCH] ARM: uniphier: enable CONFIG_MMC_HS400_SUPPORT for uniphier_v8_defconfig

2020-02-27 Thread Masahiro Yamada
On Thu, Feb 27, 2020 at 8:32 PM Masahiro Yamada
 wrote:
>
> The eMMC controller on LD20 or later supports HS-400 mode. It works on
> a quick test. Enable it in case somebody may want to use it.
>
> Signed-off-by: Masahiro Yamada 
> ---



Applied to u-boot-uniphier.


>  configs/uniphier_v8_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configs/uniphier_v8_defconfig b/configs/uniphier_v8_defconfig
> index 25ab2c5a8158..4514468abf88 100644
> --- a/configs/uniphier_v8_defconfig
> +++ b/configs/uniphier_v8_defconfig
> @@ -39,7 +39,7 @@ CONFIG_I2C_EEPROM=y
>  CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=10
>  CONFIG_SUPPORT_EMMC_RPMB=y
>  CONFIG_SUPPORT_EMMC_BOOT=y
> -CONFIG_MMC_HS200_SUPPORT=y
> +CONFIG_MMC_HS400_SUPPORT=y
>  CONFIG_MMC_UNIPHIER=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_ADMA=y
> --
> 2.17.1
>


-- 
Best Regards
Masahiro Yamada


Re: [PATCH 1/3] ARM: uniphier: move NAND reset assertion to U-Boot proper from SPL

2020-02-27 Thread Masahiro Yamada
On Fri, Feb 14, 2020 at 8:55 PM Masahiro Yamada
 wrote:
>
> The comment /* deassert reset */ is wrong. It asserts the reset.
>
> It no longer needs to stay in SPL. The NAND controller reset is
> handled  in the driver. So, this assert can be moved to the
> board_init() of U-Boot proper.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  arch/arm/mach-uniphier/Makefile|  1 +
>  arch/arm/mach-uniphier/board_init.c|  4 ++
>  arch/arm/mach-uniphier/clk/clk-early-ld4.c |  7 
>  arch/arm/mach-uniphier/init.h  |  8 
>  arch/arm/mach-uniphier/nand-reset.c| 43 ++
>  5 files changed, 56 insertions(+), 7 deletions(-)
>  create mode 100644 arch/arm/mach-uniphier/nand-reset.c
>
> diff --git a/arch/arm/mach-uniphier/Makefile b/arch/arm/mach-uniphier/Makefile
> index 115af244cd55..769778cf5083 100644
> --- a/arch/arm/mach-uniphier/Makefile
> +++ b/arch/arm/mach-uniphier/Makefile
> @@ -22,6 +22,7 @@ endif
>  obj-$(CONFIG_MICRO_SUPPORT_CARD) += micro-support-card.o
>  obj-y += pinctrl-glue.o
>  obj-$(CONFIG_MMC) += mmc-first-dev.o
> +obj-$(CONFIG_NAND_DENALI) += nand-reset.o
>  obj-y += fdt-fixup.o
>
>  endif
> diff --git a/arch/arm/mach-uniphier/board_init.c 
> b/arch/arm/mach-uniphier/board_init.c
> index 99727a300420..4f9cd6e722c1 100644
> --- a/arch/arm/mach-uniphier/board_init.c
> +++ b/arch/arm/mach-uniphier/board_init.c
> @@ -141,6 +141,10 @@ int board_init(void)
>
> support_card_late_init();
>
> +   led_puts("U4");
> +
> +   uniphier_nand_reset_assert();
> +
> led_puts("Uboo");
>
> return 0;
> diff --git a/arch/arm/mach-uniphier/clk/clk-early-ld4.c 
> b/arch/arm/mach-uniphier/clk/clk-early-ld4.c
> index f32f78dd26d8..0f9ce6509768 100644
> --- a/arch/arm/mach-uniphier/clk/clk-early-ld4.c
> +++ b/arch/arm/mach-uniphier/clk/clk-early-ld4.c
> @@ -15,13 +15,6 @@ void uniphier_ld4_early_clk_init(void)
>  {
> u32 tmp;
>
> -   /* deassert reset */
> -   if (spl_boot_device() != BOOT_DEVICE_NAND) {
> -   tmp = readl(sc_base + SC_RSTCTRL);
> -   tmp &= ~SC_RSTCTRL_NRST_NAND;
> -   writel(tmp, sc_base + SC_RSTCTRL);
> -   };
> -
> /* provide clocks */
> tmp = readl(sc_base + SC_CLKCTRL);
> tmp |= SC_CLKCTRL_CEN_SBC | SC_CLKCTRL_CEN_PERI;
> diff --git a/arch/arm/mach-uniphier/init.h b/arch/arm/mach-uniphier/init.h
> index 9dc5b885a5fe..3c77f4885348 100644
> --- a/arch/arm/mach-uniphier/init.h
> +++ b/arch/arm/mach-uniphier/init.h
> @@ -101,6 +101,14 @@ unsigned int uniphier_boot_device_raw(void);
>  int uniphier_have_internal_stm(void);
>  int uniphier_boot_from_backend(void);
>  int uniphier_pin_init(const char *pinconfig_name);
> +
> +#ifdef CONFIG_NAND_DENALI
> +void uniphier_nand_reset_assert(void);
> +#else
> +static inline void uniphier_nand_reset_assert(void)
> +{
> +}
> +#endif
>  #ifdef CONFIG_ARM64
>  void uniphier_mem_map_init(unsigned long dram_base, unsigned long dram_size);
>  #else
> diff --git a/arch/arm/mach-uniphier/nand-reset.c 
> b/arch/arm/mach-uniphier/nand-reset.c
> new file mode 100644
> index ..b8f75a5f189f
> --- /dev/null
> +++ b/arch/arm/mach-uniphier/nand-reset.c
> @@ -0,0 +1,43 @@
> +// SPDX-License-Identifier: GPL-2.0 or later
> +/*
> + * Copyright (C) 2020 Socionext Inc.
> + *   Author: Masahiro Yamada 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "init.h"
> +
> +/*
> + * Assert the Denali NAND controller reset if found.
> + *
> + * On LD4, the bootstrap process starts running after power-on reset 
> regardless
> + * of the boot mode, here the pin-mux is not necessarily set up for NAND, 
> then
> + * the controller is stuck. Assert the controller reset here, and should be
> + * deasserted in the driver after the pin-mux is correctly handled. For other
> + * SoCs, the bootstrap runs only when the boot mode selects ONFi, but it is 
> yet
> + * effective when the boot swap is on. So, the reset should be asserted 
> anyway.
> + */
> +void uniphier_nand_reset_assert(void)
> +{
> +   struct udevice *dev;
> +   struct reset_ctl_bulk resets;
> +   int ret;
> +
> +   ret = uclass_find_first_device(UCLASS_MTD, );
> +   if (ret)
> +   return;

I changed this hunk as follows, and applied to u-boot-uniphier.


index b8f75a5f18..11cadaabd8 100644
--- a/arch/arm/mach-uniphier/nand-reset.c
+++ b/arch/arm/mach-uniphier/nand-reset.c
@@ -28,7 +28,7 @@ void uniphier_nand_reset_assert(void)
int ret;

ret = uclass_find_first_device(UCLASS_MTD, );
-   if (ret)
+   if (ret || !dev)
return;

/* make sure this is the Denali NAND controller */







> +   /* make sure this is the Denali NAND controller */
> +   if (strcmp(dev->driver->name, "denali-nand-dt"))
> +   return;
> +
> +   ret = reset_get_bulk(dev, );
> +   if (ret)
> +   return;
> +
> +   reset_assert_bulk();
> +}
> --
> 

Re: [PATCH] ARM: uniphier: add sdscript, sdboot, sdupdate environment variables

2020-02-27 Thread Masahiro Yamada
On Thu, Feb 13, 2020 at 12:28 PM Masahiro Yamada
 wrote:
>
> Add handy macros:
>
>   - sdscript: source boot.scr in the file system of the SD media
>   - sdboot  : boot the kernel using the images in the file system
>   of the SD media
>   - sdscript: update the boot firmware in the SD media
>   (in raw block sectors)
>
> Signed-off-by: Masahiro Yamada 
> ---

Applied to u-boot-uniphier.


>
>  arch/arm/mach-uniphier/mmc-first-dev.c | 27 ++
>  include/configs/uniphier.h | 11 +++
>  2 files changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-uniphier/mmc-first-dev.c 
> b/arch/arm/mach-uniphier/mmc-first-dev.c
> index 149e662070ff..e2f4f4eb5c7a 100644
> --- a/arch/arm/mach-uniphier/mmc-first-dev.c
> +++ b/arch/arm/mach-uniphier/mmc-first-dev.c
> @@ -9,13 +9,14 @@
>  #include 
>  #include 
>
> -static int find_first_mmc_device(void)
> +static int find_first_mmc_device(bool is_sd)
>  {
> struct mmc *mmc;
> int i;
>
> for (i = 0; (mmc = find_mmc_device(i)); i++) {
> -   if (!mmc_init(mmc) && IS_MMC(mmc))
> +   if (!mmc_init(mmc) &&
> +   ((is_sd && IS_SD(mmc)) || (!is_sd && IS_MMC(mmc
> return i;
> }
>
> @@ -24,14 +25,14 @@ static int find_first_mmc_device(void)
>
>  int mmc_get_env_dev(void)
>  {
> -   return find_first_mmc_device();
> +   return find_first_mmc_device(false);
>  }
>
>  static int do_mmcsetn(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[])
>  {
> int dev;
>
> -   dev = find_first_mmc_device();
> +   dev = find_first_mmc_device(false);
> if (dev < 0)
> return CMD_RET_FAILURE;
>
> @@ -44,3 +45,21 @@ U_BOOT_CMD(
> "Set the first MMC (not SD) dev number to \"mmc_first_dev\" 
> environment",
> ""
>  );
> +
> +static int do_sdsetn(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[])
> +{
> +   int dev;
> +
> +   dev = find_first_mmc_device(true);
> +   if (dev < 0)
> +   return CMD_RET_FAILURE;
> +
> +   env_set_ulong("sd_first_dev", dev);
> +   return CMD_RET_SUCCESS;
> +}
> +
> +U_BOOT_CMD(
> +   sdsetn, 1,  1,  do_sdsetn,
> +   "Set the first SD dev number to \"sd_first_dev\" environment",
> +   ""
> +);
> diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
> index b95fb9c93fa9..55fa85ed6256 100644
> --- a/include/configs/uniphier.h
> +++ b/include/configs/uniphier.h
> @@ -160,6 +160,7 @@
> "emmcboot=mmcsetn && run bootcmd_mmc${mmc_first_dev}\0" \
> "nandboot=run bootcmd_ubifs0\0" \
> "norboot=run tftpboot\0" \
> +   "sdboot=sdsetn && run bootcmd_mmc${sd_first_dev}\0" \
> "usbboot=run bootcmd_usb0\0" \
> "emmcscript=setenv devtype mmc && " \
> "mmcsetn && " \
> @@ -170,6 +171,10 @@
> "ubifsmount ubi0:boot && " \
> "ubifsload ${loadaddr} ${script} && " \
> "source $loadaddr\0" \
> +   "sdscript=setenv devtype mmc && " \
> +   "sdsetn && " \
> +   "setenv devnum ${sd_first_dev} && " \
> +   "run loadscript_fat\0" \
> "norscript=echo Running ${script} from tftp ... && " \
> "tftpboot ${script} &&" \
> "source $loadaddr\0" \
> @@ -196,6 +201,12 @@
> "nand write $loadaddr 0 0x0002 && " \
> "tftpboot $third_image && " \
> "nand write $loadaddr 0x0002 0x001e\0" \
> +   "sdupdate=sdsetn &&" \
> +   "mmc dev $sd_first_dev &&" \
> +   "tftpboot $second_image && " \
> +   "mmc write $loadaddr 0 100 && " \
> +   "tftpboot $third_image && " \
> +   "mmc write $loadaddr 100 f00\0" \
> "usbupdate=usb start &&" \
> "tftpboot $second_image && " \
> "usb write $loadaddr 0 100 && " \
> --
> 2.17.1
>


-- 
Best Regards
Masahiro Yamada


[PATCH 0/2] block: ide: remove duplicate defines form include/ata.h

2020-02-27 Thread Heinrich Schuchardt
This patchset is about removing duplicate constants.

In drivers/block/ide.c use constants from include/libata.h.
In include/ata.h remove constants duplicating constants from
include/libata.h.

Heinrich Schuchardt (2):
  block: ide: use definitions from include/libata.h
  ide: remove duplicate defines form include/ata.h

 drivers/block/ide.c |  8 
 include/ata.h   | 34 --
 2 files changed, 4 insertions(+), 38 deletions(-)

--
2.25.0



[PATCH 1/2] block: ide: use definitions from include/libata.h

2020-02-27 Thread Heinrich Schuchardt
Currently ATA commands are defined both in include/libata.h and
include/ata.h. Use the command definitions from include/libata.h where
applicable.

Signed-off-by: Heinrich Schuchardt 
---
Resent
---
 drivers/block/ide.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/block/ide.c b/drivers/block/ide.c
index 4b8a4eac17..67cc4fbc02 100644
--- a/drivers/block/ide.c
+++ b/drivers/block/ide.c
@@ -231,7 +231,7 @@ unsigned char atapi_issue(int device, unsigned char *ccb, 
int ccblen,
 (unsigned char) ((buflen >> 8) & 0xFF));
ide_outb(device, ATA_DEV_HD, ATA_LBA | ATA_DEVICE(device));

-   ide_outb(device, ATA_COMMAND, ATAPI_CMD_PACKET);
+   ide_outb(device, ATA_COMMAND, ATA_CMD_PACKET);
udelay(50);

mask = ATA_STAT_DRQ | ATA_STAT_BUSY | ATA_STAT_ERR;
@@ -570,7 +570,7 @@ static void ide_ident(struct blk_desc *dev_desc)
/*
 * Start Ident Command
 */
-   ide_outb(device, ATA_COMMAND, ATAPI_CMD_IDENT);
+   ide_outb(device, ATA_COMMAND, ATA_CMD_ID_ATAPI);
/*
 * Wait for completion - ATAPI devices need more time
 * to become ready
@@ -582,7 +582,7 @@ static void ide_ident(struct blk_desc *dev_desc)
/*
 * Start Ident Command
 */
-   ide_outb(device, ATA_COMMAND, ATA_CMD_IDENT);
+   ide_outb(device, ATA_COMMAND, ATA_CMD_ID_ATA);

/*
 * Wait for completion
@@ -966,7 +966,7 @@ ulong ide_read(struct blk_desc *block_dev, lbaint_t blknr, 
lbaint_t blkcnt,

/* first check if the drive is in Powersaving mode, if yes,
 * increase the timeout value */
-   ide_outb(device, ATA_COMMAND, ATA_CMD_CHK_PWR);
+   ide_outb(device, ATA_COMMAND, ATA_CMD_CHK_POWER);
udelay(50);

c = ide_wait(device, IDE_TIME_OUT); /* can't take over 500 ms */
--
2.25.0



[PATCH 2/2] ide: remove duplicate defines form include/ata.h

2020-02-27 Thread Heinrich Schuchardt
ATA commands are already defined in include/libata.h. There is no need to
duplicate them in include/ata.h.

Signed-off-by: Heinrich Schuchardt 
---
 include/ata.h | 34 --
 1 file changed, 34 deletions(-)

diff --git a/include/ata.h b/include/ata.h
index 3f4e4a0234..e35d91941d 100644
--- a/include/ata.h
+++ b/include/ata.h
@@ -70,43 +70,9 @@
 #endif /* ATA_DEVICE */
 #define ATA_LBA0xE0

-/*
- * ATA Commands (only mandatory commands listed here)
- */
-#define ATA_CMD_READ   0x20/* Read Sectors (with retries)  */
-#define ATA_CMD_READN  0x21/* Read Sectors ( no  retries)  */
-#define ATA_CMD_WRITE  0x30/* Write Sectores (with retries)*/
-#define ATA_CMD_WRITEN 0x31/* Write Sectors  ( no  retries)*/
-#define ATA_CMD_VRFY   0x40/* Read Verify  (with retries)  */
-#define ATA_CMD_VRFYN  0x41/* Read verify  ( no  retries)  */
-#define ATA_CMD_SEEK   0x70/* Seek */
-#define ATA_CMD_DIAG   0x90/* Execute Device Diagnostic*/
-#define ATA_CMD_INIT   0x91/* Initialize Device Parameters */
-#define ATA_CMD_RD_MULT0xC4/* Read Multiple*/
-#define ATA_CMD_WR_MULT0xC5/* Write Multiple   */
-#define ATA_CMD_SETMULT0xC6/* Set Multiple Mode*/
-#define ATA_CMD_RD_DMA 0xC8/* Read DMA (with retries)  */
-#define ATA_CMD_RD_DMAN0xC9/* Read DMS ( no  retries)  */
-#define ATA_CMD_WR_DMA 0xCA/* Write DMA (with retries) */
-#define ATA_CMD_WR_DMAN0xCB/* Write DMA ( no  retires) */
-#define ATA_CMD_IDENT  0xEC/* Identify Device  */
-#define ATA_CMD_SETF   0xEF/* Set Features */
-#define ATA_CMD_CHK_PWR0xE5/* Check Power Mode */
-
-#define ATA_CMD_READ_EXT 0x24  /* Read Sectors (with retries)  with 48bit 
addressing */
-#define ATA_CMD_WRITE_EXT  0x34/* Write Sectores (with retries) with 
48bit addressing */
-#define ATA_CMD_VRFY_EXT   0x42/* Read Verify  (with retries)  with 
48bit addressing */
-
-#define ATA_CMD_FLUSH 0xE7 /* Flush drive cache */
-#define ATA_CMD_FLUSH_EXT 0xEA /* Flush drive cache, with 48bit addressing */
-
 /*
  * ATAPI Commands
  */
-#define ATAPI_CMD_IDENT 0xA1 /* Identify AT Atachment Packed Interface Device 
*/
-#define ATAPI_CMD_PACKET 0xA0 /* Packed Command */
-
-
 #define ATAPI_CMD_INQUIRY 0x12
 #define ATAPI_CMD_REQ_SENSE 0x03
 #define ATAPI_CMD_READ_CAP 0x25
--
2.25.0



Re: [PATCH] ARM: uniphier: enable CONFIG_MMC_SDHCI_ADMA for uniphier_v8_defconfig

2020-02-27 Thread Masahiro Yamada
On Tue, Feb 4, 2020 at 8:14 PM Masahiro Yamada
 wrote:
>
> Switch over to ADMA from SDMA.
>
> Signed-off-by: Masahiro Yamada 
> ---

Applied to u-boot-uniphier.

>
>  configs/uniphier_v8_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configs/uniphier_v8_defconfig b/configs/uniphier_v8_defconfig
> index 9ad4bd68b6c8..55f7516e3992 100644
> --- a/configs/uniphier_v8_defconfig
> +++ b/configs/uniphier_v8_defconfig
> @@ -42,7 +42,7 @@ CONFIG_SUPPORT_EMMC_BOOT=y
>  CONFIG_MMC_HS200_SUPPORT=y
>  CONFIG_MMC_UNIPHIER=y
>  CONFIG_MMC_SDHCI=y
> -CONFIG_MMC_SDHCI_SDMA=y
> +CONFIG_MMC_SDHCI_ADMA=y
>  CONFIG_MMC_SDHCI_CADENCE=y
>  CONFIG_MTD=y
>  CONFIG_FLASH_CFI_DRIVER=y
> --
> 2.17.1
>


-- 
Best Regards
Masahiro Yamada


Re: [GIT PULL] TI changes for v2020.04-rc4

2020-02-27 Thread Tom Rini
On Thu, Feb 27, 2020 at 08:48:53AM +0530, Lokesh Vutla wrote:

> Hi Tom,
> 
> Please find the pull request for v2020.04-rc4 containing TI specific changes.
> 
> Travis-CI build: https://travis-ci.org/lokeshvutla/u-boot/builds/655346045 
> 
> Thanks and regards,
> Lokesh
> 
> The following changes since commit 548ce227d3d852455c6395c0cec30af0cda77b09:
> 
>   Prepare v2020.04-rc3 (2020-02-26 07:53:20 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2020.04-rc4
> 
> for you to fetch changes up to 8bef0597e46db229220de3a9c76bf448b290db62:
> 
>   defconfig: k2x_hs: Remove DTB_RESELECT to fix DHCP issue (2020-02-26 
> 18:35:29 +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: Pull request for UEFI sub-system for efi-2020-04-rc4

2020-02-27 Thread Tom Rini
On Wed, Feb 26, 2020 at 07:40:52PM +0100, Heinrich Schuchardt wrote:

> The following changes since commit 548ce227d3d852455c6395c0cec30af0cda77b09:
> 
>   Prepare v2020.04-rc3 (2020-02-26 07:53:20 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2020-04-rc4
> 
> for you to fetch changes up to 76be687288dc618eabd1ef643488cd5bd93f84ff:
> 
>   efi_loader: implement EFI_RT_PROPERTIES_TABLE (2020-02-26 19:32:09 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v1 3/3] x86: acpi: Let OS know that console already had been initialized

2020-02-27 Thread Andy Shevchenko
SPCR has no clue if the UART base clock speed is different to
the default one. However, the SPCR 1.04 defines baud rate 0 as
a preconfigured state of UART and OS is supposed not to touch
the configuration of the serial device.

Linux kernel supports that starting from v5.0, see commit
b413b1abeb21 ("ACPI: SPCR: Consider baud rate 0 as preconfigured state")
for the details.

Signed-off-by: Andy Shevchenko 
---
 arch/x86/lib/acpi_table.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index 66e32f21bd..074987e294 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -471,6 +471,15 @@ static void acpi_create_spcr(struct acpi_spcr *spcr)
spcr->pci_device_id = 0x;
spcr->pci_vendor_id = 0x;
 
+   /*
+* SPCR has no clue if the UART base clock speed is different
+* to the default one. However, the SPCR 1.04 defines baud rate
+* 0 as a preconfigured state of UART and OS is supposed not
+* to touch the configuration of the serial device.
+*/
+   if (serial_info.clock != SERIAL_DEFAULT_CLOCK)
+   spcr->baud_rate = 0;
+
/* Fix checksum */
header->checksum = table_compute_checksum((void *)spcr, header->length);
 }
-- 
2.25.0



[PATCH v1 1/3] dm: serial: Add clock member to struct serial_device_info

2020-02-27 Thread Andy Shevchenko
Some callers of serial_getinfo() would like to know the UART base
clock speed in order to make decision what to pass to OS in some
cases. In particular, ACPI SPCR table expects only certain base
clock speed and thus we have to act accordingly.

Signed-off-by: Andy Shevchenko 
---
 drivers/serial/sandbox.c | 1 +
 include/serial.h | 3 +++
 test/dm/serial.c | 1 +
 3 files changed, 5 insertions(+)

diff --git a/drivers/serial/sandbox.c b/drivers/serial/sandbox.c
index 1af5cc12f3..545ff3f747 100644
--- a/drivers/serial/sandbox.c
+++ b/drivers/serial/sandbox.c
@@ -198,6 +198,7 @@ static int sandbox_serial_getinfo(struct udevice *dev,
.reg_width = 1,
.reg_offset = 0,
.reg_shift = 0,
+   .clock = SERIAL_DEFAULT_CLOCK,
};
 
if (!serial_info)
diff --git a/include/serial.h b/include/serial.h
index 104f34ff91..54b21a0470 100644
--- a/include/serial.h
+++ b/include/serial.h
@@ -139,6 +139,7 @@ enum adr_space_type {
  * @reg_width: size (in bytes) of the IO accesses to the registers
  * @reg_offset:offset to apply to the @addr from the start of the 
registers
  * @reg_shift: quantity to shift the register offsets by
+ * @clock: UART base clock speed in Hz
  * @baudrate:  baud rate
  */
 struct serial_device_info {
@@ -148,10 +149,12 @@ struct serial_device_info {
u8 reg_width;
u8 reg_offset;
u8 reg_shift;
+   unsigned int clock;
unsigned int baudrate;
 };
 
 #define SERIAL_DEFAULT_ADDRESS 0xBADACCE5
+#define SERIAL_DEFAULT_CLOCK   (16 * 115200)
 
 /**
  * struct struct dm_serial_ops - Driver model serial operations
diff --git a/test/dm/serial.c b/test/dm/serial.c
index 3d741a8c36..c6be6ab7ab 100644
--- a/test/dm/serial.c
+++ b/test/dm/serial.c
@@ -29,6 +29,7 @@ static int dm_test_serial(struct unit_test_state *uts)
ut_assertok(serial_getinfo(dev_serial, _serial));
ut_assert(info_serial.type == SERIAL_CHIP_UNKNOWN);
ut_assert(info_serial.addr == SERIAL_DEFAULT_ADDRESS);
+   ut_assert(info_serial.clock == SERIAL_DEFAULT_CLOCK);
/*
 * test with a parameter which is NULL pointer
 */
-- 
2.25.0



[PATCH v1 2/3] serial: ns16550: Provide UART base clock speed in ->getinfo()

2020-02-27 Thread Andy Shevchenko
Some callers may need the UART base clock speed value.
Provide it in the ->getinfo() callback.

Signed-off-by: Andy Shevchenko 
---
 drivers/serial/ns16550.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 1fcbc35015..386b5e04c8 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -476,6 +476,7 @@ static int ns16550_serial_getinfo(struct udevice *dev,
info->reg_width = plat->reg_width;
info->reg_shift = plat->reg_shift;
info->reg_offset = plat->reg_offset;
+   info->clock = plat->clock;
return 0;
 }
 
-- 
2.25.0



[PATCH v1] x86: acpi: Refactor XSDT handling in acpi_add_table()

2020-02-27 Thread Andy Shevchenko
There is no need to have an assignment to NULL for XSDT pointer.
Therefore, no need to assign it when rsdt_address is not set.
Because of above changes we may decrease indentation level as well.

While here, drop unnecessary parentheses.

Signed-off-by: Andy Shevchenko 
---
 arch/x86/lib/acpi_table.c | 37 +++--
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index efc4edf801..421456fc2e 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -109,14 +109,11 @@ static void acpi_add_table(struct acpi_rsdp *rsdp, void 
*table)
 {
int i, entries_num;
struct acpi_rsdt *rsdt;
-   struct acpi_xsdt *xsdt = NULL;
+   struct acpi_xsdt *xsdt;
 
/* The RSDT is mandatory while the XSDT is not */
rsdt = (struct acpi_rsdt *)rsdp->rsdt_address;
 
-   if (rsdp->xsdt_address)
-   xsdt = (struct acpi_xsdt *)((u32)rsdp->xsdt_address);
-
/* This should always be MAX_ACPI_TABLES */
entries_num = ARRAY_SIZE(rsdt->entry);
 
@@ -135,30 +132,34 @@ static void acpi_add_table(struct acpi_rsdp *rsdp, void 
*table)
 
/* Fix RSDT length or the kernel will assume invalid entries */
rsdt->header.length = sizeof(struct acpi_table_header) +
-   (sizeof(u32) * (i + 1));
+   sizeof(u32) * (i + 1);
 
/* Re-calculate checksum */
rsdt->header.checksum = 0;
rsdt->header.checksum = table_compute_checksum((u8 *)rsdt,
rsdt->header.length);
 
+   /* The RSDT is mandatory while the XSDT is not */
+   if (!rsdp->xsdt_address)
+   return;
+
/*
 * And now the same thing for the XSDT. We use the same index as for
 * now we want the XSDT and RSDT to always be in sync in U-Boot
 */
-   if (xsdt) {
-   /* Add table to the XSDT */
-   xsdt->entry[i] = (u64)(u32)table;
-
-   /* Fix XSDT length */
-   xsdt->header.length = sizeof(struct acpi_table_header) +
-   (sizeof(u64) * (i + 1));
-
-   /* Re-calculate checksum */
-   xsdt->header.checksum = 0;
-   xsdt->header.checksum = table_compute_checksum((u8 *)xsdt,
-   xsdt->header.length);
-   }
+   xsdt = (struct acpi_xsdt *)((u32)rsdp->xsdt_address);
+
+   /* Add table to the XSDT */
+   xsdt->entry[i] = (u64)(u32)table;
+
+   /* Fix XSDT length */
+   xsdt->header.length = sizeof(struct acpi_table_header) +
+   sizeof(u64) * (i + 1);
+
+   /* Re-calculate checksum */
+   xsdt->header.checksum = 0;
+   xsdt->header.checksum = table_compute_checksum((u8 *)xsdt,
+   xsdt->header.length);
 }
 
 static void acpi_create_facs(struct acpi_facs *facs)
-- 
2.25.0



[PATCH 0/4] remove (more) env callback code for SPL

2020-02-27 Thread Rasmus Villemoes
The actual environment callbacks are automatically dropped from an SPL
build, but the support code (env/callback.o) for associating a
callback to an environment variable is still there.

These patches reduce a CONFIG_SPL_ENV_SUPPORT=y SPL image by about 1K
(at least for my ppc build), and another ~2K of run-time memory.

===

Aside:

While poking around in this code, I noticed a few somewhat related
bugs in callback.o: (1) The caching of env_get(".callbacks") in
env_callback_init() is dubious at best: It gets called during the
initial import, so env_get ends up calling env_get_f. So either we
cache a value of NULL (no .callbacks variable in initial environment),
or we cache a value of gd->env_buf. Now, of course env_get_f will soon
no longer be used, so there's not a big risk that gd->env_buf will be
overwritten, but it's rather fragile. In either case (2), the cache is
not invalidated or updated by the on_callbacks() callback associated
to .callbacks itself.

Finally, (3) with CONFIG_REGEX=y, that on_callbacks() function has the
unfortunate effect of removing itself as the callback associated to
.callbacks: When .callbacks is initially added to the environment,
env_callback_init() correctly associates on_callbacks, because it uses
env_attr_lookup() (which is regex-aware) on the
ENV_CALLBACK_STATIC_LIST. Now, when .callbacks is set the next time,
on_callbacks() is called, starts by clearing all callbacks, including
the one for .callbacks. It then tries to initialize them again, but it
uses env_attr_walk() (which roughly speaking just splits the given
string on , and : and calls back to the user's handler) on
ENV_CALLBACK_STATIC_LIST, which means that set_callback() gets called
with the string "\.callbacks" - and such a variable does not
exist. set_callback() is never called with ".callbacks" as name, so
.callbacks (and e.g. eth5addr - anything else which is supposed to be
matched by a regex) now no longer has a callback.

Perhaps this can all be fixed by just having on_callbacks update the
cached static callback_list with value, then do a hwalk_r(_htab,
env_callback_init) - no need for either set_callback or clear_callback.

Rasmus Villemoes (4):
  env: remove callback.o for an SPL build
  lib/hashtable.c: create helper for calling env_entry::callback
  lib/hashtable.c: don't test ->callback in SPL
  make env_entry::callback conditional on !CONFIG_SPL_BUILD

 env/Makefile   |  2 +-
 env/callback.c |  2 ++
 env/flags.c|  1 -
 include/env_callback.h |  6 ++
 include/search.h   |  2 ++
 lib/hashtable.c| 26 +-
 6 files changed, 28 insertions(+), 11 deletions(-)

-- 
2.23.0



[PATCH 1/4] env: remove callback.o for an SPL build

2020-02-27 Thread Rasmus Villemoes
env.h says this about about callback declarations (U_BOOT_ENV_CALLBACK):

 * For SPL these are silently dropped to reduce code size, since environment
 * callbacks are not supported with SPL.

So env_callback_init() does a lot of work to not find anything in the
guaranteed empty env_clbk list. Drop callback.o entirely from the link
and stub out the only public function defined in callback.o. This cuts
about 600 bytes from the SPL on my ppc build.

Signed-off-by: Rasmus Villemoes 
---
 env/Makefile   | 2 +-
 include/env_callback.h | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/env/Makefile b/env/Makefile
index e2a165b8f1..c4ad654328 100644
--- a/env/Makefile
+++ b/env/Makefile
@@ -7,9 +7,9 @@ obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += common.o
 obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += env.o
 obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += attr.o
 obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += flags.o
-obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += callback.o
 
 ifndef CONFIG_SPL_BUILD
+obj-y += callback.o
 obj-$(CONFIG_ENV_IS_IN_EEPROM) += eeprom.o
 extra-$(CONFIG_ENV_IS_EMBEDDED) += embedded.o
 obj-$(CONFIG_ENV_IS_IN_EEPROM) += embedded.o
diff --git a/include/env_callback.h b/include/env_callback.h
index 74da20eec3..05e9516a0f 100644
--- a/include/env_callback.h
+++ b/include/env_callback.h
@@ -72,6 +72,12 @@
"serial#:serialno," \
CONFIG_ENV_CALLBACK_LIST_STATIC
 
+#ifndef CONFIG_SPL_BUILD
 void env_callback_init(struct env_entry *var_entry);
+#else
+static inline void env_callback_init(struct env_entry *var_entry)
+{
+}
+#endif
 
 #endif /* __ENV_CALLBACK_H__ */
-- 
2.23.0



[PATCH 2/4] lib/hashtable.c: create helper for calling env_entry::callback

2020-02-27 Thread Rasmus Villemoes
This is preparation for compiling out the "call the callback" code and
associated error handling for SPL, where ->callback is always NULL.

Signed-off-by: Rasmus Villemoes 
---
 lib/hashtable.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/lib/hashtable.c b/lib/hashtable.c
index 907e8a642f..574ec6af86 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -222,6 +222,15 @@ int hmatch_r(const char *match, int last_idx, struct 
env_entry **retval,
return 0;
 }
 
+static int
+do_callback(const struct env_entry *e, const char *name, const char *value,
+   enum env_op op, int flags)
+{
+   if (e->callback)
+   return e->callback(name, value, op, flags);
+   return 0;
+}
+
 /*
  * Compare an existing entry with the desired key, and overwrite if the action
  * is ENV_ENTER.  This is simply a helper function for hsearch_r().
@@ -247,9 +256,8 @@ static inline int _compare_and_overwrite_entry(struct 
env_entry item,
}
 
/* If there is a callback, call it */
-   if (htab->table[idx].entry.callback &&
-   htab->table[idx].entry.callback(item.key,
-   item.data, env_op_overwrite, flag)) {
+   if (do_callback(>table[idx].entry, item.key,
+   item.data, env_op_overwrite, flag)) {
debug("callback() rejected setting variable "
"%s, skipping it!\n", item.key);
__set_errno(EINVAL);
@@ -402,9 +410,8 @@ int hsearch_r(struct env_entry item, enum env_action action,
}
 
/* If there is a callback, call it */
-   if (htab->table[idx].entry.callback &&
-   htab->table[idx].entry.callback(item.key, item.data,
-   env_op_create, flag)) {
+   if (do_callback(>table[idx].entry, item.key, item.data,
+   env_op_create, flag)) {
debug("callback() rejected setting variable "
"%s, skipping it!\n", item.key);
_hdelete(item.key, htab, >table[idx].entry, idx);
@@ -473,8 +480,8 @@ int hdelete_r(const char *key, struct hsearch_data *htab, 
int flag)
}
 
/* If there is a callback, call it */
-   if (htab->table[idx].entry.callback &&
-   htab->table[idx].entry.callback(key, NULL, env_op_delete, flag)) {
+   if (do_callback(>table[idx].entry, key, NULL,
+   env_op_delete, flag)) {
debug("callback() rejected deleting variable "
"%s, skipping it!\n", key);
__set_errno(EINVAL);
-- 
2.23.0



[PATCH 3/4] lib/hashtable.c: don't test ->callback in SPL

2020-02-27 Thread Rasmus Villemoes
In SPL, environment callbacks are not supported, so e->callback is
always NULL. Removing this makes the SPL a little smaller (about 400
bytes in my ppc build) with no functional change.

Signed-off-by: Rasmus Villemoes 
---
 lib/hashtable.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/hashtable.c b/lib/hashtable.c
index 574ec6af86..c4e1e2bd45 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -226,8 +226,10 @@ static int
 do_callback(const struct env_entry *e, const char *name, const char *value,
enum env_op op, int flags)
 {
+#ifndef CONFIG_SPL_BUILD
if (e->callback)
return e->callback(name, value, op, flags);
+#endif
return 0;
 }
 
-- 
2.23.0



[PATCH 4/4] make env_entry::callback conditional on !CONFIG_SPL_BUILD

2020-02-27 Thread Rasmus Villemoes
The callback member of struct env_entry is always NULL for an SPL
build. Removing it thus saves a bit of run-time memory in the
SPL (when CONFIG_SPL_ENV_SUPPORT=y) since struct env_entry is embedded
in struct env_entry_node - i.e. about 2KB for the normal case of
512+change hash table entries.

Two small fixups are needed for this, all other references to the
callback member are already under !CONFIG_SPL_BUILD: Don't initialize
.callback in set_flags() - hsearch_r doesn't use that value
anyway. And make env_callback_init() initialize ->callback to NULL for
a new entry instead of relying on an unused or deleted entry having
NULL in ->callback.

Signed-off-by: Rasmus Villemoes 
---
 env/callback.c   | 2 ++
 env/flags.c  | 1 -
 include/search.h | 2 ++
 lib/hashtable.c  | 1 -
 4 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/env/callback.c b/env/callback.c
index f0904cfdc5..4054b9ef58 100644
--- a/env/callback.c
+++ b/env/callback.c
@@ -55,6 +55,8 @@ void env_callback_init(struct env_entry *var_entry)
first_call = 0;
}
 
+   var_entry->callback = NULL;
+
/* look in the ".callbacks" var for a reference to this variable */
if (callback_list != NULL)
ret = env_attr_lookup(callback_list, var_name, callback_name);
diff --git a/env/flags.c b/env/flags.c
index 418d6cc742..b88fe7ba9c 100644
--- a/env/flags.c
+++ b/env/flags.c
@@ -457,7 +457,6 @@ static int set_flags(const char *name, const char *value, 
void *priv)
 
e.key   = name;
e.data  = NULL;
-   e.callback = NULL;
hsearch_r(e, ENV_FIND, , _htab, 0);
 
/* does the env variable actually exist? */
diff --git a/include/search.h b/include/search.h
index 0469a852e0..8f87dc72ce 100644
--- a/include/search.h
+++ b/include/search.h
@@ -29,8 +29,10 @@ enum env_action {
 struct env_entry {
const char *key;
char *data;
+#ifndef CONFIG_SPL_BUILD
int (*callback)(const char *name, const char *value, enum env_op op,
int flags);
+#endif
int flags;
 };
 
diff --git a/lib/hashtable.c b/lib/hashtable.c
index c4e1e2bd45..f82f2463cf 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -450,7 +450,6 @@ static void _hdelete(const char *key, struct hsearch_data 
*htab,
debug("hdelete: DELETING key \"%s\"\n", key);
free((void *)ep->key);
free(ep->data);
-   ep->callback = NULL;
ep->flags = 0;
htab->table[idx].used = USED_DELETED;
 
-- 
2.23.0



Re: Starting u-boot in USB otg mode

2020-02-27 Thread mRbinG
Maxime Ripard wrote
> On Thu, Sep 07, 2017 at 01:23:32PM +0300, rivael_il wrote:
>> 
>> Hello Maxime!
>> 
>> Thank you for your answer.
>> How can I set "peripheral" mode on the USB in u-boot?
> 
> Enable CONFIG_USB_MUSB_GADGET instead of HOST.
> 
> Maxime

In which file should this be done?
I need this for enabling the fastboot feature in u-boot itself, what are the
next steps after this?



--
Sent from: http://u-boot.10912.n7.nabble.com/


[PATCH v2 4/6] arm64: dts: meson: sync dt and bindings from v5.6-rc2

2020-02-27 Thread Jerome Brunet
Sync the device tree and dt-bindings from Linux v5.6-rc2
11a48a5a18c6 ("Linux 5.6-rc2")

The only exception to this is the mmc pinctrl pin bias of gxl SoC family.
This is a fix which found its way to u-boot but not Linux yet.

Signed-off-by: Jerome Brunet 
---
 arch/arm/dts/meson-axg-s400.dts   |  70 ++-
 arch/arm/dts/meson-axg.dtsi   | 273 --
 arch/arm/dts/meson-g12-common.dtsi| 478 ++
 arch/arm/dts/meson-g12.dtsi   | 398 +++
 arch/arm/dts/meson-g12a-sei510.dts|  64 +++
 arch/arm/dts/meson-g12a-u200.dts  |  54 ++
 arch/arm/dts/meson-g12a.dtsi  |  33 +-
 arch/arm/dts/meson-g12b-a311d-khadas-vim3.dts |  25 +
 arch/arm/dts/meson-g12b-odroid-n2.dts |   2 +-
 arch/arm/dts/meson-g12b.dtsi  |  26 +-
 arch/arm/dts/meson-gx.dtsi|  87 +++-
 arch/arm/dts/meson-gxbb-nanopi-k2.dts |  26 +-
 arch/arm/dts/meson-gxbb-odroidc2.dts  | 100 +++-
 arch/arm/dts/meson-gxbb-p200.dts  |   9 +-
 arch/arm/dts/meson-gxbb-p201.dts  |   2 +-
 arch/arm/dts/meson-gxbb-p20x.dtsi |   9 +-
 arch/arm/dts/meson-gxbb.dtsi  | 118 -
 arch/arm/dts/meson-gxl-s805x-libretech-ac.dts |   2 +-
 arch/arm/dts/meson-gxl-s905x-khadas-vim.dts   |  20 +-
 arch/arm/dts/meson-gxl-s905x-libretech-cc.dts |  26 +-
 arch/arm/dts/meson-gxl-s905x-p212.dtsi|  10 +-
 arch/arm/dts/meson-gxl.dtsi   |  76 ++-
 arch/arm/dts/meson-gxm-khadas-vim2.dts|  71 +--
 arch/arm/dts/meson-gxm.dtsi   |  39 +-
 arch/arm/dts/meson-khadas-vim3.dtsi   |   7 +
 arch/arm/dts/meson-sm1-khadas-vim3l.dts   |  95 
 arch/arm/dts/meson-sm1-sei610.dts | 236 -
 arch/arm/dts/meson-sm1.dtsi   | 356 +
 include/dt-bindings/clock/axg-audio-clkc.h|  10 +
 include/dt-bindings/clock/gxbb-aoclkc.h   |   7 +
 include/dt-bindings/clock/gxbb-clkc.h |  21 +
 include/dt-bindings/gpio/meson-gxbb-gpio.h|   8 +-
 include/dt-bindings/gpio/meson-gxl-gpio.h |   8 +-
 .../reset/amlogic,meson-axg-audio-arb.h   |   2 +
 .../reset/amlogic,meson-axg-reset.h   |   3 +-
 .../reset/amlogic,meson-g12a-audio-reset.h|  15 +
 .../reset/amlogic,meson-gxbb-reset.h  |  51 +-
 37 files changed, 2214 insertions(+), 623 deletions(-)
 create mode 100644 arch/arm/dts/meson-g12.dtsi
 create mode 100644 arch/arm/dts/meson-sm1-khadas-vim3l.dts

diff --git a/arch/arm/dts/meson-axg-s400.dts b/arch/arm/dts/meson-axg-s400.dts
index 18778ada7bd3..4cd2d5951822 100644
--- a/arch/arm/dts/meson-axg-s400.dts
+++ b/arch/arm/dts/meson-axg-s400.dts
@@ -60,7 +60,7 @@
serial1 = _A;
};
 
-   linein: audio-codec@0 {
+   linein: audio-codec-0 {
#sound-dai-cells = <0>;
compatible = "everest,es7241";
VDDA-supply = <_3v3>;
@@ -70,7 +70,7 @@
sound-name-prefix = "Linein";
};
 
-   lineout: audio-codec@1 {
+   lineout: audio-codec-1 {
#sound-dai-cells = <0>;
compatible = "everest,es7154";
VDD-supply = <_3v3>;
@@ -79,14 +79,14 @@
sound-name-prefix = "Lineout";
};
 
-   spdif_dit: audio-codec@2 {
+   spdif_dit: audio-codec-2 {
#sound-dai-cells = <0>;
compatible = "linux,spdif-dit";
status = "okay";
sound-name-prefix = "DIT";
};
 
-   dmics: audio-codec@3 {
+   dmics: audio-codec-3 {
#sound-dai-cells = <0>;
compatible = "dmic-codec";
num-channels = <7>;
@@ -95,6 +95,13 @@
sound-name-prefix = "MIC";
};
 
+   spdif_dir: audio-codec-4 {
+   #sound-dai-cells = <0>;
+   compatible = "linux,spdif-dir";
+   status = "okay";
+   sound-name-prefix = "DIR";
+   };
+
emmc_pwrseq: emmc-pwrseq {
compatible = "mmc-pwrseq-emmc";
reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
@@ -249,6 +256,9 @@
"TODDR_A IN 2", "TDMIN_C OUT",
"TODDR_B IN 2", "TDMIN_C OUT",
"TODDR_C IN 2", "TDMIN_C OUT",
+   "TODDR_A IN 3", "SPDIFIN Capture",
+   "TODDR_B IN 3", "SPDIFIN Capture",
+   "TODDR_C IN 3", "SPDIFIN Capture",
"TODDR_A IN 4", "PDM Capture",
"TODDR_B IN 4", "PDM Capture",
"TODDR_C IN 4", "PDM Capture",
@@ -272,31 +282,31 @@
   <393216000>;
status = "okay";
 
-   dai-link@0 {
+   dai-link-0 {

Re: Starting u-boot in USB otg mode

2020-02-27 Thread mRbinG
Maxime Ripard wrote
> Both are peripheral-only features, not OTG. OTG is about switching
> from peripheral to host based on the ID-pin, and this what is not
> supported in U-Boot.
> 
> However, peripheral is, and it's already supported for the Allwinner
> SoCs. We use it for things like fastboot. I'm not sure what this has
> to do with fel though.
> 
> Maxime

It would be really helpful if you could guide me to enable the fastboot
feature in u-boot for linux & NOT android.



--
Sent from: http://u-boot.10912.n7.nabble.com/


[PATCH] ARM: uniphier: enable CONFIG_MMC_HS400_SUPPORT for uniphier_v8_defconfig

2020-02-27 Thread Masahiro Yamada
The eMMC controller on LD20 or later supports HS-400 mode. It works on
a quick test. Enable it in case somebody may want to use it.

Signed-off-by: Masahiro Yamada 
---

 configs/uniphier_v8_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/uniphier_v8_defconfig b/configs/uniphier_v8_defconfig
index 25ab2c5a8158..4514468abf88 100644
--- a/configs/uniphier_v8_defconfig
+++ b/configs/uniphier_v8_defconfig
@@ -39,7 +39,7 @@ CONFIG_I2C_EEPROM=y
 CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=10
 CONFIG_SUPPORT_EMMC_RPMB=y
 CONFIG_SUPPORT_EMMC_BOOT=y
-CONFIG_MMC_HS200_SUPPORT=y
+CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_MMC_UNIPHIER=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ADMA=y
-- 
2.17.1



[PATCH v2 3/6] clk: meson: reset mmc clock on probe

2020-02-27 Thread Jerome Brunet
On some SoCs, depending on the boot device, the MMC clock block may be
left in a weird state by the ROM code, in which no decent clock may be
provided. Reset the related register to make sure a sane MMC clock is
ready for the controller.

Reviewed-by: Neil Armstrong 
Tested-by: Anand Moon 
Signed-off-by: Jerome Brunet 
---
 drivers/clk/meson/axg.c  | 7 +++
 drivers/clk/meson/g12a.c | 7 +++
 drivers/clk/meson/gxbb.c | 7 +++
 3 files changed, 21 insertions(+)

diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
index 32cbf752aed8..0ba6c303e122 100644
--- a/drivers/clk/meson/axg.c
+++ b/drivers/clk/meson/axg.c
@@ -290,6 +290,13 @@ static int meson_clk_probe(struct udevice *dev)
if (IS_ERR(priv->map))
return PTR_ERR(priv->map);
 
+   /*
+* Depending on the boot src, the state of the MMC clock might
+* be different. Reset it to make sure we won't get stuck
+*/
+   regmap_write(priv->map, HHI_NAND_CLK_CNTL, 0);
+   regmap_write(priv->map, HHI_SD_EMMC_CLK_CNTL, 0);
+
debug("meson-clk-axg: probed\n");
 
return 0;
diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c
index 1b2523bbf1fe..03d885d986b8 100644
--- a/drivers/clk/meson/g12a.c
+++ b/drivers/clk/meson/g12a.c
@@ -976,6 +976,13 @@ static int meson_clk_probe(struct udevice *dev)
if (IS_ERR(priv->map))
return PTR_ERR(priv->map);
 
+   /*
+* Depending on the boot src, the state of the MMC clock might
+* be different. Reset it to make sure we won't get stuck
+*/
+   regmap_write(priv->map, HHI_NAND_CLK_CNTL, 0);
+   regmap_write(priv->map, HHI_SD_EMMC_CLK_CNTL, 0);
+
debug("meson-clk-g12a: probed\n");
 
return 0;
diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index abb5337e7829..aedba991603f 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -886,6 +886,13 @@ static int meson_clk_probe(struct udevice *dev)
if (IS_ERR(priv->map))
return PTR_ERR(priv->map);
 
+   /*
+* Depending on the boot src, the state of the MMC clock might
+* be different. Reset it to make sure we won't get stuck
+*/
+   regmap_write(priv->map, HHI_NAND_CLK_CNTL, 0);
+   regmap_write(priv->map, HHI_SD_EMMC_CLK_CNTL, 0);
+
debug("meson-clk: probed\n");
 
return 0;
-- 
2.24.1



[PATCH v2 6/6] arm64: dts: meson: add libretech-pc support

2020-02-27 Thread Jerome Brunet
Add support for the Amlogic based libretech-pc platform.
This platform comes with 2 variant, based on the s905d or s912 SoC.

Signed-off-by: Jerome Brunet 
---
 arch/arm/dts/Makefile |  2 +
 .../meson-gxl-s905d-libretech-pc-u-boot.dtsi  |  7 ++
 .../meson-gxm-s912-libretech-pc-u-boot.dtsi   |  7 ++
 configs/libretech-s905d-pc_defconfig  | 71 +++
 configs/libretech-s912-pc_defconfig   | 71 +++
 include/configs/libretech-pc.h| 17 +
 6 files changed, 175 insertions(+)
 create mode 100644 arch/arm/dts/meson-gxl-s905d-libretech-pc-u-boot.dtsi
 create mode 100644 arch/arm/dts/meson-gxm-s912-libretech-pc-u-boot.dtsi
 create mode 100644 configs/libretech-s905d-pc_defconfig
 create mode 100644 configs/libretech-s912-pc_defconfig
 create mode 100644 include/configs/libretech-pc.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 3b8dc2f56fd2..45120d8f20ce 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -137,7 +137,9 @@ dtb-$(CONFIG_ARCH_MESON) += \
meson-gxl-s805x-libretech-ac.dtb \
meson-gxl-s905x-libretech-cc.dtb \
meson-gxl-s905x-khadas-vim.dtb \
+   meson-gxl-s905d-libretech-pc.dtb \
meson-gxm-khadas-vim2.dtb \
+   meson-gxm-s912-libretech-pc.dtb \
meson-axg-s400.dtb \
meson-g12a-u200.dtb \
meson-g12a-sei510.dtb \
diff --git a/arch/arm/dts/meson-gxl-s905d-libretech-pc-u-boot.dtsi 
b/arch/arm/dts/meson-gxl-s905d-libretech-pc-u-boot.dtsi
new file mode 100644
index ..c35158d7e9ee
--- /dev/null
+++ b/arch/arm/dts/meson-gxl-s905d-libretech-pc-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ */
+
+#include "meson-gx-u-boot.dtsi"
diff --git a/arch/arm/dts/meson-gxm-s912-libretech-pc-u-boot.dtsi 
b/arch/arm/dts/meson-gxm-s912-libretech-pc-u-boot.dtsi
new file mode 100644
index ..c35158d7e9ee
--- /dev/null
+++ b/arch/arm/dts/meson-gxm-s912-libretech-pc-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ */
+
+#include "meson-gx-u-boot.dtsi"
diff --git a/configs/libretech-s905d-pc_defconfig 
b/configs/libretech-s905d-pc_defconfig
new file mode 100644
index ..0dbacf60046a
--- /dev/null
+++ b/configs/libretech-s905d-pc_defconfig
@@ -0,0 +1,71 @@
+CONFIG_ARM=y
+CONFIG_SYS_CONFIG_NAME="libretech-pc"
+CONFIG_SYS_BOARD="q200"
+CONFIG_ARCH_MESON=y
+CONFIG_SYS_TEXT_BASE=0x0100
+CONFIG_MESON_GXL=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEBUG_UART_BASE=0xc81004c0
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_IDENT_STRING=" libretech-s905d-pc"
+CONFIG_DEBUG_UART=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_USE_PREBOOT=y
+CONFIG_PREBOOT="usb start"
+CONFIG_MISC_INIT_R=y
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_CMD_BDI is not set
+# CONFIG_CMD_IMI is not set
+CONFIG_CMD_ADC=y
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SF_TEST=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_REGULATOR=y
+CONFIG_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="meson-gxl-s905d-libretech-pc"
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SARADC_MESON=y
+CONFIG_DM_GPIO=y
+CONFIG_DM_KEYBOARD=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_MESON_GX=y
+CONFIG_MTD=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_PHY_REALTEK=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_PHY=y
+CONFIG_MESON_GXL_USB_PHY=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_MESON_GXL=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_MESON_GX_VPU_POWER_DOMAIN=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_RESET=y
+CONFIG_DEBUG_UART_MESON=y
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_DEBUG_UART_SKIP_INIT=y
+CONFIG_MESON_SERIAL=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_MESON_SPIFC=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_XHCI_DWC3_OF_SIMPLE=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_KEYBOARD=y
+CONFIG_DM_VIDEO=y
+CONFIG_SYS_WHITE_ON_BLACK=y
+CONFIG_VIDEO_MESON=y
+CONFIG_VIDEO_DT_SIMPLEFB=y
+CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/configs/libretech-s912-pc_defconfig 
b/configs/libretech-s912-pc_defconfig
new file mode 100644
index ..63b44b389be6
--- /dev/null
+++ b/configs/libretech-s912-pc_defconfig
@@ -0,0 +1,71 @@
+CONFIG_ARM=y
+CONFIG_SYS_CONFIG_NAME="libretech-pc"
+CONFIG_SYS_BOARD="q200"
+CONFIG_ARCH_MESON=y
+CONFIG_SYS_TEXT_BASE=0x0100
+CONFIG_MESON_GXM=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEBUG_UART_BASE=0xc81004c0
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_IDENT_STRING=" libretech-s912-pc"
+CONFIG_DEBUG_UART=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_USE_PREBOOT=y
+CONFIG_PREBOOT="usb start"
+CONFIG_MISC_INIT_R=y
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_CMD_BDI is not set
+# CONFIG_CMD_IMI is not set
+CONFIG_CMD_ADC=y
+CONFIG_CMD_GPIO=y
+# 

[PATCH v2 5/6] arm64: dts: meson: import libretech-pc from linux v5.6-rc2

2020-02-27 Thread Jerome Brunet
Sync the libretech-pc device tree from Linux v5.6-rc2
11a48a5a18c6 ("Linux 5.6-rc2")

Signed-off-by: Jerome Brunet 
---
 arch/arm/dts/meson-gx-libretech-pc.dtsi   | 375 ++
 arch/arm/dts/meson-gxl-s905d-libretech-pc.dts |  16 +
 arch/arm/dts/meson-gxl-s905d.dtsi |  12 +
 arch/arm/dts/meson-gxm-s912-libretech-pc.dts  |  62 +++
 4 files changed, 465 insertions(+)
 create mode 100644 arch/arm/dts/meson-gx-libretech-pc.dtsi
 create mode 100644 arch/arm/dts/meson-gxl-s905d-libretech-pc.dts
 create mode 100644 arch/arm/dts/meson-gxl-s905d.dtsi
 create mode 100644 arch/arm/dts/meson-gxm-s912-libretech-pc.dts

diff --git a/arch/arm/dts/meson-gx-libretech-pc.dtsi 
b/arch/arm/dts/meson-gx-libretech-pc.dtsi
new file mode 100644
index ..248b018c83d5
--- /dev/null
+++ b/arch/arm/dts/meson-gx-libretech-pc.dtsi
@@ -0,0 +1,375 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 BayLibre SAS.
+ * Author: Jerome Brunet 
+ */
+
+/* Libretech Amlogic GX PC form factor - AKA: Tartiflette */
+
+#include 
+#include 
+
+/ {
+   adc-keys {
+   compatible = "adc-keys";
+   io-channels = < 0>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <180>;
+
+   update-button {
+   label = "update";
+   linux,code = ;
+   press-threshold-microvolt = <130>;
+   };
+   };
+
+   aliases {
+   serial0 = _AO;
+   ethernet0 = 
+   spi0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   cvbs-connector {
+   compatible = "composite-video-connector";
+   status = "disabled";
+
+   port {
+   cvbs_connector_in: endpoint {
+   remote-endpoint = <_vdac_out>;
+   };
+   };
+   };
+
+   emmc_pwrseq: emmc-pwrseq {
+   compatible = "mmc-pwrseq-emmc";
+   reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
+   };
+
+   hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = <_tx_tmds_out>;
+   };
+   };
+   };
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   poll-interval = <100>;
+
+   power-button {
+   label = "power";
+   linux,code = ;
+   gpios = <_ao GPIOAO_2 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x8000>;
+   };
+
+   ao_5v: regulator-ao_5v {
+   compatible = "regulator-fixed";
+   regulator-name = "AO_5V";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <_in>;
+   regulator-always-on;
+   };
+
+   dc_in: regulator-dc_in {
+   compatible = "regulator-fixed";
+   regulator-name = "DC_IN";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   green {
+   color = ;
+   function = LED_FUNCTION_DISK_ACTIVITY;
+   gpios = <_ao GPIOAO_9 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "disk-activity";
+   };
+
+   blue {
+   color = ;
+   function = LED_FUNCTION_STATUS;
+   gpios = < GPIODV_28 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   panic-indicator;
+   };
+   };
+
+   vcc_card: regulator-vcc_card {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_CARD";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_ao3v3>;
+
+   gpio = < GPIODV_4 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   vcc5v: regulator-vcc5v {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC5V";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <_5v>;
+
+   gpio = < GPIOH_3 GPIO_OPEN_DRAIN>;
+   };
+
+   vddio_ao18: regulator-vddio_ao18 {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDIO_AO18";
+   

[PATCH v2 1/6] dt-bindings: leds: import common led bindings from linux v5.5

2020-02-27 Thread Jerome Brunet
Import the common leds bindings definition from linux
d5226fa6dbae ("Linux 5.5")

Reviewed-by: Neil Armstrong 
Signed-off-by: Jerome Brunet 
---
 include/dt-bindings/leds/common.h | 75 +++
 1 file changed, 75 insertions(+)
 create mode 100644 include/dt-bindings/leds/common.h

diff --git a/include/dt-bindings/leds/common.h 
b/include/dt-bindings/leds/common.h
new file mode 100644
index ..9e1256a7c1bf
--- /dev/null
+++ b/include/dt-bindings/leds/common.h
@@ -0,0 +1,75 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides macros for the common LEDs device tree bindings.
+ *
+ * Copyright (C) 2015, Samsung Electronics Co., Ltd.
+ * Author: Jacek Anaszewski 
+ *
+ * Copyright (C) 2019 Jacek Anaszewski 
+ */
+
+#ifndef __DT_BINDINGS_LEDS_H
+#define __DT_BINDINGS_LEDS_H
+
+/* External trigger type */
+#define LEDS_TRIG_TYPE_EDGE0
+#define LEDS_TRIG_TYPE_LEVEL   1
+
+/* Boost modes */
+#define LEDS_BOOST_OFF 0
+#define LEDS_BOOST_ADAPTIVE1
+#define LEDS_BOOST_FIXED   2
+
+/* Standard LED colors */
+#define LED_COLOR_ID_WHITE 0
+#define LED_COLOR_ID_RED   1
+#define LED_COLOR_ID_GREEN 2
+#define LED_COLOR_ID_BLUE  3
+#define LED_COLOR_ID_AMBER 4
+#define LED_COLOR_ID_VIOLET5
+#define LED_COLOR_ID_YELLOW6
+#define LED_COLOR_ID_IR7
+#define LED_COLOR_ID_MAX   8
+
+/* Standard LED functions */
+#define LED_FUNCTION_ACTIVITY "activity"
+#define LED_FUNCTION_ALARM "alarm"
+#define LED_FUNCTION_BACKLIGHT "backlight"
+#define LED_FUNCTION_BLUETOOTH "bluetooth"
+#define LED_FUNCTION_BOOT "boot"
+#define LED_FUNCTION_CPU "cpu"
+#define LED_FUNCTION_CAPSLOCK "capslock"
+#define LED_FUNCTION_CHARGING "charging"
+#define LED_FUNCTION_DEBUG "debug"
+#define LED_FUNCTION_DISK "disk"
+#define LED_FUNCTION_DISK_ACTIVITY "disk-activity"
+#define LED_FUNCTION_DISK_ERR "disk-err"
+#define LED_FUNCTION_DISK_READ "disk-read"
+#define LED_FUNCTION_DISK_WRITE "disk-write"
+#define LED_FUNCTION_FAULT "fault"
+#define LED_FUNCTION_FLASH "flash"
+#define LED_FUNCTION_HEARTBEAT "heartbeat"
+#define LED_FUNCTION_INDICATOR "indicator"
+#define LED_FUNCTION_KBD_BACKLIGHT "kbd_backlight"
+#define LED_FUNCTION_LAN "lan"
+#define LED_FUNCTION_MAIL "mail"
+#define LED_FUNCTION_MTD "mtd"
+#define LED_FUNCTION_MICMUTE "micmute"
+#define LED_FUNCTION_MUTE "mute"
+#define LED_FUNCTION_NUMLOCK "numlock"
+#define LED_FUNCTION_PANIC "panic"
+#define LED_FUNCTION_PROGRAMMING "programming"
+#define LED_FUNCTION_POWER "power"
+#define LED_FUNCTION_RX "rx"
+#define LED_FUNCTION_SD "sd"
+#define LED_FUNCTION_SCROLLLOCK "scrolllock"
+#define LED_FUNCTION_STANDBY "standby"
+#define LED_FUNCTION_STATUS "status"
+#define LED_FUNCTION_TORCH "torch"
+#define LED_FUNCTION_TX "tx"
+#define LED_FUNCTION_USB "usb"
+#define LED_FUNCTION_WAN "wan"
+#define LED_FUNCTION_WLAN "wlan"
+#define LED_FUNCTION_WPS "wps"
+
+#endif /* __DT_BINDINGS_LEDS_H */
-- 
2.24.1



[PATCH v2 2/6] mmc: meson-gx: enable input clocks

2020-02-27 Thread Jerome Brunet
Until now, the mmc clock was left in a good enough state by the ROM
code to be used by the controller. However on some SoC, if the ROM
code finds a bootloader on USB or SPI, it might leave the MMC clock
in state the controller cannot work with.

Enable the input clocks provided to the mmc controller. While the
u-boot mmc controller driver is not doing fancy settings like the Linux,
it at least needs to make these clocks are running.

Reviewed-by: Neil Armstrong 
Signed-off-by: Jerome Brunet 
---
 drivers/mmc/meson_gx_mmc.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
index 031cc79ccb1f..7060f15787f6 100644
--- a/drivers/mmc/meson_gx_mmc.c
+++ b/drivers/mmc/meson_gx_mmc.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -240,12 +241,23 @@ static int meson_mmc_probe(struct udevice *dev)
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
struct mmc *mmc = >mmc;
struct mmc_config *cfg = >cfg;
+   struct clk_bulk clocks;
uint32_t val;
+   int ret;
+
 #ifdef CONFIG_PWRSEQ
struct udevice *pwr_dev;
-   int ret;
 #endif
 
+   /* Enable the clocks feeding the MMC controller */
+   ret = clk_get_bulk(dev, );
+   if (ret)
+   return ret;
+
+   ret = clk_enable_bulk();
+   if (ret)
+   return ret;
+
cfg->voltages = MMC_VDD_33_34 | MMC_VDD_32_33 |
MMC_VDD_31_32 | MMC_VDD_165_195;
cfg->host_caps = MMC_MODE_8BIT | MMC_MODE_4BIT |
-- 
2.24.1



[PATCH v2 0/6] arm64: meson: add libretech-pc support

2020-02-27 Thread Jerome Brunet
Add libretech PC platform support. This platform comes in 2 variants,
one with the s905d and the other s912.

While working on these boards, I've found a problem related the mmc
clock. In some cases, the ROM code will leave the mmc clocks in such
a weird state that any access to the mmc controller would lock the
device.

Making sure the MMC clocks are properly reset and enabled is enough
to solve the problem.

I have also synced all amlogic supported dts. Since I had to update
the gx dsti files, it made sense to update the dts as well. This is
done to keep things coherent even if it is not the original purpose
of this series.

Changes since v1:
 - Split dt sync, libretech-pc import and config addition.
 - Rebase on master

Jerome Brunet (6):
  dt-bindings: leds: import common led bindings from linux v5.5
  mmc: meson-gx: enable input clocks
  clk: meson: reset mmc clock on probe
  arm64: dts: meson: sync dt and bindings from v5.6-rc2
  arm64: dts: meson: import libretech-pc from linux v5.6-rc2
  arm64: dts: meson: add libretech-pc support

 arch/arm/dts/Makefile |   2 +
 arch/arm/dts/meson-axg-s400.dts   |  70 ++-
 arch/arm/dts/meson-axg.dtsi   | 273 --
 arch/arm/dts/meson-g12-common.dtsi| 478 ++
 arch/arm/dts/meson-g12.dtsi   | 398 +++
 arch/arm/dts/meson-g12a-sei510.dts|  64 +++
 arch/arm/dts/meson-g12a-u200.dts  |  54 ++
 arch/arm/dts/meson-g12a.dtsi  |  33 +-
 arch/arm/dts/meson-g12b-a311d-khadas-vim3.dts |  25 +
 arch/arm/dts/meson-g12b-odroid-n2.dts |   2 +-
 arch/arm/dts/meson-g12b.dtsi  |  26 +-
 arch/arm/dts/meson-gx-libretech-pc.dtsi   | 375 ++
 arch/arm/dts/meson-gx.dtsi|  87 +++-
 arch/arm/dts/meson-gxbb-nanopi-k2.dts |  26 +-
 arch/arm/dts/meson-gxbb-odroidc2.dts  | 100 +++-
 arch/arm/dts/meson-gxbb-p200.dts  |   9 +-
 arch/arm/dts/meson-gxbb-p201.dts  |   2 +-
 arch/arm/dts/meson-gxbb-p20x.dtsi |   9 +-
 arch/arm/dts/meson-gxbb.dtsi  | 118 -
 arch/arm/dts/meson-gxl-s805x-libretech-ac.dts |   2 +-
 .../meson-gxl-s905d-libretech-pc-u-boot.dtsi  |   7 +
 arch/arm/dts/meson-gxl-s905d-libretech-pc.dts |  16 +
 arch/arm/dts/meson-gxl-s905d.dtsi |  12 +
 arch/arm/dts/meson-gxl-s905x-khadas-vim.dts   |  20 +-
 arch/arm/dts/meson-gxl-s905x-libretech-cc.dts |  26 +-
 arch/arm/dts/meson-gxl-s905x-p212.dtsi|  10 +-
 arch/arm/dts/meson-gxl.dtsi   |  76 ++-
 arch/arm/dts/meson-gxm-khadas-vim2.dts|  71 +--
 .../meson-gxm-s912-libretech-pc-u-boot.dtsi   |   7 +
 arch/arm/dts/meson-gxm-s912-libretech-pc.dts  |  62 +++
 arch/arm/dts/meson-gxm.dtsi   |  39 +-
 arch/arm/dts/meson-khadas-vim3.dtsi   |   7 +
 arch/arm/dts/meson-sm1-khadas-vim3l.dts   |  95 
 arch/arm/dts/meson-sm1-sei610.dts | 236 -
 arch/arm/dts/meson-sm1.dtsi   | 356 +
 configs/libretech-s905d-pc_defconfig  |  71 +++
 configs/libretech-s912-pc_defconfig   |  71 +++
 drivers/clk/meson/axg.c   |   7 +
 drivers/clk/meson/g12a.c  |   7 +
 drivers/clk/meson/gxbb.c  |   7 +
 drivers/mmc/meson_gx_mmc.c|  14 +-
 include/configs/libretech-pc.h|  17 +
 include/dt-bindings/clock/axg-audio-clkc.h|  10 +
 include/dt-bindings/clock/gxbb-aoclkc.h   |   7 +
 include/dt-bindings/clock/gxbb-clkc.h |  21 +
 include/dt-bindings/gpio/meson-gxbb-gpio.h|   8 +-
 include/dt-bindings/gpio/meson-gxl-gpio.h |   8 +-
 include/dt-bindings/leds/common.h |  75 +++
 .../reset/amlogic,meson-axg-audio-arb.h   |   2 +
 .../reset/amlogic,meson-axg-reset.h   |   3 +-
 .../reset/amlogic,meson-g12a-audio-reset.h|  15 +
 .../reset/amlogic,meson-gxbb-reset.h  |  51 +-
 52 files changed, 2963 insertions(+), 624 deletions(-)
 create mode 100644 arch/arm/dts/meson-g12.dtsi
 create mode 100644 arch/arm/dts/meson-gx-libretech-pc.dtsi
 create mode 100644 arch/arm/dts/meson-gxl-s905d-libretech-pc-u-boot.dtsi
 create mode 100644 arch/arm/dts/meson-gxl-s905d-libretech-pc.dts
 create mode 100644 arch/arm/dts/meson-gxl-s905d.dtsi
 create mode 100644 arch/arm/dts/meson-gxm-s912-libretech-pc-u-boot.dtsi
 create mode 100644 arch/arm/dts/meson-gxm-s912-libretech-pc.dts
 create mode 100644 arch/arm/dts/meson-sm1-khadas-vim3l.dts
 create mode 100644 configs/libretech-s905d-pc_defconfig
 create mode 100644 configs/libretech-s912-pc_defconfig
 create mode 100644 include/configs/libretech-pc.h
 create mode 100644 include/dt-bindings/leds/common.h

-- 
2.24.1



Re: [U-Boot] [PATCH 1/2] sunxi: fix support board-specific CONFIG_PREBOOT

2020-02-27 Thread Lukasz Majewski
Hi Jonas,

> Hi Lukasz,
> 
> Quoting Lukasz Majewski (2019-08-23 23:05:41)

Some time has already passed ... :-)

> > > Quoting Lukasz Majewski (2019-08-23 10:37:28)  
> > > > On Sun, 18 Aug 2019 17:16:06 +0200
> > > > Jonas Smedegaard  wrote:
> > > > 
> > > > > commit 37304aaf60bf ("Convert CONFIG_USE_PREBOOT and
> > > > > CONFIG_PREBOOT to Kconfig") intended to support
> > > > > CONFIG_PREBOOT, but include/configs/sunxi-common.h hardcodes
> > > > > preboot as part of internally defined CONSOLE_STDIN_SETTINGS,
> > > > > silently ignoring any board-specific CONFIG_PREBOOT.
> > > > > 
> > > > > Tested-by: Jonas Smedegaard 
> > > > > Signed-off-by: Jonas Smedegaard 
> > > > > Series-Cc: Jagan Teki 
> > > > > ---
> > > > > 
> > > > >  include/configs/sunxi-common.h | 7 ++-
> > > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/include/configs/sunxi-common.h
> > > > > b/include/configs/sunxi-common.h index d7133a73fc..2069884b63
> > > > > 100644 --- a/include/configs/sunxi-common.h
> > > > > +++ b/include/configs/sunxi-common.h
> > > > > @@ -432,8 +432,13 @@ extern int soft_i2c_gpio_scl;
> > > > >  #include 
> > > > >  
> > > > >  #ifdef CONFIG_USB_KEYBOARD
> > > > > +#ifdef CONFIG_USE_PREBOOT
> > > > > +#ifndef CONFIG_PREBOOT
> > > > > +#define CONFIG_PREBOOT \
> > > > > + "usb start"
> > > > 
> > > > Shouldn't this (CONFIG_PREBOOT) be set in the Kconfig? 
> > > 
> > > My changeset ensures that _if_ CONFIG_PREBOOT is set in Kconfig
> > > then it is not _also_ set in header file.
> > > 
> > > Reason for my approach was to keep the changeset minimal.  
> > 
> > I think I have been misunderstood...  
> 
> Likewise... :-)
> 
> > The patch to which you referred in the commit message:
> > 
> > commit 37304aaf60bf ("Convert CONFIG_USE_PREBOOT and CONFIG_PREBOOT
> > to Kconfig")
> > 
> > was supposed to move setting of CONFIG_PREBOOT to Kconfig.
> > 
> > As it broke your setup - I proposed that you could add your fix not
> > to sunxi-common.h, but to Kconfig. In that way you would benefit
> > from the patch you refer to.  
> 
> commit 37304aaf60bf did not break my setup.
> 
> This proposed patch _improves_ commit 37304aaf60bf to make it
> possible to pass CONFIG_USE_PREBOOT in Kconfig on sunxi devices.
> 
> In fact, that is the very thing that next patch in this patchset does
> - which is what fixes my device: My device was broken also before
> commit 37304aaf60bf.
> 
> 
> This patchset still applies when unfuzzed.  Should I make a
> non-change v2 of this patch, or do anyone have other comments on it?
> 

If it fixes the issue on your board (and don't break other boards),
then prepare v2 on top of newest -master and post the patch (adding
sunxi maintainer/custodian to TO).

It shall be applied as a fix before next release.

> 
>  - Jonas
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgp6XEMCi2TIt.pgp
Description: OpenPGP digital signature


Re: [U-Boot] [PATCH 1/2] sunxi: fix support board-specific CONFIG_PREBOOT

2020-02-27 Thread Jonas Smedegaard
Hi Lukasz,

Quoting Lukasz Majewski (2019-08-23 23:05:41)
> > Quoting Lukasz Majewski (2019-08-23 10:37:28)
> > > On Sun, 18 Aug 2019 17:16:06 +0200
> > > Jonas Smedegaard  wrote:
> > >   
> > > > commit 37304aaf60bf ("Convert CONFIG_USE_PREBOOT and
> > > > CONFIG_PREBOOT to Kconfig") intended to support CONFIG_PREBOOT,
> > > > but include/configs/sunxi-common.h hardcodes preboot as part of
> > > > internally defined CONSOLE_STDIN_SETTINGS, silently ignoring any
> > > > board-specific CONFIG_PREBOOT.
> > > > 
> > > > Tested-by: Jonas Smedegaard 
> > > > Signed-off-by: Jonas Smedegaard 
> > > > Series-Cc: Jagan Teki 
> > > > ---
> > > > 
> > > >  include/configs/sunxi-common.h | 7 ++-
> > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/include/configs/sunxi-common.h
> > > > b/include/configs/sunxi-common.h index d7133a73fc..2069884b63
> > > > 100644 --- a/include/configs/sunxi-common.h
> > > > +++ b/include/configs/sunxi-common.h
> > > > @@ -432,8 +432,13 @@ extern int soft_i2c_gpio_scl;
> > > >  #include 
> > > >  
> > > >  #ifdef CONFIG_USB_KEYBOARD
> > > > +#ifdef CONFIG_USE_PREBOOT
> > > > +#ifndef CONFIG_PREBOOT
> > > > +#define CONFIG_PREBOOT \
> > > > + "usb start"  
> > > 
> > > Shouldn't this (CONFIG_PREBOOT) be set in the Kconfig?   
> > 
> > My changeset ensures that _if_ CONFIG_PREBOOT is set in Kconfig then
> > it is not _also_ set in header file.
> > 
> > Reason for my approach was to keep the changeset minimal.
> 
> I think I have been misunderstood...

Likewise... :-)

> The patch to which you referred in the commit message:
> 
> commit 37304aaf60bf ("Convert CONFIG_USE_PREBOOT and CONFIG_PREBOOT to 
> Kconfig")
> 
> was supposed to move setting of CONFIG_PREBOOT to Kconfig.
> 
> As it broke your setup - I proposed that you could add your fix not to 
> sunxi-common.h, but to Kconfig. In that way you would benefit from the 
> patch you refer to.

commit 37304aaf60bf did not break my setup.

This proposed patch _improves_ commit 37304aaf60bf to make it possible 
to pass CONFIG_USE_PREBOOT in Kconfig on sunxi devices.

In fact, that is the very thing that next patch in this patchset does - 
which is what fixes my device: My device was broken also before commit 
37304aaf60bf.


This patchset still applies when unfuzzed.  Should I make a non-change 
v2 of this patch, or do anyone have other comments on it?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature


Re: [PATCH] x86: p2sb: Drop 'apl' prefix

2020-02-27 Thread Bin Meng
On Tue, Feb 18, 2020 at 10:32 PM Wolfgang Wallner
 wrote:
>
> Drop the Apollo Lake prefix 'apl' from the functions, types and
> variables in the P2SB driver.
>
> The P2SB is not Apollo Lake specific, and as such it was moved in
> commit 2999846c1127 ("x86: Move P2SB from Apollo Lake to a more generic
> location") from the Apollo Lake folder to the intel_common folder.
>
> Signed-off-by: Wolfgang Wallner 
>
> ---
> This patch follows a similar rational for P2SB as commit 03fe85a27b23
> ("x86: itss: Remove apl-prefix") for the ITSS.
>
>  arch/x86/cpu/intel_common/p2sb.c  | 30 +--
>  arch/x86/dts/chromebook_coral.dts |  2 +-
>  .../gpio/intel,apl-gpio.txt   |  2 +-
>  .../pinctrl/intel,apl-pinctrl.txt |  2 +-
>  4 files changed, 18 insertions(+), 18 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [RFC PATCH] serial: ns16550: Move PCI access from ofdata_to_platdata() to probe()

2020-02-27 Thread Bin Meng
On Tue, Feb 18, 2020 at 8:36 PM Wolfgang Wallner
 wrote:
>
> Currently the ofdata_to_platdata() method calls dev_read_addr_pci(),
> which potentially accesses the parent PCI bus. If this happens before
> the parent PCI bus is probed the resulting address will be wrong.
>
> This behavior was triggered by commit 82de42fa1468 ("dm: core:
> Allocate parent data separate from probing parent").
>
> According to a comment in drivers/pci/pci-uclass.c [1] accessing
> the PCI parent bus in ofdata_to_platdata() is not allowed, and the
> access should be moved to the probe() function.
>
> Move the call to dev_read_addr_pci() and the related handling of the
> 'addr' value from the ofdata_to_platdata() to the probe() method.
>
> While moving the code, the comment /* try Processor Local Bus device
> first */ was dropped. It was initially added with commit 3db886a5bf38
> ("serial: ns16550: Support ns16550 compatible pci uart devices") and
> later made obsolete with commit 33c215af4b9d ("dm: pci: Add a function
> to read a PCI BAR").
>
> [1] Comment in drivers/pci/pci-uclass.c:
> "A common cause of this problem is that this function is called in the
> ofdata_to_platdata() method of @dev. Accessing the PCI bus in that
> method is not allowed, since it has not yet been probed. To fix this,
> move that access to the probe() method of @dev instead."
>
> Signed-off-by: Wolfgang Wallner 
>
> Fixes: 82de42fa1468 ("dm: core: Allocate parent data separate from
> probing parent")
>
> ---
> The discussion leading to this patch is located at
> https://lists.denx.de/pipermail/u-boot/2020-February/399811.html
>
>  drivers/serial/ns16550.c | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
>

Reviewed-by: Bin Meng 

This fixed the boot failure of Intel Galileo

Tested on Intel Galileo
Tested-by: Bin Meng 


[PATCH] arm: socfpga: arria10: Add save_boot_params()

2020-02-27 Thread Ley Foon Tan
Add save_boot_params() to save reset status value from bootrom.

Bootrom will clear the status register in reset manager and stores the
reset status value in shared memory. Bootrom stores shared data at last
2KB of onchip RAM.

This function save reset status provided by BootROM to rst_mgr_status.
More information about reset status register value can be found in reset
manager register description.

When running in debugger without Bootrom, r0 to r3 are random values.
So, skip save the value when r0 is not BootROM shared data address.

Signed-off-by: Ley Foon Tan 
---
 arch/arm/mach-socfpga/spl_a10.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c
index d9ef851054..867b1c906e 100644
--- a/arch/arm/mach-socfpga/spl_a10.c
+++ b/arch/arm/mach-socfpga/spl_a10.c
@@ -33,6 +33,36 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#define BOOTROM_SHARED_MEM_ADDR(CONFIG_SYS_INIT_RAM_ADDR + 
0x4 \
+- 0x800)
+#define RST_STATUS_SHARED_ADDR (BOOTROM_SHARED_MEM_ADDR + 0x438)
+u32 rst_mgr_status __section(.data);
+
+/*
+ * Bootrom will clear the status register in reset manager and stores the
+ * reset status value in shared memory. Bootrom stores shared data at last
+ * 2KB of onchip RAM.
+ * This function save reset status provided by BootROM to rst_mgr_status.
+ * More information about reset status register value can be found in reset
+ * manager register description.
+ * When running in debugger without Bootrom, r0 to r3 are random values.
+ * So, skip save the value when r0 is not BootROM shared data address.
+ *
+ * r0 - Contains the pointer to the shared memory block. The shared
+ * memory block is located in the top 2 KB of on-chip RAM.
+ * r1 - contains the length of the shared memory.
+ * r2 - unused and set to 0x0.
+ * r3 - points to the version block.
+ */
+void save_boot_params(unsigned long r0, unsigned long r1, unsigned long r2,
+ unsigned long r3)
+{
+   if (r0 == BOOTROM_SHARED_MEM_ADDR)
+   rst_mgr_status = readl(RST_STATUS_SHARED_ADDR);
+
+   save_boot_params_ret();
+}
+
 u32 spl_boot_device(void)
 {
const u32 bsel = readl(socfpga_get_sysmgr_addr() + SYSMGR_A10_BOOTINFO);
-- 
2.19.0



[PATCH] common/board_f.c: use #ifdefs a little more consistently

2020-02-27 Thread Rasmus Villemoes
Some init functions, e.g. print_resetinfo(), are conditionally defined
depending on some config options, and are correspondingly
conditionally included in the init_sequence_f[] array.

Others are unconditionally defined and included in init_sequence_f[],
but have their entire body, sans a mandatory "return 0", conditionally
compiled.

For the simple cases, switch to the former model, making it a bit more
consistent. This also makes the U-Boot image very slightly smaller and
avoids a few useless calls to no-op functions during board_init_f.

Signed-off-by: Rasmus Villemoes 
---
 common/board_f.c | 54 
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index 82a164752a..ed63fbcea2 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -285,16 +285,16 @@ static int setup_mon_len(void)
return 0;
 }
 
+#if CONFIG_IS_ENABLED(HANDOFF)
 static int setup_spl_handoff(void)
 {
-#if CONFIG_IS_ENABLED(HANDOFF)
gd->spl_handoff = bloblist_find(BLOBLISTT_SPL_HANDOFF,
sizeof(struct spl_handoff));
debug("Found SPL hand-off info %p\n", gd->spl_handoff);
-#endif
 
return 0;
 }
+#endif
 
 __weak int arch_cpu_init(void)
 {
@@ -437,17 +437,17 @@ static int reserve_video(void)
return 0;
 }
 
+#ifdef CONFIG_TRACE
 static int reserve_trace(void)
 {
-#ifdef CONFIG_TRACE
gd->relocaddr -= CONFIG_TRACE_BUFFER_SIZE;
gd->trace_buff = map_sysmem(gd->relocaddr, CONFIG_TRACE_BUFFER_SIZE);
debug("Reserving %luk for trace data at: %08lx\n",
  (unsigned long)CONFIG_TRACE_BUFFER_SIZE >> 10, gd->relocaddr);
-#endif
 
return 0;
 }
+#endif
 
 static int reserve_uboot(void)
 {
@@ -520,13 +520,13 @@ static int reserve_board(void)
return 0;
 }
 
+#ifdef CONFIG_MACH_TYPE
 static int setup_machine(void)
 {
-#ifdef CONFIG_MACH_TYPE
gd->bd->bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */
-#endif
return 0;
 }
+#endif
 
 static int reserve_global_data(void)
 {
@@ -537,9 +537,9 @@ static int reserve_global_data(void)
return 0;
 }
 
+#ifndef CONFIG_OF_EMBED
 static int reserve_fdt(void)
 {
-#ifndef CONFIG_OF_EMBED
/*
 * If the device tree is sitting immediately above our image then we
 * must relocate it. If it is embedded in the data section, then it
@@ -553,24 +553,24 @@ static int reserve_fdt(void)
debug("Reserving %lu Bytes for FDT at: %08lx\n",
  gd->fdt_size, gd->start_addr_sp);
}
-#endif
 
return 0;
 }
+#endif
 
+#ifdef CONFIG_BOOTSTAGE
 static int reserve_bootstage(void)
 {
-#ifdef CONFIG_BOOTSTAGE
int size = bootstage_get_size();
 
gd->start_addr_sp -= size;
gd->new_bootstage = map_sysmem(gd->start_addr_sp, size);
debug("Reserving %#x Bytes for bootstage at: %08lx\n", size,
  gd->start_addr_sp);
-#endif
 
return 0;
 }
+#endif
 
 __weak int arch_reserve_stacks(void)
 {
@@ -590,16 +590,16 @@ static int reserve_stacks(void)
return arch_reserve_stacks();
 }
 
+#ifdef CONFIG_BLOBLIST
 static int reserve_bloblist(void)
 {
-#ifdef CONFIG_BLOBLIST
gd->start_addr_sp &= ~0xf;
gd->start_addr_sp -= CONFIG_BLOBLIST_SIZE;
gd->new_bloblist = map_sysmem(gd->start_addr_sp, CONFIG_BLOBLIST_SIZE);
-#endif
 
return 0;
 }
+#endif
 
 static int display_new_sp(void)
 {
@@ -675,23 +675,23 @@ static int init_post(void)
 }
 #endif
 
+#ifndef CONFIG_OF_EMBED
 static int reloc_fdt(void)
 {
-#ifndef CONFIG_OF_EMBED
if (gd->flags & GD_FLG_SKIP_RELOC)
return 0;
if (gd->new_fdt) {
memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size);
gd->fdt_blob = gd->new_fdt;
}
-#endif
 
return 0;
 }
+#endif
 
+#ifdef CONFIG_BOOTSTAGE
 static int reloc_bootstage(void)
 {
-#ifdef CONFIG_BOOTSTAGE
if (gd->flags & GD_FLG_SKIP_RELOC)
return 0;
if (gd->new_bootstage) {
@@ -703,14 +703,14 @@ static int reloc_bootstage(void)
gd->bootstage = gd->new_bootstage;
bootstage_relocate();
}
-#endif
 
return 0;
 }
+#endif
 
+#ifdef CONFIG_BLOBLIST
 static int reloc_bloblist(void)
 {
-#ifdef CONFIG_BLOBLIST
if (gd->flags & GD_FLG_SKIP_RELOC)
return 0;
if (gd->new_bloblist) {
@@ -721,10 +721,10 @@ static int reloc_bloblist(void)
memcpy(gd->new_bloblist, gd->bloblist, size);
gd->bloblist = gd->new_bloblist;
}
-#endif
 
return 0;
 }
+#endif
 
 static int setup_reloc(void)
 {
@@ -886,7 +886,9 @@ static const init_fnc_t init_sequence_f[] = {
 #ifdef CONFIG_BLOBLIST
bloblist_init,
 #endif
+#if CONFIG_IS_ENABLED(HANDOFF)
setup_spl_handoff,
+#endif
initf_console_record,
 #if defined(CONFIG_HAVE_FSP)
arch_fsp_init,
@@ -974,15 

[PATCH v2 8/8] board: presidio-asic: Add SPI NAND and NOR support

2020-02-27 Thread Alex Nemirovsky
Add SPI NAND and NOR support for Cortina Access
Presidio Engineering Board

Signed-off-by: Alex Nemirovsky 
---

Changes in v2: None

 arch/arm/dts/ca-presidio-engboard.dts|  8 ++--
 board/cortina/presidio-asic/presidio.c   | 16 ++-
 configs/cortina_presidio-asic-spi-nand_defconfig | 48 +++
 configs/cortina_presidio-asic-spi-nor_defconfig  | 59 
 4 files changed, 125 insertions(+), 6 deletions(-)
 create mode 100644 configs/cortina_presidio-asic-spi-nand_defconfig
 create mode 100644 configs/cortina_presidio-asic-spi-nor_defconfig

diff --git a/arch/arm/dts/ca-presidio-engboard.dts 
b/arch/arm/dts/ca-presidio-engboard.dts
index ae897e8..8c73eb6 100644
--- a/arch/arm/dts/ca-presidio-engboard.dts
+++ b/arch/arm/dts/ca-presidio-engboard.dts
@@ -55,15 +55,13 @@
};
 
sflash: sflash-controller@f4324000 {
-   #address-cells = <2>;
-   #size-cells = <1>;
compatible = "cortina,ca-sflash";
reg = <0x0 0xf4324000 0x50>;
reg-names = "sflash-regs";
flash@0 {
-   compatible = "jedec,spi-nor";
-   spi-rx-bus-width = <1>;
-   spi-max-frequency = <10800>;
+   compatible = "spi-nand", "jedec,spi-nor";
+   spi-rx-bus-width = <4>;
+   spi-tx-bus-width = <4>;
};
};
 
diff --git a/board/cortina/presidio-asic/presidio.c 
b/board/cortina/presidio-asic/presidio.c
index b4fa01f..d547b60 100644
--- a/board/cortina/presidio-asic/presidio.c
+++ b/board/cortina/presidio-asic/presidio.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 #include 
-
+#include 
 DECLARE_GLOBAL_DATA_PTR;
 
 #define CA_PERIPH_BASE  0xE000UL
@@ -70,9 +70,23 @@ static noinline int invoke_psci_fn_smc(u64 function_id, u64 
arg0, u64 arg1,
return function_id;
 }
 
+#ifdef CONFIG_CORTINA_SFLASH
+static int init_sflash(void)
+{
+   struct udevice *dev;
+
+   uclass_first_device(UCLASS_SPI, );
+
+   return 0;
+}
+#endif
+
 int board_early_init_r(void)
 {
dcache_disable();
+#ifdef CONFIG_CORTINA_SFLASH
+   init_sflash();
+#endif
return 0;
 }
 
diff --git a/configs/cortina_presidio-asic-spi-nand_defconfig 
b/configs/cortina_presidio-asic-spi-nand_defconfig
new file mode 100644
index 000..515ad22
--- /dev/null
+++ b/configs/cortina_presidio-asic-spi-nand_defconfig
@@ -0,0 +1,48 @@
+CONFIG_ARM=y
+# CONFIG_SYS_ARCH_TIMER is not set
+CONFIG_TARGET_PRESIDIO_ASIC=y
+CONFIG_SYS_TEXT_BASE=0x0400
+CONFIG_ENV_SIZE=0x2
+CONFIG_DM_GPIO=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_IDENT_STRING="Presidio-SoC"
+CONFIG_SHOW_BOOT_PROGRESS=y
+CONFIG_BOOTDELAY=3
+CONFIG_LOGLEVEL=7
+CONFIG_BOARD_EARLY_INIT_R=y
+CONFIG_SYS_PROMPT="G3#"
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_PART=y
+CONFIG_CMD_SF_TEST=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_WDT=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIMER=y
+CONFIG_CMD_SMC=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+CONFIG_DEFAULT_DEVICE_TREE="ca-presidio-engboard"
+# CONFIG_NET is not set
+CONFIG_DM=y
+CONFIG_CORTINA_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_CA=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_CORTINA=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_MTD_SPI_NAND=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_DM_SERIAL=y
+CONFIG_CORTINA_UART=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_CORTINA_SFLASH=y
+CONFIG_WDT=y
+CONFIG_WDT_CORTINA=y
diff --git a/configs/cortina_presidio-asic-spi-nor_defconfig 
b/configs/cortina_presidio-asic-spi-nor_defconfig
new file mode 100644
index 000..d7ecec3
--- /dev/null
+++ b/configs/cortina_presidio-asic-spi-nor_defconfig
@@ -0,0 +1,59 @@
+CONFIG_ARM=y
+# CONFIG_SYS_ARCH_TIMER is not set
+CONFIG_TARGET_PRESIDIO_ASIC=y
+CONFIG_SYS_TEXT_BASE=0x0400
+CONFIG_ENV_SIZE=0x2
+CONFIG_DM_GPIO=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_IDENT_STRING="Presidio-SoC"
+CONFIG_SHOW_BOOT_PROGRESS=y
+CONFIG_BOOTDELAY=3
+CONFIG_BOARD_EARLY_INIT_R=y
+CONFIG_SYS_PROMPT="G3#"
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_PART=y
+CONFIG_CMD_SF_TEST=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_WDT=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIMER=y
+CONFIG_CMD_SMC=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+CONFIG_DEFAULT_DEVICE_TREE="ca-presidio-engboard"
+# CONFIG_NET is not set
+CONFIG_DM=y
+CONFIG_CORTINA_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_CA=y
+CONFIG_LED=y
+CONFIG_LED_CORTINA=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_CORTINA=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_ATMEL=y
+CONFIG_SPI_FLASH_EON=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_SPI_FLASH_ISSI=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_SST=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_XMC=y

[PATCH v2 6/8] board: presidio: add LED support

2020-02-27 Thread Alex Nemirovsky
From: Jway Lin 

Add LED support for Cortina Access Presidio Engineering Board

Signed-off-by: Jway Lin 
Signed-off-by: Alex Nemirovsky 
---

Changes in v2: None

 arch/arm/dts/ca-presidio-engboard.dts| 31 
 configs/cortina_presidio-asic-emmc_defconfig |  2 ++
 2 files changed, 33 insertions(+)

diff --git a/arch/arm/dts/ca-presidio-engboard.dts 
b/arch/arm/dts/ca-presidio-engboard.dts
index c03dacc..ae897e8 100644
--- a/arch/arm/dts/ca-presidio-engboard.dts
+++ b/arch/arm/dts/ca-presidio-engboard.dts
@@ -66,4 +66,35 @@
spi-max-frequency = <10800>;
};
};
+
+   leds: led-controller@f43200f0 {
+   compatible = "cortina,ca-leds";
+   reg = <0x0 0xf43200f0 0x40>;
+
+   cortina,blink_rate1 = <256>;
+   cortina,blink_rate2 = <512>;
+
+   led@0 {
+   pin = <0>;
+   active-low;
+   blink-sel =<0>;
+   port = <0>;
+   off-event = <0>;
+   label = "led0";
+   };
+
+   led@1 {
+   pin = <1>;
+   active-low;
+   blink-sel =<1>;
+   label = "led1";
+   };
+
+   led@2 {
+   pin = <2>;
+   active-low;
+   label = "led2";
+   };
+
+   };
 };
diff --git a/configs/cortina_presidio-asic-emmc_defconfig 
b/configs/cortina_presidio-asic-emmc_defconfig
index e45e23c..3c6bd6b 100644
--- a/configs/cortina_presidio-asic-emmc_defconfig
+++ b/configs/cortina_presidio-asic-emmc_defconfig
@@ -27,6 +27,8 @@ CONFIG_DM=y
 CONFIG_CORTINA_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_CA=y
+CONFIG_LED=y
+CONFIG_LED_CORTINA=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_CORTINA=y
-- 
2.7.4



[PATCH v2 3/8] i2c: i2c-cortina: added CAxxxx I2C support

2020-02-27 Thread Alex Nemirovsky
From: Arthur Li 

Add I2C controller support for Cortina Access CA SoCs

Signed-off-by: Arthur Li 
Signed-off-by: Alex Nemirovsky 
---

Changes in v2: None

 MAINTAINERS   |   4 +
 drivers/i2c/Kconfig   |   7 +
 drivers/i2c/Makefile  |   1 +
 drivers/i2c/i2c-cortina.c | 346 ++
 drivers/i2c/i2c-cortina.h |  92 
 5 files changed, 450 insertions(+)
 create mode 100644 drivers/i2c/i2c-cortina.c
 create mode 100644 drivers/i2c/i2c-cortina.h

diff --git a/MAINTAINERS b/MAINTAINERS
index bb45d3c..b147faa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -181,6 +181,8 @@ F:  drivers/gpio/cortina_gpio.c
 F: drivers/watchdog/cortina_wdt.c
 F: drivers/serial/serial_cortina.c
 F: drivers/mmc/ca_dw_mmc.c
+F: drivers/i2c/i2c-cortina.c
+F: drivers/i2c/i2c-cortina.h
 
 ARM/CZ.NIC TURRIS MOX SUPPORT
 M: Marek Behun 
@@ -672,6 +674,8 @@ F:  drivers/gpio/cortina_gpio.c
 F: drivers/watchdog/cortina_wdt.c
 F: drivers/serial/serial_cortina.c
 F: drivers/mmc/ca_dw_mmc.c
+F: drivers/i2c/i2c-cortina.c
+F: drivers/i2c/i2c-cortina.h
 
 MIPS MSCC
 M: Gregory CLEMENT 
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 03d2fed..b98a4aa 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -85,6 +85,13 @@ config SYS_I2C_CADENCE
  Say yes here to select Cadence I2C Host Controller. This controller is
  e.g. used by Xilinx Zynq.
 
+config SYS_I2C_CA
+   tristate "Cortina-Access I2C Controller"
+   depends on DM_I2C && CORTINA_PLATFORM
+   default n
+   help
+ Say yes here to select Cortina-Access I2C Host Controller.
+
 config SYS_I2C_DAVINCI
bool "Davinci I2C Controller"
depends on (ARCH_KEYSTONE || ARCH_DAVINCI)
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index f5a471f..5d18cf7 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SYS_I2C) += i2c_core.o
 obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
 obj-$(CONFIG_SYS_I2C_AT91) += at91_i2c.o
 obj-$(CONFIG_SYS_I2C_CADENCE) += i2c-cdns.o
+obj-$(CONFIG_SYS_I2C_CA) += i2c-cortina.o
 obj-$(CONFIG_SYS_I2C_DAVINCI) += davinci_i2c.o
 obj-$(CONFIG_SYS_I2C_DW) += designware_i2c.o
 ifdef CONFIG_DM_PCI
diff --git a/drivers/i2c/i2c-cortina.c b/drivers/i2c/i2c-cortina.c
new file mode 100644
index 000..99c63f3
--- /dev/null
+++ b/drivers/i2c/i2c-cortina.c
@@ -0,0 +1,346 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2020
+ * Arthur Li, Cortina Access, arthur...@cortina-access.com.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "i2c-cortina.h"
+
+static void set_speed(struct i2c_regs *regs, int i2c_spd)
+{
+   union ca_biw_cfg i2c_cfg;
+
+   i2c_cfg.wrd = readl(>i2c_cfg);
+   i2c_cfg.bf.core_en = 0;
+   writel(i2c_cfg.wrd, >i2c_cfg);
+
+   switch (i2c_spd) {
+   case IC_SPEED_MODE_MAX:
+   i2c_cfg.bf.prer =
+   CORTINA_PER_IO_FREQ / (5 * I2C_MAX_SPEED) - 1;
+   break;
+
+   case IC_SPEED_MODE_STANDARD:
+   i2c_cfg.bf.prer =
+   CORTINA_PER_IO_FREQ / (5 * I2C_STANDARD_SPEED) - 1;
+   break;
+
+   case IC_SPEED_MODE_FAST:
+   default:
+   i2c_cfg.bf.prer =
+   CORTINA_PER_IO_FREQ / (5 * I2C_FAST_SPEED) - 1;
+   break;
+   }
+
+   i2c_cfg.bf.core_en = 1;
+   writel(i2c_cfg.wrd, >i2c_cfg);
+}
+
+static int ca_i2c_set_bus_speed(struct udevice *bus, unsigned int speed)
+{
+   struct ca_i2c *priv = dev_get_priv(bus);
+   int i2c_spd;
+
+   if (speed >= I2C_MAX_SPEED) {
+   i2c_spd = IC_SPEED_MODE_MAX;
+   priv->speed = I2C_MAX_SPEED;
+   } else if (speed >= I2C_FAST_SPEED) {
+   i2c_spd = IC_SPEED_MODE_FAST;
+   priv->speed = I2C_FAST_SPEED;
+   } else {
+   i2c_spd = IC_SPEED_MODE_STANDARD;
+   priv->speed = I2C_STANDARD_SPEED;
+   }
+
+   set_speed(priv->regs, i2c_spd);
+
+   return 0;
+}
+
+static int ca_i2c_get_bus_speed(struct udevice *bus)
+{
+   struct ca_i2c *priv = dev_get_priv(bus);
+
+   return priv->speed;
+}
+
+static void ca_i2c_init(struct i2c_regs *regs)
+{
+   union ca_biw_cfg i2c_cfg;
+
+   i2c_cfg.wrd = readl(>i2c_cfg);
+   i2c_cfg.bf.core_en = 0;
+   i2c_cfg.bf.biw_soft_reset = 1;
+   writel(i2c_cfg.wrd, >i2c_cfg);
+   mdelay(10);
+   i2c_cfg.bf.biw_soft_reset = 0;
+   writel(i2c_cfg.wrd, >i2c_cfg);
+
+   set_speed(regs, IC_SPEED_MODE_STANDARD);
+
+   i2c_cfg.wrd = readl(>i2c_cfg);
+   i2c_cfg.bf.core_en = 1;
+   writel(i2c_cfg.wrd, >i2c_cfg);
+}
+
+static int i2c_wait_complete(struct i2c_regs *regs)
+{
+   union ca_biw_ctrl i2c_ctrl;
+   unsigned long start_time_bb = get_timer(0);
+
+   i2c_ctrl.wrd = readl(>i2c_ctrl);
+
+   while (i2c_ctrl.bf.biwdone == 

[PATCH v2 7/8] spi: ca_sflash: Add CAxxxx SPI Flash Controller

2020-02-27 Thread Alex Nemirovsky
From: Pengpeng Chen 

Add SPI Flash controller driver for Cortina Access
CA SoCs

Signed-off-by: Pengpeng Chen 
Signed-off-by: Alex Nemirovsky 
---

Changes in v2: None

 MAINTAINERS |   2 +
 drivers/spi/Kconfig |   8 +
 drivers/spi/Makefile|   1 +
 drivers/spi/ca_sflash.c | 575 
 4 files changed, 586 insertions(+)
 create mode 100644 drivers/spi/ca_sflash.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 24a2655..8509779 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -184,6 +184,7 @@ F:  drivers/mmc/ca_dw_mmc.c
 F: drivers/i2c/i2c-cortina.c
 F: drivers/i2c/i2c-cortina.h
 F: drivers/led/led_cortina.c
+F: drivers/spi/ca_sflash.c
 
 ARM/CZ.NIC TURRIS MOX SUPPORT
 M: Marek Behun 
@@ -678,6 +679,7 @@ F:  drivers/mmc/ca_dw_mmc.c
 F: drivers/i2c/i2c-cortina.c
 F: drivers/i2c/i2c-cortina.h
 F: drivers/led/led_cortina.c
+F: drivers/spi/ca_sflash.c
 
 MIPS MSCC
 M: Gregory CLEMENT 
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 4166c61..8a244f1 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -106,6 +106,14 @@ config BCMSTB_SPI
  be used to access the SPI flash on platforms embedding this
  Broadcom SPI core.
 
+config CORTINA_SFLASH
+   bool "Cortina-Access Serial Flash controller driver"
+   depends on DM_SPI && SPI_MEM
+   help
+ Enable the Cortina-Access Serial Flash controller driver. This driver
+ can be used to access the SPI NOR/NAND flash on platforms embedding 
this
+ Cortina-Access IP core.
+
 config CADENCE_QSPI
bool "Cadence QSPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 52462e1..32b98b4 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_BCM63XX_SPI) += bcm63xx_spi.o
 obj-$(CONFIG_BCMSTB_SPI) += bcmstb_spi.o
 obj-$(CONFIG_CADENCE_QSPI) += cadence_qspi.o cadence_qspi_apb.o
 obj-$(CONFIG_CF_SPI) += cf_spi.o
+obj-$(CONFIG_CORTINA_SFLASH) += ca_sflash.o
 obj-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
 obj-$(CONFIG_DESIGNWARE_SPI) += designware_spi.o
 obj-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
diff --git a/drivers/spi/ca_sflash.c b/drivers/spi/ca_sflash.c
new file mode 100644
index 000..293eeb5
--- /dev/null
+++ b/drivers/spi/ca_sflash.c
@@ -0,0 +1,575 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for Cortina SPI-FLASH Controller
+ *
+ * Copyright (C) 2020 Cortina Access Inc. All Rights Reserved.
+ *
+ * Author: PengPeng Chen 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct ca_sflash_regs {
+   u32 idr;/* 0x00:Flash word ID Register */
+   u32 tc; /* 0x04:Flash Timeout Counter Register */
+   u32 sr; /* 0x08:Flash Status Register */
+   u32 tr; /* 0x0C:Flash Type Register */
+   u32 asr;/* 0x10:Flash ACCESS START/BUSY Register */
+   u32 isr;/* 0x14:Flash Interrupt Status Register */
+   u32 imr;/* 0x18:Flash Interrupt Mask Register */
+   u32 fcr;/* 0x1C:NAND Flash FIFO Control Register */
+   u32 ffsr;   /* 0x20:Flash FIFO Status Register */
+   u32 ffar;   /* 0x24:Flash FIFO ADDRESS Register */
+   u32 ffmar;  /* 0x28:Flash FIFO MATCHING ADDRESS Register */
+   u32 ffdr;   /* 0x2C:Flash FIFO Data Register */
+   u32 ar; /* 0x30:Serial Flash Access Register */
+   u32 ear;/* 0x34:Serial Flash Extend Access Register */
+   u32 adr;/* 0x38:Serial Flash ADdress Register */
+   u32 dr; /* 0x3C:Serial Flash Data Register */
+   u32 tmr;/* 0x40:Serial Flash Timing Register */
+};
+
+/*
+ * FLASH_TYPE
+ */
+#define CA_FLASH_TR_PINBIT(15)
+#define CA_FLASH_TR_TYPE_MASK  GENMASK(14, 12)
+#define CA_FLASH_TR_TYPE(tp)   (((tp) << 12) & CA_FLASH_TR_TYPE_MASK)
+#define CA_FLASH_TR_WIDTH  BIT(11)
+#define CA_FLASH_TR_SIZE_MASK  GENMASK(10, 9)
+#define CA_FLASH_TR_SIZE(sz)   (((sz) << 9) & CA_FLASH_TR_SIZE_MASK)
+
+/*
+ * FLASH_FLASH_ACCESS_START
+ */
+#define CA_FLASH_ASR_IND_START_EN  BIT(1)
+#define CA_FLASH_ASR_DMA_START_EN  BIT(3)
+#define CA_FLASH_ASR_WR_ACCESS_EN  BIT(9)
+
+/*
+ * FLASH_FLASH_INTERRUPT
+ */
+#define CA_FLASH_ISR_REG_IRQ   BIT(1)
+#define CA_FLASH_ISR_FIFO_IRQ  BIT(2)
+
+/*
+ * FLASH_SF_ACCESS
+ */
+#define CA_SF_AR_OPCODE_MASK   GENMASK(7, 0)
+#define CA_SF_AR_OPCODE(op)((op) << 0) & CA_SF_AR_OPCODE_MASK)
+#define CA_SF_AR_ACCODE_MASK   GENMASK(11, 8)
+#define CA_SF_AR_ACCODE(ac)(((ac) << 8) & 

[PATCH v2 5/8] led: led_cortina: Add CAxxx LED support

2020-02-27 Thread Alex Nemirovsky
From: Jway Lin 

Add Cortina Access LED controller support for CA SOCs

Signed-off-by: Jway Lin 
Signed-off-by: Alex Nemirovsky 
---

Changes in v2: None

 MAINTAINERS   |   2 +
 drivers/led/Kconfig   |   8 ++
 drivers/led/Makefile  |   1 +
 drivers/led/led_cortina.c | 308 ++
 4 files changed, 319 insertions(+)
 create mode 100644 drivers/led/led_cortina.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b147faa..24a2655 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -183,6 +183,7 @@ F:  drivers/serial/serial_cortina.c
 F: drivers/mmc/ca_dw_mmc.c
 F: drivers/i2c/i2c-cortina.c
 F: drivers/i2c/i2c-cortina.h
+F: drivers/led/led_cortina.c
 
 ARM/CZ.NIC TURRIS MOX SUPPORT
 M: Marek Behun 
@@ -676,6 +677,7 @@ F:  drivers/serial/serial_cortina.c
 F: drivers/mmc/ca_dw_mmc.c
 F: drivers/i2c/i2c-cortina.c
 F: drivers/i2c/i2c-cortina.h
+F: drivers/led/led_cortina.c
 
 MIPS MSCC
 M: Gregory CLEMENT 
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index 6675934..cc87fbf 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -35,6 +35,14 @@ config LED_BCM6858
  This option enables support for LEDs connected to the BCM6858
  HW has blinking capabilities and up to 32 LEDs can be controlled.
 
+config LED_CORTINA
+   bool "LED Support for Cortina Access CA SoCs"
+   depends on LED && (CORTINA_PLATFORM)
+   help
+ This option enables support for LEDs connected to the Cortina
+ Access CA SOCs.
+
+
 config LED_BLINK
bool "Support LED blinking"
depends on LED
diff --git a/drivers/led/Makefile b/drivers/led/Makefile
index 3654dd3..8e3ae7f 100644
--- a/drivers/led/Makefile
+++ b/drivers/led/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_LED_BCM6328) += led_bcm6328.o
 obj-$(CONFIG_LED_BCM6358) += led_bcm6358.o
 obj-$(CONFIG_LED_BCM6858) += led_bcm6858.o
 obj-$(CONFIG_$(SPL_)LED_GPIO) += led_gpio.o
+obj-$(CONFIG_LED_CORTINA) += led_cortina.o
diff --git a/drivers/led/led_cortina.c b/drivers/led/led_cortina.c
new file mode 100644
index 000..53435e8
--- /dev/null
+++ b/drivers/led/led_cortina.c
@@ -0,0 +1,308 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright (C) 2020 Cortina-Access
+ * Author: Jway Lin 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CORTINA_LED_NUM16
+
+#define BIT(nr)(1UL << (nr))
+
+#define cortina_LED_CONTROL0x00
+#define cortina_LED_CONFIG_0   0x04
+#define cortina_LED_CONFIG_1   0x08
+#define cortina_LED_CONFIG_2   0x0c
+#define cortina_LED_CONFIG_3   0x10
+#define cortina_LED_CONFIG_4   0x14
+#define cortina_LED_CONFIG_5   0x18
+#define cortina_LED_CONFIG_6   0x1c
+#define cortina_LED_CONFIG_7   0x20
+#define cortina_LED_CONFIG_8   0x24
+#define cortina_LED_CONFIG_9   0x28
+#define cortina_LED_CONFIG_10  0x2c
+#define cortina_LED_CONFIG_11  0x30
+#define cortina_LED_CONFIG_12  0x34
+#define cortina_LED_CONFIG_13  0x38
+#define cortina_LED_CONFIG_14  0x3c
+#define cortina_LED_CONFIG_15  0x40
+
+#define cortina_LED_MAX_HW_BLINK   127
+#define cortina_LED_MAX_COUNT  CORTINA_LED_NUM
+#define cortina_LED_MAX_PORT   8
+
+/* LED_CONTROL fields */
+#define cortina_LED_BLINK_RATE1_OFFSET 0
+#define cortina_LED_BLINK_RATE1_MASK   0xFF
+#define cortina_LED_BLINK_RATE2_OFFSET 8
+#define cortina_LED_BLINK_RATE2_MASK   0xFF
+#define cortina_LED_CLK_TEST   BIT(16)
+#define cortina_LED_CLK_POLARITY   BIT(17)
+#define cortina_LED_CLK_TEST_MODE  BIT(16)
+#define cortina_LED_CLK_TEST_RX_TEST   BIT(30)
+#define cortina_LED_CLK_TEST_TX_TEST   BIT(31)
+
+/* LED_CONFIG fields */
+#define cortina_LED_EVENT_ON_OFFSET0
+#define cortina_LED_EVENT_ON_MASK  0x7
+#define cortina_LED_EVENT_BLINK_OFFSET 3
+#define cortina_LED_EVENT_BLINK_MASK   0x7
+#define cortina_LED_EVENT_OFF_OFFSET   6
+#define cortina_LED_EVENT_OFF_MASK 0x7
+#define cortina_LED_OFF_ON_OFFSET  9
+#define cortina_LED_OFF_ON_MASK0x3
+#define cortina_LED_PORT_OFFSET11
+#define cortina_LED_PORT_MASK  0x7
+#define cortina_LED_OFF_VALBIT(14)
+#define cortina_LED_SW_EVENT   BIT(15)
+#define cortina_LED_BLINK_SEL  BIT(16)
+
+struct cortina_led_cfg {
+   void __iomem *regs;
+   spinlock_t *lock;   /* protect LED resource access */
+   int idx;
+   bool active_low;
+
+   int off_event;
+   int blink_event;
+   int on_event;
+   int port;
+   int blink;
+   int enable;
+};
+
+struct cortina_led_top_cfg {
+   void __iomem *regs;
+   u16 blink_rate1;
+   u16 blink_rate2;
+};
+
+static struct cortina_led_top_cfg glb_led_ctrl;
+
+static void cortina_led_write(void __iomem *reg,