Re: [U-Boot] Buildman Kconfig issue with consecutive builds
On 06.11.19 17:16, Frieder Schrempf wrote: > Hi, > > I'm having some trouble using buildman to test the impact of some > Kconfig cleanup patches ([1]). > > The patches introduce a new CONFIG_SPL_* option and I try to find out > which defconfigs need to be fixed, by comparing build sizes. > > Now when I added a patch to fix a defconfig I noticed that buildman > wouldn't report the expected size changes and upon looking more closely > I found that the added Kconfig options are still missing in u-boot-spl.cfg. > > The strange thing is, that when I try to build only the last commit then > the Kconfig options are there, which is why I suspect a bug in buildman > not handling Kconfig changes correctly with consecutive builds. > > Can anyone have a look what is wrong or how I can debug this issue? > > The issue can be reproduced with the branch at [1], running: > > buildman -b spi_flash_kconfig_cleanup_3 --step 0 xilinx_zynqmp_virt Forgot to mention that my master is set to 32d870a82203a16a6e05958e2a02287af4dd825a (which is not upstream) in this case. > > for a build where the added Kconfig options are missing in the resulting > u-boot-spl.cfg. > > And: > > buildman -b spi_flash_kconfig_cleanup_3^..spi_flash_kconfig_cleanup_3 > xilinx_zynqmp_virt > > for a build of only the last commit with expected output. > > Thanks, > Frieder > > [1]: > https://github.com/fschrempf/u-boot/commits/spi_flash_kconfig_cleanup_3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] USB doesn't work on Rockpro64 in u-boot
On Wed, Nov 6, 2019 at 7:48 PM Vasily Khoruzhick wrote: > > On Wed, Nov 6, 2019 at 8:50 AM Jagan Teki wrote: > > > > Hi Vasily, > > > > On Wed, Nov 6, 2019 at 9:17 AM Vasily Khoruzhick wrote: > > > > > > Hi Akash, Jagan, > > > > > > Looks like USB is not functional in u-boot on Rockpro64. u-boot is > > > from git, commit 680023c5fab6b1777c0c6f2e76e5d2effb7903a0. > > > > > > I'm using u-boot SPL and mainline ATF > > > (19adcb415c313d656324d54e7608cdc7d7a5c414 is ATF commit) > > > > > > 'usb start' doesn't detect anything but hubs and looks like there's no > > > power on USB ports: > > > > > > => usb start > > > starting USB... > > > Bus usb@fe38: USB EHCI 1.00 > > > Bus usb@fe3c: USB EHCI 1.00 > > > Bus dwc3: Register 2000140 NbrPorts 2 > > > Starting the controller > > > USB XHCI 1.10 > > > Bus dwc3: Register 2000140 NbrPorts 2 > > > Starting the controller > > > USB XHCI 1.10 > > > scanning bus usb@fe38 for devices... 1 USB Device(s) found > > > scanning bus usb@fe3c for devices... 1 USB Device(s) found > > > scanning bus dwc3 for devices... 1 USB Device(s) found > > > scanning bus dwc3 for devices... 1 USB Device(s) found > > >scanning usb for storage devices... 0 Storage Device(s) found > > > > > > => usb tree > > > USB device tree: > > > 1 Hub (480 Mb/s, 0mA) > > > u-boot EHCI Host Controller > > > > > > 1 Hub (480 Mb/s, 0mA) > > > u-boot EHCI Host Controller > > > > > > 1 Hub (5 Gb/s, 0mA) > > > U-Boot XHCI Host Controller > > > > > > 1 Hub (5 Gb/s, 0mA) > > > U-Boot XHCI Host Controller > > > > > > Regulators were probed correctly according to 'dm tree': > > > > > > regulator14 [ + ] fixed regulator |-- vcc12v-dcin > > > regulator15 [ + ] fixed regulator |-- vcc1v8-s3 > > > regulator16 [ + ] fixed regulator |-- vcc3v3-pcie-regulator > > > regulator17 [ + ] fixed regulator |-- vcc3v3-sys > > > regulator18 [ + ] fixed regulator |-- vcc5v0-host-regulator > > > regulator19 [ + ] fixed regulator |-- vcc5v0-typec-regulator > > > regulator20 [ + ] fixed regulator |-- vcc5v0-sys > > > regulator21 [ + ] fixed regulator |-- vcc5v0-usb > > > regulator22 [ + ] pwm_regulator `-- vdd-log > > > > > > Any ideas what can be wrong? Have it worked before? > > > > I remember my last checking, give me sometime will check it on master > > and update you. > > Looks like gpio clock is not enabled anywhere in u-boot for rk3399, so > gpios just don't work. I was wrong about clock, it appears that set bin in CRU is disabled clock. Yet GPIOs don't work in u-boot, e.g. => gpio set 154 gpio: pin 154 (gpio 154) value is 1 Warning: value of pin is still 0 154 is vcc5v0-host-regulator.gpio. > rk3399 clock driver is very rudimentary and doesn't touch clock gates at all. > > Can anyone explain how it's supposed to work? > > > > > Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
On Thu, Nov 7, 2019 at 11:40 AM Rick Chen wrote: > > Hi Anup > > > > > On Thu, Nov 7, 2019 at 10:45 AM Anup Patel wrote: > > > > > > On Thu, Nov 7, 2019 at 7:04 AM Rick Chen wrote: > > > > > > > > Hi Anup > > > > > > > > > On Wed, Nov 6, 2019 at 2:51 PM Rick Chen wrote: > > > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > > > > On Wed, Nov 6, 2019 at 2:18 PM Anup Patel > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Nov 6, 2019 at 12:14 PM Rick Chen > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2019 at 7:19 AM Rick Chen > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 1:42 PM Anup Patel > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 6:30 AM Alan Kao > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the critics. Comments below. > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 06:38:00PM +0800, Bin > > > > > > > > > > > > > > > Meng wrote: > > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 10:50 AM Rick Chen > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 25, 2019 at 2:18 PM Andes > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Rick Chen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It will work fine due to hart 0 always > > > > > > > > > > > > > > > > > > > will be main > > > > > > > > > > > > > > > > > > > hart coincidentally. When develop SPL > > > > > > > > > > > > > > > > > > > flow, I try to > > > > > > > > > > > > > > > > > > > force other harts to be main hart. And it > > > > > > > > > > > > > > > > > > > will go > > > > > > > > > > > > > > > > > > > wrong in sending IPI flow. So fix it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Fix what? Does this commit contain 2 fixes, > > > > > > > > > > > > > > > > > > or just 1 fix? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, it include two fixs. But they will cause > > > > > > > > > > > > > > > > > one negative result > > > > > > > > > > > > > > > > > that only hart 0 can send ipi to other harts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Having this fix, any hart can be main > > > > > > > > > > > > > > > > > > > hart in U-Boot SPL > > > > > > > > > > > > > > > > > > > theoretically, but it still fail > > > > > > > > > > > > > > > > > > > somewhere. After dig in > > > > > > > > > > > > > > > > > > > and found there is an assumption that > > > > > > > > > > > > > > > > > > > hart 0 shall be > > > > > > > > > > > > > > > > > > > main hart in OpenSbi. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So does this mean there is a bug in OpenSBI > > > > > > > > > > > > > > > > > > too? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am not sure if it is a bug. Maybe it is a > > > > > > > > > > > > > > > > > compatible issue. > > > > > > > > > > > > > > > > > There is a limitation that only hart 0 can be > > > > > > > > > > > > > > > > > main hart in OpenSBI. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't think OpenSBI has such limitation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please check the source. > > > > > > > > > > > > > > > https://github.com/riscv/opensbi/blob/master/firmware/fw_base.S#L54 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apparently, the FIRST TWO LINEs of the > > > > > > > > > > > > > > > initialization are the > > > > > > > > > > > > > > > 1. get hart ID. > > > > > > > > > > > > > > > 2. determine which route to take based on their > > > > > > > > > > > > > > > ID respectively. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, I do think OpenSBI has this signature, if you > > > > > > > > > > > > > > > are not willing to call it > > > > > > > > > > > > > > > a limitation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > This dependency on hart id #0 was not there until > > > > > > > > > > > > > > we added self-relocation > > > > > > > > > > > > > > in OpenSBI for FW_DYNAMIC. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I will try to
Re: [U-Boot] [PATCH 1/2] spi: cadence_qspi: Move to spi-mem framework
Hi Simon,
On 07/11/19 1:25 AM, Simon Goldschmidt wrote:
> Hi Vignesh,
>
> On Thu, Oct 17, 2019 at 2:31 PM Vignesh Raghavendra wrote:
>>
>> Hi Simon,
>>
>> On 17/10/19 4:50 PM, Simon Goldschmidt wrote:
>>> On Mon, Oct 14, 2019 at 3:27 PM Vignesh Raghavendra wrote:
Current Cadence QSPI driver has few limitations. It assumes all read
operations to be in Quad mode and thus does not support SFDP parsing.
Also, adding support for new mode such as Octal mode would not be
possible with current configuration. Therefore move the driver over to
spi-mem
framework. This has added advantage that driver can be used to support
SPI NAND memories too.
Hence, move driver over to new spi-mem APIs.
Please note that this gets rid of mode bit setting done when
CONFIG_SPL_SPI_XIP is defined as there does not seem to be any user to
that config option.
>>>
>>> I just have tried this on an socfgpa cylone5 board with an mt25ql256a, but
>>> it does not seem to work: when leaving spi-rx-bus-width and spi-tx-bus-width
>>> at 4 in my devicetree, SFDP parsing works, but reading data afterwards
>>> produces invalid results (I haven't tested what's wrong there).
>>>
>>
>> Thanks for testing!
>>
>> spi-tx-bus-width = 4 was not supported before so I haven't added support
>> for that mode in this series. That change will be a separate series.
>>
>> Could you try with spi-tx-bus-width = 1 and spi-rx-bus-width = 4 and see
>> if that works?
>>
>> If that does not work then could you disable SFDP parsing (but keep
>> spi-rx-bus-width = 4) and see if that works. This should narrow down
>> whether SFDP parsing is broken or if driver has an issue.
>
> Sorry, I still haven't found the time at work to test this. I'll keep trying.
> Keeping that aside, if this driver is converted to spi-mem, is there any
> chance of getting this into SPL while not getting standard SPI drivers in?
>
> On socfpga, I have a standard SPI driver (designware_spi) enabled but that
> results in both the cadence_qspi and designware_spi being included in SPL
> aside
> well when boot-from-SPI is enabled.
>
> Does that somehow change when cadence_qspi is an spi-mem driver?
>
I dont think so. Only solution I can think of is to create a separate
SPL specific config for designware_spi and disable that for socfpga.
Regards
Vignesh
> Thanks,
> Simon
>
>>
>> Regards
>> Vignesh
>>
>>> It works as expected when not parsing SFDP or setting the bus-width to 1.
>>> So the change itself probably works, but SFDP parsing is broken?
>>>
>>> I did the tests with this applied first:
>>> https://patchwork.ozlabs.org/project/uboot/list/?series=135505
>>>
>>> Regards,
>>> Simon
>>>
>>>
Signed-off-by: Vignesh Raghavendra
---
drivers/spi/cadence_qspi.c | 136 +
drivers/spi/cadence_qspi.h | 9 +--
drivers/spi/cadence_qspi_apb.c | 124 --
3 files changed, 91 insertions(+), 178 deletions(-)
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index e2e54cd27723..673a2e9a6c4c 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include "cadence_qspi.h"
@@ -34,12 +35,21 @@ static int cadence_spi_write_speed(struct udevice
*bus, uint hz)
return 0;
}
+static int cadence_spi_read_id(void *reg_base, u8 len, u8 *idcode)
+{
+ struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(0x9F, 1),
+ SPI_MEM_OP_NO_ADDR,
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_IN(len, idcode,
1));
+
+ return cadence_qspi_apb_command_read(reg_base, );
+}
+
/* Calibration sequence to determine the read data capture delay register
*/
static int spi_calibration(struct udevice *bus, uint hz)
{
struct cadence_spi_priv *priv = dev_get_priv(bus);
void *base = priv->regbase;
- u8 opcode_rdid = 0x9F;
unsigned int idcode = 0, temp = 0;
int err = 0, i, range_lo = -1, range_hi = -1;
@@ -53,8 +63,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
cadence_qspi_apb_controller_enable(base);
/* read the ID which will be our golden value */
- err = cadence_qspi_apb_command_read(base, 1, _rdid,
- 3, (u8 *));
+ err = cadence_spi_read_id(base, 3, (u8 *));
if (err) {
puts("SF: Calibration failed (read)\n");
return err;
@@ -73,8 +82,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
cadence_qspi_apb_controller_enable(base);
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
Hi Anup > > On Thu, Nov 7, 2019 at 10:45 AM Anup Patel wrote: > > > > On Thu, Nov 7, 2019 at 7:04 AM Rick Chen wrote: > > > > > > Hi Anup > > > > > > > On Wed, Nov 6, 2019 at 2:51 PM Rick Chen wrote: > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > On Wed, Nov 6, 2019 at 2:18 PM Anup Patel > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Nov 6, 2019 at 12:14 PM Rick Chen > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2019 at 7:19 AM Rick Chen > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 1:42 PM Anup Patel > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 6:30 AM Alan Kao > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the critics. Comments below. > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 06:38:00PM +0800, Bin Meng > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 10:50 AM Rick Chen > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 25, 2019 at 2:18 PM Andes > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Rick Chen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It will work fine due to hart 0 always will > > > > > > > > > > > > > > > > > > be main > > > > > > > > > > > > > > > > > > hart coincidentally. When develop SPL flow, > > > > > > > > > > > > > > > > > > I try to > > > > > > > > > > > > > > > > > > force other harts to be main hart. And it > > > > > > > > > > > > > > > > > > will go > > > > > > > > > > > > > > > > > > wrong in sending IPI flow. So fix it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Fix what? Does this commit contain 2 fixes, > > > > > > > > > > > > > > > > > or just 1 fix? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, it include two fixs. But they will cause > > > > > > > > > > > > > > > > one negative result > > > > > > > > > > > > > > > > that only hart 0 can send ipi to other harts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Having this fix, any hart can be main hart > > > > > > > > > > > > > > > > > > in U-Boot SPL > > > > > > > > > > > > > > > > > > theoretically, but it still fail somewhere. > > > > > > > > > > > > > > > > > > After dig in > > > > > > > > > > > > > > > > > > and found there is an assumption that hart > > > > > > > > > > > > > > > > > > 0 shall be > > > > > > > > > > > > > > > > > > main hart in OpenSbi. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So does this mean there is a bug in OpenSBI > > > > > > > > > > > > > > > > > too? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am not sure if it is a bug. Maybe it is a > > > > > > > > > > > > > > > > compatible issue. > > > > > > > > > > > > > > > > There is a limitation that only hart 0 can be > > > > > > > > > > > > > > > > main hart in OpenSBI. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't think OpenSBI has such limitation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please check the source. > > > > > > > > > > > > > > https://github.com/riscv/opensbi/blob/master/firmware/fw_base.S#L54 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apparently, the FIRST TWO LINEs of the > > > > > > > > > > > > > > initialization are the > > > > > > > > > > > > > > 1. get hart ID. > > > > > > > > > > > > > > 2. determine which route to take based on their ID > > > > > > > > > > > > > > respectively. > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, I do think OpenSBI has this signature, if you > > > > > > > > > > > > > > are not willing to call it > > > > > > > > > > > > > > a limitation. > > > > > > > > > > > > > > > > > > > > > > > > > > This dependency on hart id #0 was not there until we > > > > > > > > > > > > > added self-relocation > > > > > > > > > > > > > in OpenSBI for FW_DYNAMIC. > > > > > > > > > > > > > > > > > > > > > > > > > > I will try to fix this in OpenSBI but we might end-up > > > > > > > > > > > > > having boot_lottery. > > > > > > > > > > > > > > > > > > > > > > > > I have send a patch to fix this OpenSBI: > > > > > > > > > > > > "[PATCH] firmware: Introduce relocation lottery" > > > > > > > > >
Re: [U-Boot] [PATCH 2/2] freescale/powerpc: Rename the config CONFIG_SECURE_BOOT name.
>-Original Message- >From: Udit Agarwal >Sent: Thursday, October 31, 2019 5:38 PM >To: u-boot@lists.denx.de >Cc: Priyanka Jain ; Arun Pathak >; Ruchika Gupta ; Udit >Agarwal >Subject: [PATCH 2/2] freescale/powerpc: Rename the config >CONFIG_SECURE_BOOT name. > >Renames the CONFIG_SECURE_BOOT name to CONFIG_NXP_ESBC to avoid >conflicts with UEFI secure boot. > >Signed-off-by: Udit Agarwal >--- > arch/powerpc/cpu/mpc85xx/Kconfig | 4 ++-- > arch/powerpc/cpu/mpc85xx/cpu_init.c| 8 > arch/powerpc/cpu/mpc85xx/start.S | 10 +- > arch/powerpc/cpu/mpc8xxx/law.c | 4 ++-- > arch/powerpc/include/asm/fsl_secure_boot.h | 4 ++-- > board/freescale/common/p_corenet/tlb.c | 2 +- > board/freescale/t104xrdb/tlb.c | 4 ++-- > configs/B4860QDS_SECURE_BOOT_defconfig | 2 +- > configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig | 2 +- > configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig | 2 +- > configs/BSC9132QDS_NOR_DDRCLK100_SECURE_defconfig | 2 +- > configs/BSC9132QDS_NOR_DDRCLK133_SECURE_defconfig | 2 +- > configs/BSC9132QDS_SDCARD_DDRCLK100_SECURE_defconfig | 2 +- > configs/BSC9132QDS_SDCARD_DDRCLK133_SECURE_defconfig | 2 +- > configs/BSC9132QDS_SPIFLASH_DDRCLK100_SECURE_defconfig | 2 +- >configs/BSC9132QDS_SPIFLASH_DDRCLK133_SECURE_defconfig | 2 +- > configs/C29XPCIE_NOR_SECBOOT_defconfig | 2 +- > configs/C29XPCIE_SPIFLASH_SECBOOT_defconfig| 2 +- > configs/P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig | 2 +- > configs/P1010RDB-PA_36BIT_NOR_SECBOOT_defconfig| 2 +- > configs/P1010RDB-PA_36BIT_SPIFLASH_SECBOOT_defconfig | 2 +- > configs/P1010RDB-PA_NAND_SECBOOT_defconfig | 2 +- > configs/P1010RDB-PA_NOR_SECBOOT_defconfig | 2 +- > configs/P1010RDB-PA_SPIFLASH_SECBOOT_defconfig | 2 +- > configs/P1010RDB-PB_36BIT_NAND_SECBOOT_defconfig | 2 +- > configs/P1010RDB-PB_36BIT_NOR_SECBOOT_defconfig| 2 +- > configs/P1010RDB-PB_36BIT_SPIFLASH_SECBOOT_defconfig | 2 +- > configs/P1010RDB-PB_NAND_SECBOOT_defconfig | 2 +- > configs/P1010RDB-PB_NOR_SECBOOT_defconfig | 2 +- > configs/P1010RDB-PB_SPIFLASH_SECBOOT_defconfig | 2 +- > configs/P2041RDB_SECURE_BOOT_defconfig | 2 +- > configs/P3041DS_NAND_SECURE_BOOT_defconfig | 2 +- > configs/P3041DS_SECURE_BOOT_defconfig | 2 +- > configs/P4080DS_SECURE_BOOT_defconfig | 2 +- > configs/P5020DS_NAND_SECURE_BOOT_defconfig | 2 +- > configs/P5020DS_SECURE_BOOT_defconfig | 2 +- > configs/P5040DS_NAND_SECURE_BOOT_defconfig | 2 +- > configs/P5040DS_SECURE_BOOT_defconfig | 2 +- > configs/T1023RDB_SECURE_BOOT_defconfig | 2 +- > configs/T1024QDS_DDR4_SECURE_BOOT_defconfig| 2 +- > configs/T1024QDS_SECURE_BOOT_defconfig | 2 +- > configs/T1024RDB_SECURE_BOOT_defconfig | 2 +- > configs/T1040D4RDB_SECURE_BOOT_defconfig | 2 +- > configs/T1040QDS_SECURE_BOOT_defconfig | 2 +- > configs/T1040RDB_SECURE_BOOT_defconfig | 2 +- > configs/T1042D4RDB_SECURE_BOOT_defconfig | 2 +- > configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig | 2 +- > configs/T1042RDB_SECURE_BOOT_defconfig | 2 +- > configs/T2080QDS_SECURE_BOOT_defconfig | 2 +- > configs/T2080RDB_SECURE_BOOT_defconfig | 2 +- > configs/T4160QDS_SECURE_BOOT_defconfig | 2 +- > configs/T4240QDS_SECURE_BOOT_defconfig | 2 +- > doc/README.mpc85xx | 8 > include/configs/P1010RDB.h | 4 ++-- > include/configs/T104xRDB.h | 6 +++--- > include/configs/corenet_ds.h | 2 +- > 56 files changed, 73 insertions(+), 73 deletions(-) > Please rebase to top of tree. --priyankajain ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
On Thu, Nov 7, 2019 at 10:45 AM Anup Patel wrote: > > On Thu, Nov 7, 2019 at 7:04 AM Rick Chen wrote: > > > > Hi Anup > > > > > On Wed, Nov 6, 2019 at 2:51 PM Rick Chen wrote: > > > > > > > > Hi Anup > > > > > > > > > > > > > > On Wed, Nov 6, 2019 at 2:18 PM Anup Patel wrote: > > > > > > > > > > > > On Wed, Nov 6, 2019 at 12:14 PM Rick Chen > > > > > > wrote: > > > > > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2019 at 7:19 AM Rick Chen > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 1:42 PM Anup Patel > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 6:30 AM Alan Kao > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the critics. Comments below. > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 06:38:00PM +0800, Bin Meng > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 10:50 AM Rick Chen > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 25, 2019 at 2:18 PM Andes > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Rick Chen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It will work fine due to hart 0 always will > > > > > > > > > > > > > > > > > be main > > > > > > > > > > > > > > > > > hart coincidentally. When develop SPL flow, I > > > > > > > > > > > > > > > > > try to > > > > > > > > > > > > > > > > > force other harts to be main hart. And it > > > > > > > > > > > > > > > > > will go > > > > > > > > > > > > > > > > > wrong in sending IPI flow. So fix it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Fix what? Does this commit contain 2 fixes, or > > > > > > > > > > > > > > > > just 1 fix? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, it include two fixs. But they will cause one > > > > > > > > > > > > > > > negative result > > > > > > > > > > > > > > > that only hart 0 can send ipi to other harts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Having this fix, any hart can be main hart in > > > > > > > > > > > > > > > > > U-Boot SPL > > > > > > > > > > > > > > > > > theoretically, but it still fail somewhere. > > > > > > > > > > > > > > > > > After dig in > > > > > > > > > > > > > > > > > and found there is an assumption that hart 0 > > > > > > > > > > > > > > > > > shall be > > > > > > > > > > > > > > > > > main hart in OpenSbi. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So does this mean there is a bug in OpenSBI too? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am not sure if it is a bug. Maybe it is a > > > > > > > > > > > > > > > compatible issue. > > > > > > > > > > > > > > > There is a limitation that only hart 0 can be > > > > > > > > > > > > > > > main hart in OpenSBI. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't think OpenSBI has such limitation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please check the source. > > > > > > > > > > > > > https://github.com/riscv/opensbi/blob/master/firmware/fw_base.S#L54 > > > > > > > > > > > > > > > > > > > > > > > > > > Apparently, the FIRST TWO LINEs of the initialization > > > > > > > > > > > > > are the > > > > > > > > > > > > > 1. get hart ID. > > > > > > > > > > > > > 2. determine which route to take based on their ID > > > > > > > > > > > > > respectively. > > > > > > > > > > > > > > > > > > > > > > > > > > So, I do think OpenSBI has this signature, if you are > > > > > > > > > > > > > not willing to call it > > > > > > > > > > > > > a limitation. > > > > > > > > > > > > > > > > > > > > > > > > This dependency on hart id #0 was not there until we > > > > > > > > > > > > added self-relocation > > > > > > > > > > > > in OpenSBI for FW_DYNAMIC. > > > > > > > > > > > > > > > > > > > > > > > > I will try to fix this in OpenSBI but we might end-up > > > > > > > > > > > > having boot_lottery. > > > > > > > > > > > > > > > > > > > > > > I have send a patch to fix this OpenSBI: > > > > > > > > > > > "[PATCH] firmware: Introduce relocation lottery" > > > > > > > > > > > > > > > > > > > > > > Can you try above patch and see if that helps ? > > > > > > > > > > > > > > > > > > > > > > It will be great if you can provide Tested-by to my patch > > > > > > > > > > > as well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: [U-Boot] [PATCH 1/2] arm: dts: hummingboard: add cubox/hummingboard DT
Hi Fabio,
On Wed, Nov 06, 2019 at 03:37:18PM -0300, Fabio Estevam wrote:
> On Wed, Nov 6, 2019 at 11:28 AM Baruch Siach wrote:
> > These DT files are copied from kernel v5.3 with very little changes.
> > Notably missing are audmux port configuration nodes, since U-Boot does
> > not provide the IMX_AUDMUX_ macros.
>
> What about importing the include/dt-bindings/sound/fsl-imx-audmux.h
> file from the kernel to U-Boot?
>
> This would help us to use the kernel dts as is in U-Boot.
I'll add that in v2.
I guess I also need to split this patch somehow to fit in the list message
size limit.
Thanks for reviewing.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: fsl-layerscape: use IS_ENABLED()
>-Original Message- >From: U-Boot On Behalf Of Michael Walle >Sent: Monday, October 21, 2019 11:03 PM >To: u-boot@lists.denx.de >Cc: Tom Rini >Subject: [U-Boot] [PATCH] armv8: fsl-layerscape: use IS_ENABLED() > >We have to use IS_ENABLED() otherwise the compiler will throw an error if >CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT is not set. > >Signed-off-by: Michael Walle >--- > arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h >b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h >index 37e2fe4e66..522c7b89df 100644 >--- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h >+++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h >@@ -166,7 +166,7 @@ extern int fman_icid_tbl_sz; > > #define SET_SEC_JR_ICID_ENTRY(jr_num, streamid) \ > SET_ICID_ENTRY( \ >- (CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT && \ >+ (IS_ENABLED(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT) && >\ > (FSL_SEC_JR##jr_num##_OFFSET == \ > SEC_JR3_OFFSET + CONFIG_SYS_FSL_SEC_OFFSET) \ > ? NULL \ >-- >2.20.1 > >__ Similar patch : https://patchwork.ozlabs.org/patch/1179214/ posted before Changing state to "not applicable" --priyankajain ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
On Thu, Nov 7, 2019 at 7:04 AM Rick Chen wrote: > > Hi Anup > > > On Wed, Nov 6, 2019 at 2:51 PM Rick Chen wrote: > > > > > > Hi Anup > > > > > > > > > > > On Wed, Nov 6, 2019 at 2:18 PM Anup Patel wrote: > > > > > > > > > > On Wed, Nov 6, 2019 at 12:14 PM Rick Chen > > > > > wrote: > > > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2019 at 7:19 AM Rick Chen > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 1:42 PM Anup Patel > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 6:30 AM Alan Kao > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the critics. Comments below. > > > > > > > > > > > > On Wed, Oct 30, 2019 at 06:38:00PM +0800, Bin Meng > > > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 10:50 AM Rick Chen > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 25, 2019 at 2:18 PM Andes > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Rick Chen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It will work fine due to hart 0 always will be > > > > > > > > > > > > > > > > main > > > > > > > > > > > > > > > > hart coincidentally. When develop SPL flow, I > > > > > > > > > > > > > > > > try to > > > > > > > > > > > > > > > > force other harts to be main hart. And it will > > > > > > > > > > > > > > > > go > > > > > > > > > > > > > > > > wrong in sending IPI flow. So fix it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Fix what? Does this commit contain 2 fixes, or > > > > > > > > > > > > > > > just 1 fix? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, it include two fixs. But they will cause one > > > > > > > > > > > > > > negative result > > > > > > > > > > > > > > that only hart 0 can send ipi to other harts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Having this fix, any hart can be main hart in > > > > > > > > > > > > > > > > U-Boot SPL > > > > > > > > > > > > > > > > theoretically, but it still fail somewhere. > > > > > > > > > > > > > > > > After dig in > > > > > > > > > > > > > > > > and found there is an assumption that hart 0 > > > > > > > > > > > > > > > > shall be > > > > > > > > > > > > > > > > main hart in OpenSbi. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So does this mean there is a bug in OpenSBI too? > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am not sure if it is a bug. Maybe it is a > > > > > > > > > > > > > > compatible issue. > > > > > > > > > > > > > > There is a limitation that only hart 0 can be main > > > > > > > > > > > > > > hart in OpenSBI. > > > > > > > > > > > > > > > > > > > > > > > > > > I don't think OpenSBI has such limitation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please check the source. > > > > > > > > > > > > https://github.com/riscv/opensbi/blob/master/firmware/fw_base.S#L54 > > > > > > > > > > > > > > > > > > > > > > > > Apparently, the FIRST TWO LINEs of the initialization > > > > > > > > > > > > are the > > > > > > > > > > > > 1. get hart ID. > > > > > > > > > > > > 2. determine which route to take based on their ID > > > > > > > > > > > > respectively. > > > > > > > > > > > > > > > > > > > > > > > > So, I do think OpenSBI has this signature, if you are > > > > > > > > > > > > not willing to call it > > > > > > > > > > > > a limitation. > > > > > > > > > > > > > > > > > > > > > > This dependency on hart id #0 was not there until we > > > > > > > > > > > added self-relocation > > > > > > > > > > > in OpenSBI for FW_DYNAMIC. > > > > > > > > > > > > > > > > > > > > > > I will try to fix this in OpenSBI but we might end-up > > > > > > > > > > > having boot_lottery. > > > > > > > > > > > > > > > > > > > > I have send a patch to fix this OpenSBI: > > > > > > > > > > "[PATCH] firmware: Introduce relocation lottery" > > > > > > > > > > > > > > > > > > > > Can you try above patch and see if that helps ? > > > > > > > > > > > > > > > > > > > > It will be great if you can provide Tested-by to my patch > > > > > > > > > > as well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I can not find this patch in mailing list. > > > > > > > > Can you provide a hyperlink ? > > > > > > > > > > > > > > You can try latest riscv/opensbi master. > > > > > > > > > > > > > > I have tested the patch on SiFive Unleashed multiple times. > > > > > > > > > > >
Re: [U-Boot] [PATCH 1/2] freescale/layerscape: Rename the config CONFIG_SECURE_BOOT name.
>-Original Message- >From: Udit Agarwal >Sent: Thursday, October 31, 2019 5:38 PM >To: u-boot@lists.denx.de >Cc: Priyanka Jain ; Arun Pathak >; Ruchika Gupta ; Udit >Agarwal >Subject: [PATCH 1/2] freescale/layerscape: Rename the config >CONFIG_SECURE_BOOT name. > >Renames CONFIG_SECURE_BOOT to CONFIG_NXP_ESBC to avoid conflict with >UEFI secure boot. > >Signed-off-by: Udit Agarwal >--- > arch/arm/cpu/armv7/ls102xa/Kconfig | 4 ++-- > arch/arm/cpu/armv8/fsl-layerscape/Kconfig| 4 ++-- > arch/arm/cpu/armv8/fsl-layerscape/spl.c | 2 +- > board/freescale/common/Kconfig | 2 +- > board/freescale/common/Makefile | 2 +- > board/freescale/ls1043ardb/ls1043ardb.c | 2 +- > board/freescale/ls1046afrwy/ls1046afrwy.c| 2 +- > board/freescale/ls1046aqds/ls1046aqds.c | 2 +- > board/freescale/ls1046ardb/ls1046ardb.c | 2 +- > configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig | 2 +- > configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig| 2 +- > configs/ls1012aqds_tfa_SECURE_BOOT_defconfig | 2 +- > configs/ls1012ardb_qspi_SECURE_BOOT_defconfig| 2 +- > configs/ls1012ardb_tfa_SECURE_BOOT_defconfig | 2 +- > configs/ls1021aqds_nor_SECURE_BOOT_defconfig | 2 +- > configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 2 +- > configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig | 2 +- > configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 2 +- > configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 2 +- > configs/ls1043aqds_tfa_SECURE_BOOT_defconfig | 2 +- > configs/ls1043ardb_SECURE_BOOT_defconfig | 2 +- > configs/ls1043ardb_nand_SECURE_BOOT_defconfig| 2 +- > configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig | 2 +- > configs/ls1043ardb_tfa_SECURE_BOOT_defconfig | 2 +- > configs/ls1046afrwy_tfa_SECURE_BOOT_defconfig| 2 +- Please rebase to top of tree u-boot code. I can't find some files like above --priyankajain > configs/ls1046aqds_SECURE_BOOT_defconfig | 2 +- > configs/ls1046aqds_tfa_SECURE_BOOT_defconfig | 2 +- > configs/ls1046ardb_qspi_SECURE_BOOT_defconfig| 2 +- > configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig | 2 +- > configs/ls1046ardb_tfa_SECURE_BOOT_defconfig | 2 +- > configs/ls1088aqds_qspi_SECURE_BOOT_defconfig| 2 +- > configs/ls1088ardb_qspi_SECURE_BOOT_defconfig| 2 +- > configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig | 2 +- > configs/ls1088ardb_tfa_SECURE_BOOT_defconfig | 2 +- > configs/ls2080aqds_SECURE_BOOT_defconfig | 2 +- > configs/ls2080ardb_SECURE_BOOT_defconfig | 2 +- > configs/ls2088ardb_qspi_SECURE_BOOT_defconfig| 2 +- > configs/ls2088ardb_tfa_SECURE_BOOT_defconfig | 2 +- > configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 2 +- > configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 2 +- > include/configs/ls1021atwr.h | 4 ++-- > include/configs/ls1028a_common.h | 2 +- > include/configs/ls1043a_common.h | 8 > include/configs/ls1046a_common.h | 4 ++-- > include/configs/ls1088a_common.h | 4 ++-- > include/configs/ls1088aqds.h | 6 +++--- > include/configs/ls2080aqds.h | 4 ++-- > 47 files changed, 58 insertions(+), 58 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/9] powerpc: convert socrates board to DM
>-Original Message- >From: U-Boot On Behalf Of Heiko Schocher >Sent: Wednesday, October 16, 2019 9:26 AM >To: U-Boot Mailing List >Subject: [U-Boot] [PATCH v2 0/9] powerpc: convert socrates board to DM > >convert the socrates board to use DM. > >needed pending PCI patch >https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwo >rk.ozlabs.org%2Fpatch%2F1176108%2Fdata=02%7C01%7Cpriyanka.jain >%40nxp.com%7Cd938ac783e094919420008d751eccfd3%7C686ea1d3bc2b4c6fa >92cd99c5c301635%7C0%7C0%7C637067949868856596sdata=R0csZibE6 >UBNyNR7FKQgmLNQ7ABggMirfCsY2Cs6j4c%3Dreserved=0 > >fixes compiler warnings: >= WARNING == This board >does not use CONFIG_DM. CONFIG_DM will be compulsory starting with the >v2020.01 release. >Failure to update may result in board removal. >See doc/driver-model/migration.rst for more info. > >= WARNING == This board >does not use CONFIG_DM_USB. Please update the board to use >CONFIG_DM_USB before the v2019.07 release. >Failure to update by the deadline may result in board removal. >See doc/driver-model/MIGRATION.txt for more info. > >= WARNING == This board >does not use CONFIG_DM_PCI Please update the board to use >CONFIG_DM_PCI before the v2019.07 release. >Failure to update by the deadline may result in board removal. >See doc/driver-model/MIGRATION.txt for more info. > >= WARNING == This board >does not use CONFIG_DM_VIDEO Please update the board to use >CONFIG_DM_VIDEO before the v2019.07 release. >Failure to update by the deadline may result in board removal. >See doc/driver-model/MIGRATION.txt for more info. > > >Travis build: >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis- >ci.org%2Fhsdenx%2Fu-boot- >test%2Fbuilds%2F597488733data=02%7C01%7Cpriyanka.jain%40nxp.co >m%7Cd938ac783e094919420008d751eccfd3%7C686ea1d3bc2b4c6fa92cd99c5c >301635%7C0%7C0%7C637067949868856596sdata=nxIa1Ur2OMMZBmFz >iCT8lmc%2Bm14CFb29B9dOsucvyas%3Dreserved=0 > >Changes in v2: >- use separate PCI driver for mpc85xx as Z.q. Hou mentioned: > and drop the patchseries: > pci: pcie_fsl: add support for none PCIe devices > >https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwo >rk.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D134976data= >02%7C01%7Cpriyanka.jain%40nxp.com%7Cd938ac783e094919420008d751eccf >d3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370679498688565 >96sdata=hPUIpB%2FRyEQkK94MP3%2F1mB8RNg9FyyL%2Bo0DqDHUQk4 >k%3Dreserved=0 >END > >Heiko Schocher (9): > mpc85xx, socrates: suppress unknown flash warning > mpc85xx: add socrates dts from linux > mpc85xx, dts, socrates: add u-boot specific dtsi > mpc85xx, socrates: add DM support > mpc85xx, socrates: get rid of DM_USB warning > mpc85xx, socrates: disable VIDEO > mpc85xx, socrates: enable DM I2C > mpc85xx, socrates: enable DM serial > mpc85xx, socrates: add DM PCI support > > arch/powerpc/dts/Makefile | 1 + > arch/powerpc/dts/socrates-u-boot.dtsi | 40 +++ > arch/powerpc/dts/socrates.dts | 349 ++ > board/socrates/MAINTAINERS| 4 +- > board/socrates/law.c | 2 - > board/socrates/socrates.c | 222 ++-- > configs/socrates_defconfig| 24 +- > include/configs/socrates.h| 68 + > 8 files changed, 439 insertions(+), 271 deletions(-) create mode 100644 >arch/powerpc/dts/socrates-u-boot.dtsi > create mode 100644 arch/powerpc/dts/socrates.dts > >-- >2.21.0 > >___ >U-Boot mailing list >U-Boot@lists.denx.de >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.de >nx.de%2Flistinfo%2Fu- >bootdata=02%7C01%7Cpriyanka.jain%40nxp.com%7Cd938ac783e09491 >9420008d751eccfd3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63 >7067949868856596sdata=TDp2Uz0QQfscE2sB4H6XQBNA4jT6rguzrximO6 >LSfz0%3Dreserved=0 Series applied to mpc85xx master, awaiting upstream. Thanks priyankajain ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] pci: add DM based mpc85xx driver
>-Original Message-
>From: U-Boot On Behalf Of Heiko Schocher
>Sent: Monday, October 14, 2019 3:00 PM
>To: u-boot@lists.denx.de
>Cc: Heinrich Schuchardt ; Z.q. Hou
>; Michal Simek ; Ryder
>Lee ; Stefan Roese
>Subject: [U-Boot] [PATCH v2] pci: add DM based mpc85xx driver
>
>add DM based PCI Configuration space access support for MPC85xx PCI
>Bridge. This driver is based on arch/powerpc/cpu/mpc85xx/pci.c
>
>In the old driver there is a fix for a hw issue on the TARGET_MPC8555CDS and
>TARGET_MPC8541CDS boards. As I have no such hardware I did not port this
>part.
>
>Signed-off-by: Heiko Schocher
>
>---
>Travis build, see:
>https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis-
>ci.org%2Fhsdenx%2Fu-boot-
>test%2Fbuilds%2F597452473data=02%7C01%7Cpriyanka.jain%40nxp.co
>m%7Cec182e150f6a4dd75f6408d750891bbc%7C686ea1d3bc2b4c6fa92cd99c5c
>301635%7C0%7C0%7C637066422116723776sdata=h3jdy9SofUyvjzm5Jdy
>NTnWqphxOLRnzEkxYBguxYrw%3Dreserved=0
>
>Changes in v2:
>- added in commit message that this driver is based on
> arch/powerpc/cpu/mpc85xx/pci.c
>- add note, that I did not port the fix for hw issue on
> TARGET_MPC8555CDS and TARGET_MPC8541CDS boards
>- set LAWs in this driver not in board code
> as suggested by Zhiqiang
>
> MAINTAINERS | 5 ++
> drivers/pci/Kconfig | 7 ++
> drivers/pci/Makefile | 1 +
> drivers/pci/pci_mpc85xx.c | 158
>++
> 4 files changed, 171 insertions(+)
> create mode 100644 drivers/pci/pci_mpc85xx.c
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index 2ef2976855..c9cd817b59 100644
>--- a/MAINTAINERS
>+++ b/MAINTAINERS
>@@ -692,6 +692,11 @@ S:Maintained
> F:drivers/pci_endpoint/
> F: include/pci_ep.h
>
>+PCI MPC85xx
>+M:Heiko Schocher
>+S:Maintained
>+F:drivers/pci/pci_mpc85xx.c
>+
> POWER
> M:Jaehoon Chung
> S:Maintained
>diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index
>19e7b50046..71aab85ed3 100644
>--- a/drivers/pci/Kconfig
>+++ b/drivers/pci/Kconfig
>@@ -68,6 +68,13 @@ config PCIE_FSL
> PowerPC MPC85xx, MPC86xx, B series, P series and T series SoCs.
> This driver does not support SRIO_PCIE_BOOT feature.
>
>+config PCI_MPC85XX
>+ bool "MPC85XX PowerPC PCI support"
>+ depends on DM_PCI
>+ help
>+Say Y here if you want to enable PCI controller support on FSL
>+PowerPC MPC85xx SoC.
>+
> config PCI_RCAR_GEN2
> bool "Renesas RCar Gen2 PCIe driver"
> depends on DM_PCI
>diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index
>b1d3dc8610..856ac71a1c 100644
>--- a/drivers/pci/Makefile
>+++ b/drivers/pci/Makefile
>@@ -19,6 +19,7 @@ obj-$(CONFIG_PCIE_ECAM_GENERIC) +=
>pcie_ecam_generic.o
> obj-$(CONFIG_FSL_PCI_INIT) += fsl_pci_init.o
> obj-$(CONFIG_PCI_INDIRECT_BRIDGE) += pci_indirect.o
> obj-$(CONFIG_PCI_GT64120) += pci_gt64120.o
>+obj-$(CONFIG_PCI_MPC85XX) += pci_mpc85xx.o
> obj-$(CONFIG_PCI_MSC01) += pci_msc01.o
> obj-$(CONFIG_PCIE_IMX) += pcie_imx.o
> obj-$(CONFIG_FTPCI100) += pci_ftpci100.o diff --git
>a/drivers/pci/pci_mpc85xx.c b/drivers/pci/pci_mpc85xx.c new file mode
>100644 index 00..e58ab60ee0
>--- /dev/null
>+++ b/drivers/pci/pci_mpc85xx.c
>@@ -0,0 +1,158 @@
>+// SPDX-License-Identifier: GPL-2.0
>+/*
>+ * (C) Copyright 2019
>+ * Heiko Schocher, DENX Software Engineering, h...@denx.de.
>+ *
>+ */
>+#include
>+#include
>+#include
>+#include
>+#include
>+
>+struct mpc85xx_pci_priv {
>+ void __iomem*cfg_addr;
>+ void __iomem*cfg_data;
>+};
>+
>+static int mpc85xx_pci_dm_read_config(struct udevice *dev, pci_dev_t bdf,
>+uint offset, ulong *value,
>+enum pci_size_t size)
>+{
>+ struct mpc85xx_pci_priv *priv = dev_get_priv(dev);
>+ u32 addr;
>+
>+ addr = bdf | (offset & 0xfc) | ((offset & 0xf00) << 16) | 0x8000;
>+ out_be32(priv->cfg_addr, addr);
>+ sync();
>+ *value = pci_conv_32_to_size(in_le32(priv->cfg_data), offset, size);
>+
>+ return 0;
>+}
>+
>+static int mpc85xx_pci_dm_write_config(struct udevice *dev, pci_dev_t bdf,
>+ uint offset, ulong value,
>+ enum pci_size_t size)
>+{
>+ struct mpc85xx_pci_priv *priv = dev_get_priv(dev);
>+ u32 addr;
>+
>+ addr = bdf | (offset & 0xfc) | ((offset & 0xf00) << 16) | 0x8000;
>+ out_be32(priv->cfg_addr, addr);
>+ sync();
>+ out_le32(priv->cfg_data, pci_conv_size_to_32(0, value, offset, size));
>+
>+ return 0;
>+}
>+
>+static int
>+mpc85xx_pci_dm_setup_laws(struct pci_region *io, struct pci_region *mem,
>+struct pci_region *pre)
>+{
>+ /*
>+ * Unfortunately we have defines for this addresse,
>+ * as we have to setup the TLB, and at this stage
>+ * we have no access to DT ... may we check here
>+ * if the value in the define is the same
[U-Boot] pull request u-boot-mpc85xx
Dear Tom, Please find my pull-request for u-boot-mpc85xx/master https://travis-ci.org/p-priyanka-jain/u-boot/builds/608129628 Summary mpc85xx,socrates: Add dts, enable DM support, fix warnings, disable video priyankajain -- The following changes since commit 14d39c9e1dc9397febd58399a70f32e7481bbc27: travis: Rework how we write the ~/.buildman file (2019-11-05 10:44:16 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-mpc85xx.git HEAD for you to fetch changes up to 2a51fe01be0985f5214aac98866c9a26906f3fba: mpc85xx, socrates: add DM PCI support (2019-11-06 16:30:19 +0530) Heiko Schocher (10): pci: add DM based mpc85xx driver mpc85xx, socrates: suppress unknown flash warning mpc85xx: add socrates dts from linux mpc85xx, dts, socrates: add u-boot specific dtsi mpc85xx, socrates: add DM support mpc85xx, socrates: get rid of DM_USB warning mpc85xx, socrates: disable VIDEO mpc85xx, socrates: enable DM I2C mpc85xx, socrates: enable DM serial mpc85xx, socrates: add DM PCI support MAINTAINERS | 5 + arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/socrates-u-boot.dtsi | 40 arch/powerpc/dts/socrates.dts | 349 ++ board/socrates/MAINTAINERS| 4 +- board/socrates/law.c | 2 - board/socrates/socrates.c | 222 ++--- configs/socrates_defconfig| 24 ++- drivers/pci/Kconfig | 7 + drivers/pci/Makefile | 1 + drivers/pci/pci_mpc85xx.c | 158 +++ include/configs/socrates.h| 68 +-- 12 files changed, 610 insertions(+), 271 deletions(-) create mode 100644 arch/powerpc/dts/socrates-u-boot.dtsi create mode 100644 arch/powerpc/dts/socrates.dts create mode 100644 drivers/pci/pci_mpc85xx.c ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] USB doesn't work on Rockpro64 in u-boot
On Wed, Nov 6, 2019 at 8:50 AM Jagan Teki wrote: > > Hi Vasily, > > On Wed, Nov 6, 2019 at 9:17 AM Vasily Khoruzhick wrote: > > > > Hi Akash, Jagan, > > > > Looks like USB is not functional in u-boot on Rockpro64. u-boot is > > from git, commit 680023c5fab6b1777c0c6f2e76e5d2effb7903a0. > > > > I'm using u-boot SPL and mainline ATF > > (19adcb415c313d656324d54e7608cdc7d7a5c414 is ATF commit) > > > > 'usb start' doesn't detect anything but hubs and looks like there's no > > power on USB ports: > > > > => usb start > > starting USB... > > Bus usb@fe38: USB EHCI 1.00 > > Bus usb@fe3c: USB EHCI 1.00 > > Bus dwc3: Register 2000140 NbrPorts 2 > > Starting the controller > > USB XHCI 1.10 > > Bus dwc3: Register 2000140 NbrPorts 2 > > Starting the controller > > USB XHCI 1.10 > > scanning bus usb@fe38 for devices... 1 USB Device(s) found > > scanning bus usb@fe3c for devices... 1 USB Device(s) found > > scanning bus dwc3 for devices... 1 USB Device(s) found > > scanning bus dwc3 for devices... 1 USB Device(s) found > >scanning usb for storage devices... 0 Storage Device(s) found > > > > => usb tree > > USB device tree: > > 1 Hub (480 Mb/s, 0mA) > > u-boot EHCI Host Controller > > > > 1 Hub (480 Mb/s, 0mA) > > u-boot EHCI Host Controller > > > > 1 Hub (5 Gb/s, 0mA) > > U-Boot XHCI Host Controller > > > > 1 Hub (5 Gb/s, 0mA) > > U-Boot XHCI Host Controller > > > > Regulators were probed correctly according to 'dm tree': > > > > regulator14 [ + ] fixed regulator |-- vcc12v-dcin > > regulator15 [ + ] fixed regulator |-- vcc1v8-s3 > > regulator16 [ + ] fixed regulator |-- vcc3v3-pcie-regulator > > regulator17 [ + ] fixed regulator |-- vcc3v3-sys > > regulator18 [ + ] fixed regulator |-- vcc5v0-host-regulator > > regulator19 [ + ] fixed regulator |-- vcc5v0-typec-regulator > > regulator20 [ + ] fixed regulator |-- vcc5v0-sys > > regulator21 [ + ] fixed regulator |-- vcc5v0-usb > > regulator22 [ + ] pwm_regulator `-- vdd-log > > > > Any ideas what can be wrong? Have it worked before? > > I remember my last checking, give me sometime will check it on master > and update you. Looks like gpio clock is not enabled anywhere in u-boot for rk3399, so gpios just don't work. rk3399 clock driver is very rudimentary and doesn't touch clock gates at all. Can anyone explain how it's supposed to work? > > Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/4] arm: dts: socfpga: Add u-boot, dm-pre-reloc for sysmgr and clkmgr nodes
On Thu, Nov 7, 2019 at 10:49 AM Marek Vasut wrote:
>
> On 11/7/19 3:10 AM, Ley Foon Tan wrote:
> [...]
> > diff --git a/arch/arm/dts/socfpga-common-u-boot.dtsi
> > b/arch/arm/dts/socfpga-common-u-boot.dtsi
> > index 322c858c4b..d55460755f 100644
> > --- a/arch/arm/dts/socfpga-common-u-boot.dtsi
> > +++ b/arch/arm/dts/socfpga-common-u-boot.dtsi
> > @@ -10,6 +10,10 @@
> > };
> > };
> >
> > + {
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > {
> > u-boot,dm-pre-reloc;
> > };
> > @@ -17,3 +21,7 @@
> > {
> > u-boot,dm-pre-reloc;
> > };
> > +
> > + {
> > + u-boot,dm-pre-reloc;
> > +};
>
> Gen5 doesn't have any clock driver, so does it really make sense to
> retain the clkmgr node in SPL now ? Seems like this only grows the SPL
> size with no benefit.
>
But, we need to get clkmgr base address from DT even we don't have
clock driver for it.
So, clkmgr needs enable in SPL.
Regards
Ley Foon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/4] arm: socfpga: Convert system manager from struct to defines
On 11/7/19 3:10 AM, Ley Foon Tan wrote:
[...]
> diff --git a/arch/arm/mach-socfpga/misc_arria10.c
> b/arch/arm/mach-socfpga/misc_arria10.c
> index 2e2a40b65d..ff6ab83441 100644
> --- a/arch/arm/mach-socfpga/misc_arria10.c
> +++ b/arch/arm/mach-socfpga/misc_arria10.c
> @@ -28,9 +28,6 @@
> #define PINMUX_UART1_TX_SHARED_IO_OFFSET_Q3_70x78
> #define PINMUX_UART1_TX_SHARED_IO_OFFSET_Q4_30x98
>
> -static struct socfpga_system_manager *sysmgr_regs =
> - (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
> -
> /*
> * FPGA programming support for SoC FPGA Arria 10
> */
> @@ -81,7 +78,7 @@ void socfpga_init_security_policies(void)
> writel(~0, SOCFPGA_NOC_FW_H2F_SCR_OFST);
> writel(~0, SOCFPGA_NOC_FW_H2F_SCR_OFST + 4);
>
> - writel(0x0007, _regs->ecc_intmask_set);
> + writel(0x0007, socfpga_sysmgr_base + SYSMGR_A10_ECC_INTMASK_SET);
> }
>
> void socfpga_sdram_remap_zero(void)
> @@ -105,8 +102,8 @@ int arch_early_init_r(void)
> #if defined(CONFIG_DISPLAY_CPUINFO)
> int print_cpuinfo(void)
> {
> - const u32 bsel =
> - SYSMGR_GET_BOOTINFO_BSEL(readl(_regs->bootinfo));
> + u32 bootinfo = readl(socfpga_sysmgr_base + SYSMGR_A10_BOOTINFO);
const u32
> + const u32 bsel = SYSMGR_GET_BOOTINFO_BSEL(bootinfo);
>
> puts("CPU: Altera SoCFPGA Arria 10\n");
>
> diff --git a/arch/arm/mach-socfpga/misc_gen5.c
> b/arch/arm/mach-socfpga/misc_gen5.c
> index b39a66562d..7735958e9c 100644
> --- a/arch/arm/mach-socfpga/misc_gen5.c
> +++ b/arch/arm/mach-socfpga/misc_gen5.c
> @@ -28,8 +28,6 @@ DECLARE_GLOBAL_DATA_PTR;
>
> static struct pl310_regs *const pl310 =
> (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
> -static struct socfpga_system_manager *sysmgr_regs =
> - (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
> static struct nic301_registers *nic301_regs =
> (struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
> static struct scu_registers *scu_regs =
> @@ -118,8 +116,8 @@ static int socfpga_fpga_id(const bool print_id)
> #if defined(CONFIG_DISPLAY_CPUINFO)
> int print_cpuinfo(void)
> {
> - const u32 bsel =
> - SYSMGR_GET_BOOTINFO_BSEL(readl(_regs->bootinfo));
> + u32 bootinfo = readl(socfpga_sysmgr_base + SYSMGR_GEN5_BOOTINFO);
> + const u32 bsel = SYSMGR_GET_BOOTINFO_BSEL(bootinfo);
Same here , const u32 .
> puts("CPU: Altera SoCFPGA Platform\n");
> socfpga_fpga_id(1);
[...]
> diff --git a/arch/arm/mach-socfpga/misc_s10.c
> b/arch/arm/mach-socfpga/misc_s10.c
> index 0a5fab11c0..16fbf71599 100644
> --- a/arch/arm/mach-socfpga/misc_s10.c
> +++ b/arch/arm/mach-socfpga/misc_s10.c
> @@ -23,9 +23,6 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -static struct socfpga_system_manager *sysmgr_regs =
> - (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
> -
> /*
> * FPGA programming support for SoC FPGA Stratix 10
> */
> @@ -68,9 +65,9 @@ static u32 socfpga_phymode_setup(u32 gmac_index, const char
> *phymode)
> else
> return -EINVAL;
>
> - clrsetbits_le32(_regs->emac0 + gmac_index,
> - SYSMGR_EMACGRP_CTRL_PHYSEL_MASK,
> - modereg);
> + clrsetbits_le32((unsigned long)(socfpga_sysmgr_base + SYSMGR_S10_EMAC0 +
Is the typecast needed at all ?
Also, the typecast should probably apply only on socfpga_sysmgr_base,
not the entire expression.
> + gmac_index),
> + SYSMGR_EMACGRP_CTRL_PHYSEL_MASK, modereg);
>
> return 0;
> }
[...]
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/4] arm: socfpga: Convert reset manager from struct to defines
On 11/7/19 3:10 AM, Ley Foon Tan wrote:
> Convert reset manager for Gen5, Arria 10 and Stratix 10 from struct
> to defines.
>
> Change to get reset manager base address from DT node instead of using
> #define.
It seems the patch also moves spl_early_init() around ?
[...]
> diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> index 6ad037e325..a5b6931350 100644
> --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> @@ -6,6 +6,8 @@
> #ifndef _RESET_MANAGER_H_
> #define _RESET_MANAGER_H_
>
> +extern phys_addr_t socfpga_rstmgr_base;
Would it make sense to implement a getter function which would return
the reset manager base address , instead of using the extern ?
[...]
> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
> index 49dadd4c3d..901c432f82 100644
> --- a/arch/arm/mach-socfpga/misc.c
> +++ b/arch/arm/mach-socfpga/misc.c
> @@ -22,6 +22,8 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +phys_addr_t socfpga_rstmgr_base __section(".data");
> +
> #ifdef CONFIG_SYS_L2_PL310
> static const struct pl310_regs *const pl310 =
> (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
> @@ -145,6 +147,8 @@ void socfpga_fpga_add(void *fpga_desc)
>
> int arch_cpu_init(void)
> {
> + socfpga_get_manager_addr();
> +
> #ifdef CONFIG_HW_WATCHDOG
> /*
>* In case the watchdog is enabled, make sure to (re-)configure it
> @@ -202,3 +206,31 @@ U_BOOT_CMD(bridge, 3, 1, do_bridge,
> );
>
> #endif
> +
> +static phys_addr_t socfpga_get_base_addr(const char *compat)
> +{
> + const void *blob = gd->fdt_blob;
> + struct fdt_resource r;
> + int node;
> + int ret;
> +
> + node = fdt_node_offset_by_compatible(blob, -1, compat);
> + if (node < 0)
> + return 0;
0 is a valid address, so you want to discern 0 from errors here. I think
if you change the prototype of the function to e.g.
static int socfpga_get_rstmgr_base_addr(const char *compat, phys_addr_t
*base) {} , it should work. Then you can return error values as well as
the base address.
> + if (!fdtdec_get_is_enabled(blob, node))
> + return 0;
> +
> + ret = fdt_get_resource(blob, node, "reg", 0, );
> + if (ret)
> + return 0;
> +
> + return (phys_addr_t)r.start;
> +}
> +
> +void socfpga_get_manager_addr(void)
You should rename this function, a lot of blocks on the Gen5 are called
-manager .
> +{
> + socfpga_rstmgr_base = socfpga_get_base_addr("altr,rst-mgr");
> + if (!socfpga_rstmgr_base)
> + hang();
> +}
[...]
> diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c
> index b820cb0673..a0d80fd47e 100644
> --- a/arch/arm/mach-socfpga/spl_a10.c
> +++ b/arch/arm/mach-socfpga/spl_a10.c
> @@ -106,6 +106,11 @@ void spl_board_init(void)
>
> void board_init_f(ulong dummy)
> {
> + if (spl_early_init())
> + hang();
> +
> + socfpga_get_manager_addr();
> +
> dcache_disable();
>
> socfpga_init_security_policies();
> @@ -116,8 +121,6 @@ void board_init_f(ulong dummy)
> socfpga_per_reset_all();
> socfpga_watchdog_disable();
>
> - spl_early_init();
> -
> /* Configure the clock based on handoff */
> cm_basic_init(gd->fdt_blob);
>
> diff --git a/arch/arm/mach-socfpga/spl_gen5.c
> b/arch/arm/mach-socfpga/spl_gen5.c
> index 47e63709ad..c646331081 100644
> --- a/arch/arm/mach-socfpga/spl_gen5.c
> +++ b/arch/arm/mach-socfpga/spl_gen5.c
> @@ -67,8 +67,14 @@ void board_init_f(ulong dummy)
> int ret;
> struct udevice *dev;
>
> + ret = spl_early_init();
> + if (ret)
> + hang();
> +
> + socfpga_get_manager_addr();
> +
> /*
> - * First C code to run. Clear fake OCRAM ECC first as SBE
> + * Clear fake OCRAM ECC first as SBE
>* and DBE might triggered during power on
>*/
> reg = readl(_regs->eccgrp_ocram);
> @@ -128,12 +134,6 @@ void board_init_f(ulong dummy)
> debug_uart_init();
> #endif
>
> - ret = spl_early_init();
> - if (ret) {
> - debug("spl_early_init() failed: %d\n", ret);
> - hang();
> - }
> -
> ret = uclass_get_device(UCLASS_RESET, 0, );
> if (ret)
> debug("Reset init failed: %d\n", ret);
> diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-socfpga/spl_s10.c
> index ec65e1ce64..9a97a84e1e 100644
> --- a/arch/arm/mach-socfpga/spl_s10.c
> +++ b/arch/arm/mach-socfpga/spl_s10.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -120,6 +121,12 @@ void board_init_f(ulong dummy)
> const struct cm_config *cm_default_cfg = cm_get_default_config();
> int ret;
>
> + ret = spl_early_init();
> + if (ret)
> + hang();
> +
> + socfpga_get_manager_addr();
> +
> #ifdef CONFIG_HW_WATCHDOG
Re: [U-Boot] [PATCH v5 1/4] arm: dts: socfpga: Add u-boot, dm-pre-reloc for sysmgr and clkmgr nodes
On 11/7/19 3:10 AM, Ley Foon Tan wrote:
[...]
> diff --git a/arch/arm/dts/socfpga-common-u-boot.dtsi
> b/arch/arm/dts/socfpga-common-u-boot.dtsi
> index 322c858c4b..d55460755f 100644
> --- a/arch/arm/dts/socfpga-common-u-boot.dtsi
> +++ b/arch/arm/dts/socfpga-common-u-boot.dtsi
> @@ -10,6 +10,10 @@
> };
> };
>
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> {
> u-boot,dm-pre-reloc;
> };
> @@ -17,3 +21,7 @@
> {
> u-boot,dm-pre-reloc;
> };
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
Gen5 doesn't have any clock driver, so does it really make sense to
retain the clkmgr node in SPL now ? Seems like this only grows the SPL
size with no benefit.
[...]
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 4/4] arm: socfpga: Convert clock manager from struct to defines
Convert clock manager for Gen5, Arria 10 and Stratix 10 from struct
to defines.
Change to get clock manager base address from DT node instead of using
#define.
Signed-off-by: Ley Foon Tan
---
v5:
- Change macro value to 0x** format.
v4:
- Update commit message about get base address from DT node.
v3:
- Remove "No functional change" in commit description.
v2:
- Revert to use writel(), readl() and etc.
- Get base address from DT.
- Add prefix to defines.
---
arch/arm/mach-socfpga/clock_manager.c | 12 +-
arch/arm/mach-socfpga/clock_manager_arria10.c | 156 +++--
arch/arm/mach-socfpga/clock_manager_gen5.c| 199 +
arch/arm/mach-socfpga/clock_manager_s10.c | 206 ++
.../mach-socfpga/include/mach/clock_manager.h | 2 +
.../include/mach/clock_manager_arria10.h | 133 +--
.../include/mach/clock_manager_gen5.h | 112 --
.../include/mach/clock_manager_s10.h | 115 --
arch/arm/mach-socfpga/misc.c | 5 +
drivers/mmc/socfpga_dw_mmc.c | 11 +-
10 files changed, 476 insertions(+), 475 deletions(-)
diff --git a/arch/arm/mach-socfpga/clock_manager.c
b/arch/arm/mach-socfpga/clock_manager.c
index 9f3c643df8..09857dc37b 100644
--- a/arch/arm/mach-socfpga/clock_manager.c
+++ b/arch/arm/mach-socfpga/clock_manager.c
@@ -10,18 +10,15 @@
DECLARE_GLOBAL_DATA_PTR;
-static const struct socfpga_clock_manager *clock_manager_base =
- (struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
-
void cm_wait_for_lock(u32 mask)
{
u32 inter_val;
u32 retry = 0;
do {
#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
- inter_val = readl(_manager_base->inter) & mask;
+ inter_val = readl(socfpga_clkmgr_base + CLKMGR_INTER) & mask;
#else
- inter_val = readl(_manager_base->stat) & mask;
+ inter_val = readl(socfpga_clkmgr_base + CLKMGR_STAT) & mask;
#endif
/* Wait for stable lock */
if (inter_val == mask)
@@ -36,8 +33,9 @@ void cm_wait_for_lock(u32 mask)
/* function to poll in the fsm busy bit */
int cm_wait_for_fsm(void)
{
- return wait_for_bit_le32(_manager_base->stat,
-CLKMGR_STAT_BUSY, false, 2, false);
+ return wait_for_bit_le32((const void *)(socfpga_clkmgr_base +
+CLKMGR_STAT), CLKMGR_STAT_BUSY, false, 2,
+false);
}
int set_cpu_clk_info(void)
diff --git a/arch/arm/mach-socfpga/clock_manager_arria10.c
b/arch/arm/mach-socfpga/clock_manager_arria10.c
index 334a79fd9c..33aebd4f47 100644
--- a/arch/arm/mach-socfpga/clock_manager_arria10.c
+++ b/arch/arm/mach-socfpga/clock_manager_arria10.c
@@ -231,9 +231,6 @@ static int of_get_clk_cfg(const void *blob, struct
mainpll_cfg *main_cfg,
return 0;
}
-static const struct socfpga_clock_manager *clock_manager_base =
- (struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
-
/* calculate the intended main VCO frequency based on handoff */
static unsigned int cm_calc_handoff_main_vco_clk_hz
(struct mainpll_cfg *main_cfg)
@@ -551,12 +548,13 @@ static void cm_pll_ramp_main(struct mainpll_cfg *main_cfg,
writel((main_cfg->vco1_denom <<
CLKMGR_MAINPLL_VCO1_DENOM_LSB) |
cm_calc_safe_pll_numer(0, main_cfg, per_cfg, clk_hz),
- _manager_base->main_pll.vco1);
+ socfpga_clkmgr_base + CLKMGR_A10_MAINPLL_VCO1);
mdelay(1);
cm_wait_for_lock(LOCKED_MASK);
}
writel((main_cfg->vco1_denom << CLKMGR_MAINPLL_VCO1_DENOM_LSB) |
- main_cfg->vco1_numer, _manager_base->main_pll.vco1);
+ main_cfg->vco1_numer,
+ socfpga_clkmgr_base + CLKMGR_A10_MAINPLL_VCO1);
mdelay(1);
cm_wait_for_lock(LOCKED_MASK);
}
@@ -579,14 +577,17 @@ static void cm_pll_ramp_periph(struct mainpll_cfg
*main_cfg,
/* execute the ramping here */
for (clk_hz = pll_ramp_periph_hz + clk_incr_hz;
clk_hz < clk_final_hz; clk_hz += clk_incr_hz) {
- writel((per_cfg->vco1_denom << CLKMGR_PERPLL_VCO1_DENOM_LSB) |
- cm_calc_safe_pll_numer(1, main_cfg, per_cfg, clk_hz),
- _manager_base->per_pll.vco1);
+ writel((per_cfg->vco1_denom <<
+ CLKMGR_PERPLL_VCO1_DENOM_LSB) |
+ cm_calc_safe_pll_numer(1, main_cfg, per_cfg,
+clk_hz),
+ socfpga_clkmgr_base + CLKMGR_A10_PERPLL_VCO1);
mdelay(1);
cm_wait_for_lock(LOCKED_MASK);
}
writel((per_cfg->vco1_denom << CLKMGR_PERPLL_VCO1_DENOM_LSB) |
- per_cfg->vco1_numer, _manager_base->per_pll.vco1);
[U-Boot] [PATCH v5 3/4] arm: socfpga: Convert system manager from struct to defines
Convert system manager for Gen5, Arria 10 and Stratix 10 from struct
to defines.
Change to get system manager base address from DT node instead of
using #define.
Signed-off-by: Ley Foon Tan
---
v5:
- Change macro value to 0x** format.
v4:
- Update commit message about get base address from DT node.
v3:
- Remove "No functional change" in commit description.
v2:
- Revert to use writel(), readl() and etc.
- Get base address from DT.
- Add prefix to defines.
---
arch/arm/mach-socfpga/clock_manager_s10.c | 4 +-
.../include/mach/system_manager.h | 2 +
.../include/mach/system_manager_arria10.h | 94 +++--
.../include/mach/system_manager_gen5.h| 123 +++-
.../include/mach/system_manager_s10.h | 184 +++---
arch/arm/mach-socfpga/mailbox_s10.c | 6 +-
arch/arm/mach-socfpga/misc.c | 5 +
arch/arm/mach-socfpga/misc_arria10.c | 9 +-
arch/arm/mach-socfpga/misc_gen5.c | 22 ++-
arch/arm/mach-socfpga/misc_s10.c | 9 +-
arch/arm/mach-socfpga/reset_manager_arria10.c | 24 +--
arch/arm/mach-socfpga/reset_manager_gen5.c| 7 +-
arch/arm/mach-socfpga/reset_manager_s10.c | 18 +-
arch/arm/mach-socfpga/scan_manager.c | 6 +-
arch/arm/mach-socfpga/spl_a10.c | 5 +-
arch/arm/mach-socfpga/spl_gen5.c | 11 +-
arch/arm/mach-socfpga/spl_s10.c | 12 +-
arch/arm/mach-socfpga/system_manager_gen5.c | 38 ++--
arch/arm/mach-socfpga/system_manager_s10.c| 39 ++--
arch/arm/mach-socfpga/wrap_pll_config_s10.c | 11 +-
drivers/ddr/altera/sdram_gen5.c | 10 +-
drivers/ddr/altera/sdram_s10.c| 6 +-
drivers/fpga/socfpga_arria10.c| 7 +-
drivers/fpga/socfpga_gen5.c | 4 +-
drivers/mmc/socfpga_dw_mmc.c | 6 +-
25 files changed, 240 insertions(+), 422 deletions(-)
diff --git a/arch/arm/mach-socfpga/clock_manager_s10.c
b/arch/arm/mach-socfpga/clock_manager_s10.c
index 3ba2a00c02..6cbf07ac6f 100644
--- a/arch/arm/mach-socfpga/clock_manager_s10.c
+++ b/arch/arm/mach-socfpga/clock_manager_s10.c
@@ -14,8 +14,6 @@ DECLARE_GLOBAL_DATA_PTR;
static const struct socfpga_clock_manager *clock_manager_base =
(struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
-static const struct socfpga_system_manager *sysmgr_regs =
- (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
/*
* function to write the bypass register which requires a poll of the
@@ -351,7 +349,7 @@ unsigned int cm_get_l4_sp_clk_hz(void)
unsigned int cm_get_qspi_controller_clk_hz(void)
{
- return readl(_regs->boot_scratch_cold0);
+ return readl(socfpga_sysmgr_base + SYSMGR_S10_BOOT_SCRATCH_COLD0);
}
unsigned int cm_get_spi_controller_clk_hz(void)
diff --git a/arch/arm/mach-socfpga/include/mach/system_manager.h
b/arch/arm/mach-socfpga/include/mach/system_manager.h
index 7e76df74b7..803305eb35 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager.h
@@ -6,6 +6,8 @@
#ifndef _SYSTEM_MANAGER_H_
#define _SYSTEM_MANAGER_H_
+extern phys_addr_t socfpga_sysmgr_base;
+
#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
#include
#else
diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_arria10.h
b/arch/arm/mach-socfpga/include/mach/system_manager_arria10.h
index 14052b957c..e4fc6d2e55 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager_arria10.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager_arria10.h
@@ -6,73 +6,33 @@
#ifndef _SYSTEM_MANAGER_ARRIA10_H_
#define _SYSTEM_MANAGER_ARRIA10_H_
-struct socfpga_system_manager {
- u32 siliconid1;
- u32 siliconid2;
- u32 wddbg;
- u32 bootinfo;
- u32 mpu_ctrl_l2_ecc;
- u32 _pad_0x14_0x1f[3];
- u32 dma;
- u32 dma_periph;
- u32 sdmmcgrp_ctrl;
- u32 sdmmc_l3master;
- u32 nand_bootstrap;
- u32 nand_l3master;
- u32 usb0_l3master;
- u32 usb1_l3master;
- u32 emac_global;
- u32 emac[3];
- u32 _pad_0x50_0x5f[4];
- u32 fpgaintf_en_global;
- u32 fpgaintf_en_0;
- u32 fpgaintf_en_1;
- u32 fpgaintf_en_2;
- u32 fpgaintf_en_3;
- u32 _pad_0x74_0x7f[3];
- u32 noc_addr_remap_value;
- u32 noc_addr_remap_set;
- u32 noc_addr_remap_clear;
- u32 _pad_0x8c_0x8f;
- u32 ecc_intmask_value;
- u32 ecc_intmask_set;
- u32 ecc_intmask_clr;
- u32 ecc_intstatus_serr;
- u32 ecc_intstatus_derr;
- u32 mpu_status_l2_ecc;
- u32 mpu_clear_l2_ecc;
- u32 mpu_status_l1_parity;
- u32 mpu_clear_l1_parity;
- u32 mpu_set_l1_parity;
- u32 _pad_0xb8_0xbf[2];
- u32 noc_timeout;
- u32 noc_idlereq_set;
- u32 noc_idlereq_clr;
- u32 noc_idlereq_value;
- u32
[U-Boot] [PATCH v5 2/4] arm: socfpga: Convert reset manager from struct to defines
Convert reset manager for Gen5, Arria 10 and Stratix 10 from struct
to defines.
Change to get reset manager base address from DT node instead of using
#define.
Signed-off-by: Ley Foon Tan
---
v5:
- Change macro values with 0x** format.
v4:
- Update commit message about get base address from DT node.
v3:
- Remove "No functional change" in commit description.
v2:
- Get base address from DT
- Revert to use writel(), readl(), setbits_le32() and clrbits_le32().
- Add prefix to defines.
---
arch/arm/mach-socfpga/include/mach/misc.h | 1 +
.../mach-socfpga/include/mach/reset_manager.h | 2 +
.../include/mach/reset_manager_arria10.h | 43 -
.../include/mach/reset_manager_gen5.h | 22 -
.../include/mach/reset_manager_s10.h | 33 ++---
arch/arm/mach-socfpga/misc.c | 32 +
arch/arm/mach-socfpga/misc_gen5.c | 7 ++-
arch/arm/mach-socfpga/reset_manager_arria10.c | 47 ++-
arch/arm/mach-socfpga/reset_manager_gen5.c| 28 +--
arch/arm/mach-socfpga/reset_manager_s10.c | 34 +++---
arch/arm/mach-socfpga/spl_a10.c | 7 ++-
arch/arm/mach-socfpga/spl_gen5.c | 14 +++---
arch/arm/mach-socfpga/spl_s10.c | 12 +++--
drivers/sysreset/sysreset_socfpga.c | 6 +--
14 files changed, 138 insertions(+), 150 deletions(-)
diff --git a/arch/arm/mach-socfpga/include/mach/misc.h
b/arch/arm/mach-socfpga/include/mach/misc.h
index 27d0b6a370..a29b049742 100644
--- a/arch/arm/mach-socfpga/include/mach/misc.h
+++ b/arch/arm/mach-socfpga/include/mach/misc.h
@@ -41,5 +41,6 @@ void socfpga_sdram_remap_zero(void);
void do_bridge_reset(int enable, unsigned int mask);
void socfpga_pl310_clear(void);
+void socfpga_get_manager_addr(void);
#endif /* _MISC_H_ */
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index 6ad037e325..a5b6931350 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -6,6 +6,8 @@
#ifndef _RESET_MANAGER_H_
#define _RESET_MANAGER_H_
+extern phys_addr_t socfpga_rstmgr_base;
+
void reset_cpu(ulong addr);
void socfpga_per_reset(u32 reset, int set);
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
b/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
index 6623ebee65..22e4eb33de 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
@@ -14,40 +14,15 @@ int socfpga_reset_deassert_bridges_handoff(void);
void socfpga_reset_deassert_osc1wd0(void);
int socfpga_bridges_reset(void);
-struct socfpga_reset_manager {
- u32 stat;
- u32 ramstat;
- u32 miscstat;
- u32 ctrl;
- u32 hdsken;
- u32 hdskreq;
- u32 hdskack;
- u32 counts;
- u32 mpumodrst;
- u32 per0modrst;
- u32 per1modrst;
- u32 brgmodrst;
- u32 sysmodrst;
- u32 coldmodrst;
- u32 nrstmodrst;
- u32 dbgmodrst;
- u32 mpuwarmmask;
- u32 per0warmmask;
- u32 per1warmmask;
- u32 brgwarmmask;
- u32 syswarmmask;
- u32 nrstwarmmask;
- u32 l3warmmask;
- u32 tststa;
- u32 tstscratch;
- u32 hdsktimeout;
- u32 hmcintr;
- u32 hmcintren;
- u32 hmcintrens;
- u32 hmcintrenr;
- u32 hmcgpout;
- u32 hmcgpin;
-};
+#define RSTMGR_A10_STATUS 0x00
+#define RSTMGR_A10_CTRL0x0c
+#define RSTMGR_A10_MPUMODRST 0x20
+#define RSTMGR_A10_PER0MODRST 0x24
+#define RSTMGR_A10_PER1MODRST 0x28
+#define RSTMGR_A10_BRGMODRST 0x2c
+#define RSTMGR_A10_SYSMODRST 0x30
+
+#define RSTMGR_CTRLRSTMGR_A10_CTRL
/*
* SocFPGA Arria10 reset IDs, bank mapping is as follows:
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
b/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
index f4dcb14623..d108eac1e2 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
@@ -11,19 +11,15 @@
void socfpga_bridges_set_handoff_regs(bool h2f, bool lwh2f, bool f2h);
void socfpga_bridges_reset(int enable);
-struct socfpga_reset_manager {
- u32 status;
- u32 ctrl;
- u32 counts;
- u32 padding1;
- u32 mpu_mod_reset;
- u32 per_mod_reset;
- u32 per2_mod_reset;
- u32 brg_mod_reset;
- u32 misc_mod_reset;
- u32 padding2[12];
- u32 tstscratch;
-};
+#define RSTMGR_GEN5_STATUS 0x00
+#define RSTMGR_GEN5_CTRL 0x04
+#define RSTMGR_GEN5_MPUMODRST 0x10
+#define RSTMGR_GEN5_PERMODRST 0x14
+#define RSTMGR_GEN5_PER2MODRST 0x18
[U-Boot] [PATCH v5 1/4] arm: dts: socfpga: Add u-boot, dm-pre-reloc for sysmgr and clkmgr nodes
Add u-boot,dm-pre-reloc for sysmgr and clkmgr nodes to use it in SPL.
In preparation to get base address from DT.
Signed-off-by: Ley Foon Tan
Reviewed-by: Simon Goldschmidt
---
v3:
- Fix missing '0' in clkmgr@ffd1 node.
---
arch/arm/dts/socfpga-common-u-boot.dtsi | 8
arch/arm/dts/socfpga.dtsi| 2 +-
arch/arm/dts/socfpga_arria10.dtsi| 2 +-
arch/arm/dts/socfpga_arria10_socdk.dtsi | 8
arch/arm/dts/socfpga_stratix10.dtsi | 2 +-
arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi | 8
6 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/socfpga-common-u-boot.dtsi
b/arch/arm/dts/socfpga-common-u-boot.dtsi
index 322c858c4b..d55460755f 100644
--- a/arch/arm/dts/socfpga-common-u-boot.dtsi
+++ b/arch/arm/dts/socfpga-common-u-boot.dtsi
@@ -10,6 +10,10 @@
};
};
+ {
+ u-boot,dm-pre-reloc;
+};
+
{
u-boot,dm-pre-reloc;
};
@@ -17,3 +21,7 @@
{
u-boot,dm-pre-reloc;
};
+
+ {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
index 51a6a51b53..eda558f2fe 100644
--- a/arch/arm/dts/socfpga.dtsi
+++ b/arch/arm/dts/socfpga.dtsi
@@ -114,7 +114,7 @@
status = "disabled";
};
- clkmgr@ffd04000 {
+ clkmgr: clkmgr@ffd04000 {
compatible = "altr,clk-mgr";
reg = <0xffd04000 0x1000>;
diff --git a/arch/arm/dts/socfpga_arria10.dtsi
b/arch/arm/dts/socfpga_arria10.dtsi
index c11a5c0cc1..cc529bcd11 100644
--- a/arch/arm/dts/socfpga_arria10.dtsi
+++ b/arch/arm/dts/socfpga_arria10.dtsi
@@ -96,7 +96,7 @@
fpga-mgr = <_mgr>;
};
- clkmgr@ffd04000 {
+ clkmgr: clkmgr@ffd04000 {
compatible = "altr,clk-mgr";
reg = <0xffd04000 0x1000>;
u-boot,dm-pre-reloc;
diff --git a/arch/arm/dts/socfpga_arria10_socdk.dtsi
b/arch/arm/dts/socfpga_arria10_socdk.dtsi
index 6e5578d7bd..ef10708ee8 100644
--- a/arch/arm/dts/socfpga_arria10_socdk.dtsi
+++ b/arch/arm/dts/socfpga_arria10_socdk.dtsi
@@ -180,3 +180,11 @@
_sp_clk {
u-boot,dm-pre-reloc;
};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/socfpga_stratix10.dtsi
b/arch/arm/dts/socfpga_stratix10.dtsi
index bd68a78a37..a8e61cf728 100755
--- a/arch/arm/dts/socfpga_stratix10.dtsi
+++ b/arch/arm/dts/socfpga_stratix10.dtsi
@@ -82,7 +82,7 @@
ranges = <0 0 0 0x>;
u-boot,dm-pre-reloc;
- clkmgr@ffd1000 {
+ clkmgr: clkmgr@ffd1 {
compatible = "altr,clk-mgr";
reg = <0xffd1 0x1000>;
};
diff --git a/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
b/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
index e1cfb522bf..38855aecd7 100755
--- a/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
@@ -11,6 +11,10 @@
};
};
+ {
+ u-boot,dm-pre-reloc;
+};
+
{
status = "okay";
u-boot,dm-pre-reloc;
@@ -23,3 +27,7 @@
spi-rx-bus-width = <4>;
u-boot,dm-pre-reloc;
};
+
+ {
+ u-boot,dm-pre-reloc;
+};
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 0/4] arm: socfpga: Convert drivers from struct to defines
This is 5th version of patchset to convert reset, system and clock manager drivers to use #define instead of struct. Patch 1 unchanged, patch 2,3,4 change macro value to 0x** format. Tested on Cyclone 5, Arria 10 and Stratix 10 devices. Changes in v5: - Patch 2,3,4: Change macro value to 0x** format. History: v1: https://patchwork.ozlabs.org/cover/1149731/ v2: https://patchwork.ozlabs.org/cover/1160079/ v3: https://patchwork.ozlabs.org/cover/1174327/ v4: https://patchwork.ozlabs.org/cover/1174347/ Ley Foon Tan (4): arm: dts: socfpga: Add u-boot,dm-pre-reloc for sysmgr and clkmgr nodes arm: socfpga: Convert reset manager from struct to defines arm: socfpga: Convert system manager from struct to defines arm: socfpga: Convert clock manager from struct to defines arch/arm/dts/socfpga-common-u-boot.dtsi | 8 + arch/arm/dts/socfpga.dtsi | 2 +- arch/arm/dts/socfpga_arria10.dtsi | 2 +- arch/arm/dts/socfpga_arria10_socdk.dtsi | 8 + arch/arm/dts/socfpga_stratix10.dtsi | 2 +- .../dts/socfpga_stratix10_socdk-u-boot.dtsi | 8 + arch/arm/mach-socfpga/clock_manager.c | 12 +- arch/arm/mach-socfpga/clock_manager_arria10.c | 156 +++-- arch/arm/mach-socfpga/clock_manager_gen5.c| 199 + arch/arm/mach-socfpga/clock_manager_s10.c | 210 ++ .../mach-socfpga/include/mach/clock_manager.h | 2 + .../include/mach/clock_manager_arria10.h | 133 +-- .../include/mach/clock_manager_gen5.h | 112 -- .../include/mach/clock_manager_s10.h | 115 -- arch/arm/mach-socfpga/include/mach/misc.h | 1 + .../mach-socfpga/include/mach/reset_manager.h | 2 + .../include/mach/reset_manager_arria10.h | 43 +--- .../include/mach/reset_manager_gen5.h | 22 +- .../include/mach/reset_manager_s10.h | 33 +-- .../include/mach/system_manager.h | 2 + .../include/mach/system_manager_arria10.h | 94 +++- .../include/mach/system_manager_gen5.h| 123 ++ .../include/mach/system_manager_s10.h | 184 ++- arch/arm/mach-socfpga/mailbox_s10.c | 6 +- arch/arm/mach-socfpga/misc.c | 42 arch/arm/mach-socfpga/misc_arria10.c | 9 +- arch/arm/mach-socfpga/misc_gen5.c | 29 +-- arch/arm/mach-socfpga/misc_s10.c | 9 +- arch/arm/mach-socfpga/reset_manager_arria10.c | 71 +++--- arch/arm/mach-socfpga/reset_manager_gen5.c| 35 ++- arch/arm/mach-socfpga/reset_manager_s10.c | 52 +++-- arch/arm/mach-socfpga/scan_manager.c | 6 +- arch/arm/mach-socfpga/spl_a10.c | 12 +- arch/arm/mach-socfpga/spl_gen5.c | 25 +-- arch/arm/mach-socfpga/spl_s10.c | 24 +- arch/arm/mach-socfpga/system_manager_gen5.c | 38 ++-- arch/arm/mach-socfpga/system_manager_s10.c| 39 ++-- arch/arm/mach-socfpga/wrap_pll_config_s10.c | 11 +- drivers/ddr/altera/sdram_gen5.c | 10 +- drivers/ddr/altera/sdram_s10.c| 6 +- drivers/fpga/socfpga_arria10.c| 7 +- drivers/fpga/socfpga_gen5.c | 4 +- drivers/mmc/socfpga_dw_mmc.c | 17 +- drivers/sysreset/sysreset_socfpga.c | 6 +- 44 files changed, 881 insertions(+), 1050 deletions(-) -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
Hi Anup > On Wed, Nov 6, 2019 at 2:51 PM Rick Chen wrote: > > > > Hi Anup > > > > > > > > On Wed, Nov 6, 2019 at 2:18 PM Anup Patel wrote: > > > > > > > > On Wed, Nov 6, 2019 at 12:14 PM Rick Chen wrote: > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2019 at 7:19 AM Rick Chen > > > > > > wrote: > > > > > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 1:42 PM Anup Patel > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 6:30 AM Alan Kao > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > > > > > > > > > Thanks for the critics. Comments below. > > > > > > > > > > > On Wed, Oct 30, 2019 at 06:38:00PM +0800, Bin Meng wrote: > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 10:50 AM Rick Chen > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 25, 2019 at 2:18 PM Andes > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Rick Chen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It will work fine due to hart 0 always will be > > > > > > > > > > > > > > > main > > > > > > > > > > > > > > > hart coincidentally. When develop SPL flow, I try > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > force other harts to be main hart. And it will go > > > > > > > > > > > > > > > wrong in sending IPI flow. So fix it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Fix what? Does this commit contain 2 fixes, or just > > > > > > > > > > > > > > 1 fix? > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, it include two fixs. But they will cause one > > > > > > > > > > > > > negative result > > > > > > > > > > > > > that only hart 0 can send ipi to other harts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Having this fix, any hart can be main hart in > > > > > > > > > > > > > > > U-Boot SPL > > > > > > > > > > > > > > > theoretically, but it still fail somewhere. After > > > > > > > > > > > > > > > dig in > > > > > > > > > > > > > > > and found there is an assumption that hart 0 > > > > > > > > > > > > > > > shall be > > > > > > > > > > > > > > > main hart in OpenSbi. > > > > > > > > > > > > > > > > > > > > > > > > > > > > So does this mean there is a bug in OpenSBI too? > > > > > > > > > > > > > > > > > > > > > > > > > > I am not sure if it is a bug. Maybe it is a > > > > > > > > > > > > > compatible issue. > > > > > > > > > > > > > There is a limitation that only hart 0 can be main > > > > > > > > > > > > > hart in OpenSBI. > > > > > > > > > > > > > > > > > > > > > > > > I don't think OpenSBI has such limitation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please check the source. > > > > > > > > > > > https://github.com/riscv/opensbi/blob/master/firmware/fw_base.S#L54 > > > > > > > > > > > > > > > > > > > > > > Apparently, the FIRST TWO LINEs of the initialization are > > > > > > > > > > > the > > > > > > > > > > > 1. get hart ID. > > > > > > > > > > > 2. determine which route to take based on their ID > > > > > > > > > > > respectively. > > > > > > > > > > > > > > > > > > > > > > So, I do think OpenSBI has this signature, if you are not > > > > > > > > > > > willing to call it > > > > > > > > > > > a limitation. > > > > > > > > > > > > > > > > > > > > This dependency on hart id #0 was not there until we added > > > > > > > > > > self-relocation > > > > > > > > > > in OpenSBI for FW_DYNAMIC. > > > > > > > > > > > > > > > > > > > > I will try to fix this in OpenSBI but we might end-up > > > > > > > > > > having boot_lottery. > > > > > > > > > > > > > > > > > > I have send a patch to fix this OpenSBI: > > > > > > > > > "[PATCH] firmware: Introduce relocation lottery" > > > > > > > > > > > > > > > > > > Can you try above patch and see if that helps ? > > > > > > > > > > > > > > > > > > It will be great if you can provide Tested-by to my patch as > > > > > > > > > well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I can not find this patch in mailing list. > > > > > > > Can you provide a hyperlink ? > > > > > > > > > > > > You can try latest riscv/opensbi master. > > > > > > > > > > > > I have tested the patch on SiFive Unleashed multiple times. > > > > > > > > > > I have tried this patch, but it fail > > > > > firmware: Introduce relocation lottery( > > > > > 98f4a208995b027662a7b04a25e4fa5df5f3eefe) > > > > > > > > > > The scenario was as below: > > > > > There are 4 harts run in U-Boot SPL, hart 0 play as main hart. > > > > > The hart 1 will receive ipi and come into OpenSBI(0x100) from > > > > >
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Wed, Nov 06, 2019 at 12:03:23AM +, Aaron Williams wrote: > Hi Tom, > > > From: Tom Rini > Sent: Tuesday, November 5, 2019 6:16 AM > To: Wolfgang Denk > Cc: Aaron Williams; Daniel Schwierzeck; u-boot@lists.denx.de > Subject: Re: [EXT] Re: Cavium/Marvell Octeon Support > > On Tue, Nov 05, 2019 at 09:33:35AM +0100, Wolfgang Denk wrote: > > Dear Aaron, > > > > In message <5376617.97hUrJXovB@flash> you wrote: > > > > > > > Again you don't answer my question. Why do you need a special new > > > > API for such code? Why do you not just link that code with the rest > > > > of U-Boot? > > > > > > The code in question that is calling the API is not GPL and hence cannot > > > be > > > linked with U-Boot though the phy code is GPL. > > > > Ouch. I was afraid to hear that. > > > > Please be aware that your newly created API does NOT implement a GPL > > license exception. the only interface that allows for non-GPL code > > to be run under control of U-Boot is the standalone program > > interface, which is intentionally very restricted. > > > > In other words: what you are doing here is a clear (and intentional, > > which makes it even worse) GPL license violation. > > > > > > It has been mentioned before, but just to be sure: this code which > > > > uses your new API is licensed under a GPLv2 conforming lincense? > > > > > > > There should be no need. None of the code is linked against U-Boot, > > > either at > > > compile time nor at runtime. The application doesn't even know where it is > > > located except by looking for a named block of memory. > > > > It does not have to be linked. You access internal interfaces of > > U-Boot that have not been exported for non-GPL use, so your code > > still has to be licensed under GPLv2 or a compatible license. > > I'm just following up to say that I agree with Wolfgang here. > > Sorry for the broken formatting (our IT department forces the Outhouse web > client). > > I think there is some misunderstanding here. All of the code we include in > U-Boot IS GPL or GPL compatible, including the API. > > "Even though U-Boot in general is covered by the GPL-2.0/GPL-2.0+, > this does *not* cover the so-called "standalone" applications that > use U-Boot services by means of the jump table provided by U-Boot > exactly for this purpose - this is merely considered normal use of > U-Boot, and does *not* fall under the heading of "derived work"." > > No part of U-Boot is included in these applications and no application code > is included in U-Boot. We DO have SDK files used in U-Boot, but the SDK files > are under a BSD-like license, basically do whatever you want with the code > but don't hold us responsible. The SDK code is also used in stand-alone > applications as well as the Linux kernel, where derivatives were upstreamed > long-ago. > > In any event, I think at this point we can remove this support. I don't think > it's used any longer. It also looks like EFI does allow for vendor defined > services. I hadn't looked at this code for a while but looking at it again it > also appears the phy code has been removed. I think the remaining code for > QLM configuration could be modified to just use a hook from some environment > variables, removing this issue entirely. Not needing to worry about how to deal with this support is indeed the best case for everyone, 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] gitlab/azure: Enable LLVM tests
Now that we have again fixed the problems that building with clang
exposes, enable these tests on Azure and GitLab-CI as well.
Signed-off-by: Tom Rini
---
.azure-pipelines.yml | 5 +
.gitlab-ci.yml | 8
2 files changed, 13 insertions(+)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 862cced1cc56..44a76ebb09b5 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -149,6 +149,10 @@ jobs:
sandbox:
TEST_PY_BD: "sandbox"
BUILDMAN: "^sandbox$"
+sandbox_clang:
+ TEST_PY_BD: "sandbox"
+ BUILDMAN: "^sandbox$"
+ OVERRIDE: "-O clang-7"
sandbox_spl:
TEST_PY_BD: "sandbox_spl"
TEST_PY_TEST_SPEC: "test_ofplatdata"
@@ -238,6 +242,7 @@ jobs:
export TEST_PY_ID="${TEST_PY_ID}"
export TEST_PY_TEST_SPEC="${TEST_PY_TEST_SPEC}"
export BUILDMAN="${BUILDMAN}"
+ export OVERRIDE="${OVERRIDE}"
EOF
cat << "EOF" >> test.sh
# the below corresponds to .gitlab-ci.yml "before_script"
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 9b295ac710fe..0f5271dcd308 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -178,6 +178,14 @@ sandbox test.py:
BUILDMAN: "^sandbox$"
<<: *buildman_and_testpy_dfn
+sandbox with clang test.py:
+ tags: [ 'all' ]
+ variables:
+TEST_PY_BD: "sandbox"
+BUILDMAN: "^sandbox$"
+OVERRIDE: "-O clang-7"
+ <<: *buildman_and_testpy_dfn
+
sandbox_spl test.py:
tags: [ 'all' ]
variables:
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] binman: tegra: Adjust symbol calculation depending on end-at-4gb
A recent change adjusted the symbol calculation to work on x86 but broke it for Tegra. In fact this is because they have different needs. On x86 devices the code is linked to a ROM address and the end-at-4gb property is used for the image. In this case there is no need to add the base address of the image, since the base address is already built into the offset and image-pos properties. On other devices we must add the base address since the offsets start at zero. In addition the base address is currently added to the 'offset' and 'size' values. It should in fact only be added to 'image-pos', since 'offset' is relative to its parent and 'size' is not actually an address. This code should have been adjusted when support for 'image-pos' and 'size' was added, but it was not. To correct these problems: - move the code that handles adding the base address to section.py, which can check the end-at-4gb property and which property (offset/size/image-pos) is being read - add the base address only when needed (only for image-pos and not if the image uses end-at-4gb) - add a note to the documentation - add a separate test to cover x86 behaviour Fixes: 15c981cc (binman: Correct symbol calculation with non-zero image base) Signed-off-by: Simon Glass --- tools/binman/README | 34 +++- tools/binman/elf.py | 2 +- tools/binman/elf_test.py | 2 +- tools/binman/etype/section.py| 18 +-- tools/binman/ftest.py| 28 +++- tools/binman/image_test.py | 8 ++--- tools/binman/test/155_symbols_tpl_x86.dts| 31 ++ tools/binman/test/Makefile | 6 +++- tools/binman/test/u_boot_binman_syms_x86.c | 1 + tools/binman/test/u_boot_binman_syms_x86.lds | 30 + 10 files changed, 134 insertions(+), 26 deletions(-) create mode 100644 tools/binman/test/155_symbols_tpl_x86.dts create mode 12 tools/binman/test/u_boot_binman_syms_x86.c create mode 100644 tools/binman/test/u_boot_binman_syms_x86.lds diff --git a/tools/binman/README b/tools/binman/README index c96a564226..20a80944e2 100644 --- a/tools/binman/README +++ b/tools/binman/README @@ -766,20 +766,38 @@ when SPL is finished. Binman allows you to declare symbols in the SPL image which are filled in with their correct values during the build. For example: -binman_sym_declare(ulong, u_boot_any, offset); +binman_sym_declare(ulong, u_boot_any, image_pos); -declares a ulong value which will be assigned to the offset of any U-Boot +declares a ulong value which will be assigned to the image-pos of any U-Boot image (u-boot.bin, u-boot.img, u-boot-nodtb.bin) that is present in the image. You can access this value with something like: -ulong u_boot_offset = binman_sym(ulong, u_boot_any, offset); +ulong u_boot_offset = binman_sym(ulong, u_boot_any, image_pos); -Thus u_boot_offset will be set to the offset of U-Boot in memory, assuming that -the whole image has been loaded, or is available in flash. You can then jump to -that address to start U-Boot. +Thus u_boot_offset will be set to the image-pos of U-Boot in memory, assuming +that the whole image has been loaded, or is available in flash. You can then +jump to that address to start U-Boot. -At present this feature is only supported in SPL. In principle it is possible -to fill in such symbols in U-Boot proper, as well. +At present this feature is only supported in SPL and TPL. In principle it is +possible to fill in such symbols in U-Boot proper, as well, but a future C +library is planned for this instead, to read from the device tree. + +As well as image-pos, it is possible to read the size of an entry and its +offset (which is the start position of the entry within its parent). + +A small technical note: Binman automatically adds the base address of the image +(i.e. __image_copy_start) to the value of the image-pos symbol, so that when the +image is loaded to its linked address, the value will be correct and actually +point into the image. + +For example, say SPL is at the start of the image and linked to start at address +80108000. If U-Boot's image-pos is 0x8000 then binman will write an image-pos +for U-Boot of 8011 into the SPL binary, since it assumes the image is loaded +to 80108000, with SPL at 80108000 and U-Boot at 8011. + +For x86 devices (with the end-at-4gb property) this base address is not added +since it is assumed that images are XIP and the offsets already include the +address. Access to binman entry offsets at run time (fdt) diff --git a/tools/binman/elf.py b/tools/binman/elf.py index 0c1a5b44b6..de1ce73f2a 100644 --- a/tools/binman/elf.py +++ b/tools/binman/elf.py @@ -134,7 +134,7 @@ def LookupAndWriteSymbols(elf_fname, entry, section): (msg, sym.size)) # Look up the symbol in our entry tables.
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Wed, Nov 06, 2019 at 10:18:45PM +, Aaron Williams wrote: > Hi Wolfgang, > > On Wednesday, November 6, 2019 7:06:17 AM PST Wolfgang Denk wrote: > > Dear Aaron, > > > > In message > > > you wrote: > > > > Definitely not. You could not implement any of this without heavily > > > > relyin on and deriving from internal interfaces of U-Boot which are > > > > not exported for non-GPL use. > > > > > > See > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.gnu.org_licenses > > > _old-2Dlicenses_gpl-2D2.0-2Dfaq.en.html-23GPLInProp-3D=DwIDaQ=nKjWec2b > > > 6R0mOyPaz7xtfQ=3yfMNumMHGMnOfmVc0dViBi3fJfF8ZXRL_aRWSIGwm4=a19tqjpYreP > > > S1AEd1tHmUya1hcqvHmvs57fTB9c5I50=rp_kzh8HU_FV56RrXpf-0DCuegF0rrporRqWwdT > > > MiR0= rietarySystem > > > > > > This behaves exactly in the manner that is permitted by the GPL. > > > They are completely separate programs. > > > > Are they? > > > > You wrote: > > > > "There is no linking. Only a call table descriptor is published in a > > named block of memory." > > > > I can only interpret from that that there is a call table, where your > > applications call into interfaces that have not been exported for > > non-GPL use. This is not what I call "completely separate". > > > > > > Best regards, > > > > Wolfgang Denk > > Calling directly into U-Boot would be bad. We don't do that. It wouldn't work > anyway on our 32-bit bootloader due to the required TLB mapping. > > There is no call table. There is a single XKPhys address that points to some > assembly code that saves the state of the calling application and sets up the > memory mapping and stack for U-Boot (we map it to 0xC000) then > look at an opcode that's passed and parameters. From there it performs one of > several functions based on the opcode. On the way out the reverse is done, > the > state is restored and the TLB restored before returning to the outside > application. The calling application has its own virtual memory map, so that > has to be saved and restored on entry by the assembly code as well. > > Since U-Boot uses a TLB for mapping, it's just not possible for an outside > application to call into U-Boot using a function table, so everything must go > through the one assembly function. The old U-Boot code was written before EFI > support was added. It looks like I'll be removing it anyway, though. We have > never exported any U-Boot functions save for the assembly code and the API > functionality. The API functionality was not usable by our applications since > our applications were typically 64-bit whereas our old U-Boot was 32-bit > running in mapped memory (0xC000/0xC000) and physically > located at the top of physical memory. Alright, so I think here's the important thing to look at moving forward. In mainline U-Boot, the options for communication between closed source components and U-Boot itself (where GPLv2 is the minimum license) are either the defined ABI or making use of the EFI ABI. We do not want to add or support a 3rd method. 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] [GIT] Pull request: u-boot-dfu (06.11.2019)
On 11/6/19 1:27 PM, Lukasz Majewski wrote: > Hi Marek, Hi, >> On 11/6/19 12:27 PM, Lukasz Majewski wrote: >>> Hi Marek, >>> On 11/6/19 10:21 AM, Lukasz Majewski wrote: > Dear Marek, > > The following changes since commit > 14d39c9e1dc9397febd58399a70f32e7481bbc27: > > travis: Rework how we write the ~/.buildman file (2019-11-05 > 10:44:16 -0500) > > are available in the Git repository at: > > g...@gitlab.denx.de:u-boot/custodians/u-boot-dfu.git > > BRANCH: master > https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/commits/master > > Merge TAG: > https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/-/tags/u-boot-dfu-06Nov2019 > > for you to fetch changes up to > 8c5df588e89b2bf4aad4c95b17cfc8634b8dcaaf: > > usb: composite: add BOS descriptor support to composite > framework (2019-11-06 01:01:06 +0100) > > > My remark: > > - Those patches are new code, (like adding the USB 3.0 controller > from Cadence) hence IMHO it would be best to add them to your next > PR We are already in -rc cycle, so fixes only. Should this PR be for -next ? >>> >>> The BOS support is a fix do SS USB. >>> >>> And the Cadence USB support is a new code, which is not touching any >>> relevant parts of USB (and IMHO it applies to the same category as >>> adding new boards outside the merge window). >>> >>> However, if you believe that this code is not eligible for >>> u-boot-usb/master ,then yes please pull it into -next. >> >> That decision is up to you. If you think this is safe to pull in RC1, >> I don't mind either way. > > Ok. Lets then pull it in RC1. Thanks for understanding :-) Pulled, thanks. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Add support for imxrt
Hi Fabio, On 10/9/19 6:03 PM, Fabio Estevam wrote: Hi Giulio, On Wed, Oct 9, 2019 at 12:59 PM Giulio Benetti wrote: Hi Fabio and Stefano, On 9/29/19 9:40 PM, Fabio Estevam wrote: We try to use DM in U-Boot proper as much as possible, but using DM in SPL is currently not a requirement, especially due to internal RAM size constraints. IOMUXC and LPUART(using 24Mhz clock) work correctly using DM. About clk drivers, I've seen all around that they are very shrinked Linux's version drivers. Would it make sense to add complete clk driver in u-boot starting from Linux one(i.e. vf610) or it would only grow size? I mean, after adding initial support I would like to add Lcd controller driver etc. etc. so a complete driver would be useful. Instead what I see on IMX6 clk driver is only a subsection of all PLLs and ref_sel to start Linux up. Yes, since you are adding this from scratch, I would suggest adding a complete clock driver, which is close to the Linux driver. With this you mean adding every single mux, divider, gate, fixed_factor and pfd(i.e. linux/drivers/clk/imx/clk-imxq6.c)? Or only a shrinked version of that? I mean, is it ok if I list everything during imxrt_clk_probe()? Thanks in advance -- Giulio Benetti Benetti Engineering sas ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Hi Wolfgang, On Wednesday, November 6, 2019 7:06:17 AM PST Wolfgang Denk wrote: > Dear Aaron, > > In message you wrote: > > > Definitely not. You could not implement any of this without heavily > > > relyin on and deriving from internal interfaces of U-Boot which are > > > not exported for non-GPL use. > > > > See > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.gnu.org_licenses > > _old-2Dlicenses_gpl-2D2.0-2Dfaq.en.html-23GPLInProp-3D=DwIDaQ=nKjWec2b > > 6R0mOyPaz7xtfQ=3yfMNumMHGMnOfmVc0dViBi3fJfF8ZXRL_aRWSIGwm4=a19tqjpYreP > > S1AEd1tHmUya1hcqvHmvs57fTB9c5I50=rp_kzh8HU_FV56RrXpf-0DCuegF0rrporRqWwdT > > MiR0= rietarySystem > > > > This behaves exactly in the manner that is permitted by the GPL. > > They are completely separate programs. > > Are they? > > You wrote: > > "There is no linking. Only a call table descriptor is published in a > named block of memory." > > I can only interpret from that that there is a call table, where your > applications call into interfaces that have not been exported for > non-GPL use. This is not what I call "completely separate". > > > Best regards, > > Wolfgang Denk Calling directly into U-Boot would be bad. We don't do that. It wouldn't work anyway on our 32-bit bootloader due to the required TLB mapping. There is no call table. There is a single XKPhys address that points to some assembly code that saves the state of the calling application and sets up the memory mapping and stack for U-Boot (we map it to 0xC000) then look at an opcode that's passed and parameters. From there it performs one of several functions based on the opcode. On the way out the reverse is done, the state is restored and the TLB restored before returning to the outside application. The calling application has its own virtual memory map, so that has to be saved and restored on entry by the assembly code as well. Since U-Boot uses a TLB for mapping, it's just not possible for an outside application to call into U-Boot using a function table, so everything must go through the one assembly function. The old U-Boot code was written before EFI support was added. It looks like I'll be removing it anyway, though. We have never exported any U-Boot functions save for the assembly code and the API functionality. The API functionality was not usable by our applications since our applications were typically 64-bit whereas our old U-Boot was 32-bit running in mapped memory (0xC000/0xC000) and physically located at the top of physical memory. -Aaron ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC/RFT PATCH v3 3/3] image: Add compressed Image parsing support in booti.
Add compressed Image parsing support so that booti can parse both
flat and compressed Image to boot Linux. Currently, it is difficult
to calculate a safe address for every board where the compressed
image can be decompressed. It is also not possible to figure out the
size of the compressed file as well. Thus, user need to set two
additional environment variables kernel_comp_addr_r and filesize to
make this work.
Following compression methods are supported for now.
lzma, lzo, bzip2, gzip.
lz4 support is not added as ARM64 kernel generates a lz4 compressed
image with legacy header which U-Boot doesn't know how to parse and
decompress.
Tested on HiFive Unleashed and Qemu for RISC-V.
Tested on Qemu for ARM64.
Signed-off-by: Atish Patra
---
I could not test this patch on any ARM64 boards due to lack of
access to any ARM64 board. If anybody can test it on ARM64, that
would be great.
---
cmd/booti.c| 39 ++-
doc/README.distro | 12 +
doc/board/sifive/fu540.rst | 55 ++
3 files changed, 105 insertions(+), 1 deletion(-)
diff --git a/cmd/booti.c b/cmd/booti.c
index c36b0235df8c..531de507149c 100644
--- a/cmd/booti.c
+++ b/cmd/booti.c
@@ -13,6 +13,7 @@
#include
#include
+DECLARE_GLOBAL_DATA_PTR;
/*
* Image booting support
*/
@@ -23,6 +24,11 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
ulong ld;
ulong relocated_addr;
ulong image_size;
+ uint8_t *temp;
+ ulong dest;
+ ulong dest_end;
+ unsigned long comp_len;
+ int ctype;
ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
images, 1);
@@ -37,6 +43,33 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
debug("* kernel: cmdline image address = 0x%08lx\n", ld);
}
+ temp = map_sysmem(ld, 0);
+ ctype = image_decomp_type(temp, 2);
+ if (ctype > 0) {
+ dest = env_get_ulong("kernel_comp_addr_r", 16, 0);
+ comp_len = env_get_ulong("filesize", 16, 0);
+ if (!dest || !comp_len) {
+ puts("kernel_comp_addr_r or filesize is not
provided!\n");
+ return -EINVAL;
+ }
+ if (dest < gd->ram_base || dest > gd->ram_top) {
+ puts("kernel_comp_addr_r is outside of DRAM range!\n");
+ return -EINVAL;
+ }
+
+ debug("kernel image compression type %d size = 0x%08lx address
= 0x%08lx\n",
+ ctype, comp_len, (ulong)dest);
+
+ ret = image_decomp(ctype, 0, ld, IH_TYPE_KERNEL,
+(void *)dest, (void *)ld, comp_len,
+CONFIG_SYS_BOOTM_LEN, _end);
+ if (ret)
+ return ret;
+ /* dest_end contains the uncompressed Image size */
+ memmove((void *) ld, (void *)dest, dest_end);
+ }
+ unmap_sysmem((void *)ld);
+
ret = booti_setup(ld, _addr, _size, false);
if (ret != 0)
return 1;
@@ -96,10 +129,14 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
#ifdef CONFIG_SYS_LONGHELP
static char booti_help_text[] =
"[addr [initrd[:size]] [fdt]]\n"
- "- boot Linux 'Image' stored at 'addr'\n"
+ "- boot Linux flat or compressed 'Image' stored at 'addr'\n"
"\tThe argument 'initrd' is optional and specifies the address\n"
"\tof an initrd in memory. The optional parameter ':size' allows\n"
"\tspecifying the size of a RAW initrd.\n"
+ "\tCurrently only booting from gz, bz2, lzma and lz4 compression\n"
+ "\ttypes are supported. In order to boot from any of these compressed\n"
+ "\timages, user have to set kernel_comp_addr_r and filesize
enviornment\n"
+ "\tvariables beforehand.\n"
#if defined(CONFIG_OF_LIBFDT)
"\tSince booting a Linux kernel requires a flat device-tree, a\n"
"\tthird argument providing the address of the device-tree blob\n"
diff --git a/doc/README.distro b/doc/README.distro
index ab6e6f4e74be..67b49e1e4b6a 100644
--- a/doc/README.distro
+++ b/doc/README.distro
@@ -246,6 +246,18 @@ kernel_addr_r:
A size of 16MB for the kernel is likely adequate.
+kernel_comp_addr_r:
+ Optional. This is only required if user wants to boot Linux from a compressed
+ Image(.gz, .bz2, .lzma, .lzo) using booti command. It represents the location
+ in RAM where the compressed Image will be decompressed temporarily. Once the
+ decompression is complete, decompressed data will be moved kernel_addr_r for
+ booting.
+
+filesize:
+ Optional. This is only required if user wants to boot Linux from a compressed
+ Image using booti command. It represents the size of the compressed file. The
+ size has to at least the size of loaded image
[U-Boot] [RFC/RFT PATCH v3 1/3] lib: kconfig: Add option to set BZIP2 compression method
There is no way to select BZIP2 compression method. Add it under library/compression config where all other compression related configs are present. Signed-off-by: Atish Patra --- lib/Kconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/Kconfig b/lib/Kconfig index 3da45a5ec322..b5dcdba23014 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -385,6 +385,11 @@ config GZIP help This enables support for GZIP compression algorithm. +config BZIP2 + bool "Enable bzip2 decompression support" + help + This enables support for BZIP2 compression algorithm. + config ZLIB bool default y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC/RFT PATCH v3 2/3] image: Add a common compression type detection function.
Currently, there is no method that can detect compression types
given a file. This is very useful where a compressed kernel image
is loaded directly to the memory.
Inspect initial few bytes to figure out compression type of the
image. It will be used in booti method for now but can be reused
any other function in future as well.
Signed-off-by: Atish Patra
---
common/image.c | 23 +++
include/image.h | 21 +
2 files changed, 44 insertions(+)
diff --git a/common/image.c b/common/image.c
index 179eef0bd2dc..3043f0a1c2fc 100644
--- a/common/image.c
+++ b/common/image.c
@@ -196,6 +196,14 @@ struct table_info {
const table_entry_t *table;
};
+static const struct comp_magic_map image_comp[] = {
+ { IH_COMP_BZIP2, "bzip2",{0x42, 0x5a},},
+ { IH_COMP_GZIP, "gzip", {0x1f, 0x8b},},
+ { IH_COMP_LZMA, "lzma", {0x5d, 0x00},},
+ { IH_COMP_LZO,"lzo", {0x89, 0x4c},},
+ { IH_COMP_NONE, "none", {}, },
+};
+
static const struct table_info table_info[IH_COUNT] = {
{ "architecture", IH_ARCH_COUNT, uimage_arch },
{ "compression", IH_COMP_COUNT, uimage_comp },
@@ -401,6 +409,21 @@ static void print_decomp_msg(int comp_type, int type, bool
is_xip)
printf(" Uncompressing %s\n", name);
}
+int image_decomp_type(const unsigned char *buf, ulong len)
+{
+ const struct comp_magic_map *cmagic = image_comp;
+
+ if (len < 2)
+ return -EINVAL;
+
+ for (; cmagic->comp_id > 0; cmagic++) {
+ if (!memcmp(buf, cmagic->magic, 2))
+ break;
+ }
+
+ return cmagic->comp_id;
+}
+
int image_decomp(int comp, ulong load, ulong image_start, int type,
void *load_buf, void *image_buf, ulong image_len,
uint unc_len, ulong *load_end)
diff --git a/include/image.h b/include/image.h
index c1065c06f9bd..733a6a107da8 100644
--- a/include/image.h
+++ b/include/image.h
@@ -447,6 +447,15 @@ typedef struct table_entry {
char*lname; /* long (output) name to print for messages */
} table_entry_t;
+/*
+ * Compression type and magic number mapping table.
+ */
+struct comp_magic_map {
+ int comp_id;
+ const char *name;
+ unsigned char magic[2];
+};
+
/*
* get_table_entry_id() scans the translation table trying to find an
* entry that matches the given short name. If a matching entry is
@@ -851,6 +860,18 @@ static inline int image_check_target_arch(const
image_header_t *hdr)
}
#endif /* USE_HOSTCC */
+/**
+ * image_decomp_type() - Find out compression type of an image
+ *
+ * @buf: Address in U-Boot memory where image is loaded.
+ * @len: Length of the compressed image.
+ * @return compression type or IH_COMP_NONE if not compressed.
+ *
+ * Note: Only following compression types are supported now.
+ * lzo, lzma, gzip, bzip2
+ */
+int image_decomp_type(const unsigned char *buf, ulong len);
+
/**
* image_decomp() - decompress an image
*
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC/RFT PATCH v3 0/3] Add compressed Image booting support
This patch series extends booti to support compressed images as well. Following compressed images are supported for now. lzma, lzo, bzip2, gz. Other compression methods can easily be supported if required. The above compression methods are the common ones that both Linux kernel (ARM64/RISC-V) and U-Boot supports. Atish Patra (3): lib: kconfig: Add option to set BZIP2 compression method image: Add a common compression type detection function. image: Add compressed Image parsing support in booti. cmd/booti.c| 39 ++- common/image.c | 23 doc/README.distro | 12 + doc/board/sifive/fu540.rst | 55 ++ include/image.h| 21 +++ lib/Kconfig| 5 6 files changed, 154 insertions(+), 1 deletion(-) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 3/5] usb: host: dwc2: force reset assert
On 11/6/19 7:27 PM, Patrick DELAUNAY wrote: > Hi, Hi, [...] >>> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index >>> 51023b0c2c..3086411fc4 100644 >>> --- a/drivers/usb/host/dwc2.c >>> +++ b/drivers/usb/host/dwc2.c >>> @@ -1149,6 +1149,8 @@ static int dwc2_reset(struct udevice *dev) >>> return ret; >>> } >>> >>> + reset_assert_bulk(>resets); >>> + udelay(2); >> >> Why is there a 2 uS delay ? > > I think: no real reason to have 2 us > > It was jus a reasonable time to be sure that the device reset is correctly > performed, the reset signal is propagated > > but perhaps that no delay is working... > I can test without delay if you prefer... > > PS: I use the same value than DWC2 gadget driver: >Added by my commit c2c74f97afff Isn't there a way to poll the IP to determine whether the reset completed ? [...] -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 2/5] usb: host: dwc2: add support for clk
On 11/6/19 7:03 PM, Patrick DELAUNAY wrote: > Hi Marek, Hi, [...] >> Same question as with the PHY -- is there now a mandatory dependency on the >> DM CLK ? > > No I don't think. > > Because the clk function are also stubbed in ./include/clk.h > CONFIG_IS_ENABLED(CLK) > > But I don't 100% sure as I don't tested it on one platform without DM_CLK... SoCFPGA is one of those, so +CC Simon. >> [...] >> >>> @@ -1403,6 +1429,7 @@ static int dwc2_usb_remove(struct udevice *dev) >>> dwc2_uninit_common(priv->regs); >>> >>> reset_release_bulk(>resets); >>> + clk_release_bulk(>clks); >> >> Shouldn't there be some clk_...disable() here ? > > I don't like make clk_disable() in U-Boot remove function because the > clock > u-class don't managed a counter for each clock user (as it is done in kernel). > > We have always a risk to deactivate a clock needed by a several device: > each driver (A) enable a common clock with U-Boot clock function, > but the first clock disable (A) really deactivate the clock even it is still > needed > by the other driver (B) But if you don't disable the clock in .remove callback, the clock are left running and that might cause other problems. Are there such systems which share single clock enable bit between multiple DWC2 IPs ? > I use the same logical than dwc3 driver: clk_disable_bulk is not called. I suspect that driver might need fixing. [...] -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 1/5] usb: host: dwc2: add phy support
On 11/6/19 6:40 PM, Patrick DELAUNAY wrote:
> Hi Marek,
Hi,
[...]
>>> +static int dwc2_shutdown_phy(struct udevice *dev) {
>>> + struct dwc2_priv *priv = dev_get_priv(dev);
>>> + int ret;
>>> +
>>> + if (!generic_phy_valid(>phy))
>>> + return 0;
>>> +
>>> + ret = generic_phy_power_off(>phy);
>>> + if (ret) {
>>> + dev_err(dev, "failed to power off usb phy\n");
>>> + return ret;
>>> + }
>>> +
>>> + ret = generic_phy_exit(>phy);
>>> + if (ret) {
>>> + dev_err(dev, "failed to power off usb phy\n");
>>
>> Shouldn't all those error prints be produced by the PHY subsystem ?
>
> Perhaps... but it is not done today in phy u-class (only call ops).
>
> I make the same level of trace than ./drivers/usb/dwc3/core.c
> as copy initially the phy support from this driver.
So this starts the duplication. Can you move it to the PHY subsystem
instead ?
>>> + return ret;
>>
>> [...]
>>
>>> @@ -1339,6 +1398,8 @@ static int dwc2_usb_remove(struct udevice *dev)
>>> if (ret)
>>> return ret;
>>>
>>> + dwc2_shutdown_phy(dev);
>>
>> This function returns a return value, but it's ignored here ?
>
> Yes, even if the shutdown of the USB PHY failed, the USB dwc2
> driver continues the procedure to release other ressources...
How can you safely release the rest of the resources if the PHY driver
didn't shut down? I suspect this might lead to some resource corruption, no?
> And the driver expects that the USB PHY will be available for next
> request/probe (recovery with phy reset for example).
>
> I use the same logic than dwc3 driver in :
> source/drivers/usb/dwc3/dwc3-generic.c::dwc3_generic_remove()
> drivers/usb/host/xhci-dwc3.c::xhci_dwc3_remove()
dwc3_shutdown_phy() only ever returns 0 though.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] spi: cadence_qspi: Move to spi-mem framework
Hi Vignesh,
On Thu, Oct 17, 2019 at 2:31 PM Vignesh Raghavendra wrote:
>
> Hi Simon,
>
> On 17/10/19 4:50 PM, Simon Goldschmidt wrote:
> > On Mon, Oct 14, 2019 at 3:27 PM Vignesh Raghavendra wrote:
> >>
> >> Current Cadence QSPI driver has few limitations. It assumes all read
> >> operations to be in Quad mode and thus does not support SFDP parsing.
> >> Also, adding support for new mode such as Octal mode would not be
> >> possible with current configuration. Therefore move the driver over to
> >> spi-mem
> >> framework. This has added advantage that driver can be used to support
> >> SPI NAND memories too.
> >> Hence, move driver over to new spi-mem APIs.
> >>
> >> Please note that this gets rid of mode bit setting done when
> >> CONFIG_SPL_SPI_XIP is defined as there does not seem to be any user to
> >> that config option.
> >
> > I just have tried this on an socfgpa cylone5 board with an mt25ql256a, but
> > it does not seem to work: when leaving spi-rx-bus-width and spi-tx-bus-width
> > at 4 in my devicetree, SFDP parsing works, but reading data afterwards
> > produces invalid results (I haven't tested what's wrong there).
> >
>
> Thanks for testing!
>
> spi-tx-bus-width = 4 was not supported before so I haven't added support
> for that mode in this series. That change will be a separate series.
>
> Could you try with spi-tx-bus-width = 1 and spi-rx-bus-width = 4 and see
> if that works?
>
> If that does not work then could you disable SFDP parsing (but keep
> spi-rx-bus-width = 4) and see if that works. This should narrow down
> whether SFDP parsing is broken or if driver has an issue.
Sorry, I still haven't found the time at work to test this. I'll keep trying.
Keeping that aside, if this driver is converted to spi-mem, is there any
chance of getting this into SPL while not getting standard SPI drivers in?
On socfpga, I have a standard SPI driver (designware_spi) enabled but that
results in both the cadence_qspi and designware_spi being included in SPL aside
well when boot-from-SPI is enabled.
Does that somehow change when cadence_qspi is an spi-mem driver?
Thanks,
Simon
>
> Regards
> Vignesh
>
> > It works as expected when not parsing SFDP or setting the bus-width to 1.
> > So the change itself probably works, but SFDP parsing is broken?
> >
> > I did the tests with this applied first:
> > https://patchwork.ozlabs.org/project/uboot/list/?series=135505
> >
> > Regards,
> > Simon
> >
> >
> >>
> >> Signed-off-by: Vignesh Raghavendra
> >> ---
> >> drivers/spi/cadence_qspi.c | 136 +
> >> drivers/spi/cadence_qspi.h | 9 +--
> >> drivers/spi/cadence_qspi_apb.c | 124 --
> >> 3 files changed, 91 insertions(+), 178 deletions(-)
> >>
> >> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> >> index e2e54cd27723..673a2e9a6c4c 100644
> >> --- a/drivers/spi/cadence_qspi.c
> >> +++ b/drivers/spi/cadence_qspi.c
> >> @@ -10,6 +10,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include "cadence_qspi.h"
> >>
> >> @@ -34,12 +35,21 @@ static int cadence_spi_write_speed(struct udevice
> >> *bus, uint hz)
> >> return 0;
> >> }
> >>
> >> +static int cadence_spi_read_id(void *reg_base, u8 len, u8 *idcode)
> >> +{
> >> + struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(0x9F, 1),
> >> + SPI_MEM_OP_NO_ADDR,
> >> + SPI_MEM_OP_NO_DUMMY,
> >> + SPI_MEM_OP_DATA_IN(len, idcode,
> >> 1));
> >> +
> >> + return cadence_qspi_apb_command_read(reg_base, );
> >> +}
> >> +
> >> /* Calibration sequence to determine the read data capture delay register
> >> */
> >> static int spi_calibration(struct udevice *bus, uint hz)
> >> {
> >> struct cadence_spi_priv *priv = dev_get_priv(bus);
> >> void *base = priv->regbase;
> >> - u8 opcode_rdid = 0x9F;
> >> unsigned int idcode = 0, temp = 0;
> >> int err = 0, i, range_lo = -1, range_hi = -1;
> >>
> >> @@ -53,8 +63,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
> >> cadence_qspi_apb_controller_enable(base);
> >>
> >> /* read the ID which will be our golden value */
> >> - err = cadence_qspi_apb_command_read(base, 1, _rdid,
> >> - 3, (u8 *));
> >> + err = cadence_spi_read_id(base, 3, (u8 *));
> >> if (err) {
> >> puts("SF: Calibration failed (read)\n");
> >> return err;
> >> @@ -73,8 +82,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
> >> cadence_qspi_apb_controller_enable(base);
> >>
> >> /* issue a RDID to get the ID value */
> >> - err = cadence_qspi_apb_command_read(base, 1, _rdid,
> >> - 3, (u8 *));
> >> + err = cadence_spi_read_id(base, 3, (u8 *));
> >> if (err) {
Re: [U-Boot] [PATCH] ARM: defconfig: add unified config for RPi3 and RPi4
On 06/11/2019 19:06, Heinrich Schuchardt wrote: > On 11/6/19 3:41 PM, matthias@kernel.org wrote: >> From: Matthias Brugger >> >> Provide a defconfig which allows us to boot Raspberrry Pi 4 >> and Raspberry Pi 3 Model B/B+ >> Instead of using the embedded DTB as done in RPi3 we use the >> devicetree provided by the firmware. > > How different are the DTBs provided by different firmware releases? > > Could we run into problems because some elder or newer firmware releases > are not supported by U-Boot? - This prospect is what makes your patch a > bit scary to me. That could happen, but I suppose especially for older releases. Newer releases tend to change in the direction of upstream. > > Which different firmware releases did you test against? > > Do you plan to keep the existing defconfigs and dtbs? > I didn't do any extensive testing to be honest. We are using the DTB from the firmware on RPi4 already, and I expect that newer firmwares won't break U-Boot. My idea is to keep the existing defconfigs. Apart from being a good fallback option if really something breaks, there might be some distros use U-Boot with this config files and I don't want to break the setup for them. Regards, Matthias ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Wed, Nov 06, 2019 at 11:49:05AM +0100, Marek Vasut wrote: > The following changes since commit 412326d1bc2d346d7b4faad6fa547eaf065681a2: > > Merge tag 'u-boot-clk-23Oct2019' of > https://gitlab.denx.de/u-boot/custodians/u-boot-clk (2019-10-30 13:13:46 > -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to 02b0e1a36c5bc20174299312556ec4e266872bd6: > > usb: ehci-hcd: Keep async schedule running (2019-10-31 12:13:40 +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] [PULL] u-boot-mmc mmc-2019-11-5
On Wed, Nov 06, 2019 at 06:09:38AM +, Peng Fan wrote: > Hi Tom, > > Please pull u-boot-mmc mmc-2019-11-5 > > CI: https://travis-ci.org/MrVan/u-boot/builds/607453537 > 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] Makefile: fix dependency for imx targets
On Fri, Oct 25, 2019 at 02:46:54PM +0200, Heiko Schocher wrote: > imx targets are defined in arch/arm/mach-imx/Makefile. > Some of them are dependent on targets defined in main > Makefile. For the Makefile in arch/arm/mach-imx this > targets must be finished before the imx targets are > build, if not you get for example the error: > > make -f /home/hs/abb/mainlining/u-boot/scripts/Makefile.build > obj=arch/arm/mach-imx u-boot-dtb.imx > make[2]: *** No rule to make target 'u-boot-fit-dtb.bin', needed by > 'u-boot-dtb.imx'. Stop. > make[1]: *** [/home/hs/abb/mainlining/u-boot/Makefile:1123: u-boot-dtb.imx] > Error 2 > make[1]: *** Waiting for unfinished jobs > make[1]: Leaving directory '/work/hs/compile/u-boot/aristainetos2_defconfig' > make: *** [Makefile:148: sub-make] Error 2 > compile failed > > In above case of CONFIG_MULTI_DTB_FIT is defined, the > u-boot-dtb.imx is dependent on the u-boot-fit-dtb.bin > which may is not build yet ... > > I could reproduce this error on a travis build also if > I build an out-of-tree build on a local machine with a > build directory on a "slow" slow storage device. If > building the same source target with a build dir on a > fast storage device, the build works. > > I found no solution to tell the arch/arm/mach-imx/Makefile > to find the targets in main Makefile, if there is a way > this would be the better fix. > > I solved it by adding a IMX_DEPS var, which holds a list > of main u-boot targets, which must be finished, before > calling imx targets and fixed the build for imx > targets which enabled CONFIG_MULTI_DTB_FIT. > > I think it is just luck, that imx targets with > CONFIG_OF_SEPARATE enabled build, because the > u-boot-dtb.imx target depends on u-boot-dtb.bin > which gets build early enough before starting with > u-boot-dtb.imx. May this targets should be fixed too. > > Signed-off-by: Heiko Schocher > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 4/5] usb: host: dwc2: add usb33d supply support for stm32mp1
Hi, > > On 10/14/19 10:00 AM, Patrick Delaunay wrote: > > Enable the usb33d-supply on STM32MP1 SoCs (with "st,stm32mp1-hsotg" > > compatible), it is the external VBUS and ID sensing comparators supply > > needed to perform OTG operation. > > I suspect we might need some dwc2-stm32p1.c SoC-specific driver here. > Adding SoC-specific stuff into common driver doesn't sound right. Yes, you are right... I perhaps need to rework this patch. Today I will drop this part in the V2 patchset. I will resubmit a other patch later for this part because I need to cross-checks with Linux driver This stm32mp1 specific part also exist in our dwc2 kernel driver but I need to check if it can be upstreamed (modification in binding dwc2 is acceptable). Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm: dts: hummingboard: add cubox/hummingboard DT
Hi Baruch, On Wed, Nov 6, 2019 at 11:28 AM Baruch Siach wrote: > > These DT files are copied from kernel v5.3 with very little changes. > Notably missing are audmux port configuration nodes, since U-Boot does > not provide the IMX_AUDMUX_ macros. What about importing the include/dt-bindings/sound/fsl-imx-audmux.h file from the kernel to U-Boot? This would help us to use the kernel dts as is in U-Boot. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 3/5] usb: host: dwc2: force reset assert
Hi,
> From: Marek Vasut
> Sent: mardi 15 octobre 2019 01:30
>
> On 10/14/19 10:00 AM, Patrick Delaunay wrote:
> > Assert reset before deassert in dwc2_reset; It should be more safe for
> > DWC2.
>
> Can you be more descriptive about this issue ? I have no idea what this patch
> does
> or fixes from the description.
Yes
I will explain it in V2 commit message.
The issue only occurs if the DWC2 OTG device switch between gadget mode
and host mode.
For example:
some registers initialiaze by the command "ums" (device mode is forced for
example),
cause problem for the next command "usb start" and vice versa.
Even the existing software reset in dwc_otg_core_reset is not enough;
the added hardware reset solve all the issues.
> > Signed-off-by: Patrick Delaunay
> > ---
> >
> > drivers/usb/host/dwc2.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index
> > 51023b0c2c..3086411fc4 100644
> > --- a/drivers/usb/host/dwc2.c
> > +++ b/drivers/usb/host/dwc2.c
> > @@ -1149,6 +1149,8 @@ static int dwc2_reset(struct udevice *dev)
> > return ret;
> > }
> >
> > + reset_assert_bulk(>resets);
> > + udelay(2);
>
> Why is there a 2 uS delay ?
I think: no real reason to have 2 us
It was jus a reasonable time to be sure that the device reset is correctly
performed, the reset signal is propagated
but perhaps that no delay is working...
I can test without delay if you prefer...
PS: I use the same value than DWC2 gadget driver:
Added by my commit c2c74f97afff
static int dwc2_udc_otg_reset_init(struct udevice *dev,
struct reset_ctl_bulk *resets)
{
.
ret = reset_assert_bulk(resets);
if (!ret) {
udelay(2);
ret = reset_deassert_bulk(resets);
}
}
> > ret = reset_deassert_bulk(>resets);
> > if (ret) {
> > reset_release_bulk(>resets);
> >
>
> [...]
Regards
Patrick
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: defconfig: add unified config for RPi3 and RPi4
On 11/6/19 3:41 PM, matthias@kernel.org wrote: From: Matthias Brugger Provide a defconfig which allows us to boot Raspberrry Pi 4 and Raspberry Pi 3 Model B/B+ Instead of using the embedded DTB as done in RPi3 we use the devicetree provided by the firmware. How different are the DTBs provided by different firmware releases? Could we run into problems because some elder or newer firmware releases are not supported by U-Boot? - This prospect is what makes your patch a bit scary to me. Which different firmware releases did you test against? Do you plan to keep the existing defconfigs and dtbs? Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 2/5] usb: host: dwc2: add support for clk
Hi Marek,
> From: Marek Vasut
> Sent: mardi 15 octobre 2019 01:28
>
> On 10/14/19 10:00 AM, Patrick Delaunay wrote:
> > Add support for clock with driver model.
> >
>
> Same question as with the PHY -- is there now a mandatory dependency on the
> DM CLK ?
No I don't think.
Because the clk function are also stubbed in ./include/clk.h
CONFIG_IS_ENABLED(CLK)
But I don't 100% sure as I don't tested it on one platform without DM_CLK...
> [...]
>
> > @@ -1403,6 +1429,7 @@ static int dwc2_usb_remove(struct udevice *dev)
> > dwc2_uninit_common(priv->regs);
> >
> > reset_release_bulk(>resets);
> > + clk_release_bulk(>clks);
>
> Shouldn't there be some clk_...disable() here ?
I don't like make clk_disable() in U-Boot remove function because the clock
u-class don't managed a counter for each clock user (as it is done in kernel).
We have always a risk to deactivate a clock needed by a several device:
each driver (A) enable a common clock with U-Boot clock function,
but the first clock disable (A) really deactivate the clock even it is still
needed
by the other driver (B)
I use the same logical than dwc3 driver: clk_disable_bulk is not called.
static int dwc3_glue_remove(struct udevice *dev)
{
struct dwc3_glue_data *glue = dev_get_platdata(dev);
reset_release_bulk(>resets);
clk_release_bulk(>clks);
return 0;
}
Regards
Patrick
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] include/env.h: Ensure ulong is defined
On Wed, 2019-11-06 at 17:59 +0200, David Abdurachmanov wrote: > On Wed, Nov 6, 2019 at 4:30 PM Alistair Francis > wrote: > > To fix these failures when building with musl: > >include/env.h:166:1: error: unknown type name 'ulong'; did you > > mean 'long'? > > ensure that ulong is defined. > > I think, this was fixed before 2019.10 release by this patchset: > > https://patchwork.ozlabs.org/cover/1152432/ That didn't fix the problem for musl. Alistair > > > Signed-off-by: Alistair Francis > > --- > > include/env.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/include/env.h b/include/env.h > > index b72239f6a5..5ca49a3456 100644 > > --- a/include/env.h > > +++ b/include/env.h > > @@ -13,6 +13,8 @@ > > #include > > #include > > > > +typedef unsigned long ulong; > > + > > struct environment_s; > > > > /* Value for environment validity */ > > -- > > 2.23.0 > > > > ___ > > 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] [RESEND PATCH 1/5] usb: host: dwc2: add phy support
Hi Marek,
> From: Marek Vasut
> Sent: mardi 15 octobre 2019 01:27
First sorry for my late answer
> On 10/14/19 10:00 AM, Patrick Delaunay wrote:
> > Use generic phy to initialize the PHY associated to the
>
> PHY and USB are abbreviations, should be in capitals.
>
> > DWC2 device and available in the device tree.
>
> [...]
>
> General question -- is the PHY subsystem a mandatory dependency of this driver
> now or will it work without the PHY subsystem still ?
Normally it is working as all the generic_phy_XXX fucntions
are stubbed in include/generic-phy.h
- generic_phy_get_by_index() return 0 and phy->dev = NULL
- all other function return 0
- generic_phy_valid return FALSE (phy->dev = NULL)
> > +static int dwc2_setup_phy(struct udevice *dev) {
> > + struct dwc2_priv *priv = dev_get_priv(dev);
> > + int ret;
> > +
> > + ret = generic_phy_get_by_index(dev, 0, >phy);
> > + if (ret) {
> > + if (ret != -ENOENT) {
> > + dev_err(dev, "failed to get usb phy\n");
>
> Sentence starts with capital letter, USB and PHY are in capitals. Fix globally
> please.
> It would be useful to print the $ret value too.
Yes, in V2
>
> > + return ret;
> > + }
> > + return 0;
> > + }
> > +
> > + ret = generic_phy_init(>phy);
> > + if (ret) {
> > + dev_err(dev, "failed to init usb phy\n");
> > + return ret;
> > + }
> > +
> > + ret = generic_phy_power_on(>phy);
> > + if (ret) {
> > + dev_err(dev, "failed to power on usb phy\n");
> > + return generic_phy_exit(>phy);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int dwc2_shutdown_phy(struct udevice *dev) {
> > + struct dwc2_priv *priv = dev_get_priv(dev);
> > + int ret;
> > +
> > + if (!generic_phy_valid(>phy))
> > + return 0;
> > +
> > + ret = generic_phy_power_off(>phy);
> > + if (ret) {
> > + dev_err(dev, "failed to power off usb phy\n");
> > + return ret;
> > + }
> > +
> > + ret = generic_phy_exit(>phy);
> > + if (ret) {
> > + dev_err(dev, "failed to power off usb phy\n");
>
> Shouldn't all those error prints be produced by the PHY subsystem ?
Perhaps... but it is not done today in phy u-class (only call ops).
I make the same level of trace than ./drivers/usb/dwc3/core.c
as copy initially the phy support from this driver.
> > + return ret;
>
> [...]
>
> > @@ -1339,6 +1398,8 @@ static int dwc2_usb_remove(struct udevice *dev)
> > if (ret)
> > return ret;
> >
> > + dwc2_shutdown_phy(dev);
>
> This function returns a return value, but it's ignored here ?
Yes, even if the shutdown of the USB PHY failed, the USB dwc2
driver continues the procedure to release other ressources...
And the driver expects that the USB PHY will be available for next
request/probe (recovery with phy reset for example).
I use the same logic than dwc3 driver in :
source/drivers/usb/dwc3/dwc3-generic.c::dwc3_generic_remove()
drivers/usb/host/xhci-dwc3.c::xhci_dwc3_remove()
>
> > dwc2_uninit_common(priv->regs);
> >
> > reset_release_bulk(>resets);
> >
>
> [...]
Regards
Patrick
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] USB doesn't work on Rockpro64 in u-boot
Hi Vasily, On Wed, Nov 6, 2019 at 9:17 AM Vasily Khoruzhick wrote: > > Hi Akash, Jagan, > > Looks like USB is not functional in u-boot on Rockpro64. u-boot is > from git, commit 680023c5fab6b1777c0c6f2e76e5d2effb7903a0. > > I'm using u-boot SPL and mainline ATF > (19adcb415c313d656324d54e7608cdc7d7a5c414 is ATF commit) > > 'usb start' doesn't detect anything but hubs and looks like there's no > power on USB ports: > > => usb start > starting USB... > Bus usb@fe38: USB EHCI 1.00 > Bus usb@fe3c: USB EHCI 1.00 > Bus dwc3: Register 2000140 NbrPorts 2 > Starting the controller > USB XHCI 1.10 > Bus dwc3: Register 2000140 NbrPorts 2 > Starting the controller > USB XHCI 1.10 > scanning bus usb@fe38 for devices... 1 USB Device(s) found > scanning bus usb@fe3c for devices... 1 USB Device(s) found > scanning bus dwc3 for devices... 1 USB Device(s) found > scanning bus dwc3 for devices... 1 USB Device(s) found >scanning usb for storage devices... 0 Storage Device(s) found > > => usb tree > USB device tree: > 1 Hub (480 Mb/s, 0mA) > u-boot EHCI Host Controller > > 1 Hub (480 Mb/s, 0mA) > u-boot EHCI Host Controller > > 1 Hub (5 Gb/s, 0mA) > U-Boot XHCI Host Controller > > 1 Hub (5 Gb/s, 0mA) > U-Boot XHCI Host Controller > > Regulators were probed correctly according to 'dm tree': > > regulator14 [ + ] fixed regulator |-- vcc12v-dcin > regulator15 [ + ] fixed regulator |-- vcc1v8-s3 > regulator16 [ + ] fixed regulator |-- vcc3v3-pcie-regulator > regulator17 [ + ] fixed regulator |-- vcc3v3-sys > regulator18 [ + ] fixed regulator |-- vcc5v0-host-regulator > regulator19 [ + ] fixed regulator |-- vcc5v0-typec-regulator > regulator20 [ + ] fixed regulator |-- vcc5v0-sys > regulator21 [ + ] fixed regulator |-- vcc5v0-usb > regulator22 [ + ] pwm_regulator `-- vdd-log > > Any ideas what can be wrong? Have it worked before? I remember my last checking, give me sometime will check it on master and update you. Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Buildman Kconfig issue with consecutive builds
Hi, I'm having some trouble using buildman to test the impact of some Kconfig cleanup patches ([1]). The patches introduce a new CONFIG_SPL_* option and I try to find out which defconfigs need to be fixed, by comparing build sizes. Now when I added a patch to fix a defconfig I noticed that buildman wouldn't report the expected size changes and upon looking more closely I found that the added Kconfig options are still missing in u-boot-spl.cfg. The strange thing is, that when I try to build only the last commit then the Kconfig options are there, which is why I suspect a bug in buildman not handling Kconfig changes correctly with consecutive builds. Can anyone have a look what is wrong or how I can debug this issue? The issue can be reproduced with the branch at [1], running: buildman -b spi_flash_kconfig_cleanup_3 --step 0 xilinx_zynqmp_virt for a build where the added Kconfig options are missing in the resulting u-boot-spl.cfg. And: buildman -b spi_flash_kconfig_cleanup_3^..spi_flash_kconfig_cleanup_3 xilinx_zynqmp_virt for a build of only the last commit with expected output. Thanks, Frieder [1]: https://github.com/fschrempf/u-boot/commits/spi_flash_kconfig_cleanup_3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] include/env.h: Ensure ulong is defined
On Wed, Nov 6, 2019 at 4:30 PM Alistair Francis wrote: > > To fix these failures when building with musl: >include/env.h:166:1: error: unknown type name 'ulong'; did you mean 'long'? > ensure that ulong is defined. I think, this was fixed before 2019.10 release by this patchset: https://patchwork.ozlabs.org/cover/1152432/ > > Signed-off-by: Alistair Francis > --- > include/env.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/env.h b/include/env.h > index b72239f6a5..5ca49a3456 100644 > --- a/include/env.h > +++ b/include/env.h > @@ -13,6 +13,8 @@ > #include > #include > > +typedef unsigned long ulong; > + > struct environment_s; > > /* Value for environment validity */ > -- > 2.23.0 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] ARM: dts: stm32: DT alignment with kernel v5.3
Device tree and binding alignment with kernel v5.3
and converted to SPDX.
Signed-off-by: Patrick Delaunay
---
arch/arm/dts/stm32429i-eval.dts | 4 +-
arch/arm/dts/stm32746g-eval.dts | 105 +---
arch/arm/dts/stm32f4-pinctrl.dtsi | 38 +--
arch/arm/dts/stm32f429-disco.dts | 40 +---
arch/arm/dts/stm32f429-pinctrl.dtsi | 38 +--
arch/arm/dts/stm32f429.dtsi | 115 +++---
arch/arm/dts/stm32f469-disco.dts | 39 +---
arch/arm/dts/stm32f469-pinctrl.dtsi | 39 +---
arch/arm/dts/stm32f469.dtsi | 2 +-
arch/arm/dts/stm32f746-disco.dts | 39 +---
arch/arm/dts/stm32f746.dtsi | 42 +---
arch/arm/dts/stm32f769-disco.dts | 43 ++--
arch/arm/dts/stm32h7-u-boot.dtsi | 41 +---
arch/arm/dts/stm32h743-pinctrl.dtsi | 83
arch/arm/dts/stm32h743.dtsi | 69 ++---
arch/arm/dts/stm32h743i-disco-u-boot.dtsi | 8 --
arch/arm/dts/stm32h743i-disco.dts | 76 +++---
arch/arm/dts/stm32h743i-eval-u-boot.dtsi | 9 --
arch/arm/dts/stm32h743i-eval.dts | 41 +++-
arch/arm/dts/stm32mp157c-ed1.dts | 4 +-
include/dt-bindings/clock/stm32fx-clock.h | 9 +-
include/dt-bindings/mfd/st,stpmic1.h | 4 +
22 files changed, 377 insertions(+), 511 deletions(-)
diff --git a/arch/arm/dts/stm32429i-eval.dts b/arch/arm/dts/stm32429i-eval.dts
index 1eec951188..bd41ae3c14 100644
--- a/arch/arm/dts/stm32429i-eval.dts
+++ b/arch/arm/dts/stm32429i-eval.dts
@@ -20,6 +20,7 @@
};
memory {
+ device_type = "memory";
reg = <0x 0x200>;
};
@@ -72,6 +73,7 @@
gpio_keys {
compatible = "gpio-keys";
+ #address-cells = <1>;
#size-cells = <0>;
autorepeat;
button@0 {
@@ -227,7 +229,7 @@
pinctrl-0 = <_pins>;
pinctrl-1 = <_pins_od>;
bus-width = <4>;
- max-frequency = <1400>;
+ max-frequency = <1250>;
};
{
diff --git a/arch/arm/dts/stm32746g-eval.dts b/arch/arm/dts/stm32746g-eval.dts
index 8c081eaf20..d77eb53c6a 100644
--- a/arch/arm/dts/stm32746g-eval.dts
+++ b/arch/arm/dts/stm32746g-eval.dts
@@ -1,49 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
/*
* Copyright 2015 - Maxime Coquelin
*
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This file is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
*/
/dts-v1/;
#include "stm32f746.dtsi"
#include "stm32f746-pinctrl.dtsi"
#include
+#include
/ {
model = "STMicroelectronics STM32746g-EVAL board";
@@ -55,6 +20,7 @@
};
memory {
+ device_type = "memory";
reg = <0xc000 0x200>;
};
@@ -68,9 +34,15 @@
gpios = < 10 1>;
linux,default-trigger = "heartbeat";
};
+ orange {
+ gpios = <_pinctrl 17 1>;
+ };
[U-Boot] [PATCH 0/3] ARM: dts: stm32: udpate device tree for v2020.01
Alignment of the device tree for all STM32 boards (MCU/MPU) with the latest Linux kernel and solve STM32MP157c-EV1 issue for eMMC on SDMMC2. All the boards (except avenger96i: not available) correctly boot after the patches. Patrick Delaunay (3): ARM: dts: stm32: DT alignment with kernel v5.3 ARM: dts: stm32: DT alignment with kernel v5.4-rc4 ARM: dts: stm32: update eMMC configuration for stm32mp157c-ev1 arch/arm/dts/st-pincfg.h | 1 + arch/arm/dts/stm32429i-eval.dts | 29 ++-- arch/arm/dts/stm32746g-eval.dts | 105 +- arch/arm/dts/stm32f4-pinctrl.dtsi | 38 +- arch/arm/dts/stm32f429-disco.dts | 40 +- arch/arm/dts/stm32f429-pinctrl.dtsi | 38 +- arch/arm/dts/stm32f429.dtsi | 127 +++-- arch/arm/dts/stm32f469-disco.dts | 39 +- arch/arm/dts/stm32f469-pinctrl.dtsi | 39 +- arch/arm/dts/stm32f469.dtsi | 2 +- arch/arm/dts/stm32f746-disco.dts | 39 +- arch/arm/dts/stm32f746.dtsi | 54 +++- arch/arm/dts/stm32f769-disco.dts | 43 +- arch/arm/dts/stm32h7-u-boot.dtsi | 41 +- arch/arm/dts/stm32h743-pinctrl.dtsi | 83 +++ arch/arm/dts/stm32h743.dtsi | 69 +- arch/arm/dts/stm32h743i-disco-u-boot.dtsi | 8 -- arch/arm/dts/stm32h743i-disco.dts | 76 ++- arch/arm/dts/stm32h743i-eval-u-boot.dtsi | 9 -- arch/arm/dts/stm32h743i-eval.dts | 42 +- arch/arm/dts/stm32mp157-pinctrl.dtsi | 59 +++- .../arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 5 +- arch/arm/dts/stm32mp157a-dk1.dts | 129 ++ arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 5 +- arch/arm/dts/stm32mp157c-ed1.dts | 51 ++- arch/arm/dts/stm32mp157c-ev1.dts | 3 +- arch/arm/dts/stm32mp157c.dtsi | 26 include/dt-bindings/clock/stm32fx-clock.h | 9 +- include/dt-bindings/mfd/st,stpmic1.h | 4 + include/dt-bindings/mfd/stm32f7-rcc.h | 1 + include/dt-bindings/mfd/stm32h7-rcc.h | 2 +- 31 files changed, 682 insertions(+), 534 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] ARM: dts: stm32: update eMMC configuration for stm32mp157c-ev1
Update the sdmmc2 node for eMMC support on eval board stm32mp157c-ev1.
- update slew-rate for pin configuration
- update "vqmmc-supply"
- remove "st,sig-dir"
- add mandatory "pinctrl-names"
- add "mmc-ddr-3_3v"
This patch solve the eMMC detection issue for command "mmc dev 1".
Signed-off-by: Patrick Delaunay
---
arch/arm/dts/stm32mp157-pinctrl.dtsi | 57 +--
.../arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 5 +-
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 5 +-
arch/arm/dts/stm32mp157c-ed1.dts | 7 ++-
4 files changed, 66 insertions(+), 8 deletions(-)
diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi
b/arch/arm/dts/stm32mp157-pinctrl.dtsi
index 2d73d502d9..0d53396119 100644
--- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
@@ -812,31 +812,80 @@
};
sdmmc2_b4_pins_a: sdmmc2-b4-0 {
- pins {
+ pins1 {
pinmux = ,
/* SDMMC2_D0 */
,
/* SDMMC2_D1 */
,
/* SDMMC2_D2 */
,
/* SDMMC2_D3 */
-,
/* SDMMC2_CK */
;
/* SDMMC2_CMD */
- slew-rate = <3>;
+ slew-rate = <1>;
+ drive-push-pull;
+ bias-pull-up;
+ };
+ pins2 {
+ pinmux = ;
/* SDMMC2_CK */
+ slew-rate = <2>;
drive-push-pull;
bias-pull-up;
};
};
+ sdmmc2_b4_od_pins_a: sdmmc2-b4-od-0 {
+ pins1 {
+ pinmux = ,
/* SDMMC2_D0 */
+,
/* SDMMC2_D1 */
+,
/* SDMMC2_D2 */
+;
/* SDMMC2_D3 */
+ slew-rate = <1>;
+ drive-push-pull;
+ bias-pull-up;
+ };
+ pins2 {
+ pinmux = ;
/* SDMMC2_CK */
+ slew-rate = <2>;
+ drive-push-pull;
+ bias-pull-up;
+ };
+ pins3 {
+ pinmux = ;
/* SDMMC2_CMD */
+ slew-rate = <1>;
+ drive-open-drain;
+ bias-pull-up;
+ };
+ };
+
+ sdmmc2_b4_sleep_pins_a: sdmmc2-b4-sleep-0 {
+ pins {
+ pinmux = , /* SDMMC2_D0 */
+, /* SDMMC2_D1 */
+, /* SDMMC2_D2 */
+, /* SDMMC2_D3 */
+, /* SDMMC2_CK */
+; /* SDMMC2_CMD */
+ };
+ };
+
sdmmc2_d47_pins_a: sdmmc2-d47-0 {
pins {
pinmux = ,
/* SDMMC2_D4 */
,
/* SDMMC2_D5 */
,
/* SDMMC2_D6 */
;
/* SDMMC2_D7 */
- slew-rate = <3>;
+ slew-rate = <1>;
drive-push-pull;
bias-pull-up;
};
};
+ sdmmc2_d47_sleep_pins_a: sdmmc2-d47-sleep-0 {
+ pins {
+ pinmux = , /* SDMMC2_D4 */
+, /* SDMMC2_D5 */
+, /* SDMMC2_D6 */
+; /* SDMMC2_D7 */
+ };
+ };
+
spdifrx_pins_a: spdifrx-0 {
[U-Boot] [PATCH 2/3] ARM: dts: stm32: DT alignment with kernel v5.4-rc4
Device tree and binding alignment with kernel v5.4-rc4
Signed-off-by: Patrick Delaunay
---
arch/arm/dts/st-pincfg.h | 1 +
arch/arm/dts/stm32429i-eval.dts | 25 ++---
arch/arm/dts/stm32f429.dtsi | 12 +++
arch/arm/dts/stm32f746.dtsi | 12 +++
arch/arm/dts/stm32h743i-eval.dts | 1 +
arch/arm/dts/stm32mp157-pinctrl.dtsi | 2 +-
arch/arm/dts/stm32mp157a-dk1.dts | 129 ++
arch/arm/dts/stm32mp157c-ed1.dts | 40
arch/arm/dts/stm32mp157c-ev1.dts | 3 +-
arch/arm/dts/stm32mp157c.dtsi | 26 ++
include/dt-bindings/mfd/stm32f7-rcc.h | 1 +
include/dt-bindings/mfd/stm32h7-rcc.h | 2 +-
12 files changed, 239 insertions(+), 15 deletions(-)
diff --git a/arch/arm/dts/st-pincfg.h b/arch/arm/dts/st-pincfg.h
index 4851c387d5..d805512022 100644
--- a/arch/arm/dts/st-pincfg.h
+++ b/arch/arm/dts/st-pincfg.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 */
#ifndef _ST_PINCFG_H_
#define _ST_PINCFG_H_
diff --git a/arch/arm/dts/stm32429i-eval.dts b/arch/arm/dts/stm32429i-eval.dts
index bd41ae3c14..c5afa0c162 100644
--- a/arch/arm/dts/stm32429i-eval.dts
+++ b/arch/arm/dts/stm32429i-eval.dts
@@ -40,18 +40,18 @@
dma-ranges = <0xc000 0x0 0x1000>;
};
- regulators {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
+ vdda: regulator-vdda {
+ compatible = "regulator-fixed";
+ regulator-name = "vdda";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
- reg_vref: regulator@0 {
- compatible = "regulator-fixed";
- reg = <0>;
- regulator-name = "vref";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- };
+ vref: regulator-vref {
+ compatible = "regulator-fixed";
+ regulator-name = "vref";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
};
leds {
@@ -116,7 +116,8 @@
{
pinctrl-names = "default";
pinctrl-0 = <_in8_pin>;
- vref-supply = <_vref>;
+ vdda-supply = <>;
+ vref-supply = <>;
status = "okay";
adc3: adc@200 {
st,adc-channels = <8>;
diff --git a/arch/arm/dts/stm32f429.dtsi b/arch/arm/dts/stm32f429.dtsi
index ec84ae4f52..db0b82e89e 100644
--- a/arch/arm/dts/stm32f429.dtsi
+++ b/arch/arm/dts/stm32f429.dtsi
@@ -71,6 +71,7 @@
pwm {
compatible = "st,stm32-pwm";
+ #pwm-cells = <3>;
status = "disabled";
};
@@ -100,6 +101,7 @@
pwm {
compatible = "st,stm32-pwm";
+ #pwm-cells = <3>;
status = "disabled";
};
@@ -129,6 +131,7 @@
pwm {
compatible = "st,stm32-pwm";
+ #pwm-cells = <3>;
status = "disabled";
};
@@ -157,6 +160,7 @@
pwm {
compatible = "st,stm32-pwm";
+ #pwm-cells = <3>;
status = "disabled";
};
@@ -226,6 +230,7 @@
pwm {
compatible = "st,stm32-pwm";
+ #pwm-cells = <3>;
status = "disabled";
};
@@ -247,6 +252,7 @@
pwm {
compatible = "st,stm32-pwm";
+ #pwm-cells = <3>;
status = "disabled";
};
};
@@ -262,6 +268,7 @@
pwm {
compatible = "st,stm32-pwm";
+ #pwm-cells = <3>;
status = "disabled";
};
};
@@ -407,6 +414,7 @@
pwm {
compatible = "st,stm32-pwm";
+ #pwm-cells = <3>;
status = "disabled";
};
@@ -428,6 +436,7 @@
pwm {
compatible = "st,stm32-pwm";
+ #pwm-cells = <3>;
status = "disabled";
};
@@ -561,6 +570,7 @@
pwm {
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Dear Aaron, In message you wrote: > > > Definitely not. You could not implement any of this without heavily > > relyin on and deriving from internal interfaces of U-Boot which are > > not exported for non-GPL use. > > See https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#GPLInProp= > rietarySystem > > This behaves exactly in the manner that is permitted by the GPL. > They are completely separate programs. Are they? You wrote: "There is no linking. Only a call table descriptor is published in a named block of memory." I can only interpret from that that there is a call table, where your applications call into interfaces that have not been exported for non-GPL use. This is not what I call "completely separate". Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A conservative is a man who believes that nothing should be done for the first time. - Alfred E. Wiggam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: defconfig: add unified config for RPi3 and RPi4
From: Matthias Brugger Provide a defconfig which allows us to boot Raspberrry Pi 4 and Raspberry Pi 3 Model B/B+ Instead of using the embedded DTB as done in RPi3 we use the devicetree provided by the firmware. Signed-off-by: Matthias Brugger --- This patch is based on the series to enable one binary for RPi3 and RPi4: https://patchwork.ozlabs.org/project/uboot/list/?series=140696 arch/arm/mach-bcm283x/Kconfig | 7 ++ configs/rpi_arm64_defconfig | 45 +++ 2 files changed, 52 insertions(+) create mode 100644 configs/rpi_arm64_defconfig diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig index e8e0ff0eb4..00419bf254 100644 --- a/arch/arm/mach-bcm283x/Kconfig +++ b/arch/arm/mach-bcm283x/Kconfig @@ -188,6 +188,13 @@ config TARGET_RPI_4 This option creates a build targeting the ARMv8/AArch64 ISA. select BCM2711_64B +config TARGET_RPI_ARM64 + bool "Raspberry Pi one binary 64-bit build" + help + Support for all armv8 based Raspberry Pi variants, such as + the RPi 4 model B, in AArch64 (64-bit) mode. + select ARM64 + endchoice config SYS_BOARD diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig new file mode 100644 index 00..f4e113f58c --- /dev/null +++ b/configs/rpi_arm64_defconfig @@ -0,0 +1,45 @@ +CONFIG_ARM=y +CONFIG_ARM64=y +CONFIG_TARGET_RPI_ARM64=y +CONFIG_ARCH_BCM283X=y +CONFIG_SYS_TEXT_BASE=0x0008 +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_DISTRO_DEFAULTS=y +CONFIG_NR_DRAM_BANKS=2 +CONFIG_OF_BOARD_SETUP=y +CONFIG_USE_PREBOOT=y +CONFIG_PREBOOT="usb start" +CONFIG_MISC_INIT_R=y +# CONFIG_DISPLAY_CPUINFO is not set +# CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_SYS_PROMPT="U-Boot> " +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_GPIO=y +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +CONFIG_CMD_FS_UUID=y +CONFIG_OF_BOARD=y +CONFIG_ENV_FAT_INTERFACE="mmc" +CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y +CONFIG_DM_KEYBOARD=y +CONFIG_DM_MMC=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_BCM2835=y +CONFIG_PHYLIB=y +CONFIG_DM_ETH=y +CONFIG_PINCTRL=y +# CONFIG_PINCTRL_GENERIC is not set +# CONFIG_REQUIRE_SERIAL_CONSOLE is not set +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_DWC2=y +CONFIG_USB_KEYBOARD=y +CONFIG_USB_HOST_ETHER=y +CONFIG_USB_ETHER_LAN78XX=y +CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_DM_VIDEO=y +CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_CONSOLE_SCROLL_LINES=10 +CONFIG_PHYS_TO_BUS=y +CONFIG_OF_LIBFDT_OVERLAY=y -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [uboot PATCH 1/4] phy: ti-pipe3: Use TRM recommended settings for SATA DPLL
The AM572x Technical Reference Manual, SPRUHZ6H,
Revised November 2016 [1], shows recommended settings for the
SATA DPLL in Table 26-8. DPLL CLKDCOLDO Recommended Settings.
Use those settings in the driver. The TRM does not show
a value for 20MHz SYS_CLK so we use something close to the
26MHz setting.
[1] - http://www.ti.com/lit/ug/spruhz6h/spruhz6h.pdf
Signed-off-by: Roger Quadros
---
drivers/phy/ti-pipe3-phy.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/ti-pipe3-phy.c b/drivers/phy/ti-pipe3-phy.c
index e7e78e3c56..f3b071399c 100644
--- a/drivers/phy/ti-pipe3-phy.c
+++ b/drivers/phy/ti-pipe3-phy.c
@@ -346,13 +346,13 @@ static int pipe3_phy_probe(struct udevice *dev)
}
static struct pipe3_dpll_map dpll_map_sata[] = {
- {1200, {1000, 7, 4, 6, 0} },/* 12 MHz */
- {1680, {714, 7, 4, 6, 0} }, /* 16.8 MHz */
- {1920, {625, 7, 4, 6, 0} }, /* 19.2 MHz */
- {2000, {600, 7, 4, 6, 0} }, /* 20 MHz */
- {2600, {461, 7, 4, 6, 0} }, /* 26 MHz */
- {3840, {312, 7, 4, 6, 0} }, /* 38.4 MHz */
- { },/* Terminator */
+ {1200, {625, 4, 4, 6, 0} }, /* 12 MHz */
+ {1680, {625, 6, 4, 7, 0} }, /* 16.8 MHz */
+ {1920, {625, 7, 4, 6, 0} }, /* 19.2 MHz */
+ {2000, {750, 9, 4, 6, 0} }, /* 20 MHz */
+ {2600, {750, 12, 4, 6, 0} },/* 26 MHz */
+ {3840, {625, 15, 4, 6, 0} },/* 38.4 MHz */
+ { },/* Terminator */
};
static struct pipe3_dpll_map dpll_map_usb[] = {
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [uboot PATCH 2/4] phy: ti-pipe3: Introduce mode property in driver data
Introduce a mode property in the driver data so that
we don't have to keep using "of_device_is_compatible()"
throughtout the driver.
No functional change.
Signed-off-by: Roger Quadros
---
drivers/phy/ti-pipe3-phy.c | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/ti-pipe3-phy.c b/drivers/phy/ti-pipe3-phy.c
index f3b071399c..935dc7afb6 100644
--- a/drivers/phy/ti-pipe3-phy.c
+++ b/drivers/phy/ti-pipe3-phy.c
@@ -54,14 +54,18 @@
#define PLL_IDLE_TIME 100 /* in milliseconds */
#define PLL_LOCK_TIME 100 /* in milliseconds */
+enum pipe3_mode { PIPE3_MODE_PCIE = 1,
+ PIPE3_MODE_SATA,
+ PIPE3_MODE_USBSS };
+
struct omap_pipe3 {
void __iomem*pll_ctrl_base;
void __iomem*power_reg;
void __iomem*pll_reset_reg;
struct pipe3_dpll_map *dpll_map;
+ enum pipe3_mode mode;
};
-
struct pipe3_dpll_params {
u16 m;
u8 n;
@@ -75,6 +79,11 @@ struct pipe3_dpll_map {
struct pipe3_dpll_params params;
};
+struct pipe3_data {
+ enum pipe3_mode mode;
+ struct pipe3_dpll_map *dpll_map;
+};
+
static inline u32 omap_pipe3_readl(void __iomem *addr, unsigned offset)
{
return readl(addr + offset);
@@ -317,6 +326,7 @@ static int pipe3_phy_probe(struct udevice *dev)
fdt_addr_t addr;
fdt_size_t sz;
struct omap_pipe3 *pipe3 = dev_get_priv(dev);
+ struct pipe3_data *data;
addr = devfdt_get_addr_size_index(dev, 2, );
if (addr == FDT_ADDR_T_NONE) {
@@ -334,14 +344,16 @@ static int pipe3_phy_probe(struct udevice *dev)
if (!pipe3->power_reg)
return -EINVAL;
- if (device_is_compatible(dev, "ti,phy-pipe3-sata")) {
+ data = (struct pipe3_data *)dev_get_driver_data(dev);
+ pipe3->mode = data->mode;
+ pipe3->dpll_map = data->dpll_map;
+
+ if (pipe3->mode == PIPE3_MODE_SATA) {
pipe3->pll_reset_reg = get_reg(dev, "syscon-pllreset");
if (!pipe3->pll_reset_reg)
return -EINVAL;
}
- pipe3->dpll_map = (struct pipe3_dpll_map *)dev_get_driver_data(dev);
-
return 0;
}
@@ -365,9 +377,19 @@ static struct pipe3_dpll_map dpll_map_usb[] = {
{ },/* Terminator */
};
+static struct pipe3_data data_usb = {
+ .mode = PIPE3_MODE_USBSS,
+ .dpll_map = dpll_map_usb,
+};
+
+static struct pipe3_data data_sata = {
+ .mode = PIPE3_MODE_SATA,
+ .dpll_map = dpll_map_sata,
+};
+
static const struct udevice_id pipe3_phy_ids[] = {
- { .compatible = "ti,phy-pipe3-sata", .data = (ulong)_map_sata },
- { .compatible = "ti,omap-usb3", .data = (ulong)_map_usb},
+ { .compatible = "ti,phy-pipe3-sata", .data = (ulong)_sata },
+ { .compatible = "ti,omap-usb3", .data = (ulong)_usb},
{ }
};
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [uboot PATCH 3/4] phy: ti-pipe3: improve DPLL stability for SATA & USB
For increased DPLL stability use the settings recommended in
the TRM [1] for PHY_RX registers for SATA and USB.
For SATA we need to use spread spectrum settings even
though we don't have spread spectrum enabled. The
suggested non-spread spectrum settings don't work.
[1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf
Signed-off-by: Roger Quadros
---
drivers/phy/ti-pipe3-phy.c | 193 +
1 file changed, 193 insertions(+)
diff --git a/drivers/phy/ti-pipe3-phy.c b/drivers/phy/ti-pipe3-phy.c
index 935dc7afb6..b9c8591470 100644
--- a/drivers/phy/ti-pipe3-phy.c
+++ b/drivers/phy/ti-pipe3-phy.c
@@ -50,6 +50,62 @@
#define OMAP_CTRL_PIPE3_PHY_TX_RX_POWERON 0x3
#define OMAP_CTRL_PIPE3_PHY_TX_RX_POWEROFF 0x0
+/* PHY RX Registers */
+#define PIPE3_PHY_RX_ANA_PROGRAMMABILITY 0x000C
+#define INTERFACE_MASK GENMASK(31, 27)
+#define INTERFACE_SHIFT27
+#define INTERFACE_MODE_USBSS BIT(4)
+#define INTERFACE_MODE_SATA_1P5BIT(3)
+#define INTERFACE_MODE_SATA_3P0BIT(2)
+#define INTERFACE_MODE_PCIEBIT(0)
+
+#define LOSD_MASK GENMASK(17, 14)
+#define LOSD_SHIFT 14
+#define MEM_PLLDIV GENMASK(6, 5)
+
+#define PIPE3_PHY_RX_TRIM 0x001C
+#define MEM_DLL_TRIM_SEL_MASK GENMASK(31, 30)
+#define MEM_DLL_TRIM_SHIFT 30
+
+#define PIPE3_PHY_RX_DLL 0x0024
+#define MEM_DLL_PHINT_RATE_MASKGENMASK(31, 30)
+#define MEM_DLL_PHINT_RATE_SHIFT 30
+
+#define PIPE3_PHY_RX_DIGITAL_MODES 0x0028
+#define MEM_HS_RATE_MASK GENMASK(28, 27)
+#define MEM_HS_RATE_SHIFT 27
+#define MEM_OVRD_HS_RATE BIT(26)
+#define MEM_OVRD_HS_RATE_SHIFT 26
+#define MEM_CDR_FASTLOCK BIT(23)
+#define MEM_CDR_FASTLOCK_SHIFT 23
+#define MEM_CDR_LBW_MASK GENMASK(22, 21)
+#define MEM_CDR_LBW_SHIFT 21
+#define MEM_CDR_STEPCNT_MASK GENMASK(20, 19)
+#define MEM_CDR_STEPCNT_SHIFT 19
+#define MEM_CDR_STL_MASK GENMASK(18, 16)
+#define MEM_CDR_STL_SHIFT 16
+#define MEM_CDR_THR_MASK GENMASK(15, 13)
+#define MEM_CDR_THR_SHIFT 13
+#define MEM_CDR_THR_MODE BIT(12)
+#define MEM_CDR_THR_MODE_SHIFT 12
+#define MEM_CDR_2NDO_SDM_MODE BIT(11)
+#define MEM_CDR_2NDO_SDM_MODE_SHIFT11
+
+#define PIPE3_PHY_RX_EQUALIZER 0x0038
+#define MEM_EQLEV_MASK GENMASK(31, 16)
+#define MEM_EQLEV_SHIFT16
+#define MEM_EQFTC_MASK GENMASK(15, 11)
+#define MEM_EQFTC_SHIFT11
+#define MEM_EQCTL_MASK GENMASK(10, 7)
+#define MEM_EQCTL_SHIFT7
+#define MEM_OVRD_EQLEV BIT(2)
+#define MEM_OVRD_EQLEV_SHIFT 2
+#define MEM_OVRD_EQFTC BIT(1)
+#define MEM_OVRD_EQFTC_SHIFT 1
+
+#define SATA_PHY_RX_IO_AND_A2D_OVERRIDES 0x44
+#define MEM_CDR_LOS_SOURCE_MASKGENMASK(10, 9)
+#define MEM_CDR_LOS_SOURCE_SHIFT 9
#define PLL_IDLE_TIME 100 /* in milliseconds */
#define PLL_LOCK_TIME 100 /* in milliseconds */
@@ -58,12 +114,35 @@ enum pipe3_mode { PIPE3_MODE_PCIE = 1,
PIPE3_MODE_SATA,
PIPE3_MODE_USBSS };
+struct pipe3_settings {
+ u8 ana_interface;
+ u8 ana_losd;
+ u8 dig_fastlock;
+ u8 dig_lbw;
+ u8 dig_stepcnt;
+ u8 dig_stl;
+ u8 dig_thr;
+ u8 dig_thr_mode;
+ u8 dig_2ndo_sdm_mode;
+ u8 dig_hs_rate;
+ u8 dig_ovrd_hs_rate;
+ u8 dll_trim_sel;
+ u8 dll_phint_rate;
+ u8 eq_lev;
+ u8 eq_ftc;
+ u8 eq_ctl;
+ u8 eq_ovrd_lev;
+ u8 eq_ovrd_ftc;
+};
+
struct omap_pipe3 {
void __iomem*pll_ctrl_base;
+ void __iomem*phy_rx;
void __iomem*power_reg;
void __iomem*pll_reset_reg;
struct pipe3_dpll_map *dpll_map;
enum pipe3_mode mode;
+ struct pipe3_settings settings;
};
struct pipe3_dpll_params {
@@ -82,6 +161,7 @@ struct pipe3_dpll_map {
struct pipe3_data {
enum pipe3_mode mode;
struct pipe3_dpll_map *dpll_map;
+ struct pipe3_settings settings;
};
static inline u32 omap_pipe3_readl(void __iomem *addr, unsigned offset)
@@ -199,6 +279,60 @@ static void omap_control_pipe3_power(struct omap_pipe3
*pipe3, int on)
writel(val, pipe3->power_reg);
}
+static void ti_pipe3_calibrate(struct omap_pipe3 *phy)
+{
+ u32 val;
+ struct pipe3_settings *s = >settings;
+
+ val = omap_pipe3_readl(phy->phy_rx, PIPE3_PHY_RX_ANA_PROGRAMMABILITY);
+ val &= ~(INTERFACE_MASK | LOSD_MASK | MEM_PLLDIV);
+ val =
[U-Boot] [uboot PATCH 4/4] phy: ti-pipe3: Fix SATA & USB PHY power up sequence
As per "Table 26-7. SATA PHY Subsystem Low-Level Programming Sequence"
in TRM [1] we need to turn on SATA_PHY_TX before SATA_PHY_RX.
[1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf
Signed-off-by: Roger Quadros
---
drivers/phy/ti-pipe3-phy.c | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/phy/ti-pipe3-phy.c b/drivers/phy/ti-pipe3-phy.c
index b9c8591470..0c59552bb8 100644
--- a/drivers/phy/ti-pipe3-phy.c
+++ b/drivers/phy/ti-pipe3-phy.c
@@ -41,14 +41,14 @@
#define SATA_PLL_SOFT_RESET (1<<18)
/* PHY POWER CONTROL Register */
-#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK 0x003FC000
-#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT0xE
+#define PIPE3_PHY_PWRCTL_CLK_CMD_MASK GENMASK(21, 14)
+#define PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT 14
-#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK0xFFC0
-#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT 0x16
+#define PIPE3_PHY_PWRCTL_CLK_FREQ_MASK GENMASK(31, 22)
+#define PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT22
-#define OMAP_CTRL_PIPE3_PHY_TX_RX_POWERON 0x3
-#define OMAP_CTRL_PIPE3_PHY_TX_RX_POWEROFF 0x0
+#define PIPE3_PHY_RX_POWERON (0x1 << PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT)
+#define PIPE3_PHY_TX_POWERON (0x2 << PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT)
/* PHY RX Registers */
#define PIPE3_PHY_RX_ANA_PROGRAMMABILITY 0x000C
@@ -264,19 +264,21 @@ static void omap_control_pipe3_power(struct omap_pipe3
*pipe3, int on)
rate = rate/100;
if (on) {
- val &= ~(OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK |
- OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK);
- val |= OMAP_CTRL_PIPE3_PHY_TX_RX_POWERON <<
- OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
- val |= rate <<
- OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT;
+ val &= ~(PIPE3_PHY_PWRCTL_CLK_CMD_MASK |
+PIPE3_PHY_PWRCTL_CLK_FREQ_MASK);
+ val |= rate << PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT;
+ writel(val, pipe3->power_reg);
+
+ /* Power up TX before RX for SATA & USB */
+ val |= PIPE3_PHY_TX_POWERON;
+ writel(val, pipe3->power_reg);
+
+ val |= PIPE3_PHY_RX_POWERON;
+ writel(val, pipe3->power_reg);
} else {
- val &= ~OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK;
- val |= OMAP_CTRL_PIPE3_PHY_TX_RX_POWEROFF <<
- OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
+ val &= ~PIPE3_PHY_PWRCTL_CLK_CMD_MASK;
+ writel(val, pipe3->power_reg);
}
-
- writel(val, pipe3->power_reg);
}
static void ti_pipe3_calibrate(struct omap_pipe3 *phy)
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] pinctrl: bcm283x: Add compatible for RPi4
From: Matthias Brugger
The Raspberry Pi 4 upstream kernel device tree instroduces
a new compatible for the pinctroller. Add this to the driver
so that we can boot with the upstream kernel DT.
Signed-off-by: Matthias Brugger
---
drivers/pinctrl/broadcom/pinctrl-bcm283x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
index 3be080d29e..8d9074e0c1 100644
--- a/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
+++ b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
@@ -99,6 +99,7 @@ static int bcm283x_pinctrl_get_gpio_mux(struct udevice *dev,
int banknum,
static const struct udevice_id bcm2835_pinctrl_id[] = {
{.compatible = "brcm,bcm2835-gpio"},
+ {.compatible = "brcm,bcm2711-gpio"},
{}
};
--
2.23.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] `uclass_find_device_by_name` fails to find the device
Hi everybody,
I've noticed that commit 4213609cc7fb78f84b2ea63f4a5691b60d01c248
changes how `uclass.c:uclass_find_device_by_name` function compares the
names for finding devices.
Because of this I have an issue when having a DTS and trying to find a
device by name.
The `lists.c:lists_bind_fdt` function will bind a device to a device
node tree and use the node name as device name.
```
lists.c:
int lists_bind_fdt(..)
...
name = ofnode_get_name(node);
...
```
Because of this devices will end up having names like: i2c@021a,
pfuze100@8...
When using `uclass.c:uclass_find_device_by_name` to get a device, before
the change, this was not an issue since `strncmp` was used with the
length of the name making a call like
`uclass_find_device_by_name(pfuze100)` successfully even if the device
name was `pfuze100@8`.
```
if (!strncmp(dev->name, name, strlen(name))) {
```
However after the change (which I think is correct), the check fails,
resulting in not finding the expected device, since the device name has
also the suffix `@...` included.
What's the proper fix here:
1. Changing the `lists.c:lists_bind_fdt` to drop the `@` suffix?
Note: Could this be a problem when having the same node names but
different addressees in DTS {e.g.foo@1, foo@2}
2. When using `uclass.c:uclass_find_device_by_name` the user should take
in consideration that `@..` suffix needs to be added.
Note: This could be a problem when same code is used with different
DTSs.
3. Changing the comparation in `uclass.c:uclass_find_device_by_name` to
ignore the part after `@` for device names.
4. What else?
Regads,
Nandor
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [uboot PATCH 0/4] phy: ti-pipe3: Match TRM sequence & settings
Hi, We need to follow the TRM sequence and settings to ensure that the DPLL & PHY operates correctly over the entire temperature range. Tested with SATA on dra7-evm. Since this is a bug fix, I will suggest to include it in current -rc. cheers, -roger Roger Quadros (4): phy: ti-pipe3: Use TRM recommended settings for SATA DPLL phy: ti-pipe3: Introduce mode property in driver data phy: ti-pipe3: improve DPLL stability for SATA & USB phy: ti-pipe3: Fix SATA & USB PHY power up sequence drivers/phy/ti-pipe3-phy.c | 281 - 1 file changed, 249 insertions(+), 32 deletions(-) -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] sun8i: h3: Support H3 variant of Orange Pi Zero Plus 2
Orangepi Zero Plus 2 is an open-source single-board computer, available
in two Allwinner SOC variants, H3 and H5. We add support for H3 variant
here, as the H5 is already supported.
H3 Orangepi Zero Plus 2 has:
- Quad-core Cortex-A7
- 512MB DDR3
- microSD slot and 8GB eMMC
- Debug TTL UART
- HDMI
- Wifi + BT
- OTG + power supply
Signed-off-by: Diego Rondini
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts | 139 ++
board/sunxi/MAINTAINERS | 5 +
configs/orangepi_zero_plus2_h3_defconfig | 19 +++
4 files changed, 165 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts
create mode 100644 configs/orangepi_zero_plus2_h3_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 251d32ca62..5c7b8cfcc9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -513,7 +513,8 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \
sun8i-h3-orangepi-pc.dtb \
sun8i-h3-orangepi-pc-plus.dtb \
sun8i-h3-orangepi-plus.dtb \
- sun8i-h3-orangepi-plus2e.dtb
+ sun8i-h3-orangepi-plus2e.dtb \
+ sun8i-h3-orangepi-zero-plus2.dtb
dtb-$(CONFIG_MACH_SUN8I_R40) += \
sun8i-r40-bananapi-m2-ultra.dtb \
sun8i-v40-bananapi-m2-berry.dtb
diff --git a/arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts
b/arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts
new file mode 100644
index 00..f2f7b7a925
--- /dev/null
+++ b/arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts
@@ -0,0 +1,139 @@
+/*
+ * Copyright (C) 2017 Jagan Teki
+ * Copyright (C) 2018 Diego Rondini
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun8i-h3.dtsi"
+
+#include
+
+/ {
+ model = "OrangePi Zero Plus2 H3";
+ compatible = "xunlong,orangepi-zero-plus2-h3", "allwinner,sun8i-h3";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <_out_con>;
+ };
+ };
+ };
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = < 0 9 GPIO_ACTIVE_LOW>; /* PA9 */
+ post-power-on-delay-ms = <200>;
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <_con_in>;
+ };
+};
+
+ {
+ vmmc-supply = <_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
[U-Boot] [PATCH] include/env.h: Ensure ulong is defined
To fix these failures when building with musl: include/env.h:166:1: error: unknown type name 'ulong'; did you mean 'long'? ensure that ulong is defined. Signed-off-by: Alistair Francis --- include/env.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/env.h b/include/env.h index b72239f6a5..5ca49a3456 100644 --- a/include/env.h +++ b/include/env.h @@ -13,6 +13,8 @@ #include #include +typedef unsigned long ulong; + struct environment_s; /* Value for environment validity */ -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] arm: dts: hummingboard: add cubox/hummingboard DT
These DT files are copied from kernel v5.3 with very little changes. Notably missing are audmux port configuration nodes, since U-Boot does not provide the IMX_AUDMUX_ macros. Add -u-boot.dtsi files to support GPIO based board detect. Signed-off-by: Baruch Siach --- arch/arm/dts/Makefile | 18 + arch/arm/dts/imx6dl-cubox-i-emmc-som-v15.dts | 52 ++ arch/arm/dts/imx6dl-cubox-i-som-v15.dts | 51 ++ arch/arm/dts/imx6dl-cubox-i.dts | 51 ++ .../dts/imx6dl-hummingboard-emmc-som-v15.dts | 53 ++ arch/arm/dts/imx6dl-hummingboard-som-v15.dts | 52 ++ arch/arm/dts/imx6dl-hummingboard.dts | 52 ++ ...6dl-hummingboard2-emmc-som-v15-u-boot.dtsi | 1 + .../dts/imx6dl-hummingboard2-emmc-som-v15.dts | 55 ++ arch/arm/dts/imx6dl-hummingboard2-som-v15.dts | 54 ++ arch/arm/dts/imx6dl-hummingboard2.dts | 53 ++ arch/arm/dts/imx6q-cubox-i-emmc-som-v15.dts | 60 ++ arch/arm/dts/imx6q-cubox-i-som-v15.dts| 59 ++ arch/arm/dts/imx6q-cubox-i.dts| 59 ++ .../dts/imx6q-hummingboard-emmc-som-v15.dts | 61 ++ arch/arm/dts/imx6q-hummingboard-som-v15.dts | 60 ++ arch/arm/dts/imx6q-hummingboard.dts | 60 ++ ...x6q-hummingboard2-emmc-som-v15-u-boot.dtsi | 1 + .../dts/imx6q-hummingboard2-emmc-som-v15.dts | 63 ++ arch/arm/dts/imx6q-hummingboard2-som-v15.dts | 62 ++ arch/arm/dts/imx6q-hummingboard2.dts | 61 ++ arch/arm/dts/imx6qdl-cubox-i.dtsi | 269 + arch/arm/dts/imx6qdl-hummingboard.dtsi| 347 +++ ...qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 36 ++ arch/arm/dts/imx6qdl-hummingboard2-emmc.dtsi | 72 +++ arch/arm/dts/imx6qdl-hummingboard2.dtsi | 556 ++ arch/arm/dts/imx6qdl-sr-som-brcm.dtsi | 144 + arch/arm/dts/imx6qdl-sr-som-emmc.dtsi | 70 +++ arch/arm/dts/imx6qdl-sr-som-ti.dtsi | 170 ++ arch/arm/dts/imx6qdl-sr-som.dtsi | 121 30 files changed, 2823 insertions(+) create mode 100644 arch/arm/dts/imx6dl-cubox-i-emmc-som-v15.dts create mode 100644 arch/arm/dts/imx6dl-cubox-i-som-v15.dts create mode 100644 arch/arm/dts/imx6dl-cubox-i.dts create mode 100644 arch/arm/dts/imx6dl-hummingboard-emmc-som-v15.dts create mode 100644 arch/arm/dts/imx6dl-hummingboard-som-v15.dts create mode 100644 arch/arm/dts/imx6dl-hummingboard.dts create mode 100644 arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15-u-boot.dtsi create mode 100644 arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts create mode 100644 arch/arm/dts/imx6dl-hummingboard2-som-v15.dts create mode 100644 arch/arm/dts/imx6dl-hummingboard2.dts create mode 100644 arch/arm/dts/imx6q-cubox-i-emmc-som-v15.dts create mode 100644 arch/arm/dts/imx6q-cubox-i-som-v15.dts create mode 100644 arch/arm/dts/imx6q-cubox-i.dts create mode 100644 arch/arm/dts/imx6q-hummingboard-emmc-som-v15.dts create mode 100644 arch/arm/dts/imx6q-hummingboard-som-v15.dts create mode 100644 arch/arm/dts/imx6q-hummingboard.dts create mode 100644 arch/arm/dts/imx6q-hummingboard2-emmc-som-v15-u-boot.dtsi create mode 100644 arch/arm/dts/imx6q-hummingboard2-emmc-som-v15.dts create mode 100644 arch/arm/dts/imx6q-hummingboard2-som-v15.dts create mode 100644 arch/arm/dts/imx6q-hummingboard2.dts create mode 100644 arch/arm/dts/imx6qdl-cubox-i.dtsi create mode 100644 arch/arm/dts/imx6qdl-hummingboard.dtsi create mode 100644 arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi create mode 100644 arch/arm/dts/imx6qdl-hummingboard2-emmc.dtsi create mode 100644 arch/arm/dts/imx6qdl-hummingboard2.dtsi create mode 100644 arch/arm/dts/imx6qdl-sr-som-brcm.dtsi create mode 100644 arch/arm/dts/imx6qdl-sr-som-emmc.dtsi create mode 100644 arch/arm/dts/imx6qdl-sr-som-ti.dtsi create mode 100644 arch/arm/dts/imx6qdl-sr-som.dtsi diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 3b8dc2f56fd2..866ee1605722 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -560,7 +560,16 @@ dtb-$(CONFIG_MX53) += imx53-cx9020.dtb \ ifneq ($(CONFIG_MX6DL)$(CONFIG_MX6QDL)$(CONFIG_MX6S),) dtb-y += \ + imx6dl-cubox-i.dtb \ + imx6dl-cubox-i-emmc-som-v15.dtb \ + imx6dl-cubox-i-som-v15.dtb \ imx6dl-dhcom-pdk2.dtb \ + imx6dl-hummingboard2.dtb \ + imx6dl-hummingboard2-emmc-som-v15.dtb \ + imx6dl-hummingboard2-som-v15.dtb \ + imx6dl-hummingboard.dtb \ + imx6dl-hummingboard-emmc-som-v15.dtb \ + imx6dl-hummingboard-som-v15.dtb \ imx6dl-icore.dtb \ imx6dl-icore-mipi.dtb \ imx6dl-icore-rqs.dtb \ @@ -577,8 +586,17 @@ ifneq ($(CONFIG_MX6Q)$(CONFIG_MX6QDL),) dtb-y += \ imx6-apalis.dtb \ imx6q-cm-fx6.dtb \ + imx6q-cubox-i.dtb \ + imx6q-cubox-i-emmc-som-v15.dtb \ + imx6q-cubox-i-som-v15.dtb \ imx6q-dhcom-pdk2.dtb \ imx6q-display5.dtb \ + imx6q-hummingboard2.dtb \ + imx6q-hummingboard2-emmc-som-v15.dtb \ +
Re: [U-Boot] required host packages on Travis CI
On Wed, Nov 06, 2019 at 04:12:40PM +0900, AKASHI Takahiro wrote: > Tom, > > On Fri, Nov 01, 2019 at 09:07:04AM -0400, Tom Rini wrote: > > On Fri, Nov 01, 2019 at 02:34:35PM +0900, AKASHI Takahiro wrote: > > > Tom, > > > > > > On Wed, Oct 30, 2019 at 07:17:29AM -0400, Tom Rini wrote: > > > > On Wed, Oct 30, 2019 at 03:30:58PM +0900, AKASHI Takahiro wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > In test/py/README.md, all the required host packages and their > > > > > versions to be used on 14.04(Trusty) are listed. On the other hand, > > > > > ".travis.yml" names a similar but different list of packages. > > > > > The latter also specifies the distribution to be used, which is > > > > > xenial(16.04). > > > > > > > > > > * How would like to sync those two different lists? > > > > > * Do you still think it appropriate to mention the "tested versions" > > > > > in README.md at all? > > > > > > > > The README is woefully out of date and I addressed that as part of: > > > > http://patchwork.ozlabs.org/project/uboot/list/?series=138421 > > > > > > Oooops, I haven't noticed it. > > > > > > > Please note that moving forward, the GitLab and Azure CI files need to > > > > be kept up to date as well, but with at least one of them being updated > > > > I can help with the other two. Thanks! > > > > > > Although I don't understand what you mean above very well, > > > some questions: > > > 1) Is it good enough just to put a package name in .travis.yml's addons > > >if all the required binaries (commands) are installed in standard > > >PATH? > > > > For Travis, the list of packages there is what we apt-get install, so > > yes, it's found in the normal PATH and we can add to that as needed. > > Good. > > > > 2) I need efitools package, but a version provided in xenial(16.04) is > > >quite old and some command has a fatal bug. So my current py test > > >will fail. > > >We need v1.5.2 or later of efitools, which is only available > > >in cosmic(18.10) and later. > > >How can we address this issue? Do we need some script to build efitools > > >on our own on GitLab/Travis server? > > > > Currently, Travis, GitLab and Azure all use Bionic. Is the version of > > the tool available there good enough? > > Not really. The version in Bionic(18.04) is still v1.4.2. > Only Cosmic(18.10) and later support v1.8.1, which should work. > > > If not, can we grab only the > > tool .deb and install that by hand? We have to do that for libmpfr4 for > > example today. > > From where do you fetch a pre-built package of libmpfr4? > future release of ubuntu? > If so, we may want to try one from Cosmic or later. We wget it from 16.04 and install it manually, as it's otherwise stand-alone. You would need to explore doing that for this tool, but grabbing from cosmic. -- 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] [GIT] Pull request: u-boot-dfu (06.11.2019)
Hi Marek, > On 11/6/19 12:27 PM, Lukasz Majewski wrote: > > Hi Marek, > > > >> On 11/6/19 10:21 AM, Lukasz Majewski wrote: > >>> Dear Marek, > >>> > >>> The following changes since commit > >>> 14d39c9e1dc9397febd58399a70f32e7481bbc27: > >>> > >>> travis: Rework how we write the ~/.buildman file (2019-11-05 > >>> 10:44:16 -0500) > >>> > >>> are available in the Git repository at: > >>> > >>> g...@gitlab.denx.de:u-boot/custodians/u-boot-dfu.git > >>> > >>> BRANCH: master > >>> https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/commits/master > >>> > >>> Merge TAG: > >>> https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/-/tags/u-boot-dfu-06Nov2019 > >>> > >>> for you to fetch changes up to > >>> 8c5df588e89b2bf4aad4c95b17cfc8634b8dcaaf: > >>> > >>> usb: composite: add BOS descriptor support to composite > >>> framework (2019-11-06 01:01:06 +0100) > >>> > >>> > >>> My remark: > >>> > >>> - Those patches are new code, (like adding the USB 3.0 controller > >>> from Cadence) hence IMHO it would be best to add them to your next > >>> PR > >> > >> We are already in -rc cycle, so fixes only. Should this PR be for > >> -next ? > >> > > > > The BOS support is a fix do SS USB. > > > > And the Cadence USB support is a new code, which is not touching any > > relevant parts of USB (and IMHO it applies to the same category as > > adding new boards outside the merge window). > > > > However, if you believe that this code is not eligible for > > u-boot-usb/master ,then yes please pull it into -next. > > That decision is up to you. If you think this is safe to pull in RC1, > I don't mind either way. Ok. Lets then pull it in RC1. Thanks for understanding :-) 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 pgpYgQqgNo5Q4.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: rk3399: rock960: Update config for TPL
On Mon, Oct 14, 2019 at 9:58 AM Kever Yang wrote: > > Hi Peter, > > On 2019/10/9 下午7:20, Peter Robinson wrote: > > The SPL is now running at SDRAM, and 0x1 is used by BL31, > and the ARM SPL do not support relocate now, we need reserved > 0x5 so that it won't overwrite the code when we load the > bl31 to target space. > We should remove this after we enable the relocate feature. > > The SPL need malloc 0x9000 for MMC as buffer used for transfer > data to IRAM(The EMMC DMA can not transfer data to IRAM directly). > > Signed-off-by: Peter Robinson > --- > configs/rock960-rk3399_defconfig | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/configs/rock960-rk3399_defconfig > b/configs/rock960-rk3399_defconfig > index cb3c68db6b..f211a65587 100644 > --- a/configs/rock960-rk3399_defconfig > +++ b/configs/rock960-rk3399_defconfig > @@ -2,19 +2,21 @@ CONFIG_ARM=y > CONFIG_ARCH_ROCKCHIP=y > CONFIG_SYS_TEXT_BASE=0x0020 > CONFIG_ROCKCHIP_RK3399=y > -CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000 > +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x5 > > > Could you update this to '0x0'(drop this line to use default value) since I > have > > already update this in another mail[0], I can merge them together. Update sent. Thanks, Peter > Thanks, > > - Kever > > [0] https://patchwork.ozlabs.org/patch/1173719/ > > CONFIG_TARGET_ROCK960_RK3399=y > CONFIG_SPL_STACK_R_ADDR=0x8 > CONFIG_DEBUG_UART_BASE=0xFF1A > CONFIG_DEBUG_UART_CLOCK=2400 > CONFIG_DEBUG_UART=y > -CONFIG_SPL_TEXT_BASE=0xff8c2000 > CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock960.dtb" > # CONFIG_DISPLAY_CPUINFO is not set > CONFIG_DISPLAY_BOARDINFO_LATE=y > # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set > CONFIG_SPL_STACK_R=y > -CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000 > +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 > +CONFIG_SPL_ATF=y > +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y > +CONFIG_TPL=y > CONFIG_SYS_PROMPT="rock960 => " > CONFIG_CMD_BOOTZ=y > CONFIG_CMD_GPT=y > @@ -56,4 +58,6 @@ CONFIG_USB_ETHER_ASIX88179=y > CONFIG_USB_ETHER_MCS7830=y > CONFIG_USB_ETHER_RTL8152=y > CONFIG_USB_ETHER_SMSC95XX=y > +CONFIG_USE_TINY_PRINTF=y > +CONFIG_SPL_TINY_MEMSET=y > CONFIG_ERRNO_STR=y ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] rockchip: rk3399: rock960: Update config for TPL
The SPL is now running at SDRAM, and 0x1 is used by BL31, and the ARM SPL do not support relocate now, we need reserved 0x5 so that it won't overwrite the code when we load the bl31 to target space. We should remove this after we enable the relocate feature. Signed-off-by: Peter Robinson --- configs/rock960-rk3399_defconfig | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/configs/rock960-rk3399_defconfig b/configs/rock960-rk3399_defconfig index cb3c68db6b..01b84a4742 100644 --- a/configs/rock960-rk3399_defconfig +++ b/configs/rock960-rk3399_defconfig @@ -8,13 +8,15 @@ CONFIG_SPL_STACK_R_ADDR=0x8 CONFIG_DEBUG_UART_BASE=0xFF1A CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_DEBUG_UART=y -CONFIG_SPL_TEXT_BASE=0xff8c2000 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock960.dtb" # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set CONFIG_SPL_STACK_R=y -CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000 +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 +CONFIG_SPL_ATF=y +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y +CONFIG_TPL=y CONFIG_SYS_PROMPT="rock960 => " CONFIG_CMD_BOOTZ=y CONFIG_CMD_GPT=y @@ -56,4 +58,6 @@ CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_USE_TINY_PRINTF=y +CONFIG_SPL_TINY_MEMSET=y CONFIG_ERRNO_STR=y -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu (06.11.2019)
On 11/6/19 12:27 PM, Lukasz Majewski wrote: > Hi Marek, > >> On 11/6/19 10:21 AM, Lukasz Majewski wrote: >>> Dear Marek, >>> >>> The following changes since commit >>> 14d39c9e1dc9397febd58399a70f32e7481bbc27: >>> >>> travis: Rework how we write the ~/.buildman file (2019-11-05 >>> 10:44:16 -0500) >>> >>> are available in the Git repository at: >>> >>> g...@gitlab.denx.de:u-boot/custodians/u-boot-dfu.git >>> >>> BRANCH: master >>> https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/commits/master >>> >>> Merge TAG: >>> https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/-/tags/u-boot-dfu-06Nov2019 >>> >>> for you to fetch changes up to >>> 8c5df588e89b2bf4aad4c95b17cfc8634b8dcaaf: >>> >>> usb: composite: add BOS descriptor support to composite framework >>> (2019-11-06 01:01:06 +0100) >>> >>> >>> My remark: >>> >>> - Those patches are new code, (like adding the USB 3.0 controller >>> from Cadence) hence IMHO it would be best to add them to your next >>> PR >> >> We are already in -rc cycle, so fixes only. Should this PR be for >> -next ? >> > > The BOS support is a fix do SS USB. > > And the Cadence USB support is a new code, which is not touching any > relevant parts of USB (and IMHO it applies to the same category as > adding new boards outside the merge window). > > However, if you believe that this code is not eligible for > u-boot-usb/master ,then yes please pull it into -next. That decision is up to you. If you think this is safe to pull in RC1, I don't mind either way. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu (06.11.2019)
Hi Marek, > On 11/6/19 10:21 AM, Lukasz Majewski wrote: > > Dear Marek, > > > > The following changes since commit > > 14d39c9e1dc9397febd58399a70f32e7481bbc27: > > > > travis: Rework how we write the ~/.buildman file (2019-11-05 > > 10:44:16 -0500) > > > > are available in the Git repository at: > > > > g...@gitlab.denx.de:u-boot/custodians/u-boot-dfu.git > > > > BRANCH: master > > https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/commits/master > > > > Merge TAG: > > https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/-/tags/u-boot-dfu-06Nov2019 > > > > for you to fetch changes up to > > 8c5df588e89b2bf4aad4c95b17cfc8634b8dcaaf: > > > > usb: composite: add BOS descriptor support to composite framework > > (2019-11-06 01:01:06 +0100) > > > > > > My remark: > > > > - Those patches are new code, (like adding the USB 3.0 controller > > from Cadence) hence IMHO it would be best to add them to your next > > PR > > We are already in -rc cycle, so fixes only. Should this PR be for > -next ? > The BOS support is a fix do SS USB. And the Cadence USB support is a new code, which is not touching any relevant parts of USB (and IMHO it applies to the same category as adding new boards outside the merge window). However, if you believe that this code is not eligible for u-boot-usb/master ,then yes please pull it into -next. 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 pgpw_8jfwyEGw.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
On Wed, Nov 6, 2019 at 2:51 PM Rick Chen wrote: > > Hi Anup > > > > > On Wed, Nov 6, 2019 at 2:18 PM Anup Patel wrote: > > > > > > On Wed, Nov 6, 2019 at 12:14 PM Rick Chen wrote: > > > > > > > > Hi Anup > > > > > > > > > > > > > > On Tue, Nov 5, 2019 at 7:19 AM Rick Chen wrote: > > > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 1:42 PM Anup Patel > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 6:30 AM Alan Kao > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > > > > > > > Thanks for the critics. Comments below. > > > > > > > > > > On Wed, Oct 30, 2019 at 06:38:00PM +0800, Bin Meng wrote: > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 10:50 AM Rick Chen > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 25, 2019 at 2:18 PM Andes > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Rick Chen > > > > > > > > > > > > > > > > > > > > > > > > > > > > It will work fine due to hart 0 always will be main > > > > > > > > > > > > > > hart coincidentally. When develop SPL flow, I try to > > > > > > > > > > > > > > force other harts to be main hart. And it will go > > > > > > > > > > > > > > wrong in sending IPI flow. So fix it. > > > > > > > > > > > > > > > > > > > > > > > > > > Fix what? Does this commit contain 2 fixes, or just 1 > > > > > > > > > > > > > fix? > > > > > > > > > > > > > > > > > > > > > > > > Yes, it include two fixs. But they will cause one > > > > > > > > > > > > negative result > > > > > > > > > > > > that only hart 0 can send ipi to other harts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Having this fix, any hart can be main hart in > > > > > > > > > > > > > > U-Boot SPL > > > > > > > > > > > > > > theoretically, but it still fail somewhere. After > > > > > > > > > > > > > > dig in > > > > > > > > > > > > > > and found there is an assumption that hart 0 shall > > > > > > > > > > > > > > be > > > > > > > > > > > > > > main hart in OpenSbi. > > > > > > > > > > > > > > > > > > > > > > > > > > So does this mean there is a bug in OpenSBI too? > > > > > > > > > > > > > > > > > > > > > > > > I am not sure if it is a bug. Maybe it is a compatible > > > > > > > > > > > > issue. > > > > > > > > > > > > There is a limitation that only hart 0 can be main hart > > > > > > > > > > > > in OpenSBI. > > > > > > > > > > > > > > > > > > > > > > I don't think OpenSBI has such limitation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please check the source. > > > > > > > > > > https://github.com/riscv/opensbi/blob/master/firmware/fw_base.S#L54 > > > > > > > > > > > > > > > > > > > > Apparently, the FIRST TWO LINEs of the initialization are > > > > > > > > > > the > > > > > > > > > > 1. get hart ID. > > > > > > > > > > 2. determine which route to take based on their ID > > > > > > > > > > respectively. > > > > > > > > > > > > > > > > > > > > So, I do think OpenSBI has this signature, if you are not > > > > > > > > > > willing to call it > > > > > > > > > > a limitation. > > > > > > > > > > > > > > > > > > This dependency on hart id #0 was not there until we added > > > > > > > > > self-relocation > > > > > > > > > in OpenSBI for FW_DYNAMIC. > > > > > > > > > > > > > > > > > > I will try to fix this in OpenSBI but we might end-up having > > > > > > > > > boot_lottery. > > > > > > > > > > > > > > > > I have send a patch to fix this OpenSBI: > > > > > > > > "[PATCH] firmware: Introduce relocation lottery" > > > > > > > > > > > > > > > > Can you try above patch and see if that helps ? > > > > > > > > > > > > > > > > It will be great if you can provide Tested-by to my patch as > > > > > > > > well. > > > > > > > > > > > > > > > > > > > > > > > > > > > I can not find this patch in mailing list. > > > > > > Can you provide a hyperlink ? > > > > > > > > > > You can try latest riscv/opensbi master. > > > > > > > > > > I have tested the patch on SiFive Unleashed multiple times. > > > > > > > > I have tried this patch, but it fail > > > > firmware: Introduce relocation lottery( > > > > 98f4a208995b027662a7b04a25e4fa5df5f3eefe) > > > > > > > > The scenario was as below: > > > > There are 4 harts run in U-Boot SPL, hart 0 play as main hart. > > > > The hart 1 will receive ipi and come into OpenSBI(0x100) from > > > > U-Boot SPL(0x0), meanwhile hart 0,2,3 still run in U-Boot SPL. > > > > Then hart 1 will do _relocate_copy_to_lower which will copy data from > > > > 0x100 to 0x0. > > > > And it will corrupt U-Boot SPL. > > > > > > The self-relocation in OpenSBI firmwares ensures that OpenSBI firmware > > > are moved to the
[U-Boot] [PATCH 3/4] configs: ls1028a: Enable FSPI support
Enable FSPI controller support. So, flash environment can now be used Signed-off-by: Kuldeep Singh --- Depends on https://patchwork.ozlabs.org/patch/1190054/ https://patchwork.ozlabs.org/patch/1190052/ https://patchwork.ozlabs.org/patch/1190051/ configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1028aqds_tfa_defconfig | 1 + configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1028ardb_tfa_defconfig | 1 + 4 files changed, 4 insertions(+) diff --git a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig index 3170d81aaf..c115885923 100644 --- a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig @@ -65,6 +65,7 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_FSL_DSPI=y +CONFIG_NXP_FSPI=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y diff --git a/configs/ls1028aqds_tfa_defconfig b/configs/ls1028aqds_tfa_defconfig index 2da7b1d94e..1fbba3c73d 100644 --- a/configs/ls1028aqds_tfa_defconfig +++ b/configs/ls1028aqds_tfa_defconfig @@ -68,6 +68,7 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_FSL_DSPI=y +CONFIG_NXP_FSPI=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y diff --git a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig index c1e88b5465..caba7f7be4 100644 --- a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig @@ -65,6 +65,7 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_FSL_DSPI=y +CONFIG_NXP_FSPI=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 5ff34047a7..f1c8f0348d 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -69,6 +69,7 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_FSL_DSPI=y +CONFIG_NXP_FSPI=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] arm: dts: ls1028a: Add FSPI node properties
Align flexspi node properties with linux device-tree properties
Tested on LS1028A-RDB
Signed-off-by: Kuldeep Singh
---
Depends on
https://patchwork.ozlabs.org/patch/1190054/
https://patchwork.ozlabs.org/patch/1190052/
https://patchwork.ozlabs.org/patch/1190051/
arch/arm/dts/fsl-ls1028a-qds.dts | 16
arch/arm/dts/fsl-ls1028a-rdb.dts | 15 +++
2 files changed, 31 insertions(+)
diff --git a/arch/arm/dts/fsl-ls1028a-qds.dts b/arch/arm/dts/fsl-ls1028a-qds.dts
index 5d143ba077..3fd37beedf 100644
--- a/arch/arm/dts/fsl-ls1028a-qds.dts
+++ b/arch/arm/dts/fsl-ls1028a-qds.dts
@@ -13,6 +13,10 @@
/ {
model = "NXP Layerscape 1028a QDS Board";
compatible = "fsl,ls1028a-qds", "fsl,ls1028a";
+ aliases {
+ spi0 =
+ };
+
};
{
@@ -36,6 +40,18 @@
};
+ {
+ status = "okay";
+
+ mt35xu02g0: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <5000>;
+ reg = <0>;
+ };
+};
+
{
status = "okay";
u-boot,dm-pre-reloc;
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 3d5e8ade21..a8f40855b6 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -13,6 +13,9 @@
/ {
model = "NXP Layerscape 1028a RDB Board";
compatible = "fsl,ls1028a-rdb", "fsl,ls1028a";
+ aliases {
+ spi0 =
+ };
};
{
@@ -36,6 +39,18 @@
mmc-hs200-1_8v;
};
+ {
+ status = "okay";
+
+ mt35xu02g0: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <5000>;
+ reg = <0>;
+ };
+};
+
{
status = "okay";
u-boot,dm-pre-reloc;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] configs: lx2160a: Enable FSPI support
Enable FSPI controller support. So, flash environment can now be used Signed-off-by: Kuldeep Singh --- Depends on https://patchwork.ozlabs.org/patch/1190054/ https://patchwork.ozlabs.org/patch/1190052/ https://patchwork.ozlabs.org/patch/1190051/ configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 1 + configs/lx2160aqds_tfa_defconfig | 2 ++ configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 1 + configs/lx2160ardb_tfa_defconfig | 2 ++ 4 files changed, 6 insertions(+) diff --git a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig index 3d4506bbff..dc3a613b48 100644 --- a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig @@ -61,6 +61,7 @@ CONFIG_DM_SERIAL=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_FSL_DSPI=y +CONFIG_NXP_FSPI=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y diff --git a/configs/lx2160aqds_tfa_defconfig b/configs/lx2160aqds_tfa_defconfig index ef774af62e..568da54c71 100644 --- a/configs/lx2160aqds_tfa_defconfig +++ b/configs/lx2160aqds_tfa_defconfig @@ -28,6 +28,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_BOARD_FIXUP=y CONFIG_DEFAULT_DEVICE_TREE="fsl-lx2160a-qds" CONFIG_ENV_IS_IN_MMC=y +CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_SATA_CEVA=y @@ -61,6 +62,7 @@ CONFIG_DM_SCSI=y CONFIG_DM_SERIAL=y CONFIG_SPI=y CONFIG_DM_SPI=y +CONFIG_NXP_FSPI=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y diff --git a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig index ede4e0f75f..786f2c6a78 100644 --- a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig @@ -56,6 +56,7 @@ CONFIG_DM_SCSI=y CONFIG_DM_SERIAL=y CONFIG_SPI=y CONFIG_DM_SPI=y +CONFIG_NXP_FSPI=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y diff --git a/configs/lx2160ardb_tfa_defconfig b/configs/lx2160ardb_tfa_defconfig index 1ad4ad79b5..e59bbb275b 100644 --- a/configs/lx2160ardb_tfa_defconfig +++ b/configs/lx2160ardb_tfa_defconfig @@ -29,6 +29,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_BOARD_FIXUP=y CONFIG_DEFAULT_DEVICE_TREE="fsl-lx2160a-rdb" CONFIG_ENV_IS_IN_MMC=y +CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_SATA_CEVA=y @@ -60,6 +61,7 @@ CONFIG_DM_SCSI=y CONFIG_DM_SERIAL=y CONFIG_SPI=y CONFIG_DM_SPI=y +CONFIG_NXP_FSPI=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] arm: dts: lx2160a: Add FSPI node properties
Align flexspi node properties with linux device-tree properties
Tested on LX2160A-RDB
Signed-off-by: Kuldeep Singh
---
Depends on
https://patchwork.ozlabs.org/patch/1190054/
https://patchwork.ozlabs.org/patch/1190052/
https://patchwork.ozlabs.org/patch/1190051/
arch/arm/dts/fsl-lx2160a-rdb.dts | 24 +++-
arch/arm/dts/fsl-lx2160a.dtsi| 15 +++
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-lx2160a-rdb.dts b/arch/arm/dts/fsl-lx2160a-rdb.dts
index 46a9239c25..e542c6992a 100644
--- a/arch/arm/dts/fsl-lx2160a-rdb.dts
+++ b/arch/arm/dts/fsl-lx2160a-rdb.dts
@@ -16,7 +16,9 @@
/ {
model = "NXP Layerscape LX2160ARDB Board";
compatible = "fsl,lx2160ardb", "fsl,lx2160a";
-
+ aliases {
+ spi0 =
+ };
};
{
@@ -28,6 +30,26 @@
mmc-hs200-1_8v;
};
+ {
+ status = "okay";
+
+ mt35xu512aba0: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <5000>;
+ reg = <0>;
+ };
+
+ mt35xu512aba1: flash@1 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <5000>;
+ reg = <1>;
+ };
+};
+
{
status = "okay";
u-boot,dm-pre-reloc;
diff --git a/arch/arm/dts/fsl-lx2160a.dtsi b/arch/arm/dts/fsl-lx2160a.dtsi
index a189333e40..8c2ab1da31 100644
--- a/arch/arm/dts/fsl-lx2160a.dtsi
+++ b/arch/arm/dts/fsl-lx2160a.dtsi
@@ -6,6 +6,8 @@
*
*/
+#include
+
/ {
compatible = "fsl,lx2160a";
interrupt-parent = <>;
@@ -49,6 +51,19 @@
<1 10 0x8>; /* Hypervisor PPI, active-low */
};
+ fspi: flexspi@20c {
+ compatible = "nxp,lx2160a-fspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x20c 0x0 0x1>,
+ <0x0 0x2000 0x0 0x1000>;
+ reg-names = "fspi_base", "fspi_mmap";
+ clocks = < 4 3>, < 4 3>;
+ clock-names = "fspi_en", "fspi";
+ interrupts = ;
+ status = "disabled";
+ };
+
i2c0: i2c@200 {
compatible = "fsl,vf610-i2c";
#address-cells = <1>;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu (06.11.2019)
On 11/6/19 10:21 AM, Lukasz Majewski wrote: > Dear Marek, > > The following changes since commit > 14d39c9e1dc9397febd58399a70f32e7481bbc27: > > travis: Rework how we write the ~/.buildman file (2019-11-05 10:44:16 > -0500) > > are available in the Git repository at: > > g...@gitlab.denx.de:u-boot/custodians/u-boot-dfu.git > > BRANCH: master > https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/commits/master > > Merge TAG: > https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/-/tags/u-boot-dfu-06Nov2019 > > for you to fetch changes up to 8c5df588e89b2bf4aad4c95b17cfc8634b8dcaaf: > > usb: composite: add BOS descriptor support to composite framework > (2019-11-06 01:01:06 +0100) > > > My remark: > > - Those patches are new code, (like adding the USB 3.0 controller from > Cadence) hence IMHO it would be best to add them to your next PR We are already in -rc cycle, so fixes only. Should this PR be for -next ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
The following changes since commit 412326d1bc2d346d7b4faad6fa547eaf065681a2: Merge tag 'u-boot-clk-23Oct2019' of https://gitlab.denx.de/u-boot/custodians/u-boot-clk (2019-10-30 13:13:46 -0400) are available in the Git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 02b0e1a36c5bc20174299312556ec4e266872bd6: usb: ehci-hcd: Keep async schedule running (2019-10-31 12:13:40 +0100) Marek Szyprowski (5): gadget: f_thor: properly enable 3rd endpoint defined by the protocol cmd: thor: select DFU subsystem also for 'thor' download tool dfu: mmc: add support for in-partition offset dwc3: flush cache only if there is a buffer attached to a request thor: fix error path after g_dnl_register() failure Marek Vasut (3): usb: storage: Limit transfer size to 120 kiB usb: storage: Only clear READY flag on error usb: ehci-hcd: Keep async schedule running Patrick Delaunay (10): dfu: cosmetic: cleanup sf to avoid checkpatch error doc: dfu: Add dfu documentation dfu: sf: add partition support for nor backend dfu: prepare the support of multiple interface dfu: allow to manage DFU on several devices dfu: allow read with no data without error for EOF indication dfu: add backend for MTD device dfu: add partition support for MTD backend dfu: add DFU virtual backend dfu: add callback for flush and initiated operation Ralph Siemsen (1): dfu: dfu_nand: reduce verbosity Vignesh Raghavendra (1): dwc3-generic: Don't fail probe if clk/reset entries are absent cmd/Kconfig | 1 + cmd/dfu.c | 21 --- cmd/thordown.c | 3 +- common/usb_storage.c| 49 doc/README.dfu | 270 +++ drivers/dfu/Kconfig | 21 +++ drivers/dfu/Makefile| 2 + drivers/dfu/dfu.c | 145 +-- drivers/dfu/dfu_mmc.c | 13 - drivers/dfu/dfu_mtd.c | 311 + drivers/dfu/dfu_nand.c | 2 +- drivers/dfu/dfu_sf.c| 56 ++- drivers/dfu/dfu_virt.c | 49 drivers/usb/dwc3/dwc3-generic.c | 4 +- drivers/usb/dwc3/gadget.c | 3 +- drivers/usb/gadget/f_thor.c | 7 +++ drivers/usb/host/ehci-hcd.c | 51 +++-- include/dfu.h | 71 +++ 18 files changed, 992 insertions(+), 87 deletions(-) create mode 100644 doc/README.dfu create mode 100644 drivers/dfu/dfu_mtd.c create mode 100644 drivers/dfu/dfu_virt.c ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] [PATCH v3 1/3] spi: nxp_fspi: new driver for the FlexSPI controller
Hi, > -Original Message- > From: Michael Walle > Sent: Wednesday, November 6, 2019 4:33 AM > To: u-boot@lists.denx.de > Cc: Vignesh R ; Prabhakar X > ; Kuldeep Singh ; > Michael Walle ; Jagan Teki > > Subject: [EXT] [PATCH v3 1/3] spi: nxp_fspi: new driver for the FlexSPI > controller > > Caution: EXT Email > > This is a port of the kernel's spi-nxp-fspi driver. It uses the new spi-mem > interface and does not expose the more generic spi-xfer interface. The source > was taken from the v5.3-rc3 tag. > > The port was straightforward: > - remove the interrupt handling and the completion by busy polling the >controller > - remove locks > - move the setup of the memory windows into claim_bus() > - move the setup of the speed into set_speed() > - port the device tree bindings from the original fspi_probe() to >ofdata_to_platdata() > > There were only some style change fixes, no change in any logic. For example, > there are busy loops where the return code is not handled correctly, eg. only > prints a warning with WARN_ON(). This port intentionally left most functions > unchanged to ease future bugfixes. > > This was tested on a custom LS1028A board. Because the LS1028A doesn't > have proper clock framework support, changing the clock speed was not > tested. This also means that it is not possible to change the SPI speed on > LS1028A for now (neither is it possible in the linux driver). > > Signed-off-by: Michael Walle > Reviewed-by: Jagan Teki Tested on LS1028A-RDB and LX2160A-RDB Tested-by: Kuldeep Singh Regards, Kuldeep ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
Hi Anup > > On Wed, Nov 6, 2019 at 2:18 PM Anup Patel wrote: > > > > On Wed, Nov 6, 2019 at 12:14 PM Rick Chen wrote: > > > > > > Hi Anup > > > > > > > > > > > On Tue, Nov 5, 2019 at 7:19 AM Rick Chen wrote: > > > > > > > > > > Hi Anup > > > > > > > > > > > > On Thu, Oct 31, 2019 at 1:42 PM Anup Patel > > > > > > > wrote: > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 6:30 AM Alan Kao > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > > > > > Thanks for the critics. Comments below. > > > > > > > > > On Wed, Oct 30, 2019 at 06:38:00PM +0800, Bin Meng wrote: > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 10:50 AM Rick Chen > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Bin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 25, 2019 at 2:18 PM Andes > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > From: Rick Chen > > > > > > > > > > > > > > > > > > > > > > > > > > It will work fine due to hart 0 always will be main > > > > > > > > > > > > > hart coincidentally. When develop SPL flow, I try to > > > > > > > > > > > > > force other harts to be main hart. And it will go > > > > > > > > > > > > > wrong in sending IPI flow. So fix it. > > > > > > > > > > > > > > > > > > > > > > > > Fix what? Does this commit contain 2 fixes, or just 1 > > > > > > > > > > > > fix? > > > > > > > > > > > > > > > > > > > > > > Yes, it include two fixs. But they will cause one > > > > > > > > > > > negative result > > > > > > > > > > > that only hart 0 can send ipi to other harts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Having this fix, any hart can be main hart in U-Boot > > > > > > > > > > > > > SPL > > > > > > > > > > > > > theoretically, but it still fail somewhere. After dig > > > > > > > > > > > > > in > > > > > > > > > > > > > and found there is an assumption that hart 0 shall be > > > > > > > > > > > > > main hart in OpenSbi. > > > > > > > > > > > > > > > > > > > > > > > > So does this mean there is a bug in OpenSBI too? > > > > > > > > > > > > > > > > > > > > > > I am not sure if it is a bug. Maybe it is a compatible > > > > > > > > > > > issue. > > > > > > > > > > > There is a limitation that only hart 0 can be main hart > > > > > > > > > > > in OpenSBI. > > > > > > > > > > > > > > > > > > > > I don't think OpenSBI has such limitation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please check the source. > > > > > > > > > https://github.com/riscv/opensbi/blob/master/firmware/fw_base.S#L54 > > > > > > > > > > > > > > > > > > Apparently, the FIRST TWO LINEs of the initialization are the > > > > > > > > > 1. get hart ID. > > > > > > > > > 2. determine which route to take based on their ID > > > > > > > > > respectively. > > > > > > > > > > > > > > > > > > So, I do think OpenSBI has this signature, if you are not > > > > > > > > > willing to call it > > > > > > > > > a limitation. > > > > > > > > > > > > > > > > This dependency on hart id #0 was not there until we added > > > > > > > > self-relocation > > > > > > > > in OpenSBI for FW_DYNAMIC. > > > > > > > > > > > > > > > > I will try to fix this in OpenSBI but we might end-up having > > > > > > > > boot_lottery. > > > > > > > > > > > > > > I have send a patch to fix this OpenSBI: > > > > > > > "[PATCH] firmware: Introduce relocation lottery" > > > > > > > > > > > > > > Can you try above patch and see if that helps ? > > > > > > > > > > > > > > It will be great if you can provide Tested-by to my patch as well. > > > > > > > > > > > > > > > > > > > > > > > I can not find this patch in mailing list. > > > > > Can you provide a hyperlink ? > > > > > > > > You can try latest riscv/opensbi master. > > > > > > > > I have tested the patch on SiFive Unleashed multiple times. > > > > > > I have tried this patch, but it fail > > > firmware: Introduce relocation lottery( > > > 98f4a208995b027662a7b04a25e4fa5df5f3eefe) > > > > > > The scenario was as below: > > > There are 4 harts run in U-Boot SPL, hart 0 play as main hart. > > > The hart 1 will receive ipi and come into OpenSBI(0x100) from > > > U-Boot SPL(0x0), meanwhile hart 0,2,3 still run in U-Boot SPL. > > > Then hart 1 will do _relocate_copy_to_lower which will copy data from > > > 0x100 to 0x0. > > > And it will corrupt U-Boot SPL. > > > > The self-relocation in OpenSBI firmwares ensures that OpenSBI firmware > > are moved to the FW_TEXT_START before entering C code. This helps > > us load OpenSBI firmwares anywhere in RAM. > > > > However, OpenSBI firmwares don't know where the U-Boot SPL is running. > > > > In your case, both OpenSBI FW_DYNAMIC and U-Boot SPL are linked to > > address same address 0x0. This means secondary HARTs cannot safely > > wait while primary HART enters OpenSBI.
[U-Boot] [GIT] Pull request: u-boot-dfu (06.11.2019)
Dear Marek, The following changes since commit 14d39c9e1dc9397febd58399a70f32e7481bbc27: travis: Rework how we write the ~/.buildman file (2019-11-05 10:44:16 -0500) are available in the Git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-dfu.git BRANCH: master https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/commits/master Merge TAG: https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/-/tags/u-boot-dfu-06Nov2019 for you to fetch changes up to 8c5df588e89b2bf4aad4c95b17cfc8634b8dcaaf: usb: composite: add BOS descriptor support to composite framework (2019-11-06 01:01:06 +0100) My remark: - Those patches are new code, (like adding the USB 3.0 controller from Cadence) hence IMHO it would be best to add them to your next PR Sherry Sun (1): usb: udc: Introduce ->udc_set_speed() method T Karthik Reddy (1): usb: composite: add BOS descriptor support to composite framework Vignesh Raghavendra (7): list: import list_first_entry_or_null() bitmaps: import for_each_set_bit() macro usb: gadget: Add match_ep() op to usb_gadget_ops usb: Add Cadence USB3 host and gadget driver usb: cdns3: gadget: Implement udc_set_speed() callback usb: cdns3: Add TI wrapper driver for CDNS USB3 controller usb: gadget: Add gadget_is_cdns3() macro Travis-CI: https://travis-ci.org/lmajewski/u-boot-dfu/builds/607937090 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 pgpMO2keVbBwc.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
On Wed, Nov 6, 2019 at 2:18 PM Anup Patel wrote: > > On Wed, Nov 6, 2019 at 12:14 PM Rick Chen wrote: > > > > Hi Anup > > > > > > > > On Tue, Nov 5, 2019 at 7:19 AM Rick Chen wrote: > > > > > > > > Hi Anup > > > > > > > > > > On Thu, Oct 31, 2019 at 1:42 PM Anup Patel > > > > > > wrote: > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 6:30 AM Alan Kao > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > > > Thanks for the critics. Comments below. > > > > > > > > On Wed, Oct 30, 2019 at 06:38:00PM +0800, Bin Meng wrote: > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 10:50 AM Rick Chen > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Bin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 25, 2019 at 2:18 PM Andes > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > From: Rick Chen > > > > > > > > > > > > > > > > > > > > > > > > It will work fine due to hart 0 always will be main > > > > > > > > > > > > hart coincidentally. When develop SPL flow, I try to > > > > > > > > > > > > force other harts to be main hart. And it will go > > > > > > > > > > > > wrong in sending IPI flow. So fix it. > > > > > > > > > > > > > > > > > > > > > > Fix what? Does this commit contain 2 fixes, or just 1 fix? > > > > > > > > > > > > > > > > > > > > Yes, it include two fixs. But they will cause one negative > > > > > > > > > > result > > > > > > > > > > that only hart 0 can send ipi to other harts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Having this fix, any hart can be main hart in U-Boot SPL > > > > > > > > > > > > theoretically, but it still fail somewhere. After dig in > > > > > > > > > > > > and found there is an assumption that hart 0 shall be > > > > > > > > > > > > main hart in OpenSbi. > > > > > > > > > > > > > > > > > > > > > > So does this mean there is a bug in OpenSBI too? > > > > > > > > > > > > > > > > > > > > I am not sure if it is a bug. Maybe it is a compatible > > > > > > > > > > issue. > > > > > > > > > > There is a limitation that only hart 0 can be main hart in > > > > > > > > > > OpenSBI. > > > > > > > > > > > > > > > > > > I don't think OpenSBI has such limitation. > > > > > > > > > > > > > > > > > > > > > > > > > Please check the source. > > > > > > > > https://github.com/riscv/opensbi/blob/master/firmware/fw_base.S#L54 > > > > > > > > > > > > > > > > Apparently, the FIRST TWO LINEs of the initialization are the > > > > > > > > 1. get hart ID. > > > > > > > > 2. determine which route to take based on their ID respectively. > > > > > > > > > > > > > > > > So, I do think OpenSBI has this signature, if you are not > > > > > > > > willing to call it > > > > > > > > a limitation. > > > > > > > > > > > > > > This dependency on hart id #0 was not there until we added > > > > > > > self-relocation > > > > > > > in OpenSBI for FW_DYNAMIC. > > > > > > > > > > > > > > I will try to fix this in OpenSBI but we might end-up having > > > > > > > boot_lottery. > > > > > > > > > > > > I have send a patch to fix this OpenSBI: > > > > > > "[PATCH] firmware: Introduce relocation lottery" > > > > > > > > > > > > Can you try above patch and see if that helps ? > > > > > > > > > > > > It will be great if you can provide Tested-by to my patch as well. > > > > > > > > > > > > > > > > > > > I can not find this patch in mailing list. > > > > Can you provide a hyperlink ? > > > > > > You can try latest riscv/opensbi master. > > > > > > I have tested the patch on SiFive Unleashed multiple times. > > > > I have tried this patch, but it fail > > firmware: Introduce relocation lottery( > > 98f4a208995b027662a7b04a25e4fa5df5f3eefe) > > > > The scenario was as below: > > There are 4 harts run in U-Boot SPL, hart 0 play as main hart. > > The hart 1 will receive ipi and come into OpenSBI(0x100) from > > U-Boot SPL(0x0), meanwhile hart 0,2,3 still run in U-Boot SPL. > > Then hart 1 will do _relocate_copy_to_lower which will copy data from > > 0x100 to 0x0. > > And it will corrupt U-Boot SPL. > > The self-relocation in OpenSBI firmwares ensures that OpenSBI firmware > are moved to the FW_TEXT_START before entering C code. This helps > us load OpenSBI firmwares anywhere in RAM. > > However, OpenSBI firmwares don't know where the U-Boot SPL is running. > > In your case, both OpenSBI FW_DYNAMIC and U-Boot SPL are linked to > address same address 0x0. This means secondary HARTs cannot safely > wait while primary HART enters OpenSBI. You should hold secondary HARTs > in U-Boot SPL only till OpenSBI FW_DYNAMIC and U-Boot proper are > loaded in RAM by primary HART. All your HARTs should jump to OpenSBI > at the same time after everything is loaded in RAM. I see the issue now. The U-Boot SPL is first letting secondary HART jump to OpenSBI and primary HART jumps to OpenSBI at
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
On Wed, Nov 6, 2019 at 12:14 PM Rick Chen wrote: > > Hi Anup > > > > > On Tue, Nov 5, 2019 at 7:19 AM Rick Chen wrote: > > > > > > Hi Anup > > > > > > > > On Thu, Oct 31, 2019 at 1:42 PM Anup Patel > > > > > wrote: > > > > > > > > > > > > On Thu, Oct 31, 2019 at 6:30 AM Alan Kao > > > > > > wrote: > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > Thanks for the critics. Comments below. > > > > > > > On Wed, Oct 30, 2019 at 06:38:00PM +0800, Bin Meng wrote: > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 10:50 AM Rick Chen > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Bin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > On Fri, Oct 25, 2019 at 2:18 PM Andes > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > From: Rick Chen > > > > > > > > > > > > > > > > > > > > > > It will work fine due to hart 0 always will be main > > > > > > > > > > > hart coincidentally. When develop SPL flow, I try to > > > > > > > > > > > force other harts to be main hart. And it will go > > > > > > > > > > > wrong in sending IPI flow. So fix it. > > > > > > > > > > > > > > > > > > > > Fix what? Does this commit contain 2 fixes, or just 1 fix? > > > > > > > > > > > > > > > > > > Yes, it include two fixs. But they will cause one negative > > > > > > > > > result > > > > > > > > > that only hart 0 can send ipi to other harts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Having this fix, any hart can be main hart in U-Boot SPL > > > > > > > > > > > theoretically, but it still fail somewhere. After dig in > > > > > > > > > > > and found there is an assumption that hart 0 shall be > > > > > > > > > > > main hart in OpenSbi. > > > > > > > > > > > > > > > > > > > > So does this mean there is a bug in OpenSBI too? > > > > > > > > > > > > > > > > > > I am not sure if it is a bug. Maybe it is a compatible issue. > > > > > > > > > There is a limitation that only hart 0 can be main hart in > > > > > > > > > OpenSBI. > > > > > > > > > > > > > > > > I don't think OpenSBI has such limitation. > > > > > > > > > > > > > > > > > > > > > > Please check the source. > > > > > > > https://github.com/riscv/opensbi/blob/master/firmware/fw_base.S#L54 > > > > > > > > > > > > > > Apparently, the FIRST TWO LINEs of the initialization are the > > > > > > > 1. get hart ID. > > > > > > > 2. determine which route to take based on their ID respectively. > > > > > > > > > > > > > > So, I do think OpenSBI has this signature, if you are not willing > > > > > > > to call it > > > > > > > a limitation. > > > > > > > > > > > > This dependency on hart id #0 was not there until we added > > > > > > self-relocation > > > > > > in OpenSBI for FW_DYNAMIC. > > > > > > > > > > > > I will try to fix this in OpenSBI but we might end-up having > > > > > > boot_lottery. > > > > > > > > > > I have send a patch to fix this OpenSBI: > > > > > "[PATCH] firmware: Introduce relocation lottery" > > > > > > > > > > Can you try above patch and see if that helps ? > > > > > > > > > > It will be great if you can provide Tested-by to my patch as well. > > > > > > > > > > > > > > > I can not find this patch in mailing list. > > > Can you provide a hyperlink ? > > > > You can try latest riscv/opensbi master. > > > > I have tested the patch on SiFive Unleashed multiple times. > > I have tried this patch, but it fail > firmware: Introduce relocation lottery( > 98f4a208995b027662a7b04a25e4fa5df5f3eefe) > > The scenario was as below: > There are 4 harts run in U-Boot SPL, hart 0 play as main hart. > The hart 1 will receive ipi and come into OpenSBI(0x100) from > U-Boot SPL(0x0), meanwhile hart 0,2,3 still run in U-Boot SPL. > Then hart 1 will do _relocate_copy_to_lower which will copy data from > 0x100 to 0x0. > And it will corrupt U-Boot SPL. The self-relocation in OpenSBI firmwares ensures that OpenSBI firmware are moved to the FW_TEXT_START before entering C code. This helps us load OpenSBI firmwares anywhere in RAM. However, OpenSBI firmwares don't know where the U-Boot SPL is running. In your case, both OpenSBI FW_DYNAMIC and U-Boot SPL are linked to address same address 0x0. This means secondary HARTs cannot safely wait while primary HART enters OpenSBI. You should hold secondary HARTs in U-Boot SPL only till OpenSBI FW_DYNAMIC and U-Boot proper are loaded in RAM by primary HART. All your HARTs should jump to OpenSBI at the same time after everything is loaded in RAM. Regards, Anup ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [v4] armv8: ls1028ardb: enable DisplayPort Power support
Enable DP_PWR signal to power the DP to HDMI converter cable. Signed-off-by: Wen He --- board/freescale/ls1028a/ls1028a.c | 14 ++ include/configs/ls1028a_common.h | 3 +++ 2 files changed, 17 insertions(+) diff --git a/board/freescale/ls1028a/ls1028a.c b/board/freescale/ls1028a/ls1028a.c index 095971448f..c71ed21e9f 100644 --- a/board/freescale/ls1028a/ls1028a.c +++ b/board/freescale/ls1028a/ls1028a.c @@ -83,6 +83,20 @@ int board_init(void) dm_i2c_write(dev, 0x0b, , 1); #endif +#endif + +#if defined(CONFIG_TARGET_LS1028ARDB) + u8 reg; + + reg = QIXIS_READ(brdcfg[4]); + /* +* Field | Function +* 3 | DisplayPort Power Enable (net DP_PWR_EN): +* DPPWR | 0= DP_PWR is enabled. +*/ + reg &= ~(DP_PWD_EN_DEFAULT_MASK); + QIXIS_WRITE(brdcfg[4], reg); + #endif return 0; } diff --git a/include/configs/ls1028a_common.h b/include/configs/ls1028a_common.h index 40fcd22582..99f5c21689 100644 --- a/include/configs/ls1028a_common.h +++ b/include/configs/ls1028a_common.h @@ -192,6 +192,9 @@ #define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS 3 #define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS 5 +/* DisplayPort */ +#define DP_PWD_EN_DEFAULT_MASK 0x8 + #ifdef CONFIG_SECURE_BOOT #include #endif -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
