[PATCH 1/2] rockchip: rk3308: allow loading larger kernel Image

[Andy Yan]

When compile the curren mainline linux kernel(Linux 5.5-rc3)
with defconfig, the final Image is 29M, it's much
larger than Linux 5.4.

On the current u-boot side on rk3308, the gap between
kernel and fdt is 25M, the fdt will overwrite kernel
Image, so move ftd to a higher memory to give 34M
gab for them.

Signed-off-by: Andy Yan 
---

 include/configs/rk3308_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/rk3308_common.h b/include/configs/rk3308_common.h
index a67d3d7d1b..bd9ac826f3 100644
--- a/include/configs/rk3308_common.h
+++ b/include/configs/rk3308_common.h
@@ -42,7 +42,7 @@
 #define ENV_MEM_LAYOUT_SETTINGS \
"scriptaddr=0x0050\0" \
"pxefile_addr_r=0x0060\0" \
-   "fdt_addr_r=0x01f0\0" \
+   "fdt_addr_r=0x0280\0" \
"kernel_addr_r=0x0068\0" \
"ramdisk_addr_r=0x0400\0"
 
-- 
2.17.1

[PATCH 2/2] doc: rockchip: Fix reference the wrong defconfig name of ROC-CC-RK3308

[Andy Yan]

The defconfig file for ROC-CC-RK3308 is roc-cc-rk3308_defconfig.

Fixes: 7f08bfb74f04 ("doc: rockchip: Add documentation for rk3308 based
boards")

Signed-off-by: Andy Yan 
---

 doc/README.rockchip | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/README.rockchip b/doc/README.rockchip
index dae4ebc8e4..ffab8ff417 100644
--- a/doc/README.rockchip
+++ b/doc/README.rockchip
@@ -50,7 +50,7 @@ Two RK3036 boards are supported:
 Two RK3308 boards are supported:
 
- EVB RK3308 - use evb-rk3308 configuration
-   - ROC-CC-RK3308 - use roc-rk3308-cc configuration
+   - ROC-CC-RK3308 - use roc-cc-rk3308 configuration
 
 Two RK3328 board are supported:
 
@@ -106,7 +106,7 @@ For example:
- Compile U-Boot
  => cd /path/to/u-boot
  => export BL31=/path/to/rkbin/bin/rk33/rk3308_bl31_v2.22.elf
- => make roc-rk3308-cc_defconfig
+ => make roc-cc-rk3308_defconfig
  => make CROSS_COMPILE=aarch64-linux-gnu- all
  => ./tools/mkimage -n rk3308 -T rksd -d 
/path/to/rkbin/bin/rk33/rk3308_ddr_589MHz_uart2_m0_v1.26.bin idbloader.img
  => cat spl/u-boot-spl.bin  >> idbloader.img
-- 
2.17.1

RE: [PATCH] global_data: remove unused mxc_i2c specific field

[Peng Fan]

> Subject: [PATCH] global_data: remove unused mxc_i2c specific field
> 
> The srdata field is unused since commit 71204e95ce13228 ("i2c: mxc:
> refactor i2c driver and support dm").
> 
> Cc: Peng Fan 
> Signed-off-by: Baruch Siach 

Reviewed-by: Peng Fan 

> ---
>  include/asm-generic/global_data.h | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/include/asm-generic/global_data.h
> b/include/asm-generic/global_data.h
> index 7587ba2ee586..5d027329fe0f 100644
> --- a/include/asm-generic/global_data.h
> +++ b/include/asm-generic/global_data.h
> @@ -89,9 +89,6 @@ typedef struct global_data {  #endif  #if
> defined(CONFIG_SYS_I2C)
>   int cur_i2c_bus;/* current used i2c bus */
> -#endif
> -#ifdef CONFIG_SYS_I2C_MXC
> - void *srdata[10];
>  #endif
>   unsigned int timebase_h;
>   unsigned int timebase_l;
> --
> 2.24.0

Formal upstream support of Cortina Access ARM Based SoCs

[Alex Nemirovsky]

Hi Tom,

Hope you are doing well and enjoying the holiday season.

Cortina Access management has decided that we want to add formal upstream 
support of u-boot 
going forward for our line of SoCs and evaluation boards   Our line of SoC’s 
all begin with the “CA” designation
followed by 4 digits.  i.e. CA. 

We are preparing a phased release based on the current u-boot master and would 
like to contribute
into it.   Our first effort will be to upstream support of an ARMv8 Quad A53 
based SoC and its associated development board. 

From maintenance point of view, I have agreed to be the technical point of 
contact and custodian
for all Cortina Access u-boot support going forward.

Let us know what additional info if any you need from us to get started.

BR,
-Alex

[PATCH] global_data: remove unused mxc_i2c specific field

[Baruch Siach]

The srdata field is unused since commit 71204e95ce13228 ("i2c: mxc:
refactor i2c driver and support dm").

Cc: Peng Fan 
Signed-off-by: Baruch Siach 
---
 include/asm-generic/global_data.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/asm-generic/global_data.h 
b/include/asm-generic/global_data.h
index 7587ba2ee586..5d027329fe0f 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -89,9 +89,6 @@ typedef struct global_data {
 #endif
 #if defined(CONFIG_SYS_I2C)
int cur_i2c_bus;/* current used i2c bus */
-#endif
-#ifdef CONFIG_SYS_I2C_MXC
-   void *srdata[10];
 #endif
unsigned int timebase_h;
unsigned int timebase_l;
-- 
2.24.0

Re: Garbage UART output on RPI 4 with upstream kernel DTB

[Stefan Wahren]

Am 24.12.19 um 13:38 schrieb Matthias Brugger:
>
> On 24/12/2019 12:56, Stefan Wahren wrote:
>> Hi Matthias,
>>
>> Am 23.12.19 um 21:20 schrieb Matthias Brugger:
>>> Hi Stefan,
>>>
>>> On 23/12/2019 19:51, Stefan Wahren wrote:
 Am 20.12.19 um 14:58 schrieb Stefan Wahren:
> Hi,
>
> i tried to run current U-Boot (rpi_4_32b_defconfig) on my RPi 4 with
> bcm2711-rpi-4-b.dtb from the upstream kernel. Unfortunately i only see
> garbage on the debug UART (pin 14 & 15). Using the DTB from the
> downstream kernel has a proper UART output. The config.txt contains
> debug_uart=1
>
> I compared both and identified an offending Linux commit:
> ARM: dts: bcm283x: Remove brcm,bcm2835-pl011 compatible
>
> Unfortunately reverting this patch still doesn't fix the issue. Any ideas?
 After hours of playing with the DTB, i finally found the reason why the
 upstream kernel DTB doesn't work with U-Boot on RPI 4. The DTS must be
 compiled with flag "-@".

 It isn't clear to me, why this is necessary but it would be nice to make
 U-Boot work without this.

>>> Can you provide the exact command you are using?
>> i didn't call dtc directly via command line. I just added this Makefile
>> hack [1] to the Linux upstream tree. This will add a __symbols__ section
>> to the DTB which is required for overlays. You can verify this with dtdiff.
>>
>> Since the upstream kernel boots without the __symbols__ section, i think
>> this garbage output issue could be fixed in u-boot.
>>
> Little by little I grasp what you are doing. So you compile the DTB in the
> kernel, then pass the blob to u-boot and add it with OF_EMBED? Is that 
> correct?

I use a recent Raspbian image, replace the bcm2711 DTB with the upstream
kernel ones (yes build with make dtbs) and kernel7.img with u-boot.bin
(renamed all the other kernel binaries to make sure kernel7.img is
really used). Also use a boot.scr from here, but not sure this have an
influence [1]. I used the rpi_4_32b_defconfig without any modifications
like OF_EMBED. I assume u-boot uses the FDT image passed by the
Raspberry Pi bootloader.

[1] - https://andrei.gherzan.ro/linux/uboot-on-rpi/

>
> Regards,
> Matthias

Re: [PATCH 2/3] efi: qemu: arm64: Add efi_rng_protocol implementation for the platform

[Sughosh Ganu]

On Wed, 25 Dec 2019 at 13:51, Heinrich Schuchardt 
wrote:

> On 12/25/19 7:21 AM, Sughosh Ganu wrote:
> > hi Heinrich,
> > Thanks for the review.
> >
> > On Tue, 24 Dec 2019 at 22:35, Heinrich Schuchardt  > > wrote:
> >
> > On 12/24/19 4:54 PM, Sughosh Ganu wrote:
> >  > Add support for the EFI_RNG_PROTOCOL routines for the qemu arm64
> >  > platform. EFI_RNG_PROTOCOL is an uefi boottime service which is
> >  > invoked by the efi stub in the kernel for getting random seed for
> >  > kaslr.
> >  >
> >  > The routines are platform specific, and use the virtio-rng device
> on
> >  > the platform to get random data.
> >  >
> >  > The feature can be enabled through the following config
> >  > CONFIG_EFI_RNG_PROTOCOL
> >  >
> >  > Signed-off-by: Sughosh Ganu  > >
> >  > ---
> >  >   board/emulation/qemu-arm/qemu-arm.c | 50
> +
> >  >   include/efi_rng.h   | 34 +
> >  >   lib/efi_loader/Kconfig  |  8 
> >  >   lib/efi_loader/Makefile |  1 +
> >  >   lib/efi_loader/efi_rng.c| 74
> > +
> >  >   5 files changed, 167 insertions(+)
> >  >   create mode 100644 include/efi_rng.h
> >  >   create mode 100644 lib/efi_loader/efi_rng.c
> >  >
> >  > diff --git a/board/emulation/qemu-arm/qemu-arm.c
> > b/board/emulation/qemu-arm/qemu-arm.c
> >  > index e1f4709..3176421 100644
> >  > --- a/board/emulation/qemu-arm/qemu-arm.c
> >  > +++ b/board/emulation/qemu-arm/qemu-arm.c
> >  > @@ -91,3 +91,53 @@ void *board_fdt_blob_setup(void)
> >  >   /* QEMU loads a generated DTB for us at the start of RAM. */
> >  >   return (void *)CONFIG_SYS_SDRAM_BASE;
> >  >   }
> >  > +
> >  > +#if defined(CONFIG_EFI_RNG_PROTOCOL)
> >  > +#include 
> >  > +#include 
> >  > +
> >  > +#include 
> >  > +
> >  > +#define VIRTIO_RNG_PCI_DEVICE"virtio-pci.l#0"
> >  > +
> >  > +void platform_rng_getinfo(efi_rng_algorithm *rng_algo)
> >
> > Thanks for working on the implementation of the EFI_RNG_PROTOCOL.
> >
> > Please, put an underscore after each word: platform_rng_get_info
> >
> >
> > Ok.
> >
> >
> >  > +{
> >  > + const efi_guid_t rng_raw_guid = EFI_RNG_ALGORITHM_RAW;
> >  > +
> >  > + guidcpy(rng_algo, &rng_raw_guid);
> >
> > This function should be in efi_rng.c if it is needed at all.
> >
> >
> > Is the rng algorithm supported not platform specific. I believe
> > different platforms might use different algorithms for providing the
> > random seed.
>
> Sure you may later want develop code implementing one of the other RNG
> algorithms and than use a Kconfig setting to enable building the code
> and calling it from the EFI_RNG_PROTOCOL driver. But this code will not
> depend on whether you are using a specific board. A good place to put
> the algorithms would be in lib/.
>

Ok. So I guess what you are suggesting is returning the algorithm in
get_info based on what is enabled through Kconfig.

-sughosh

Re: [PATCH v4 1/8] dm: rng: Add random number generator(rng) uclass

[Sughosh Ganu]

On Wed, 25 Dec 2019 at 06:41, Heinrich Schuchardt 
wrote:

> On 12/17/19 12:51 PM, Sughosh Ganu wrote:
> > Add a uclass for reading a random number seed from a random number
> > generator device.
> >
> > Signed-off-by: Sughosh Ganu 
> > Reviewed-by: Patrice Chotard 
> > ---
> > Changes since V3:
> >   Handle review comments from Patrick Delaunay.
> >
> >   drivers/Kconfig  |  2 ++
> >   drivers/Makefile |  1 +
> >   drivers/rng/Kconfig  |  7 +++
> >   drivers/rng/Makefile |  6 ++
> >   drivers/rng/rng-uclass.c | 23 +++
> >   include/dm/uclass-id.h   |  1 +
> >   include/rng.h| 32 
> >   7 files changed, 72 insertions(+)
> >   create mode 100644 drivers/rng/Kconfig
> >   create mode 100644 drivers/rng/Makefile
> >   create mode 100644 drivers/rng/rng-uclass.c
> >   create mode 100644 include/rng.h
> >
> > diff --git a/drivers/Kconfig b/drivers/Kconfig
> > index 9d99ce0..e34a227 100644
> > --- a/drivers/Kconfig
> > +++ b/drivers/Kconfig
> > @@ -90,6 +90,8 @@ source "drivers/remoteproc/Kconfig"
> >
> >   source "drivers/reset/Kconfig"
> >
> > +source "drivers/rng/Kconfig"
> > +
> >   source "drivers/rtc/Kconfig"
> >
> >   source "drivers/scsi/Kconfig"
> > diff --git a/drivers/Makefile b/drivers/Makefile
> > index e977f19..6c619b1 100644
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -115,4 +115,5 @@ obj-$(CONFIG_W1_EEPROM) += w1-eeprom/
> >
> >   obj-$(CONFIG_MACH_PIC32) += ddr/microchip/
> >   obj-$(CONFIG_DM_HWSPINLOCK) += hwspinlock/
> > +obj-$(CONFIG_DM_RNG) += rng/
> >   endif
> > diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
> > new file mode 100644
> > index 000..dd44cc0
> > --- /dev/null
> > +++ b/drivers/rng/Kconfig
> > @@ -0,0 +1,7 @@
> > +config DM_RNG
> > + bool "Driver support for Random Number Generator devices"
> > + depends on DM
> > + help
> > +   Enable driver model for random number generator(rng) devices.
> > +   This interface is used to initialise the rng device and to
> > +   read the random seed from the device.
> > diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
> > new file mode 100644
> > index 000..311705b
> > --- /dev/null
> > +++ b/drivers/rng/Makefile
> > @@ -0,0 +1,6 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# Copyright (c) 2019, Linaro Limited
> > +#
> > +
> > +obj-$(CONFIG_DM_RNG) += rng-uclass.o
> > diff --git a/drivers/rng/rng-uclass.c b/drivers/rng/rng-uclass.c
> > new file mode 100644
> > index 000..b6af3b8
> > --- /dev/null
> > +++ b/drivers/rng/rng-uclass.c
> > @@ -0,0 +1,23 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2019, Linaro Limited
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +int dm_rng_read(struct udevice *dev, void *buffer, size_t size)
> > +{
> > + const struct dm_rng_ops *ops = device_get_ops(dev);
> > +
> > + if (!ops->read)
> > + return -ENOSYS;
> > +
> > + return ops->read(dev, buffer, size);
> > +}
> > +
> > +UCLASS_DRIVER(rng) = {
> > + .name = "rng",
> > + .id = UCLASS_RNG,
> > +};
> > diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> > index 0c563d8..192202d 100644
> > --- a/include/dm/uclass-id.h
> > +++ b/include/dm/uclass-id.h
> > @@ -86,6 +86,7 @@ enum uclass_id {
> >   UCLASS_REGULATOR,   /* Regulator device */
> >   UCLASS_REMOTEPROC,  /* Remote Processor device */
> >   UCLASS_RESET,   /* Reset controller device */
> > + UCLASS_RNG, /* Random Number Generator */
> >   UCLASS_RTC, /* Real time clock device */
> >   UCLASS_SCSI,/* SCSI device */
> >   UCLASS_SERIAL,  /* Serial UART */
> > diff --git a/include/rng.h b/include/rng.h
> > new file mode 100644
> > index 000..80891fc
> > --- /dev/null
> > +++ b/include/rng.h
> > @@ -0,0 +1,32 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2019, Linaro Limited
> > + */
> > +
> > +#if !defined _RNG_H_
> > +#define _RNG_H_
> > +
> > +#include 
> > +
> > +/**
> > + * dm_rng_read() - read a random number seed from the rng device
> > + * @buffer:  input buffer to put the read random seed into
> > + * @size:number of bytes of random seed read
> > + * @return 0 if OK, -ve on error
>
> Please, stick to the Spinx syntax (Return:). See
>
> https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#function-documentation


Ok.


>
>
> The Linux kernel code uses the return value to return the number of
> bytes retrieved.
>
> Please, provide as description here of what will happen if the RNG
> device blocks.
>

I guess that would be device specific behavior. For example, in the
stm32mp1 rng driver, readl_poll_timeout is used to check for random data
availability, failing which, we return an error.


> > + *
> > + */
> > +int dm_rng_read(struct udevice *dev, void *buffer, size_t size);
>
> We have different places w

Re: [PATCH 3/3] efi_rng_protocol: Install the efi_rng_protocol on the root node

[Sughosh Ganu]

On Wed, 25 Dec 2019 at 13:57, Heinrich Schuchardt 
wrote:

> On 12/24/19 4:54 PM, Sughosh Ganu wrote:
> > Install the EFI_RNG_PROTOCOL implementation for it's subsequent use by
> > the kernel for features like kaslr.
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> >   include/efi_loader.h   | 4 
> >   lib/efi_loader/efi_rng.c   | 2 ++
> >   lib/efi_loader/efi_root_node.c | 4 
> >   3 files changed, 10 insertions(+)
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index bec7873..71996ec 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -130,6 +130,7 @@ extern const struct efi_hii_config_routing_protocol
> efi_hii_config_routing;
> >   extern const struct efi_hii_config_access_protocol
> efi_hii_config_access;
> >   extern const struct efi_hii_database_protocol efi_hii_database;
> >   extern const struct efi_hii_string_protocol efi_hii_string;
> > +extern const struct efi_rng_protocol efi_rng_protocol_ops;
>
> Could we, please, call this variable efi_rng_protocol.
>
> Otherwise
>
> Reviewed-by: Heinrich Schuchardt 
>

Will change the name of the symbol as suggested. Thanks.

-sughosh

Re: [PATCH 01/12] i2c: designware_i2c: Add more registers

[pt]

>
> > -Original Message-
> > From: Simon Glass 
> > Sent: Sunday, December 22, 2019 12:15 AM
> > To: U-Boot Mailing List 
> > Cc: Jun Chen ; Heiko Schocher ; Tan,
> > Ley Foon ; Simon Glass 
> > Subject: [PATCH 01/12] i2c: designware_i2c: Add more registers
> >
> > Some versions of this peripherals previde more control of the bus
> behaviour.
> > Add definitions for these registers.
> >
> > Signed-off-by: Simon Glass 
> Typo for 'previde' in commit message.
>
> Reviewed-by: Ley Foon Tan 
>

Reviewed-by: Jun Chen 

>
> > ---
> >
> >  drivers/i2c/designware_i2c.h | 13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/i2c/designware_i2c.h b/drivers/i2c/designware_i2c.h
> > index 48766d0806..d359c8c3f8 100644
> > --- a/drivers/i2c/designware_i2c.h
> > +++ b/drivers/i2c/designware_i2c.h
> > @@ -43,8 +43,19 @@ struct i2c_regs {
> >   u32 ic_rxflr;   /* 0x78 */
> >   u32 ic_sda_hold;/* 0x7c */
> >   u32 ic_tx_abrt_source;  /* 0x80 */
> > - u8 res1[0x18];  /* 0x84 */
> > + u32 slv_data_nak_only;
> > + u32 dma_cr;
> > + u32 dma_tdlr;
> > + u32 dma_rdlr;
> > + u32 sda_setup;
> > + u32 ack_general_call;
> >   u32 ic_enable_status;   /* 0x9c */
> > + u32 fs_spklen;
> > + u32 hs_spklen;
> > + u32 clr_restart_det;
> > + u32 comp_param1;
> > + u32 comp_version;
> > + u32 comp_type;
> >  };
> >
> >  #if !defined(IC_CLK)
> > --
> > 2.24.1.735.g03f4e72817-goog
>
>

I change chip main of the pico-imx7D SOM module. Now I need put u-boot.imx(bin) using imx_uart

[Neuber Sousa]

Hi,

https://community.nxp.com/thread/520887

https://forum.digikey.com/t/re-pico-pi-imx7-and-siging-in-um/2537/208
*(Please look at my last 10 posts.) *

I have these issues above. When I tried theses commands:

.*/imx_uart* /dev/ttyUSB0 mx7_usb_work.conf u-boot.imx
&
*imx_usb u-boot.imx* (of course, conform github, imx_usb wouldn’t work
because the SOM is dead)

How can I put u-boot.imx in pico-imx7d SOM module/baseboard  with new main
chip (MCIMX7D7DVM10SC)

Re: [PATCH 1/3] net: Add support for Broadcom GENETv5 Ethernet controller

[Sascha Dewald]

thank you :-)

@Andre:
you said it before.

Are any other cases i could test ? don't worry, one of three boards i
could damage ! (but it's better if not ... ;-))

Happy days, people - for all of you :-)

and thank you again

Am Mo., 23. Dez. 2019 um 23:24 Uhr schrieb André Przywara
:
>
> On 23/12/2019 18:42, Stefan Wahren wrote:
>
> Hi Stefan,
>
> > Am 20.12.19 um 20:29 schrieb Stefan Wahren:
> >> Hi Andre,
> >>
> >> Am 18.12.19 um 12:59 schrieb Andre Przywara:
> >>> From: Amit Singh Tomar 
> >>>
> >>> The Broadcom GENET Ethernet MACs are used in several MIPS based SoCs
> >>> and in the Broadcom 2711/2838 SoC used on the Raspberry Pi 4.
> >>> There is no publicly available documentation, so this driver is based
> >>> on the Linux driver. Compared to that the queue management is
> >>> drastically simplified, also we only support version 5 of the IP and
> >>> RGMII connections between MAC and PHY, as used on the RPi4.
> >>>
> >>> Signed-off-by: Amit Singh Tomar 
> >>> Reviewed-by: Andre Przywara 
> >>> [Andre: heavy cleanup and a few fixes]
> >>> Signed-off-by: Andre Przywara 
> >>> ---
> >>>  drivers/net/Kconfig|   7 +
> >>>  drivers/net/Makefile   |   1 +
> >>>  drivers/net/bcmgenet.c | 702 +
> >>>  3 files changed, 710 insertions(+)
> >>>  create mode 100644 drivers/net/bcmgenet.c
> >>>
> >> ...
> >>> +
> >>> +/* We only support RGMII (as used on the RPi4). */
> >>> +static int bcmgenet_interface_set(struct bcmgenet_eth_priv *priv)
> >>> +{
> >>> +   phy_interface_t phy_mode = priv->interface;
> >>> +
> >>> +   switch (phy_mode) {
> >>> +   case PHY_INTERFACE_MODE_RGMII:
> >>> +   writel(PORT_MODE_EXT_GPHY, priv->mac_reg + SYS_PORT_CTRL);
> >>> +   break;
> >> This doesn't match the current Linux upstream kernel / DTS. We consider
> >> the PHY mode in the downstream DTS as wrong. It should be
> >> PHY_INTERFACE_MODE_RGMII_RXID. So please add this to keep compatibility
> >> to the upstream devicetree.
> >>
> >> Please following this series [1] for more information.
> >>
> >> Thank you a lot for this work
> >>
> >> Stefan
> >>
> >> [1] - https://marc.info/?l=linux-netdev&m=157350191805462&w=2
> >
> > Except of this, i noticed another issue with current u-boot. It
> > complains about misaligned access:
>
> Thanks for the report, and yeah: this is one of the things I wanted to
> fix still. But that only happens with the 32-bit build, right?
> The issue goes a bit deeper than it seems at the first glance.
> Can you please try this patch?
> https://lists.denx.de/pipermail/u-boot/2019-December/394174.html
>
> And feel free to join the discussion there ;-)
>
> Cheers,
> Andre
>
> >
> > U-Boot 2020.01-rc5-7-g5111518-dirty (Dec 23 2019 - 19:25:49 +0100)
> >
> > DRAM:  948 MiB
> > RPI 4 Model B (0xc03112)
> > MMC:   sdhci@7e30: 0, emmc2@7e34: 1
> > Loading Environment from FAT... Card did not respond to voltage select!
> > In:serial
> > Out:   serial
> > Err:   serial
> > Net:   eth0: ethernet@7d58
> > Hit any key to stop autoboot:  0
> > Card did not respond to voltage select!
> > switch to partitions #0, OK
> > mmc1 is current device
> > Scanning mmc 1:1...
> > Found U-Boot script /boot.scr
> > 213 bytes read in 73 ms (2 KiB/s)
> > ## Executing script at 0240
> > Card did not respond to voltage select!
> > Wrong Image Format for bootm command
> > ERROR: can't get kernel image!
> > SCRIPT FAILED: continuing...
> > 30395 bytes read in 53 ms (559.6 KiB/s)
> > ethernet@7d58 Waiting for PHY auto negotiation to complete.. done
> > BOOTP broadcast 1
> > CACHE: Misaligned operation at range [3b3ed1c0, 3b3ed316]
> > CACHE: Misaligned operation at range [3b3ed1c0, 3b3ed316]
> > DHCP client bound to address 192.168.1.171 (15 ms)
> > *** Warning: no boot file name; using 'C0A801AB.img'
> > Using ethernet@7d58 device
> > TFTP from server 192.168.1.1; our IP address is 192.168.1.171
> > Filename 'C0A801AB.img'.
> > Load address: 0x20
> > Loading: CACHE: Misaligned operation at range [3b3ec640, 3b3ec66a]
> >
>

[PATCH] [ARM] arch/arm/Kconfig: typo/grammar/punctuation fixes

[Robert P. J. Day]

Various (mostly minor) spelling, grammar and punctuation tweaks for
arch/arm/Kconfig.

Signed-off-by: Robert P. J. Day 

---

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f9dab073ea..36c9c2fecd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -17,7 +17,7 @@ config POSITION_INDEPENDENT
  be loaded to and run from that address. This option lifts that
  restriction, thus allowing the code to be loaded to and executed
  from almost any address. This logic relies on the relocation
- information that is embedded into the binary to support U-Boot
+ information that is embedded in the binary to support U-Boot
  relocating itself to the top-of-RAM later during execution.

 config INIT_SP_RELATIVE
@@ -26,7 +26,7 @@ config INIT_SP_RELATIVE
  U-Boot typically uses a hard-coded value for the stack pointer
  before relocation. Enable this option to instead calculate the
  initial SP at run-time. This is useful to avoid hard-coding addresses
- into U-Boot, so that can be loaded and executed at arbitrary
+ into U-Boot, so that it can be loaded and executed at arbitrary
  addresses and thus avoid using arbitrary addresses at runtime.

  If this option is enabled, the early stack pointer is set to
@@ -57,7 +57,7 @@ config LNX_KRNL_IMG_TEXT_OFFSET_BASE
hex
help
  The value subtracted from CONFIG_SYS_TEXT_BASE to calculate the
- TEXT_OFFSET value written in to the Linux kernel image header.
+ TEXT_OFFSET value written to the Linux kernel image header.
 endif
 endif

@@ -121,7 +121,7 @@ config SYS_ARM_MMU
select SYS_ARM_CACHE_CP15
help
  Select if you want MMU-based virtualised addressing space
- support by paged memory management.
+ support via paged memory management.

 config SYS_ARM_MPU
bool 'Use the ARM v7 PMSA Compliant MPU'
@@ -136,8 +136,8 @@ config SYS_ARM_MPU
 # startup. Note that in general these options force the workarounds to be
 # applied; no CPU-type/version detection exists, unlike the similar options in
 # the Linux kernel. Do not set these options unless they apply!  Also note that
-# the following can be machine specific errata. These do have ability to
-# provide rudimentary version and machine specific checks, but expect no
+# the following can be machine-specific errata. These do have ability to
+# provide rudimentary version and machine-specific checks, but expect no
 # product checks:
 # CONFIG_ARM_ERRATA_430973
 # CONFIG_ARM_ERRATA_454179
@@ -332,7 +332,7 @@ config SYS_CACHELINE_SIZE
 config ARCH_CPU_INIT
bool "Enable ARCH_CPU_INIT"
help
- Some architectures require a call to arch_cpu_init()
+ Some architectures require a call to arch_cpu_init().
  Say Y here to enable it

 config SYS_ARCH_TIMER
@@ -342,7 +342,7 @@ config SYS_ARCH_TIMER
help
  The ARM Generic Timer (aka arch-timer) provides an architected
  interface to a timer source on an SoC.
- It is mandantory for ARMv8 implementation and widely available
+ It is mandatory for ARMv8 implementation and widely available
  on ARMv7 systems.

 config ARM_SMCCC
@@ -385,7 +385,7 @@ config TPL_SYS_THUMB_BUILD
default y if SYS_THUMB_BUILD
depends on TPL && !ARM64
help
-  Use this flag to build SPL using the Thumb instruction set for
+  Use this flag to build TPL using the Thumb instruction set for
   ARM architectures. Thumb instruction set provides better code
   density. For ARM architectures that support Thumb2 this flag will
   result in Thumb2 code generated by GCC.
@@ -394,7 +394,7 @@ config TPL_SYS_THUMB_BUILD
 config SYS_L2CACHE_OFF
bool "L2cache off"
help
- If SoC does not support L2CACHE or one do not want to enable
+ If SoC does not support L2CACHE or one does not want to enable
  L2CACHE, choose this option.

 config ENABLE_ARM_SOC_BOOT0_HOOK
@@ -414,7 +414,7 @@ config USE_ARCH_MEMCPY
depends on !ARM64
help
  Enable the generation of an optimized version of memcpy.
- Such implementation may be faster under some conditions
+ Such an implementation may be faster under some conditions
  but may increase the binary size.

 config SPL_USE_ARCH_MEMCPY
@@ -423,7 +423,7 @@ config SPL_USE_ARCH_MEMCPY
depends on !ARM64 && SPL
help
  Enable the generation of an optimized version of memcpy.
- Such implementation may be faster under some conditions
+ Such an implementation may be faster under some conditions
  but may increase the binary size.

 config TPL_USE_ARCH_MEMCPY
@@ -432,7 +432,7 @@ config TPL_USE_ARCH_MEMCPY
depends on !ARM64 && TPL
help
  Enable the generation of an optimized version of memcpy.
- Such implementation may be f

Re: [PATCH 1/1] virtio: fix typo devicd

[Bin Meng]

On Tue, Dec 24, 2019 at 7:21 PM Heinrich Schuchardt  wrote:
>
> %s/devicd/device
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/virtio/virtio_mmio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 

proper way to build [html]docs these days?

[Robert P. J. Day]

  just tried to build docs on a fully-updated fedora 31 system, and
got:

$ make htmldocs
  SPHINX  htmldocs --> file:///home/rpjday/uboot/git/doc/output
make[2]: Nothing to be done for 'html'.
Running Sphinx v2.1.2

Extension error:
Could not import extension kerneldoc (exception: cannot import name
'AutodocReporter' from 'sphinx.ext.autodoc' (unknown location))
make[1]: *** [doc/Makefile:68: htmldocs] Error 2
make: *** [Makefile:1984: htmldocs] Error 2
$

  i don't know enough about sphinx to know what to do with that
diagnostic -- what is the current way to build u-boot docs?

rday

Re: [PATCH 3/3] efi_rng_protocol: Install the efi_rng_protocol on the root node

[Heinrich Schuchardt]

On 12/24/19 4:54 PM, Sughosh Ganu wrote:

Install the EFI_RNG_PROTOCOL implementation for it's subsequent use by
the kernel for features like kaslr.

Signed-off-by: Sughosh Ganu 
---
  include/efi_loader.h   | 4 
  lib/efi_loader/efi_rng.c   | 2 ++
  lib/efi_loader/efi_root_node.c | 4 
  3 files changed, 10 insertions(+)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index bec7873..71996ec 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -130,6 +130,7 @@ extern const struct efi_hii_config_routing_protocol 
efi_hii_config_routing;
  extern const struct efi_hii_config_access_protocol efi_hii_config_access;
  extern const struct efi_hii_database_protocol efi_hii_database;
  extern const struct efi_hii_string_protocol efi_hii_string;
+extern const struct efi_rng_protocol efi_rng_protocol_ops;


Could we, please, call this variable efi_rng_protocol.

Otherwise

Reviewed-by: Heinrich Schuchardt 



  uint16_t *efi_dp_str(struct efi_device_path *dp);

@@ -175,6 +176,9 @@ extern const efi_guid_t efi_guid_hii_config_access_protocol;
  extern const efi_guid_t efi_guid_hii_database_protocol;
  extern const efi_guid_t efi_guid_hii_string_protocol;

+/* GUID of RNG protocol */
+extern const efi_guid_t efi_guid_rng_protocol;
+
  extern unsigned int __efi_runtime_start, __efi_runtime_stop;
  extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;

diff --git a/lib/efi_loader/efi_rng.c b/lib/efi_loader/efi_rng.c
index 8456592..80c8fc9 100644
--- a/lib/efi_loader/efi_rng.c
+++ b/lib/efi_loader/efi_rng.c
@@ -11,6 +11,8 @@

  DECLARE_GLOBAL_DATA_PTR;

+const efi_guid_t efi_guid_rng_protocol = EFI_RNG_PROTOCOL_GUID;
+
  static efi_status_t EFIAPI rng_getinfo(struct efi_rng_protocol *this,
efi_uintn_t *rng_algo_size,
efi_rng_algorithm *rng_algo)
diff --git a/lib/efi_loader/efi_root_node.c b/lib/efi_loader/efi_root_node.c
index f68b0fd..3d937ce 100644
--- a/lib/efi_loader/efi_root_node.c
+++ b/lib/efi_loader/efi_root_node.c
@@ -81,6 +81,10 @@ efi_status_t efi_root_node_register(void)
 &efi_guid_hii_config_routing_protocol,
 (void *)&efi_hii_config_routing,
  #endif
+#if CONFIG_IS_ENABLED(EFI_RNG_PROTOCOL)
+&efi_guid_rng_protocol,
+(void *)&efi_rng_protocol_ops,
+#endif
 NULL));
efi_root->type = EFI_OBJECT_TYPE_U_BOOT_FIRMWARE;
return ret;

Re: [PATCH 2/3] efi: qemu: arm64: Add efi_rng_protocol implementation for the platform

[Heinrich Schuchardt]

On 12/25/19 7:21 AM, Sughosh Ganu wrote:

hi Heinrich,
Thanks for the review.

On Tue, 24 Dec 2019 at 22:35, Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:

On 12/24/19 4:54 PM, Sughosh Ganu wrote:
 > Add support for the EFI_RNG_PROTOCOL routines for the qemu arm64
 > platform. EFI_RNG_PROTOCOL is an uefi boottime service which is
 > invoked by the efi stub in the kernel for getting random seed for
 > kaslr.
 >
 > The routines are platform specific, and use the virtio-rng device on
 > the platform to get random data.
 >
 > The feature can be enabled through the following config
 > CONFIG_EFI_RNG_PROTOCOL
 >
 > Signed-off-by: Sughosh Ganu mailto:sughosh.g...@linaro.org>>
 > ---
 >   board/emulation/qemu-arm/qemu-arm.c | 50 +
 >   include/efi_rng.h                   | 34 +
 >   lib/efi_loader/Kconfig              |  8 
 >   lib/efi_loader/Makefile             |  1 +
 >   lib/efi_loader/efi_rng.c            | 74
+
 >   5 files changed, 167 insertions(+)
 >   create mode 100644 include/efi_rng.h
 >   create mode 100644 lib/efi_loader/efi_rng.c
 >
 > diff --git a/board/emulation/qemu-arm/qemu-arm.c
b/board/emulation/qemu-arm/qemu-arm.c
 > index e1f4709..3176421 100644
 > --- a/board/emulation/qemu-arm/qemu-arm.c
 > +++ b/board/emulation/qemu-arm/qemu-arm.c
 > @@ -91,3 +91,53 @@ void *board_fdt_blob_setup(void)
 >       /* QEMU loads a generated DTB for us at the start of RAM. */
 >       return (void *)CONFIG_SYS_SDRAM_BASE;
 >   }
 > +
 > +#if defined(CONFIG_EFI_RNG_PROTOCOL)
 > +#include 
 > +#include 
 > +
 > +#include 
 > +
 > +#define VIRTIO_RNG_PCI_DEVICE        "virtio-pci.l#0"
 > +
 > +void platform_rng_getinfo(efi_rng_algorithm *rng_algo)

Thanks for working on the implementation of the EFI_RNG_PROTOCOL.

Please, put an underscore after each word: platform_rng_get_info


Ok.


 > +{
 > +     const efi_guid_t rng_raw_guid = EFI_RNG_ALGORITHM_RAW;
 > +
 > +     guidcpy(rng_algo, &rng_raw_guid);

This function should be in efi_rng.c if it is needed at all.


Is the rng algorithm supported not platform specific. I believe
different platforms might use different algorithms for providing the
random seed.


Sure you may later want develop code implementing one of the other RNG
algorithms and than use a Kconfig setting to enable building the code
and calling it from the EFI_RNG_PROTOCOL driver. But this code will not
depend on whether you are using a specific board. A good place to put
the algorithms would be in lib/.

Have a look at EDK II's
SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.c. That code does not
depend on anything from https://github.com/tianocore/edk2-platforms -
EDK II's analogue of our board/ and arch/ directories.

As platform_rng_getinfo() will only depend on Kconfig settings you can
put it into lib/efi_loader/efi_rng.c.

Best regards

Heinrich




 > +}
 > +
 > +efi_status_t platform_get_rng_device(struct udevice **dev)
 > +{

Here you are creating platform specific code. The idea of the driver
model in U-Boot is to separate duties.

So the implementation of the EFI_RNG_PROTOCOL should be platform
agnostic and rely simply on looping of the devices of UCLASS_RNG.


The core implementation of efi_rng_protocol routines is indeed platform
agnostic. I have just separated the method of getting the rng
device(struct udevice), since different platforms might need different
ways of getting the rng device. For example, on the qemu arm64 platform,
the rng device is a child of a virtio device on the pci bus, while the
rng module on the stm32mp1 platform is a direct memory mapped
peripheral. So the mechanism used to fetch the rng udevice would be
platform dependent. Hence the platform_get_rng_device function. In fact,
I see this kind of method adopted in a lot many other boards, one
example being board/CZ.NIC/turris_omnia/turris_omnia.c(get_atsha204a_dev).


Please, move function platform_get_rng_device into the RNG uclass.


 > +     int ret;
 > +     efi_status_t status = EFI_DEVICE_ERROR;
 > +     struct udevice *bus, *devp;
 > +
 > +     for (uclass_first_device(UCLASS_VIRTIO, &bus); bus;
 > +          uclass_next_device(&bus)) {
 > +             for (device_find_first_child(bus, &devp); devp;
device_find_next_child(&devp)) {
 > +                     if (device_get_uclass_id(devp) == UCLASS_RNG) {
 > +                             *dev = devp;
 > +                             status = EFI_SUCCESS;
 > +                             break;
 > +                     }
 > +             }
 > +     }
 > +
 > +     if (status != EFI_SUCCESS) {
 > +             debug("No rng device found\n");
 > +             retur