Re: [U-Boot] [PATCH 3/3] mtd: spi: Kconfig: Select SPI_FLASH if DM_SPI_FLASH

[Vignesh R]

On 09/02/19 5:45 PM, Jagan Teki wrote:
> DM_SPI_FLASH should require spi flash interface code for dm
> version, so select SPI_FLASH core by default if any board
> enabled DM_SPI_FLASH.
> 
> This overcome the explicit enablement of CONFIG_SPI_FLASH on
> respective boards when DM_SPI_FLASH being used.
> > Cc: Vignesh R 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/mtd/spi/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> index 605f60c713..43f597ec29 100644
> --- a/drivers/mtd/spi/Kconfig
> +++ b/drivers/mtd/spi/Kconfig
> @@ -3,6 +3,7 @@ menu "SPI Flash Support"
>  config DM_SPI_FLASH
>   bool "Enable Driver Model for SPI flash"
>   depends on DM && DM_SPI
> + select SPI_FLASH

How about imply instead of select since there is no compile time dependency?

>   help
> Enable driver model for SPI flash. This SPI flash interface
> (spi_flash_probe(), spi_flash_write(), etc.) is then
> 

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

Re: [U-Boot] [RFC v2 02/15] efi_loader: boottime: convert efi_loaded_image_obj to DM

[AKASHI Takahiro]

On Tue, Feb 12, 2019 at 07:47:06AM +0100, Heinrich Schuchardt wrote:
> On 2/12/19 6:07 AM, AKASHI Takahiro wrote:
> > Heinrich,
> > 
> > On Fri, Feb 08, 2019 at 06:53:00PM +0100, Heinrich Schuchardt wrote:
> >> On 2/8/19 9:15 AM, AKASHI Takahiro wrote:
> >>> Signed-off-by: AKASHI Takahiro 
> >>> ---
> >>>  include/efi_loader.h  |  2 +-
> >>>  lib/efi_loader/efi_boottime.c | 61 +++
> >>>  2 files changed, 35 insertions(+), 28 deletions(-)
> >>>
> >>> diff --git a/include/efi_loader.h b/include/efi_loader.h
> >>> index 4d5e22564a72..5882cd7dd3b0 100644
> >>> --- a/include/efi_loader.h
> >>> +++ b/include/efi_loader.h
> >>> @@ -367,7 +367,7 @@ efi_status_t efi_install_configuration_table(const 
> >>> efi_guid_t *guid, void *table
> >>>  /* Sets up a loaded image */
> >>>  efi_status_t efi_setup_loaded_image(struct efi_device_path *device_path,
> >>>   struct efi_device_path *file_path,
> >>> - struct efi_loaded_image_obj **handle_ptr,
> >>> + efi_handle_t *handle_ptr,
> >>>   struct efi_loaded_image **info_ptr);
> >>>  efi_status_t efi_load_image_from_path(struct efi_device_path *file_path,
> >>> void **buffer);
> >>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> >>> index d23e4fbbdf23..624156d4578b 100644
> >>> --- a/lib/efi_loader/efi_boottime.c
> >>> +++ b/lib/efi_loader/efi_boottime.c
> >>> @@ -1690,29 +1690,29 @@ static efi_status_t EFIAPI 
> >>> efi_install_configuration_table_ext(efi_guid_t *guid,
> >>>   */
> >>>  efi_status_t efi_setup_loaded_image(struct efi_device_path *device_path,
> >>>   struct efi_device_path *file_path,
> >>> - struct efi_loaded_image_obj **handle_ptr,
> >>> + efi_handle_t *handle_ptr,
> >>>   struct efi_loaded_image **info_ptr)
> >>>  {
> >>>   efi_status_t ret;
> >>>   struct efi_loaded_image *info;
> >>> - struct efi_loaded_image_obj *obj;
> >>> + struct udevice *dev;
> >>>  
> >>>   info = calloc(1, sizeof(*info));
> >>>   if (!info)
> >>>   return EFI_OUT_OF_RESOURCES;
> >>> - obj = calloc(1, sizeof(*obj));
> >>> - if (!obj) {
> >>> +
> >>> + ret = device_bind_driver(dm_root(), "efi_loaded_image", "(IMG)", );
> >>
> >> A loaded image is not a device. There is nothing in the EFI world
> >> relating the loaded image directly to the root of the device tree.
> > 
> > Please notice that any loaded image is linked to "efi_root",
> > not "root of the device tree."
> > 
> > Such a relationship is an analogy to the current implementation
> > where *global* protocols are added to "efi_root" for now. 
> 
> Yes we are lacking the necessary handles to show that the USB keyboard
> in connected to a USB controller installed on a PCI bus.
> 
> But what has this to do with loaded images? When we call the U-Boot
> `load` command to load a kernel image we do not update the device model.

That's right.

> So why should be do it for a kernel image loaded via LoadImage()?

The difference here is that multiple instances of loaded image,
either application or driver, can co-exist at the same time in EFI world.
So distinguishing those by handles may make some sense.

-Takahiro Akashi


> A kernel image isn't a device. So let's keep it separate from the device
> mmodel.
> 
> Best regards
> 
> Heinrich
> 
> > 
> > -Takahiro Akashi
> > 
> >> We should not create a meaningless link here.
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >>
> >>> + if (ret) {
> >>>   free(info);
> >>>   return EFI_OUT_OF_RESOURCES;
> >>>   }
> >>>  
> >>> - /* Add internal object to object list */
> >>> - efi_add_handle(>header);
> >>> + efi_add_handle(dev);
> >>>  
> >>>   if (info_ptr)
> >>>   *info_ptr = info;
> >>>   if (handle_ptr)
> >>> - *handle_ptr = obj;
> >>> + *handle_ptr = dev;
> >>>  
> >>>   info->revision =  EFI_LOADED_IMAGE_PROTOCOL_REVISION;
> >>>   info->file_path = file_path;
> >>> @@ -1724,7 +1724,7 @@ efi_status_t efi_setup_loaded_image(struct 
> >>> efi_device_path *device_path,
> >>>* When asking for the device path interface, return
> >>>* bootefi_device_path
> >>>*/
> >>> - ret = efi_add_protocol(>header,
> >>> + ret = efi_add_protocol(dev,
> >>>  _guid_device_path, device_path);
> >>>   if (ret != EFI_SUCCESS)
> >>>   goto failure;
> >>> @@ -1734,24 +1734,24 @@ efi_status_t efi_setup_loaded_image(struct 
> >>> efi_device_path *device_path,
> >>>* When asking for the loaded_image interface, just
> >>>* return handle which points to loaded_image_info
> >>>*/
> >>> - ret = efi_add_protocol(>header,
> >>> + ret = efi_add_protocol(dev,
> >>>  _guid_loaded_image, info);
> >>>   if (ret != 

Re: [U-Boot] [RFC v2 00/15] dm, efi: integrate efi objects into DM

[AKASHI Takahiro]

Hi Heinrich, Simon,

On Sat, Feb 09, 2019 at 05:00:33PM -0600, Simon Glass wrote:
> Hi Heinrich,
> 
> On Fri, 8 Feb 2019 at 03:36, Heinrich Schuchardt  wrote:
> >
> >
> >
> > On 2/8/19 9:15 AM, AKASHI Takahiro wrote:
> > > # bootefi doesn't work with this patch set yet
> > >
> > > This patch set came from the past discussion[1] on my "removable device
> > > support" patch and is intended to be an attempt to integrate efi objects
> > >  into u-boot's Driver Model as much seamlessly as possible.
> > >
> > > [1] https://lists.denx.de/pipermail/u-boot/2019-January/354010.html
> > >
> > > Since this patch is a prototype (or POC, Proof-Of-Concept), the aim here
> > > is to discuss further about how in a better shape we will be able to
> > > merge the two worlds.
> > >
> > > After RFC, Simon suggested that efi protocols could be also presented
> > > as DM devices. This is a major change in RFC v2.
> > >
> > Hello Takahiro,
> >
> > thanks a lot for laying out your thoughts about a possible integration of
> > the EFI subsystem and the driver model. Thanks also for providing a first
> > implementation.
> 
> Yes indeed. It is very clever what you have been able to do Takahiro.

I think that I'm going to extremes here :)

I wonder what the EFI world will look like if all the handles
and protocols are also DM devices.
I don't expect that my patch will be upstreamed any time soon
(or possibly forever not) So, instead of claiming the change
would be meaningless, I'd welcome any suggestions, like what will
happen if we merge/integrate EFI's A with U-Boot's B?

I'm willing to make best efforts to give such an idea a reality
if possible. Then choices come after that.

> >
> > > Basic idea is
> > > * efi_root is a DM device
> > > * Any efi object, refered to by efi_handle_t in UEFI world,
> > >   has a corresponding DM device.
> >
> > EFI applications and drivers will create handles having no relation to
> > the U-Boot world.
> 
> I suggest that we change that, i.e. that all devices in existence have
> a struct udevice. That way DM knows about everything and we don't have
> the strange parallel 'EFI' world. I don't see any need for it.

Simply, it would be nice that we can list all the applications
and drivers loaded at one place, akin to linux's
  * ls /proc/
  * cat /proc/modules

(From the viewpoint of API, we can do that just by calling
locate_handle(BY_PROTOCOL, EFI_LOADED_IMAGE, ...) though.)

> >
> > >   - define efi_handle_t as "struct udevice *"
> >
> > An EFI handle does not necessarily relate to any U-Boot device. Why
> > should a handle which has not backing device carry the extra fields of
> > struct udevice?
> 
> Because this is the U-Boot driver model. We should not have an EFI
> parallel to DM and certainly not just to save a few dozen bytes of
> data space. If you were trying to save data space, you would not use
> EFI :-)

Ah, thank you.
From a viewpoint of implementation, the situation where some handles
are DM devices and some are not could make the efi code, particularly
boottime.c, quite ugly and complicated.

> >
> > >   - for efi_disk,
> > > * add "struct efi_disk_obj" to blk_desc
> >
> > struct efi_disk_obj * is currently the handle of the block device. So
> > you only some fields may be moved to blk_desc. But I guess I will find
> > that in one of the patches.

This is definitely a future work item.
In this case, however, blk_desc should also be able to represent
a partition.

> > >   - for the objects below, there is only one instance for each and so
> > > they are currently global data:
> > >   efi_gop_obj,
> > >   efi_net_obj,
> >
> > efi_net_obj * is the handle of the network device. In future we should
> > support multiple network devices.

It will be a natural extension.

> > >   simple_text_output_mode
> > >   - for loaded_image,
> > > * link efi_loaded_image_obj to device's platdata
> >
> > An EFI application can create an image out of "nothing". Just create a
> > handle with InstallProtocolInterface() and then call LoadImage() with a
> > pointer to some place in memory.
> >
> > Many images loaded from the same device may be present at the same time,
> > e.g. iPXE, GRUB, and Linux.

I don't get your point here, but please notice that a "loaded image"
is more or less portion of main memory with loaded code.
iPXE, GRUB and Linux are the same in this respect.

> >
> > >
> > > * Any efi protocol has a corresponding DM device.
> >
> > Protocol implementations are not only provided by U-Boot but also by EFI
> > applications and driver binaries. And of cause the EFI binaries will
> > implement a lot of protocols completely unknown to U-Boot. So what
> > should be the meaning of the above sentence in this context?
> 
> Can we instead add a uclass for each EFI protocol? Then U-Boot does
> know about them.

Yeah, I thought about defining an uclass for each EFI protocol.
Given that a protocol defines a protocol-specific set of function
interfaces in most cases, it will be 

Re: [U-Boot] [PATCH 2/2] xilinx: common: Add support for DM_I2C zynq_board_read_rom_ethaddr()

[Mike Looijmans]

It would even be better to adopt the Linux kernel way of storing MAC address 
through nvmem. That works for basically any board - and you get rid of the 
vendor prefix. Any nvmem provider can store the data, not just I2C eeproms. It 
reduces the total code size since all gem drivers can call the same function.

Example:

eeprom: eeprom@50 {
compatible = "at24,24c04";
reg = <0x50>;
#address-cells = <1>;
#size-cells = <1>;
/* NVMEM entries */
gem0_mac: mac@0x1e8 {
reg = <0x1e8 6>;
};
};

 {
/* MAC address stored in NVMEM */
nvmem-cells = <_mac>;
nvmem-cell-names = "mac-address";
};


On 28-01-19 09:52, Michal Simek wrote:
> It is much easier to point to eeprom which stores information like MAC
> address directly via DT. eeprom which contains this information is
> pointed by /chosen/xlnx,eeprom parameter.
> 
> For example:
>  chosen {
>  bootargs = "earlycon";
>  stdout-path = "serial0:115200n8";
> +   xlnx,eeprom = 
>  };
> 
> Signed-off-by: Michal Simek 
> ---
> 
>   board/xilinx/common/board.c | 32 
>   1 file changed, 32 insertions(+)
> 
> diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
> index 7e813d856404..b14f530c72c5 100644
> --- a/board/xilinx/common/board.c
> +++ b/board/xilinx/common/board.c
> @@ -8,6 +8,7 @@
>   #include 
>   #include 
>   
> +#if !defined(CONFIG_DM_I2C)
>   int zynq_board_read_rom_ethaddr(unsigned char *ethaddr)
>   {
>   #if defined(CONFIG_ZYNQ_GEM_EEPROM_ADDR) && \
> @@ -23,3 +24,34 @@ int zynq_board_read_rom_ethaddr(unsigned char *ethaddr)
>   
>   return 0;
>   }
> +
> +#else
> +int zynq_board_read_rom_ethaddr(unsigned char *ethaddr)
> +{
> + int ret = -EINVAL;
> +
> +#if defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET)
> + struct udevice *dev;
> + ofnode eeprom;
> +
> + eeprom = ofnode_get_chosen_node("xlnx,eeprom");
> + if (!ofnode_valid(eeprom))
> + return -ENODEV;
> +
> + debug("%s: Path to EEPROM %s\n", __func__,
> +   ofnode_get_chosen_prop("xlnx,eeprom"));
> +
> + ret = uclass_get_device_by_ofnode(UCLASS_I2C_EEPROM, eeprom, );
> + if (ret)
> + return ret;
> +
> + ret = dm_i2c_read(dev, CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET, ethaddr, 6);
> + if (ret)
> + debug("%s: I2C EEPROM MAC address read failed\n", __func__);
> + else
> + debug("%s: I2C EEPROM MAC %pM\n", __func__, ethaddr);
> +#endif
> +
> + return ret;
> +}
> +#endif
> 

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

Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support

[Alexander Graf]

> Am 12.02.2019 um 07:35 schrieb Anup Patel :
> 
>> On Tue, Feb 12, 2019 at 11:52 AM Alexander Graf  wrote:
>> 
>> 
>> 
 Am 12.02.2019 um 03:57 schrieb Anup Patel :
 
> On Mon, Feb 11, 2019 at 9:07 PM Andreas Schwab  wrote:
> 
> On Feb 11 2019, Anup Patel  wrote:
> 
> This patchset adds SiFive Freedom Unleashed (FU540) support
> to RISC-V U-Boot.
> 
> The patches are based upon latest U-Boot source tree
> (git://git.denx.de/u-boot.git) at commit id
> dbe70c7d4e3d5c705a98d82952e05a591efd0683
> 
> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> MACB Ethernet work fine on actual SiFive Unleashed board and
> QEMU sifive_u machine.
 
 Looks like the MACB driver cannot find the correct MAC address.  That
 makes it rather awkward for network boot.
 
 Warning: ethernet@1009 (eth0) using random MAC address - 
 0e:14:15:06:ae:e4
>>> 
>>> This is because we don't have place to put U-Boot environment
>>> variables as of now on Unleashed board. This will be solved once
>>> we have SPI driver and SPI_MMC driver for Unleased board.
>>> 
>>> In future, we will be saving "ethaddr" environment variable on
>>> SPI_MMC so U-Boot will pick MAC address at boot-time from
>>> SPI_MMC. Once this is achieved, the above warning will go away.
>> 
>> How is the MAC determined in Linux?
> 
> In Linux, we have an "local-mac-address" DT property used by
> quite a few drivers (including Cadence Ethernet driver) but it's not
> uniform across Linux drivers.
> 
> In U-Boot, another option is to change the Candence MACB driver and
> set "ethaddr" environment variable based on "local-mac-address" DT
> property from driver probe. Suggestions ??

That would be my quick fix suggestion, yes :). Or do it in the board file.

Alex

> 
> Regards,
> Anup

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

[U-Boot] Please pull u-boot-x86

[Bin Meng]

Hi Tom,

This PR includes the following changes to x86:
- edison switch to CONFIG_OF_SEPARATE
- tangier initial ACPI support for PMIC device
- tsc timer driver update to support native calibration
- fixes to 64-bit U-Boot proper

The following changes since commit f94fa0e94f36c740d3c7aa314c89a750c742185b:

  Merge branch 'master' of git://git.denx.de/u-boot-i2c (2019-02-11
11:15:34 -0500)

are available in the git repository at:

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

for you to fetch changes up to 24b56e2bf369ac003ccaac37d8bb80e08b743e16:

  x86: tangier: Add initial ACPI support for PMIC device (2019-02-12
14:37:17 +0800)


Andy Shevchenko (3):
  x86: edison: Switch to CONFIG_OF_SEPARATE
  doc: Fix CONFIG_OF_SEPARATE description
  x86: tangier: Add initial ACPI support for PMIC device

Bernhard Messerklinger (1):
  x86: tsc: Add support for native calibration of TSC freq

Bin Meng (3):
  x86: Change 4-level page table base address to low memory
  x86: Don't copy the cpu_call64() function to a hardcoded address
  x86: Use the existing GDT in the ROM for 64-bit U-Boot proper

 arch/x86/cpu/i386/call64.S  |  4 
 arch/x86/cpu/i386/cpu.c | 31
++-
 arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 87
+++
 configs/edison_defconfig|  2 +-
 doc/README.fdt-control  |  7 ---
 drivers/timer/tsc_timer.c   | 55
+++
 6 files changed, 161 insertions(+), 25 deletions(-)

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

Re: [U-Boot] [PATCH v3 01/22] net: FEC: Add compatible for vybrid (vf610) to reuse fec_mxc.c driver

[Lukasz Majewski]

Hi Marcel,

> Hi Lukasz
> 
> On Sun, 2019-02-03 at 00:02 +0100, Lukasz Majewski wrote:
> > The NXP's FEC driver can be reused on vf610 device (with DM).
> > 
> > Signed-off-by: Lukasz Majewski 
> > Reviewed-by: Stefan Agner 
> > ---
> > 
> > Changes in v3: None
> > Changes in v2: None
> > 
> >  drivers/net/fec_mxc.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
> > index 1a59026a62..5ff49224f4 100644
> > --- a/drivers/net/fec_mxc.c
> > +++ b/drivers/net/fec_mxc.c
> > @@ -1486,6 +1486,7 @@ static const struct udevice_id fecmxc_ids[] =
> > { { .compatible = "fsl,imx6ul-fec" },
> > { .compatible = "fsl,imx53-fec" },
> > { .compatible = "fsl,imx7d-fec" },
> > +   { .compatible = "fsl,mvf600-fec" },
> > { }
> >  };  
> 
> For some reason while the FEC prior to DM was rock solid on Vybrid
> with DM it at times only sends stuff but refuses to receive packets.
> Do you recall having any such issues? Could it have to do with us
> using FEC1 by default rather than FEC0? But then at times it works
> just fine again which is rather strange...

I had also some problems when I switched to DM (but for other NXP
IMX6Q based board - mccmon6). It turned out that the time between probe
in the driver and first read of MDIO was just as in spec (or too short).

As a result the PHY was sometimes in uninitialized state, and silently
read 0x as ID, which prevent us from normal work.

The fix in this case was to increase the delay between powering up PHY
and exiting the ETH driver probe:
http://patchwork.ozlabs.org/patch/1034050/


Please check if this patch (from this series):
"pcm052: bk4: Add board_phy_config() for BK4 to setup ksz8081 phy"

is not solving your problem.

> 
> Cheers
> 
> Marcel




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


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

Re: [U-Boot] [RFC v2 02/15] efi_loader: boottime: convert efi_loaded_image_obj to DM

[Heinrich Schuchardt]

On 2/12/19 6:07 AM, AKASHI Takahiro wrote:
> Heinrich,
> 
> On Fri, Feb 08, 2019 at 06:53:00PM +0100, Heinrich Schuchardt wrote:
>> On 2/8/19 9:15 AM, AKASHI Takahiro wrote:
>>> Signed-off-by: AKASHI Takahiro 
>>> ---
>>>  include/efi_loader.h  |  2 +-
>>>  lib/efi_loader/efi_boottime.c | 61 +++
>>>  2 files changed, 35 insertions(+), 28 deletions(-)
>>>
>>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>>> index 4d5e22564a72..5882cd7dd3b0 100644
>>> --- a/include/efi_loader.h
>>> +++ b/include/efi_loader.h
>>> @@ -367,7 +367,7 @@ efi_status_t efi_install_configuration_table(const 
>>> efi_guid_t *guid, void *table
>>>  /* Sets up a loaded image */
>>>  efi_status_t efi_setup_loaded_image(struct efi_device_path *device_path,
>>> struct efi_device_path *file_path,
>>> -   struct efi_loaded_image_obj **handle_ptr,
>>> +   efi_handle_t *handle_ptr,
>>> struct efi_loaded_image **info_ptr);
>>>  efi_status_t efi_load_image_from_path(struct efi_device_path *file_path,
>>>   void **buffer);
>>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>>> index d23e4fbbdf23..624156d4578b 100644
>>> --- a/lib/efi_loader/efi_boottime.c
>>> +++ b/lib/efi_loader/efi_boottime.c
>>> @@ -1690,29 +1690,29 @@ static efi_status_t EFIAPI 
>>> efi_install_configuration_table_ext(efi_guid_t *guid,
>>>   */
>>>  efi_status_t efi_setup_loaded_image(struct efi_device_path *device_path,
>>> struct efi_device_path *file_path,
>>> -   struct efi_loaded_image_obj **handle_ptr,
>>> +   efi_handle_t *handle_ptr,
>>> struct efi_loaded_image **info_ptr)
>>>  {
>>> efi_status_t ret;
>>> struct efi_loaded_image *info;
>>> -   struct efi_loaded_image_obj *obj;
>>> +   struct udevice *dev;
>>>  
>>> info = calloc(1, sizeof(*info));
>>> if (!info)
>>> return EFI_OUT_OF_RESOURCES;
>>> -   obj = calloc(1, sizeof(*obj));
>>> -   if (!obj) {
>>> +
>>> +   ret = device_bind_driver(dm_root(), "efi_loaded_image", "(IMG)", );
>>
>> A loaded image is not a device. There is nothing in the EFI world
>> relating the loaded image directly to the root of the device tree.
> 
> Please notice that any loaded image is linked to "efi_root",
> not "root of the device tree."
> 
> Such a relationship is an analogy to the current implementation
> where *global* protocols are added to "efi_root" for now. 

Yes we are lacking the necessary handles to show that the USB keyboard
in connected to a USB controller installed on a PCI bus.

But what has this to do with loaded images? When we call the U-Boot
`load` command to load a kernel image we do not update the device model.
So why should be do it for a kernel image loaded via LoadImage()?

A kernel image isn't a device. So let's keep it separate from the device
mmodel.

Best regards

Heinrich

> 
> -Takahiro Akashi
> 
>> We should not create a meaningless link here.
>>
>> Best regards
>>
>> Heinrich
>>
>>
>>> +   if (ret) {
>>> free(info);
>>> return EFI_OUT_OF_RESOURCES;
>>> }
>>>  
>>> -   /* Add internal object to object list */
>>> -   efi_add_handle(>header);
>>> +   efi_add_handle(dev);
>>>  
>>> if (info_ptr)
>>> *info_ptr = info;
>>> if (handle_ptr)
>>> -   *handle_ptr = obj;
>>> +   *handle_ptr = dev;
>>>  
>>> info->revision =  EFI_LOADED_IMAGE_PROTOCOL_REVISION;
>>> info->file_path = file_path;
>>> @@ -1724,7 +1724,7 @@ efi_status_t efi_setup_loaded_image(struct 
>>> efi_device_path *device_path,
>>>  * When asking for the device path interface, return
>>>  * bootefi_device_path
>>>  */
>>> -   ret = efi_add_protocol(>header,
>>> +   ret = efi_add_protocol(dev,
>>>_guid_device_path, device_path);
>>> if (ret != EFI_SUCCESS)
>>> goto failure;
>>> @@ -1734,24 +1734,24 @@ efi_status_t efi_setup_loaded_image(struct 
>>> efi_device_path *device_path,
>>>  * When asking for the loaded_image interface, just
>>>  * return handle which points to loaded_image_info
>>>  */
>>> -   ret = efi_add_protocol(>header,
>>> +   ret = efi_add_protocol(dev,
>>>_guid_loaded_image, info);
>>> if (ret != EFI_SUCCESS)
>>> goto failure;
>>>  
>>> -   ret = efi_add_protocol(>header,
>>> +   ret = efi_add_protocol(dev,
>>>_guid_hii_string_protocol,
>>>(void *)_hii_string);
>>> if (ret != EFI_SUCCESS)
>>> goto failure;
>>>  
>>> -   ret = efi_add_protocol(>header,
>>> +   ret = efi_add_protocol(dev,
>>>_guid_hii_database_protocol,

Re: [U-Boot] [PATCH v3 03/22] vybrid: ddr: Extend vf610-pinfunc.h with DDR pads definitions

[Lukasz Majewski]

Hi Marcel,

> Hi Lukasz
> 
> BTW: Thanks for this work which greatly helped us getting Colibri
> VF50/VF61 up to speed concerning device tree resp. driver model
> integration/migration. Hopefully, I can send that out later this week.
> 
> On Sun, 2019-02-03 at 00:02 +0100, Lukasz Majewski wrote:
> > This patch provides definitions necessary for VF610 DDR pad
> > configurations.
> > 
> > Signed-off-by: Lukasz Majewski 
> > Reviewed-by: Stefan Agner 
> > ---
> > 
> > Changes in v3: None
> > Changes in v2: None
> > 
> >  arch/arm/dts/vf610-pinfunc.h | 50
> > 
> >  1 file changed, 50 insertions(+)
> > 
> > diff --git a/arch/arm/dts/vf610-pinfunc.h b/arch/arm/dts/vf610-
> > pinfunc.h
> > index fcad7132c8..24d7126756 100644
> > --- a/arch/arm/dts/vf610-pinfunc.h
> > +++ b/arch/arm/dts/vf610-pinfunc.h
> > @@ -807,4 +807,54 @@
> >  #define VF610_PAD_PTA7__GPIO_134   0x218 0x000 ALT0
> > 0x0 #define VF610_PAD_PTA7__VIU_PIX_CLK 0x218 0x3AC
> > ALT1 0x1 
> > +#define VF610_PAD_DDR_RESETB   0x21c 0x000
> > ALT0 0x0 +#define VF610_PAD_DDR_A15__DDR_A_15   0x220
> > 0x000 ALT0 0x0 +#define VF610_PAD_DDR_A14__DDR_A_14
> > 0x224 0x000 ALT0 0x0 +#define
> > VF610_PAD_DDR_A13__DDR_A_13 0x228 0x000 ALT0 0x0
> > +#define VF610_PAD_DDR_A12__DDR_A_120x22c 0x000
> > ALT0 0x0 +#define VF610_PAD_DDR_A11__DDR_A_11   0x230
> > 0x000 ALT0 0x0 +#define VF610_PAD_DDR_A10__DDR_A_10
> > 0x234 0x000 ALT0 0x0 +#define
> > VF610_PAD_DDR_A9__DDR_A_9   0x238 0x000 ALT0 0x0
> > +#define VF610_PAD_DDR_A8__DDR_A_8  0x23c 0x000 ALT0
> > 0x0 +#define VF610_PAD_DDR_A7__DDR_A_7  0x240 0x000
> > ALT0 0x0 +#define VF610_PAD_DDR_A6__DDR_A_6 0x244
> > 0x000 ALT0 0x0 +#define VF610_PAD_DDR_A5__DDR_A_5
> > 0x248 0x000 ALT0 0x0 +#define
> > VF610_PAD_DDR_A4__DDR_A_4   0x24c 0x000 ALT0 0x0
> > +#define VF610_PAD_DDR_A3__DDR_A_3  0x250 0x000 ALT0
> > 0x0 +#define VF610_PAD_DDR_A2__DDR_A_2  0x254 0x000
> > ALT0 0x0 +#define VF610_PAD_DDR_A1__DDR_A_1 0x258
> > 0x000 ALT0 0x0 +#define VF610_PAD_DDR_A0__DDR_A_0
> > 0x25c 0x000 ALT0 0x0 +#define
> > VF610_PAD_DDR_BA2__DDR_BA_2 0x260 0x000 ALT0 0x0
> > +#define VF610_PAD_DDR_BA1__DDR_BA_10x264 0x000
> > ALT0 0x0 +#define VF610_PAD_DDR_BA0__DDR_BA_0   0x268
> > 0x000 ALT0 0x0 +#define VF610_PAD_DDR_CAS__DDR_CAS_B
> > 0x26c 0x000 ALT0 0x0 +#define
> > VF610_PAD_DDR_CKE__DDR_CKE_00x270 0x000 ALT0 0x0
> > +#define VF610_PAD_DDR_CLK__DDR_CLK_0   0x274 0x000
> > ALT0 0x0 +#define VF610_PAD_DDR_CS__DDR_CS_B_0  0x278
> > 0x000 ALT0 0x0 +#define VF610_PAD_DDR_D15__DDR_D_15
> > 0x27c 0x000 ALT0 0x0 +#define
> > VF610_PAD_DDR_D14__DDR_D_14 0x280 0x000 ALT0 0x0
> > +#define VF610_PAD_DDR_D13__DDR_D_130x284 0x000
> > ALT0 0x0 +#define VF610_PAD_DDR_D12__DDR_D_12   0x288
> > 0x000 ALT0 0x0 +#define VF610_PAD_DDR_D11__DDR_D_11
> > 0x28c 0x000 ALT0 0x0 +#define
> > VF610_PAD_DDR_D10__DDR_D_10 0x290 0x000 ALT0 0x0
> > +#define VF610_PAD_DDR_D9__DDR_D_9  0x294 0x000 ALT0
> > 0x0 +#define VF610_PAD_DDR_D8__DDR_D_8  0x298 0x000
> > ALT0 0x0 +#define VF610_PAD_DDR_D7__DDR_D_7 0x29c
> > 0x000 ALT0 0x0 +#define VF610_PAD_DDR_D6__DDR_D_6
> > 0x2a0 0x000 ALT0 0x0 +#define
> > VF610_PAD_DDR_D5__DDR_D_5   0x2a4 0x000 ALT0 0x0
> > +#define VF610_PAD_DDR_D4__DDR_D_4  0x2a8 0x000 ALT0
> > 0x0 +#define VF610_PAD_DDR_D3__DDR_D_3  0x2ac 0x000
> > ALT0 0x0 +#define VF610_PAD_DDR_D2__DDR_D_2 0x2b0
> > 0x000 ALT0 0x0 +#define VF610_PAD_DDR_D1__DDR_D_1
> > 0x2b4 0x000 ALT0 0x0 +#define
> > VF610_PAD_DDR_D0__DDR_D_0   0x2b8 0x000 ALT0 0x0
> > +#define VF610_PAD_DDR_DQM1__DDR_DQM_1  0x2bc 0x000
> > ALT0 0x0 +#define VF610_PAD_DDR_DQM0__DDR_DQM_0
> > 0x2c0 0x000 ALT0 0x0 +#define
> > VF610_PAD_DDR_DQS1__DDR_DQS_1   0x2c4 0x000 ALT0 0x0
> > +#define VF610_PAD_DDR_DQS0__DDR_DQS_0  0x2c8 0x000
> > ALT0 0x0 +#define VF610_PAD_DDR_RAS__DDR_RAS_B  0x2cc
> > 0x000 ALT0 0x0 +#define VF610_PAD_DDR_WE__DDR_WE_B
> > 0x2d0 0x000 ALT0 0x0 +#define
> > VF610_PAD_DDR_ODT1__DDR_ODT_0   0x2d4 0x000 ALT0 0x0
> > +#define VF610_PAD_DDR_ODT0__DDR_ODT_1  0x2d8 0x000
> > ALT0 0x0 +#define VF610_PAD_DDR_DDRBYTE1__DDR_DDRBYTE1  0x2dc
> > 0x000 ALT0 0x0 +#define VF610_PAD_DDR_DDRBYTE0__DDR_DDRBYTE0
> > 0x2e0 0x000 ALT0 0x0  
> 
> As far as I can tell from the reference manual there is no such thing
> as a DDRBYTE0 but it is rather called DDRBYTE2, not?

Yes, correct. This indeed shall be DDRBYTE2, not 0.

Thanks for spotting it.

> 
> >  #endif  
> 
> Cheers
> 
> Marcel




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: 

Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support

[Anup Patel]

On Tue, Feb 12, 2019 at 11:52 AM Alexander Graf  wrote:
>
>
>
> > Am 12.02.2019 um 03:57 schrieb Anup Patel :
> >
> >> On Mon, Feb 11, 2019 at 9:07 PM Andreas Schwab  wrote:
> >>
> >>> On Feb 11 2019, Anup Patel  wrote:
> >>>
> >>> This patchset adds SiFive Freedom Unleashed (FU540) support
> >>> to RISC-V U-Boot.
> >>>
> >>> The patches are based upon latest U-Boot source tree
> >>> (git://git.denx.de/u-boot.git) at commit id
> >>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
> >>>
> >>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> >>> MACB Ethernet work fine on actual SiFive Unleashed board and
> >>> QEMU sifive_u machine.
> >>
> >> Looks like the MACB driver cannot find the correct MAC address.  That
> >> makes it rather awkward for network boot.
> >>
> >> Warning: ethernet@1009 (eth0) using random MAC address - 
> >> 0e:14:15:06:ae:e4
> >
> > This is because we don't have place to put U-Boot environment
> > variables as of now on Unleashed board. This will be solved once
> > we have SPI driver and SPI_MMC driver for Unleased board.
> >
> > In future, we will be saving "ethaddr" environment variable on
> > SPI_MMC so U-Boot will pick MAC address at boot-time from
> > SPI_MMC. Once this is achieved, the above warning will go away.
>
> How is the MAC determined in Linux?

In Linux, we have an "local-mac-address" DT property used by
quite a few drivers (including Cadence Ethernet driver) but it's not
uniform across Linux drivers.

In U-Boot, another option is to change the Candence MACB driver and
set "ethaddr" environment variable based on "local-mac-address" DT
property from driver probe. Suggestions ??

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

Re: [U-Boot] [PATCH v1] x86: tangier: Add initial ACPI support for PMIC device

[Bin Meng]

On Tue, Feb 12, 2019 at 2:18 PM Bin Meng  wrote:
>
> On Tue, Feb 5, 2019 at 7:07 PM Andy Shevchenko
>  wrote:
> >
> > Basin Cove PMIC is connected to I2C0 bus which is hidden from the OS
> > and access is going via SCU device, enumerated via PCI.
> >
> > For now, we add just a minimum support of PMIC device to allow enabling,
> > e.g. USB OTG, in the OS.
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  .../asm/arch-tangier/acpi/southcluster.asl| 86 +++
> >  1 file changed, 86 insertions(+)
> >
>
> Acked-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] x86: Don't copy the cpu_call64() function to a hardcoded address

[Bin Meng]

On Sat, Feb 2, 2019 at 2:06 PM Simon Glass  wrote:
>
> On Thu, 31 Jan 2019 at 09:17, Bin Meng  wrote:
> >
> > Before jumping to 64-bit U-Boot proper, SPL copies the cpu_call64()
> > function to a hardcoded address 0x300. This can have potential
> > conflicts with application usage. Switch the destination address
> > to be allocated from the heap to avoid such risk.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  arch/x86/cpu/i386/call64.S |  4 
> >  arch/x86/cpu/i386/cpu.c| 11 ---
> >  2 files changed, 12 insertions(+), 3 deletions(-)
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] x86: Use the existing GDT in the ROM for 64-bit U-Boot proper

[Bin Meng]

On Sat, Feb 2, 2019 at 2:06 PM Simon Glass  wrote:
>
> Hi Bin,
>
> On Thu, 31 Jan 2019 at 09:17, Bin Meng  wrote:
> >
> > It is unnecessary to use a RAM version GDT for 64-bit U-Boot proper.
> > In fact we can just use the ROM version directly, which not only
> > eliminates the risk of being overwritten by application, but also
> > removes the complexity of patching the cpu_call64().
> >
> > Signed-off-by: Bin Meng 
> >
> > ---
> >
> >  arch/x86/cpu/i386/cpu.c | 14 --
> >  1 file changed, 14 deletions(-)
>
> I am not sure what issue I had with this, but I'm pleased that this works.
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support

[Alexander Graf]

> Am 12.02.2019 um 03:57 schrieb Anup Patel :
> 
>> On Mon, Feb 11, 2019 at 9:07 PM Andreas Schwab  wrote:
>> 
>>> On Feb 11 2019, Anup Patel  wrote:
>>> 
>>> This patchset adds SiFive Freedom Unleashed (FU540) support
>>> to RISC-V U-Boot.
>>> 
>>> The patches are based upon latest U-Boot source tree
>>> (git://git.denx.de/u-boot.git) at commit id
>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>>> 
>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>>> MACB Ethernet work fine on actual SiFive Unleashed board and
>>> QEMU sifive_u machine.
>> 
>> Looks like the MACB driver cannot find the correct MAC address.  That
>> makes it rather awkward for network boot.
>> 
>> Warning: ethernet@1009 (eth0) using random MAC address - 
>> 0e:14:15:06:ae:e4
> 
> This is because we don't have place to put U-Boot environment
> variables as of now on Unleashed board. This will be solved once
> we have SPI driver and SPI_MMC driver for Unleased board.
> 
> In future, we will be saving "ethaddr" environment variable on
> SPI_MMC so U-Boot will pick MAC address at boot-time from
> SPI_MMC. Once this is achieved, the above warning will go away.

How is the MAC determined in Linux?

Alex

> 
> Regards,
> Anup

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

Re: [U-Boot] [PATCH 1/3] x86: Change 4-level page table base address to low memory

[Bin Meng]

Hi Heinrich,

On Tue, Feb 5, 2019 at 7:32 PM Heinrich Schuchardt  wrote:
>
> On 2/2/19 7:06 AM, Simon Glass wrote:
> > On Thu, 31 Jan 2019 at 09:17, Bin Meng  wrote:
> >>
> >> At present the 4-level page table base address for 64-bit U-Boot
> >> proper is assigned an address that conflicts with CONFIG_LOADADDR.
> >> Change it to an address within the low memory range instead.
> >>
> >> Fixes crashes seen when 'dhcp' on QEMU x86_64 with
> >> "-net nic -net user,tftp=.,bootfile=u-boot".
> >>
> >> Reported-by: Alexander Graf 
> >> Signed-off-by: Bin Meng 
> >> ---
> >>
> >>  arch/x86/cpu/i386/cpu.c | 6 ++
> >>  1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > Reviewed-by: Simon Glass 
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> >
>
> Hello Bin,
>
> this patch is needed together with
>
> test/py: use default load address for tftp
> https://lists.denx.de/pipermail/u-boot/2019-January/356265.html
>
> to get the EFI patch queue merged.
>
> Should Tom pick the patch series?
>

Sorry I just came back from Chinese new year holiday vacation. I will
send PR to Tom ASAP.

applied to u-boot-x86, thanks!

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

Re: [U-Boot] [PATCH v1] x86: tangier: Add initial ACPI support for PMIC device

[Bin Meng]

On Tue, Feb 5, 2019 at 7:07 PM Andy Shevchenko
 wrote:
>
> Basin Cove PMIC is connected to I2C0 bus which is hidden from the OS
> and access is going via SCU device, enumerated via PCI.
>
> For now, we add just a minimum support of PMIC device to allow enabling,
> e.g. USB OTG, in the OS.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  .../asm/arch-tangier/acpi/southcluster.asl| 86 +++
>  1 file changed, 86 insertions(+)
>

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

Re: [U-Boot] [PATCH] Fix : Uboot crash when booting from SD.

[Prabhakar Kushwaha]

> -Original Message-
> From: Meenakshi Aggarwal 
> Sent: Tuesday, February 12, 2019 4:51 PM
> To: u-boot@lists.denx.de; Prabhakar Kushwaha
> 
> Cc: Meenakshi Aggarwal ; Udit Kumar
> 
> Subject: [PATCH] Fix : Uboot crash when booting from SD.
> 
> Issue : In case of SD boot, u-boot was crashing due to DDR was not coherent
> 
> Fix : Making DDR as device memory will make sure DDR is coherent when we
> are relocating the code

Please work on the subject and description.
Avoid writing description as you have written. 

--pk


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

[U-Boot] [PATCH] Fix : Uboot crash when booting from SD.

[Meenakshi Aggarwal]

Issue : In case of SD boot, u-boot was crashing due to DDR was not
coherent

Fix : Making DDR as device memory will make sure DDR is coherent
when we are relocating the code

Signed-off-by: Meenakshi Aggarwal 
Signed-off-by: Udit Kumar 
---
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 978d46b..cb1abf3 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -102,7 +102,7 @@ static struct mm_region early_map[] = {
  CONFIG_SYS_FSL_DRAM_SIZE1,
 #if defined(CONFIG_TFABOOT) || \
(defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD))
- PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+ PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 #else  /* Start with nGnRnE and PXN and UXN to prevent speculative access */
  PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | PTE_BLOCK_PXN | PTE_BLOCK_UXN |
 #endif
-- 
1.9.1

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

Re: [U-Boot] [PATCH] mc : Add support to run MC in 128 MB DDR size

[Meenakshi Aggarwal]

> -Original Message-
> From: Ashish Kumar
> Sent: Tuesday, February 12, 2019 10:12 AM
> To: Meenakshi Aggarwal ; u-
> b...@lists.denx.de; Prabhakar Kushwaha 
> Cc: Meenakshi Aggarwal 
> Subject: RE: [PATCH] mc : Add support to run MC in 128 MB DDR size
> 
> 
> 
> > -Original Message-
> > From: Meenakshi Aggarwal 
> > Sent: Tuesday, February 12, 2019 2:44 PM
> > To: u-boot@lists.denx.de; Prabhakar Kushwaha
> > 
> > Cc: Meenakshi Aggarwal 
> > Subject: [PATCH] mc : Add support to run MC in 128 MB DDR size
> Ashish: Rephrase to "Reduce MC memory size to 128M" from the above it sound
> like system DDR is 128MB
> >
> > ls2088, ls1088 : minimum DDR size for MC is 128 MB
> > lx2 : minimum DDR size for MC is 256 MB
> >
> > Signed-off-by: Meenakshi Aggarwal 
> > ---
> >  drivers/net/fsl-mc/mc.c  | 20 +---
> >  include/configs/ls1088a_common.h |  2 +-
> > include/configs/ls2080a_common.h
> > |  2 +-  include/configs/lx2160a_common.h |  2 +-
> >  4 files changed, 20 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c index
> > fa0a05d..98c57ed 100644
> > --- a/drivers/net/fsl-mc/mc.c
> > +++ b/drivers/net/fsl-mc/mc.c
> > @@ -684,7 +684,15 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
> > size_t mc_ram_size = mc_get_dram_block_size();
> >
> > mc_ram_num_256mb_blocks = mc_ram_size /
> MC_RAM_SIZE_ALIGNMENT;
> > -   if (mc_ram_num_256mb_blocks < 1 || mc_ram_num_256mb_blocks >
> > 0xff) {
> > +
> > +   /*
> > +* To support 128 MB DDR Size for MC
> > +*/
> Ashish: How does the MC grow now, wrt to MC base ?.
> Earlier it was 2 blocks of 256 up and rest down.
No changes done in this respect, it is same as before depending on MC size.
For 128 MB, we are reserving only 128 M up and rest down.

> Considering MC base alignment is 512. 256 MB  is always wasted from top of the
> memory, now since the minimum block is 128MB
We are reserving only DDR memory according to the size of MC, so if it is 128 
M, 
then we are reserving only 128 M (surely, base address is 512 MB aligned).
Rest DDR memory is available for uboot to use and is marked as free.

> > +   if (mc_ram_num_256mb_blocks == 0) {
> > +   mc_ram_num_256mb_blocks = 0xFF;
> > +   }
> > +
> > +   if (mc_ram_num_256mb_blocks > 0xff) {
> > error = -EINVAL;
> > printf("fsl-mc: ERROR: invalid MC private RAM size (%lu)\n",
> >mc_ram_size);
> > @@ -731,8 +739,14 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
> > /*
> >  * Tell MC what is the address range of the DRAM block assigned to it:
> >  */
> > -   reg_mcfbalr = (u32)mc_ram_addr |
> > - (mc_ram_num_256mb_blocks - 1);
> > +   if (mc_ram_num_256mb_blocks < 0xFF) {
> > +   reg_mcfbalr = (u32)mc_ram_addr |
> > +   (mc_ram_num_256mb_blocks - 1);
> > +   } else {
> > +   reg_mcfbalr = (u32)mc_ram_addr |
> > +   (mc_ram_num_256mb_blocks);
> > +   }
> > +
> > out_le32(_ccsr_regs->reg_mcfbalr, reg_mcfbalr);
> > out_le32(_ccsr_regs->reg_mcfbahr,
> >  (u32)(mc_ram_addr >> 32));
> > diff --git a/include/configs/ls1088a_common.h
> > b/include/configs/ls1088a_common.h
> > index 89133c2..1509292 100644
> > --- a/include/configs/ls1088a_common.h
> > +++ b/include/configs/ls1088a_common.h
> > @@ -154,7 +154,7 @@ unsigned long long get_qixis_addr(void);
> >   */
> >
> >  #if defined(CONFIG_FSL_MC_ENET)
> > -#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE
>   (512UL *
> > 1024 * 1024)
> > +#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE
>   (128UL *
> > 1024 * 1024)
> >  #endif
> >  /* Command line configuration */
> >  #define CONFIG_CMD_CACHE
> > diff --git a/include/configs/ls2080a_common.h
> > b/include/configs/ls2080a_common.h
> > index ab38981..7c1d35b 100644
> > --- a/include/configs/ls2080a_common.h
> > +++ b/include/configs/ls2080a_common.h
> > @@ -159,7 +159,7 @@ unsigned long long get_qixis_addr(void);
> >   * 512MB aligned, so the min size to hide is 512MB.
> >   */
> >  #ifdef CONFIG_FSL_MC_ENET
> > -#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE
>   (512UL *
> > 1024 * 1024)
> > +#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE
>   (128UL *
> > 1024 * 1024)
> >  #endif
> >
> >  /* Command line configuration */
> > diff --git a/include/configs/lx2160a_common.h
> > b/include/configs/lx2160a_common.h
> > index 0f1a621..c4bbe96 100644
> > --- a/include/configs/lx2160a_common.h
> > +++ b/include/configs/lx2160a_common.h
> > @@ -102,7 +102,7 @@
> >   * 512MB aligned, so the min size to hide is 512MB.
> >   */
> >  #ifdef CONFIG_FSL_MC_ENET
> > -#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (512UL * 1024
> *
> > 1024)
> > +#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (256UL * 1024
> *
> > 1024)
> >  #endif
> >
> >  /* I2C bus multiplexer */
> > --
> > 1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [RFC v2 02/15] efi_loader: boottime: convert efi_loaded_image_obj to DM

[AKASHI Takahiro]

Heinrich,

On Fri, Feb 08, 2019 at 06:53:00PM +0100, Heinrich Schuchardt wrote:
> On 2/8/19 9:15 AM, AKASHI Takahiro wrote:
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  include/efi_loader.h  |  2 +-
> >  lib/efi_loader/efi_boottime.c | 61 +++
> >  2 files changed, 35 insertions(+), 28 deletions(-)
> > 
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 4d5e22564a72..5882cd7dd3b0 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -367,7 +367,7 @@ efi_status_t efi_install_configuration_table(const 
> > efi_guid_t *guid, void *table
> >  /* Sets up a loaded image */
> >  efi_status_t efi_setup_loaded_image(struct efi_device_path *device_path,
> > struct efi_device_path *file_path,
> > -   struct efi_loaded_image_obj **handle_ptr,
> > +   efi_handle_t *handle_ptr,
> > struct efi_loaded_image **info_ptr);
> >  efi_status_t efi_load_image_from_path(struct efi_device_path *file_path,
> >   void **buffer);
> > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> > index d23e4fbbdf23..624156d4578b 100644
> > --- a/lib/efi_loader/efi_boottime.c
> > +++ b/lib/efi_loader/efi_boottime.c
> > @@ -1690,29 +1690,29 @@ static efi_status_t EFIAPI 
> > efi_install_configuration_table_ext(efi_guid_t *guid,
> >   */
> >  efi_status_t efi_setup_loaded_image(struct efi_device_path *device_path,
> > struct efi_device_path *file_path,
> > -   struct efi_loaded_image_obj **handle_ptr,
> > +   efi_handle_t *handle_ptr,
> > struct efi_loaded_image **info_ptr)
> >  {
> > efi_status_t ret;
> > struct efi_loaded_image *info;
> > -   struct efi_loaded_image_obj *obj;
> > +   struct udevice *dev;
> >  
> > info = calloc(1, sizeof(*info));
> > if (!info)
> > return EFI_OUT_OF_RESOURCES;
> > -   obj = calloc(1, sizeof(*obj));
> > -   if (!obj) {
> > +
> > +   ret = device_bind_driver(dm_root(), "efi_loaded_image", "(IMG)", );
> 
> A loaded image is not a device. There is nothing in the EFI world
> relating the loaded image directly to the root of the device tree.

Please notice that any loaded image is linked to "efi_root",
not "root of the device tree."

Such a relationship is an analogy to the current implementation
where *global* protocols are added to "efi_root" for now. 

-Takahiro Akashi

> We should not create a meaningless link here.
> 
> Best regards
> 
> Heinrich
> 
> 
> > +   if (ret) {
> > free(info);
> > return EFI_OUT_OF_RESOURCES;
> > }
> >  
> > -   /* Add internal object to object list */
> > -   efi_add_handle(>header);
> > +   efi_add_handle(dev);
> >  
> > if (info_ptr)
> > *info_ptr = info;
> > if (handle_ptr)
> > -   *handle_ptr = obj;
> > +   *handle_ptr = dev;
> >  
> > info->revision =  EFI_LOADED_IMAGE_PROTOCOL_REVISION;
> > info->file_path = file_path;
> > @@ -1724,7 +1724,7 @@ efi_status_t efi_setup_loaded_image(struct 
> > efi_device_path *device_path,
> >  * When asking for the device path interface, return
> >  * bootefi_device_path
> >  */
> > -   ret = efi_add_protocol(>header,
> > +   ret = efi_add_protocol(dev,
> >_guid_device_path, device_path);
> > if (ret != EFI_SUCCESS)
> > goto failure;
> > @@ -1734,24 +1734,24 @@ efi_status_t efi_setup_loaded_image(struct 
> > efi_device_path *device_path,
> >  * When asking for the loaded_image interface, just
> >  * return handle which points to loaded_image_info
> >  */
> > -   ret = efi_add_protocol(>header,
> > +   ret = efi_add_protocol(dev,
> >_guid_loaded_image, info);
> > if (ret != EFI_SUCCESS)
> > goto failure;
> >  
> > -   ret = efi_add_protocol(>header,
> > +   ret = efi_add_protocol(dev,
> >_guid_hii_string_protocol,
> >(void *)_hii_string);
> > if (ret != EFI_SUCCESS)
> > goto failure;
> >  
> > -   ret = efi_add_protocol(>header,
> > +   ret = efi_add_protocol(dev,
> >_guid_hii_database_protocol,
> >(void *)_hii_database);
> > if (ret != EFI_SUCCESS)
> > goto failure;
> >  
> > -   ret = efi_add_protocol(>header,
> > +   ret = efi_add_protocol(dev,
> >_guid_hii_config_routing_protocol,
> >(void *)_hii_config_routing);
> > if (ret != EFI_SUCCESS)
> > @@ -1835,9 +1835,8 @@ static efi_status_t EFIAPI efi_load_image(bool 
> > boot_policy,
> >   efi_uintn_t source_size,
> 

Re: [U-Boot] [PATCH] riscv: fu540: enable SMP

[Anup Patel]

> -Original Message-
> From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> Sent: Tuesday, February 12, 2019 4:12 AM
> To: u-boot@lists.denx.de
> Cc: Atish Patra ; Anup Patel
> ; Bin Meng ; Andreas
> Schwab ; Palmer Dabbelt ;
> Alexander Graf ; Lukas Auer
> ; Anup Patel ;
> Atish Patra ; Paul Walmsley
> 
> Subject: [PATCH] riscv: fu540: enable SMP
> 
> Hart 0 on the SiFive FU540 is meant for monitoring tasks. It is a E51 core,
> whereas all other cores are U54 cores. Select hart 1 as the main hart to run 
> U-
> Boot.
> 
> Signed-off-by: Lukas Auer 
> ---
> This patch depends on the SMP support [1] and the SiFive FU540 support
> patch series [2].
> I have submitted it independently from the SMP support patch series to
> allow the series to be merged independently from the SiFive FU540 support
> patch series.
> 
> [1]: https://patchwork.ozlabs.org/project/uboot/list/?series=91320
> [2]: https://patchwork.ozlabs.org/project/uboot/list/?series=91125
> 
>  board/sifive/fu540/Kconfig | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig index
> 6be3d88144..d8a6020cf8 100644
> --- a/board/sifive/fu540/Kconfig
> +++ b/board/sifive/fu540/Kconfig
> @@ -16,6 +16,9 @@ config SYS_TEXT_BASE
>   default 0x8000 if !RISCV_SMODE
>   default 0x8020 if RISCV_SMODE
> 
> +config MAIN_HART
> + default 1
> +
>  config BOARD_SPECIFIC_OPTIONS # dummy
>   def_bool y
>   select GENERIC_RISCV
> @@ -38,5 +41,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
>   imply PHY_LIB
>   imply PHY_MSCC
>   imply SIFIVE_SERIAL
> + imply SMP
> 
>  endif
> --
> 2.20.1

It will be better if we can get rid off MAIN_HART config option.
Otherwise, looks good to me.

Reviewed-by: Anup Patel 

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

Re: [U-Boot] [RFC v2 01/15] efi_loader: efi objects and protocols as DM devices

[AKASHI Takahiro]

Heinrich,

On Fri, Feb 08, 2019 at 06:47:12PM +0100, Heinrich Schuchardt wrote:
> On 2/8/19 9:15 AM, AKASHI Takahiro wrote:
> > All efi objects are presented as DM devices, either existing device types
> > or efi-specific, and efi_handle_t is an opaque pointer to "struct udevice."
> > 
> > We still maintain efi_obj_list as it is quite inefficient to traverse
> > the DM hierarchy to find any efi objects, which are just part of it.
> > 
> > All efi protocols are also presented as DM devices, replacing
> > "struct efi_handler" with "struct udevice." So searching for an efi
> > protocol is nothing but traversing child nodes under a device.
> > 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  include/dm/device.h   |   3 +
> >  include/dm/uclass-id.h|   2 +
> >  include/efi.h |   4 +-
> >  include/efi_loader.h  |  37 +--
> >  lib/efi_loader/efi_boottime.c | 544 --
> >  5 files changed, 400 insertions(+), 190 deletions(-)
> > 
> > diff --git a/include/dm/device.h b/include/dm/device.h
> > index 27a6d7b9fdb0..0d82402c8e70 100644
> > --- a/include/dm/device.h
> > +++ b/include/dm/device.h
> > @@ -146,6 +146,9 @@ struct udevice {
> >  #ifdef CONFIG_DEVRES
> > struct list_head devres_head;
> >  #endif
> > +#ifdef CONFIG_EFI_LOADER
> > +   void *efi_obj;
> > +#endif
> >  };
> >  
> >  /* Maximum sequence number supported */
> > diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> > index f3bafb3c6353..fb0ab40891c8 100644
> > --- a/include/dm/uclass-id.h
> > +++ b/include/dm/uclass-id.h
> > @@ -40,6 +40,8 @@ enum uclass_id {
> > UCLASS_DISPLAY, /* Display (e.g. DisplayPort, HDMI) */
> > UCLASS_DMA, /* Direct Memory Access */
> > UCLASS_EFI, /* EFI managed devices */
> > +   UCLASS_EFI_OBJECT,  /* EFI managed objects */
> > +   UCLASS_EFI_PROTOCOL,/* EFI managed protocols */
> > UCLASS_ETH, /* Ethernet device */
> > UCLASS_FIRMWARE,/* Firmware */
> > UCLASS_FS_FIRMWARE_LOADER,  /* Generic loader */
> > diff --git a/include/efi.h b/include/efi.h
> > index b5e2c64f38b5..58902299a9a0 100644
> > --- a/include/efi.h
> > +++ b/include/efi.h
> > @@ -96,7 +96,9 @@ typedef struct {
> >  typedef unsigned long efi_status_t;
> >  typedef u64 efi_physical_addr_t;
> >  typedef u64 efi_virtual_addr_t;
> > -typedef struct efi_object *efi_handle_t;
> > +/* Eventually this should be 'void *' */
> > +struct udevice;
> > +typedef struct udevice *efi_handle_t;
> >  
> >  #define EFI_GUID(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
> > {{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, \
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 3077a1e9d58b..4d5e22564a72 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -167,38 +167,12 @@ struct efi_open_protocol_info_item {
> >   * protocol GUID to the respective protocol interface
> >   */
> >  struct efi_handler {
> > -   /* Link to the list of protocols of a handle */
> > -   struct list_head link;
> > const efi_guid_t *guid;
> > void *protocol_interface;
> > /* Link to the list of open protocol info items */
> > struct list_head open_infos;
> >  };
> >  
> > -/**
> > - * struct efi_object - dereferenced EFI handle
> > - *
> > - * @link:  pointers to put the handle into a linked list
> > - * @protocols: linked list with the protocol interfaces installed on 
> > this
> > - * handle
> > - *
> > - * UEFI offers a flexible and expandable object model. The objects in the 
> > UEFI
> > - * API are devices, drivers, and loaded images. struct efi_object is our 
> > storage
> > - * structure for these objects.
> > - *
> > - * When including this structure into a larger structure always put it 
> > first so
> > - * that when deleting a handle the whole encompassing structure can be 
> > freed.
> > - *
> > - * A pointer to this structure is referred to as a handle. Typedef 
> > efi_handle_t
> > - * has been created for such pointers.
> > - */
> > -struct efi_object {
> > -   /* Every UEFI object is part of a global object list */
> > -   struct list_head link;
> > -   /* The list of protocols */
> > -   struct list_head protocols;
> > -};
> > -
> >  /**
> >   * struct efi_loaded_image_obj - handle of a loaded image
> >   *
> > @@ -209,7 +183,6 @@ struct efi_object {
> >   * @entry: entry address of the relocated image
> >   */
> >  struct efi_loaded_image_obj {
> > -   struct efi_object header;
> > void *reloc_base;
> > aligned_u64 reloc_size;
> > efi_status_t exit_status;
> > @@ -312,18 +285,18 @@ void efi_restore_gd(void);
> >  void efi_runtime_relocate(ulong offset, struct efi_mem_desc *map);
> >  /* Call this to set the current device name */
> >  void efi_set_bootdev(const char *dev, const char *devnr, const char *path);
> > +/* Go through all the efi objects and call func() for each */
> > +efi_status_t 

Re: [U-Boot] [PATCH] mc : Add support to run MC in 128 MB DDR size

[Ashish Kumar]

> -Original Message-
> From: Meenakshi Aggarwal 
> Sent: Tuesday, February 12, 2019 2:44 PM
> To: u-boot@lists.denx.de; Prabhakar Kushwaha
> 
> Cc: Meenakshi Aggarwal 
> Subject: [PATCH] mc : Add support to run MC in 128 MB DDR size
Ashish: Rephrase to "Reduce MC memory size to 128M" from the above it sound 
like system DDR is 128MB
> 
> ls2088, ls1088 : minimum DDR size for MC is 128 MB
> lx2 : minimum DDR size for MC is 256 MB
> 
> Signed-off-by: Meenakshi Aggarwal 
> ---
>  drivers/net/fsl-mc/mc.c  | 20 +---
>  include/configs/ls1088a_common.h |  2 +-  include/configs/ls2080a_common.h
> |  2 +-  include/configs/lx2160a_common.h |  2 +-
>  4 files changed, 20 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c index
> fa0a05d..98c57ed 100644
> --- a/drivers/net/fsl-mc/mc.c
> +++ b/drivers/net/fsl-mc/mc.c
> @@ -684,7 +684,15 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
>   size_t mc_ram_size = mc_get_dram_block_size();
> 
>   mc_ram_num_256mb_blocks = mc_ram_size /
> MC_RAM_SIZE_ALIGNMENT;
> - if (mc_ram_num_256mb_blocks < 1 || mc_ram_num_256mb_blocks >
> 0xff) {
> +
> + /*
> +  * To support 128 MB DDR Size for MC
> +  */
Ashish: How does the MC grow now, wrt to MC base ?.
Earlier it was 2 blocks of 256 up and rest down. 
Considering MC base alignment is 512. 256 MB  is always wasted from top of the 
memory, now since the minimum block is 128MB
> + if (mc_ram_num_256mb_blocks == 0) {
> + mc_ram_num_256mb_blocks = 0xFF;
> + }
> +
> + if (mc_ram_num_256mb_blocks > 0xff) {
>   error = -EINVAL;
>   printf("fsl-mc: ERROR: invalid MC private RAM size (%lu)\n",
>  mc_ram_size);
> @@ -731,8 +739,14 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
>   /*
>* Tell MC what is the address range of the DRAM block assigned to it:
>*/
> - reg_mcfbalr = (u32)mc_ram_addr |
> -   (mc_ram_num_256mb_blocks - 1);
> + if (mc_ram_num_256mb_blocks < 0xFF) {
> + reg_mcfbalr = (u32)mc_ram_addr |
> + (mc_ram_num_256mb_blocks - 1);
> + } else {
> + reg_mcfbalr = (u32)mc_ram_addr |
> + (mc_ram_num_256mb_blocks);
> + }
> +
>   out_le32(_ccsr_regs->reg_mcfbalr, reg_mcfbalr);
>   out_le32(_ccsr_regs->reg_mcfbahr,
>(u32)(mc_ram_addr >> 32));
> diff --git a/include/configs/ls1088a_common.h
> b/include/configs/ls1088a_common.h
> index 89133c2..1509292 100644
> --- a/include/configs/ls1088a_common.h
> +++ b/include/configs/ls1088a_common.h
> @@ -154,7 +154,7 @@ unsigned long long get_qixis_addr(void);
>   */
> 
>  #if defined(CONFIG_FSL_MC_ENET)
> -#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE (512UL *
> 1024 * 1024)
> +#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE (128UL *
> 1024 * 1024)
>  #endif
>  /* Command line configuration */
>  #define CONFIG_CMD_CACHE
> diff --git a/include/configs/ls2080a_common.h
> b/include/configs/ls2080a_common.h
> index ab38981..7c1d35b 100644
> --- a/include/configs/ls2080a_common.h
> +++ b/include/configs/ls2080a_common.h
> @@ -159,7 +159,7 @@ unsigned long long get_qixis_addr(void);
>   * 512MB aligned, so the min size to hide is 512MB.
>   */
>  #ifdef CONFIG_FSL_MC_ENET
> -#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE (512UL *
> 1024 * 1024)
> +#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE (128UL *
> 1024 * 1024)
>  #endif
> 
>  /* Command line configuration */
> diff --git a/include/configs/lx2160a_common.h
> b/include/configs/lx2160a_common.h
> index 0f1a621..c4bbe96 100644
> --- a/include/configs/lx2160a_common.h
> +++ b/include/configs/lx2160a_common.h
> @@ -102,7 +102,7 @@
>   * 512MB aligned, so the min size to hide is 512MB.
>   */
>  #ifdef CONFIG_FSL_MC_ENET
> -#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE (512UL * 1024 *
> 1024)
> +#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE (256UL * 1024 *
> 1024)
>  #endif
> 
>  /* I2C bus multiplexer */
> --
> 1.9.1

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

Re: [U-Boot] [PATCHv3 10/11] pci: ls_pcie_g4: Add Workaround for A-011451

[Bin Meng]

Hi,

On Fri, Jan 25, 2019 at 6:07 PM Z.q. Hou  wrote:
>
> From: Hou Zhiqiang 
>
> When LAYERSCAPE Gen4 PCIe controller is sending multiple split
> completions and ACK latency expires indicating that ACK should
> be send at priority. But because of large number of split
> completions and FC update DLLP, the controller does not give
> priority to ACK transmission. This results into ACK latency
> timer timeout error at the link partner and the pending TLPs
> are replayed by the link partner again.
>
> Workaround:
> 1. Reduce the ACK latency timeout value to a very small value.
> 2. Restrict the number of completions from the PCIe controller
>to 1, by changing the Max Read Request Size (MRRS) of link
>partner to the same value as Max Packet size (MPS).
>
> This ERRATA is only for LX2160A Rev1.0 and will be fixed in Rev2.0.
>
> Signed-off-by: Hou Zhiqiang 
> ---
> V3:
>  - New patch.
>
>  drivers/pci/pci_auto.c | 34 ++
>  drivers/pci/pcie_layerscape_gen4.c |  8 +++
>  drivers/pci/pcie_layerscape_gen4.h |  4 
>  include/pci.h  |  9 
>  include/pci_ids.h  |  1 +
>  5 files changed, 56 insertions(+)
>
> diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
> index d7237f6eee..37307bd54b 100644
> --- a/drivers/pci/pci_auto.c
> +++ b/drivers/pci/pci_auto.c
> @@ -22,6 +22,7 @@ void dm_pciauto_setup_device(struct udevice *dev, int 
> bars_num,
>  struct pci_region *prefetch, struct pci_region 
> *io,
>  bool enum_only)
>  {
> +   struct udevice *rp = pci_get_controller(dev);
> u32 bar_response;
> pci_size_t bar_size;
> u16 cmdstat = 0;
> @@ -32,6 +33,9 @@ void dm_pciauto_setup_device(struct udevice *dev, int 
> bars_num,
> struct pci_region *bar_res = NULL;
> int found_mem64 = 0;
> u16 class;
> +   int pos;
> +   u16 val, vendor, dev_id;
> +   u8 rev;
>
> dm_pci_read_config16(dev, PCI_COMMAND, );
> cmdstat = (cmdstat & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) |
> @@ -161,6 +165,36 @@ void dm_pciauto_setup_device(struct udevice *dev, int 
> bars_num,
> dm_pci_write_config8(dev, PCI_CACHE_LINE_SIZE,
>  CONFIG_SYS_PCI_CACHE_LINE_SIZE);
> dm_pci_write_config8(dev, PCI_LATENCY_TIMER, 0x80);
> +
> +   /*
> +* When NXP LAYERSCAPE Gen4 PCIe controller is sending multiple split
> +* completions and ACK latency expires indicating that ACK should be
> +* send at priority. But because of large number of split completions
> +* and FC update DLLP, the controller does not give priority to ACK
> +* transmission. This results into ACK latency timer timeout error at
> +* the link partner and the pending TLPs are replayed by the link
> +* partner again.
> +*
> +* The workaround:
> +* Restrict the number of completions from the PCIe controller to 1,
> +* by changing the Max Read Request Size (MRRS) of link partner to the
> +* same value as Max Packet size (MPS).
> +*
> +* So, set both the MPS and MRRS to the minimum 128B.
> +*/
> +   dm_pci_read_config16(rp, PCI_VENDOR_ID, );
> +   dm_pci_read_config16(rp, PCI_DEVICE_ID, _id);
> +   dm_pci_read_config8(rp, PCI_REVISION_ID, );
> +   if (vendor == PCI_VENDOR_ID_FREESCALE &&
> +   dev_id == PCI_DEVICE_ID_LX2160A && rev == 0x10) {
> +   pos = dm_pci_find_capability(dev, PCI_CAP_ID_EXP);
> +   if (pos) {
> +   dm_pci_read_config16(dev, pos + PCI_EXP_DEVCTL, );
> +   val &= ~(PCI_EXP_DEVCTL_READRQ |
> +PCI_EXP_DEVCTL_PAYLOAD);
> +   dm_pci_write_config16(dev, pos + PCI_EXP_DEVCTL, val);
> +   }
> +   }

Can this be done in the probe() routine of the driver codes?

>  }
>
>  void dm_pciauto_prescan_setup_bridge(struct udevice *dev, int sub_bus)
> diff --git a/drivers/pci/pcie_layerscape_gen4.c 
> b/drivers/pci/pcie_layerscape_gen4.c
> index 799da2f7df..b530a9979c 100644
> --- a/drivers/pci/pcie_layerscape_gen4.c
> +++ b/drivers/pci/pcie_layerscape_gen4.c
> @@ -526,6 +526,14 @@ static int ls_pcie_g4_probe(struct udevice *dev)
>
> pcie->rev = readb(pcie->ccsr + PCI_REVISION_ID);
>
> +   /* Set ACK latency timeout */
> +   if (pcie->rev == REV_1_0) {
> +   val = ccsr_readl(pcie, GPEX_ACK_REPLAY_TO);
> +   val &= ~(ACK_LAT_TO_VAL_MASK << ACK_LAT_TO_VAL_SHIFT);
> +   val |= (4 << ACK_LAT_TO_VAL_SHIFT);
> +   ccsr_writel(pcie, GPEX_ACK_REPLAY_TO, val);
> +   }
> +
> pcie->mode = readb(pcie->ccsr + PCI_HEADER_TYPE) & 0x7f;
>
> if (pcie->mode == PCI_HEADER_TYPE_NORMAL) {
> diff --git a/drivers/pci/pcie_layerscape_gen4.h 
> b/drivers/pci/pcie_layerscape_gen4.h
> 

Re: [U-Boot] [PATCH] board: ti: Move fastboot functions out of TI_SECURE_DEVICE ifdef

[Lokesh Vutla]

On 11/02/19 7:30 PM, Andrew F. Davis wrote:
> When these were moved from mach-omap2 to board files they got placed
> inside TI_SECURE_DEVICE ifdef block, they are not secure only, move
> them up and out.
> 
> Fixes: 413b90777f8d ("ti: fastboot: Move weak overrides to board files")
> Signed-off-by: Andrew F. Davis 


Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

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

Re: [U-Boot] [PATCH 2/7] ARM: k2g-gp-evm: update to rgmii pinmux configuration

[Lokesh Vutla]

On 11/02/19 10:45 PM, Murali Karicheri wrote:
> This patch updates pinmux configuration for K2G GP EVM based on
> data generated by the pinmux tool at
> https://dev.ti.com/pinmux/app.html#/default
> 
> Signed-off-by: Murali Karicheri 


Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

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

Re: [U-Boot] [PATCH 1/7] ARM: k2g-ice: Add pinmux support for rgmii interface

[Lokesh Vutla]

On 11/02/19 10:45 PM, Murali Karicheri wrote:
> This add pinmux configuration for rgmii interface so that network
> driver can be supported on K2G ICE boards. The pinmux configurations
> for this are generated using the pinmux tool at
> https://dev.ti.com/pinmux/app.html#/default
> 
> As this required some BUFFER_CLASS definitions, same is re-used
> from the linux defnitions in include/dt-bindings/pinctrl/keystone.h
> 
> Signed-off-by: Murali Karicheri 

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

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

Re: [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL

[Adam Ford]

On Tue, Jan 29, 2019 at 7:36 AM Adam Ford  wrote:
>
> On Mon, Jan 28, 2019 at 2:33 PM Tom Rini  wrote:
> >
> > On Mon, Jan 28, 2019 at 02:23:00PM -0600, Adam Ford wrote:
> > > On Mon, Jan 28, 2019 at 9:14 AM Tom Rini  wrote:
> > > >
> > > > On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote:
> > > > > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford  wrote:
> > > > > >
> > > > > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack  wrote:
> > > > > > >
> > > > > > > Hello Adam,
> > > > > > >
> > > > > > > On 23.01.2019 22:13, Adam Ford wrote:
> > > > > > > > By removing EXT support from SPL, it makes room for the extra
> > > > > > > > overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> > > > > > > > enabled, extra options need to be added to the device tree to
> > > > > > > > tell it which portions of the tree are needed early in boot time
> > > > > > > >
> > > > > > > > Unfortunately, with these options as-is, the system doesn't boot
> > > > > > > > nor does it display anything on the UART.  I don't have a 
> > > > > > > > debugger
> > > > > > > > readily available, but I have seen others with AM33x boards 
> > > > > > > > which
> > > > > > > > are similar to OMAP3 boards. This is posted as an RFC just in 
> > > > > > > > case
> > > > > > > > anyone has any suggestions on what  might be missing.
> > > > > > > >
> > > > > > > On an AM335x board I had problems when moving from embedded to 
> > > > > > > separate
> > > > > > > DTB. Even if deprecated you should probably give CONFIG_OF_EMBED 
> > > > > > > a try.
> > > > > > > If this works you could go back to CONFIG_OF_SEPARATE and 
> > > > > > > probably give
> > > > > > > CONFIG_SPL_SEPARATE_BSS a try.
> > > > > > > Also CONFIG_DEBUG_UART (assumed the pin configuration is working) 
> > > > > > > did
> > > > > > > help me quite a lot.
> > > > > >
> > > > > > I had to turn off DM_SERIAL temporarily to get some debugging going.
> > > > > > I 'think' there is something wrong with fetching data from the 
> > > > > > device
> > > > > > tree.
> > > > > >
> > > > > > I tried both OF_EMBDED and OF_SEPARATE without luck.  
> > > > > > SPL_SEPARATE_BSS is set.
> > > > > >
> > > > > > U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 
> > > > > > -0600)
> > > > > > Trying to boot from MMC1
> > > > > > uclass_find_device_by_seq: 0 0
> > > > > >- not found
> > > > > > uclass_find_device_by_seq: 1 0
> > > > > >- not found
> > > > > > spl: could not find mmc device 0. error: -19
> > > > > > SPL: failed to boot from all boot devices
> > > > > > ### ERROR ### Please RESET the board ###
> > > > > >
> > > > > > I can see the mmc0 device is appearing in my SPL dtb file.
> > > > > >
> > > > > > I am not sure what these values are support to be, but I was able to
> > > > > > do a dump of my spl device tree:
> > > > > >
> > > > > >  dtc -I dtb -O dts spl/u-boot-spl.dtb
> > > > >
> > > > > Looking at Tom's defconfig file changes for the beagle, I noticed he
> > > > > disabled Falcon mode.  As soon as I disabled Falcon mode, I was able
> > > > > to get my device tree based SPL to initialize both serial and MMC.
> > > > > With Falcon mode enabled, it immediately stops booting and/or showing
> > > > > anything.  There seems to be some correlation, because disabling it
> > > > > again make it work.
> > > > >
> > > > > With DM_SERIAL off, I can see the dumps to the screen and with the
> > > > > debugging enabled, I can see that it is not able to locate the MMC
> > > > > device.  I am going to assume that if it cannot find the MMC device,
> > > > > it probably cannot find the serial device which may explain why
> > > > > disabling DM_SERIAL in SPL with Falcon mode on shows text.
> > > > >
> > > > > Might someone have any suggestions as to how to get both SPL_OF_CONFIG
> > > > > with Falcon working?  I'd really like to keep that enabled by default.
> > > >
> > > > Note that I disabled Falcon for the space savings to keep MLO small
> > > > enough, not that I noticed it failing to work.  Given that with my
> > > > patches what does work is loading an un-patched-for-DM-and-SPL u-boot
> > > > and doesn't work is booting the u-boot.img I just built if there's not
> > > > some overlap there.  Perhaps the addresses being used for
> > > > BSS/malloc/whatever are stomping on the image and that's wrecking
> > > > things?
> > > >
> > >
> > > Is there an easy way to debug memory utilization?  We're not quite
> > > getting to the point of loading u-boot.img since it cannot find the
> > > MMC driver.
> > >
> > > Interestingly enough, when I rebased my quasi-working image with the
> > > master, it died.  I can still build DM_SPL without SPL_OF_CONTROL but
> > > now even with Falcon disabled, any attempts to build with
> > > SPL_OF_CONTROL fail.
> > > I even tried using OF_PLATDATA hoping it might reduce the memory 
> > > footprint.
> > >
> > > I'm going to go back to 2019.01 and run some tests, but any pointers
> > > on how to debug memory allocation might be helpful.
> >

Re: [U-Boot] [PATCHv3 08/11] armv8: lx2160a: enable the pci command

[Bin Meng]

On Fri, Jan 25, 2019 at 6:07 PM Z.q. Hou  wrote:
>
> From: Hou Zhiqiang 
>
> Signed-off-by: Hou Zhiqiang 
> ---
> V3:
>  - No change
>
>  include/configs/lx2160a_common.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/configs/lx2160a_common.h 
> b/include/configs/lx2160a_common.h
> index 41931e5b53..19053b43a1 100644
> --- a/include/configs/lx2160a_common.h
> +++ b/include/configs/lx2160a_common.h
> @@ -129,6 +129,7 @@
>  #ifdef CONFIG_PCI
>  #define CONFIG_SYS_PCI_64BIT
>  #define CONFIG_PCI_SCAN_SHOW
> +#define CONFIG_CMD_PCI

This is already a Kconfig option. Please update Kconfig instead.

>  #endif
>

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

Re: [U-Boot] [PATCH 1/8] armv8: fsl-layerscpae: correct the PCIe controllers' region size

[Bin Meng]

On Tue, Oct 30, 2018 at 10:21 PM Z.q. Hou  wrote:
>
> From: Hou Zhiqiang 
>
> The LS2080A has 8GB region for each PCIe controller, while the
> other platforms have 32GB.
>
> Signed-off-by: Hou Zhiqiang 
> ---
>  arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h 
> b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> index eaa9ed251e..b4bd2c604a 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> @@ -34,10 +34,17 @@
>  #define CONFIG_SYS_FSL_QBMAN_BASE  0x81800
>  #define CONFIG_SYS_FSL_QBMAN_SIZE  0x800
>  #define CONFIG_SYS_FSL_QBMAN_SIZE_10x400
> +#ifdef CONFIG_ARCH_LS2080A
>  #define CONFIG_SYS_PCIE1_PHYS_SIZE 0x2
>  #define CONFIG_SYS_PCIE2_PHYS_SIZE 0x2
>  #define CONFIG_SYS_PCIE3_PHYS_SIZE 0x2
>  #define CONFIG_SYS_PCIE4_PHYS_SIZE 0x2
> +#else
> +#define CONFIG_SYS_PCIE1_PHYS_SIZE 0x8
> +#define CONFIG_SYS_PCIE2_PHYS_SIZE 0x8
> +#define CONFIG_SYS_PCIE3_PHYS_SIZE 0x8
> +#define CONFIG_SYS_PCIE4_PHYS_SIZE 0x8
> +#endif

Shouldn't these sizes be encoded in the ranges property of the PCIe
node in DTS files?

>  #define CONFIG_SYS_FSL_WRIOP1_BASE 0x43
>  #define CONFIG_SYS_FSL_WRIOP1_SIZE 0x1
>  #define CONFIG_SYS_FSL_AIOP1_BASE  0x4b
> --

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

Re: [U-Boot] FW: [PATCHv3 00/11] pci: Add PCIe Gen4 controller driver for NXP Layerscape SoCs

[Bin Meng]

Hi,

On Tue, Feb 12, 2019 at 11:09 AM Prabhakar Kushwaha
 wrote:
>
> [Re-sending after including mailing list]
>
> Dear Tom,
>
> > -Original Message-
> > From: Z.q. Hou
> > Sent: Friday, January 25, 2019 3:33 PM
> > To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Priyanka Jain
> > ; York Sun ;
> > sriram.d...@nxp.com; yamada.masah...@socionext.com; Prabhakar Kushwaha
> > ; Mingkai Hu ; M.h.
> > Lian 
> > Cc: Z.q. Hou 
> > Subject: [PATCHv3 00/11] pci: Add PCIe Gen4 controller driver for NXP
> > Layerscape SoCs
> >
> > From: Hou Zhiqiang 
> >
> > Add PCIe Gen4 driver for the NXP Layerscape series SoCs.
> >
> > Hou Zhiqiang (11):
> >   armv8: fsl-layerscpae: correct the PCIe controllers' region size
> >   armv8: lx2160a: add MMU table entries for PCIe
> >   pci: Add PCIe Gen4 controller driver for NXP Layerscape SoCs
> >   kconfig: add dependency PCIE_LAYERSCAPE_GEN4 for FSL_PCIE_COMPAT
> >   pci: ls_pcie_g4: add device tree fixups for PCI Stream IDs
> >   armv8: lx2160a: add PCIe controller DT nodes
> >   armv8: lx2160a: enable PCIe support on RDB defconfig
> >   armv8: lx2160a: enable the pci command
> >   pci: ls_pcie_g4: add Workaround for A-011577
> >   pci: ls_pcie_g4: Add Workaround for A-011451
> >   pci: ls_pcie_g4: add Workaround for A-011452
> >
> > Depends on the following patches:
> >   https://patchwork.ozlabs.org/patch/990088/
> >   https://patchwork.ozlabs.org/patch/990093/
> >   https://patchwork.ozlabs.org/patch/990097/
> >   https://patchwork.ozlabs.org/patch/990098/
> >
> >  arch/arm/cpu/armv8/fsl-layerscape/Kconfig |   2 +-
> >  arch/arm/cpu/armv8/fsl-layerscape/cpu.c   |  12 +
> >  arch/arm/dts/fsl-lx2160a.dtsi |  85 +++
> >  .../arm/include/asm/arch-fsl-layerscape/cpu.h |   9 +
> >  .../asm/arch-fsl-layerscape/immap_lsch3.h |  14 +-
> >  configs/lx2160ardb_tfa_defconfig  |   5 +
> >  drivers/pci/Kconfig   |   8 +
> >  drivers/pci/Makefile  |   2 +
> >  drivers/pci/pci_auto.c|  34 +
> >  drivers/pci/pcie_layerscape_gen4.c| 593 ++
> >  drivers/pci/pcie_layerscape_gen4.h| 273 
> >  drivers/pci/pcie_layerscape_gen4_fixup.c  | 249 
> >  include/configs/lx2160a_common.h  |   1 +
> >  include/pci.h |   9 +
> >  include/pci_ids.h |   1 +
> >  15 files changed, 1295 insertions(+), 2 deletions(-)  create mode
> > 100644 drivers/pci/pcie_layerscape_gen4.c
> >  create mode 100644 drivers/pci/pcie_layerscape_gen4.h
> >  create mode 100644 drivers/pci/pcie_layerscape_gen4_fixup.c
> >
>
> Sorry for my unawareness,  who is maintainer for driver/pci.
>
> I am finding multiple names for driver pcie.
> Simon Glass  (commit_signer:20/37=54%) Bin Meng 
>  (commit_signer:19/37=51%,authored:11/37=30%)
> Stefan Roese  (commit_signer:4/37=11%,authored:2/37=5%)
> York Sun  (commit_signer:4/37=11%) Tuomas Tynkkynen 
>  (commit_signer:3/37=8%,authored:3/37=8%)
> Xiaowei Bao  (authored:3/37=8%) u-boot@lists.denx.de 
> (open list)
>
> considering this patch-set is touching driver/pci. I would like PCI 
> maintainer to have a look.
> Patch related to arch/arm/../fsl-layerscape can be reviewed by me.
>

I will take a look.

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

[U-Boot] [PATCH] mc : Add support to run MC in 128 MB DDR size

[Meenakshi Aggarwal]

ls2088, ls1088 : minimum DDR size for MC is 128 MB
lx2 : minimum DDR size for MC is 256 MB

Signed-off-by: Meenakshi Aggarwal 
---
 drivers/net/fsl-mc/mc.c  | 20 +---
 include/configs/ls1088a_common.h |  2 +-
 include/configs/ls2080a_common.h |  2 +-
 include/configs/lx2160a_common.h |  2 +-
 4 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index fa0a05d..98c57ed 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -684,7 +684,15 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
size_t mc_ram_size = mc_get_dram_block_size();
 
mc_ram_num_256mb_blocks = mc_ram_size / MC_RAM_SIZE_ALIGNMENT;
-   if (mc_ram_num_256mb_blocks < 1 || mc_ram_num_256mb_blocks > 0xff) {
+
+   /*
+* To support 128 MB DDR Size for MC
+*/
+   if (mc_ram_num_256mb_blocks == 0) {
+   mc_ram_num_256mb_blocks = 0xFF;
+   }
+
+   if (mc_ram_num_256mb_blocks > 0xff) {
error = -EINVAL;
printf("fsl-mc: ERROR: invalid MC private RAM size (%lu)\n",
   mc_ram_size);
@@ -731,8 +739,14 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
/*
 * Tell MC what is the address range of the DRAM block assigned to it:
 */
-   reg_mcfbalr = (u32)mc_ram_addr |
- (mc_ram_num_256mb_blocks - 1);
+   if (mc_ram_num_256mb_blocks < 0xFF) {
+   reg_mcfbalr = (u32)mc_ram_addr |
+   (mc_ram_num_256mb_blocks - 1);
+   } else {
+   reg_mcfbalr = (u32)mc_ram_addr |
+   (mc_ram_num_256mb_blocks);
+   }
+
out_le32(_ccsr_regs->reg_mcfbalr, reg_mcfbalr);
out_le32(_ccsr_regs->reg_mcfbahr,
 (u32)(mc_ram_addr >> 32));
diff --git a/include/configs/ls1088a_common.h b/include/configs/ls1088a_common.h
index 89133c2..1509292 100644
--- a/include/configs/ls1088a_common.h
+++ b/include/configs/ls1088a_common.h
@@ -154,7 +154,7 @@ unsigned long long get_qixis_addr(void);
  */
 
 #if defined(CONFIG_FSL_MC_ENET)
-#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (512UL * 1024 * 1024)
+#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (128UL * 1024 * 1024)
 #endif
 /* Command line configuration */
 #define CONFIG_CMD_CACHE
diff --git a/include/configs/ls2080a_common.h b/include/configs/ls2080a_common.h
index ab38981..7c1d35b 100644
--- a/include/configs/ls2080a_common.h
+++ b/include/configs/ls2080a_common.h
@@ -159,7 +159,7 @@ unsigned long long get_qixis_addr(void);
  * 512MB aligned, so the min size to hide is 512MB.
  */
 #ifdef CONFIG_FSL_MC_ENET
-#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (512UL * 1024 * 1024)
+#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (128UL * 1024 * 1024)
 #endif
 
 /* Command line configuration */
diff --git a/include/configs/lx2160a_common.h b/include/configs/lx2160a_common.h
index 0f1a621..c4bbe96 100644
--- a/include/configs/lx2160a_common.h
+++ b/include/configs/lx2160a_common.h
@@ -102,7 +102,7 @@
  * 512MB aligned, so the min size to hide is 512MB.
  */
 #ifdef CONFIG_FSL_MC_ENET
-#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (512UL * 1024 * 1024)
+#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (256UL * 1024 * 1024)
 #endif
 
 /* I2C bus multiplexer */
-- 
1.9.1

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

[U-Boot] FW: [PATCHv3 00/11] pci: Add PCIe Gen4 controller driver for NXP Layerscape SoCs

[Prabhakar Kushwaha]

[Re-sending after including mailing list]

Dear Tom,

> -Original Message-
> From: Z.q. Hou
> Sent: Friday, January 25, 2019 3:33 PM
> To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; Priyanka Jain 
> ; York Sun ; 
> sriram.d...@nxp.com; yamada.masah...@socionext.com; Prabhakar Kushwaha 
> ; Mingkai Hu ; M.h. 
> Lian 
> Cc: Z.q. Hou 
> Subject: [PATCHv3 00/11] pci: Add PCIe Gen4 controller driver for NXP 
> Layerscape SoCs
> 
> From: Hou Zhiqiang 
> 
> Add PCIe Gen4 driver for the NXP Layerscape series SoCs.
> 
> Hou Zhiqiang (11):
>   armv8: fsl-layerscpae: correct the PCIe controllers' region size
>   armv8: lx2160a: add MMU table entries for PCIe
>   pci: Add PCIe Gen4 controller driver for NXP Layerscape SoCs
>   kconfig: add dependency PCIE_LAYERSCAPE_GEN4 for FSL_PCIE_COMPAT
>   pci: ls_pcie_g4: add device tree fixups for PCI Stream IDs
>   armv8: lx2160a: add PCIe controller DT nodes
>   armv8: lx2160a: enable PCIe support on RDB defconfig
>   armv8: lx2160a: enable the pci command
>   pci: ls_pcie_g4: add Workaround for A-011577
>   pci: ls_pcie_g4: Add Workaround for A-011451
>   pci: ls_pcie_g4: add Workaround for A-011452
> 
> Depends on the following patches:
>   https://patchwork.ozlabs.org/patch/990088/
>   https://patchwork.ozlabs.org/patch/990093/
>   https://patchwork.ozlabs.org/patch/990097/
>   https://patchwork.ozlabs.org/patch/990098/
> 
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig |   2 +-
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c   |  12 +
>  arch/arm/dts/fsl-lx2160a.dtsi |  85 +++
>  .../arm/include/asm/arch-fsl-layerscape/cpu.h |   9 +
>  .../asm/arch-fsl-layerscape/immap_lsch3.h |  14 +-
>  configs/lx2160ardb_tfa_defconfig  |   5 +
>  drivers/pci/Kconfig   |   8 +
>  drivers/pci/Makefile  |   2 +
>  drivers/pci/pci_auto.c|  34 +
>  drivers/pci/pcie_layerscape_gen4.c| 593 ++
>  drivers/pci/pcie_layerscape_gen4.h| 273 
>  drivers/pci/pcie_layerscape_gen4_fixup.c  | 249 
>  include/configs/lx2160a_common.h  |   1 +
>  include/pci.h |   9 +
>  include/pci_ids.h |   1 +
>  15 files changed, 1295 insertions(+), 2 deletions(-)  create mode 
> 100644 drivers/pci/pcie_layerscape_gen4.c
>  create mode 100644 drivers/pci/pcie_layerscape_gen4.h
>  create mode 100644 drivers/pci/pcie_layerscape_gen4_fixup.c
> 

Sorry for my unawareness,  who is maintainer for driver/pci.

I am finding multiple names for driver pcie.
Simon Glass  (commit_signer:20/37=54%) Bin Meng 
 (commit_signer:19/37=51%,authored:11/37=30%)
Stefan Roese  (commit_signer:4/37=11%,authored:2/37=5%)
York Sun  (commit_signer:4/37=11%) Tuomas Tynkkynen 
 (commit_signer:3/37=8%,authored:3/37=8%)
Xiaowei Bao  (authored:3/37=8%) u-boot@lists.denx.de (open 
list)

considering this patch-set is touching driver/pci. I would like PCI maintainer 
to have a look.
Patch related to arch/arm/../fsl-layerscape can be reviewed by me. 

--pk



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

Re: [U-Boot] [PATCH 7/7] riscv: qemu: enable SMP

[Bin Meng]

On Tue, Feb 12, 2019 at 6:14 AM Lukas Auer
 wrote:
>
> Signed-off-by: Lukas Auer 
> ---
>
>  board/emulation/qemu-riscv/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>

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

Re: [U-Boot] [PATCH 6/7] riscv: boot images passed to bootm on all harts

[Bin Meng]

On Tue, Feb 12, 2019 at 6:14 AM Lukas Auer
 wrote:
>
> Signed-off-by: Lukas Auer 
> ---
>
>  arch/riscv/lib/bootm.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>

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

Re: [U-Boot] [U-Boot, 2/2] rockchip: Drop call to rockchip_dnl_mode_check() for now【请注意，邮件由u-boot-boun...@lists.denx.de代发】

[Andy Yan]

Hi Philipp:

    Sorry for the late reply, we just come back from the Chinese Spring 
Festival.


On 2019/2/1 下午6:26, Philipp Tomsich wrote:

Kever,

Independent of whether we revert this for the current cycle (and also 
independent of
if I ever find the other patch you had been referring to — I couldn’t 
find it in my local
mailing list archive) and then deprecate it for the next release 
(unless converted to
DM), we still have a number of architectural issues that need to be 
addressed:


I still doubt  is this a right  work-flow for patch apply. Before we  
apply  a patch  which will break many other boards , should we  make 
sure there is a solution patch applied for these boars first?




1.This really should be a driver under DTS control.
2.We need to not get away from configuring SOM-specific addresses via 
Kconfig


Both these issues are technical debt that we’ve accumulated over the 
last 18 months

and need to address for the sake of future maintainability.
E.g. ‘setting an address to 0x0 via Kconfig to disable a 
driver/feature’ really isn’t in line

with the architectural direction of U-Boot.

For technical side, I think CONFIG_ROCKCHIP_BOOT_MODE_REG is necessary 
here, we will read this register from save_boot_params when we get out 
from bootrom,  the dtb is not available at this point.


On the other hand, almost rockchip based products use a recovery key to 
enter download(upgrade)mode, this is a muti-funtion key, most of them 
reuse with vol+- key,  we would like the u-boot share


dtb with linux kernel. To keep the linux kernel dts as clean as possible 
,we don't want to add another dts property to describe this key either. 
This is why I implement function rockchip_dnl_key_pressed as __weak.



I don’t have my own house completely in order (I’ve been talking for a 
year now about
finally wrapping the RGMII/GMII selection into an ioctl-call to a 
driver) yet, but that doesn’t

mean that we we should delay this clean-up more than absolutely necessary.

Thanks,
Philipp.

On 01.02.2019, at 10:34, Philipp Tomsich 
> wrote:




On 01.02.2019, at 10:32, Kever Yang > wrote:


Hi Philipp,

   This is not right,  this patch should not merged like this!!!

   I have give my review comment in previous mail, and this will break
many boards.

   My another patch do not break anything, but you insist NAK it
without acceptable reason;


What other patch?
I don’t remember seeing that one...


   This patch definitely break other board and I have comment it, but
you just ignore other people's review and merge it, good job!

Thanks,
- Kever
On 02/01/2019 05:12 AM, Philipp Tomsich wrote:

This function causes a 5-second delay and stops the display working on
minnie. This code should be in a driver and should only be enabled by
a device-tree property, so that it does not affect devices which 
do not

have this feature.

Signed-off-by: Simon Glass >
Reviewed-by: Philipp Tomsich 
>

---

arch/arm/mach-rockchip/boot_mode.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)


Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de 
https://lists.denx.de/listinfo/u-boot






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



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

Re: [U-Boot] [PATCH 4/7] riscv: delay initialization of caches and debug UART

[Bin Meng]

On Tue, Feb 12, 2019 at 6:14 AM Lukas Auer
 wrote:
>
> Move the initialization of the caches and the debug UART until after
> board_init_f_init_reserve. This is in preparation for SMP support, where
> code prior to this point will be executed by all harts. This ensures
> that initialization will only be performed once for the main hart
> running U-Boot.
>
> Signed-off-by: Lukas Auer 
> ---
>
>  arch/riscv/cpu/start.S | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>

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

Re: [U-Boot] [PATCH 3/7] riscv: implement IPI platform functions using SBI

[Bin Meng]

On Tue, Feb 12, 2019 at 6:14 AM Lukas Auer
 wrote:
>
> The supervisor binary interface (SBI) provides the necessary functions
> to implement the platform IPI functions riscv_send_ipi() and
> riscv_clear_ipi(). Use it to implement them.
>
> This adds support for inter-processor interrupts (IPIs) on RISC-V CPUs
> running in supervisor mode. Support for machine mode is already
> available for CPUs that include the SiFive CLINT.
>
> Signed-off-by: Lukas Auer 
> ---
>
>  arch/riscv/Kconfig   |  5 +
>  arch/riscv/lib/Makefile  |  1 +
>  arch/riscv/lib/sbi_ipi.c | 25 +
>  3 files changed, 31 insertions(+)
>  create mode 100644 arch/riscv/lib/sbi_ipi.c
>

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

Re: [U-Boot] [PATCH 2/7] riscv: import the supervisor binary interface header file

[Bin Meng]

On Tue, Feb 12, 2019 at 6:14 AM Lukas Auer
 wrote:
>
> Import the supervisor binary interface (SBI) header file from Linux
> (arch/riscv/include/asm/sbi.h). The last change to it was in commit
> 6d60b6ee0c97 ("RISC-V: Device, timer, IRQs, and the SBI").
>
> Signed-off-by: Lukas Auer 
> ---
>
>  arch/riscv/include/asm/sbi.h | 94 
>  1 file changed, 94 insertions(+)
>  create mode 100644 arch/riscv/include/asm/sbi.h
>

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

Re: [U-Boot] [PATCH 1/7] riscv: add infrastructure for calling functions on other harts

[Bin Meng]

Hi Lukas,

On Tue, Feb 12, 2019 at 6:14 AM Lukas Auer
 wrote:
>
> Harts on RISC-V boot independently and U-Boot is responsible for
> managing them. Functions are called on other harts with
> smp_call_function(), which sends inter-processor interrupts (IPIs) to
> all other harts. Functions are specified with their address and two
> function arguments (argument 2 and 3). The first function argument is
> always the hart ID of the hart calling the function. On the other harts,
> the IPI interrupt handler handle_ipi() must be called on software
> interrupts to handle the request and call the specified function.
>
> Functions are stored in the ipi_data data structure. Every hart has its
> own data structure in global data. While this is not required at the
> moment (all harts are expected to boot Linux), this does allow future
> expansion, where other harts may be used for monitoring or other tasks.
>
> Signed-off-by: Lukas Auer 
> ---
>
>  arch/riscv/Kconfig   |  19 +
>  arch/riscv/include/asm/global_data.h |   5 ++
>  arch/riscv/include/asm/smp.h |  53 +
>  arch/riscv/lib/Makefile  |   1 +
>  arch/riscv/lib/smp.c | 110 +++
>  5 files changed, 188 insertions(+)
>  create mode 100644 arch/riscv/include/asm/smp.h
>  create mode 100644 arch/riscv/lib/smp.c
>

Looks pretty clean to me. Thanks! Some nits below.

> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index c45e4d73a8..c0842178dd 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -116,4 +116,23 @@ config RISCV_RDTIME
>  config SYS_MALLOC_F_LEN
> default 0x1000
>
> +config SMP
> +   bool "Symmetric Multi-Processing"
> +   help
> + This enables support for systems with more than one CPU. If
> + you say N here, U-Boot will run on single and multiprocessor
> + machines, but will use only one CPU of a multiprocessor
> + machine. If you say Y here, U-Boot will run on many, but not
> + all, single processor machines.

U-Boot will run on both single and multiprocessor machines?

> +
> +config NR_CPUS
> +   int "Maximum number of CPUs (2-32)"
> +   range 2 32
> +   depends on SMP
> +   default "8"

no quotation mark?

> +   help
> + On multiprocessor machines, U-Boot sets up a stack for each CPU.
> + Stack memory is pre-allocated. U-Boot must therefore know the
> + maximum number of CPUs that may be present.
> +
>  endmenu
> diff --git a/arch/riscv/include/asm/global_data.h 
> b/arch/riscv/include/asm/global_data.h
> index a3a342c6e1..23a5f35af5 100644
> --- a/arch/riscv/include/asm/global_data.h
> +++ b/arch/riscv/include/asm/global_data.h
> @@ -10,12 +10,17 @@
>  #ifndef__ASM_GBL_DATA_H
>  #define __ASM_GBL_DATA_H
>
> +#include 
> +
>  /* Architecture-specific global data */
>  struct arch_global_data {
> long boot_hart; /* boot hart id */
>  #ifdef CONFIG_SIFIVE_CLINT
> void __iomem *clint;/* clint base address */
>  #endif
> +#ifdef CONFIG_SMP
> +   struct ipi_data ipi[CONFIG_NR_CPUS];
> +#endif
>  };
>
>  #include 
> diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
> new file mode 100644
> index 00..bc863fdbaf
> --- /dev/null
> +++ b/arch/riscv/include/asm/smp.h
> @@ -0,0 +1,53 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2019 Fraunhofer AISEC,
> + * Lukas Auer 
> + */
> +
> +#ifndef _ASM_RISCV_SMP_H
> +#define _ASM_RISCV_SMP_H
> +
> +/**
> + * struct ipi_data - Inter-processor interrupt (IPI) data structure
> + *
> + * IPIs are used for SMP support to communicate to other harts what function 
> to
> + * call. Functions are in the form
> + * void (*addr)(ulong hart, ulong arg0, ulong arg1).
> + *
> + * The function address and the two arguments, arg0 and arg1, are stored in 
> the
> + * IPI data structure. The hart ID is inserted by the hart handling the IPI 
> and
> + * calling the function.
> + *
> + * @addr: Address of function
> + * @arg0: First argument of function
> + * @arg1: Second argument of function
> + */
> +struct ipi_data {
> +   ulong addr;
> +   ulong arg0;
> +   ulong arg1;
> +};
> +
> +/**
> + * handle_ipi() - interrupt handler for software interrupts
> + *
> + * The IPI interrupt handler must be called to handle software interrupts. It
> + * calls the function specified in the hart's IPI data structure.
> + *
> + * @hart: Hart ID of the current hart
> + */
> +void handle_ipi(ulong hart);
> +
> +/**
> + * smp_call_function() - Call a function on all other harts
> + *
> + * Send IPIs with the specified function call to all harts.
> + *
> + * @addr: Address of function
> + * @arg0: First argument of function
> + * @arg1: Second argument of function
> + * @return 0 if OK, -ve on error
> + */
> +int smp_call_function(ulong addr, ulong arg0, ulong arg1);
> +
> +#endif
> diff --git a/arch/riscv/lib/Makefile 

Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support

[Anup Patel]

On Mon, Feb 11, 2019 at 9:07 PM Andreas Schwab  wrote:
>
> On Feb 11 2019, Anup Patel  wrote:
>
> > This patchset adds SiFive Freedom Unleashed (FU540) support
> > to RISC-V U-Boot.
> >
> > The patches are based upon latest U-Boot source tree
> > (git://git.denx.de/u-boot.git) at commit id
> > dbe70c7d4e3d5c705a98d82952e05a591efd0683
> >
> > All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> > MACB Ethernet work fine on actual SiFive Unleashed board and
> > QEMU sifive_u machine.
>
> Looks like the MACB driver cannot find the correct MAC address.  That
> makes it rather awkward for network boot.
>
> Warning: ethernet@1009 (eth0) using random MAC address - 0e:14:15:06:ae:e4

This is because we don't have place to put U-Boot environment
variables as of now on Unleashed board. This will be solved once
we have SPI driver and SPI_MMC driver for Unleased board.

In future, we will be saving "ethaddr" environment variable on
SPI_MMC so U-Boot will pick MAC address at boot-time from
SPI_MMC. Once this is achieved, the above warning will go away.

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

Re: [U-Boot] [PATCH 7/7] riscv: qemu: enable SMP

[Anup Patel]

> -Original Message-
> From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> Sent: Tuesday, February 12, 2019 3:44 AM
> To: u-boot@lists.denx.de
> Cc: Atish Patra ; Anup Patel
> ; Bin Meng ; Andreas
> Schwab ; Palmer Dabbelt ;
> Alexander Graf ; Lukas Auer
> 
> Subject: [PATCH 7/7] riscv: qemu: enable SMP
> 
> Signed-off-by: Lukas Auer 
> ---
> 
>  board/emulation/qemu-riscv/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-
> riscv/Kconfig
> index 0d865acf10..b3300c64a8 100644
> --- a/board/emulation/qemu-riscv/Kconfig
> +++ b/board/emulation/qemu-riscv/Kconfig
> @@ -34,5 +34,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
>   imply BOARD_LATE_INIT
>   imply OF_BOARD_SETUP
>   imply SIFIVE_SERIAL
> + imply SMP
> 
>  endif
> --
> 2.20.1

Looks good to me.

Reviewed-by: Anup Patel 

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

Re: [U-Boot] [PATCH 6/7] riscv: boot images passed to bootm on all harts

[Anup Patel]

> -Original Message-
> From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> Sent: Tuesday, February 12, 2019 3:44 AM
> To: u-boot@lists.denx.de
> Cc: Atish Patra ; Anup Patel
> ; Bin Meng ; Andreas
> Schwab ; Palmer Dabbelt ;
> Alexander Graf ; Lukas Auer
> ; Anup Patel ; Rick
> Chen ; Simon Glass 
> Subject: [PATCH 6/7] riscv: boot images passed to bootm on all harts
> 
> Signed-off-by: Lukas Auer 
> ---
> 
>  arch/riscv/lib/bootm.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c index
> f36b8702ef..efbd3e23e7 100644
> --- a/arch/riscv/lib/bootm.c
> +++ b/arch/riscv/lib/bootm.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -81,6 +82,9 @@ static void boot_jump_linux(bootm_headers_t
> *images, int flag)  {
>   void (*kernel)(ulong hart, void *dtb);
>   int fake = (flag & BOOTM_STATE_OS_FAKE_GO);
> +#ifdef CONFIG_SMP
> + int ret;
> +#endif
> 
>   kernel = (void (*)(ulong, void *))images->ep;
> 
> @@ -92,8 +96,15 @@ static void boot_jump_linux(bootm_headers_t
> *images, int flag)
>   announce_and_cleanup(fake);
> 
>   if (!fake) {
> - if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len)
> + if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len) { #ifdef
> CONFIG_SMP
> + ret = smp_call_function(images->ep,
> + (ulong)images->ft_addr, 0);
> + if (ret)
> + hang();
> +#endif
>   kernel(gd->arch.boot_hart, images->ft_addr);
> + }
>   }
>  }
> 
> --
> 2.20.1

Looks good to me.

Reviewed-by: Anup Patel 

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

Re: [U-Boot] [PATCH 3/7] riscv: implement IPI platform functions using SBI

[Anup Patel]

> -Original Message-
> From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> Sent: Tuesday, February 12, 2019 3:44 AM
> To: u-boot@lists.denx.de
> Cc: Atish Patra ; Anup Patel
> ; Bin Meng ; Andreas
> Schwab ; Palmer Dabbelt ;
> Alexander Graf ; Lukas Auer
> ; Anup Patel ; Rick
> Chen 
> Subject: [PATCH 3/7] riscv: implement IPI platform functions using SBI
> 
> The supervisor binary interface (SBI) provides the necessary functions to
> implement the platform IPI functions riscv_send_ipi() and riscv_clear_ipi().
> Use it to implement them.
> 
> This adds support for inter-processor interrupts (IPIs) on RISC-V CPUs
> running in supervisor mode. Support for machine mode is already available
> for CPUs that include the SiFive CLINT.
> 
> Signed-off-by: Lukas Auer 
> ---
> 
>  arch/riscv/Kconfig   |  5 +
>  arch/riscv/lib/Makefile  |  1 +
>  arch/riscv/lib/sbi_ipi.c | 25 +
>  3 files changed, 31 insertions(+)
>  create mode 100644 arch/riscv/lib/sbi_ipi.c
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
> c0842178dd..3a51339c4d 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -135,4 +135,9 @@ config NR_CPUS
> Stack memory is pre-allocated. U-Boot must therefore know the
> maximum number of CPUs that may be present.
> 
> +config SBI_IPI
> + bool
> + default y if RISCV_SMODE
> + depends on SMP
> +
>  endmenu
> diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index
> 19370f9749..35dbf643e4 100644
> --- a/arch/riscv/lib/Makefile
> +++ b/arch/riscv/lib/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_RISCV_RDTIME) += rdtime.o
>  obj-$(CONFIG_SIFIVE_CLINT) += sifive_clint.o
>  obj-y+= interrupts.o
>  obj-y+= reset.o
> +obj-$(CONFIG_SBI_IPI) += sbi_ipi.o
>  obj-y   += setjmp.o
>  obj-$(CONFIG_SMP) += smp.o
> 
> diff --git a/arch/riscv/lib/sbi_ipi.c b/arch/riscv/lib/sbi_ipi.c new file mode
> 100644 index 00..170346da68
> --- /dev/null
> +++ b/arch/riscv/lib/sbi_ipi.c
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Fraunhofer AISEC,
> + * Lukas Auer   */
> +
> +#include 
> +#include 
> +
> +int riscv_send_ipi(int hart)
> +{
> + ulong mask;
> +
> + mask = 1UL << hart;
> + sbi_send_ipi();
> +
> + return 0;
> +}
> +
> +int riscv_clear_ipi(int hart)
> +{
> + sbi_clear_ipi();
> +
> + return 0;
> +}
> --
> 2.20.1

Looks good to me.

Reviewed-by: Anup Patel 

Regards,
Anup

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

Re: [U-Boot] [PATCH 4/7] riscv: delay initialization of caches and debug UART

[Anup Patel]

> -Original Message-
> From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> Sent: Tuesday, February 12, 2019 3:44 AM
> To: u-boot@lists.denx.de
> Cc: Atish Patra ; Anup Patel
> ; Bin Meng ; Andreas
> Schwab ; Palmer Dabbelt ;
> Alexander Graf ; Lukas Auer
> ; Rick Chen ; Anup
> Patel 
> Subject: [PATCH 4/7] riscv: delay initialization of caches and debug UART
> 
> Move the initialization of the caches and the debug UART until after
> board_init_f_init_reserve. This is in preparation for SMP support, where
> code prior to this point will be executed by all harts. This ensures that
> initialization will only be performed once for the main hart running U-Boot.
> 
> Signed-off-by: Lukas Auer 
> ---
> 
>  arch/riscv/cpu/start.S | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> 81ea52b170..a30f6f7194 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -45,10 +45,6 @@ _start:
>   /* mask all interrupts */
>   csrwMODE_PREFIX(ie), zero
> 
> - /* Enable cache */
> - jal icache_enable
> - jal dcache_enable
> -
>  /*
>   * Set stackpointer in internal/ex RAM to call board_init_f
>   */
> @@ -57,10 +53,6 @@ call_board_init_f:
>   li  t1, CONFIG_SYS_INIT_SP_ADDR
>   and sp, t1, t0  /* force 16 byte alignment */
> 
> -#ifdef CONFIG_DEBUG_UART
> - jal debug_uart_init
> -#endif
> -
>  call_board_init_f_0:
>   mv  a0, sp
>   jal board_init_f_alloc_reserve
> @@ -74,6 +66,14 @@ call_board_init_f_0:
>   /* save the boot hart id to global_data */
>   SREGs0, GD_BOOT_HART(gp)
> 
> + /* Enable cache */
> + jal icache_enable
> + jal dcache_enable
> +
> +#ifdef CONFIG_DEBUG_UART
> + jal debug_uart_init
> +#endif
> +
>   mv  a0, zero/* a0 <-- boot_flags = 0 */
>   la  t5, board_init_f
>   jr  t5  /* jump to board_init_f() */
> --
> 2.20.1

Looks good to me.

Reviewed-by: Anup Patel 

Regards,
Anup

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

Re: [U-Boot] [PATCH 2/7] riscv: import the supervisor binary interface header file

[Anup Patel]

> -Original Message-
> From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> Sent: Tuesday, February 12, 2019 3:44 AM
> To: u-boot@lists.denx.de
> Cc: Atish Patra ; Anup Patel
> ; Bin Meng ; Andreas
> Schwab ; Palmer Dabbelt ;
> Alexander Graf ; Lukas Auer
> ; Rick Chen 
> Subject: [PATCH 2/7] riscv: import the supervisor binary interface header file
> 
> Import the supervisor binary interface (SBI) header file from Linux
> (arch/riscv/include/asm/sbi.h). The last change to it was in commit
> 6d60b6ee0c97 ("RISC-V: Device, timer, IRQs, and the SBI").
> 
> Signed-off-by: Lukas Auer 
> ---
> 
>  arch/riscv/include/asm/sbi.h | 94
> 
>  1 file changed, 94 insertions(+)
>  create mode 100644 arch/riscv/include/asm/sbi.h
> 
> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h new
> file mode 100644 index 00..ced57defdd
> --- /dev/null
> +++ b/arch/riscv/include/asm/sbi.h
> @@ -0,0 +1,94 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2015 Regents of the University of California
> + *
> + * Taken from Linux arch/riscv/include/asm/sbi.h  */
> +
> +#ifndef _ASM_RISCV_SBI_H
> +#define _ASM_RISCV_SBI_H
> +
> +#include 
> +
> +#define SBI_SET_TIMER 0
> +#define SBI_CONSOLE_PUTCHAR 1
> +#define SBI_CONSOLE_GETCHAR 2
> +#define SBI_CLEAR_IPI 3
> +#define SBI_SEND_IPI 4
> +#define SBI_REMOTE_FENCE_I 5
> +#define SBI_REMOTE_SFENCE_VMA 6
> +#define SBI_REMOTE_SFENCE_VMA_ASID 7
> +#define SBI_SHUTDOWN 8
> +
> +#define SBI_CALL(which, arg0, arg1, arg2) ({ \
> + register uintptr_t a0 asm ("a0") = (uintptr_t)(arg0);   \
> + register uintptr_t a1 asm ("a1") = (uintptr_t)(arg1);   \
> + register uintptr_t a2 asm ("a2") = (uintptr_t)(arg2);   \
> + register uintptr_t a7 asm ("a7") = (uintptr_t)(which);  \
> + asm volatile ("ecall"   \
> +   : "+r" (a0)   \
> +   : "r" (a1), "r" (a2), "r" (a7)\
> +   : "memory");  \
> + a0; \
> +})
> +
> +/* Lazy implementations until SBI is finalized */ #define
> +SBI_CALL_0(which) SBI_CALL(which, 0, 0, 0) #define SBI_CALL_1(which,
> +arg0) SBI_CALL(which, arg0, 0, 0) #define SBI_CALL_2(which, arg0, arg1)
> +SBI_CALL(which, arg0, arg1, 0)
> +
> +static inline void sbi_console_putchar(int ch) {
> + SBI_CALL_1(SBI_CONSOLE_PUTCHAR, ch);
> +}
> +
> +static inline int sbi_console_getchar(void) {
> + return SBI_CALL_0(SBI_CONSOLE_GETCHAR); }
> +
> +static inline void sbi_set_timer(uint64_t stime_value) { #if
> +__riscv_xlen == 32
> + SBI_CALL_2(SBI_SET_TIMER, stime_value, stime_value >> 32); #else
> + SBI_CALL_1(SBI_SET_TIMER, stime_value); #endif }
> +
> +static inline void sbi_shutdown(void)
> +{
> + SBI_CALL_0(SBI_SHUTDOWN);
> +}
> +
> +static inline void sbi_clear_ipi(void)
> +{
> + SBI_CALL_0(SBI_CLEAR_IPI);
> +}
> +
> +static inline void sbi_send_ipi(const unsigned long *hart_mask) {
> + SBI_CALL_1(SBI_SEND_IPI, hart_mask);
> +}
> +
> +static inline void sbi_remote_fence_i(const unsigned long *hart_mask) {
> + SBI_CALL_1(SBI_REMOTE_FENCE_I, hart_mask); }
> +
> +static inline void sbi_remote_sfence_vma(const unsigned long *hart_mask,
> +  unsigned long start,
> +  unsigned long size)
> +{
> + SBI_CALL_1(SBI_REMOTE_SFENCE_VMA, hart_mask); }
> +
> +static inline void sbi_remote_sfence_vma_asid(const unsigned long
> *hart_mask,
> +   unsigned long start,
> +   unsigned long size,
> +   unsigned long asid)
> +{
> + SBI_CALL_1(SBI_REMOTE_SFENCE_VMA_ASID, hart_mask); }
> +
> +#endif
> --
> 2.20.1

Looks good to me.

Reviewed-by: Anup Patel 

Regards,
Anup

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

Re: [U-Boot] [PATCH 5/7] riscv: add support for multi-hart systems

[Anup Patel]

> -Original Message-
> From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> Sent: Tuesday, February 12, 2019 3:44 AM
> To: u-boot@lists.denx.de
> Cc: Atish Patra ; Anup Patel
> ; Bin Meng ; Andreas
> Schwab ; Palmer Dabbelt ;
> Alexander Graf ; Lukas Auer
> ; Anup Patel ; Rick
> Chen ; Baruch Siach ; Stefan
> Roese 
> Subject: [PATCH 5/7] riscv: add support for multi-hart systems
> 
> On RISC-V, all harts boot independently. To be able to run on a multi-hart
> system, U-Boot must be extended with the functionality to manage all harts
> in the system. A new config option, CONFIG_MAIN_HART, is used to select
> the hart U-Boot runs on. All other harts are halted.
> U-Boot can delegate functions to them using smp_call_function().
> 
> Every hart has a valid pointer to the global data structure and a 8KiB stack 
> by
> default. The stack size is set with CONFIG_STACK_SIZE_SHIFT.
> 
> Signed-off-by: Lukas Auer 
> ---
> 
>  arch/riscv/Kconfig   |  12 +
>  arch/riscv/cpu/start.S   | 102 ++-
>  arch/riscv/include/asm/csr.h |   1 +
>  3 files changed, 114 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
> 3a51339c4d..af8d0f8d67 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -140,4 +140,16 @@ config SBI_IPI
>   default y if RISCV_SMODE
>   depends on SMP
> 
> +config MAIN_HART
> + int "Main hart in system"
> + default 0
> + help
> +   Some SoCs include harts of various sizes, some of which might not
> +   be suitable for running U-Boot. CONFIG_MAIN_HART is used to
> select
> +   the hart U-Boot runs on.

This config option can be avoided altogether if we have
lottery based system to select "Main HART" in start.S.

With the MAIN_HART config option in-place, every system
will have to pick a "Main HART". What if the "Main HART"
itself does not come online due to HW failure.

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

Re: [U-Boot] [PATCH 1/7] riscv: add infrastructure for calling functions on other harts

[Anup Patel]

> -Original Message-
> From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> Sent: Tuesday, February 12, 2019 3:44 AM
> To: u-boot@lists.denx.de
> Cc: Atish Patra ; Anup Patel
> ; Bin Meng ; Andreas
> Schwab ; Palmer Dabbelt ;
> Alexander Graf ; Lukas Auer
> ; Anup Patel ; Rick
> Chen 
> Subject: [PATCH 1/7] riscv: add infrastructure for calling functions on other
> harts
> 
> Harts on RISC-V boot independently and U-Boot is responsible for managing
> them. Functions are called on other harts with smp_call_function(), which
> sends inter-processor interrupts (IPIs) to all other harts. Functions are
> specified with their address and two function arguments (argument 2 and 3).
> The first function argument is always the hart ID of the hart calling the
> function. On the other harts, the IPI interrupt handler handle_ipi() must be
> called on software interrupts to handle the request and call the specified
> function.
> 
> Functions are stored in the ipi_data data structure. Every hart has its own
> data structure in global data. While this is not required at the moment (all
> harts are expected to boot Linux), this does allow future expansion, where
> other harts may be used for monitoring or other tasks.
> 
> Signed-off-by: Lukas Auer 
> ---
> 
>  arch/riscv/Kconfig   |  19 +
>  arch/riscv/include/asm/global_data.h |   5 ++
>  arch/riscv/include/asm/smp.h |  53 +
>  arch/riscv/lib/Makefile  |   1 +
>  arch/riscv/lib/smp.c | 110 +++
>  5 files changed, 188 insertions(+)
>  create mode 100644 arch/riscv/include/asm/smp.h  create mode 100644
> arch/riscv/lib/smp.c
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
> c45e4d73a8..c0842178dd 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -116,4 +116,23 @@ config RISCV_RDTIME  config SYS_MALLOC_F_LEN
>   default 0x1000
> 
> +config SMP
> + bool "Symmetric Multi-Processing"
> + help
> +   This enables support for systems with more than one CPU. If
> +   you say N here, U-Boot will run on single and multiprocessor
> +   machines, but will use only one CPU of a multiprocessor
> +   machine. If you say Y here, U-Boot will run on many, but not
> +   all, single processor machines.
> +
> +config NR_CPUS
> + int "Maximum number of CPUs (2-32)"
> + range 2 32
> + depends on SMP
> + default "8"
> + help
> +   On multiprocessor machines, U-Boot sets up a stack for each CPU.
> +   Stack memory is pre-allocated. U-Boot must therefore know the
> +   maximum number of CPUs that may be present.
> +
>  endmenu
> diff --git a/arch/riscv/include/asm/global_data.h
> b/arch/riscv/include/asm/global_data.h
> index a3a342c6e1..23a5f35af5 100644
> --- a/arch/riscv/include/asm/global_data.h
> +++ b/arch/riscv/include/asm/global_data.h
> @@ -10,12 +10,17 @@
>  #ifndef  __ASM_GBL_DATA_H
>  #define __ASM_GBL_DATA_H
> 
> +#include 
> +
>  /* Architecture-specific global data */  struct arch_global_data {
>   long boot_hart; /* boot hart id */
>  #ifdef CONFIG_SIFIVE_CLINT
>   void __iomem *clint;/* clint base address */
>  #endif
> +#ifdef CONFIG_SMP
> + struct ipi_data ipi[CONFIG_NR_CPUS];
> +#endif
>  };
> 
>  #include 
> diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
> new file mode 100644 index 00..bc863fdbaf
> --- /dev/null
> +++ b/arch/riscv/include/asm/smp.h
> @@ -0,0 +1,53 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2019 Fraunhofer AISEC,
> + * Lukas Auer   */
> +
> +#ifndef _ASM_RISCV_SMP_H
> +#define _ASM_RISCV_SMP_H
> +
> +/**
> + * struct ipi_data - Inter-processor interrupt (IPI) data structure
> + *
> + * IPIs are used for SMP support to communicate to other harts what
> +function to
> + * call. Functions are in the form
> + * void (*addr)(ulong hart, ulong arg0, ulong arg1).
> + *
> + * The function address and the two arguments, arg0 and arg1, are
> +stored in the
> + * IPI data structure. The hart ID is inserted by the hart handling the
> +IPI and
> + * calling the function.
> + *
> + * @addr: Address of function
> + * @arg0: First argument of function
> + * @arg1: Second argument of function
> + */
> +struct ipi_data {
> + ulong addr;
> + ulong arg0;
> + ulong arg1;
> +};
> +
> +/**
> + * handle_ipi() - interrupt handler for software interrupts
> + *
> + * The IPI interrupt handler must be called to handle software
> +interrupts. It
> + * calls the function specified in the hart's IPI data structure.
> + *
> + * @hart: Hart ID of the current hart
> + */
> +void handle_ipi(ulong hart);
> +
> +/**
> + * smp_call_function() - Call a function on all other harts
> + *
> + * Send IPIs with the specified function call to all harts.
> + *
> + * @addr: Address of function
> + * @arg0: First argument of function
> + * @arg1: Second argument of function
> + * @return 0 if OK, -ve on 

Re: [U-Boot] [U-Boot, v3, 1/5] efi_loader: Initial HII database protocols

[AKASHI Takahiro]

Alex, Heinrich,

On Mon, Feb 11, 2019 at 03:28:58PM +0100, Alexander Graf wrote:
> On 02/09/2019 05:19 PM, Heinrich Schuchardt wrote:
> >On 1/23/19 2:01 PM, Alexander Graf wrote:
> >>>From: Leif Lindholm 
> >>>
> >>>This patch provides enough implementation of the following protocols to
> >>>run EDKII's Shell.efi and UEFI SCT:
> >>>
> >>>   * EfiHiiDatabaseProtocol
> >>>   * EfiHiiStringProtocol
> >>>
> >>>Not implemented are:
> >>>   * ExportPackageLists()
> >>>   * RegisterPackageNotify()/UnregisterPackageNotify()
> >>>   * SetKeyboardLayout() (i.e. *current* keyboard layout)
> >>>
> >>>HII database protocol in this patch series can handle only:
> >>>   * GUID package
> >>>   * string package
> >>>   * keyboard layout package
> >>>   (The other packages, except Device path package, will be necessary
> >>>for interactive and graphical UI.)
> >>>
> >>>Cc: Leif Lindholm 
> >>>Signed-off-by: Rob Clark 
> >>>Signed-off-by: AKASHI Takahiro 
> >>Thanks, applied to efi-next
> >>
> >>Alex
> >>
> >>
> >I have rebased the efi-next tree upon U-Boot master. My Odroid C2
> >crashes when booting via U-Boot -> iPXE -> GRUB -> Linux. Bisection
> >points to this patch. The HII protocols are referenced by iPXE if available.
> >
> >An interesting comment in
> >https://www.spinics.net/lists/arm-kernel/msg704238.html for a similar
> >U-Boot related error is:
> >
> >"Looks like you're taking the SError as soon as we unmask them, so it
> >could've been pending for ages. It would be interesting to see if it's
> >actually caused by the kernel, or if the firmware triggers it beforehand."
> >
> >Booting via iPXE is described in doc/README.iscsi
> >
> >This patch and some follow up patches are included in the pull request
> >for the EFI tree.
> >
> >I would prefer if we could remove the HII protocols from the pull
> >request until the patches are thoroughly tested.
> 
> I've posted a patch to remove only the protocol exposure. That way we can
> leave most bits in.
> 
> The #SError sounds like something is trying to write to a memory location
> that is not backed by a device. That is usually an indicator for a NULL
> dereference. Maybe by looking at the respective iPXE code, you will be able
> to find the spot that does the invalid access?

Taking a quick look at iPXE code (src/interface/efi/*),
it uses
 * HII_PACKAGE_FORMS
 * HII_PACKAGE_STRINGS
 * HII_CONFIG_ROUTING_PROTOCOL
 * HII_CONFIG_ACCESS_PROTOCOL
but my current patch doesn't support neither PACKAGE_FORMS nor
CONFIG_*_PROTOCOL. One of those might be a root cause.
(I don't know when and how SError was triggered though.)

-Takahiro Akashi



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

Re: [U-Boot] [REGRESSION] tegra124: nyan-big: LPAE not working

[Marcel Ziswiler]

Hi there

On Mon, 2019-02-11 at 15:13 -0700, Stephen Warren wrote:
> On 2/11/19 3:48 AM, Thierry Reding wrote:
> > On Mon, Feb 11, 2019 at 10:04:37AM +, Tristan Bastian wrote:
> > > 
> > > 
> > > Thierry Reding – Mon, 11. February 2019 10:38
> > > > On Mon, Feb 11, 2019 at 09:20:33AM +, Tristan Bastian
> > > > wrote:
> > > > > Thierry Reding – Mon, 11. February 2019 9:52
> > > > > > On Sun, Feb 10, 2019 at 08:53:11PM +0100, Tristan Bastian
> > > > > > wrote:
> > > > > > > Thierry, do you have any news on this?
> > > > > > > 
> > > > > > > I don't think, that google is going to push an updated
> > > > > > > version of
> > > > coreboot
> > > > > > > to each nyan-big device..
> > > > > > > So reverting this patch at least for the nyan devices
> > > > > > > would be the best
> > > > I
> > > > > > > think..
> > > > > > 
> > > > > > Yes, I agree. I had a brief chat with Rob Herring about
> > > > > > this and he too
> > > > > > agrees that we should revert it for now. I'll make it a
> > > > > > manual revert
> > > > > > and add a comment to the device tree node that will
> > > > > > hopefully avoid any
> > > > > > future janitorial "cleanups" of this sort.
> > > > > 
> > > > > great news! :)
> > > > > 
> > > > > > > BTW: I'm now running u-boot natively and it seems like u-
> > > > > > > boot always has
> > > > a
> > > > > > > problem with the memory..
> > > > > > > If u-boot is used chainloaded to coreboot it is only
> > > > > > > getting 2GB of
> > > > memory
> > > > > > > and running u-boot natively also just gives me 2GB..
> > > > > > > I've tested that with a kernel with "ARM: tegra: Fix
> > > > > > > unit_address_vs_reg
> > > > DTC
> > > > > > > warnings for /memory" reverted and also on a kernel,
> > > > > > > before this patch
> > > > was
> > > > > > > applied..
> > > > > > 
> > > > > > It's possible that U-Boot doesn't support LPAE and
> > > > > > therefore may not be
> > > > > > able to use more than the 2 GiB of memory.
> > > > > 
> > > > > So I at least enabled LPAE in u-boot with
> > > > > "CONFIG_ARMV7_LPAE=y" and
> > > > > this was for some reason also needed to get some output on
> > > > > the
> > > > > display..
> > > > > I'm not sure why LPAE needs to activated in u-boot for
> > > > > display output
> > > > > on the nyan-big..
> > > > > Without LPAE enabled u-boot was still working, and booted
> > > > > linux, but
> > > > > u-boot didn't display anything on screen, linux then did..
> > > > 
> > > > Yeah, that's surprising. Perhaps without LPAE U-Boot thinks
> > > > there's not
> > > > enough memory for the framebuffer? There should be plenty, so
> > > > maybe
> > > > there is something else going on here.
> > > > 
> > > > > > However, U-Boot should be
> > > > > > able to tell the kernel exactly how much memory the system
> > > > > > has and pass
> > > > > > that on via device tree. That still does work, right?
> > > > > 
> > > > > It seems like this is not working..
> > > > > And this seems to be the case with both, u-boot chainloaded
> > > > > and
> > > > > running u-boot natively..
> > > > > 
> > > > > I've used these scripts for flashing:
> > > > > github.com/NVIDIA/tegra-uboot-flasher-scripts
> > > > > And used the norrin device since it seems like it is the
> > > > > nyan-big dev
> > > > > board?
> > > > > But going with the norrin device config should not be the
> > > > > issue here
> > > > > since the problem also exists when chainloading u-boot,
> > > > > right?
> > > > 
> > > > It could be a problem. The memory bank configuration is stored
> > > > in what's
> > > > called a BCT along with a bunch of other parameters that define
> > > > what the
> > > > memory controller needs to access the given memory chips. So if
> > > > you've
> > > > flashed a BCT that's for a board with only 2 GiB of memory you
> > > > would end
> > > > up with a system that can't address any more than that. It's
> > > > somewhat
> > > > surprising that memory accesses work at all with a BCT that's
> > > > for
> > > > different memory chips, but sometimes you can get lucky.
> > > > 
> > > > You may want to try reflashing with the right BCT. The simplest
> > > > would
> > > > probably be to duplicate the cbootimage configuration for
> > > > Norrin and
> > > > substitute the relevant bits by what you have from the
> > > > Chromebook flash
> > > > utilities. Looks like the BCT in really the only thing you can
> > > > replace
> > > > there. Make sure to replace it with the one that matches your
> > > > Chromebook
> > > > and it should give you the right memory bank configuration.
> > > 
> > > Is there a way to check if the correct bct for my 4GB model was
> > > used?
> > > What I tried was to edit the existing bct config file of norrin
> > > from here:
> > > https://github.com/NVIDIA/cbootimage-configs/blob/master/tegra124/nvidia/norrin/PM370_Hynix_2GB_H5TC4G63AFR_PBA_924MHz_01212014.bct.cfg
> > > by replacing all entries for each memory bank with the entries
> > > from here:
> > > 

Re: [U-Boot] [PATCH v3 14/22] config: pcm052: Use SZ_X{MK} from linux/sizes.h for include/configs/pcm052.h

[Marcel Ziswiler]

On Sun, 2019-02-03 at 00:02 +0100, Lukasz Majewski wrote:
> Signed-off-by: Lukasz Majewski 

Reviewed-by: Marcel Ziswiler 

> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  include/configs/pcm052.h | 17 +
>  1 file changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/include/configs/pcm052.h b/include/configs/pcm052.h
> index c2ecb7ec18..fb8f3c8609 100644
> --- a/include/configs/pcm052.h
> +++ b/include/configs/pcm052.h
> @@ -9,6 +9,7 @@
>  #define __CONFIG_H
>  
>  #include 
> +#include 
>  
>  #define CONFIG_SKIP_LOWLEVEL_INIT
>  
> @@ -16,7 +17,7 @@
>  #define CONFIG_CMDLINE_TAG
>  
>  /* Size of malloc() pool */
> -#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + 2 *
> 1024 * 1024)
> +#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + 2 *
> SZ_1M)
>  
>  /* Allow to overwrite serial and ethaddr */
>  #define CONFIG_ENV_OVERWRITE
> @@ -27,7 +28,7 @@
>  #define CONFIG_SYS_MAX_NAND_DEVICE   1
>  /* QSPI Configs*/
>  #ifdef CONFIG_FSL_QSPI
> -#define FSL_QSPI_FLASH_SIZE  (1 << 24)
> +#define FSL_QSPI_FLASH_SIZE  (SZ_16M)
>  #define FSL_QSPI_FLASH_NUM   2
>  #define CONFIG_SYS_FSL_QSPI_LE
>  #endif
> @@ -154,7 +155,7 @@
>  
>  /* Physical memory map */
>  #define PHYS_SDRAM   (0x8000)
> -#define PHYS_SDRAM_SIZE  (CONFIG_PCM052_DDR_SIZE
> * 1024 * 1024)
> +#define PHYS_SDRAM_SIZE  (CONFIG_PCM052_DDR_SIZE
> * SZ_1M)
>  
>  #define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM
>  #define CONFIG_SYS_INIT_RAM_ADDR IRAM_BASE_ADDR
> @@ -167,17 +168,17 @@
>  
>  /* environment organization */
>  #ifdef CONFIG_ENV_IS_IN_MMC
> -#define CONFIG_ENV_SIZE  (8 * 1024)
> +#define CONFIG_ENV_SIZE  (SZ_8K)
>  
> -#define CONFIG_ENV_OFFSET(12 * 64 * 1024)
> +#define CONFIG_ENV_OFFSET(12 * SZ_64K)
>  #define CONFIG_SYS_MMC_ENV_DEV   0
>  #endif
>  
>  #ifdef CONFIG_ENV_IS_IN_NAND
> -#define CONFIG_ENV_SECT_SIZE (128 * 1024)
> -#define CONFIG_ENV_SIZE  (8 * 1024)
> +#define CONFIG_ENV_SECT_SIZE (SZ_128K)
> +#define CONFIG_ENV_SIZE  (SZ_8K)
>  #define CONFIG_ENV_OFFSET0xA
> -#define CONFIG_ENV_SIZE_REDUND   (8 * 1024)
> +#define CONFIG_ENV_SIZE_REDUND   (SZ_8K)
>  #define CONFIG_ENV_OFFSET_REDUND 0xC
>  #endif
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 09/22] ARM: DTS: vybrid: Update vf.dtsi file to descibe more vf610 hardware

[Marcel Ziswiler]

On Sun, 2019-02-03 at 00:02 +0100, Lukasz Majewski wrote:
> This patch allows moving vf610 based boards to a device tree and
> model.
> Ported from Linux kernel - v4.20 (tag)
> 
> Signed-off-by: Lukasz Majewski 
> Reviewed-by: Stefan Agner 

Tested-by: Marcel Ziswiler 

> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/dts/vf.dtsi | 62
> 
>  1 file changed, 62 insertions(+)
> 
> diff --git a/arch/arm/dts/vf.dtsi b/arch/arm/dts/vf.dtsi
> index ad30059b9a..5e3b2c5b9d 100644
> --- a/arch/arm/dts/vf.dtsi
> +++ b/arch/arm/dts/vf.dtsi
> @@ -22,6 +22,10 @@
>   spi1 = 
>   ehci0 = 
>   ehci1 = 
> + i2c0 = 
> + i2c1 = 
> + i2c2 = 
> + i2c3 = 
>   };
>  
>   soc {
> @@ -89,6 +93,22 @@
>   status = "disabled";
>   };
>  
> + i2c0: i2c@40066000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-i2c";
> + reg = <0x40066000 0x1000>;
> + status = "disabled";
> + };
> +
> + i2c1: i2c@40067000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-i2c";
> + reg = <0x40067000 0x1000>;
> + status = "disabled";
> + };
> +
>   iomuxc: iomuxc@40048000 {
>   compatible = "fsl,vf610-iomuxc";
>   reg = <0x40048000 0x1000>;
> @@ -156,6 +176,48 @@
>   reg = <0x400b4000 0x800>;
>   status = "disabled";
>   };
> +
> + esdhc1: esdhc@400b2000 {
> + compatible = "fsl,esdhc";
> + reg = <0x400b2000 0x1000>;
> + status = "disabled";
> + };
> +
> + fec0: fec@400d {
> +   compatible = "fsl,mvf600-fec";
> +   reg = <0x400d 0x1000>;
> +   status = "disabled";
> + };
> +
> + fec1: fec@400d1000 {
> +   compatible = "fsl,mvf600-fec";
> +   reg = <0x400d1000 0x1000>;
> +   status = "disabled";
> + };
> +
> + nfc: nand@400e {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-nfc";
> + reg = <0x400e 0x4000>;
> + status = "disabled";
> + };
> +
> + i2c2: i2c@400e6000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-i2c";
> + reg = <0x400e6000 0x1000>;
> + status = "disabled";
> + };
> +
> + i2c3: i2c@400e7000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-i2c";
> + reg = <0x400e7000 0x1000>;
> + status = "disabled";
> + };
>   };
>   };
>  };
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 05/22] pcm052: board: Do not enable I2C2 code in the board file

[Marcel Ziswiler]

Hi Lukasz

On Sun, 2019-02-03 at 00:02 +0100, Lukasz Majewski wrote:
> As the I2C2 clock is now enabled in the generic clock code, we can
> remove
> this code from a board file.
> 
> Signed-off-by: Lukasz Majewski 

Tested-by: Marcel Ziswiler 

> ---
> 
> Changes in v3:
> - New patch (separate board code patch)
> 
> Changes in v2: None
> 
>  board/phytec/pcm052/pcm052.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/board/phytec/pcm052/pcm052.c
> b/board/phytec/pcm052/pcm052.c
> index f988af2abc..cfc8009102 100644
> --- a/board/phytec/pcm052/pcm052.c
> +++ b/board/phytec/pcm052/pcm052.c
> @@ -485,7 +485,7 @@ static void clock_init(void)
>   clrsetbits_le32(>ccgr9, CCM_REG_CTRL_MASK,
>   CCM_CCGR9_FEC0_CTRL_MASK |
> CCM_CCGR9_FEC1_CTRL_MASK);
>   clrsetbits_le32(>ccgr10, CCM_REG_CTRL_MASK,
> - CCM_CCGR10_NFC_CTRL_MASK |
> CCM_CCGR10_I2C2_CTRL_MASK);
> + CCM_CCGR10_NFC_CTRL_MASK);
>  
>   clrsetbits_le32(>pll2_ctrl, ANADIG_PLL2_CTRL_POWERDOWN,
>   ANADIG_PLL2_CTRL_ENABLE |
> ANADIG_PLL2_CTRL_DIV_SELECT);

I can confirm that a similar change also works on Colibri VF50/VF61
albeit there on I2C0 rather than I2C2.

Cheers

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

Re: [U-Boot] [PATCH v3 04/22] vybrid: clock: Provide enable_i2c_clk() function for Vybrid

[Marcel Ziswiler]

On Sun, 2019-02-03 at 00:02 +0100, Lukasz Majewski wrote:
> Provide function to enable I2C clocks for vf610 - in the generic
> code.
> This function overrides the default weak function implementation
> (which
> only returns 1).
> 
> Signed-off-by: Lukasz Majewski 

Tested-by: Marcel Ziswiler 

> ---
> 
> Changes in v3:
> - Add code to enable I2C0 code as suggested by Stefan (so the code
> can be
>   reused by other boards without regressions)
> - Exclude the pcm052.c related code to a separate patch
> 
> Changes in v2: None
> 
>  arch/arm/cpu/armv7/vf610/generic.c  | 22 ++
>  arch/arm/include/asm/arch-vf610/clock.h |  3 +++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv7/vf610/generic.c
> b/arch/arm/cpu/armv7/vf610/generic.c
> index cbd3391918..e0c0b1bcb0 100644
> --- a/arch/arm/cpu/armv7/vf610/generic.c
> +++ b/arch/arm/cpu/armv7/vf610/generic.c
> @@ -375,3 +375,25 @@ void enable_caches(void)
>   mmu_set_region_dcache_behaviour(IRAM_BASE_ADDR, IRAM_SIZE,
> option);
>  }
>  #endif
> +
> +#ifdef CONFIG_SYS_I2C_MXC
> +/* i2c_num can be from 0 - 3 */
> +int enable_i2c_clk(unsigned char enable, unsigned int i2c_num)
> +{
> + struct ccm_reg *ccm = (struct ccm_reg *)CCM_BASE_ADDR;
> +
> + switch (i2c_num) {
> + case 0:
> + clrsetbits_le32(>ccgr4, CCM_CCGR4_I2C0_CTRL_MASK,
> + CCM_CCGR4_I2C0_CTRL_MASK);
> + case 2:
> + clrsetbits_le32(>ccgr10,
> CCM_CCGR10_I2C2_CTRL_MASK,
> + CCM_CCGR10_I2C2_CTRL_MASK);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +#endif
> diff --git a/arch/arm/include/asm/arch-vf610/clock.h
> b/arch/arm/include/asm/arch-vf610/clock.h
> index 3bd73a01f3..72184fd608 100644
> --- a/arch/arm/include/asm/arch-vf610/clock.h
> +++ b/arch/arm/include/asm/arch-vf610/clock.h
> @@ -22,6 +22,9 @@ enum mxc_clock {
>  void enable_ocotp_clk(unsigned char enable);
>  unsigned int mxc_get_clock(enum mxc_clock clk);
>  u32 get_lpuart_clk(void);
> +#ifdef CONFIG_SYS_I2C_MXC
> +int enable_i2c_clk(unsigned char enable, unsigned int i2c_num);
> +#endif
>  
>  #define imx_get_fecclk() mxc_get_clock(MXC_FEC_CLK)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 01/22] net: FEC: Add compatible for vybrid (vf610) to reuse fec_mxc.c driver

[Marcel Ziswiler]

Hi Lukasz

On Sun, 2019-02-03 at 00:02 +0100, Lukasz Majewski wrote:
> The NXP's FEC driver can be reused on vf610 device (with DM).
> 
> Signed-off-by: Lukasz Majewski 
> Reviewed-by: Stefan Agner 
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/net/fec_mxc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
> index 1a59026a62..5ff49224f4 100644
> --- a/drivers/net/fec_mxc.c
> +++ b/drivers/net/fec_mxc.c
> @@ -1486,6 +1486,7 @@ static const struct udevice_id fecmxc_ids[] = {
>   { .compatible = "fsl,imx6ul-fec" },
>   { .compatible = "fsl,imx53-fec" },
>   { .compatible = "fsl,imx7d-fec" },
> + { .compatible = "fsl,mvf600-fec" },
>   { }
>  };

For some reason while the FEC prior to DM was rock solid on Vybrid with
DM it at times only sends stuff but refuses to receive packets. Do you
recall having any such issues? Could it have to do with us using FEC1
by default rather than FEC0? But then at times it works just fine again
which is rather strange...

Cheers

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

Re: [U-Boot] [PATCH v3 03/22] vybrid: ddr: Extend vf610-pinfunc.h with DDR pads definitions

[Marcel Ziswiler]

Hi Lukasz

BTW: Thanks for this work which greatly helped us getting Colibri
VF50/VF61 up to speed concerning device tree resp. driver model
integration/migration. Hopefully, I can send that out later this week.

On Sun, 2019-02-03 at 00:02 +0100, Lukasz Majewski wrote:
> This patch provides definitions necessary for VF610 DDR pad
> configurations.
> 
> Signed-off-by: Lukasz Majewski 
> Reviewed-by: Stefan Agner 
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/dts/vf610-pinfunc.h | 50
> 
>  1 file changed, 50 insertions(+)
> 
> diff --git a/arch/arm/dts/vf610-pinfunc.h b/arch/arm/dts/vf610-
> pinfunc.h
> index fcad7132c8..24d7126756 100644
> --- a/arch/arm/dts/vf610-pinfunc.h
> +++ b/arch/arm/dts/vf610-pinfunc.h
> @@ -807,4 +807,54 @@
>  #define VF610_PAD_PTA7__GPIO_134 0x218 0x000 ALT0 0x0
>  #define VF610_PAD_PTA7__VIU_PIX_CLK  0x218 0x3AC ALT1 0x1
>  
> +#define VF610_PAD_DDR_RESETB 0x21c 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A15__DDR_A_15  0x220 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A14__DDR_A_14  0x224 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A13__DDR_A_13  0x228 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A12__DDR_A_12  0x22c 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A11__DDR_A_11  0x230 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A10__DDR_A_10  0x234 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A9__DDR_A_90x238 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A8__DDR_A_80x23c 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A7__DDR_A_70x240 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A6__DDR_A_60x244 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A5__DDR_A_50x248 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A4__DDR_A_40x24c 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A3__DDR_A_30x250 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A2__DDR_A_20x254 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A1__DDR_A_10x258 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_A0__DDR_A_00x25c 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_BA2__DDR_BA_2  0x260 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_BA1__DDR_BA_1  0x264 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_BA0__DDR_BA_0  0x268 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_CAS__DDR_CAS_B 0x26c 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_CKE__DDR_CKE_0 0x270 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_CLK__DDR_CLK_0 0x274 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_CS__DDR_CS_B_0 0x278 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D15__DDR_D_15  0x27c 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D14__DDR_D_14  0x280 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D13__DDR_D_13  0x284 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D12__DDR_D_12  0x288 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D11__DDR_D_11  0x28c 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D10__DDR_D_10  0x290 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D9__DDR_D_90x294 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D8__DDR_D_80x298 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D7__DDR_D_70x29c 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D6__DDR_D_60x2a0 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D5__DDR_D_50x2a4 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D4__DDR_D_40x2a8 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D3__DDR_D_30x2ac 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D2__DDR_D_20x2b0 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D1__DDR_D_10x2b4 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_D0__DDR_D_00x2b8 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_DQM1__DDR_DQM_10x2bc 0x000
> ALT0 0x0
> +#define VF610_PAD_DDR_DQM0__DDR_DQM_00x2c0 0x000
> ALT0 0x0
> +#define VF610_PAD_DDR_DQS1__DDR_DQS_10x2c4 0x000
> ALT0 0x0
> +#define VF610_PAD_DDR_DQS0__DDR_DQS_00x2c8 0x000
> ALT0 0x0
> +#define VF610_PAD_DDR_RAS__DDR_RAS_B 0x2cc 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_WE__DDR_WE_B   0x2d0 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_ODT1__DDR_ODT_00x2d4 0x000
> ALT0 0x0
> +#define VF610_PAD_DDR_ODT0__DDR_ODT_10x2d8 0x000
> ALT0 0x0
> +#define VF610_PAD_DDR_DDRBYTE1__DDR_DDRBYTE1 0x2dc 0x000 ALT0 0x0
> +#define VF610_PAD_DDR_DDRBYTE0__DDR_DDRBYTE0 0x2e0 0x000 ALT0 0x0

As far as I can tell from the reference manual there is no such thing
as a DDRBYTE0 but it is rather called DDRBYTE2, not?

>  #endif

Cheers

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

Re: [U-Boot] [PATCH 2/3] ARM: rmobile: Add basic PSCI support for r8a7790 SoC

[Marek Vasut]

On 2/11/19 9:10 PM, Oleksandr wrote:

[...]

>>> Yes. I had to re-implement. Let me describe why.
>>>
>>>  From my understanding (I may mistake), the PSCI backend code which
>>> lives
>>> in secure section should be as lightweight as possible
>>>
>>> and shouldn't call any U-Boot routines not marked as __secure, except
>>> simple static inline functions.
>>>
>>> You can see PSCI implementation for any platform in U-Boot,  and only
>>> simple "macroses/inlines" are used across all of them.
>>>
>>> Even for realizing some delay in code, they have specially implemented
>>> something simple. As an example __mdelay() realization here:
>>>
>>> https://elixir.bootlin.com/u-boot/v2019.01/source/arch/arm/cpu/armv7/sunxi/psci.c#L61
>>>
>> Can the U-Boot code be refactored somehow to avoid the duplication ?
> 
> Sorry, what duplication you are speaking about?

It is my impression that we're reimplementing code we already have
either in drivers/ or in Linux, again, in arch/arm/ . Isn't it the case ?

>>> I know that PMIC (for Lager) and CPLD (for Stout) assist SoC to perform
>>> reset. But, I couldn't use that functional here in PSCI backend, as it
>>> pulls a lot of code (i2c for PMIC, gpio manipulation for CPLD, etc),
>> How can the reset work properly if the CPLD/PMIC isn't even used then ?
> 
> 
> We ask WDT to perform a CPU reset, although this is not the same reset
> as an external reset from CPLD/PMIC,
> 
> but, why not use it, if we don't have alternative? This is certainly
> better than nothing, I think.

Do we need to do a full board reset in this case ?

> Actually, we ask WDT to do what it is intended to do, and it seems to
> work properly as the system up and running after WDT reset in 100% cases.
> 
> What is more, this PSCI reset implementation could be common for Gen2
> SoCs where WDT is present...
> 
> 
>>> so for that reason (AFAIK the PSCI system reset is a mandatory option) I
>>> chose WDT as a entity for doing a reset. This is quite simple and can be
>>> used on both boards, what is more that it can be used on other Gen2 SoC
>>> if required.
>>>
> +}
> +
> +/*
>
>
> + * Functions which intended to be called from PSCI board
> initialization.
> +
> */
>
>
> +static int sysc_power_up(int scu)
> +{
> +    u32 status, chan_offs, isr_bit;
> +    int i, j, ret = 0;
> +
> +    if (scu == CA15_SCU) {
> +    chan_offs = CA15_SCU_CHAN_OFFS;
> +    isr_bit = CA15_SCU_ISR_BIT;
> +    } else {
> +    chan_offs = CA7_SCU_CHAN_OFFS;
> +    isr_bit = CA7_SCU_ISR_BIT;
> +    }
> +
> +    writel(BIT(isr_bit), SYSC_BASE + SYSCISCR);
> +
> +    /* Submit power resume request until it was accepted */
> +    for (i = 0; i < PWRER_RETRIES; i++) {
> +    /* Wait until SYSC is ready to accept a power resume
> request */
> +    for (j = 0; j < SYSCSR_RETRIES; j++) {
> +    if (readl(SYSC_BASE + SYSCSR) & BIT(1))
> +    break;
> +
> +    udelay(SYSCSR_DELAY_US);
> +    }
> +
> +    if (j == SYSCSR_RETRIES)
> +    return -EAGAIN;
> +
> +    /* Submit power resume request */
> +    writel(BIT(0), SYSC_BASE + chan_offs + PWRONCR_OFFS);
> +
> +    /* Check if power resume request was accepted */
> +    status = readl(SYSC_BASE + chan_offs + PWRER_OFFS);
> +    if (!(status & BIT(0)))
> +    break;
> +
> +    udelay(PWRER_DELAY_US);
> +    }
> +
> +    if (i == PWRER_RETRIES)
> +    return -EIO;
> +
> +    /* Wait until the power resume request has completed */
> +    for (i = 0; i < SYSCISR_RETRIES; i++) {
> +    if (readl(SYSC_BASE + SYSCISR) & BIT(isr_bit))
> +    break;
> +    udelay(SYSCISR_DELAY_US);
> +    }
> +
> +    if (i == SYSCISR_RETRIES)
> +    ret = -EIO;
> +
> +    writel(BIT(isr_bit), SYSC_BASE + SYSCISCR);
> +
> +    return ret;
> +}
> +
> +static bool sysc_power_is_off(int scu)
> +{
> +    u32 status, chan_offs;
> +
> +    chan_offs = scu == CA15_SCU ? CA15_SCU_CHAN_OFFS :
> CA7_SCU_CHAN_OFFS;
> +
> +    /* Check if SCU is in power shutoff state */
> +    status = readl(SYSC_BASE + chan_offs + PWRSR_OFFS);
> +    if (status & BIT(0))
> +    return true;
> +
> +    return false;
> +}
> +
> +static void apmu_setup_debug_mode(int cpu)
> +{
> +    int cluster = r8a7790_cluster_id(cpu);
> +    u32 apmu_base, reg;
> +
> +    apmu_base = cluster == 0 ? CA15_APMU_BASE : CA7_APMU_BASE;
> +
> +    /*
> + * Enable reset requests derived from power shutoff to the
> AP-system

Re: [U-Boot] [PATCH 0/7] SMP support for RISC-V

[Auer, Lukas]

On Mon, 2019-02-11 at 23:16 +0100, Philipp Tomsich wrote:
> On 11.02.2019, at 23:13, Lukas Auer 
> wrote:
> > This patch series adds SMP support for RISC-V to U-Boot. It allows
> > U-Boot to run on multi-hart systems and will boot images passed to
> > bootm
> > on all harts. The bootm command is currently the only one that will
> > boot
> > images on all harts, bootefi is not yet supported.
> 
> You might want to clarify somewhere that a ‘hart’ is RISC-V
> terminology
> for a hardware thread.
> 

Good point, I will add a note in the next version. Thanks!

Lukas

> > The patches have been successfully tested on both QEMU (machine and
> > supervisor mode) and the HiFive Unleashed board [1] (supervisor
> > mode),
> > using BBL and OpenSBI.
> > Mainline QEMU requires two patches [2, 3] to run in this
> > configuration.
> > I will send a follow-up patch to enable SMP support on the HiFive
> > Unleashed board.
> > 
> > [1]: https://patchwork.ozlabs.org/project/uboot/list/?series=91125
> > [2]: https://patchwork.ozlabs.org/patch/1039493/
> > [3]: https://patchwork.ozlabs.org/patch/1039082/
> > 
> > 
> > Lukas Auer (7):
> >  riscv: add infrastructure for calling functions on other harts
> >  riscv: import the supervisor binary interface header file
> >  riscv: implement IPI platform functions using SBI
> >  riscv: delay initialization of caches and debug UART
> >  riscv: add support for multi-hart systems
> >  riscv: boot images passed to bootm on all harts
> >  riscv: qemu: enable SMP
> > 
> > arch/riscv/Kconfig   |  36 +
> > arch/riscv/cpu/start.S   | 116
> > +--
> > arch/riscv/include/asm/csr.h |   1 +
> > arch/riscv/include/asm/global_data.h |   5 ++
> > arch/riscv/include/asm/sbi.h |  94 ++
> > arch/riscv/include/asm/smp.h |  53 
> > arch/riscv/lib/Makefile  |   2 +
> > arch/riscv/lib/bootm.c   |  13 ++-
> > arch/riscv/lib/sbi_ipi.c |  25 ++
> > arch/riscv/lib/smp.c | 110
> > +
> > board/emulation/qemu-riscv/Kconfig   |   1 +
> > 11 files changed, 447 insertions(+), 9 deletions(-)
> > create mode 100644 arch/riscv/include/asm/sbi.h
> > create mode 100644 arch/riscv/include/asm/smp.h
> > create mode 100644 arch/riscv/lib/sbi_ipi.c
> > create mode 100644 arch/riscv/lib/smp.c
> > 
> > -- 
> > 2.20.1
> > 
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] riscv: fu540: enable SMP

[Lukas Auer]

Hart 0 on the SiFive FU540 is meant for monitoring tasks. It is a E51
core, whereas all other cores are U54 cores. Select hart 1 as the main
hart to run U-Boot.

Signed-off-by: Lukas Auer 
---
This patch depends on the SMP support [1] and the SiFive FU540 support
patch series [2].
I have submitted it independently from the SMP support patch series to
allow the series to be merged independently from the SiFive FU540
support patch series.

[1]: https://patchwork.ozlabs.org/project/uboot/list/?series=91320
[2]: https://patchwork.ozlabs.org/project/uboot/list/?series=91125

 board/sifive/fu540/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
index 6be3d88144..d8a6020cf8 100644
--- a/board/sifive/fu540/Kconfig
+++ b/board/sifive/fu540/Kconfig
@@ -16,6 +16,9 @@ config SYS_TEXT_BASE
default 0x8000 if !RISCV_SMODE
default 0x8020 if RISCV_SMODE
 
+config MAIN_HART
+   default 1
+
 config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
select GENERIC_RISCV
@@ -38,5 +41,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply PHY_LIB
imply PHY_MSCC
imply SIFIVE_SERIAL
+   imply SMP
 
 endif
-- 
2.20.1

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

Re: [U-Boot] [PATCH 2/2] spi: ti_qspi: Convert to spi-mem ops

[Tom Rini]

On Mon, Feb 11, 2019 at 02:35:36PM +0530, Vignesh R wrote:

> Convert driver to use  spi-mem ops in order to support accelerated MMIO
> flash interface in generic way and for better performance.
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] Please pull from u-boot-i2c

[Tom Rini]

On Mon, Feb 11, 2019 at 04:55:29PM +0100, Heiko Schocher wrote:

> Hello Tom,
> 
> please pull from u-boot-i2c.git master
> 
> The following changes since commit 97276a91db8e98f081a40ddf9dc8f81d4032a756:
> 
>   Prepare v2019.04-rc1 (2019-02-07 21:32:19 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-i2c.git master
> 
> for you to fetch changes up to c4bd12a7dad43ed9de3070c7c5e8b690d8c03a79:
> 
>   i2c: mux: Generate longer i2c mux name (2019-02-11 09:38:23 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/2] spi: ti_qspi: Drop non DM code

[Tom Rini]

On Mon, Feb 11, 2019 at 02:35:35PM +0530, Vignesh R wrote:

> Now that all boards using TI QSPI have moved to DM and DT, drop non DM
> code completely.
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Tom Rini 

-- 
Tom


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

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

[Tom Rini]

On Mon, Feb 11, 2019 at 01:34:36PM +0100, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the following Marvell related patches, mostly board
> specific changes and one platform build fix:
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH 4/7] riscv: delay initialization of caches and debug UART

[Lukas Auer]

Move the initialization of the caches and the debug UART until after
board_init_f_init_reserve. This is in preparation for SMP support, where
code prior to this point will be executed by all harts. This ensures
that initialization will only be performed once for the main hart
running U-Boot.

Signed-off-by: Lukas Auer 
---

 arch/riscv/cpu/start.S | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 81ea52b170..a30f6f7194 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -45,10 +45,6 @@ _start:
/* mask all interrupts */
csrwMODE_PREFIX(ie), zero
 
-   /* Enable cache */
-   jal icache_enable
-   jal dcache_enable
-
 /*
  * Set stackpointer in internal/ex RAM to call board_init_f
  */
@@ -57,10 +53,6 @@ call_board_init_f:
li  t1, CONFIG_SYS_INIT_SP_ADDR
and sp, t1, t0  /* force 16 byte alignment */
 
-#ifdef CONFIG_DEBUG_UART
-   jal debug_uart_init
-#endif
-
 call_board_init_f_0:
mv  a0, sp
jal board_init_f_alloc_reserve
@@ -74,6 +66,14 @@ call_board_init_f_0:
/* save the boot hart id to global_data */
SREGs0, GD_BOOT_HART(gp)
 
+   /* Enable cache */
+   jal icache_enable
+   jal dcache_enable
+
+#ifdef CONFIG_DEBUG_UART
+   jal debug_uart_init
+#endif
+
mv  a0, zero/* a0 <-- boot_flags = 0 */
la  t5, board_init_f
jr  t5  /* jump to board_init_f() */
-- 
2.20.1

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

Re: [U-Boot] [PATCH 0/7] SMP support for RISC-V

[Philipp Tomsich]

On 11.02.2019, at 23:13, Lukas Auer  wrote:
> 
> This patch series adds SMP support for RISC-V to U-Boot. It allows
> U-Boot to run on multi-hart systems and will boot images passed to bootm
> on all harts. The bootm command is currently the only one that will boot
> images on all harts, bootefi is not yet supported.

You might want to clarify somewhere that a ‘hart’ is RISC-V terminology
for a hardware thread.

> 
> The patches have been successfully tested on both QEMU (machine and
> supervisor mode) and the HiFive Unleashed board [1] (supervisor mode),
> using BBL and OpenSBI.
> Mainline QEMU requires two patches [2, 3] to run in this configuration.
> I will send a follow-up patch to enable SMP support on the HiFive
> Unleashed board.
> 
> [1]: https://patchwork.ozlabs.org/project/uboot/list/?series=91125
> [2]: https://patchwork.ozlabs.org/patch/1039493/
> [3]: https://patchwork.ozlabs.org/patch/1039082/
> 
> 
> Lukas Auer (7):
>  riscv: add infrastructure for calling functions on other harts
>  riscv: import the supervisor binary interface header file
>  riscv: implement IPI platform functions using SBI
>  riscv: delay initialization of caches and debug UART
>  riscv: add support for multi-hart systems
>  riscv: boot images passed to bootm on all harts
>  riscv: qemu: enable SMP
> 
> arch/riscv/Kconfig   |  36 +
> arch/riscv/cpu/start.S   | 116 +--
> arch/riscv/include/asm/csr.h |   1 +
> arch/riscv/include/asm/global_data.h |   5 ++
> arch/riscv/include/asm/sbi.h |  94 ++
> arch/riscv/include/asm/smp.h |  53 
> arch/riscv/lib/Makefile  |   2 +
> arch/riscv/lib/bootm.c   |  13 ++-
> arch/riscv/lib/sbi_ipi.c |  25 ++
> arch/riscv/lib/smp.c | 110 +
> board/emulation/qemu-riscv/Kconfig   |   1 +
> 11 files changed, 447 insertions(+), 9 deletions(-)
> create mode 100644 arch/riscv/include/asm/sbi.h
> create mode 100644 arch/riscv/include/asm/smp.h
> create mode 100644 arch/riscv/lib/sbi_ipi.c
> create mode 100644 arch/riscv/lib/smp.c
> 
> -- 
> 2.20.1
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

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

[U-Boot] [PATCH 6/7] riscv: boot images passed to bootm on all harts

[Lukas Auer]

Signed-off-by: Lukas Auer 
---

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

diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index f36b8702ef..efbd3e23e7 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -81,6 +82,9 @@ static void boot_jump_linux(bootm_headers_t *images, int flag)
 {
void (*kernel)(ulong hart, void *dtb);
int fake = (flag & BOOTM_STATE_OS_FAKE_GO);
+#ifdef CONFIG_SMP
+   int ret;
+#endif
 
kernel = (void (*)(ulong, void *))images->ep;
 
@@ -92,8 +96,15 @@ static void boot_jump_linux(bootm_headers_t *images, int 
flag)
announce_and_cleanup(fake);
 
if (!fake) {
-   if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len)
+   if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len) {
+#ifdef CONFIG_SMP
+   ret = smp_call_function(images->ep,
+   (ulong)images->ft_addr, 0);
+   if (ret)
+   hang();
+#endif
kernel(gd->arch.boot_hart, images->ft_addr);
+   }
}
 }
 
-- 
2.20.1

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

[U-Boot] [PATCH 5/7] riscv: add support for multi-hart systems

[Lukas Auer]

On RISC-V, all harts boot independently. To be able to run on a
multi-hart system, U-Boot must be extended with the functionality to
manage all harts in the system. A new config option, CONFIG_MAIN_HART,
is used to select the hart U-Boot runs on. All other harts are halted.
U-Boot can delegate functions to them using smp_call_function().

Every hart has a valid pointer to the global data structure and a 8KiB
stack by default. The stack size is set with CONFIG_STACK_SIZE_SHIFT.

Signed-off-by: Lukas Auer 
---

 arch/riscv/Kconfig   |  12 +
 arch/riscv/cpu/start.S   | 102 ++-
 arch/riscv/include/asm/csr.h |   1 +
 3 files changed, 114 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 3a51339c4d..af8d0f8d67 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -140,4 +140,16 @@ config SBI_IPI
default y if RISCV_SMODE
depends on SMP
 
+config MAIN_HART
+   int "Main hart in system"
+   default 0
+   help
+ Some SoCs include harts of various sizes, some of which might not
+ be suitable for running U-Boot. CONFIG_MAIN_HART is used to select
+ the hart U-Boot runs on.
+
+config STACK_SIZE_SHIFT
+   int
+   default 13
+
 endmenu
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index a30f6f7194..ce7230df37 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -45,6 +46,23 @@ _start:
/* mask all interrupts */
csrwMODE_PREFIX(ie), zero
 
+#ifdef CONFIG_SMP
+   /* check if hart is within range */
+   /* s0: hart id */
+   li  t0, CONFIG_NR_CPUS
+   bge s0, t0, hart_out_of_bounds_loop
+#endif
+
+#ifdef CONFIG_SMP
+   /* set xSIE bit to receive IPIs */
+#ifdef CONFIG_RISCV_MMODE
+   li  t0, MIE_MSIE
+#else
+   li  t0, SIE_SSIE
+#endif
+   csrsMODE_PREFIX(ie), t0
+#endif
+
 /*
  * Set stackpointer in internal/ex RAM to call board_init_f
  */
@@ -56,7 +74,25 @@ call_board_init_f:
 call_board_init_f_0:
mv  a0, sp
jal board_init_f_alloc_reserve
+
+   /*
+* Set global data pointer here for all harts, uninitialized at this
+* point.
+*/
+   mv  gp, a0
+
+   /* setup stack */
+#ifdef CONFIG_SMP
+   /* s0: hart id */
+   sllit0, s0, CONFIG_STACK_SIZE_SHIFT
+   sub sp, a0, t0
+#else
mv  sp, a0
+#endif
+
+   /* Continue on main hart, others branch to secondary_hart_loop */
+   li  t0, CONFIG_MAIN_HART
+   bne s0, t0, secondary_hart_loop
 
la  t0, prior_stage_fdt_address
SREGs1, 0(t0)
@@ -95,7 +131,14 @@ relocate_code:
  *Set up the stack
  */
 stack_setup:
+#ifdef CONFIG_SMP
+   /* s0: hart id */
+   sllit0, s0, CONFIG_STACK_SIZE_SHIFT
+   sub sp, s2, t0
+#else
mv  sp, s2
+#endif
+
la  t0, _start
sub t6, s4, t0  /* t6 <- relocation offset */
beq t0, s4, clear_bss   /* skip relocation */
@@ -175,13 +218,30 @@ clear_bss:
add t0, t0, t6  /* t0 <- rel __bss_start in RAM */
la  t1, __bss_end   /* t1 <- rel __bss_end in FLASH */
add t1, t1, t6  /* t1 <- rel __bss_end in RAM */
-   beq t0, t1, call_board_init_r
+   beq t0, t1, relocate_secondary_harts
 
 clbss_l:
SREGzero, 0(t0) /* clear loop... */
addit0, t0, REGBYTES
bne t0, t1, clbss_l
 
+relocate_secondary_harts:
+#ifdef CONFIG_SMP
+   /* send relocation IPI */
+   la  t0, secondary_hart_relocate
+   add a0, t0, t6
+
+   /* store relocation offset */
+   mv  s5, t6
+
+   mv  a1, s2
+   mv  a2, s3
+   jal smp_call_function
+
+   /* restore relocation offset */
+   mv  t6, s5
+#endif
+
 /*
  * We are done. Do not return, instead branch to second part of board
  * initialization, now running from RAM.
@@ -202,3 +262,43 @@ call_board_init_r:
  * jump to it ...
  */
jr  t4  /* jump to board_init_r() */
+
+#ifdef CONFIG_SMP
+hart_out_of_bounds_loop:
+   /* Harts in this loop are out of bounds, increase CONFIG_NR_CPUS. */
+   wfi
+   j   hart_out_of_bounds_loop
+#endif
+
+#ifdef CONFIG_SMP
+/* SMP relocation entry */
+secondary_hart_relocate:
+   /* a1: new sp */
+   /* a2: new gd */
+   /* s0: hart id */
+
+   /* setup stack */
+   sllit0, s0, CONFIG_STACK_SIZE_SHIFT
+   sub sp, a1, t0
+
+   /* update global data pointer */
+   mv  gp, a2
+#endif
+
+secondary_hart_loop:
+   wfi
+
+#ifdef CONFIG_SMP
+   csrrt0, MODE_PREFIX(ip)
+#ifdef CONFIG_RISCV_MMODE
+   andit0, t0, MIE_MSIE
+#else
+   andit0, t0, SIE_SSIE
+#endif
+   

[U-Boot] [PATCH 7/7] riscv: qemu: enable SMP

[Lukas Auer]

Signed-off-by: Lukas Auer 
---

 board/emulation/qemu-riscv/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/emulation/qemu-riscv/Kconfig 
b/board/emulation/qemu-riscv/Kconfig
index 0d865acf10..b3300c64a8 100644
--- a/board/emulation/qemu-riscv/Kconfig
+++ b/board/emulation/qemu-riscv/Kconfig
@@ -34,5 +34,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply BOARD_LATE_INIT
imply OF_BOARD_SETUP
imply SIFIVE_SERIAL
+   imply SMP
 
 endif
-- 
2.20.1

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

[U-Boot] [PATCH 3/7] riscv: implement IPI platform functions using SBI

[Lukas Auer]

The supervisor binary interface (SBI) provides the necessary functions
to implement the platform IPI functions riscv_send_ipi() and
riscv_clear_ipi(). Use it to implement them.

This adds support for inter-processor interrupts (IPIs) on RISC-V CPUs
running in supervisor mode. Support for machine mode is already
available for CPUs that include the SiFive CLINT.

Signed-off-by: Lukas Auer 
---

 arch/riscv/Kconfig   |  5 +
 arch/riscv/lib/Makefile  |  1 +
 arch/riscv/lib/sbi_ipi.c | 25 +
 3 files changed, 31 insertions(+)
 create mode 100644 arch/riscv/lib/sbi_ipi.c

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index c0842178dd..3a51339c4d 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -135,4 +135,9 @@ config NR_CPUS
  Stack memory is pre-allocated. U-Boot must therefore know the
  maximum number of CPUs that may be present.
 
+config SBI_IPI
+   bool
+   default y if RISCV_SMODE
+   depends on SMP
+
 endmenu
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 19370f9749..35dbf643e4 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_RISCV_RDTIME) += rdtime.o
 obj-$(CONFIG_SIFIVE_CLINT) += sifive_clint.o
 obj-y  += interrupts.o
 obj-y  += reset.o
+obj-$(CONFIG_SBI_IPI) += sbi_ipi.o
 obj-y   += setjmp.o
 obj-$(CONFIG_SMP) += smp.o
 
diff --git a/arch/riscv/lib/sbi_ipi.c b/arch/riscv/lib/sbi_ipi.c
new file mode 100644
index 00..170346da68
--- /dev/null
+++ b/arch/riscv/lib/sbi_ipi.c
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Fraunhofer AISEC,
+ * Lukas Auer 
+ */
+
+#include 
+#include 
+
+int riscv_send_ipi(int hart)
+{
+   ulong mask;
+
+   mask = 1UL << hart;
+   sbi_send_ipi();
+
+   return 0;
+}
+
+int riscv_clear_ipi(int hart)
+{
+   sbi_clear_ipi();
+
+   return 0;
+}
-- 
2.20.1

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

[U-Boot] [PATCH 2/7] riscv: import the supervisor binary interface header file

[Lukas Auer]

Import the supervisor binary interface (SBI) header file from Linux
(arch/riscv/include/asm/sbi.h). The last change to it was in commit
6d60b6ee0c97 ("RISC-V: Device, timer, IRQs, and the SBI").

Signed-off-by: Lukas Auer 
---

 arch/riscv/include/asm/sbi.h | 94 
 1 file changed, 94 insertions(+)
 create mode 100644 arch/riscv/include/asm/sbi.h

diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
new file mode 100644
index 00..ced57defdd
--- /dev/null
+++ b/arch/riscv/include/asm/sbi.h
@@ -0,0 +1,94 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2015 Regents of the University of California
+ *
+ * Taken from Linux arch/riscv/include/asm/sbi.h
+ */
+
+#ifndef _ASM_RISCV_SBI_H
+#define _ASM_RISCV_SBI_H
+
+#include 
+
+#define SBI_SET_TIMER 0
+#define SBI_CONSOLE_PUTCHAR 1
+#define SBI_CONSOLE_GETCHAR 2
+#define SBI_CLEAR_IPI 3
+#define SBI_SEND_IPI 4
+#define SBI_REMOTE_FENCE_I 5
+#define SBI_REMOTE_SFENCE_VMA 6
+#define SBI_REMOTE_SFENCE_VMA_ASID 7
+#define SBI_SHUTDOWN 8
+
+#define SBI_CALL(which, arg0, arg1, arg2) ({   \
+   register uintptr_t a0 asm ("a0") = (uintptr_t)(arg0);   \
+   register uintptr_t a1 asm ("a1") = (uintptr_t)(arg1);   \
+   register uintptr_t a2 asm ("a2") = (uintptr_t)(arg2);   \
+   register uintptr_t a7 asm ("a7") = (uintptr_t)(which);  \
+   asm volatile ("ecall"   \
+ : "+r" (a0)   \
+ : "r" (a1), "r" (a2), "r" (a7)\
+ : "memory");  \
+   a0; \
+})
+
+/* Lazy implementations until SBI is finalized */
+#define SBI_CALL_0(which) SBI_CALL(which, 0, 0, 0)
+#define SBI_CALL_1(which, arg0) SBI_CALL(which, arg0, 0, 0)
+#define SBI_CALL_2(which, arg0, arg1) SBI_CALL(which, arg0, arg1, 0)
+
+static inline void sbi_console_putchar(int ch)
+{
+   SBI_CALL_1(SBI_CONSOLE_PUTCHAR, ch);
+}
+
+static inline int sbi_console_getchar(void)
+{
+   return SBI_CALL_0(SBI_CONSOLE_GETCHAR);
+}
+
+static inline void sbi_set_timer(uint64_t stime_value)
+{
+#if __riscv_xlen == 32
+   SBI_CALL_2(SBI_SET_TIMER, stime_value, stime_value >> 32);
+#else
+   SBI_CALL_1(SBI_SET_TIMER, stime_value);
+#endif
+}
+
+static inline void sbi_shutdown(void)
+{
+   SBI_CALL_0(SBI_SHUTDOWN);
+}
+
+static inline void sbi_clear_ipi(void)
+{
+   SBI_CALL_0(SBI_CLEAR_IPI);
+}
+
+static inline void sbi_send_ipi(const unsigned long *hart_mask)
+{
+   SBI_CALL_1(SBI_SEND_IPI, hart_mask);
+}
+
+static inline void sbi_remote_fence_i(const unsigned long *hart_mask)
+{
+   SBI_CALL_1(SBI_REMOTE_FENCE_I, hart_mask);
+}
+
+static inline void sbi_remote_sfence_vma(const unsigned long *hart_mask,
+unsigned long start,
+unsigned long size)
+{
+   SBI_CALL_1(SBI_REMOTE_SFENCE_VMA, hart_mask);
+}
+
+static inline void sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
+ unsigned long start,
+ unsigned long size,
+ unsigned long asid)
+{
+   SBI_CALL_1(SBI_REMOTE_SFENCE_VMA_ASID, hart_mask);
+}
+
+#endif
-- 
2.20.1

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

[U-Boot] [PATCH 1/7] riscv: add infrastructure for calling functions on other harts

[Lukas Auer]

Harts on RISC-V boot independently and U-Boot is responsible for
managing them. Functions are called on other harts with
smp_call_function(), which sends inter-processor interrupts (IPIs) to
all other harts. Functions are specified with their address and two
function arguments (argument 2 and 3). The first function argument is
always the hart ID of the hart calling the function. On the other harts,
the IPI interrupt handler handle_ipi() must be called on software
interrupts to handle the request and call the specified function.

Functions are stored in the ipi_data data structure. Every hart has its
own data structure in global data. While this is not required at the
moment (all harts are expected to boot Linux), this does allow future
expansion, where other harts may be used for monitoring or other tasks.

Signed-off-by: Lukas Auer 
---

 arch/riscv/Kconfig   |  19 +
 arch/riscv/include/asm/global_data.h |   5 ++
 arch/riscv/include/asm/smp.h |  53 +
 arch/riscv/lib/Makefile  |   1 +
 arch/riscv/lib/smp.c | 110 +++
 5 files changed, 188 insertions(+)
 create mode 100644 arch/riscv/include/asm/smp.h
 create mode 100644 arch/riscv/lib/smp.c

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index c45e4d73a8..c0842178dd 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -116,4 +116,23 @@ config RISCV_RDTIME
 config SYS_MALLOC_F_LEN
default 0x1000
 
+config SMP
+   bool "Symmetric Multi-Processing"
+   help
+ This enables support for systems with more than one CPU. If
+ you say N here, U-Boot will run on single and multiprocessor
+ machines, but will use only one CPU of a multiprocessor
+ machine. If you say Y here, U-Boot will run on many, but not
+ all, single processor machines.
+
+config NR_CPUS
+   int "Maximum number of CPUs (2-32)"
+   range 2 32
+   depends on SMP
+   default "8"
+   help
+ On multiprocessor machines, U-Boot sets up a stack for each CPU.
+ Stack memory is pre-allocated. U-Boot must therefore know the
+ maximum number of CPUs that may be present.
+
 endmenu
diff --git a/arch/riscv/include/asm/global_data.h 
b/arch/riscv/include/asm/global_data.h
index a3a342c6e1..23a5f35af5 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -10,12 +10,17 @@
 #ifndef__ASM_GBL_DATA_H
 #define __ASM_GBL_DATA_H
 
+#include 
+
 /* Architecture-specific global data */
 struct arch_global_data {
long boot_hart; /* boot hart id */
 #ifdef CONFIG_SIFIVE_CLINT
void __iomem *clint;/* clint base address */
 #endif
+#ifdef CONFIG_SMP
+   struct ipi_data ipi[CONFIG_NR_CPUS];
+#endif
 };
 
 #include 
diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
new file mode 100644
index 00..bc863fdbaf
--- /dev/null
+++ b/arch/riscv/include/asm/smp.h
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Fraunhofer AISEC,
+ * Lukas Auer 
+ */
+
+#ifndef _ASM_RISCV_SMP_H
+#define _ASM_RISCV_SMP_H
+
+/**
+ * struct ipi_data - Inter-processor interrupt (IPI) data structure
+ *
+ * IPIs are used for SMP support to communicate to other harts what function to
+ * call. Functions are in the form
+ * void (*addr)(ulong hart, ulong arg0, ulong arg1).
+ *
+ * The function address and the two arguments, arg0 and arg1, are stored in the
+ * IPI data structure. The hart ID is inserted by the hart handling the IPI and
+ * calling the function.
+ *
+ * @addr: Address of function
+ * @arg0: First argument of function
+ * @arg1: Second argument of function
+ */
+struct ipi_data {
+   ulong addr;
+   ulong arg0;
+   ulong arg1;
+};
+
+/**
+ * handle_ipi() - interrupt handler for software interrupts
+ *
+ * The IPI interrupt handler must be called to handle software interrupts. It
+ * calls the function specified in the hart's IPI data structure.
+ *
+ * @hart: Hart ID of the current hart
+ */
+void handle_ipi(ulong hart);
+
+/**
+ * smp_call_function() - Call a function on all other harts
+ *
+ * Send IPIs with the specified function call to all harts.
+ *
+ * @addr: Address of function
+ * @arg0: First argument of function
+ * @arg1: Second argument of function
+ * @return 0 if OK, -ve on error
+ */
+int smp_call_function(ulong addr, ulong arg0, ulong arg1);
+
+#endif
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index edfa61690c..19370f9749 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_SIFIVE_CLINT) += sifive_clint.o
 obj-y  += interrupts.o
 obj-y  += reset.o
 obj-y   += setjmp.o
+obj-$(CONFIG_SMP) += smp.o
 
 # For building EFI apps
 CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
diff --git a/arch/riscv/lib/smp.c b/arch/riscv/lib/smp.c
new file mode 100644
index 00..1266a2a0ef
--- /dev/null
+++ b/arch/riscv/lib/smp.c
@@ 

[U-Boot] [PATCH 0/7] SMP support for RISC-V

[Lukas Auer]

This patch series adds SMP support for RISC-V to U-Boot. It allows
U-Boot to run on multi-hart systems and will boot images passed to bootm
on all harts. The bootm command is currently the only one that will boot
images on all harts, bootefi is not yet supported.

The patches have been successfully tested on both QEMU (machine and
supervisor mode) and the HiFive Unleashed board [1] (supervisor mode),
using BBL and OpenSBI.
Mainline QEMU requires two patches [2, 3] to run in this configuration.
I will send a follow-up patch to enable SMP support on the HiFive
Unleashed board.

[1]: https://patchwork.ozlabs.org/project/uboot/list/?series=91125
[2]: https://patchwork.ozlabs.org/patch/1039493/
[3]: https://patchwork.ozlabs.org/patch/1039082/


Lukas Auer (7):
  riscv: add infrastructure for calling functions on other harts
  riscv: import the supervisor binary interface header file
  riscv: implement IPI platform functions using SBI
  riscv: delay initialization of caches and debug UART
  riscv: add support for multi-hart systems
  riscv: boot images passed to bootm on all harts
  riscv: qemu: enable SMP

 arch/riscv/Kconfig   |  36 +
 arch/riscv/cpu/start.S   | 116 +--
 arch/riscv/include/asm/csr.h |   1 +
 arch/riscv/include/asm/global_data.h |   5 ++
 arch/riscv/include/asm/sbi.h |  94 ++
 arch/riscv/include/asm/smp.h |  53 
 arch/riscv/lib/Makefile  |   2 +
 arch/riscv/lib/bootm.c   |  13 ++-
 arch/riscv/lib/sbi_ipi.c |  25 ++
 arch/riscv/lib/smp.c | 110 +
 board/emulation/qemu-riscv/Kconfig   |   1 +
 11 files changed, 447 insertions(+), 9 deletions(-)
 create mode 100644 arch/riscv/include/asm/sbi.h
 create mode 100644 arch/riscv/include/asm/smp.h
 create mode 100644 arch/riscv/lib/sbi_ipi.c
 create mode 100644 arch/riscv/lib/smp.c

-- 
2.20.1

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

Re: [U-Boot] [REGRESSION] tegra124: nyan-big: LPAE not working

[Stephen Warren]

On 2/11/19 3:48 AM, Thierry Reding wrote:

On Mon, Feb 11, 2019 at 10:04:37AM +, Tristan Bastian wrote:




Thierry Reding – Mon, 11. February 2019 10:38

On Mon, Feb 11, 2019 at 09:20:33AM +, Tristan Bastian wrote:


Thierry Reding – Mon, 11. February 2019 9:52

On Sun, Feb 10, 2019 at 08:53:11PM +0100, Tristan Bastian wrote:

Thierry, do you have any news on this?

I don't think, that google is going to push an updated version of

coreboot

to each nyan-big device..
So reverting this patch at least for the nyan devices would be the best

I

think..


Yes, I agree. I had a brief chat with Rob Herring about this and he too
agrees that we should revert it for now. I'll make it a manual revert
and add a comment to the device tree node that will hopefully avoid any
future janitorial "cleanups" of this sort.


great news! :)


BTW: I'm now running u-boot natively and it seems like u-boot always has

a

problem with the memory..
If u-boot is used chainloaded to coreboot it is only getting 2GB of

memory

and running u-boot natively also just gives me 2GB..
I've tested that with a kernel with "ARM: tegra: Fix unit_address_vs_reg

DTC

warnings for /memory" reverted and also on a kernel, before this patch

was

applied..


It's possible that U-Boot doesn't support LPAE and therefore may not be
able to use more than the 2 GiB of memory.


So I at least enabled LPAE in u-boot with "CONFIG_ARMV7_LPAE=y" and
this was for some reason also needed to get some output on the
display..
I'm not sure why LPAE needs to activated in u-boot for display output
on the nyan-big..
Without LPAE enabled u-boot was still working, and booted linux, but
u-boot didn't display anything on screen, linux then did..


Yeah, that's surprising. Perhaps without LPAE U-Boot thinks there's not
enough memory for the framebuffer? There should be plenty, so maybe
there is something else going on here.


However, U-Boot should be
able to tell the kernel exactly how much memory the system has and pass
that on via device tree. That still does work, right?


It seems like this is not working..
And this seems to be the case with both, u-boot chainloaded and
running u-boot natively..

I've used these scripts for flashing:
github.com/NVIDIA/tegra-uboot-flasher-scripts
And used the norrin device since it seems like it is the nyan-big dev
board?
But going with the norrin device config should not be the issue here
since the problem also exists when chainloading u-boot, right?


It could be a problem. The memory bank configuration is stored in what's
called a BCT along with a bunch of other parameters that define what the
memory controller needs to access the given memory chips. So if you've
flashed a BCT that's for a board with only 2 GiB of memory you would end
up with a system that can't address any more than that. It's somewhat
surprising that memory accesses work at all with a BCT that's for
different memory chips, but sometimes you can get lucky.

You may want to try reflashing with the right BCT. The simplest would
probably be to duplicate the cbootimage configuration for Norrin and
substitute the relevant bits by what you have from the Chromebook flash
utilities. Looks like the BCT in really the only thing you can replace
there. Make sure to replace it with the one that matches your Chromebook
and it should give you the right memory bank configuration.


Is there a way to check if the correct bct for my 4GB model was used?
What I tried was to edit the existing bct config file of norrin from here:
https://github.com/NVIDIA/cbootimage-configs/blob/master/tegra124/nvidia/norrin/PM370_Hynix_2GB_H5TC4G63AFR_PBA_924MHz_01212014.bct.cfg
by replacing all entries for each memory bank with the entries from here:
https://github.com/coreboot/coreboot/blob/master/src/mainboard/google/nyan_big/bct/sdram-hynix-4GB-792.inc

I also added the SDRAM[0], SDRAM[1], SDRAM[2], SDRAM[3] each time in front of 
each line..
This also booted for me, but also just leaves me with only 2Gb of my 4GB..

And since this problem also occurs, when chainloading u-boot, this must be a 
problem with u-boot, I think..


Not necessarily. U-Boot reads the memory size from EMC registers and
those EMC registers are programmed based on the contents of the BCT. So
if the BCT is wrong, then it's going to be wrong irrespective of what
bootloader you use.

That said, I does indeed look as if U-Boot only supports 2 GiB of memory
on 32-bit Tegra. arch/arm/mach-tegra/board.c contains the relevant code.
If you look at dram_init() it uses query_sdram_size() to get the size of
RAM. That will allow to convey up to 4 GiB of RAM, but then the code in
board2.c (see dram_init_banksize()) only uses a single bank on 32-bit
Tegra (CONFIG_PHYS_64BIT is only set for 64-bit Tegra).

According to the comments for dram_init_bank_size() we can't store the
second bank because the .start field is 32 bits wide and therefore can't
store the 0x1 start address for the bank.

It sounds to me like ARMV7_LPAE 

Re: [U-Boot] [REGRESSION] tegra124: nyan-big: LPAE not working

[Tristan Bastian]

Am 11.02.19 um 11:48 schrieb Thierry Reding:

On Mon, Feb 11, 2019 at 10:04:37AM +, Tristan Bastian wrote:



Thierry Reding – Mon, 11. February 2019 10:38

On Mon, Feb 11, 2019 at 09:20:33AM +, Tristan Bastian wrote:

Thierry Reding – Mon, 11. February 2019 9:52

On Sun, Feb 10, 2019 at 08:53:11PM +0100, Tristan Bastian wrote:

Thierry, do you have any news on this?

I don't think, that google is going to push an updated version of

coreboot

to each nyan-big device..
So reverting this patch at least for the nyan devices would be the best

I

think..

Yes, I agree. I had a brief chat with Rob Herring about this and he too
agrees that we should revert it for now. I'll make it a manual revert
and add a comment to the device tree node that will hopefully avoid any
future janitorial "cleanups" of this sort.

great news! :)


BTW: I'm now running u-boot natively and it seems like u-boot always has

a

problem with the memory..
If u-boot is used chainloaded to coreboot it is only getting 2GB of

memory

and running u-boot natively also just gives me 2GB..
I've tested that with a kernel with "ARM: tegra: Fix unit_address_vs_reg

DTC

warnings for /memory" reverted and also on a kernel, before this patch

was

applied..

It's possible that U-Boot doesn't support LPAE and therefore may not be
able to use more than the 2 GiB of memory.

So I at least enabled LPAE in u-boot with "CONFIG_ARMV7_LPAE=y" and
this was for some reason also needed to get some output on the
display..
I'm not sure why LPAE needs to activated in u-boot for display output
on the nyan-big..
Without LPAE enabled u-boot was still working, and booted linux, but
u-boot didn't display anything on screen, linux then did..

Yeah, that's surprising. Perhaps without LPAE U-Boot thinks there's not
enough memory for the framebuffer? There should be plenty, so maybe
there is something else going on here.


However, U-Boot should be
able to tell the kernel exactly how much memory the system has and pass
that on via device tree. That still does work, right?

It seems like this is not working..
And this seems to be the case with both, u-boot chainloaded and
running u-boot natively..

I've used these scripts for flashing:
github.com/NVIDIA/tegra-uboot-flasher-scripts
And used the norrin device since it seems like it is the nyan-big dev
board?
But going with the norrin device config should not be the issue here
since the problem also exists when chainloading u-boot, right?

It could be a problem. The memory bank configuration is stored in what's
called a BCT along with a bunch of other parameters that define what the
memory controller needs to access the given memory chips. So if you've
flashed a BCT that's for a board with only 2 GiB of memory you would end
up with a system that can't address any more than that. It's somewhat
surprising that memory accesses work at all with a BCT that's for
different memory chips, but sometimes you can get lucky.

You may want to try reflashing with the right BCT. The simplest would
probably be to duplicate the cbootimage configuration for Norrin and
substitute the relevant bits by what you have from the Chromebook flash
utilities. Looks like the BCT in really the only thing you can replace
there. Make sure to replace it with the one that matches your Chromebook
and it should give you the right memory bank configuration.

Is there a way to check if the correct bct for my 4GB model was used?
What I tried was to edit the existing bct config file of norrin from here:
https://github.com/NVIDIA/cbootimage-configs/blob/master/tegra124/nvidia/norrin/PM370_Hynix_2GB_H5TC4G63AFR_PBA_924MHz_01212014.bct.cfg
by replacing all entries for each memory bank with the entries from here:
https://github.com/coreboot/coreboot/blob/master/src/mainboard/google/nyan_big/bct/sdram-hynix-4GB-792.inc

I also added the SDRAM[0], SDRAM[1], SDRAM[2], SDRAM[3] each time in front of 
each line..
This also booted for me, but also just leaves me with only 2Gb of my 4GB..

And since this problem also occurs, when chainloading u-boot, this must be a 
problem with u-boot, I think..

Not necessarily. U-Boot reads the memory size from EMC registers and
those EMC registers are programmed based on the contents of the BCT. So
if the BCT is wrong, then it's going to be wrong irrespective of what
bootloader you use.

That said, I does indeed look as if U-Boot only supports 2 GiB of memory
on 32-bit Tegra. arch/arm/mach-tegra/board.c contains the relevant code.
If you look at dram_init() it uses query_sdram_size() to get the size of
RAM. That will allow to convey up to 4 GiB of RAM, but then the code in
board2.c (see dram_init_banksize()) only uses a single bank on 32-bit
Tegra (CONFIG_PHYS_64BIT is only set for 64-bit Tegra).


I've enabled "CONFIG_PHYS_64BIT" for testing and it seems to be at least 
helping.
I'm getting a bunch of compile warnings about casting pointers from 
integers of different size..


But I'm getting 4GB of memory now if I boot via an 

Re: [U-Boot] [PATCH] test: call lmb tests vi 'ut lib'

[Simon Goldschmidt]

Am Mo., 11. Feb. 2019, 22:27 hat Heinrich Schuchardt 
geschrieben:

> On 2/11/19 8:58 PM, Simon Goldschmidt wrote:
> > The unit tests in test/lib/lmb.c are not related to the device tree.
> > So they should be executed via `ut lib` and not via `ut dm`.
> >
> > Signed-off-by: Simon Goldschmidt 
> > ---
>
> With sandbox_defconfig:
>
> ./u-boot -D
> => ut lib
> Running 12 lib tests
> Test: lib_memcpy
> Test: lib_memmove
> Test: lib_memset
> Test: lib_test_lmb_alloc_addr
> ERROR: Failed to allocate 0x1 bytes below 0x0.
> ERROR: Failed to allocate 0x1 bytes below 0x0.
> Test: lib_test_lmb_at_0
> ERROR: Failed to allocate 0x4 bytes below 0x0.
> Test: lib_test_lmb_big
> ERROR: Failed to allocate 0x1000 bytes below 0x0.
> ERROR: Failed to allocate 0x2000 bytes below 0x0.
> ERROR: Failed to allocate 0x1000 bytes below 0x0.
> ERROR: Failed to allocate 0x2000 bytes below 0x0.
> Test: lib_test_lmb_get_free_size
> Test: lib_test_lmb_noreserved
> Test: lib_test_lmb_overlapping_reserve
> Test: lib_test_lmb_simple
> Test: lib_test_lmb_simple_x2
> Test: lib_test_lmb_unaligned_size
> Failures: 0
> =>
>

Well, these are not test errors but output of the functions the test calls.
That could be improved...


> Without your patch
>
> => ut dm
>
> simply hangs. So I cannot judge if these are new errors.
>

Hmm, I have no idea what's wrong when it hangs. I ran 'ut dm' about a week
or two ago and it worked for me...

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

Re: [U-Boot] [PATCH] test: call lmb tests vi 'ut lib'

[Heinrich Schuchardt]

On 2/11/19 8:58 PM, Simon Goldschmidt wrote:
> The unit tests in test/lib/lmb.c are not related to the device tree.
> So they should be executed via `ut lib` and not via `ut dm`.
> 
> Signed-off-by: Simon Goldschmidt 
> ---

With sandbox_defconfig:

./u-boot -D
=> ut lib
Running 12 lib tests
Test: lib_memcpy
Test: lib_memmove
Test: lib_memset
Test: lib_test_lmb_alloc_addr
ERROR: Failed to allocate 0x1 bytes below 0x0.
ERROR: Failed to allocate 0x1 bytes below 0x0.
Test: lib_test_lmb_at_0
ERROR: Failed to allocate 0x4 bytes below 0x0.
Test: lib_test_lmb_big
ERROR: Failed to allocate 0x1000 bytes below 0x0.
ERROR: Failed to allocate 0x2000 bytes below 0x0.
ERROR: Failed to allocate 0x1000 bytes below 0x0.
ERROR: Failed to allocate 0x2000 bytes below 0x0.
Test: lib_test_lmb_get_free_size
Test: lib_test_lmb_noreserved
Test: lib_test_lmb_overlapping_reserve
Test: lib_test_lmb_simple
Test: lib_test_lmb_simple_x2
Test: lib_test_lmb_unaligned_size
Failures: 0
=>

Without your patch

=> ut dm

simply hangs. So I cannot judge if these are new errors.

Best regards

Heinrich


> 
>  test/lib/lmb.c | 23 +++
>  1 file changed, 11 insertions(+), 12 deletions(-)
> 
> diff --git a/test/lib/lmb.c b/test/lib/lmb.c
> index ec68227bb6..88764293b9 100644
> --- a/test/lib/lmb.c
> +++ b/test/lib/lmb.c
> @@ -5,7 +5,8 @@
>  
>  #include 
>  #include 
> -#include 
> +#include 
> +#include 
>  #include 
>  
>  static int check_lmb(struct unit_test_state *uts, struct lmb *lmb,
> @@ -197,7 +198,7 @@ static int lib_test_lmb_simple(struct unit_test_state 
> *uts)
>   return test_multi_alloc_512mb(uts, 0xE000);
>  }
>  
> -DM_TEST(lib_test_lmb_simple, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
> +LIB_TEST(lib_test_lmb_simple, 0);
>  
>  /* Create two memory regions with one reserved region and allocate */
>  static int lib_test_lmb_simple_x2(struct unit_test_state *uts)
> @@ -213,7 +214,7 @@ static int lib_test_lmb_simple_x2(struct unit_test_state 
> *uts)
>   return test_multi_alloc_512mb_x2(uts, 0xE000, 0x4000);
>  }
>  
> -DM_TEST(lib_test_lmb_simple_x2,  DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
> +LIB_TEST(lib_test_lmb_simple_x2, 0);
>  
>  /* Simulate 512 MiB RAM, allocate some blocks that fit/don't fit */
>  static int test_bigblock(struct unit_test_state *uts, const phys_addr_t ram)
> @@ -280,7 +281,7 @@ static int lib_test_lmb_big(struct unit_test_state *uts)
>   return test_bigblock(uts, 0xE000);
>  }
>  
> -DM_TEST(lib_test_lmb_big, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
> +LIB_TEST(lib_test_lmb_big, 0);
>  
>  /* Simulate 512 MiB RAM, allocate a block without previous reservation */
>  static int test_noreserved(struct unit_test_state *uts, const phys_addr_t 
> ram,
> @@ -355,7 +356,7 @@ static int lib_test_lmb_noreserved(struct unit_test_state 
> *uts)
>   return test_noreserved(uts, 0xE000, 4, 1);
>  }
>  
> -DM_TEST(lib_test_lmb_noreserved, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
> +LIB_TEST(lib_test_lmb_noreserved, 0);
>  
>  static int lib_test_lmb_unaligned_size(struct unit_test_state *uts)
>  {
> @@ -370,7 +371,7 @@ static int lib_test_lmb_unaligned_size(struct 
> unit_test_state *uts)
>   return test_noreserved(uts, 0xE000, 5, 8);
>  }
>  
> -DM_TEST(lib_test_lmb_unaligned_size, DM_TESTF_SCAN_PDATA | 
> DM_TESTF_SCAN_FDT);
> +LIB_TEST(lib_test_lmb_unaligned_size, 0);
>  /*
>   * Simulate a RAM that starts at 0 and allocate down to address 0, which must
>   * fail as '0' means failure for the lmb_alloc functions.
> @@ -413,7 +414,7 @@ static int lib_test_lmb_at_0(struct unit_test_state *uts)
>   return 0;
>  }
>  
> -DM_TEST(lib_test_lmb_at_0, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
> +LIB_TEST(lib_test_lmb_at_0, 0);
>  
>  /* Check that calling lmb_reserve with overlapping regions fails. */
>  static int lib_test_lmb_overlapping_reserve(struct unit_test_state *uts)
> @@ -451,8 +452,7 @@ static int lib_test_lmb_overlapping_reserve(struct 
> unit_test_state *uts)
>   return 0;
>  }
>  
> -DM_TEST(lib_test_lmb_overlapping_reserve,
> - DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
> +LIB_TEST(lib_test_lmb_overlapping_reserve, 0);
>  
>  /*
>   * Simulate 512 MiB RAM, reserve 3 blocks, allocate addresses in between.
> @@ -582,7 +582,7 @@ static int lib_test_lmb_alloc_addr(struct unit_test_state 
> *uts)
>   return test_alloc_addr(uts, 0xE000);
>  }
>  
> -DM_TEST(lib_test_lmb_alloc_addr, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
> +LIB_TEST(lib_test_lmb_alloc_addr, 0);
>  
>  /* Simulate 512 MiB RAM, reserve 3 blocks, check addresses in between */
>  static int test_get_unreserved_size(struct unit_test_state *uts,
> @@ -653,5 +653,4 @@ static int lib_test_lmb_get_free_size(struct 
> unit_test_state *uts)
>   return test_get_unreserved_size(uts, 0xE000);
>  }
>  
> -DM_TEST(lib_test_lmb_get_free_size,
> - DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
> +LIB_TEST(lib_test_lmb_get_free_size, 0);
> 

Re: [U-Boot] [PATCH 1/1] efi_loader: fix EFI entry counting

[Alexander Graf]

On 11.02.19 18:46, Heinrich Schuchardt wrote:
> On 2/10/19 1:11 AM, Heinrich Schuchardt wrote:
>> `bootefi selftest` fails on qemu-x86_defconfig if efi_selftest() is not
>> invoked using EFI_CALL().
>>
>> Likewise we call the entry point of EFI payloads with
>> EFI_CALL(efi_start_image()).
>>
>> entry_count indicates if we are in U-Boot (1) or in EFI payload code (0).
>> As we start in U-Boot code the initial value has to be 1.
>>
>> Signed-off-by: Heinrich Schuchardt 
> 
> Hello Alex,
> 
> you just merged this patch into your efi-next tree.

Yes, I figured that a "Fix" patch is reasonably important for this cycle.

> 
> It depends on
> 
> efi_loader: use efi_start_image() for bootefi
> https://lists.denx.de/pipermail/u-boot/2019-February/358045.html

Please indicate that properly in the patch next time.

> 
> So, please, either remove the patch from your efi-next queue or put the
> "efi_loader: rework loading and starting of images" patch series in
> before this patch.

I've removed it from there queue again.

Thanks for the report!


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

Re: [U-Boot] [U-Boot,v2,11/23] spl: Add a comment to spl_set_bd()

[Simon Goldschmidt]

Am 09.11.2018 um 19:43 schrieb Tom Rini:

On Tue, Oct 02, 2018 at 05:22:41AM -0600, Simon Glass wrote:


There is a strange feature to set global_data to a data-section variable
early in SPL. This only works if SPL actually has access to SRAM which is
not the case on x86, for eaxmple. Add a comment to this effect.


Seems like I missed that one back in October.

Does anyone have an idea why this variable ('static bd_t bdata') is 
hard-coded into section ".data"? To me this seems pretty unportable...


For example, for a specific feature on socfpga (warm reboot CRC check), 
I would prefer to have the ".data" section empty and put 'bdata' into 
bss. This is currently not possible.


But before sending a patch that somehow changes this behaviour, I'd like 
to know why this variable is put into ".data" instead of ".bss"


Thanks,
Simon



Signed-off-by: Simon Glass 


Reviewed-by: Tom Rini 

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

Re: [U-Boot] [PATCH 2/3] ARM: rmobile: Add basic PSCI support for r8a7790 SoC

[Oleksandr]

On 09.02.19 18:32, Marek Vasut wrote:

On 2/8/19 11:52 AM, Oleksandr wrote:

On 05.02.19 20:55, Marek Vasut wrote:

Hi Marek

Hi,


Hi Marek


On 1/31/19 6:38 PM, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

Also enable PSCI support for Stout and Lager boards where
actually the r8a7790 SoC is installed.

All secondary CPUs will be switched to a non-secure HYP mode
after booting.

Signed-off-by: Oleksandr Tyshchenko 
---
   arch/arm/mach-rmobile/Kconfig.32   |   2 +
   arch/arm/mach-rmobile/Makefile |   6 +
   arch/arm/mach-rmobile/pm-r8a7790.c | 408
+
   arch/arm/mach-rmobile/pm-r8a7790.h |  72 +++
   arch/arm/mach-rmobile/psci.c   | 193 ++
   include/configs/lager.h    |   2 +
   include/configs/stout.h    |   2 +
   7 files changed, 685 insertions(+)
   create mode 100644 arch/arm/mach-rmobile/pm-r8a7790.c
   create mode 100644 arch/arm/mach-rmobile/pm-r8a7790.h
   create mode 100644 arch/arm/mach-rmobile/psci.c

diff --git a/arch/arm/mach-rmobile/Kconfig.32
b/arch/arm/mach-rmobile/Kconfig.32
index a2e9e3d..728c323 100644
--- a/arch/arm/mach-rmobile/Kconfig.32
+++ b/arch/arm/mach-rmobile/Kconfig.32
@@ -78,6 +78,7 @@ config TARGET_LAGER
   imply CMD_DM
   select CPU_V7_HAS_NONSEC
   select CPU_V7_HAS_VIRT
+    select ARCH_SUPPORT_PSCI
     config TARGET_KZM9G
   bool "KZM9D board"
@@ -119,6 +120,7 @@ config TARGET_STOUT
   imply CMD_DM
   select CPU_V7_HAS_NONSEC
   select CPU_V7_HAS_VIRT
+    select ARCH_SUPPORT_PSCI

To myself: Move this option under "config R8A7790".


     endchoice
   diff --git a/arch/arm/mach-rmobile/Makefile
b/arch/arm/mach-rmobile/Makefile
index 1f26ada..6f4c513 100644
--- a/arch/arm/mach-rmobile/Makefile
+++ b/arch/arm/mach-rmobile/Makefile
@@ -13,3 +13,9 @@ obj-$(CONFIG_SH73A0) += lowlevel_init.o
cpu_info-sh73a0.o pfc-sh73a0.o
   obj-$(CONFIG_R8A7740) += lowlevel_init.o cpu_info-r8a7740.o
pfc-r8a7740.o
   obj-$(CONFIG_RCAR_GEN2) += lowlevel_init_ca15.o cpu_info-rcar.o
   obj-$(CONFIG_RCAR_GEN3) += lowlevel_init_gen3.o cpu_info-rcar.o
memmap-gen3.o
+
+ifndef CONFIG_SPL_BUILD
+ifdef CONFIG_R8A7790
+obj-$(CONFIG_ARMV7_PSCI) += psci.o pm-r8a7790.o
+endif
+endif
diff --git a/arch/arm/mach-rmobile/pm-r8a7790.c
b/arch/arm/mach-rmobile/pm-r8a7790.c
new file mode 100644
index 000..c635cf6
--- /dev/null
+++ b/arch/arm/mach-rmobile/pm-r8a7790.c
@@ -0,0 +1,408 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CPU power management support for Renesas r8a7790 SoC
+ *
+ * Contains functions to control ARM Cortex A15/A7 cores and
+ * related peripherals basically used for PSCI.
+ *
+ * Copyright (C) 2018 EPAM Systems Inc.
+ *
+ * Mainly based on Renesas R-Car Gen2 platform code from Linux:
+ *    arch/arm/mach-shmobile/...
+ */
+
+#include 
+#include 
+#include 
+
+#include "pm-r8a7790.h"
+
+/*


I'd expect checkpatch to complain about these long lines of asterisks.

No, there was no complain about it. I have checked. Anyway, I can remove
them if required.

Yes please, keep the comment style consistent with the rest of the
codebase, which is also the kernel comment style.


OK, will remove





+ * APMU definitions
+
*/

+#define CA15_APMU_BASE    0xe6152000
+#define CA7_APMU_BASE    0xe6151000

All these addresses should come from DT. And the driver should be DM
capable and live in drivers/

[...]

All PSCI backends for ARMV7 in U-Boot which I was able to found, are
located either in arch/arm/cpu/armv7/

or in arch/arm/mach-X. As well as other PSCI backends, this one will be
located in a separate secure section and acts as secure monitor,

so it will be still alive, when U-Boot is gone away. Do we really want
this one to go into drivers?

I'd much prefer it if we stopped adding more stuff to arch/arm/mach-* ,
but I think we cannot avoid that in this case, can we ?


I am afraid, we can't avoid.





+/*

+ * Functions which intended to be called from PSCI handlers. These
functions
+ * marked as __secure and are placed in .secure section.
+
*/

+void __secure r8a7790_apmu_power_on(int cpu)
+{
+    int cluster = r8a7790_cluster_id(cpu);
+    u32 apmu_base;
+
+    apmu_base = cluster == 0 ? CA15_APMU_BASE : CA7_APMU_BASE;
+
+    /* Request power on */
+    writel(BIT(r8a7790_core_id(cpu)), apmu_base + WUPCR_OFFS);

wait_for_bit of some sorts ?

probably yes, will re-use

+    /* Wait for APMU to finish */
+    while (readl(apmu_base + WUPCR_OFFS))
+    ;

Can this spin forever ?

I didn't find anything in TRM which describes how long it may take.
Linux also doesn't use timeout.

https://elixir.bootlin.com/linux/v5.0-rc5/source/arch/arm/mach-shmobile/platsmp-apmu.c#L46

Re: [U-Boot] [RFC 1/9] Arm: dts: imx7d-pico: Import Linux pico-pi dts

[Fabio Estevam]

Hi Joris,

On Thu, Jan 31, 2019 at 1:20 PM Joris Offouga  wrote:

> I update the branche on my repo :)
>
> https://github.com/jorisoffouga/u-boot/tree/pico-imx7d/convert_dm
>
> The patches on top of u-boot master

I tested your series and I was able to reproduce the PMIC error.

I tried to debug it and could not fix the error yet. Also tested the
warp7 board, which uses the same PMIC and it has been converted to DM
without issues.

Maybe you could resend this series without the PMIC part for now and
we can work to add it as soon as we figure it out.

Thanks for your work!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] test: call lmb tests vi 'ut lib'

[Simon Goldschmidt]

The unit tests in test/lib/lmb.c are not related to the device tree.
So they should be executed via `ut lib` and not via `ut dm`.

Signed-off-by: Simon Goldschmidt 
---

 test/lib/lmb.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/test/lib/lmb.c b/test/lib/lmb.c
index ec68227bb6..88764293b9 100644
--- a/test/lib/lmb.c
+++ b/test/lib/lmb.c
@@ -5,7 +5,8 @@
 
 #include 
 #include 
-#include 
+#include 
+#include 
 #include 
 
 static int check_lmb(struct unit_test_state *uts, struct lmb *lmb,
@@ -197,7 +198,7 @@ static int lib_test_lmb_simple(struct unit_test_state *uts)
return test_multi_alloc_512mb(uts, 0xE000);
 }
 
-DM_TEST(lib_test_lmb_simple, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+LIB_TEST(lib_test_lmb_simple, 0);
 
 /* Create two memory regions with one reserved region and allocate */
 static int lib_test_lmb_simple_x2(struct unit_test_state *uts)
@@ -213,7 +214,7 @@ static int lib_test_lmb_simple_x2(struct unit_test_state 
*uts)
return test_multi_alloc_512mb_x2(uts, 0xE000, 0x4000);
 }
 
-DM_TEST(lib_test_lmb_simple_x2,  DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+LIB_TEST(lib_test_lmb_simple_x2, 0);
 
 /* Simulate 512 MiB RAM, allocate some blocks that fit/don't fit */
 static int test_bigblock(struct unit_test_state *uts, const phys_addr_t ram)
@@ -280,7 +281,7 @@ static int lib_test_lmb_big(struct unit_test_state *uts)
return test_bigblock(uts, 0xE000);
 }
 
-DM_TEST(lib_test_lmb_big, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+LIB_TEST(lib_test_lmb_big, 0);
 
 /* Simulate 512 MiB RAM, allocate a block without previous reservation */
 static int test_noreserved(struct unit_test_state *uts, const phys_addr_t ram,
@@ -355,7 +356,7 @@ static int lib_test_lmb_noreserved(struct unit_test_state 
*uts)
return test_noreserved(uts, 0xE000, 4, 1);
 }
 
-DM_TEST(lib_test_lmb_noreserved, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+LIB_TEST(lib_test_lmb_noreserved, 0);
 
 static int lib_test_lmb_unaligned_size(struct unit_test_state *uts)
 {
@@ -370,7 +371,7 @@ static int lib_test_lmb_unaligned_size(struct 
unit_test_state *uts)
return test_noreserved(uts, 0xE000, 5, 8);
 }
 
-DM_TEST(lib_test_lmb_unaligned_size, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+LIB_TEST(lib_test_lmb_unaligned_size, 0);
 /*
  * Simulate a RAM that starts at 0 and allocate down to address 0, which must
  * fail as '0' means failure for the lmb_alloc functions.
@@ -413,7 +414,7 @@ static int lib_test_lmb_at_0(struct unit_test_state *uts)
return 0;
 }
 
-DM_TEST(lib_test_lmb_at_0, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+LIB_TEST(lib_test_lmb_at_0, 0);
 
 /* Check that calling lmb_reserve with overlapping regions fails. */
 static int lib_test_lmb_overlapping_reserve(struct unit_test_state *uts)
@@ -451,8 +452,7 @@ static int lib_test_lmb_overlapping_reserve(struct 
unit_test_state *uts)
return 0;
 }
 
-DM_TEST(lib_test_lmb_overlapping_reserve,
-   DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+LIB_TEST(lib_test_lmb_overlapping_reserve, 0);
 
 /*
  * Simulate 512 MiB RAM, reserve 3 blocks, allocate addresses in between.
@@ -582,7 +582,7 @@ static int lib_test_lmb_alloc_addr(struct unit_test_state 
*uts)
return test_alloc_addr(uts, 0xE000);
 }
 
-DM_TEST(lib_test_lmb_alloc_addr, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+LIB_TEST(lib_test_lmb_alloc_addr, 0);
 
 /* Simulate 512 MiB RAM, reserve 3 blocks, check addresses in between */
 static int test_get_unreserved_size(struct unit_test_state *uts,
@@ -653,5 +653,4 @@ static int lib_test_lmb_get_free_size(struct 
unit_test_state *uts)
return test_get_unreserved_size(uts, 0xE000);
 }
 
-DM_TEST(lib_test_lmb_get_free_size,
-   DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+LIB_TEST(lib_test_lmb_get_free_size, 0);
-- 
2.17.1

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

Re: [U-Boot] [PATCH 1/1] test: call hexdump tests via `ut lib`

[Simon Goldschmidt]

Am 11.02.2019 um 18:29 schrieb Heinrich Schuchardt:

The unit tests in test/lib/hexdump.c are not related to the device tree.
So they should be executed via `ut lib` and not via `ut dm`.

Signed-off-by: Heinrich Schuchardt 


Reviewed-by: Simon Goldschmidt 

Excellent idea, I'll send the same for test/lib/lmb.c.

Thanks,
Simon


---
  test/lib/hexdump.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/test/lib/hexdump.c b/test/lib/hexdump.c
index 567b57686a..5dccf43886 100644
--- a/test/lib/hexdump.c
+++ b/test/lib/hexdump.c
@@ -6,7 +6,8 @@
  
  #include 

  #include 
-#include 
+#include 
+#include 
  #include 
  
  static int lib_test_hex_to_bin(struct unit_test_state *uts)

@@ -32,7 +33,7 @@ static int lib_test_hex_to_bin(struct unit_test_state *uts)
return 0;
  }
  
-DM_TEST(lib_test_hex_to_bin, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);

+LIB_TEST(lib_test_hex_to_bin, 0);
  
  static int lib_test_hex2bin(struct unit_test_state *uts)

  {
@@ -62,7 +63,7 @@ static int lib_test_hex2bin(struct unit_test_state *uts)
return 0;
  }
  
-DM_TEST(lib_test_hex2bin, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);

+LIB_TEST(lib_test_hex2bin, 0);
  
  static int lib_test_bin2hex(struct unit_test_state *uts)

  {
@@ -92,4 +93,4 @@ static int lib_test_bin2hex(struct unit_test_state *uts)
return 0;
  }
  
-DM_TEST(lib_test_bin2hex, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);

+LIB_TEST(lib_test_bin2hex, 0);



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

Re: [U-Boot] [PATCH] arm: socfpga: move gen5 SDR driver to DM

[Simon Goldschmidt]

Am 11.02.2019 um 19:38 schrieb Dalon L Westergreen:

On Sat, 2019-02-09 at 11:02 +0100, Marek Vasut wrote:

On 2/8/19 11:51 PM, Dalon L Westergreen wrote:

On Fri, 2019-02-08 at 21:36 +0100, Simon Goldschmidt wrote:


Am Fr., 8. Feb. 2019, 21:28 hat Dalon L Westergreen <
dalon.westergr...@linux.intel.com> geschrieben:

On Thu, 2019-02-07 at 22:23 +0100, Simon Goldschmidt wrote:

...


All you need is to have the h2f bridge enabled during the boot.  We used to
do
this for you if spl found that the FPGA was already configured.  On the FPGA
side, a nios in the ddr controller runs the ddr calibration code.


This is stratix10 you're talking about, isn't it ? I recall S10 has
nios2 hard block to start up the DRAM, but Gen5 and A10 do not have
that, do they ?


S10 and A10 both have a hard nios for ddr callibration, in cv / av for
the soc emif, the A9 performs this functions, but for FPGA only DDR
controllers there is a soft nios included in the FPGA ddr RTL that
does the ddr callibration.  The cv/av code that does this is based
on the soft nios core code that performs this function for fpga ddr
controllers.


OK, thank you for this explanation!

So if I would use an FPGA-based SDRAM controller on cv, would this be 
the same driver (except for the calibration part) with a different base 
address? From reading the description I found, I thought it wouldn't?


Because this is where the discussion had started from Dalon: a 
FPGA-based SDRAM controller should now be possible when my patch is done 
and applied, but I guess it would need a different driver. My patch only 
ensures DM-based UCLASS_RAM drivers are probed.


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

Re: [U-Boot] [PATCH] arm: socfpga: move gen5 SDR driver to DM

[Dalon L Westergreen]

On Sat, 2019-02-09 at 11:02 +0100, Marek Vasut wrote:
> On 2/8/19 11:51 PM, Dalon L Westergreen wrote:
> > On Fri, 2019-02-08 at 21:36 +0100, Simon Goldschmidt wrote:
> > > 
> > > Am Fr., 8. Feb. 2019, 21:28 hat Dalon L Westergreen <
> > > dalon.westergr...@linux.intel.com> geschrieben:
> > > > On Thu, 2019-02-07 at 22:23 +0100, Simon Goldschmidt wrote:
...
> > 
> > All you need is to have the h2f bridge enabled during the boot.  We used to
> > do
> > this for you if spl found that the FPGA was already configured.  On the FPGA
> > side, a nios in the ddr controller runs the ddr calibration code.
> 
> This is stratix10 you're talking about, isn't it ? I recall S10 has
> nios2 hard block to start up the DRAM, but Gen5 and A10 do not have
> that, do they ?
> 
S10 and A10 both have a hard nios for ddr callibration, in cv / av for
the soc emif, the A9 performs this functions, but for FPGA only DDR
controllers there is a soft nios included in the FPGA ddr RTL that
does the ddr callibration.  The cv/av code that does this is based
on the soft nios core code that performs this function for fpga ddr
controllers.

--dalon

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

Re: [U-Boot] [PATCH 1/1] efi_loader: fix EFI entry counting

[Heinrich Schuchardt]

On 2/10/19 1:11 AM, Heinrich Schuchardt wrote:
> `bootefi selftest` fails on qemu-x86_defconfig if efi_selftest() is not
> invoked using EFI_CALL().
> 
> Likewise we call the entry point of EFI payloads with
> EFI_CALL(efi_start_image()).
> 
> entry_count indicates if we are in U-Boot (1) or in EFI payload code (0).
> As we start in U-Boot code the initial value has to be 1.
> 
> Signed-off-by: Heinrich Schuchardt 

Hello Alex,

you just merged this patch into your efi-next tree.

It depends on

efi_loader: use efi_start_image() for bootefi
https://lists.denx.de/pipermail/u-boot/2019-February/358045.html

So, please, either remove the patch from your efi-next queue or put the
"efi_loader: rework loading and starting of images" patch series in
before this patch.

Best regards

Heinrich

> ---
>  cmd/bootefi.c | 2 +-
>  lib/efi_loader/efi_boottime.c | 3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 9d9ccdd31a..3619a20e64 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -445,7 +445,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
> argc, char * const argv[])
>   return CMD_RET_FAILURE;
>  
>   /* Execute the test */
> - r = efi_selftest(_obj->header, );
> + r = EFI_CALL(efi_selftest(_obj->header, ));
>   bootefi_run_finish(image_obj, loaded_image_info);
>   return r != EFI_SUCCESS;
>   } else
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 0b13c79b76..ed0e926646 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -44,7 +44,8 @@ static bool efi_is_direct_boot = true;
>  static volatile void *efi_gd, *app_gd;
>  #endif
>  
> -static int entry_count;
> +/* 1 if inside U-Boot code, 0 if inside EFI payload code */
> +static int entry_count = 1;
>  static int nesting_level;
>  /* GUID of the device tree table */
>  const efi_guid_t efi_guid_fdt = EFI_FDT_GUID;
> 

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

[U-Boot] [PATCH 5/7] k2g: config enable ti phy dp83867 for k2g

[Murali Karicheri]

Enable ti phy driver dp83867 for k2g based boards.

Signed-off-by: Murali Karicheri 
---
 include/configs/k2g_evm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
index 90f9a9922c..9fe5411619 100644
--- a/include/configs/k2g_evm.h
+++ b/include/configs/k2g_evm.h
@@ -98,4 +98,5 @@
 
 #include 
 
+#define CONFIG_PHY_TI
 #endif /* __CONFIG_K2G_EVM_H */
-- 
2.17.0

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

[U-Boot] [PATCH 7/7] ARM: dts: k2g-ice: add dt node for netcp

[Murali Karicheri]

This patch adds dt node for DP83867 phy used on K2G ICE board and
also enable netcp device nodes for the board.

EVM hardware spec recommends to add 0.25 nsec delay in the tx
direction and 2.25 nsec delay in the rx direction for internal
delay in the clock path to be on the safer side.

The board straps RX_DV/RX_CTRL pin of on board DP83867 phy in mode
1. Unfortunately, the phy data manual disallows this. Add
ti,dp83867-rxctrl-strap-quirk in the phy node to allow software to
enable workaround suggested for this incorrect strap setting. This
ensures proper operation of this PHY.

The dts bindings are kept in sync with that from 4.14.y linux
kernel. This required the pinmux device related bindings to be
commented out to allow for compilation.

Signed-off-by: Murali Karicheri 
---
 arch/arm/dts/keystone-k2g-ice.dts | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/dts/keystone-k2g-ice.dts 
b/arch/arm/dts/keystone-k2g-ice.dts
index 698338b93d..b67332fed5 100644
--- a/arch/arm/dts/keystone-k2g-ice.dts
+++ b/arch/arm/dts/keystone-k2g-ice.dts
@@ -7,6 +7,7 @@
 /dts-v1/;
 
 #include "keystone-k2g.dtsi"
+#include 
 
 / {
compatible = "ti,k2g-ice", "ti,k2g", "ti,keystone";
@@ -81,3 +82,37 @@
};
};
 };
+
+ {
+   status = "okay";
+};
+
+_dmas {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   //pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   //pinctrl-0 = <_pins>;
+   status = "okay";
+   ethphy0: ethernet-phy@0 {
+   reg = <0>;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
+   ti,fifo-depth = ;
+   ti,min-output-impedance;
+   ti,dp83867-rxctrl-strap-quirk;
+   };
+};
+
+ {
+   phy-handle = <>;
+   phy-mode = "rgmii-id";
+   status = "okay";
+};
-- 
2.17.0

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

[U-Boot] [PATCH 3/7] net: netcp: add support for phy with rgmii ids

[Murali Karicheri]

Enhance the netcp driver to support phys that can be configured
for internal delay (rgmii-id, rgmii-rxid, rgmii-txid)

Signed-off-by: Murali Karicheri 
---
 drivers/net/ti/keystone_net.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ti/keystone_net.c b/drivers/net/ti/keystone_net.c
index a3ba91cc3f..defc57b29f 100644
--- a/drivers/net/ti/keystone_net.c
+++ b/drivers/net/ti/keystone_net.c
@@ -88,6 +88,7 @@ struct ks2_eth_priv {
struct mii_dev  *mdio_bus;
int phy_addr;
phy_interface_t phy_if;
+   int phy_of_handle;
int sgmii_link_type;
void*mdio_base;
struct rx_buff_desc net_rx_buffs;
@@ -588,6 +589,10 @@ static int ks2_eth_probe(struct udevice *dev)
if (priv->has_mdio) {
priv->phydev = phy_connect(priv->mdio_bus, priv->phy_addr,
   dev, priv->phy_if);
+#ifdef CONFIG_DM_ETH
+   if (priv->phy_of_handle)
+   dev_set_of_offset(priv->phydev->dev, priv->phy_of_handle);
+#endif
phy_config(priv->phydev);
}
 
@@ -679,6 +684,7 @@ static int ks2_eth_parse_slave_interface(int netcp, int 
slave,
int phy;
int dma_count;
u32 dma_channel[8];
+   const char *phy_mode;
 
priv->slave_port = fdtdec_get_int(fdt, slave, "slave-port", -1);
priv->net_rx_buffs.rx_flow = priv->slave_port * 8;
@@ -700,7 +706,9 @@ static int ks2_eth_parse_slave_interface(int netcp, int 
slave,
priv->link_type = fdtdec_get_int(fdt, slave, "link-interface", -1);
 
phy = fdtdec_lookup_phandle(fdt, slave, "phy-handle");
+
if (phy >= 0) {
+   priv->phy_of_handle = phy;
priv->phy_addr = fdtdec_get_int(fdt, phy, "reg", -1);
 
mdio = fdt_parent_offset(fdt, phy);
@@ -717,7 +725,19 @@ static int ks2_eth_parse_slave_interface(int netcp, int 
slave,
priv->sgmii_link_type = SGMII_LINK_MAC_PHY;
priv->has_mdio = true;
} else if (priv->link_type == LINK_TYPE_RGMII_LINK_MAC_PHY) {
-   priv->phy_if = PHY_INTERFACE_MODE_RGMII;
+   phy_mode = fdt_getprop(fdt, slave, "phy-mode", NULL);
+   if (phy_mode) {
+   priv->phy_if = phy_get_interface_by_name(phy_mode);
+   if (priv->phy_if != PHY_INTERFACE_MODE_RGMII &&
+   priv->phy_if != PHY_INTERFACE_MODE_RGMII_ID &&
+   priv->phy_if != PHY_INTERFACE_MODE_RGMII_RXID &&
+   priv->phy_if != PHY_INTERFACE_MODE_RGMII_TXID) {
+   pr_err("invalid phy-mode\n");
+   return -EINVAL;
+   }
+   } else {
+   priv->phy_if = PHY_INTERFACE_MODE_RGMII;
+   }
pdata->phy_interface = priv->phy_if;
priv->has_mdio = true;
}
-- 
2.17.0

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

[U-Boot] [PATCH 7/7] ARM: dts: k2g-ice: add dt node for netcp

[Murali Karicheri]

This patch adds dt node for DP83867 phy used on K2G ICE board and
also enable netcp device nodes for the board.

EVM hardware spec recommends to add 0.25 nsec delay in the tx
direction and 2.25 nsec delay in the rx direction for internal
delay in the clock path to be on the safer side.

The board straps RX_DV/RX_CTRL pin of on board DP83867 phy in mode
1. Unfortunately, the phy data manual disallows this. Add
ti,dp83867-rxctrl-strap-quirk in the phy node to allow software to
enable workaround suggested for this incorrect strap setting. This
ensures proper operation of this PHY.

The dts bindings are kept in sync with that from 4.14.y linux
kernel. This required the pinmux device related bindings to be
commented out to allow for compilation.

Signed-off-by: Murali Karicheri 
---
 arch/arm/dts/keystone-k2g-ice.dts | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/dts/keystone-k2g-ice.dts 
b/arch/arm/dts/keystone-k2g-ice.dts
index 698338b93d..b67332fed5 100644
--- a/arch/arm/dts/keystone-k2g-ice.dts
+++ b/arch/arm/dts/keystone-k2g-ice.dts
@@ -7,6 +7,7 @@
 /dts-v1/;
 
 #include "keystone-k2g.dtsi"
+#include 
 
 / {
compatible = "ti,k2g-ice", "ti,k2g", "ti,keystone";
@@ -81,3 +82,37 @@
};
};
 };
+
+ {
+   status = "okay";
+};
+
+_dmas {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   //pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   //pinctrl-0 = <_pins>;
+   status = "okay";
+   ethphy0: ethernet-phy@0 {
+   reg = <0>;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
+   ti,fifo-depth = ;
+   ti,min-output-impedance;
+   ti,dp83867-rxctrl-strap-quirk;
+   };
+};
+
+ {
+   phy-handle = <>;
+   phy-mode = "rgmii-id";
+   status = "okay";
+};
-- 
2.17.0

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

[U-Boot] [PATCH 0/7] Add netcp networking support on K2G ICE EVM

[Murali Karicheri]

- Resending this as I was not subscribed to u-boot mailing
  list when the initial patch series was sent. Sorry for the
  trouble.

This patch series add networking capability to K2G ICE EVM
based on netcp driver. Networking function has been tested
using the latest master branch from u-boot repo. Following
boot mode has been tested for networking.

Net boot (tftp images over ethernet interface and boot kernel)
  log at https://pastebin.ubuntu.com/p/b3nyCXPhWc/
MMC boot: (load images from boot folder of rootfs and boot kernel)
  log at https://pastebin.ubuntu.com/p/FWycmKd9KB/

Used Linux upstream linux kernel version 4.19.9 for the tests. 

Please review and apply if this looks good.

Thanks

Murali Karicheri (7):
  ARM: k2g-ice: Add pinmux support for rgmii interface
  ARM: k2g-gp-evm: update to rgmii pinmux configuration
  net: netcp: add support for phy with rgmii ids
  ARM: k2g: add a workaround to reset the phy
  k2g: config enable ti phy dp83867 for k2g
  ARM: dts: k2g-evm: remove unused phy-mode property from phy node
  ARM: dts: k2g-ice: add dt node for netcp

 arch/arm/dts/keystone-k2g-evm.dts |  1 -
 arch/arm/dts/keystone-k2g-ice.dts | 35 +
 .../mach-keystone/include/mach/hardware-k2g.h |  3 ++
 arch/arm/mach-keystone/include/mach/mux-k2g.h |  5 ++
 board/ti/ks2_evm/board_k2g.c  | 15 ++
 board/ti/ks2_evm/mux-k2g.h| 51 +--
 drivers/net/ti/keystone_net.c | 22 +++-
 include/configs/k2g_evm.h |  1 +
 8 files changed, 116 insertions(+), 17 deletions(-)

-- 
2.17.0

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

[U-Boot] [PATCH 4/7] ARM: k2g: add a workaround to reset the phy

[Murali Karicheri]

This patch adds a workaround to reset the phy one time during boot
using GPIO0 pin 10 to make sure, the Phy latches the configuration
from the input pins correctly.

Signed-off-by: Murali Karicheri 
---
 .../arm/mach-keystone/include/mach/hardware-k2g.h |  3 +++
 board/ti/ks2_evm/board_k2g.c  | 15 +++
 2 files changed, 18 insertions(+)

diff --git a/arch/arm/mach-keystone/include/mach/hardware-k2g.h 
b/arch/arm/mach-keystone/include/mach/hardware-k2g.h
index 8b902641ec..971c081bb3 100644
--- a/arch/arm/mach-keystone/include/mach/hardware-k2g.h
+++ b/arch/arm/mach-keystone/include/mach/hardware-k2g.h
@@ -69,9 +69,12 @@
 
 #define K2G_GPIO0_BASE 0X02603000
 #define K2G_GPIO1_BASE 0X0260a000
+#define K2G_GPIO0_BANK0_BASE   K2G_GPIO0_BASE + 0x10
 #define K2G_GPIO1_BANK2_BASE   K2G_GPIO1_BASE + 0x38
 #define K2G_GPIO_DIR_OFFSET0x0
+#define K2G_GPIO_OUTDATA_OFFSET0x4
 #define K2G_GPIO_SETDATA_OFFSET0x8
+#define K2G_GPIO_CLRDATA_OFFSET0xC
 
 /* BOOTCFG RESETMUX8 */
 #define KS2_RSTMUX8(KS2_DEVICE_STATE_CTRL_BASE + 0x328)
diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index 39a782e479..6d0fc21c67 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -315,6 +315,21 @@ int embedded_dtb_select(void)
 BIT(9));
setbits_le32(K2G_GPIO1_BANK2_BASE + K2G_GPIO_SETDATA_OFFSET,
 BIT(9));
+   } else if (board_is_k2g_ice()) {
+   /* GBE Phy workaround. For Phy to latch the input
+* configuration, a GPIO reset is asserted at the
+* Phy reset pin to latch configuration correctly after SoC
+* reset. GPIO0 Pin 10 (Ball AA20) is used for this on ICE
+* board. Just do a low to high transition.
+*/
+   clrbits_le32(K2G_GPIO0_BANK0_BASE + K2G_GPIO_DIR_OFFSET,
+BIT(10));
+   setbits_le32(K2G_GPIO0_BANK0_BASE + K2G_GPIO_CLRDATA_OFFSET,
+BIT(10));
+   /* Delay just to get a transition to high */
+   udelay(100);
+   setbits_le32(K2G_GPIO0_BANK0_BASE + K2G_GPIO_SETDATA_OFFSET,
+BIT(10));
}
 
return 0;
-- 
2.17.0

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

[U-Boot] [PATCH 6/7] ARM: dts: k2g-evm: remove unused phy-mode property from phy node

[Murali Karicheri]

This patch removes the unused phy-mode property from the phy dt node. On
K2G, currently link-interface determines if phy is used or not and is
already set to use rgmii. So this is not needed. Besides phy-mode should
be added to slave interface configuration of the cpsw driver, not in the
phy node.

Signed-off-by: Murali Karicheri 
---
 arch/arm/dts/keystone-k2g-evm.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/dts/keystone-k2g-evm.dts 
b/arch/arm/dts/keystone-k2g-evm.dts
index 6c9de25b94..4820c7e50d 100644
--- a/arch/arm/dts/keystone-k2g-evm.dts
+++ b/arch/arm/dts/keystone-k2g-evm.dts
@@ -29,7 +29,6 @@
status = "okay";
ethphy0: ethernet-phy@0 {
reg = <0>;
-   phy-mode = "rgmii-id";
};
 };
 
-- 
2.17.0

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

[U-Boot] [PATCH 5/7] k2g: config enable ti phy dp83867 for k2g

[Murali Karicheri]

Enable ti phy driver dp83867 for k2g based boards.

Signed-off-by: Murali Karicheri 
---
 include/configs/k2g_evm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
index 90f9a9922c..9fe5411619 100644
--- a/include/configs/k2g_evm.h
+++ b/include/configs/k2g_evm.h
@@ -98,4 +98,5 @@
 
 #include 
 
+#define CONFIG_PHY_TI
 #endif /* __CONFIG_K2G_EVM_H */
-- 
2.17.0

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

[U-Boot] [PATCH 1/7] ARM: k2g-ice: Add pinmux support for rgmii interface

[Murali Karicheri]

This add pinmux configuration for rgmii interface so that network
driver can be supported on K2G ICE boards. The pinmux configurations
for this are generated using the pinmux tool at
https://dev.ti.com/pinmux/app.html#/default

As this required some BUFFER_CLASS definitions, same is re-used
from the linux defnitions in include/dt-bindings/pinctrl/keystone.h

Signed-off-by: Murali Karicheri 
---
 arch/arm/mach-keystone/include/mach/mux-k2g.h |  5 +
 board/ti/ks2_evm/mux-k2g.h| 19 +++
 2 files changed, 24 insertions(+)

diff --git a/arch/arm/mach-keystone/include/mach/mux-k2g.h 
b/arch/arm/mach-keystone/include/mach/mux-k2g.h
index 809b72d5bf..67d47f8172 100644
--- a/arch/arm/mach-keystone/include/mach/mux-k2g.h
+++ b/arch/arm/mach-keystone/include/mach/mux-k2g.h
@@ -27,6 +27,11 @@
 #define PIN_PTU(1 << 17) /* pull up */
 #define PIN_PTD(0 << 17) /* pull down */
 
+#define BUFFER_CLASS_B (0 << 19)
+#define BUFFER_CLASS_C (1 << 19)
+#define BUFFER_CLASS_D (2 << 19)
+#define BUFFER_CLASS_E (3 << 19)
+
 #define MODE(m)((m) & 0x7)
 #define MAX_PIN_N  260
 
diff --git a/board/ti/ks2_evm/mux-k2g.h b/board/ti/ks2_evm/mux-k2g.h
index 706fb7e838..8c184a85ae 100644
--- a/board/ti/ks2_evm/mux-k2g.h
+++ b/board/ti/ks2_evm/mux-k2g.h
@@ -346,6 +346,25 @@ struct pin_cfg k2g_ice_evm_pin_cfg[] = {
{ 133,  MODE(0) },  /* SOC_QSPI_D2 */
{ 134,  MODE(0) },  /* SOC_QSPI_D3 */
{ 135,  MODE(0) },  /* SOC_QSPI_CSN0 */
+
+   /* EMAC */
+   { 79,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD1 */
+   { 78,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD2 */
+   { 77,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD3 */
+   { 80,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD0 */
+   { 94,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD0 */
+   { 93,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD1 */
+   { 92,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD2 */
+   { 91,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD3 */
+   { 85,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXC */
+   { 95,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXCTL */
+   { 72,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXC */
+   { 81,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXCTL */
+
+   /* MDIO */
+   { 99,   BUFFER_CLASS_B | PIN_PDIS | MODE(0) },  /* MDIO_CLK */
+   { 98,   BUFFER_CLASS_B | PIN_PDIS | MODE(0) },  /* MDIO_DATA */
+
{ MAX_PIN_N, }
 };
 
-- 
2.17.0

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

[U-Boot] [PATCH 2/7] ARM: k2g-gp-evm: update to rgmii pinmux configuration

[Murali Karicheri]

This patch updates pinmux configuration for K2G GP EVM based on
data generated by the pinmux tool at
https://dev.ti.com/pinmux/app.html#/default

Signed-off-by: Murali Karicheri 
---
 board/ti/ks2_evm/mux-k2g.h | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/board/ti/ks2_evm/mux-k2g.h b/board/ti/ks2_evm/mux-k2g.h
index 8c184a85ae..89c49f9e4f 100644
--- a/board/ti/ks2_evm/mux-k2g.h
+++ b/board/ti/ks2_evm/mux-k2g.h
@@ -125,21 +125,23 @@ struct pin_cfg k2g_evm_pin_cfg[] = {
{ 70,   MODE(0) },  /* SOC_MMC1_SDWP */
{ 71,   MODE(0) },  /* MMC1POW TP124 */
 
-   /* RGMII */
-   { 72,   MODE(1) | PIN_IEN },/* SOC_RGMII_RXCLK */
-   { 77,   MODE(1) | PIN_IEN },/* SOC_RGMII_RXD3 */
-   { 78,   MODE(1) | PIN_IEN },/* SOC_RGMII_RXD2 */
-   { 79,   MODE(1) | PIN_IEN },/* SOC_RGMII_RXD1 */
-   { 80,   MODE(1) | PIN_IEN },/* SOC_RGMII_RXD0 */
-   { 81,   MODE(1) | PIN_IEN },/* SOC_RGMII_RXCTL */
-   { 85,   MODE(1) },  /* SOC_RGMII_TXCLK */
-   { 91,   MODE(1) },  /* SOC_RGMII_TXD3 */
-   { 92,   MODE(1) },  /* SOC_RGMII_TXD2 */
-   { 93,   MODE(1) },  /* SOC_RGMII_TXD1 */
-   { 94,   MODE(1) },  /* SOC_RGMII_TXD0 */
-   { 95,   MODE(1) },  /* SOC_RGMII_TXCTL */
-   { 98,   MODE(0) },  /* SOC_MDIO_DATA */
-   { 99,   MODE(0) },  /* SOC_MDIO_CLK */
+   /* EMAC */
+   { 79,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD1 */
+   { 78,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD2 */
+   { 77,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD3 */
+   { 80,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD0 */
+   { 94,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD0 */
+   { 93,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD1 */
+   { 92,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD2 */
+   { 91,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD3 */
+   { 85,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXC */
+   { 95,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXCTL */
+   { 72,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXC */
+   { 81,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXCTL */
+
+   /* MDIO */
+   { 99,   BUFFER_CLASS_B | PIN_PDIS | MODE(0) },  /* MDIO_CLK */
+   { 98,   BUFFER_CLASS_B | PIN_PDIS | MODE(0) },  /* MDIO_DATA */
 
/* PWM */
{ 73,   MODE(4) },  /* SOC_EHRPWM3A */
-- 
2.17.0

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

[U-Boot] [PATCH 2/7] ARM: k2g-gp-evm: update to rgmii pinmux configuration

[Murali Karicheri]

This patch updates pinmux configuration for K2G GP EVM based on
data generated by the pinmux tool at
https://dev.ti.com/pinmux/app.html#/default

Signed-off-by: Murali Karicheri 
---
 board/ti/ks2_evm/mux-k2g.h | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/board/ti/ks2_evm/mux-k2g.h b/board/ti/ks2_evm/mux-k2g.h
index 8c184a85ae..89c49f9e4f 100644
--- a/board/ti/ks2_evm/mux-k2g.h
+++ b/board/ti/ks2_evm/mux-k2g.h
@@ -125,21 +125,23 @@ struct pin_cfg k2g_evm_pin_cfg[] = {
{ 70,   MODE(0) },  /* SOC_MMC1_SDWP */
{ 71,   MODE(0) },  /* MMC1POW TP124 */
 
-   /* RGMII */
-   { 72,   MODE(1) | PIN_IEN },/* SOC_RGMII_RXCLK */
-   { 77,   MODE(1) | PIN_IEN },/* SOC_RGMII_RXD3 */
-   { 78,   MODE(1) | PIN_IEN },/* SOC_RGMII_RXD2 */
-   { 79,   MODE(1) | PIN_IEN },/* SOC_RGMII_RXD1 */
-   { 80,   MODE(1) | PIN_IEN },/* SOC_RGMII_RXD0 */
-   { 81,   MODE(1) | PIN_IEN },/* SOC_RGMII_RXCTL */
-   { 85,   MODE(1) },  /* SOC_RGMII_TXCLK */
-   { 91,   MODE(1) },  /* SOC_RGMII_TXD3 */
-   { 92,   MODE(1) },  /* SOC_RGMII_TXD2 */
-   { 93,   MODE(1) },  /* SOC_RGMII_TXD1 */
-   { 94,   MODE(1) },  /* SOC_RGMII_TXD0 */
-   { 95,   MODE(1) },  /* SOC_RGMII_TXCTL */
-   { 98,   MODE(0) },  /* SOC_MDIO_DATA */
-   { 99,   MODE(0) },  /* SOC_MDIO_CLK */
+   /* EMAC */
+   { 79,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD1 */
+   { 78,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD2 */
+   { 77,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD3 */
+   { 80,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD0 */
+   { 94,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD0 */
+   { 93,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD1 */
+   { 92,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD2 */
+   { 91,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD3 */
+   { 85,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXC */
+   { 95,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXCTL */
+   { 72,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXC */
+   { 81,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXCTL */
+
+   /* MDIO */
+   { 99,   BUFFER_CLASS_B | PIN_PDIS | MODE(0) },  /* MDIO_CLK */
+   { 98,   BUFFER_CLASS_B | PIN_PDIS | MODE(0) },  /* MDIO_DATA */
 
/* PWM */
{ 73,   MODE(4) },  /* SOC_EHRPWM3A */
-- 
2.17.0

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

[U-Boot] [PATCH 4/7] ARM: k2g: add a workaround to reset the phy

[Murali Karicheri]

This patch adds a workaround to reset the phy one time during boot
using GPIO0 pin 10 to make sure, the Phy latches the configuration
from the input pins correctly.

Signed-off-by: Murali Karicheri 
---
 .../arm/mach-keystone/include/mach/hardware-k2g.h |  3 +++
 board/ti/ks2_evm/board_k2g.c  | 15 +++
 2 files changed, 18 insertions(+)

diff --git a/arch/arm/mach-keystone/include/mach/hardware-k2g.h 
b/arch/arm/mach-keystone/include/mach/hardware-k2g.h
index 8b902641ec..971c081bb3 100644
--- a/arch/arm/mach-keystone/include/mach/hardware-k2g.h
+++ b/arch/arm/mach-keystone/include/mach/hardware-k2g.h
@@ -69,9 +69,12 @@
 
 #define K2G_GPIO0_BASE 0X02603000
 #define K2G_GPIO1_BASE 0X0260a000
+#define K2G_GPIO0_BANK0_BASE   K2G_GPIO0_BASE + 0x10
 #define K2G_GPIO1_BANK2_BASE   K2G_GPIO1_BASE + 0x38
 #define K2G_GPIO_DIR_OFFSET0x0
+#define K2G_GPIO_OUTDATA_OFFSET0x4
 #define K2G_GPIO_SETDATA_OFFSET0x8
+#define K2G_GPIO_CLRDATA_OFFSET0xC
 
 /* BOOTCFG RESETMUX8 */
 #define KS2_RSTMUX8(KS2_DEVICE_STATE_CTRL_BASE + 0x328)
diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index 39a782e479..6d0fc21c67 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -315,6 +315,21 @@ int embedded_dtb_select(void)
 BIT(9));
setbits_le32(K2G_GPIO1_BANK2_BASE + K2G_GPIO_SETDATA_OFFSET,
 BIT(9));
+   } else if (board_is_k2g_ice()) {
+   /* GBE Phy workaround. For Phy to latch the input
+* configuration, a GPIO reset is asserted at the
+* Phy reset pin to latch configuration correctly after SoC
+* reset. GPIO0 Pin 10 (Ball AA20) is used for this on ICE
+* board. Just do a low to high transition.
+*/
+   clrbits_le32(K2G_GPIO0_BANK0_BASE + K2G_GPIO_DIR_OFFSET,
+BIT(10));
+   setbits_le32(K2G_GPIO0_BANK0_BASE + K2G_GPIO_CLRDATA_OFFSET,
+BIT(10));
+   /* Delay just to get a transition to high */
+   udelay(100);
+   setbits_le32(K2G_GPIO0_BANK0_BASE + K2G_GPIO_SETDATA_OFFSET,
+BIT(10));
}
 
return 0;
-- 
2.17.0

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

[U-Boot] [PATCH 6/7] ARM: dts: k2g-evm: remove unused phy-mode property from phy node

[Murali Karicheri]

This patch removes the unused phy-mode property from the phy dt node. On
K2G, currently link-interface determines if phy is used or not and is
already set to use rgmii. So this is not needed. Besides phy-mode should
be added to slave interface configuration of the cpsw driver, not in the
phy node.

Signed-off-by: Murali Karicheri 
---
 arch/arm/dts/keystone-k2g-evm.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/dts/keystone-k2g-evm.dts 
b/arch/arm/dts/keystone-k2g-evm.dts
index 6c9de25b94..4820c7e50d 100644
--- a/arch/arm/dts/keystone-k2g-evm.dts
+++ b/arch/arm/dts/keystone-k2g-evm.dts
@@ -29,7 +29,6 @@
status = "okay";
ethphy0: ethernet-phy@0 {
reg = <0>;
-   phy-mode = "rgmii-id";
};
 };
 
-- 
2.17.0

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

[U-Boot] [PATCH 1/7] ARM: k2g-ice: Add pinmux support for rgmii interface

[Murali Karicheri]

This add pinmux configuration for rgmii interface so that network
driver can be supported on K2G ICE boards. The pinmux configurations
for this are generated using the pinmux tool at
https://dev.ti.com/pinmux/app.html#/default

As this required some BUFFER_CLASS definitions, same is re-used
from the linux defnitions in include/dt-bindings/pinctrl/keystone.h

Signed-off-by: Murali Karicheri 
---
 arch/arm/mach-keystone/include/mach/mux-k2g.h |  5 +
 board/ti/ks2_evm/mux-k2g.h| 19 +++
 2 files changed, 24 insertions(+)

diff --git a/arch/arm/mach-keystone/include/mach/mux-k2g.h 
b/arch/arm/mach-keystone/include/mach/mux-k2g.h
index 809b72d5bf..67d47f8172 100644
--- a/arch/arm/mach-keystone/include/mach/mux-k2g.h
+++ b/arch/arm/mach-keystone/include/mach/mux-k2g.h
@@ -27,6 +27,11 @@
 #define PIN_PTU(1 << 17) /* pull up */
 #define PIN_PTD(0 << 17) /* pull down */
 
+#define BUFFER_CLASS_B (0 << 19)
+#define BUFFER_CLASS_C (1 << 19)
+#define BUFFER_CLASS_D (2 << 19)
+#define BUFFER_CLASS_E (3 << 19)
+
 #define MODE(m)((m) & 0x7)
 #define MAX_PIN_N  260
 
diff --git a/board/ti/ks2_evm/mux-k2g.h b/board/ti/ks2_evm/mux-k2g.h
index 706fb7e838..8c184a85ae 100644
--- a/board/ti/ks2_evm/mux-k2g.h
+++ b/board/ti/ks2_evm/mux-k2g.h
@@ -346,6 +346,25 @@ struct pin_cfg k2g_ice_evm_pin_cfg[] = {
{ 133,  MODE(0) },  /* SOC_QSPI_D2 */
{ 134,  MODE(0) },  /* SOC_QSPI_D3 */
{ 135,  MODE(0) },  /* SOC_QSPI_CSN0 */
+
+   /* EMAC */
+   { 79,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD1 */
+   { 78,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD2 */
+   { 77,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD3 */
+   { 80,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXD0 */
+   { 94,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD0 */
+   { 93,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD1 */
+   { 92,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD2 */
+   { 91,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXD3 */
+   { 85,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXC */
+   { 95,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_TXCTL */
+   { 72,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXC */
+   { 81,   BUFFER_CLASS_D | PIN_PDIS | MODE(1) },  /* RGMII_RXCTL */
+
+   /* MDIO */
+   { 99,   BUFFER_CLASS_B | PIN_PDIS | MODE(0) },  /* MDIO_CLK */
+   { 98,   BUFFER_CLASS_B | PIN_PDIS | MODE(0) },  /* MDIO_DATA */
+
{ MAX_PIN_N, }
 };
 
-- 
2.17.0

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

[U-Boot] [PATCH 0/7] Add netcp networking support on K2G ICE EVM

[Murali Karicheri]

This patch series add networking capability to K2G ICE EVM
based on netcp driver. Networking function has been tested
using the latest master branch from u-boot repo. Following
boot mode has been tested for networking.

Net boot (tftp images over ethernet interface and boot kernel)
  log at https://pastebin.ubuntu.com/p/b3nyCXPhWc/
MMC boot: (load images from boot folder of rootfs and boot kernel)
  log at https://pastebin.ubuntu.com/p/FWycmKd9KB/

Used Linux upstream linux kernel version 4.19.9 for the tests. 

Please review and apply if this looks good.

Thanks

Murali Karicheri (7):
  ARM: k2g-ice: Add pinmux support for rgmii interface
  ARM: k2g-gp-evm: update to rgmii pinmux configuration
  net: netcp: add support for phy with rgmii ids
  ARM: k2g: add a workaround to reset the phy
  k2g: config enable ti phy dp83867 for k2g
  ARM: dts: k2g-evm: remove unused phy-mode property from phy node
  ARM: dts: k2g-ice: add dt node for netcp

 arch/arm/dts/keystone-k2g-evm.dts |  1 -
 arch/arm/dts/keystone-k2g-ice.dts | 35 +
 .../mach-keystone/include/mach/hardware-k2g.h |  3 ++
 arch/arm/mach-keystone/include/mach/mux-k2g.h |  5 ++
 board/ti/ks2_evm/board_k2g.c  | 15 ++
 board/ti/ks2_evm/mux-k2g.h| 51 +--
 drivers/net/ti/keystone_net.c | 22 +++-
 include/configs/k2g_evm.h |  1 +
 8 files changed, 116 insertions(+), 17 deletions(-)

-- 
2.17.0

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