Re: [PATCH] rpi: Update the RPi Zero 2W DT filename
On 28/02/2023 11:19, Peter Robinson wrote:
Update the Raspberry Pi Zero 2W device tree file
name to match what landed upstream.
Signed-off-by: Peter Robinson
Acked-by: Matthias Brugger
Peter will you take care to push the patch?
Regards,
Matthias
---
board/raspberrypi/rpi/rpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 8603c93de77..1fa65d51212 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -158,7 +158,7 @@ static const struct rpi_model rpi_models_new_scheme[] = {
},
[0x12] = {
"Zero 2 W",
- DTB_DIR "bcm2837-rpi-zero-2.dtb",
+ DTB_DIR "bcm2837-rpi-zero-2-w.dtb",
false,
},
[0x13] = {
Re: [PATCH] rpi: Set FDT for RPi CM4 to the IO Board one
Hi Ariel,
On 16/09/2022 17:13, Ariel D'Alessandro wrote:
For the RPi CM4 (Compute Module 4), we currently try to load the dtb
file bcm2711-rpi-cm4.dtb, which is not built by the upstream kernel.
Instead, the only CM4 dtb file provided by linux upstream is the
bcm2711-rpi-cm4-io.dtb, so let's use that.
Signed-off-by: Ariel D'Alessandro
---
board/raspberrypi/rpi/rpi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 17b8108cc8..b88f80ce05 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -168,8 +168,8 @@ static const struct rpi_model rpi_models_new_scheme[] = {
true,
},
[0x14] = {
- "Compute Module 4",
- DTB_DIR "bcm2711-rpi-cm4.dtb",
+ "Compute Module 4 IO Board",
+ DTB_DIR "bcm2711-rpi-cm4-io.dtb",
We had that discussion in the past. It is supposed that most CM4s will be used
with a custom board. I don't think it's a good idea to tie the ID of the module
to a specific IO board.
Regards,
Matthias
true,
},
};
Re: [PATCH v5 00/17] Basic StarFive JH7110 RISC-V SoC support
On 13/04/2023 12:05, yanhong wang wrote: On 2023/4/13 17:03, Torsten Duwe wrote: On Thu, 13 Apr 2023 10:05:28 +0800 yanhong wang wrote: the definition of DT refers to Linux and is consistent with the definition framework of Linux. This is one of the desired goals, to avoid confusion, usually. But note there are already the -u-boot.dtsi files; in this case it would be vice-versa: U-Boot could be simple, the kernel required a different treatment. As long as the resulting tree matches the hardware! The difference between 1.2A and 1.3B is the PHY type and phy clock delay configuration, which are reflected in DT, and the difference in defconfig is the configuration of the DT file. Is defconfig defined separately or merged? You are the implementer, this is your decision. You make a proposal, and it will get accepted or not. We only make suggestions, with the intention to improve the code. Thanks. A defconfig matches a piece of hardware, which is more developer-friendly and less confusing, so defconfig is better defined separately. My opinion isIn my opinion user-friendlyness is more important then developer friendly that from an end-user point of view it's much easier to have one binary that works on all different board versions. If not users will have to know which board version they have to flash the correct U-Boot. For the RaspberryPi we even went further and put effort into U-Boot development to have one U-Boot binary which can boot RPi3 and RPi4 boards. In that sense I would advise you to revisit your decision to put a developer-friendly approach over an end-user-friendly one. As Torsten said, it shouldn't be too difficult to update the device-tree at boot time to fit the actual board you are running U-Boot on. Just my thoughts about the issue :) Best regards, Matthias The EEPROM is being prepared and will be submitted as soon as possible. Is it necessary to incorporate EEPROM into this submission? When eeprom is supported, the MAC address will be read from eeprom. The board reversion can be read from eeprom, but phy clock delay configuration cannot be read from eeprom, only in DT. But the board revision number in EEPROM can be used to differentiate between 1.2 and 1.3, right? Yes, board reversion read from eeprom can distinguish between 1.2A and 1.3B. 1.2A and 1.3B are two sets of hardware, and the differences between the hardware are defined by DT, which is more concise and clear. When I look at the code and my test results, this is my proposal to pull this in, in order to simplify things and avoid duplication. Whether you do so is up to you, see above. Let me recap: * the device tree *must* match the hardware at hand. * the differences are minor and could be patched, Copy&Waste is error prone and causes extra work. It is my firm conviction that this patch set does not introduce hardware variants, and it would be the task of the ethernet driver patch set to split the code (DT+defconfig) OR to provide a patching method. Maybe I find a few cycles to look at the EEPROM. Torsten
Re: [RFC] riscv: visionfive2: use OF_BOARD_SETUP
On 19/04/2023 13:28, Torsten Duwe wrote:
U-Boot already has a mechanism to fix up the DT before OS boot.
This avoids the excessive duplication of data and work proposed
by the explicit separation of 1.2a and 1.3b board revisions. It
will also, to a good degree, improve the user experience, as
pointed out by Matthias.
The defconfig changes required (in diffconfig format) are
-I2C n
-NET_RANDOM_ETHADDR y
+CMD_I2C y
+CMD_MISC y
+DM_I2C y
+I2C_EEPROM y
+MISC y
+MISC_INIT_R y
+OF_BOARD_SETUP y
+SPL_DM_I2C n
+SPL_MISC n
+SYS_I2C_DW y
+SYS_I2C_EEPROM_ADDR 0x0
along with the patch below. It has the neat side effect of providing
the network with the proper MAC addresses ;)
I take advantage of the fact that I²C-5 is also required to talk to the
PMIC, so it must already be initialised by OpenSBI. All that's required
is to declare the EEPROM and to pull in the drivers.
This is only a proof of concept; let me know if you like it and I can
add the other 12 DT patches to adjust_for_rev13b(), or maybe start with
1.3b as the default and go the other way, or something in between.
The last hunk, to the i2c Makefile, is IMHO an independent fix, because
the implication PCI => ACPI in designware_i2c_pci is invalid, and the
VisionFive2 config proves it. Use this quick hack for now.
Looks like a neat approach to enable a signle U-Boot binary to boot on both
platforms.
Thanks for investigating this.
Signed-off-by: Torsten Duwe
---
diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
index ff9df56ec2..fd3a1d057a 100644
--- a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
+++ b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
@@ -119,6 +119,12 @@
pinctrl-names = "default";
pinctrl-0 = <&i2c5_pins>;
status = "okay";
+
+ eeprom@50 {
+ compatible = "atmel,24c04";
+ reg = <0x50>;
+ pagesize = <0x10>;
+ };
};
&i2c6 {
diff --git a/board/starfive/visionfive2/starfive_visionfive2.c
b/board/starfive/visionfive2/starfive_visionfive2.c
index 613fe793c4..d7f846a357 100644
--- a/board/starfive/visionfive2/starfive_visionfive2.c
+++ b/board/starfive/visionfive2/starfive_visionfive2.c
@@ -7,6 +7,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#define JH7110_L2_PREFETCHER_BASE_ADDR 0x203
@@ -38,3 +42,62 @@ int board_init(void)
return 0;
}
+
+#ifdef CONFIG_MISC_INIT_R
As this is will be enabled for the board config I think we don't need the
ifedef.
+int misc_init_r(void)
+{
+ int ret = 0;
+
+#ifdef CONFIG_I2C_EEPROM
+ struct udevice *dev;
+ char mac_addr[6];
+ unsigned char pcb_rev, BOM;
+
+ ret = uclass_first_device_err(UCLASS_I2C_EEPROM, &dev);
+ if (ret)
+ goto out;
+
+ if (eth_env_get_enetaddr("ethaddr", mac_addr) == 0) {
+ int i;
+ for (i=0; i<2; i++) {
+ ret = i2c_eeprom_read(dev, 0x78+6*i, mac_addr, 6);
+ if (!ret && is_valid_ethaddr(mac_addr))
+ eth_env_set_enetaddr_by_index("eth", i,
mac_addr);
+ }
+ }
+
+ ret = i2c_eeprom_read(dev, 0x76, &pcb_rev, 1);
+ if (!ret)
+ env_set_hex("board_revision", pcb_rev);
+
+ ret = i2c_eeprom_read(dev, 0x77, &BOM, 1);
+
+ out:
+#endif
+return ret;
+}
+#endif
+
+#ifdef CONFIG_OF_BOARD_SETUP
Same here.
Regards,
Matthias
+static void adjust_for_rev13b(void * fdt)
+{
+ do_fixup_by_path(fdt, "/soc/ethernet@1604",
+"phy-mode", "rgmii-id", 9, 0);
+ /*
+ ... other fixups ...
+
+*/
+}
+
+int ft_board_setup(void *fdt, struct bd_info *bdip)
+{
+ unsigned char pcb_rev = 0;
+
+ pcb_rev = env_get_hex("board_revision", pcb_rev);
+ if (pcb_rev >= 0xB2) {
+ printf("Adjusting FDT for v1.3B board rev\n");
+ adjust_for_rev13b(fdt);
+ }
+ return 0;
+}
+#endif
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 99545df2e5..828856e40d 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -19,8 +19,10 @@ obj-$(CONFIG_SYS_I2C_CA) += i2c-cortina.o
obj-$(CONFIG_SYS_I2C_DAVINCI) += davinci_i2c.o
obj-$(CONFIG_SYS_I2C_DW) += designware_i2c.o
ifdef CONFIG_PCI
+ifdef CONFIG_ACPIGEN
obj-$(CONFIG_SYS_I2C_DW) += designware_i2c_pci.o
endif
+endif
obj-$(CONFIG_SYS_I2C_FSL) += fsl_i2c.o
obj-$(CONFIG_SYS_I2C_IHS) += ihs_i2c.o
obj-$(CONFIG_SYS_I2C_INTEL) += intel_i2c.o
Re: [RFC] riscv: visionfive2: use OF_BOARD_SETUP
Hi Torsten, On 20/04/2023 09:43, Torsten Duwe wrote: Hi Leo, thanks for the quick reply! On Thu, 20 Apr 2023 06:33:57 + Leo Liang wrote: Hi, Torsten, Matthias, On Wed, Apr 19, 2023 at 02:34:03PM +0200, Matthias Brugger wrote: On 19/04/2023 13:28, Torsten Duwe wrote: This is only a proof of concept; let me know if you like it and I can add the other 12 DT patches to adjust_for_rev13b(), or maybe start with 1.3b as the default and go the other way, or something in between. LGTM as well! Thank you very much! Again, this is only a PoC; if you agree with the concept, I clean it up and fill in the complete DT patching. Questions: shall I default to 1.3B and patch older 1.2A, or vice versa, or do it like your (starfive) patch set and start with something "neutral" and then patch both ways? And, more important, what is the I would go with the common case (I suppose that's version 1.3B) and detect and patch older version 1.2A. Regards, Matthias correct interpretation of the board revision byte -- I assume it's offset 0x76 in the EEPROM? Is it always? Is ">= 0xB2" the correct discriminator? Torsten
Re: [PATCH v5 00/17] Basic StarFive JH7110 RISC-V SoC support
On 02/05/2023 14:41, Andreas Schwab wrote: On Apr 14 2023, Matthias Brugger wrote: My opinion isIn my opinion user-friendlyness is more important then developer friendly that from an end-user point of view it's much easier to have one binary that works on all different board versions. If not users will have to know which board version they have to flash the correct U-Boot. As long as the kernel uses separate device trees, U-Boot needs to know which one to load. As it currently stands, U-Boot uses the wrong name that does not match either of the names used by the kernel, which means it will not be able find any of them. I'm not sure I get your point. The devicetree will be passed to the kernel via a pointer in a register, the kernel does not need to load the devicetree into memory, it will use the one passed by U-Boot. Regards, Matthias
Re: Running u-boot 2021.04 on Raspberry Pi 4
On 09/04/2021 10:14, Nicolas Saenz Julienne wrote:
> [ Adding Matthias for the SMBIOS part ]
>
> On Fri, 2021-04-09 at 00:00 -0700, Roman Shaposhnik wrote:
>> On Thu, Apr 8, 2021 at 8:59 PM Sean Anderson wrote:
>>> On 4/8/21 8:18 PM, Roman Shaposhnik wrote:
Hi!
first time poster, long time lurker here. Over at Project EVE
https://github.com/lf-edge/eve I've been trying to migrate
from our current u-boot v2020.07 + patches:
https://github.com/lf-edge/eve/tree/master/pkg/u-boot/patches/patches-v2020.07
to the latest u-boot 2021.04.
Great news is that most of the patches we dependent
on seem to have been pulled upstream. However, this
single *chunk* of one patchset wasn't:
https://github.com/lf-edge/eve/blob/master/pkg/u-boot/patches/patches-v2020.07/0001-usb-xhci-Load-Raspberry-Pi-4-VL805-s-firmware.patch#L293
I'm wondering what was the reason for leaving it behind,
>>>
>>> +CC Nicolas
>>>
- Get rid of PCI core patch as not needed with correct DT PCI topology
>>>
>>> also from the cover letter
>>>
This also depends on a DT/bindings patch available on the linux-mailing
lists:
https://www.mail-archive.com/linux-kernel@.../msg2205783.html
>>>
>>> The merged version of this series is
>>>
>>> https://patchwork.kernel.org/project/linux-usb/list/?series=310015&state=%2A&archive=both
>>>
Here is the relevant bit for reference/discussion:
&pcie0 {
pci@1,0 {
#address-cells = <3>;
#size-cells = <2>;
ranges;
reg = <0 0 0 0 0>;
usb@1,0 {
reg = <0x1 0 0 0 0>;
resets = <&reset
RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
};
};
};
>>>
>
> Yes, instead of using a PCI quirk we settled on a reset controller. All in all
> it is less hacky. But needs changes in DT.
>
>> Aha! Thank you so much -- this is super helpful!
>>
since without it I don't seem to have functioning USB
devices on my Raspberry Pi 4. In fact, adding it back:
https://github.com/rvs/eve/tree/u-boot/pkg/u-boot/patches/patches-v2021.04
(just that one chunk -- 'cuz the reset got upstreamed)
seems to solve the issue for me.
Another question I have is that the new u-boot seems to have
some kind of a regression that I can't quite debug. The SMBIOS
tables that it constructs during EFI boot sequence seem to be
broken (see the dmidecode output below). Again, this seems
to be a regression compared to v2020.07. Any ideas on what
could be wrong or how can I start debugging it would be
>>>
Yes, that's not working right now. I'm working on a fix for the tables:
https://patchwork.ozlabs.org/project/uboot/patch/20210406090435.19357-1-matthias@kernel.org/
This will fix the error en dmidecode but the tables will be basically empty.
Before that there was some information that helped you to identify that you are
running on a RaspberryPi.
A quick fix would be to add that information to the DTS. Like for example done
here:
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3328-rock64-u-boot.dtsi#L13
On the long run we want to add a sysinfo driver to read the information for the
mailbox driver and use that. But my understanding is that for that we would need
to create a SPL for the mailbox driver to provide that info in a shared data
structure. It's still on my list for investigation.
Regards,
Matthias
>>> You can always bisect it ;)
>>>
>>
>>
>> LOL -- true! I was just hoping someone would recognize the issue perhaps.
>>
>> Thanks,
>> Roman.
>
>
Re: Running u-boot 2021.04 on Raspberry Pi 4
On 09/04/2021 20:06, Roman Shaposhnik wrote:
> On Fri, Apr 9, 2021 at 3:15 AM Matthias Brugger wrote:
>
>>
>>
>> On 09/04/2021 10:14, Nicolas Saenz Julienne wrote:
>>> [ Adding Matthias for the SMBIOS part ]
>>>
>>> On Fri, 2021-04-09 at 00:00 -0700, Roman Shaposhnik wrote:
>>>> On Thu, Apr 8, 2021 at 8:59 PM Sean Anderson wrote:
>>>>> On 4/8/21 8:18 PM, Roman Shaposhnik wrote:
>>>>>> Hi!
>>>>>>
>>>>>> first time poster, long time lurker here. Over at Project EVE
>>>>>> https://github.com/lf-edge/eve I've been trying to migrate
>>>>>> from our current u-boot v2020.07 + patches:
>>>>>>
>>>>>>
>> https://github.com/lf-edge/eve/tree/master/pkg/u-boot/patches/patches-v2020.07
>>>>>> to the latest u-boot 2021.04.
>>>>>>
>>>>>> Great news is that most of the patches we dependent
>>>>>> on seem to have been pulled upstream. However, this
>>>>>> single *chunk* of one patchset wasn't:
>>>>>>
>>>>>>
>> https://github.com/lf-edge/eve/blob/master/pkg/u-boot/patches/patches-v2020.07/0001-usb-xhci-Load-Raspberry-Pi-4-VL805-s-firmware.patch#L293
>>>>>>
>>>>>> I'm wondering what was the reason for leaving it behind,
>>>>>
>>>>> +CC Nicolas
>>>>>
>>>>>> - Get rid of PCI core patch as not needed with correct DT PCI
>> topology
>>>>>
>>>>> also from the cover letter
>>>>>
>>>>>> This also depends on a DT/bindings patch available on the
>> linux-mailing lists:
>>>>>> https://www.mail-archive.com/linux-kernel@.../msg2205783.html
>>>>>
>>>>> The merged version of this series is
>>>>>
>>>>>
>> https://patchwork.kernel.org/project/linux-usb/list/?series=310015&state=%2A&archive=both
>>>>>
>>>>>> Here is the relevant bit for reference/discussion:
>>>>>>
>>>>>> &pcie0 {
>>>>>> pci@1,0 {
>>>>>> #address-cells = <3>;
>>>>>> #size-cells = <2>;
>>>>>> ranges;
>>>>>>
>>>>>> reg = <0 0 0 0 0>;
>>>>>>
>>>>>> usb@1,0 {
>>>>>> reg = <0x1 0 0 0 0>;
>>>>>> resets = <&reset
>> RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
>>>>>> };
>>>>>> };
>>>>>> };
>>>>>
>>>
>>> Yes, instead of using a PCI quirk we settled on a reset controller. All
>> in all
>>> it is less hacky. But needs changes in DT.
>>>
>>>> Aha! Thank you so much -- this is super helpful!
>>>>
>>>>>> since without it I don't seem to have functioning USB
>>>>>> devices on my Raspberry Pi 4. In fact, adding it back:
>>>>>>
>>>>>>
>> https://github.com/rvs/eve/tree/u-boot/pkg/u-boot/patches/patches-v2021.04
>>>>>> (just that one chunk -- 'cuz the reset got upstreamed)
>>>>>> seems to solve the issue for me.
>>>>>>
>>>>>> Another question I have is that the new u-boot seems to have
>>>>>> some kind of a regression that I can't quite debug. The SMBIOS
>>>>>> tables that it constructs during EFI boot sequence seem to be
>>>>>> broken (see the dmidecode output below). Again, this seems
>>>>>> to be a regression compared to v2020.07. Any ideas on what
>>>>>> could be wrong or how can I start debugging it would be
>>>>>
>>
>> Yes, that's not working right now. I'm working on a fix for the tables:
>>
>> https://patchwork.ozlabs.org/project/uboot/patch/20210406090435.19357-1-matthias@kernel.org/
>>
>> This will fix the error en dmidecode but the tables will be basically
>> empty.
>> Before that there was some information that helped you to identify that
>> you are
>> running on a RaspberryPi.
>>
>> A quick fix would be to add that information to the DTS.
Re: [PATCH 1/2] arm: dts: bcm283x: Add minimal smbios information
On Fri, Apr 09, 2021 at 03:13:25PM +0200, Fabian Vogt wrote:
> Am Freitag, 9. April 2021, 14:35:10 CEST schrieb matthias@kernel.org:
> > From: Matthias Brugger
> >
> > At present SMBIOS tables are emtpy,
> ^ typo
>
> > which breaks some use-cases that rely on that.
> Can you give an example?
Management software that want's to know what HW a node is based on.
>
> > Add some minimal information to
> Isn't it possible to get the complete information from the firmware here?
> That would allow to have the correct product and serial at least.
That's the plan for the long run.
> If that's not possible or too complex, then I suggest to use the proper
> strings, e.g. "Raspberry Pi", as those are user visible.
I'd like to stay backwards compatible to older U-Boot versions for now.
>
> > fullfill this.
> ^ typo
>
> > Signed-off-by: Matthias Brugger
> > ---
> >
> > arch/arm/dts/bcm283x-u-boot.dtsi | 20
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/arm/dts/bcm283x-u-boot.dtsi
> > b/arch/arm/dts/bcm283x-u-boot.dtsi
> > index 68d03627f4..f5235cb083 100644
> > --- a/arch/arm/dts/bcm283x-u-boot.dtsi
> > +++ b/arch/arm/dts/bcm283x-u-boot.dtsi
> > @@ -6,6 +6,26 @@
> > * (C) Copyright 2016 Fabian Vogt
> > */
> >
> > +/ {
> > + smbios {
> > + compatible = "u-boot,sysinfo-smbios";
> > + smbios {
> > + system {
> > + manufacturer = "raspberrypi";
> > + product = "rpi";
> > + };
> > + baseboard {
> > + manufacturer = "raspberrypi";
> > + product = "rpi";
> > + };
> > + chassis {
> > + manufacturer = "raspberrypi";
> > + product = "rpi";
>
> According to doc/device-tree-bindings/sysinfo/smbios.txt, "chassis"
> doesn't have a "product".
>
You are correct. I'll fix the typos and this in the next version.
Regards,
Matthias
> Cheers,
> Fabian
>
> > + };
> > + };
> > + };
> > +};
> > +
> > &uart0 {
> > skip-init;
> > u-boot,dm-pre-reloc;
> >
>
Re: [PATCH] Add support for Raspberry Pi 3B+(32bit)
On 20/04/2021 08:05, Toshifumi NISHINAGA wrote: > Hello all. > > I will add rpi_3_32b_plus_defconfig to easy to build u-boot for > Raspberry Pi 3B+(32bit). > Could you merge this patch? > This file is already present [1]. Please provide patches against the latest U-Boot tree. Is there anything missing in the config? Regards, Matthias [1] https://source.denx.de/u-boot/u-boot/-/blob/master/configs/rpi_3_b_plus_defconfig > Thanks, > Toshifumi NISHINAGA > > > From 28d13f48761ab7c137a5fdf07c76a857967e3590 Mon Sep 17 00:00:00 2001 > From: Toshifumi NISHINAGA > Date: Thu, 15 Apr 2021 16:53:33 +0900 > Subject: [PATCH] Add support for Raspberry Pi 3B+(32bit) > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > It also boots on Raspberry Pi 3B+ using rpi_3_32b_defconfig, > but the network card doesn't work. > > This defconfig is based on rpi_3_32b_defconfig. > > Signed-off-by: Toshifumi NISHINAGA > --- > > configs/rpi_3_32b_plus_defconfig | 46 > 1 file changed, 46 insertions(+) > create mode 100644 configs/rpi_3_32b_plus_defconfig > > diff --git a/configs/rpi_3_32b_plus_defconfig > b/configs/rpi_3_32b_plus_defconfig > new file mode 100644 > index 00..d147a46ae7 > --- /dev/null > +++ b/configs/rpi_3_32b_plus_defconfig > @@ -0,0 +1,46 @@ > +CONFIG_ARM=y > +CONFIG_ARCH_CPU_INIT=y > +CONFIG_ARCH_BCM283X=y > +CONFIG_SYS_TEXT_BASE=0x8000 > +CONFIG_TARGET_RPI_3_32B=y > +CONFIG_SYS_MALLOC_F_LEN=0x2000 > +CONFIG_NR_DRAM_BANKS=1 > +CONFIG_ENV_SIZE=0x4000 > +CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b-plus" > +CONFIG_DISTRO_DEFAULTS=y > +CONFIG_OF_BOARD_SETUP=y > +CONFIG_USE_PREBOOT=y > +# CONFIG_DISPLAY_CPUINFO is not set > +# CONFIG_DISPLAY_BOARDINFO is not set > +CONFIG_MISC_INIT_R=y > +CONFIG_SYS_PROMPT="U-Boot> " > +CONFIG_CMD_GPIO=y > +CONFIG_CMD_MMC=y > +CONFIG_CMD_USB=y > +CONFIG_CMD_FS_UUID=y > +CONFIG_OF_EMBED=y > +CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" > +CONFIG_SYS_RELOC_GD_ENV_ADDR=y > +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=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_VIDEO_BPP8 is not set > +# CONFIG_VIDEO_BPP16 is not set > +CONFIG_SYS_WHITE_ON_BLACK=y > +CONFIG_CONSOLE_SCROLL_LINES=10 > +CONFIG_PHYS_TO_BUS=y > +CONFIG_OF_LIBFDT_OVERLAY=y >
Re: [PATCH v3 4/7] bcm2835: brcm,bcm2708-fb device is using r5g6b5 format
On 19/12/2023 09:51, Ivan T. Ivanov wrote:
On 12-18 23:32, Stefan Wahren wrote:
static const struct udevice_id bcm2835_video_ids[] = {
- { .compatible = "brcm,bcm2835-hdmi" },
- { .compatible = "brcm,bcm2711-hdmi0" },
- { .compatible = "brcm,bcm2708-fb" },
+ { .compatible = "brcm,bcm2835-hdmi", .data = VIDEO_BPP32},
+ { .compatible = "brcm,bcm2711-hdmi0", .data = VIDEO_BPP32},
+ { .compatible = "brcm,bcm2708-fb",.data = VIDEO_BPP16 },
this change looks wrong to me. Before we used VIDEO_BPP32 for
brcm,bcm2708-fb. I think it's hard to explain why we should downgrade
the other boards. I would expect some brcm,bcm2712 compatible at least
this needs an explanation in the commit message.
If you are confident that this semi device was working before with
BPP32 I will try to find better way to handle this. Do you remember
which RPi version was this?
I think that was RPi1 maybe RPi2 Zero W as well.
Regards,
Matthias
Re: [PATCH v3 0/7] rpi5: initial support
On 21/12/2023 14:42, Stefan Agner wrote: Hi Ivan, On 2023-12-18 22:03, Ivan T. Ivanov wrote: Hi, These patches are adding basic support for RPi5. They are based on v2 series from Dmitry Malkin[1]. With them I am able to _start_ current openSUSE Tumbleweed without modification. They are still a lot of things to be added to the upstream Linux before it runs flawlessly on this device, but at least in U-Booot SD controller used for uSD card and Frameboffer and HDMI0 devices are working fine now. It seems that PCIe controller is working fine too, but I have not tested it too much. Thank you very much for this work! Serial console and reset are also functional. I've applied the patchset to v2024.01-rc5 and built the rpi_arm64_defconfig target. I added enable_uart=1 and kernel=u-boot.bin to config.txt. While I see a brief U-Boot logo on HDMI, I haven't gotten anything on the serial console on pin 8/10 of the Raspberry Pi pin header. Is there anything specific needed to get the console going? Welcome to the club! :) The RPi5 uses a rather non-standard port for debug console: https://www.raspberrypi.com/documentation/computers/raspberry-pi-5.html#uart-connector Up to now I wasn't able to get serial console on the normal pins 8/10. Regards Matthias -- Stefan Hopefully this will help others add missing pieces more easily. Happy hacking! Regards, Ivan [1] https://lore.kernel.org/all/CAKRNjQ0dsWozGo4n8g58m4cCEk3n=qx1r+l24wbgpo-ip1y...@mail.gmail.com/ Dmitry Malkin (2): rpi5: add initial memory map for bcm2712 rpi5: Use devicetree as alternative way to read IO base addresses Ivan T. Ivanov (5): rpi5: Use devicetree to retrieve board revision bcm2835: brcm,bcm2708-fb device is using r5g6b5 format mmc: bcmstb: Add support for bcm2712 SD controller configs: rpi_arm64: enable SDHCI BCMSTB driver pci: pcie-brcmstb: Add bcm2712 PCIe controller support arch/arm/mach-bcm283x/include/mach/base.h | 5 +- arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +- arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +- arch/arm/mach-bcm283x/include/mach/timer.h | 3 +- arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +- arch/arm/mach-bcm283x/init.c | 81 -- board/raspberrypi/rpi/rpi.c| 22 ++- configs/rpi_arm64_defconfig| 1 + drivers/mmc/bcmstb_sdhci.c | 173 - drivers/pci/pcie_brcmstb.c | 23 ++- drivers/video/bcm2835.c| 10 +- 11 files changed, 296 insertions(+), 31 deletions(-)
Re: [PATCH v3 2/7] rpi5: Use devicetree as alternative way to read IO base addresses
On 18/12/2023 22:03, Ivan T. Ivanov wrote:
From: Dmitry Malkin
MBOX and Watchdog on RPi5/bcm2712 has a different base IO offsets.
Find them via devicetree blob passed by bootloader.
Signed-off-by: Dmitry Malkin
Signed-off-by: Ivan T. Ivanov
Reviewed-by: Matthias Brugger
---
arch/arm/mach-bcm283x/include/mach/base.h | 5 ++-
arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +-
arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +-
arch/arm/mach-bcm283x/include/mach/timer.h | 3 +-
arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +-
arch/arm/mach-bcm283x/init.c | 43 ++
6 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-bcm283x/include/mach/base.h
b/arch/arm/mach-bcm283x/include/mach/base.h
index 4ccaf69693..6de99e7ea1 100644
--- a/arch/arm/mach-bcm283x/include/mach/base.h
+++ b/arch/arm/mach-bcm283x/include/mach/base.h
@@ -6,7 +6,10 @@
#ifndef _BCM283x_BASE_H_
#define _BCM283x_BASE_H_
-extern unsigned long rpi_bcm283x_base;
+extern unsigned long rpi_mbox_base;
+extern unsigned long rpi_timer_base;
+extern unsigned long rpi_sdhci_base;
+extern unsigned long rpi_wdog_base;
#ifdef CONFIG_ARMV7_LPAE
#ifdef CONFIG_TARGET_RPI_4_32B
diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h
b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 490664f878..35d4e2f075 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -38,8 +38,7 @@
/* Raw mailbox HW */
-#define BCM2835_MBOX_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
-rpi_bcm283x_base + 0xb880; })
+#define BCM2835_MBOX_PHYSADDR rpi_mbox_base
struct bcm2835_mbox_regs {
u32 read;
diff --git a/arch/arm/mach-bcm283x/include/mach/sdhci.h
b/arch/arm/mach-bcm283x/include/mach/sdhci.h
index 7323690687..e837c679c4 100644
--- a/arch/arm/mach-bcm283x/include/mach/sdhci.h
+++ b/arch/arm/mach-bcm283x/include/mach/sdhci.h
@@ -8,8 +8,7 @@
#include
-#define BCM2835_SDHCI_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
- rpi_bcm283x_base + 0x0030; })
+#define BCM2835_SDHCI_PHYSADDR rpi_sdhci_base
int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq);
diff --git a/arch/arm/mach-bcm283x/include/mach/timer.h b/arch/arm/mach-bcm283x/include/mach/timer.h
index 5567dbd7f3..60500a256d 100644
--- a/arch/arm/mach-bcm283x/include/mach/timer.h
+++ b/arch/arm/mach-bcm283x/include/mach/timer.h
@@ -11,8 +11,7 @@
#include
#endif
-#define BCM2835_TIMER_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
- rpi_bcm283x_base + 0x3000; })
+#define BCM2835_TIMER_PHYSADDR rpi_timer_base
#define BCM2835_TIMER_CS_M3 (1 << 3)
#define BCM2835_TIMER_CS_M2 (1 << 2)
diff --git a/arch/arm/mach-bcm283x/include/mach/wdog.h
b/arch/arm/mach-bcm283x/include/mach/wdog.h
index 9942666720..b950560674 100644
--- a/arch/arm/mach-bcm283x/include/mach/wdog.h
+++ b/arch/arm/mach-bcm283x/include/mach/wdog.h
@@ -8,8 +8,7 @@
#include
-#define BCM2835_WDOG_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
-rpi_bcm283x_base + 0x0010; })
+#define BCM2835_WDOG_PHYSADDR rpi_wdog_base
struct bcm2835_wdog_regs {
u32 unknown0[7];
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index af23b9711a..1c5c748484 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -151,7 +151,11 @@ static void rpi_update_mem_map(void)
static void rpi_update_mem_map(void) {}
#endif
-unsigned long rpi_bcm283x_base = 0x3f00;
+/* Default bcm283x devices addresses */
+unsigned long rpi_mbox_base = 0x3f00b880;
+unsigned long rpi_sdhci_base = 0x3f30;
+unsigned long rpi_wdog_base = 0x3f10;
+unsigned long rpi_timer_base = 0x3f003000;
int arch_cpu_init(void)
{
@@ -162,22 +166,45 @@ int arch_cpu_init(void)
int mach_cpu_init(void)
{
- int ret, soc_offset;
+ int ret, soc, offset;
u64 io_base, size;
rpi_update_mem_map();
/* Get IO base from device tree */
- soc_offset = fdt_path_offset(gd->fdt_blob, "/soc");
- if (soc_offset < 0)
- return soc_offset;
+ soc = fdt_path_offset(gd->fdt_blob, "/soc");
+ if (soc < 0)
+ return soc;
- ret = fdt_read_range((void *)gd->fdt_blob, soc_offset, 0, NULL,
- &io_base, &size);
+ ret = fdt_read_range((void *)gd->fdt_blob, soc, 0, NULL,
+&io_base, &size);
if (ret)
return ret;
- rpi_bcm283x_base = io_base;
+ rpi_mbox_base = io_base + 0x00b880;
+ rpi_sdhci_base = io_base + 0x30;
+ rpi_wdog_base = io_base + 0x10;
+ rpi_timer_base = io_base + 0x003000;
+
+ offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc,
+
Re: [PATCH v3 3/7] rpi5: Use devicetree to retrieve board revision
On 18/12/2023 22:03, Ivan T. Ivanov wrote:
Firmware on RPi5 return error on board revision query
through firmware interface, but on the other hand it fills
"linux,revision" in "system" node, so use it to detect board
revision.
system {
linux,revision = <0xc04170>;
linux,serial = <0x6cf44e80 0x3c533ede>;
};
Signed-off-by: Ivan T. Ivanov
Reviewed-by: Matthias Brugger
---
board/raspberrypi/rpi/rpi.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index cd823ad746..2851ebc985 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -171,6 +171,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
DTB_DIR "bcm2711-rpi-cm4.dtb",
true,
},
+ [0x17] = {
+ "5 Model B",
+ DTB_DIR "bcm2712-rpi-5-b.dtb",
+ true,
+ },
};
static const struct rpi_model rpi_models_old_scheme[] = {
@@ -429,15 +434,27 @@ static void get_board_revision(void)
int ret;
const struct rpi_model *models;
uint32_t models_count;
+ ofnode node;
BCM2835_MBOX_INIT_HDR(msg);
BCM2835_MBOX_INIT_TAG(&msg->get_board_rev, GET_BOARD_REV);
ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, &msg->hdr);
if (ret) {
- printf("bcm2835: Could not query board revision\n");
/* Ignore error; not critical */
- return;
+ node = ofnode_path("/system");
+ if (!ofnode_valid(node)) {
+ printf("bcm2835: Could not find /system node\n");
+ return;
+ }
+
+ ret = ofnode_read_u32(node, "linux,revision", &revision);
+ if (ret) {
+ printf("bcm2835: Could not find linux,revision\n");
+ return;
+ }
+ } else {
+ revision = msg->get_board_rev.body.resp.rev;
}
/*
@@ -451,7 +468,6 @@ static void get_board_revision(void)
*
http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=98367&start=250
* http://www.raspberrypi.org/forums/viewtopic.php?f=31&t=20594
*/
- revision = msg->get_board_rev.body.resp.rev;
if (revision & 0x80) {
rev_scheme = 1;
rev_type = (revision >> 4) & 0xff;
Re: [PATCH v3 7/7] pci: pcie-brcmstb: Add bcm2712 PCIe controller support
On 18/12/2023 22:03, Ivan T. Ivanov wrote:
PCIe controller have minor register map difference compared
to bcm2711 variant. Handle this using device specific register
offset.
Signed-off-by: Ivan T. Ivanov
Reviewed-by: Matthias Brugger
---
drivers/pci/pcie_brcmstb.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pcie_brcmstb.c b/drivers/pci/pcie_brcmstb.c
index cd45f0bee9..d63e715b2e 100644
--- a/drivers/pci/pcie_brcmstb.c
+++ b/drivers/pci/pcie_brcmstb.c
@@ -90,7 +90,6 @@
#define PCIE_MEM_WIN0_LIMIT_HI(win) \
PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI + ((win) * 8)
-#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
#define PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x0800
#define PCIE_MSI_INTR2_CLR0x4508
@@ -131,6 +130,10 @@
#define SSC_STATUS_PLL_LOCK_MASK 0x800
#define SSC_STATUS_PLL_LOCK_SHIFT 11
+struct pcie_cfg_data {
+ unsigned long hard_debug_offs;
+};
+
/**
* struct brcm_pcie - the PCIe controller state
* @base: Base address of memory mapped IO registers of the controller
@@ -141,6 +144,7 @@
struct brcm_pcie {
void __iomem*base;
+ struct pcie_cfg_data *cfg;
int gen;
boolssc;
};
@@ -458,7 +462,7 @@ static int brcm_pcie_probe(struct udevice *dev)
/* Take the bridge out of reset */
clrbits_le32(base + PCIE_RGR1_SW_INIT_1, RGR1_SW_INIT_1_INIT_MASK);
- clrbits_le32(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG,
+ clrbits_le32(base + pcie->cfg->hard_debug_offs,
PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
/* Wait for SerDes to be stable */
@@ -599,7 +603,7 @@ static int brcm_pcie_remove(struct udevice *dev)
setbits_le32(base + PCIE_RGR1_SW_INIT_1, RGR1_SW_INIT_1_PERST_MASK);
/* Turn off SerDes */
- setbits_le32(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG,
+ setbits_le32(base + pcie->cfg->hard_debug_offs,
PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
/* Shutdown bridge */
@@ -620,6 +624,8 @@ static int brcm_pcie_of_to_plat(struct udevice *dev)
if (!pcie->base)
return -EINVAL;
+ pcie->cfg = (struct pcie_cfg_data *)dev_get_driver_data(dev);
+
pcie->ssc = ofnode_read_bool(dn, "brcm,enable-ssc");
ret = ofnode_read_u32(dn, "max-link-speed", &max_link_speed);
@@ -636,8 +642,17 @@ static const struct dm_pci_ops brcm_pcie_ops = {
.write_config = brcm_pcie_write_config,
};
+static const struct pcie_cfg_data bcm2711_cfg = {
+ .hard_debug_offs= 0x4204
+};
+
+static const struct pcie_cfg_data bcm2712_cfg = {
+ .hard_debug_offs= 0x4304
+};
+
static const struct udevice_id brcm_pcie_ids[] = {
- { .compatible = "brcm,bcm2711-pcie" },
+ { .compatible = "brcm,bcm2711-pcie", .data = (ulong)&bcm2711_cfg },
+ { .compatible = "brcm,bcm2712-pcie", .data = (ulong)&bcm2712_cfg },
{ }
};
Re: [PATCH v4 4/6] bcm2835: Dynamically calculate bytes per pixel parameter
On 10/01/2024 13:29, Ivan T. Ivanov wrote:
brcm,bcm2708-fb device provided by firmware on RPi5 uses
16 bits per pixel, so lets calculate framebuffer bytes
per pixel dynamically based on queried information.
Tested to work for RPi2b v1.2, RPi3b v1.3, RPi4b v1.1,
RPi2 Zero W, RPi5b v1.0.
Signed-off-by: Ivan T. Ivanov
Reviewed-by: Matthias Brugger
---
drivers/video/bcm2835.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index 14942526f1..63efa762db 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -16,7 +16,7 @@ static int bcm2835_video_probe(struct udevice *dev)
struct video_uc_plat *plat = dev_get_uclass_plat(dev);
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
int ret;
- int w, h, pitch;
+ int w, h, pitch, bpp;
ulong fb_base, fb_size, fb_start, fb_end;
debug("bcm2835: Query resolution...\n");
@@ -41,9 +41,23 @@ static int bcm2835_video_probe(struct udevice *dev)
DCACHE_WRITEBACK);
video_set_flush_dcache(dev, true);
+ bpp = pitch / w;
+ switch (bpp) {
+ case 2:
+ uc_priv->bpix = VIDEO_BPP16;
+ break;
+ case 4:
+ uc_priv->bpix = VIDEO_BPP32;
+ break;
+ default:
+ printf("bcm2835: unexpected bpp %d, pitch %d, width %d\n",
+ bpp, pitch, w);
+ uc_priv->bpix = VIDEO_BPP32;
+ break;
+ }
+
uc_priv->xsize = w;
uc_priv->ysize = h;
- uc_priv->bpix = VIDEO_BPP32;
plat->base = fb_base;
plat->size = fb_size;
Re: [PATCH v4 0/6] rpi5: initial support
On 10/01/2024 13:29, Ivan T. Ivanov wrote: Hi, These patches are slight update for patches posted earlier here[1]. They are adding basic support for RPi5 and are based on v2 series from Dmitry Malkin[2]. What changed: * Initial memory map now includes whole first 1GB of DRAM. At runtime, the firmware will adjust this size depending on whether an HDMI cable is plugged in or not. If there is HDMI monitor connected it will reserve framebufer memory region and will add simple-framebuffer device into devicetree. * Dynamically calculate bits per pixel in video driver. This works on all prevous RPi's models that I have. * I am dropping PCIe patch for now. I made some progress on porting changes from vendor Linux tree to U-Boot. Unfortunatly testing it is little bit tricky. They are many devices behind PCIe, but more or less all of them requires missing either "reset-controller" or "clock-controller" or "pin-controller" drivers. I was able to probe "cdns,macb" device, but access to ethernet PHY over MDIO bus is stucking. Then I ported "raspberrypi,rp1-adc" driver from vendor Linux tree, but it requires missing clock. And on top of that machine that I used for developing this crashed and I lost my PCIe changes :-|. Anyway. These patches allows me to boot current openSUSE Tumbleweed without modification. I can see serial console log and boot process on HDMI connected monitor. I think these patches should be enough for start. Please consider for inclusion. Thanks, Ivan [1] https://lore.kernel.org/all/20231218210341.30073-1-iiva...@suse.de/ [2] https://lore.kernel.org/all/CAKRNjQ0dsWozGo4n8g58m4cCEk3n=qx1r+l24wbgpo-ip1y...@mail.gmail.com/ Dmitry Malkin (2): rpi5: add initial memory map for bcm2712 rpi5: Use devicetree as alternative way to read IO base addresses Ivan T. Ivanov (4): rpi5: Use devicetree to retrieve board revision bcm2835: Dynamically calculate bytes per pixel parameter mmc: bcmstb: Add support for bcm2712 SD controller configs: rpi_arm64: enable SDHCI BCMSTB driver In the meantime I was able to test this series. So here my: Tested-by: Matthias Brugger arch/arm/mach-bcm283x/include/mach/base.h | 5 +- arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +- arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +- arch/arm/mach-bcm283x/include/mach/timer.h | 3 +- arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +- arch/arm/mach-bcm283x/init.c | 74 - board/raspberrypi/rpi/rpi.c| 22 ++- configs/rpi_arm64_defconfig| 1 + drivers/mmc/bcmstb_sdhci.c | 173 - drivers/video/bcm2835.c| 18 ++- 10 files changed, 282 insertions(+), 23 deletions(-)
[GIT PULL] rpi: updates for v2024.04
Hi Tom, Here come a small set of patches for v2024.04 for the RaspberryPi. It adds basic support for RPi5 to be able to boot on a SD card. You can find the passing tests here: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/19512 It's the same commit ID as the tag, although it's not the same test-run. Regards, Matthias --- The following changes since commit 6faba41927bdc8973b59678649ef83c564cc421e: Prepare v2024.04-rc1 (2024-01-29 20:53:19 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-next-2024.04 for you to fetch changes up to 12d479d01849c164020e17c3ae921f974b96372d: configs: rpi_arm64: build position independent code (2024-01-30 17:40:13 +0100) Add RaspberryPi5 basic support. Dmitry Malkin (2): rpi5: add initial memory map for bcm2712 rpi5: Use devicetree as alternative way to read IO base addresses Ivan T. Ivanov (5): rpi5: Use devicetree to retrieve board revision bcm2835: Dynamically calculate bytes per pixel parameter mmc: bcmstb: Add support for bcm2712 SD controller configs: rpi_arm64: enable SDHCI BCMSTB driver configs: rpi_arm64: build position independent code arch/arm/mach-bcm283x/include/mach/base.h | 5 +- arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +- arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +- arch/arm/mach-bcm283x/include/mach/timer.h | 3 +- arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +- arch/arm/mach-bcm283x/init.c | 74 ++ board/raspberrypi/rpi/rpi.c| 22 +++-- configs/rpi_arm64_defconfig| 3 +- drivers/mmc/bcmstb_sdhci.c | 64 -- drivers/video/bcm2835.c| 18 +++- 10 files changed, 171 insertions(+), 27 deletions(-)
Re: [PATCH v3 2/3] driver: rng: Fix SMCCC TRNG crash
On Wed, Jan 31, 2024 at 02:14:25PM +, Weizhao Ouyang wrote:
> Fix a SMCCC TRNG null pointer crash due to a failed smccc feature
> binding.
>
> Fixes: 53355bb86c25 ("drivers: rng: add smccc trng driver")
> Reviewed-by: Heinrich Schuchardt
> Signed-off-by: Weizhao Ouyang
Reviewed-by: Matthias Brugger
> ---
> v3: add Fixes tag
> ---
> drivers/rng/smccc_trng.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/rng/smccc_trng.c b/drivers/rng/smccc_trng.c
> index 3a4bb33941..3087cb991a 100644
> --- a/drivers/rng/smccc_trng.c
> +++ b/drivers/rng/smccc_trng.c
> @@ -166,7 +166,7 @@ static int smccc_trng_probe(struct udevice *dev)
> struct smccc_trng_priv *priv = dev_get_priv(dev);
> struct arm_smccc_res res;
>
> - if (!(smccc_trng_is_supported(smccc->invoke_fn)))
> + if (!smccc || !(smccc_trng_is_supported(smccc->invoke_fn)))
> return -ENODEV;
>
> /* At least one of 64bit and 32bit interfaces is available */
> --
> 2.39.2
Re: [PATCH v3 3/3] cmd: rng: Add rng list command
On Wed, Jan 31, 2024 at 02:14:26PM +, Weizhao Ouyang wrote:
> The 'rng list' command probes all RNG devices and list those devices
> that are successfully probed. Also update the help info.
>
> Reviewed-by: Heinrich Schuchardt
> Signed-off-by: Weizhao Ouyang
Reviewed-by: Matthias Brugger
> ---
> cmd/rng.c | 23 ++-
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/cmd/rng.c b/cmd/rng.c
> index 52f722c7af..b073a6c849 100644
> --- a/cmd/rng.c
> +++ b/cmd/rng.c
> @@ -19,6 +19,22 @@ static int do_rng(struct cmd_tbl *cmdtp, int flag, int
> argc, char *const argv[])
> struct udevice *dev;
> int ret = CMD_RET_SUCCESS;
>
> + if (argc == 2 && !strcmp(argv[1], "list")) {
> + int idx = 0;
> +
> + uclass_foreach_dev_probe(UCLASS_RNG, dev) {
> + idx++;
> + printf("RNG #%d - %s\n", dev->seq_, dev->name);
> + }
> +
> + if (!idx) {
> + log_err("No RNG device\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + return CMD_RET_SUCCESS;
> + }
> +
> switch (argc) {
> case 1:
> devnum = 0;
> @@ -56,12 +72,9 @@ static int do_rng(struct cmd_tbl *cmdtp, int flag, int
> argc, char *const argv[])
> return ret;
> }
>
> -U_BOOT_LONGHELP(rng,
> - "[dev [n]]\n"
> - " - print n random bytes(max 64) read from dev\n");
> -
> U_BOOT_CMD(
> rng, 3, 0, do_rng,
> "print bytes from the hardware random number generator",
> - rng_help_text
> + "list - list all the probed rng devices\n"
> + "rng [dev] [n]- print n random bytes(max 64) read from dev\n"
> );
> --
> 2.39.2
Re: [PATCH 4/7] smbios: string table always needs two terminating NUL bytes
On Mon, Jan 29, 2024 at 10:04:50PM +0100, Heinrich Schuchardt wrote:
> The string section of the different SMBIOS structures is always terminated
> by two NUL bytes even if there is no string at all. This is described in
> section 6.1.3 "Text string" of the SMBIOS 3.7.0 specification.
>
> Signed-off-by: Heinrich Schuchardt
I send the very same patch some years ago [1], unfortunately it got
somehow lost. Happy to see you trying to fix the same problem, so:
Reviewed-by: Matthias Brugger
[1]
https://patchwork.ozlabs.org/project/uboot/patch/20210406090435.19357-1-matthias@kernel.org/
> ---
> lib/smbios.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/lib/smbios.c b/lib/smbios.c
> index 7bd9805fec0..81908e89610 100644
> --- a/lib/smbios.c
> +++ b/lib/smbios.c
> @@ -311,6 +311,9 @@ int smbios_update_version(const char *version)
> */
> static int smbios_string_table_len(const struct smbios_ctx *ctx)
> {
> + /* If the structure contains no string it is followed by to NUL bytes */
> + if (ctx->next_ptr == ctx->eos)
> + return 2;
> /* Allow for the final \0 after all strings */
> return (ctx->next_ptr + 1) - ctx->eos;
> }
> --
> 2.43.0
Re: [PATCH] Revert "arm: dts: bcm283x: Add minimal smbios information"
On 14/05/2024 15:07, Peter Robinson wrote:
This reverts commit 33041972727e84d3f95e26c83322521f61827584.
With the ability to generate this SMBIOS details autmotically the
small amount of details that this patch provided are generated
automatically so this is now obsolete so we can just drop it.
Signed-off-by: Peter Robinson
Acked-by: Matthias Brugger
---
arch/arm/dts/bcm283x-u-boot.dtsi | 19 ---
1 file changed, 19 deletions(-)
diff --git a/arch/arm/dts/bcm283x-u-boot.dtsi b/arch/arm/dts/bcm283x-u-boot.dtsi
index 8c17c6f6a52..ec0f93dd850 100644
--- a/arch/arm/dts/bcm283x-u-boot.dtsi
+++ b/arch/arm/dts/bcm283x-u-boot.dtsi
@@ -6,25 +6,6 @@
* (C) Copyright 2016 Fabian Vogt
*/
-/ {
- smbios {
- compatible = "u-boot,sysinfo-smbios";
- smbios {
- system {
- manufacturer = "raspberrypi";
- product = "rpi";
- };
- baseboard {
- manufacturer = "raspberrypi";
- product = "rpi";
- };
- chassis {
- manufacturer = "raspberrypi";
- };
- };
- };
-};
-
&uart0 {
skip-init;
bootph-all;
Re: [PATCH v2 1/2] lib: uuid: use RNG device if present
Hi Simon,
On 19/12/2020 03:29, Simon Glass wrote:
> Hi Mattias,
>
> On Wed, 16 Dec 2020 at 09:28, wrote:
>>
>> From: Matthias Brugger
>>
>> When calculating a random UUID we use a weak seed.
>> Use a RNG device if present to increase entropy.
>>
>> Signed-off-by: Matthias Brugger
>>
>> ---
>>
>> Changes in v2:
>> - fix dm_rng_read() parameters
>> - add missing include
>>
>> lib/uuid.c | 21 ++---
>> 1 file changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/lib/uuid.c b/lib/uuid.c
>> index e62d5ca264..e3487380c3 100644
>> --- a/lib/uuid.c
>> +++ b/lib/uuid.c
>> @@ -15,6 +15,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> /*
>> * UUID - Universally Unique IDentifier - 128 bits unique number.
>> @@ -249,9 +251,22 @@ void gen_rand_uuid(unsigned char *uuid_bin)
>> {
>> u32 ptr[4];
>> struct uuid *uuid = (struct uuid *)ptr;
>> - int i;
>> -
>> - srand(get_ticks() + rand());
>> + int i, ret;
>> + struct udevice *devp;
>> + u8 randv = 0;
>> +
>> +#if defined(CONFIG_DM_RNG)
>
> This seems a little backwards to me. The caller should request a RNG
> device, getting either a hardware one or a software one, and then call
> the uclass method to get the uuid.
>
The problem I see here is, that in case no DM_RNG is present the seed used is
different for uuid (get_ticks() + rand()) and bootp (seed_mac() uses the mac
address)
So we would need to pass this alternatives to the generic DM code, which makes
it a bit ugly. Apart from that beware that the seed used for srand() can vary
depending on the caller and the entropy it needs.
Regards,
Matthias
>> + ret = uclass_get_device(UCLASS_RNG, 0, &devp);
>> + if (ret) {
>> + ret = dm_rng_read(devp, &randv, sizeof(randv));
>> + if (ret < 0)
>> + randv = 0;
>> + }
>> + if (randv)
>> + srand(randv);
>> + else
>> +#endif
>> + srand(get_ticks() + rand());
>>
>> /* Set all fields randomly */
>> for (i = 0; i < 4; i++)
>> --
>> 2.29.2
>>
>
> Regards,
> Simon
>
Re: [PATCH] board: mediatek: disable watchdog on BananaPi R2
On 08/01/2021 08:39, Stefan Roese wrote:
> On 07.01.21 16:36, matthias@kernel.org wrote:
>> From: Matthias Brugger
>>
>> Watchdog timeout comes in before we are able to load the
>> kernel and reset the watchdog. Disable the watchdog late in the boot
>> process to be able to boot the board.
>
> Can't you change the WDT reset timeout instead to a higher value?
>
I tried that, but the HW has a max timeout of 15984 ms. Unfortunately that's not
enough.
Regards,
Matthias
> Thanks,
> Stefan
>
>> Signed-off-by: Matthias Brugger
>>
>> ---
>>
>> board/mediatek/mt7623/mt7623_rfb.c | 8
>> configs/mt7623n_bpir2_defconfig | 1 +
>> 2 files changed, 9 insertions(+)
>>
>> diff --git a/board/mediatek/mt7623/mt7623_rfb.c
>> b/board/mediatek/mt7623/mt7623_rfb.c
>> index 984e75ccaf..22120be412 100644
>> --- a/board/mediatek/mt7623/mt7623_rfb.c
>> +++ b/board/mediatek/mt7623/mt7623_rfb.c
>> @@ -5,6 +5,7 @@
>> #include
>> #include
>> +#include
>> DECLARE_GLOBAL_DATA_PTR;
>> @@ -40,3 +41,10 @@ int mmc_get_env_dev(void)
>> return mmc_get_boot_dev();
>> }
>> #endif
>> +
>> +#ifdef CONFIG_BOARD_LATE_INIT
>> +int board_late_init(void)
>> +{
>> + wdt_stop(gd->watchdog_dev);
>> +}
>> +#endif
>> diff --git a/configs/mt7623n_bpir2_defconfig
>> b/configs/mt7623n_bpir2_defconfig
>> index 9177c17dff..fe0b6259dd 100644
>> --- a/configs/mt7623n_bpir2_defconfig
>> +++ b/configs/mt7623n_bpir2_defconfig
>> @@ -14,6 +14,7 @@ CONFIG_FIT_VERBOSE=y
>> CONFIG_BOOTDELAY=3
>> CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>> CONFIG_DEFAULT_FDT_FILE="mt7623n-bananapi-bpi-r2.dtb"
>> +CONFIG_BOARD_LATE_INIT=y
>> # CONFIG_DISPLAY_BOARDINFO is not set
>> CONFIG_SYS_PROMPT="U-Boot> "
>> CONFIG_CMD_BOOTMENU=y
>>
>
>
> Viele Grüße,
> Stefan
>
Re: [PATCH] board: mediatek: disable watchdog on BananaPi R2
On 09/01/2021 15:57, Stefan Roese wrote:
> On 09.01.21 03:32, Matthias Brugger wrote:
>> On 08/01/2021 08:39, Stefan Roese wrote:
>>> On 07.01.21 16:36, matthias@kernel.org wrote:
>>>> From: Matthias Brugger
>>>>
>>>> Watchdog timeout comes in before we are able to load the
>>>> kernel and reset the watchdog. Disable the watchdog late in the boot
>>>> process to be able to boot the board.
>>>
>>> Can't you change the WDT reset timeout instead to a higher value?
>>>
>>
>> I tried that, but the HW has a max timeout of 15984 ms. Unfortunately that's
>> not
>> enough.
>
> Nearly 16 seconds is not enough to boot into Linux so that the Linux
> watchdog daemon can take control?
>
Exactly. I'm using a standard distro image. I think the main problem is, that it
needs 14 seconds for the EFI stub to actually boot the kernel. I've already the
watchdog timer as build-in (which is not the best to do, taking into account
that we don't want to bloat our distro kernel with random board specific drivers
build-in. If we I had the watchdog driver as kernel module it would take forever
to get that loaded.
You can find a serial log with timestamp from the moment U-Boot got loaded until
the kernel actually boots here:
https://paste.opensuse.org/98390849
Regards,
Matthias
> Thanks,
> Stefan
>
>> Regards,
>> Matthias
>>
>>> Thanks,
>>> Stefan
>>>
>>>> Signed-off-by: Matthias Brugger
>>>>
>>>> ---
>>>>
>>>> board/mediatek/mt7623/mt7623_rfb.c | 8
>>>> configs/mt7623n_bpir2_defconfig | 1 +
>>>> 2 files changed, 9 insertions(+)
>>>>
>>>> diff --git a/board/mediatek/mt7623/mt7623_rfb.c
>>>> b/board/mediatek/mt7623/mt7623_rfb.c
>>>> index 984e75ccaf..22120be412 100644
>>>> --- a/board/mediatek/mt7623/mt7623_rfb.c
>>>> +++ b/board/mediatek/mt7623/mt7623_rfb.c
>>>> @@ -5,6 +5,7 @@
>>>> #include
>>>> #include
>>>> +#include
>>>> DECLARE_GLOBAL_DATA_PTR;
>>>> @@ -40,3 +41,10 @@ int mmc_get_env_dev(void)
>>>> return mmc_get_boot_dev();
>>>> }
>>>> #endif
>>>> +
>>>> +#ifdef CONFIG_BOARD_LATE_INIT
>>>> +int board_late_init(void)
>>>> +{
>>>> + wdt_stop(gd->watchdog_dev);
>>>> +}
>>>> +#endif
>>>> diff --git a/configs/mt7623n_bpir2_defconfig
>>>> b/configs/mt7623n_bpir2_defconfig
>>>> index 9177c17dff..fe0b6259dd 100644
>>>> --- a/configs/mt7623n_bpir2_defconfig
>>>> +++ b/configs/mt7623n_bpir2_defconfig
>>>> @@ -14,6 +14,7 @@ CONFIG_FIT_VERBOSE=y
>>>> CONFIG_BOOTDELAY=3
>>>> CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>>>> CONFIG_DEFAULT_FDT_FILE="mt7623n-bananapi-bpi-r2.dtb"
>>>> +CONFIG_BOARD_LATE_INIT=y
>>>> # CONFIG_DISPLAY_BOARDINFO is not set
>>>> CONFIG_SYS_PROMPT="U-Boot> "
>>>> CONFIG_CMD_BOOTMENU=y
>>>>
>>>
>>>
>>> Viele Grüße,
>>> Stefan
>>>
>>
>
>
> Viele Grüße,
> Stefan
>
Re: [PATCH] board: mediatek: disable watchdog on BananaPi R2
On 10/01/2021 19:44, Matthias Brugger wrote:
>
>
> On 09/01/2021 15:57, Stefan Roese wrote:
>> On 09.01.21 03:32, Matthias Brugger wrote:
>>> On 08/01/2021 08:39, Stefan Roese wrote:
>>>> On 07.01.21 16:36, matthias@kernel.org wrote:
>>>>> From: Matthias Brugger
>>>>>
>>>>> Watchdog timeout comes in before we are able to load the
>>>>> kernel and reset the watchdog. Disable the watchdog late in the boot
>>>>> process to be able to boot the board.
>>>>
>>>> Can't you change the WDT reset timeout instead to a higher value?
>>>>
>>>
>>> I tried that, but the HW has a max timeout of 15984 ms. Unfortunately
>>> that's not
>>> enough.
>>
>> Nearly 16 seconds is not enough to boot into Linux so that the Linux
>> watchdog daemon can take control?
>>
>
> Exactly. I'm using a standard distro image. I think the main problem is, that
> it
> needs 14 seconds for the EFI stub to actually boot the kernel. I've already
> the
> watchdog timer as build-in (which is not the best to do, taking into account
> that we don't want to bloat our distro kernel with random board specific
> drivers
> build-in. If we I had the watchdog driver as kernel module it would take
> forever
> to get that loaded.
I just checked and "forever" was a bit of a overstatement. Kernel modules get
loaded after around 2 seconds into kernel booting. But adding this to the 14
seconds the EFI stub needs we already got reset by the watchdog.
Regards,
Matthias
>
> You can find a serial log with timestamp from the moment U-Boot got loaded
> until
> the kernel actually boots here:
> https://paste.opensuse.org/98390849
>
> Regards,
> Matthias
>
>> Thanks,
>> Stefan
>>
>>> Regards,
>>> Matthias
>>>
>>>> Thanks,
>>>> Stefan
>>>>
>>>>> Signed-off-by: Matthias Brugger
>>>>>
>>>>> ---
>>>>>
>>>>> board/mediatek/mt7623/mt7623_rfb.c | 8
>>>>> configs/mt7623n_bpir2_defconfig | 1 +
>>>>> 2 files changed, 9 insertions(+)
>>>>>
>>>>> diff --git a/board/mediatek/mt7623/mt7623_rfb.c
>>>>> b/board/mediatek/mt7623/mt7623_rfb.c
>>>>> index 984e75ccaf..22120be412 100644
>>>>> --- a/board/mediatek/mt7623/mt7623_rfb.c
>>>>> +++ b/board/mediatek/mt7623/mt7623_rfb.c
>>>>> @@ -5,6 +5,7 @@
>>>>> #include
>>>>> #include
>>>>> +#include
>>>>> DECLARE_GLOBAL_DATA_PTR;
>>>>> @@ -40,3 +41,10 @@ int mmc_get_env_dev(void)
>>>>> return mmc_get_boot_dev();
>>>>> }
>>>>> #endif
>>>>> +
>>>>> +#ifdef CONFIG_BOARD_LATE_INIT
>>>>> +int board_late_init(void)
>>>>> +{
>>>>> + wdt_stop(gd->watchdog_dev);
>>>>> +}
>>>>> +#endif
>>>>> diff --git a/configs/mt7623n_bpir2_defconfig
>>>>> b/configs/mt7623n_bpir2_defconfig
>>>>> index 9177c17dff..fe0b6259dd 100644
>>>>> --- a/configs/mt7623n_bpir2_defconfig
>>>>> +++ b/configs/mt7623n_bpir2_defconfig
>>>>> @@ -14,6 +14,7 @@ CONFIG_FIT_VERBOSE=y
>>>>> CONFIG_BOOTDELAY=3
>>>>> CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>>>>> CONFIG_DEFAULT_FDT_FILE="mt7623n-bananapi-bpi-r2.dtb"
>>>>> +CONFIG_BOARD_LATE_INIT=y
>>>>> # CONFIG_DISPLAY_BOARDINFO is not set
>>>>> CONFIG_SYS_PROMPT="U-Boot> "
>>>>> CONFIG_CMD_BOOTMENU=y
>>>>>
>>>>
>>>>
>>>> Viele Grüße,
>>>> Stefan
>>>>
>>>
>>
>>
>> Viele Grüße,
>> Stefan
>>
Re: [PATCH] board: mediatek: disable watchdog on BananaPi R2
On 11/01/2021 09:57, Heinrich Schuchardt wrote: > On 11.01.21 08:48, Stefan Roese wrote: >> >> >> On 11.01.21 08:17, Heinrich Schuchardt wrote: >>> Am 11. Januar 2021 08:02:12 MEZ schrieb Stefan Roese : >>>> Added Heinrich to Cc. >>>> >>>> On 10.01.21 19:44, Matthias Brugger wrote: >>>>> On 09/01/2021 15:57, Stefan Roese wrote: >>>>>> On 09.01.21 03:32, Matthias Brugger wrote: >>>>>>> On 08/01/2021 08:39, Stefan Roese wrote: >>>>>>>> On 07.01.21 16:36, matthias@kernel.org wrote: >>>>>>>>> From: Matthias Brugger >>>>>>>>> >>>>>>>>> Watchdog timeout comes in before we are able to load the >>>>>>>>> kernel and reset the watchdog. Disable the watchdog late in the >>>> boot >>>>>>>>> process to be able to boot the board. >>>>>>>> >>>>>>>> Can't you change the WDT reset timeout instead to a higher value? >>>>>>>> >>>>>>> >>>>>>> I tried that, but the HW has a max timeout of 15984 ms. >>>> Unfortunately that's not >>>>>>> enough. >>>>>> >>>>>> Nearly 16 seconds is not enough to boot into Linux so that the Linux >>>>>> watchdog daemon can take control? >>>>>> >>>>> >>>>> Exactly. I'm using a standard distro image. I think the main problem >>>> is, that it >>>>> needs 14 seconds for the EFI stub to actually boot the kernel. > > Hello Matthias, Hi Heinrich :) > > I observed that on some recent version Linux before 5.10 booting seemed > to be delayed by dozens of seconds on many boards. On which Linux > version did you see the problem? > I think it started on 5.9 or 5.10. Right now I'm seeing it with 5.10 and 5.11-rc2. >>>> >>>> I've not much experience (yet) with the "EFI stub". But if it takes >>>> this >>>> long, wouldn't it make sense that this stub also supports the WDT? >>> >>> efi_timer_check() calls WATCHDOG_RESET() trying to avoid that the >>> hardware watchdog is triggered. >> >> So efi_timer_check() is called quite frequently and should be enough >> to reset the U-Boot WDT while residing in EFI? Not sure, why the reset >> occurs in Matthias's case then. > > efi_timer_check() is only invoked, if the UEFI API is invoked. > Especially if the problem occurs after ExitBootServices() it is not > called anymore. > >> >>> There is a software watchdog >>> defaulting to 5 minutes in efi_watchdog.c which can be modified >>> via the EFI API. >>> >>> Is there a U-Boot API to disable the hardware watchdog? >> >> Yes: >> >> /* >> * Stop the timer, thus disabling the Watchdog. Use wdt_start to start >> it again. >> * >> * @dev: WDT Device >> * @return: 0 if OK, -ve on error >> */ >> int wdt_stop(struct udevice *dev); > > It would be interesting to understand if your problem occurs before or > after efi_exit_boot_services() is called. You could you add printf() > statements after EFI_ENTRY() and before EFI_EXIT() to see if it is reached. > It happens after EFI_EXIT(): [2021-01-11 14:06:04.621] EFI stub: Booting Linux Kernel... [2021-01-11 14:06:04.624] EFI stub: Using DTB from configuration table [2021-01-11 14:06:04.628] EFI stub: Exiting boot services and installing virtual address map... [2021-01-11 14:06:04.637] efi_exit_boot_services EFI_ENTRY [2021-01-11 14:06:04.641] efi_exit_boot_services EFI_EXIT [2021-01-11 14:06:20.972] [2021-01-11 14:06:20.973] [USBD] USB PRB0 LineState: 40 So reboot after around 16 seconds. > Could you further, please, test if adding wdt_stop() to the start of > do_bootefi() in cmd/bootefi.c solves your problem. Yes, that works. Do you want me to disable watchdog for all EFI boot cases? Regards, Matthias > > Best regards > > Heinrich > >> >> Thanks, >> Stefan >> >>> Best regards >>> >>> Heinrich >>> >>> >>>> >>>> Thanks, >>>> Stefan >>>> >>>>> I've already the >>>>> watchdog timer as build-in (which is not the best to do, taking into >>>> account >>>>> that we don't want to bloat our distro kernel with random board >>>> specific drivers >>>>> build-in. If we I had the
Re: [PATCH 1/2] timer: mtk_timer: initialize the timer before use
On Tue, Jan 12, 2021 at 01:44:02PM +0800, Weijie Gao wrote: > The timer being used by this driver may have already been used by first > stage bootloader (e.g. ATF/preloader), and it's settings may differ from > what this driver is going to use. > > This may cause issues, such as inaccurate timer frequency due to > incorrect clock divider. > > This patch adds the initialization code to avoid them. > > Signed-off-by: Weijie Gao > --- > drivers/timer/mtk_timer.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/timer/mtk_timer.c b/drivers/timer/mtk_timer.c > index 448a76a7e1..f6b97f868c 100644 > --- a/drivers/timer/mtk_timer.c > +++ b/drivers/timer/mtk_timer.c > @@ -61,6 +61,16 @@ static int mtk_timer_probe(struct udevice *dev) > if (!uc_priv->clock_rate) > return -EINVAL; > > + /* > + * Initialize the timer: > + * 1. set clock source to system clock with clock divider setting to 1 > + * 2. set timer mode to free running > + * 3. reset timer counter to 0 then enable the timer > + */ > + writel(GPT4_CLK_SYS | GPT4_CLK_DIV1, priv->base + MTK_GPT4_CLK); > + writel(GPT4_FREERUN | GPT4_CLEAR | GPT4_ENABLE, GPT4_FREERUN is defined as GENMASK(5,4) while in the Linux kernel it has the value of 3. Can you explain where this difference comes from? Regards, Matthias > +priv->base + MTK_GPT4_CTRL); > + > return 0; > } > > -- > 2.17.1
Re: [PATCH 1/2] timer: mtk_timer: initialize the timer before use
On Mon, Jan 18, 2021 at 08:44:42AM +0800, Weijie Gao wrote: > On Fri, 2021-01-15 at 17:36 +0100, Matthias Brugger wrote: > > On Tue, Jan 12, 2021 at 01:44:02PM +0800, Weijie Gao wrote: > > > The timer being used by this driver may have already been used by first > > > stage bootloader (e.g. ATF/preloader), and it's settings may differ from > > > what this driver is going to use. > > > > > > This may cause issues, such as inaccurate timer frequency due to > > > incorrect clock divider. > > > > > > This patch adds the initialization code to avoid them. > > > > > > Signed-off-by: Weijie Gao > > > --- > > > drivers/timer/mtk_timer.c | 10 ++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/drivers/timer/mtk_timer.c b/drivers/timer/mtk_timer.c > > > index 448a76a7e1..f6b97f868c 100644 > > > --- a/drivers/timer/mtk_timer.c > > > +++ b/drivers/timer/mtk_timer.c > > > @@ -61,6 +61,16 @@ static int mtk_timer_probe(struct udevice *dev) > > > if (!uc_priv->clock_rate) > > > return -EINVAL; > > > > > > + /* > > > + * Initialize the timer: > > > + * 1. set clock source to system clock with clock divider setting to 1 > > > + * 2. set timer mode to free running > > > + * 3. reset timer counter to 0 then enable the timer > > > + */ > > > + writel(GPT4_CLK_SYS | GPT4_CLK_DIV1, priv->base + MTK_GPT4_CLK); > > > + writel(GPT4_FREERUN | GPT4_CLEAR | GPT4_ENABLE, > > > > GPT4_FREERUN is defined as GENMASK(5,4) while in the Linux kernel it has > > the value of 3. Can you explain where this difference comes from? > > GENMASK(5,4) == 3 << 4, which is exactly the same as what's being used > in kernel: > > #define GPT_CTRL_OP(val)(((val) & 0x3) << 4) > #define GPT_CTRL_OP_FREERUN (3) > You are right, sorry my fault: Reviewed-by: Matthias Brugger > > > > Regards, > > Matthias > > > > > +priv->base + MTK_GPT4_CTRL); > > > + > > > return 0; > > > } > > > > > > -- > > > 2.17.1 >
Re: [PATCH v2 1/2] lib: uuid: use RNG device if present
On 29/12/2020 04:32, Simon Glass wrote: > Hi guys, > > On Wed, 23 Dec 2020 at 03:24, Torsten Duwe wrote: >> >> On Sun, 20 Dec 2020 11:17:50 -0700 >> Simon Glass wrote: >> >>> Hi Torsten, >>> >>> On Sun, 20 Dec 2020 at 10:00, Torsten Duwe wrote: On Fri, 18 Dec 2020 19:29:12 -0700 Simon Glass wrote: >> - int i; >> - >> - srand(get_ticks() + rand()); >> + int i, ret; >> + struct udevice *devp; >> + u8 randv = 0; >> + >> +#if defined(CONFIG_DM_RNG) > > This seems a little backwards to me. The caller should request a > RNG device, getting either a hardware one or a software one, and > then call the uclass method to get the uuid. Strictly speaking, there's no such thing as a "software RNG". The term "DRBG" was coined for accurateness, "deterministic random bit generator". The oxymoron "deterministic random" pretty much nails it. Alternatively, it can be called "pseudo" RNG. rand() and srand() exactly implement such a mechanism already, with low coding overhead. U-Boot runs fine with them most of the time, but there are rare cases where real entropy would be needed. This is what these two patches are about. In case there's more, I already speculated about a centralised entity in my response to the v1 cover letter, but for now these two changes should do. >>> >>> I am used to the term pseudo-random, but it doesn't much matter what >>> kind of random number is used. It is still covered by the RNG class. >> >> Well, in these 2 cases, it _does_ matter. And besides, as I wrote >> above, pseudo randomness is produced by the rand() function, and RNG >> devices provide _real_ entropy to a system. >> >> So, while every other entity in U-Boot is happy with a DRBG, a UUID and >> a BOOTP delay need this real entropy, hence the different code, for a >> start. >> >>> You are currently burying device access in a utility function. That >>> really isn't the right way to do it. See my comment above. There is no >>> way to control which RNG device is used and no visibility that this is >>> happening at all, outside this function. >> >> The code looks a bit odd to me, too, as I mentioned. I imagined >> something not so full blown as in the Linux kernel, but still some >> central mechanism to get entropy from, for those who really need it (in >> the current situation, just these 2 cases). This alternative would >> result in a real /dev/random in U-Boot, which would yield a cleaner >> structure, but would require more code to be produced and more code >> needing change. That given, I'd agree to these 2 hacks, especially >> because there are security implications. >> >> What's your opinion, how would you like to create really unique UUIDs? >> How should BOOTP clients wait randomly (esp. in a large group)? >> Shall we create some U-Boot version of /dev/random and haveged? >> >> I'm really open to suggestions. >> > > I really don't mind too much about that side of it. But I do worry > when I see code that buries hard-coded DM access in a lib/ function. > v3 of this series got merged, which should not stop us from making the code better. > If boot wants a random device it should get one, at the top level, not > in the bowels of U-Boot. It can pass that device down to other > functions as needed. > So you mean we should get the RNG udevice at the caller of gen_rand_uuid_str and then pass it down to gen_rand_uuid? And if no device has been found, we will call srand(get_ticks() + rand())? I'm not quite sure how we would need to implement this in the case of srand_mac() though. Regards, Matthias > To my reading, the current definition of the RNG uclass looks similar > to a /dev/random > > Let me know if I am missing something. >
Re: [PATCH v2 1/2] lib: uuid: use RNG device if present
On Wed, Jan 20, 2021 at 12:50:56PM -0700, Simon Glass wrote: > Hi Matthias, > > On Wed, 20 Jan 2021 at 04:17, Matthias Brugger wrote: > > > > > > > > On 29/12/2020 04:32, Simon Glass wrote: > > > Hi guys, > > > > > > On Wed, 23 Dec 2020 at 03:24, Torsten Duwe wrote: > > >> > > >> On Sun, 20 Dec 2020 11:17:50 -0700 > > >> Simon Glass wrote: > > >> > > >>> Hi Torsten, > > >>> > > >>> On Sun, 20 Dec 2020 at 10:00, Torsten Duwe wrote: > > >>>> > > >>>> On Fri, 18 Dec 2020 19:29:12 -0700 > > >>>> Simon Glass wrote: > > >>>> > > >>>>>> - int i; > > >>>>>> - > > >>>>>> - srand(get_ticks() + rand()); > > >>>>>> + int i, ret; > > >>>>>> + struct udevice *devp; > > >>>>>> + u8 randv = 0; > > >>>>>> + > > >>>>>> +#if defined(CONFIG_DM_RNG) > > >>>>> > > >>>>> This seems a little backwards to me. The caller should request a > > >>>>> RNG device, getting either a hardware one or a software one, and > > >>>>> then call the uclass method to get the uuid. > > >>>> > > >>>> Strictly speaking, there's no such thing as a "software RNG". The > > >>>> term "DRBG" was coined for accurateness, "deterministic random bit > > >>>> generator". The oxymoron "deterministic random" pretty much nails > > >>>> it. Alternatively, it can be called "pseudo" RNG. > > >>>> rand() and srand() exactly implement such a mechanism already, with > > >>>> low coding overhead. U-Boot runs fine with them most of the time, > > >>>> but there are rare cases where real entropy would be needed. This > > >>>> is what these two patches are about. In case there's more, I > > >>>> already speculated about a centralised entity in my response to the > > >>>> v1 cover letter, but for now these two changes should do. > > >>> > > >>> I am used to the term pseudo-random, but it doesn't much matter what > > >>> kind of random number is used. It is still covered by the RNG class. > > >> > > >> Well, in these 2 cases, it _does_ matter. And besides, as I wrote > > >> above, pseudo randomness is produced by the rand() function, and RNG > > >> devices provide _real_ entropy to a system. > > >> > > >> So, while every other entity in U-Boot is happy with a DRBG, a UUID and > > >> a BOOTP delay need this real entropy, hence the different code, for a > > >> start. > > >> > > >>> You are currently burying device access in a utility function. That > > >>> really isn't the right way to do it. See my comment above. There is no > > >>> way to control which RNG device is used and no visibility that this is > > >>> happening at all, outside this function. > > >> > > >> The code looks a bit odd to me, too, as I mentioned. I imagined > > >> something not so full blown as in the Linux kernel, but still some > > >> central mechanism to get entropy from, for those who really need it (in > > >> the current situation, just these 2 cases). This alternative would > > >> result in a real /dev/random in U-Boot, which would yield a cleaner > > >> structure, but would require more code to be produced and more code > > >> needing change. That given, I'd agree to these 2 hacks, especially > > >> because there are security implications. > > >> > > >> What's your opinion, how would you like to create really unique UUIDs? > > >> How should BOOTP clients wait randomly (esp. in a large group)? > > >> Shall we create some U-Boot version of /dev/random and haveged? > > >> > > >> I'm really open to suggestions. > > >> > > > > > > I really don't mind too much about that side of it. But I do worry > > > when I see code that buries hard-coded DM access in a lib/ function. > > > > > > > v3 of this series got merged, which should not stop us from making the code > > better. > > > > > > > If boot wants a random device it shoul
[GIT PULL] rpi: second round for v2020.10
Hi Tom, Please have a look at the second round of patches for the RPi. Two patches fixes the network driver of the RPi4 which didn't work reliable. Another patch enables USB keyboard for 32 bit RPi4. Petr tested the network patches, but his mail with the Tested-by tag didn't come through. I added it anyway. As always you can find the CI outcome here: https://travis-ci.org/github/mbgg/u-boot/builds/725262009 https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/4622 I ran the CI against the rpi-next branch and not the tag, but you can verify that this is basically the same commit id. Thanks for having a look! Regards, Matthias -- The following changes since commit 96d66a9b8ce11aae9f8bef5244b83b4740b37644: Prepare v2020.10-rc4 (2020-09-07 14:17:33 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git/ tags/rpi-next-2020.10.2 for you to fetch changes up to 40877a1a949edf7066b3e4ed16101153624bb314: config: Enable USB Keyboard suuport on RPi4 32 bit (2020-09-08 16:45:01 +0200) - fixes for bcmgenet - enable USB keyboard for RPi4 32 bit Jason Wessel (2): bcmgenet: fix DMA buffer management bcmgenet: Add support for rgmii-rxid Matthias Brugger (1): config: Enable USB Keyboard suuport on RPi4 32 bit configs/rpi_4_32b_defconfig | 1 + drivers/net/bcmgenet.c | 20 +++- 2 files changed, 12 insertions(+), 9 deletions(-)
Re: [GIT PULL] rpi: second round for v2020.10
On 09/09/2020 21:20, Petr Tesarik wrote: On Wed, 9 Sep 2020 10:13:50 +0200 Matthias Brugger wrote: Hi Tom, Please have a look at the second round of patches for the RPi. Two patches fixes the network driver of the RPi4 which didn't work reliable. Another patch enables USB keyboard for 32 bit RPi4. Petr tested the network patches, but his mail with the Tested-by tag didn't come through. I added it anyway. What do you mean by "didn't come through"? I can see it in the mailing list archive: http://u-boot.10912.n7.nabble.com/PATCH-bcmgenet-fix-DMA-buffer-management-td419536.html#a424854 Did I send my answer to the wrong thread? Ups, it seems I rely too much on my inbox instead of the filtered U-Boot list. In any case I exepcted the Tested-by for the two patches you mentioned in the thread. Anyway it's no big deal. Regards, Matthias Petr T As always you can find the CI outcome here: https://travis-ci.org/github/mbgg/u-boot/builds/725262009 https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/4622 I ran the CI against the rpi-next branch and not the tag, but you can verify that this is basically the same commit id. Thanks for having a look! Regards, Matthias -- The following changes since commit 96d66a9b8ce11aae9f8bef5244b83b4740b37644: Prepare v2020.10-rc4 (2020-09-07 14:17:33 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git/ tags/rpi-next-2020.10.2 for you to fetch changes up to 40877a1a949edf7066b3e4ed16101153624bb314: config: Enable USB Keyboard suuport on RPi4 32 bit (2020-09-08 16:45:01 +0200) - fixes for bcmgenet - enable USB keyboard for RPi4 32 bit Jason Wessel (2): bcmgenet: fix DMA buffer management bcmgenet: Add support for rgmii-rxid Matthias Brugger (1): config: Enable USB Keyboard suuport on RPi4 32 bit configs/rpi_4_32b_defconfig | 1 + drivers/net/bcmgenet.c | 20 +++- 2 files changed, 12 insertions(+), 9 deletions(-)
Re: RPi4 U-Boot freeze
On 10/09/2020 23:12, Stefan Agner wrote: On 2020-09-07 16:36, Peter Robinson wrote: Any thoughts on this issue? Any reason why you're using 2020.01 and not at least 2020.07, or at least seeing if it's reproducible on 2020.10-rc3? The RPi4 support has changed quite a bit since then I suspect. Hi Peter, It's a stable release and we support a couple of devices with the same U-Boot version. I'd rather prefer to stay with 2020.01 for RPi4 as well. We are on 2020.07 on development branch, and it does work fine there. So I thought it can't be that hard, just bisect and backport whatever fixes it... Unfortunately, it seems that there is no particular commit which fixes it (the bisect ended up in a random unrelated commit, and it seems that the issue appears/disappears depending on alignment/size...). I also did applied pretty much every RPi4 related commit made after 2020.01 up until master back to 2020.01, no success either. Which version of the Raspberry Pi firmware did you use? Unfortunately changes in the FW breaks stuff on U-Boot from time to time. Regards, Mathias I fear that the problem in fact is still in master, but only appears if certain things align a certain way... That is why I thought I bring it up, to see if anybody else has noticed something along this lines. We do have a rather trimmed down configuration, which might make the problem appear more (fit in a D cache...). I probably will just disable cached around relocation for 2020.01 and see if it resurfaces on development branch. -- Stefan Just to be sure, I did some memory testing on the 2GB module, but no issues found. I still somehow suspected that something else might be wrong with my hardware, so I bought a new RPi4 (this time with 4GB of RAM) but the very same with that: U-Boot 2020.01 (Aug 23 2020 - 22:02:31 +) DRAM: 3.9 GiB I still think there is something wrong with caching. From what I understand caches are enabled by the RPi (4) firmware. Is it safe to run 32-bit ARM U-Boot with enabled caches? -- Stefan On 2020-08-23 19:06, Stefan Agner wrote: Hi, I noticed a quite common freeze when running 32-bit U-Boot 2020.01 (rpi_4_32b_defconfig) on a 2GB RPi4 model: U-Boot 2020.01 (Aug 07 2020 - 13:00:23 +) DRAM: 1.9 GiB This happens fairly often, I would say 4 out of 5 boot tries. However, if it boots, everything seems to run fine. The issue seems to go away when using 2020.04 or any newer release, however, when trying to find the actual patch fixing the issue using git bisect I ended up with a MMC merge request which really seems unrelated (36bdcf7f3b). It seems that the problem is quite evasive and disappears if certain structure are aligned differently etc. Enabling initcall debugging showed that U-Boot crashes right after relocation: ... initcall: 00016f2c RAM Configuration: Bank #0: 0 948 MiB Bank #1: 4000 1 GiB Bank #2: 0 0 Bytes Bank #3: 0 0 Bytes DRAM: 1.9 GiB initcall: 00016bb8 New Stack Pointer is: 3af6d9e0 initcall: 00016da4 initcall: 00016ef0 initcall: 00016ef8 initcall: 00016d38 Relocation Offset is: 3b375000 Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0 initcall: 00016ec8 [clear_bss] initcall: 0004465c [display_options?? only appears sometimes] I realized when using CONFIG_SYS_(I|D)CACHE_OFF=y the problem seems to disappear. But to be 100% certain that it is cache related, I used my original configuration (which is known to "reliably" freeze), and replaced 00016ec8 with 8688 manually in the binary, essentially swapping out function pointers in "init_sequence_f" [8688 is cleanup_before_linux, which flushes and disables I-cache/D-cache]. And indeed, that hacked up binary does boot reliably every time: ... initcall: 00016f2c RAM Configuration: Bank #0: 0 948 MiB Bank #1: 4000 1 GiB Bank #2: 0 0 Bytes Bank #3: 0 0 Bytes DRAM: 1.9 GiB initcall: 00016bb8 New Stack Pointer is: 3af6d9e0 initcall: 00016da4 initcall: 00016ef0 initcall: 00016ef8 initcall: 00016d38 Relocation Offset is: 3b375000 Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0 initcall: 8688 initcall: 3b38c10c initcall: 3b38c114 initcall: 000172e0 (relocated to 3b38c2e0) initcall: 0001712c (relocated to 3b38c12c) ... From what I understand on RPi4 caches are enabled when entering U-Boot. I was wondering if the relocation code really can handle that? -- Stefan
Re: [PATCH] smbios: Fix table when no string is present
On 25/03/2021 01:38, Simon Glass wrote:
> Hi Matthias,
>
> On Thu, 18 Mar 2021 at 00:30, wrote:
>>
>> From: Matthias Brugger
>>
>> When no string is present in a table, next_ptr points to the same
>> location as eos. When calculating the string table length, we would only
>> reserve one \0. By spec a SMBIOS table has to end with two \0\0 when no
>> strings a present.
>>
>> Signed-off-by: Matthias Brugger
>>
>> ---
>>
>> lib/smbios.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> There is a bug here but I don't think this is right fix. I remember
> worrying about this, making the same change as you did, reverting it
> and then forgetting about it :-( It has no tests.
>
> You are effectively changing the definition of next_ptr here:
>
> * @next_ptr: pointer to the start of the next string to be added. When the
> * table is not empty, this points to the byte after the \0 of the
> * previous string.
>
That's true.
> (there is a typo in that in the code)
>
> I think that breaks adding new strings.
>
Well it doesn't because when adding a new string, ctx->next_ptr gets overwritten
[1]. It is only used to calculate the lenght of the string in
smbios_string_table_len() to calculate the size of the table [2]. But yes it's
not the obvious way to handle the case when no string is present.
> Can you instead change smbios_string_table_len() to add 2?
>
Do you mean returning 2 when no string is present (ctx->next_ptr == ctx->eos)?
Adding 2 will break the case when we have a string present, as a string already
finishes with '\0' and we only need a second '\0'.
Regards,
Matthias
[1] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/smbios.c#L95
[2] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/smbios.c#L196
>>
>> diff --git a/lib/smbios.c b/lib/smbios.c
>> index 7d463c84a9..d21d37cdac 100644
>> --- a/lib/smbios.c
>> +++ b/lib/smbios.c
>> @@ -153,7 +153,7 @@ static int smbios_add_prop(struct smbios_ctx *ctx, const
>> char *prop)
>> static void smbios_set_eos(struct smbios_ctx *ctx, char *eos)
>> {
>> ctx->eos = eos;
>> - ctx->next_ptr = eos;
>> + ctx->next_ptr = eos + 1;
>> ctx->last_str = NULL;
>> }
>>
>> --
>> 2.30.2
>>
>
> Regards,
> Simon
>
Re: [PATCH v2 1/2] arm: dts: bcm283x: Allow UARTs to work before relocation
Hi all, On 29/04/2020 22:11, Simon Glass wrote: > Hi Tom, > > On Wed, 15 Apr 2020 at 13:59, Tom Rini wrote: >> >> On Tue, Apr 14, 2020 at 08:23:10PM -0600, Simon Glass wrote: >>> Hi, >>> >>> On Sun, 22 Mar 2020 at 21:16, Simon Glass wrote: At present the pinctrl nodes are not enabled in pre-relocation U-Boot so the UARTs do not correctly select the pinconfig to enable the UART pins. Fix this so that the U-Boot banner is printed. This fixes serial output on rpi_3b_32b with the following config.txt options: enable_uart=1 gpu_freq=250 Signed-off-by: Simon Glass Fixes: 9821636b64 (bcm2835_pinctrl: Probe pre-reloc) --- Changes in v2: - Update commit message arch/arm/dts/bcm283x-u-boot.dtsi | 8 1 file changed, 8 insertions(+) >>> >>> Any thoughts on this series? At present all my lab tests fail. >> >> I don't know if the problem is my firmware is too old (and so works) or >> your firmware is too old (and so fails) or if there's some >> phase-of-the-moon problem. So while I'd like to know _why_ my 3B is >> fine and yours is not, we should just take this I suppose. > > It should not harm anything. > > For now I am unable to run rpi tests on mainline. > Sorry for being silent for such a long time. I'll have a look and provide a PR. Regards, Matthias
Re: [PATCH v2 1/2] arm: dts: bcm283x: Allow UARTs to work before relocation
On 23/03/2020 04:15, Simon Glass wrote:
> At present the pinctrl nodes are not enabled in pre-relocation U-Boot so
> the UARTs do not correctly select the pinconfig to enable the UART pins.
> Fix this so that the U-Boot banner is printed.
>
> This fixes serial output on rpi_3b_32b with the following config.txt
> options:
>
>enable_uart=1
>gpu_freq=250
>
> Signed-off-by: Simon Glass
> Fixes: 9821636b64 (bcm2835_pinctrl: Probe pre-reloc)
Pushed not to rpi-next, sorry for the delay and thanks for the patch :)
> ---
>
> Changes in v2:
> - Update commit message
>
> arch/arm/dts/bcm283x-u-boot.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/dts/bcm283x-u-boot.dtsi
> b/arch/arm/dts/bcm283x-u-boot.dtsi
> index 36548dad62..68d03627f4 100644
> --- a/arch/arm/dts/bcm283x-u-boot.dtsi
> +++ b/arch/arm/dts/bcm283x-u-boot.dtsi
> @@ -19,3 +19,11 @@
> &gpio {
> u-boot,dm-pre-reloc;
> };
> +
> +&uart0_gpio14 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&uart1_gpio14 {
> + u-boot,dm-pre-reloc;
> +};
>
Re: [PATCH v2 2/2] arm: bcm283x: serial: Move ofdata reading to probe() method
On 23/03/2020 04:15, Simon Glass wrote:
> We cannot rely on a parent bus that needs to be probed, until we know that
> it is probed. That means that code in the ofdata_to_platdata() method
> cannot rely on the parent bus being probed.
>
> Move the ofdata code in the two serial drivers into a probe() method.
>
> This fixes serial output on rpi_3b_32b with the following config.txt
> options:
>
>enable_uart=1
>gpu_freq=250
>
> Signed-off-by: Simon Glass
Pushed not to rpi-next, sorry for the delay and thanks for the patch :)
> ---
>
> Changes in v2:
> - Add new patch to move ofdata reading to probe() method
>
> drivers/serial/serial_bcm283x_mu.c| 21 +
> drivers/serial/serial_bcm283x_pl011.c | 12
> 2 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/serial/serial_bcm283x_mu.c
> b/drivers/serial/serial_bcm283x_mu.c
> index a6ffc84b96..febb5ceea2 100644
> --- a/drivers/serial/serial_bcm283x_mu.c
> +++ b/drivers/serial/serial_bcm283x_mu.c
> @@ -74,16 +74,6 @@ out:
> return 0;
> }
>
> -static int bcm283x_mu_serial_probe(struct udevice *dev)
> -{
> - struct bcm283x_mu_serial_platdata *plat = dev_get_platdata(dev);
> - struct bcm283x_mu_priv *priv = dev_get_priv(dev);
> -
> - priv->regs = (struct bcm283x_mu_regs *)plat->base;
> -
> - return 0;
> -}
> -
> static int bcm283x_mu_serial_getc(struct udevice *dev)
> {
> struct bcm283x_mu_priv *priv = dev_get_priv(dev);
> @@ -165,15 +155,21 @@ static bool bcm283x_is_serial_muxed(void)
> return true;
> }
>
> -static int bcm283x_mu_serial_ofdata_to_platdata(struct udevice *dev)
> +static int bcm283x_mu_serial_probe(struct udevice *dev)
> {
> struct bcm283x_mu_serial_platdata *plat = dev_get_platdata(dev);
> + struct bcm283x_mu_priv *priv = dev_get_priv(dev);
> fdt_addr_t addr;
>
> /* Don't spawn the device if it's not muxed */
> if (!bcm283x_is_serial_muxed())
> return -ENODEV;
>
> + /*
> + * Read the ofdata here rather than in an ofdata_to_platdata() method
> + * since we need the soc simple-bus to be probed so that the 'ranges'
> + * property is used.
> + */
> addr = devfdt_get_addr(dev);
> if (addr == FDT_ADDR_T_NONE)
> return -EINVAL;
> @@ -187,6 +183,8 @@ static int bcm283x_mu_serial_ofdata_to_platdata(struct
> udevice *dev)
>*/
> plat->skip_init = true;
>
> + priv->regs = (struct bcm283x_mu_regs *)plat->base;
> +
> return 0;
> }
> #endif
> @@ -195,7 +193,6 @@ U_BOOT_DRIVER(serial_bcm283x_mu) = {
> .name = "serial_bcm283x_mu",
> .id = UCLASS_SERIAL,
> .of_match = of_match_ptr(bcm283x_mu_serial_id),
> - .ofdata_to_platdata =
> of_match_ptr(bcm283x_mu_serial_ofdata_to_platdata),
> .platdata_auto_alloc_size = sizeof(struct bcm283x_mu_serial_platdata),
> .probe = bcm283x_mu_serial_probe,
> .ops = &bcm283x_mu_serial_ops,
> diff --git a/drivers/serial/serial_bcm283x_pl011.c
> b/drivers/serial/serial_bcm283x_pl011.c
> index 7d8ab7b716..923f402fbe 100644
> --- a/drivers/serial/serial_bcm283x_pl011.c
> +++ b/drivers/serial/serial_bcm283x_pl011.c
> @@ -33,7 +33,7 @@ static bool bcm283x_is_serial_muxed(void)
> return true;
> }
>
> -static int bcm283x_pl011_serial_ofdata_to_platdata(struct udevice *dev)
> +static int bcm283x_pl011_serial_probe(struct udevice *dev)
> {
> struct pl01x_serial_platdata *plat = dev_get_platdata(dev);
> int ret;
> @@ -42,6 +42,11 @@ static int bcm283x_pl011_serial_ofdata_to_platdata(struct
> udevice *dev)
> if (!bcm283x_is_serial_muxed())
> return -ENODEV;
>
> + /*
> + * Read the ofdata here rather than in an ofdata_to_platdata() method
> + * since we need the soc simple-bus to be probed so that the 'ranges'
> + * property is used.
> + */
> ret = pl01x_serial_ofdata_to_platdata(dev);
> if (ret)
> return ret;
> @@ -52,7 +57,7 @@ static int bcm283x_pl011_serial_ofdata_to_platdata(struct
> udevice *dev)
>*/
> plat->skip_init = true;
>
> - return 0;
> + return pl01x_serial_probe(dev);
> }
>
> static int bcm283x_pl011_serial_setbrg(struct udevice *dev, int baudrate)
> @@ -86,9 +91,8 @@ U_BOOT_DRIVER(bcm283x_pl011_uart) = {
> .name = "bcm283x_pl011",
> .id = UCLASS_SERIAL,
> .of_match = of_match_ptr(bcm283x_pl011_serial_id),
> - .ofdata_to_platdata =
> of_match_ptr(bcm283x_pl011_serial_ofdata_to_platdata),
> + .probe = bcm283x_pl011_serial_probe,
> .platdata_auto_alloc_size = sizeof(struct pl01x_serial_platdata),
> - .probe = pl01x_serial_probe,
> .ops= &bcm283x_pl011_serial_ops,
> #if !CONFIG_IS_ENABLED(OF_CONTROL) || CONFIG_IS_ENABLED(OF_BOARD)
> .flags = DM_FLAG_PRE_RELOC,
>
Re: [PATCH v2 2/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware
On 30/04/2020 15:04, Nicolas Saenz Julienne wrote:
> When needed, RPi4's co-processor (called VideoCore) has to be instructed
> to load VL805's firmware (the chip providing xHCI support). VideoCore's
> firmware expects the board's PCIe bus to be already configured in order
> for it to load the xHCI chip firmware. So we have to make sure this
> happens in between the PCIe configuration and xHCI startup.
>
> Introduce a callback in xhci_pci_probe() to run this platform specific
> routine.
>
> Signed-off-by: Nicolas Saenz Julienne
>
> ---
>
> Changes since v1:
> - Create callback
>
> board/raspberrypi/rpi/rpi.c | 12
> drivers/usb/host/xhci-pci.c | 6 ++
> include/usb/xhci.h | 3 +++
> 3 files changed, 21 insertions(+)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index e367ba3092..8aa78d1f48 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -494,3 +495,14 @@ int ft_board_setup(void *blob, bd_t *bd)
>
> return 0;
> }
> +
> +#ifdef CONFIG_BCM2711
This won't work with rpi_arm64_defconfig.
Can't we just evaluate at runtime if we need to do anything in xhci_pci_fixup.
I wonder if the newer RPi4 have also a newer revision ID (see get_board_rev). If
so we could add another bool to struct rpi_model which will indicate us if we
need to notify VideoCore about vl805's firmware.
Regards,
Matthias
> +void xhci_pci_fixup(struct udevice *dev)
> +{
> + int ret;
> +
> + ret = bcm2711_notify_vl805_reset();
> + if (ret)
> + printf("RPI: Failed to notify VideoCore about vl805's
> firmware\n");
> +}
> +#endif
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index c1f60da541..1285dde1ef 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -11,6 +11,10 @@
> #include
> #include
>
> +__weak void xhci_pci_fixup(struct udevice *dev)
> +{
> +}
> +
> static void xhci_pci_init(struct udevice *dev, struct xhci_hccr **ret_hccr,
> struct xhci_hcor **ret_hcor)
> {
> @@ -40,6 +44,8 @@ static int xhci_pci_probe(struct udevice *dev)
> struct xhci_hccr *hccr;
> struct xhci_hcor *hcor;
>
> + xhci_pci_fixup(dev);
> +
> xhci_pci_init(dev, &hccr, &hcor);
>
> return xhci_register(dev, hccr, hcor);
> diff --git a/include/usb/xhci.h b/include/usb/xhci.h
> index c16106a2fc..57feed7603 100644
> --- a/include/usb/xhci.h
> +++ b/include/usb/xhci.h
> @@ -16,6 +16,7 @@
> #ifndef HOST_XHCI_H_
> #define HOST_XHCI_H_
>
> +#include
> #include
> #include
> #include
> @@ -1281,4 +1282,6 @@ extern struct dm_usb_ops xhci_usb_ops;
>
> struct xhci_ctrl *xhci_get_ctrl(struct usb_device *udev);
>
> +extern void xhci_pci_fixup(struct udevice *dev);
> +
> #endif /* HOST_XHCI_H_ */
>
Re: [PATCH v2 2/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware
On 05/05/2020 14:53, Nicolas Saenz Julienne wrote:
> Hi Matthias,
>
> On Tue, 2020-05-05 at 14:15 +0200, Matthias Brugger wrote:
>>
>> On 30/04/2020 15:04, Nicolas Saenz Julienne wrote:
>>> When needed, RPi4's co-processor (called VideoCore) has to be instructed
>>> to load VL805's firmware (the chip providing xHCI support). VideoCore's
>>> firmware expects the board's PCIe bus to be already configured in order
>>> for it to load the xHCI chip firmware. So we have to make sure this
>>> happens in between the PCIe configuration and xHCI startup.
>>>
>>> Introduce a callback in xhci_pci_probe() to run this platform specific
>>> routine.
>>>
>>> Signed-off-by: Nicolas Saenz Julienne
>>>
>>> ---
>>>
>>> Changes since v1:
>>> - Create callback
>>>
>>> board/raspberrypi/rpi/rpi.c | 12
>>> drivers/usb/host/xhci-pci.c | 6 ++
>>> include/usb/xhci.h | 3 +++
>>> 3 files changed, 21 insertions(+)
>>>
>>> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
>>> index e367ba3092..8aa78d1f48 100644
>>> --- a/board/raspberrypi/rpi/rpi.c
>>> +++ b/board/raspberrypi/rpi/rpi.c
>>> @@ -14,6 +14,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -494,3 +495,14 @@ int ft_board_setup(void *blob, bd_t *bd)
>>>
>>> return 0;
>>> }
>>> +
>>> +#ifdef CONFIG_BCM2711
>>
>> This won't work with rpi_arm64_defconfig.
>> Can't we just evaluate at runtime if we need to do anything in
>> xhci_pci_fixup.
>
> I can't see why, who is going to call xhci_pci_probe() in RPi3?
>
If you do make rpi_arm64_defconfig and inspect the .config, you will see that
CONFIG_BCM2711 is not defined, so this code won't be called on RPi4.
Regards,
Matthias
> Regards,
> Nicolas
>
>> I wonder if the newer RPi4 have also a newer revision ID (see get_board_rev).
>> If
>> so we could add another bool to struct rpi_model which will indicate us if we
>> need to notify VideoCore about vl805's firmware.
>>
>>> +void xhci_pci_fixup(struct udevice *dev)
>>> +{
>>> + int ret;
>>> +
>>> + ret = bcm2711_notify_vl805_reset();
>>> + if (ret)
>>> + printf("RPI: Failed to notify VideoCore about vl805's
>>> firmware\n");
>>> +}
>>> +#endif
>>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>>> index c1f60da541..1285dde1ef 100644
>>> --- a/drivers/usb/host/xhci-pci.c
>>> +++ b/drivers/usb/host/xhci-pci.c
>>> @@ -11,6 +11,10 @@
>>> #include
>>> #include
>>>
>>> +__weak void xhci_pci_fixup(struct udevice *dev)
>>> +{
>>> +}
>>> +
>>> static void xhci_pci_init(struct udevice *dev, struct xhci_hccr **ret_hccr,
>>> struct xhci_hcor **ret_hcor)
>>> {
>>> @@ -40,6 +44,8 @@ static int xhci_pci_probe(struct udevice *dev)
>>> struct xhci_hccr *hccr;
>>> struct xhci_hcor *hcor;
>>>
>>> + xhci_pci_fixup(dev);
>>> +
>>> xhci_pci_init(dev, &hccr, &hcor);
>>>
>>> return xhci_register(dev, hccr, hcor);
>>> diff --git a/include/usb/xhci.h b/include/usb/xhci.h
>>> index c16106a2fc..57feed7603 100644
>>> --- a/include/usb/xhci.h
>>> +++ b/include/usb/xhci.h
>>> @@ -16,6 +16,7 @@
>>> #ifndef HOST_XHCI_H_
>>> #define HOST_XHCI_H_
>>>
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -1281,4 +1282,6 @@ extern struct dm_usb_ops xhci_usb_ops;
>>>
>>> struct xhci_ctrl *xhci_get_ctrl(struct usb_device *udev);
>>>
>>> +extern void xhci_pci_fixup(struct udevice *dev);
>>> +
>>> #endif /* HOST_XHCI_H_ */
>>>
>
Re: [PATCH v2 05/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit)
On 04/05/2020 14:45, Sylwester Nawrocki wrote:
> From: Marek Szyprowski
>
> Create a non-cacheable mapping for the 0x6 physical memory region,
> where MMIO registers for the PCIe XHCI controller are instantiated by the
> PCIe bridge.
>
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Sylwester Nawrocki
> Reviewed-by: Nicolas Saenz Julienne
> ---
> Changes since v1:
> - none.
> ---
> arch/arm/mach-bcm283x/init.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
> index 4295356..6a748da 100644
> --- a/arch/arm/mach-bcm283x/init.c
> +++ b/arch/arm/mach-bcm283x/init.c
> @@ -11,10 +11,15 @@
> #include
> #include
>
> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS 0x6UL
> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE 0x80UL
> +
> #ifdef CONFIG_ARM64
> #include
>
> -static struct mm_region bcm283x_mem_map[] = {
> +#define MAX_MAP_MAX_ENTRIES (4)
What stands the second 'MAX' for?
> +
> +static struct mm_region bcm283x_mem_map[MAX_MAP_MAX_ENTRIES] = {
> {
> .virt = 0xUL,
> .phys = 0xUL,
> @@ -34,7 +39,7 @@ static struct mm_region bcm283x_mem_map[] = {
> }
> };
>
> -static struct mm_region bcm2711_mem_map[] = {
> +static struct mm_region bcm2711_mem_map[MAX_MAP_MAX_ENTRIES] = {
> {
> .virt = 0xUL,
> .phys = 0xUL,
> @@ -49,6 +54,13 @@ static struct mm_region bcm2711_mem_map[] = {
>PTE_BLOCK_NON_SHARE |
>PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
I'd prefer a comment instead of using the BCM2711_RPI4_PCIE_XHCI_MMIO_* defines.
> + .virt = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS> + .phys =
> BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
> + .size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> /* List terminator */
> 0,
> }
> @@ -71,7 +83,7 @@ static void _rpi_update_mem_map(struct mm_region *pd)
> {
> int i;
>
> - for (i = 0; i < 2; i++) {
> + for (i = 0; i < MAX_MAP_MAX_ENTRIES; i++) {
Variable mem_map points to bcm283x_mem_map which only holds two mm_region's
(plus list terminator). So we have an overflow here. I think we should just
define bcm2711_mem_map and bcm283x_mem_map with a fixed array size of 4 (see
comment on the define naming above).
Regards,
Matthias
> mem_map[i].virt = pd[i].virt;
> mem_map[i].phys = pd[i].phys;
> mem_map[i].size = pd[i].size;
>
Re: [PATCH v2 05/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit)
On 05/05/2020 16:00, Matthias Brugger wrote:
>
>
> On 04/05/2020 14:45, Sylwester Nawrocki wrote:
>> From: Marek Szyprowski
>>
>> Create a non-cacheable mapping for the 0x6 physical memory region,
>> where MMIO registers for the PCIe XHCI controller are instantiated by the
>> PCIe bridge.
>>
>> Signed-off-by: Marek Szyprowski
>> Signed-off-by: Sylwester Nawrocki
>> Reviewed-by: Nicolas Saenz Julienne
>> ---
>> Changes since v1:
>> - none.
>> ---
>> arch/arm/mach-bcm283x/init.c | 18 +++---
>> 1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>> index 4295356..6a748da 100644
>> --- a/arch/arm/mach-bcm283x/init.c
>> +++ b/arch/arm/mach-bcm283x/init.c
>> @@ -11,10 +11,15 @@
>> #include
>> #include
>>
>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS0x6UL
>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE0x80UL
>> +
>> #ifdef CONFIG_ARM64
>> #include
>>
>> -static struct mm_region bcm283x_mem_map[] = {
>> +#define MAX_MAP_MAX_ENTRIES (4)
>
> What stands the second 'MAX' for?
>
>> +
>> +static struct mm_region bcm283x_mem_map[MAX_MAP_MAX_ENTRIES] = {
>> {
>> .virt = 0xUL,
>> .phys = 0xUL,
>> @@ -34,7 +39,7 @@ static struct mm_region bcm283x_mem_map[] = {
>> }
>> };
>>
>> -static struct mm_region bcm2711_mem_map[] = {
>> +static struct mm_region bcm2711_mem_map[MAX_MAP_MAX_ENTRIES] = {
>> {
>> .virt = 0xUL,
>> .phys = 0xUL,
>> @@ -49,6 +54,13 @@ static struct mm_region bcm2711_mem_map[] = {
>> PTE_BLOCK_NON_SHARE |
>> PTE_BLOCK_PXN | PTE_BLOCK_UXN
>> }, {
>
> I'd prefer a comment instead of using the BCM2711_RPI4_PCIE_XHCI_MMIO_*
> defines.
>
Ok, I see now you use the defines later on, forget my comment. It's ok as is.
Regards,
Matthias
>> +.virt = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS> + .phys =
>> BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
>> +.size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE,
>> +.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>> + PTE_BLOCK_NON_SHARE |
>> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
>> +}, {
>> /* List terminator */
>> 0,
>> }
>> @@ -71,7 +83,7 @@ static void _rpi_update_mem_map(struct mm_region *pd)
>> {
>> int i;
>>
>> -for (i = 0; i < 2; i++) {
>> +for (i = 0; i < MAX_MAP_MAX_ENTRIES; i++) {
>
> Variable mem_map points to bcm283x_mem_map which only holds two mm_region's
> (plus list terminator). So we have an overflow here. I think we should just
> define bcm2711_mem_map and bcm283x_mem_map with a fixed array size of 4 (see
> comment on the define naming above).
>
> Regards,
> Matthias
>
>> mem_map[i].virt = pd[i].virt;
>> mem_map[i].phys = pd[i].phys;
>> mem_map[i].size = pd[i].size;
>>
Re: [PATCH v2 05/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit)
On 05/05/2020 16:10, Marek Szyprowski wrote:
> Hi Matthias,
>
> On 05.05.2020 16:00, Matthias Brugger wrote:
>> On 04/05/2020 14:45, Sylwester Nawrocki wrote:
>>> From: Marek Szyprowski
>>>
>>> Create a non-cacheable mapping for the 0x6 physical memory region,
>>> where MMIO registers for the PCIe XHCI controller are instantiated by the
>>> PCIe bridge.
>>>
>>> Signed-off-by: Marek Szyprowski
>>> Signed-off-by: Sylwester Nawrocki
>>> Reviewed-by: Nicolas Saenz Julienne
>>> ---
>>> Changes since v1:
>>> - none.
>>> ---
>>> arch/arm/mach-bcm283x/init.c | 18 +++---
>>> 1 file changed, 15 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>>> index 4295356..6a748da 100644
>>> --- a/arch/arm/mach-bcm283x/init.c
>>> +++ b/arch/arm/mach-bcm283x/init.c
>>> @@ -11,10 +11,15 @@
>>> #include
>>> #include
>>>
>>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS 0x6UL
>>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE 0x80UL
>>> +
>>> #ifdef CONFIG_ARM64
>>> #include
>>>
>>> -static struct mm_region bcm283x_mem_map[] = {
>>> +#define MAX_MAP_MAX_ENTRIES (4)
>> What stands the second 'MAX' for?
> a simple copy/paste issue. I will fix it.
>>> +
>>> +static struct mm_region bcm283x_mem_map[MAX_MAP_MAX_ENTRIES] = {
>>> {
>>> .virt = 0xUL,
>>> .phys = 0xUL,
>>> @@ -34,7 +39,7 @@ static struct mm_region bcm283x_mem_map[] = {
>>> }
>>> };
>>>
>>> -static struct mm_region bcm2711_mem_map[] = {
>>> +static struct mm_region bcm2711_mem_map[MAX_MAP_MAX_ENTRIES] = {
>>> {
>>> .virt = 0xUL,
>>> .phys = 0xUL,
>>> @@ -49,6 +54,13 @@ static struct mm_region bcm2711_mem_map[] = {
>>> PTE_BLOCK_NON_SHARE |
>>> PTE_BLOCK_PXN | PTE_BLOCK_UXN
>>> }, {
>> I'd prefer a comment instead of using the BCM2711_RPI4_PCIE_XHCI_MMIO_*
>> defines.
>
> Those defines are also used in ARM 32bit code.
>
>>> + .virt = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS> + .phys =
>>> BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
>>> + .size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE,
>>> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>>> +PTE_BLOCK_NON_SHARE |
>>> +PTE_BLOCK_PXN | PTE_BLOCK_UXN
>>> + }, {
>>> /* List terminator */
>>> 0,
>>> }
>>> @@ -71,7 +83,7 @@ static void _rpi_update_mem_map(struct mm_region *pd)
>>> {
>>> int i;
>>>
>>> - for (i = 0; i < 2; i++) {
>>> + for (i = 0; i < MAX_MAP_MAX_ENTRIES; i++) {
>> Variable mem_map points to bcm283x_mem_map which only holds two mm_region's
>> (plus list terminator). So we have an overflow here.
> Nope, I've changed the bcm283x_mem_map to be large enough, see the above
> diff.
>> I think we should just
>> define bcm2711_mem_map and bcm283x_mem_map with a fixed array size of 4 (see
>> comment on the define naming above).
>
> That's exactly what I did.
>
You are right, sorry for the noise!
Matthias
Re: [PATCH v2 06/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)
On 04/05/2020 14:45, Sylwester Nawrocki wrote:
> From: Marek Szyprowski
>
> Create a non-cacheable mapping for the 0x6 physical memory region,
> where MMIO registers for the PCIe XHCI controller are instantiated by the
> PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
> 32bit mode, this region is mapped at 0xff80 CPU virtual address.
>
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Sylwester Nawrocki
> ---
> Changes since v1:
> - none.
> ---
> arch/arm/mach-bcm283x/Kconfig | 1 +
> arch/arm/mach-bcm283x/include/mach/base.h | 7 +
> arch/arm/mach-bcm283x/init.c | 52
> +++
> 3 files changed, 60 insertions(+)
>
> diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
> index 00419bf..bcb7f1d 100644
> --- a/arch/arm/mach-bcm283x/Kconfig
> +++ b/arch/arm/mach-bcm283x/Kconfig
> @@ -36,6 +36,7 @@ config BCM2711_32B
> select BCM2711
> select ARMV7_LPAE
> select CPU_V7A
> + select PHYS_64BIT
>
> config BCM2711_64B
> bool "Broadcom BCM2711 SoC 64-bit support"
> diff --git a/arch/arm/mach-bcm283x/include/mach/base.h
> b/arch/arm/mach-bcm283x/include/mach/base.h
> index c4ae398..1d10dc9 100644
> --- a/arch/arm/mach-bcm283x/include/mach/base.h
> +++ b/arch/arm/mach-bcm283x/include/mach/base.h
> @@ -6,6 +6,13 @@
> #ifndef _BCM283x_BASE_H_
> #define _BCM283x_BASE_H_
>
> +#include
> +
> extern unsigned long rpi_bcm283x_base;
>
> +#ifdef CONFIG_ARMV7_LPAE
> +extern void *rpi4_phys_to_virt(phys_addr_t paddr);
> +#define phys_to_virt(x) rpi4_phys_to_virt(x)
> +#endif
> +
> #endif
> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
> index 6a748da..5d0d160 100644
> --- a/arch/arm/mach-bcm283x/init.c
> +++ b/arch/arm/mach-bcm283x/init.c
> @@ -145,6 +145,58 @@ int mach_cpu_init(void)
> }
>
> #ifdef CONFIG_ARMV7_LPAE
> +
> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT 0xff80UL
> +
> +void *rpi4_phys_to_virt(phys_addr_t paddr)
> +{
> + if (paddr >= BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS)
> + paddr = paddr - BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS +
> + BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT;
> + return (void *)(unsigned long)paddr;
> +}
> +
> +static void set_section_phys(unsigned int section, phys_addr_t phys,
> + enum dcache_option option)
> +{
> + u64 *page_table = (u64 *)gd->arch.tlb_addr;
> + /* Need to set the access flag to not fault */
> + u64 value = TTB_SECT_AP | TTB_SECT_AF;
> +
> + /* Add the page offset */
> + value |= (phys);
> +
> + /* Add caching bits */
> + value |= option;
> +
> + /* Set PTE */
> + page_table[section] = value;
> +}
> +
> +static void rpi4_create_pcie_xhci_mapping(void)
> +{
> + unsigned sect = BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT >> MMU_SECTION_SHIFT;
> + phys_addr_t phys_addr = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS;
> + unsigned int size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE;
> +
> + while (size) {
> + set_section_phys(sect, phys_addr, DCACHE_OFF);
> + sect++;
> + phys_addr += MMU_SECTION_SIZE;
> + size -= MMU_SECTION_SIZE;
> + }
Why can't we reuse mmu_set_region_dcache_behaviour()?
> +}
> +
> +void arm_init_domains(void)
> +{
> + /*
> + * Hijack this function to prepare a mappings for the PCIe MMIO
> + * region for the XHCI controller on RPi4 board.
> + * This code is called before enabling the MMU in ARM 32bit mode.
> + */
> + rpi4_create_pcie_xhci_mapping();
I think this indirection is not necessary.
Regards,
Matthias
> +}
> +
> void enable_caches(void)
> {
> dcache_enable();
>
Re: [PATCH v2 2/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware
On 05/05/2020 15:47, Nicolas Saenz Julienne wrote:
> On Tue, 2020-05-05 at 15:39 +0200, Matthias Brugger wrote:
>>
>> On 05/05/2020 14:53, Nicolas Saenz Julienne wrote:
>>> Hi Matthias,
>>>
>>> On Tue, 2020-05-05 at 14:15 +0200, Matthias Brugger wrote:
>>>> On 30/04/2020 15:04, Nicolas Saenz Julienne wrote:
>>>>> When needed, RPi4's co-processor (called VideoCore) has to be instructed
>>>>> to load VL805's firmware (the chip providing xHCI support). VideoCore's
>>>>> firmware expects the board's PCIe bus to be already configured in order
>>>>> for it to load the xHCI chip firmware. So we have to make sure this
>>>>> happens in between the PCIe configuration and xHCI startup.
>>>>>
>>>>> Introduce a callback in xhci_pci_probe() to run this platform specific
>>>>> routine.
>>>>>
>>>>> Signed-off-by: Nicolas Saenz Julienne
>>>>>
>>>>> ---
>>>>>
>>>>> Changes since v1:
>>>>> - Create callback
>>>>>
>>>>> board/raspberrypi/rpi/rpi.c | 12
>>>>> drivers/usb/host/xhci-pci.c | 6 ++
>>>>> include/usb/xhci.h | 3 +++
>>>>> 3 files changed, 21 insertions(+)
>>>>>
>>>>> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
>>>>> index e367ba3092..8aa78d1f48 100644
>>>>> --- a/board/raspberrypi/rpi/rpi.c
>>>>> +++ b/board/raspberrypi/rpi/rpi.c
>>>>> @@ -14,6 +14,7 @@
>>>>> #include
>>>>> #include
>>>>> #include
>>>>> +#include
>>>>> #include
>>>>> #include
>>>>> #include
>>>>> @@ -494,3 +495,14 @@ int ft_board_setup(void *blob, bd_t *bd)
>>>>>
>>>>> return 0;
>>>>> }
>>>>> +
>>>>> +#ifdef CONFIG_BCM2711
>>>>
>>>> This won't work with rpi_arm64_defconfig.
>>>> Can't we just evaluate at runtime if we need to do anything in
>>>> xhci_pci_fixup.
>>>
>>> I can't see why, who is going to call xhci_pci_probe() in RPi3?
>>>
>>
>> If you do make rpi_arm64_defconfig and inspect the .config, you will see that
>> CONFIG_BCM2711 is not defined, so this code won't be called on RPi4.
>
> Oh! Understood.
>
> Well, given that only xhci_pci_probe() is called if we're running on RPi4, I
> think I can disregard those defines altogether. I'll double-check that.
>
Yes but from my understanding we only need to call the function on newer
revisions of RPi4. Does it have any side effect on older revisions, e.g. we get
error messages (see below)?
[...]>>>> I wonder if the newer RPi4 have also a newer revision ID (see
>>>> get_board_rev).
>>>> If
>>>> so we could add another bool to struct rpi_model which will indicate us if
>>>> we
>>>> need to notify VideoCore about vl805's firmware.
>>>>
>>>>> +void xhci_pci_fixup(struct udevice *dev)
>>>>> +{
>>>>> + int ret;
>>>>> +
>>>>> + ret = bcm2711_notify_vl805_reset();
>>>>> + if (ret)
>>>>> + printf("RPI: Failed to notify VideoCore about vl805's
>>>>> firmware\n");
We already have
printf("bcm2711: Faild to load vl805's firmware, %d\n", ret); in
bcm2711_notify_vl805_reset(). Do we really need two error messages?
Regards,
Matthias
>>>>> +}
>>>>> +#endif
>>>>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>>>>> index c1f60da541..1285dde1ef 100644
>>>>> --- a/drivers/usb/host/xhci-pci.c
>>>>> +++ b/drivers/usb/host/xhci-pci.c
>>>>> @@ -11,6 +11,10 @@
>>>>> #include
>>>>> #include
>>>>>
>>>>> +__weak void xhci_pci_fixup(struct udevice *dev)
>>>>> +{
>>>>> +}
>>>>> +
>>>>> static void xhci_pci_init(struct udevice *dev, struct xhci_hccr
>>>>> **ret_hccr,
>>>>> struct xhci_hcor **ret_hcor)
>>>>> {
>>>>> @@ -40,6 +44,8 @@ static int xhci_pci_probe(struct udevice *dev)
>>>>> struct xhci_hccr *hccr;
>>>>> struct xhci_hcor *hcor;
>>>>>
>>>>> + xhci_pci_fixup(dev);
>>>>> +
>>>>> xhci_pci_init(dev, &hccr, &hcor);
>>>>>
>>>>> return xhci_register(dev, hccr, hcor);
>>>>> diff --git a/include/usb/xhci.h b/include/usb/xhci.h
>>>>> index c16106a2fc..57feed7603 100644
>>>>> --- a/include/usb/xhci.h
>>>>> +++ b/include/usb/xhci.h
>>>>> @@ -16,6 +16,7 @@
>>>>> #ifndef HOST_XHCI_H_
>>>>> #define HOST_XHCI_H_
>>>>>
>>>>> +#include
>>>>> #include
>>>>> #include
>>>>> #include
>>>>> @@ -1281,4 +1282,6 @@ extern struct dm_usb_ops xhci_usb_ops;
>>>>>
>>>>> struct xhci_ctrl *xhci_get_ctrl(struct usb_device *udev);
>>>>>
>>>>> +extern void xhci_pci_fixup(struct udevice *dev);
>>>>> +
>>>>> #endif /* HOST_XHCI_H_ */
>>>>>
>
Re: [PATCH] config: Enable USB Keyboard support on RPi4
On 05/05/2020 16:51, Nicolas Saenz Julienne wrote: > Supporting USB keyboards out of the box is both handy for development > and production. Notably if u-boot is used to boot into GRUB. > > Signed-off-by: Nicolas Saenz Julienne > > --- > > Note that rpi_arm64_defconfig already supports USB keyboard. This is to > be applied on top of Sylwester Nawrocki's PCIe/xHCI on RPi4 series. > > configs/rpi_4_32b_defconfig | 1 + > configs/rpi_4_defconfig | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig > index dd7da1cf06..9c5ad7684e 100644 > --- a/configs/rpi_4_32b_defconfig > +++ b/configs/rpi_4_32b_defconfig > @@ -42,6 +42,7 @@ CONFIG_DM_USB=y > CONFIG_DM_USB_GADGET=y > CONFIG_USB_XHCI_HCD=y > CONFIG_USB_XHCI_PCI=y > +CONFIG_USB_KEYBOARD=y > CONFIG_USB_GADGET=y > CONFIG_USB_GADGET_MANUFACTURER="FSL" > CONFIG_USB_GADGET_VENDOR_NUM=0x0525 It seems we are missing CONFIG_SYS_STDIO_DEREGISTER=y at least for me without this, U-Boot does not build. Regards, Matthias > diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig > index 6eeec4592e..1a92cd637e 100644 > --- a/configs/rpi_4_defconfig > +++ b/configs/rpi_4_defconfig > @@ -42,6 +42,7 @@ CONFIG_DM_USB=y > CONFIG_DM_USB_GADGET=y > CONFIG_USB_XHCI_HCD=y > CONFIG_USB_XHCI_PCI=y > +CONFIG_USB_KEYBOARD=y > CONFIG_USB_GADGET=y > CONFIG_USB_GADGET_MANUFACTURER="FSL" > CONFIG_USB_GADGET_VENDOR_NUM=0x0525 >
Re: [PATCH] config: Enable USB Keyboard support on RPi4
On 08/05/2020 18:41, Sylwester Nawrocki wrote: > Hi Matthias, > > On 08.05.2020 17:55, Matthias Brugger wrote: >> It seems we are missing >> CONFIG_SYS_STDIO_DEREGISTER=y >> at least for me without this, U-Boot does not build. > > Isn't it selected by USB_KEYBOARD? I also had related build issues > which disappeared after running "make clean". > Correct. Sorry for the noise. Matthias
Re: [PATCH v2 06/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)
Adding Tom as he is the arm maintainer.
On 04/05/2020 14:45, Sylwester Nawrocki wrote:
> From: Marek Szyprowski
>
> Create a non-cacheable mapping for the 0x6 physical memory region,
> where MMIO registers for the PCIe XHCI controller are instantiated by the
> PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
> 32bit mode, this region is mapped at 0xff80 CPU virtual address.
>
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Sylwester Nawrocki
> ---
> Changes since v1:
> - none.
> ---
> arch/arm/mach-bcm283x/Kconfig | 1 +
> arch/arm/mach-bcm283x/include/mach/base.h | 7 +
> arch/arm/mach-bcm283x/init.c | 52
> +++
> 3 files changed, 60 insertions(+)
>
> diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
> index 00419bf..bcb7f1d 100644
> --- a/arch/arm/mach-bcm283x/Kconfig
> +++ b/arch/arm/mach-bcm283x/Kconfig
> @@ -36,6 +36,7 @@ config BCM2711_32B
> select BCM2711
> select ARMV7_LPAE
> select CPU_V7A
> + select PHYS_64BIT
>
> config BCM2711_64B
> bool "Broadcom BCM2711 SoC 64-bit support"
> diff --git a/arch/arm/mach-bcm283x/include/mach/base.h
> b/arch/arm/mach-bcm283x/include/mach/base.h
> index c4ae398..1d10dc9 100644
> --- a/arch/arm/mach-bcm283x/include/mach/base.h
> +++ b/arch/arm/mach-bcm283x/include/mach/base.h
> @@ -6,6 +6,13 @@
> #ifndef _BCM283x_BASE_H_
> #define _BCM283x_BASE_H_
>
> +#include
> +
> extern unsigned long rpi_bcm283x_base;
>
> +#ifdef CONFIG_ARMV7_LPAE
> +extern void *rpi4_phys_to_virt(phys_addr_t paddr);
> +#define phys_to_virt(x) rpi4_phys_to_virt(x)
> +#endif
> +
> #endif
> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
> index 6a748da..5d0d160 100644
> --- a/arch/arm/mach-bcm283x/init.c
> +++ b/arch/arm/mach-bcm283x/init.c
> @@ -145,6 +145,58 @@ int mach_cpu_init(void)
> }
>
> #ifdef CONFIG_ARMV7_LPAE
> +
> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT 0xff80UL
> +
> +void *rpi4_phys_to_virt(phys_addr_t paddr)
> +{
> + if (paddr >= BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS)
> + paddr = paddr - BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS +
> + BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT;
> + return (void *)(unsigned long)paddr;
I think for this cases we have addrmap_phys_to_virt() which up to now is only
used by powerpc.
> +}
> +
> +static void set_section_phys(unsigned int section, phys_addr_t phys,
> + enum dcache_option option)
> +{
> + u64 *page_table = (u64 *)gd->arch.tlb_addr;
> + /* Need to set the access flag to not fault */
> + u64 value = TTB_SECT_AP | TTB_SECT_AF;
> +
> + /* Add the page offset */
> + value |= (phys);
> +
> + /* Add caching bits */
> + value |= option;
> +
> + /* Set PTE */
> + page_table[section] = value;
> +}
> +
> +static void rpi4_create_pcie_xhci_mapping(void)
> +{
> + unsigned sect = BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT >> MMU_SECTION_SHIFT;
> + phys_addr_t phys_addr = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS;
> + unsigned int size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE;
> +
> + while (size) {
> + set_section_phys(sect, phys_addr, DCACHE_OFF);
> + sect++;
> + phys_addr += MMU_SECTION_SIZE;
> + size -= MMU_SECTION_SIZE;
> + }
> +}
I wonder if we can't do all this in the pcie driver probe function. Maybe we can
create a new function like mmu_set_region_dcache_behaviour_phys which allows us
to update a mapping that's not 1:1.
Tom what do you think?
Regards,
Matthias
> +
> +void arm_init_domains(void)
> +{
> + /*
> + * Hijack this function to prepare a mappings for the PCIe MMIO
> + * region for the XHCI controller on RPi4 board.
> + * This code is called before enabling the MMU in ARM 32bit mode.
> + */
> + rpi4_create_pcie_xhci_mapping();
> +}
> +
> void enable_caches(void)
> {
> dcache_enable();
>
Re: raspberrypi cm3 v2019.07 not working
Hi Marek,
On 08/05/2020 21:52, Belisko Marek wrote:
> On Wed, May 6, 2020 at 11:02 PM Belisko Marek wrote:
>>
>> On Tue, May 5, 2020 at 10:18 PM Belisko Marek
>> wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to run 2019.07 u-boot on raspberrypi cm3 module but I got
>>> no feedback on console. When used 2018.01 it boots fine. Probably I
>>> need to do git bisect but maybe someone have some idea or experience
>>> what can cause that. Thanks.
>> I give a try 2020.01 and I got only this:
>> U-Boot 2020.01 (May 06 2020 - 20:09:45 +)
>>
>> DRAM: 948 MiB
>> RPI Compute Module 3 (0xa020a0)
>>
>> I'll try to debug it and let you know.
> Debug messages shows this:
> https://pastebin.com/2SwNzrb1
>
> I tried to debug but I have no clue what is going one there.
>
> Also u-boot 2019.07 is not working at all on cm3 due to this commit
> (after bisect when reverted u-boot start working again):
> 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
> tree sources to Linux 5.1-rc6 state
>
> Any ideas hint how to resolve this issue? Thanks.
>
Can you try to cherry-pick the following two patches to your tree:
5051377a0b ("arm: dts: bcm283x: Rename U-Boot file")
89e47e8eb6 ("fdt: fix bcm283x dm-pre-reloc definitions")
Regards,
Matthias
Re: [PATCH] rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY
Hi Corentin, On 24/04/2020 14:51, LABBE Corentin wrote: > On Tue, Mar 31, 2020 at 12:26:35PM +, Corentin Labbe wrote: >> As discussed at >> https://lore.kernel.org/linux-arm-kernel/b726290c-1038-3771-5187-6ac370bc9...@arm.com/T/ >> the defconfig for rpi4 miss CONFIG_ARCH_FIXUP_FDT_MEMORY. >> Without it, booting with an initrd fail. >> >> Signed-off-by: Corentin Labbe >> --- >> configs/rpi_4_defconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig >> index 6d148dab07..8540b3c927 100644 >> --- a/configs/rpi_4_defconfig >> +++ b/configs/rpi_4_defconfig >> @@ -7,7 +7,7 @@ CONFIG_ENV_SIZE=0x4000 >> CONFIG_NR_DRAM_BANKS=2 >> CONFIG_DISTRO_DEFAULTS=y >> CONFIG_OF_BOARD_SETUP=y >> -# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set >> +CONFIG_ARCH_FIXUP_FDT_MEMORY=y >> CONFIG_MISC_INIT_R=y >> # CONFIG_DISPLAY_CPUINFO is not set >> # CONFIG_DISPLAY_BOARDINFO is not set >> -- > Patch looks good, but is there any reason why you don't enable it for rpi_4_32b_defconfig and rpi_arm64_defconfig? Regards, Matthias
Re: [PATCH] rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY
On 09/05/2020 01:18, Matthias Brugger wrote: > Hi Corentin, > > On 24/04/2020 14:51, LABBE Corentin wrote: >> On Tue, Mar 31, 2020 at 12:26:35PM +, Corentin Labbe wrote: >>> As discussed at >>> https://lore.kernel.org/linux-arm-kernel/b726290c-1038-3771-5187-6ac370bc9...@arm.com/T/ >>> the defconfig for rpi4 miss CONFIG_ARCH_FIXUP_FDT_MEMORY. >>> Without it, booting with an initrd fail. >>> >>> Signed-off-by: Corentin Labbe >>> --- >>> configs/rpi_4_defconfig | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig >>> index 6d148dab07..8540b3c927 100644 >>> --- a/configs/rpi_4_defconfig >>> +++ b/configs/rpi_4_defconfig >>> @@ -7,7 +7,7 @@ CONFIG_ENV_SIZE=0x4000 >>> CONFIG_NR_DRAM_BANKS=2 >>> CONFIG_DISTRO_DEFAULTS=y >>> CONFIG_OF_BOARD_SETUP=y >>> -# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set >>> +CONFIG_ARCH_FIXUP_FDT_MEMORY=y >>> CONFIG_MISC_INIT_R=y >>> # CONFIG_DISPLAY_CPUINFO is not set >>> # CONFIG_DISPLAY_BOARDINFO is not set >>> -- >> > > Patch looks good, but is there any reason why you don't enable it for > rpi_4_32b_defconfig and rpi_arm64_defconfig? > And please add me to the recipients list, otherwise this patches most probably get lost. Regards, Matthias
Re: [PATCH v2 06/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)
On 11/05/2020 21:44, Tom Rini wrote:
> On Fri, May 08, 2020 at 11:26:36PM +0200, Matthias Brugger wrote:
>> Adding Tom as he is the arm maintainer.
>>
>> On 04/05/2020 14:45, Sylwester Nawrocki wrote:
>>> From: Marek Szyprowski
>>>
>>> Create a non-cacheable mapping for the 0x6 physical memory region,
>>> where MMIO registers for the PCIe XHCI controller are instantiated by the
>>> PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
>>> 32bit mode, this region is mapped at 0xff80 CPU virtual address.
>>>
>>> Signed-off-by: Marek Szyprowski
>>> Signed-off-by: Sylwester Nawrocki
>>> ---
>>> Changes since v1:
>>> - none.
>>> ---
>>> arch/arm/mach-bcm283x/Kconfig | 1 +
>>> arch/arm/mach-bcm283x/include/mach/base.h | 7 +
>>> arch/arm/mach-bcm283x/init.c | 52
>>> +++
>>> 3 files changed, 60 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
>>> index 00419bf..bcb7f1d 100644
>>> --- a/arch/arm/mach-bcm283x/Kconfig
>>> +++ b/arch/arm/mach-bcm283x/Kconfig
>>> @@ -36,6 +36,7 @@ config BCM2711_32B
>>> select BCM2711
>>> select ARMV7_LPAE
>>> select CPU_V7A
>>> + select PHYS_64BIT
>>>
>>> config BCM2711_64B
>>> bool "Broadcom BCM2711 SoC 64-bit support"
>>> diff --git a/arch/arm/mach-bcm283x/include/mach/base.h
>>> b/arch/arm/mach-bcm283x/include/mach/base.h
>>> index c4ae398..1d10dc9 100644
>>> --- a/arch/arm/mach-bcm283x/include/mach/base.h
>>> +++ b/arch/arm/mach-bcm283x/include/mach/base.h
>>> @@ -6,6 +6,13 @@
>>> #ifndef _BCM283x_BASE_H_
>>> #define _BCM283x_BASE_H_
>>>
>>> +#include
>>> +
>>> extern unsigned long rpi_bcm283x_base;
>>>
>>> +#ifdef CONFIG_ARMV7_LPAE
>>> +extern void *rpi4_phys_to_virt(phys_addr_t paddr);
>>> +#define phys_to_virt(x) rpi4_phys_to_virt(x)
>>> +#endif
>>> +
>>> #endif
>>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>>> index 6a748da..5d0d160 100644
>>> --- a/arch/arm/mach-bcm283x/init.c
>>> +++ b/arch/arm/mach-bcm283x/init.c
>>> @@ -145,6 +145,58 @@ int mach_cpu_init(void)
>>> }
>>>
>>> #ifdef CONFIG_ARMV7_LPAE
>>> +
>>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT 0xff80UL
>>> +
>>> +void *rpi4_phys_to_virt(phys_addr_t paddr)
>>> +{
>>> + if (paddr >= BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS)
>>> + paddr = paddr - BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS +
>>> + BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT;
>>> + return (void *)(unsigned long)paddr;
>>
>> I think for this cases we have addrmap_phys_to_virt() which up to now is only
>> used by powerpc.
>>
>>> +}
>>> +
>>> +static void set_section_phys(unsigned int section, phys_addr_t phys,
>>> +enum dcache_option option)
>>> +{
>>> + u64 *page_table = (u64 *)gd->arch.tlb_addr;
>>> + /* Need to set the access flag to not fault */
>>> + u64 value = TTB_SECT_AP | TTB_SECT_AF;
>>> +
>>> + /* Add the page offset */
>>> + value |= (phys);
>>> +
>>> + /* Add caching bits */
>>> + value |= option;
>>> +
>>> + /* Set PTE */
>>> + page_table[section] = value;
>>> +}
>>> +
>>> +static void rpi4_create_pcie_xhci_mapping(void)
>>> +{
>>> + unsigned sect = BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT >> MMU_SECTION_SHIFT;
>>> + phys_addr_t phys_addr = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS;
>>> + unsigned int size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE;
>>> +
>>> + while (size) {
>>> + set_section_phys(sect, phys_addr, DCACHE_OFF);
>>> + sect++;
>>> + phys_addr += MMU_SECTION_SIZE;
>>> + size -= MMU_SECTION_SIZE;
>>> + }
>>> +}
>>
>> I wonder if we can't do all this in the pcie driver probe function. Maybe we
>> can
>> create a new function like mmu_set_region_dcache_behaviour_phys which allows
>> us
>> to update a mapping that's not 1:1.
>>
>> Tom what do you think?
>
> I think a harder look at how PowerPC handled this situation is in order,
> and then following / extending that path is in order.
>
Thanks Tom for the feedback.
Sylwester, I propose to split the series in two. One for adding the driver to
64-bit U-Boot and another one to add support for rpi_4_32b_defconfig. This way
we could get the driver merged for 2020.07 for sure, while 32-bit parts could
take more cycles to be ready. What do you think?
Regards,
Matthias
Re: [PATCH] configs: rpi_arm64: sync env size with rpi_{3,4}_defconfig
On 05/05/2020 12:09, Marek Szyprowski wrote: > Use the same environment size as the configs dedicated for rpi3 and rpi4. > This allows to switch between the builds and not to loose the settings > stored on the SD card. > > Signed-off-by: Marek Szyprowski queued for 2020.07 Thanks! > --- > configs/rpi_arm64_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig > index 926dfc3..7c59400 100644 > --- a/configs/rpi_arm64_defconfig > +++ b/configs/rpi_arm64_defconfig > @@ -3,6 +3,7 @@ CONFIG_ARCH_BCM283X=y > CONFIG_SYS_TEXT_BASE=0x0008 > CONFIG_TARGET_RPI_ARM64=y > CONFIG_SYS_MALLOC_F_LEN=0x2000 > +CONFIG_ENV_SIZE=0x4000 > CONFIG_NR_DRAM_BANKS=2 > CONFIG_DISTRO_DEFAULTS=y > CONFIG_OF_BOARD_SETUP=y >
Re: [Patch V4 0/3] Support SDMA mode on RPI4 target - 32bit
On 27/03/2020 05:07, Jaehoon Chung wrote: > RPI4's SDHCI controller is supported SDMA mode. (Checked on kernel side) > But It doesn't use on u-boot side. Then it's too slow about read/write > performance. > This patchset is supported SDMA mode on RPI4 target(32/64bit). > - Tested on RPI4 1GB/2GB/4GB target Whole series queued for v2020.07 Thanks a lot! Matthias > > Read/write time about 8MB file > Before > - Read : 1.472 seconds > - Write : 4.690 seconds > After > - Read : 0.359 seconds > - Write : 0.574 seconds > > This patch is based on my RFC's patches.RPI4's SDHCI controller is supported > SDMA mode. (Checked on kernel side) > But It doesn't use on u-boot side. Then it's too slow about read/write > performance. > This patchset is supported SDMA mode on RPI4 target(32bit). > - I didn't test on RPI4 64bit. > > Read/write time about 8MB file > Before > - Read : 1.472 seconds > - Write : 4.690 seconds > After > - Read : 0.359 seconds > - Write : 0.574 seconds > > Changelog on V4 > - Enable SDMA in rpi4_defconfig for 64bit > > Changelog on V3 > - Rebased on latest u-boot-mmc > > Changelog on V2 > - Keep printf message instead of debug > - Add Peng's Reviewed-by tag > > > Jaehoon Chung (3): > mmc: sdhci: use phys2bus macro when dma address is accessed > mmc: sdhci: not return error when SDMA is not supported > configs: rpi_4 : enable SDHCI_SDMA config > > configs/rpi_4_32b_defconfig | 1 + > configs/rpi_4_defconfig | 1 + > drivers/mmc/sdhci.c | 13 +++-- > 3 files changed, 9 insertions(+), 6 deletions(-) >
Re: [PATCH] rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY
Hi Corentin, On 09/05/2020 01:25, Matthias Brugger wrote: > On 09/05/2020 01:18, Matthias Brugger wrote: >> Hi Corentin, >> >> On 24/04/2020 14:51, LABBE Corentin wrote: >>> On Tue, Mar 31, 2020 at 12:26:35PM +, Corentin Labbe wrote: >>>> As discussed at >>>> https://lore.kernel.org/linux-arm-kernel/b726290c-1038-3771-5187-6ac370bc9...@arm.com/T/ >>>> the defconfig for rpi4 miss CONFIG_ARCH_FIXUP_FDT_MEMORY. >>>> Without it, booting with an initrd fail. >>>> >>>> Signed-off-by: Corentin Labbe >>>> --- >>>> configs/rpi_4_defconfig | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig >>>> index 6d148dab07..8540b3c927 100644 >>>> --- a/configs/rpi_4_defconfig >>>> +++ b/configs/rpi_4_defconfig >>>> @@ -7,7 +7,7 @@ CONFIG_ENV_SIZE=0x4000 >>>> CONFIG_NR_DRAM_BANKS=2 >>>> CONFIG_DISTRO_DEFAULTS=y >>>> CONFIG_OF_BOARD_SETUP=y >>>> -# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set >>>> +CONFIG_ARCH_FIXUP_FDT_MEMORY=y >>>> CONFIG_MISC_INIT_R=y >>>> # CONFIG_DISPLAY_CPUINFO is not set >>>> # CONFIG_DISPLAY_BOARDINFO is not set >>>> -- >>> >> >> Patch looks good, but is there any reason why you don't enable it for >> rpi_4_32b_defconfig and rpi_arm64_defconfig? >> > > And please add me to the recipients list, otherwise this patches most probably > get lost. > Are you planning to send a new version of the patch which enables the option for all configs? Regards, Matthias
Re: raspberrypi cm3 v2019.07 not working
On 12/05/2020 11:15, Belisko Marek wrote:
> On Fri, May 8, 2020 at 11:39 PM Belisko Marek wrote:
>>
>> Hi Matthias,
>>
>> On Fri, May 8, 2020 at 11:28 PM Matthias Brugger wrote:
>>>
>>> Hi Marek,
>>>
>>> On 08/05/2020 21:52, Belisko Marek wrote:
>>>> On Wed, May 6, 2020 at 11:02 PM Belisko Marek
>>>> wrote:
>>>>>
>>>>> On Tue, May 5, 2020 at 10:18 PM Belisko Marek
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to run 2019.07 u-boot on raspberrypi cm3 module but I got
>>>>>> no feedback on console. When used 2018.01 it boots fine. Probably I
>>>>>> need to do git bisect but maybe someone have some idea or experience
>>>>>> what can cause that. Thanks.
>>>>> I give a try 2020.01 and I got only this:
>>>>> U-Boot 2020.01 (May 06 2020 - 20:09:45 +)
>>>>>
>>>>> DRAM: 948 MiB
>>>>> RPI Compute Module 3 (0xa020a0)
>>>>>
>>>>> I'll try to debug it and let you know.
>>>> Debug messages shows this:
>>>> https://pastebin.com/2SwNzrb1
>>>>
>>>> I tried to debug but I have no clue what is going one there.
>>>>
>>>> Also u-boot 2019.07 is not working at all on cm3 due to this commit
>>>> (after bisect when reverted u-boot start working again):
>>>> 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
>>>> tree sources to Linux 5.1-rc6 state
>>>>
>>>> Any ideas hint how to resolve this issue? Thanks.
>>>>
>>>
>>> Can you try to cherry-pick the following two patches to your tree:
>>> 5051377a0b ("arm: dts: bcm283x: Rename U-Boot file")
>>> 89e47e8eb6 ("fdt: fix bcm283x dm-pre-reloc definitions")
>> But those are present in 2020.01 and this version at least print
>> something to console but stuck somewhere (pls see pastebin log with
>> debug enabled)
>> I prefer to run 2020.01 ;). Thanks.
> Any other stuff I can try to make it working in 2020.01? Could that be
> firmware issue somehow? Thanks.
Sorry I didn't realized that your first try was with 2020.01.
I just confirmed that it acutually does not boot. As a shortcut, do you know
which is the last working version of U-Boot?
Regards,
Matthias
Re: raspberrypi cm3 v2019.07 not working
On 12/05/2020 13:00, Belisko Marek wrote:
> On Tue, May 12, 2020 at 12:51 PM Matthias Brugger wrote:
>>
>>
>>
>> On 12/05/2020 11:15, Belisko Marek wrote:
>>> On Fri, May 8, 2020 at 11:39 PM Belisko Marek
>>> wrote:
>>>>
>>>> Hi Matthias,
>>>>
>>>> On Fri, May 8, 2020 at 11:28 PM Matthias Brugger wrote:
>>>>>
>>>>> Hi Marek,
>>>>>
>>>>> On 08/05/2020 21:52, Belisko Marek wrote:
>>>>>> On Wed, May 6, 2020 at 11:02 PM Belisko Marek
>>>>>> wrote:
>>>>>>>
>>>>>>> On Tue, May 5, 2020 at 10:18 PM Belisko Marek
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm trying to run 2019.07 u-boot on raspberrypi cm3 module but I got
>>>>>>>> no feedback on console. When used 2018.01 it boots fine. Probably I
>>>>>>>> need to do git bisect but maybe someone have some idea or experience
>>>>>>>> what can cause that. Thanks.
>>>>>>> I give a try 2020.01 and I got only this:
>>>>>>> U-Boot 2020.01 (May 06 2020 - 20:09:45 +)
>>>>>>>
>>>>>>> DRAM: 948 MiB
>>>>>>> RPI Compute Module 3 (0xa020a0)
>>>>>>>
>>>>>>> I'll try to debug it and let you know.
>>>>>> Debug messages shows this:
>>>>>> https://pastebin.com/2SwNzrb1
>>>>>>
>>>>>> I tried to debug but I have no clue what is going one there.
>>>>>>
>>>>>> Also u-boot 2019.07 is not working at all on cm3 due to this commit
>>>>>> (after bisect when reverted u-boot start working again):
>>>>>> 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
>>>>>> tree sources to Linux 5.1-rc6 state
>>>>>>
>>>>>> Any ideas hint how to resolve this issue? Thanks.
>>>>>>
>>>>>
>>>>> Can you try to cherry-pick the following two patches to your tree:
>>>>> 5051377a0b ("arm: dts: bcm283x: Rename U-Boot file")
>>>>> 89e47e8eb6 ("fdt: fix bcm283x dm-pre-reloc definitions")
>>>> But those are present in 2020.01 and this version at least print
>>>> something to console but stuck somewhere (pls see pastebin log with
>>>> debug enabled)
>>>> I prefer to run 2020.01 ;). Thanks.
>>> Any other stuff I can try to make it working in 2020.01? Could that be
>>> firmware issue somehow? Thanks.
>>
>> Sorry I didn't realized that your first try was with 2020.01.
>> I just confirmed that it acutually does not boot. As a shortcut, do you know
>> which is the last working version of U-Boot?
> v2019.07 with reverted commit :
> 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
> tree sources to Linux 5.1-rc6 state
> work fine. Without revert it shows anything on console. So something
> between 2019.07..2020.01 mus fix it partially ;)
I just tired v2020.04 and it works for me. Would you mind testing that on your
end?
Do you have a hard dependency on v2020.01?
Regards,
Matthias
Re: [PATCH] rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY
On 12/05/2020 13:34, LABBE Corentin wrote: > On Tue, May 12, 2020 at 12:17:25PM +0200, Matthias Brugger wrote: >> Hi Corentin, >> >> On 09/05/2020 01:25, Matthias Brugger wrote: >>> On 09/05/2020 01:18, Matthias Brugger wrote: >>>> Hi Corentin, >>>> >>>> On 24/04/2020 14:51, LABBE Corentin wrote: >>>>> On Tue, Mar 31, 2020 at 12:26:35PM +, Corentin Labbe wrote: >>>>>> As discussed at >>>>>> https://lore.kernel.org/linux-arm-kernel/b726290c-1038-3771-5187-6ac370bc9...@arm.com/T/ >>>>>> the defconfig for rpi4 miss CONFIG_ARCH_FIXUP_FDT_MEMORY. >>>>>> Without it, booting with an initrd fail. >>>>>> >>>>>> Signed-off-by: Corentin Labbe >>>>>> --- >>>>>> configs/rpi_4_defconfig | 2 +- >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig >>>>>> index 6d148dab07..8540b3c927 100644 >>>>>> --- a/configs/rpi_4_defconfig >>>>>> +++ b/configs/rpi_4_defconfig >>>>>> @@ -7,7 +7,7 @@ CONFIG_ENV_SIZE=0x4000 >>>>>> CONFIG_NR_DRAM_BANKS=2 >>>>>> CONFIG_DISTRO_DEFAULTS=y >>>>>> CONFIG_OF_BOARD_SETUP=y >>>>>> -# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set >>>>>> +CONFIG_ARCH_FIXUP_FDT_MEMORY=y >>>>>> CONFIG_MISC_INIT_R=y >>>>>> # CONFIG_DISPLAY_CPUINFO is not set >>>>>> # CONFIG_DISPLAY_BOARDINFO is not set >>>>>> -- >>>>> >>>> >>>> Patch looks good, but is there any reason why you don't enable it for >>>> rpi_4_32b_defconfig and rpi_arm64_defconfig? >>>> >>> >>> And please add me to the recipients list, otherwise this patches most >>> probably >>> get lost. >>> >> >> Are you planning to send a new version of the patch which enables the option >> for >> all configs? >> > > Yes, I will. > But note that I didnt tested rpi_4_32b_defconfig. > And I am currently unable to test it. > If you want it to be tested, could you apply this patch as is, and I will > submit the rpi_4_32b_defconfig later. > Ok, please don't forget to submit/test configs/rpi_arm64_defconfig as well. Regards, Matthias
Re: raspberrypi cm3 v2019.07 not working
On 12/05/2020 13:36, Belisko Marek wrote:
> On Tue, May 12, 2020 at 1:16 PM Matthias Brugger
> wrote:
>>
>>
>>
>> On 12/05/2020 13:00, Belisko Marek wrote:
>>> On Tue, May 12, 2020 at 12:51 PM Matthias Brugger wrote:
>>>>
>>>>
>>>>
>>>> On 12/05/2020 11:15, Belisko Marek wrote:
>>>>> On Fri, May 8, 2020 at 11:39 PM Belisko Marek
>>>>> wrote:
>>>>>>
>>>>>> Hi Matthias,
>>>>>>
>>>>>> On Fri, May 8, 2020 at 11:28 PM Matthias Brugger
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Marek,
>>>>>>>
>>>>>>> On 08/05/2020 21:52, Belisko Marek wrote:
>>>>>>>> On Wed, May 6, 2020 at 11:02 PM Belisko Marek
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Tue, May 5, 2020 at 10:18 PM Belisko Marek
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I'm trying to run 2019.07 u-boot on raspberrypi cm3 module but I got
>>>>>>>>>> no feedback on console. When used 2018.01 it boots fine. Probably I
>>>>>>>>>> need to do git bisect but maybe someone have some idea or experience
>>>>>>>>>> what can cause that. Thanks.
>>>>>>>>> I give a try 2020.01 and I got only this:
>>>>>>>>> U-Boot 2020.01 (May 06 2020 - 20:09:45 +)
>>>>>>>>>
>>>>>>>>> DRAM: 948 MiB
>>>>>>>>> RPI Compute Module 3 (0xa020a0)
>>>>>>>>>
>>>>>>>>> I'll try to debug it and let you know.
>>>>>>>> Debug messages shows this:
>>>>>>>> https://pastebin.com/2SwNzrb1
>>>>>>>>
>>>>>>>> I tried to debug but I have no clue what is going one there.
>>>>>>>>
>>>>>>>> Also u-boot 2019.07 is not working at all on cm3 due to this commit
>>>>>>>> (after bisect when reverted u-boot start working again):
>>>>>>>> 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
>>>>>>>> tree sources to Linux 5.1-rc6 state
>>>>>>>>
>>>>>>>> Any ideas hint how to resolve this issue? Thanks.
>>>>>>>>
>>>>>>>
>>>>>>> Can you try to cherry-pick the following two patches to your tree:
>>>>>>> 5051377a0b ("arm: dts: bcm283x: Rename U-Boot file")
>>>>>>> 89e47e8eb6 ("fdt: fix bcm283x dm-pre-reloc definitions")
>>>>>> But those are present in 2020.01 and this version at least print
>>>>>> something to console but stuck somewhere (pls see pastebin log with
>>>>>> debug enabled)
>>>>>> I prefer to run 2020.01 ;). Thanks.
>>>>> Any other stuff I can try to make it working in 2020.01? Could that be
>>>>> firmware issue somehow? Thanks.
>>>>
>>>> Sorry I didn't realized that your first try was with 2020.01.
>>>> I just confirmed that it acutually does not boot. As a shortcut, do you
>>>> know
>>>> which is the last working version of U-Boot?
>>> v2019.07 with reverted commit :
>>> 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
>>> tree sources to Linux 5.1-rc6 state
>>> work fine. Without revert it shows anything on console. So something
>>> between 2019.07..2020.01 mus fix it partially ;)
>>
>> I just tired v2020.04 and it works for me. Would you mind testing that on
>> your end?
> OK I'll give a try and try to bisect between 2020.01 and 2020.04. I
> have dependency on 2020.01 as I integrate mender
> and then use this version.
I'm on that no need for you to do it.
Regards,
Matthias
Re: raspberrypi cm3 v2019.07 not working
On 12/05/2020 13:39, Matthias Brugger wrote:
>
>
> On 12/05/2020 13:36, Belisko Marek wrote:
>> On Tue, May 12, 2020 at 1:16 PM Matthias Brugger
>> wrote:
>>>
>>>
>>>
>>> On 12/05/2020 13:00, Belisko Marek wrote:
>>>> On Tue, May 12, 2020 at 12:51 PM Matthias Brugger
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 12/05/2020 11:15, Belisko Marek wrote:
>>>>>> On Fri, May 8, 2020 at 11:39 PM Belisko Marek
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Matthias,
>>>>>>>
>>>>>>> On Fri, May 8, 2020 at 11:28 PM Matthias Brugger
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Marek,
>>>>>>>>
>>>>>>>> On 08/05/2020 21:52, Belisko Marek wrote:
>>>>>>>>> On Wed, May 6, 2020 at 11:02 PM Belisko Marek
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Tue, May 5, 2020 at 10:18 PM Belisko Marek
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I'm trying to run 2019.07 u-boot on raspberrypi cm3 module but I got
>>>>>>>>>>> no feedback on console. When used 2018.01 it boots fine. Probably I
>>>>>>>>>>> need to do git bisect but maybe someone have some idea or experience
>>>>>>>>>>> what can cause that. Thanks.
>>>>>>>>>> I give a try 2020.01 and I got only this:
>>>>>>>>>> U-Boot 2020.01 (May 06 2020 - 20:09:45 +)
>>>>>>>>>>
>>>>>>>>>> DRAM: 948 MiB
>>>>>>>>>> RPI Compute Module 3 (0xa020a0)
>>>>>>>>>>
>>>>>>>>>> I'll try to debug it and let you know.
>>>>>>>>> Debug messages shows this:
>>>>>>>>> https://pastebin.com/2SwNzrb1
>>>>>>>>>
>>>>>>>>> I tried to debug but I have no clue what is going one there.
>>>>>>>>>
>>>>>>>>> Also u-boot 2019.07 is not working at all on cm3 due to this commit
>>>>>>>>> (after bisect when reverted u-boot start working again):
>>>>>>>>> 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
>>>>>>>>> tree sources to Linux 5.1-rc6 state
>>>>>>>>>
>>>>>>>>> Any ideas hint how to resolve this issue? Thanks.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Can you try to cherry-pick the following two patches to your tree:
>>>>>>>> 5051377a0b ("arm: dts: bcm283x: Rename U-Boot file")
>>>>>>>> 89e47e8eb6 ("fdt: fix bcm283x dm-pre-reloc definitions")
>>>>>>> But those are present in 2020.01 and this version at least print
>>>>>>> something to console but stuck somewhere (pls see pastebin log with
>>>>>>> debug enabled)
>>>>>>> I prefer to run 2020.01 ;). Thanks.
>>>>>> Any other stuff I can try to make it working in 2020.01? Could that be
>>>>>> firmware issue somehow? Thanks.
>>>>>
>>>>> Sorry I didn't realized that your first try was with 2020.01.
>>>>> I just confirmed that it acutually does not boot. As a shortcut, do you
>>>>> know
>>>>> which is the last working version of U-Boot?
>>>> v2019.07 with reverted commit :
>>>> 143256b353c4d2ad1cf5e5e63b38410188b35e49 - fdt: update bcm283x device
>>>> tree sources to Linux 5.1-rc6 state
>>>> work fine. Without revert it shows anything on console. So something
>>>> between 2019.07..2020.01 mus fix it partially ;)
>>>
>>> I just tired v2020.04 and it works for me. Would you mind testing that on
>>> your end?
>> OK I'll give a try and try to bisect between 2020.01 and 2020.04. I
>> have dependency on 2020.01 as I integrate mender
>> and then use this version.
>
> I'm on that no need for you to do it.
>
The result f
Re: [PATCH v2] rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY
On 13/05/2020 10:07, Corentin Labbe wrote: > As discussed at > https://lore.kernel.org/linux-arm-kernel/b726290c-1038-3771-5187-6ac370bc9...@arm.com/T/ > the defconfig for rpi4 miss CONFIG_ARCH_FIXUP_FDT_MEMORY. > Without it, booting with an initrd fail. > > Signed-off-by: Corentin Labbe > --- > Changes since v1: > - added fix for rpi_4_32b_defconfig > > configs/rpi_4_32b_defconfig | 2 +- > configs/rpi_4_defconfig | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > Any reason why you don't added rpi_arm64_defconfig? Regards, Matthias > diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig > index 8d262d89b4..f2a975891c 100644 > --- a/configs/rpi_4_32b_defconfig > +++ b/configs/rpi_4_32b_defconfig > @@ -7,7 +7,7 @@ CONFIG_ENV_SIZE=0x4000 > CONFIG_NR_DRAM_BANKS=2 > CONFIG_DISTRO_DEFAULTS=y > CONFIG_OF_BOARD_SETUP=y > -# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set > +CONFIG_ARCH_FIXUP_FDT_MEMORY=y > CONFIG_MISC_INIT_R=y > # CONFIG_DISPLAY_CPUINFO is not set > # CONFIG_DISPLAY_BOARDINFO is not set > diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig > index 2a0cea4222..f1c8f5ef7d 100644 > --- a/configs/rpi_4_defconfig > +++ b/configs/rpi_4_defconfig > @@ -7,7 +7,7 @@ CONFIG_ENV_SIZE=0x4000 > CONFIG_NR_DRAM_BANKS=2 > CONFIG_DISTRO_DEFAULTS=y > CONFIG_OF_BOARD_SETUP=y > -# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set > +CONFIG_ARCH_FIXUP_FDT_MEMORY=y > CONFIG_MISC_INIT_R=y > # CONFIG_DISPLAY_CPUINFO is not set > # CONFIG_DISPLAY_BOARDINFO is not set >
Re: [PATCH 1/2] mmc: sdhci: Use debug for not supported SDMA info message
On 12/05/2020 12:02, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> If CONFIG_MMC_SDHCI_SDMA is enabled but the HW could not support it,
> we no longer error out. Instead we do not enable it in the host.
> Change the output from printf to debug as this isn't an error but only
> additional information now.
>
> Signed-off-by: Matthias Brugger
Queued for rpi-next
> ---
>
> drivers/mmc/sdhci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index 6e8f6e3d17..8bb4393ce1 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -744,8 +744,8 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct
> sdhci_host *host,
> if ((caps & SDHCI_CAN_DO_SDMA)) {
> host->flags |= USE_SDMA;
> } else {
> - printf("%s: Your controller doesn't support SDMA!!\n",
> -__func__);
> + debug("%s: Your controller doesn't support SDMA!!\n",
> + __func__);
> }
> #endif
> #if CONFIG_IS_ENABLED(MMC_SDHCI_ADMA)
>
Re: [PATCH 2/2] configs: rpi_arm64: enable SDHCI SDMA support
On 12/05/2020 12:02, matthias@kernel.org wrote: > From: Matthias Brugger > > RPi4 supports SDMA on it's SDHCI controller. Enable to option for > the combine RPi3/4 config. > > Signed-off-by: Matthias Brugger > > --- Queued for rpi-next > > configs/rpi_arm64_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig > index b9bb083a1d..66c4a5368c 100644 > --- a/configs/rpi_arm64_defconfig > +++ b/configs/rpi_arm64_defconfig > @@ -23,6 +23,7 @@ CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y > CONFIG_DM_KEYBOARD=y > CONFIG_DM_MMC=y > CONFIG_MMC_SDHCI=y > +CONFIG_MMC_SDHCI_SDMA=y > CONFIG_MMC_SDHCI_BCM2835=y > CONFIG_DM_ETH=y > CONFIG_BCMGENET=y >
Re: [PATCH 1/2] rpi: Kconfig option for initial page reservation
On 26/02/2020 22:37, kev...@freebsd.org wrote: > From: Kyle Evans > > While the nearly-universal default for the Raspberry Pi family is to use > spin tables and the spin table implementation provided by the Raspberry Pi > Foundation, FreeBSD and others may use a PSCI implementation instead. > > Accommodate these setups by allowing them to configure for more than one > page to be reserved in the initial reservation. The default reservation > remains as one page. > > Signed-off-by: Kyle Evans Queued now for rpi-next. Sorry for the long delay. > --- > arch/arm/mach-bcm283x/Kconfig | 2 ++ > board/raspberrypi/rpi/Kconfig | 10 ++ > 2 files changed, 12 insertions(+) > create mode 100644 board/raspberrypi/rpi/Kconfig > > diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig > index 00419bf254..e6eb904e7f 100644 > --- a/arch/arm/mach-bcm283x/Kconfig > +++ b/arch/arm/mach-bcm283x/Kconfig > @@ -209,4 +209,6 @@ config SYS_SOC > config SYS_CONFIG_NAME > default "rpi" > > +source "board/raspberrypi/rpi/Kconfig" > + > endmenu > diff --git a/board/raspberrypi/rpi/Kconfig b/board/raspberrypi/rpi/Kconfig > new file mode 100644 > index 00..e40088fde1 > --- /dev/null > +++ b/board/raspberrypi/rpi/Kconfig > @@ -0,0 +1,10 @@ > +if SYS_BOARD = "rpi" > + > +config RPI_EFI_NR_SPIN_PAGES > + int "Spin table page count" > + default 1 > + help > + Number of pages to reserve starting at page 0 for spin tables in the > EFI > + memory map > + > +endif >
Re: [PATCH 2/2] rpi: use the newly-added RPI_EFI_NR_SPIN_PAGES
On 26/02/2020 22:39, kev...@freebsd.org wrote: > From: Kyle Evans > > Some systems may use a slightly larger stub to do PSCI for booting the RPi > family. The number of pages has been made configurable so that operating > systems building U-Boot for use in these kinds of environments can reserve > more memory in the EFI memory map. > > Signed-off-by: Kyle Evans > --- Queued now for rpi-next Sorry for the far to long delay > board/raspberrypi/rpi/rpi.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c > index e367ba3092..0206a093d4 100644 > --- a/board/raspberrypi/rpi/rpi.c > +++ b/board/raspberrypi/rpi/rpi.c > @@ -489,7 +489,8 @@ int ft_board_setup(void *blob, bd_t *bd) > > #ifdef CONFIG_EFI_LOADER > /* Reserve the spin table */ > - efi_add_memory_map(0, 1, EFI_RESERVED_MEMORY_TYPE, 0); > + efi_add_memory_map(0, CONFIG_RPI_EFI_NR_SPIN_PAGES, > +EFI_RESERVED_MEMORY_TYPE, 0); > #endif > > return 0; >
[GIT PULL] rpi: updates for v2020.07
Hi Tom,
Please have a look at the updates for RPi below.
I know I'm a bit late in the cycle. I'll try to send my pull requests earlier
next time, sorry for that.
I just pushed the tag, so the CI is not green yet:
https://travis-ci.org/github/mbgg/u-boot/builds/686914330
https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/pipelines/3241
But the tag actually refers to the same commit as my rpi-next branch, which is
all green here:
https://travis-ci.org/github/mbgg/u-boot/builds/686541087
https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/pipelines/3227
Regards and stay safe and healthy,
Matthias
---
The following changes since commit 2a38d2239d0bb4d128b00886bf097ab247a0b1a7:
Prepare v2020.07-rc2 (2020-05-11 18:28:19 -0400)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git
tags/rpi-next-2020.07
for you to fetch changes up to 82aef6c6f8a74a0595501bfbb2f6f763c786324f:
rpi: use the newly-added RPI_EFI_NR_SPIN_PAGES (2020-05-13 14:04:50 +0200)
- fix phy configuration for RPi4's bcmgenet
- sync RPi4's env size with other RPi configs
- add kconfig option to reserver more pages in the EFI mem map
- add support for SDMA which is used by RPi4
- fix corner case boot bug for RPi3 32-bit
Jaehoon Chung (3):
mmc: sdhci: use phys2bus macro when dma address is accessed
mmc: sdhci: not return error when SDMA is not supported
configs: rpi_4 : enable SDHCI_SDMA config
Kyle Evans (2):
rpi: Kconfig option for initial page reservation
rpi: use the newly-added RPI_EFI_NR_SPIN_PAGES
Marek Szyprowski (1):
configs: rpi_arm64: sync env size with rpi_{3,4}_defconfig
Matthias Brugger (2):
mmc: sdhci: Use debug for not supported SDMA info message
configs: rpi_arm64: enable SDHCI SDMA support
Nicolas Saenz Julienne (1):
net: bcmgenet: Don't set ID_MODE_DIS when not using RGMII
Simon Glass (2):
arm: dts: bcm283x: Allow UARTs to work before relocation
arm: bcm283x: serial: Move ofdata reading to probe() method
arch/arm/dts/bcm283x-u-boot.dtsi | 8
arch/arm/mach-bcm283x/Kconfig | 2 ++
board/raspberrypi/rpi/Kconfig | 10 ++
board/raspberrypi/rpi/rpi.c | 3 ++-
configs/rpi_4_32b_defconfig | 1 +
configs/rpi_4_defconfig | 1 +
configs/rpi_arm64_defconfig | 2 ++
drivers/mmc/sdhci.c | 17 +
drivers/net/bcmgenet.c| 5 -
drivers/serial/serial_bcm283x_mu.c| 21 +
drivers/serial/serial_bcm283x_pl011.c | 12
11 files changed, 56 insertions(+), 26 deletions(-)
create mode 100644 board/raspberrypi/rpi/Kconfig
Re: [PATCH v2 1/2] arm: dts: bcm283x: Allow UARTs to work before relocation
On 15/04/2020 21:59, Tom Rini wrote: > On Tue, Apr 14, 2020 at 08:23:10PM -0600, Simon Glass wrote: >> Hi, >> >> On Sun, 22 Mar 2020 at 21:16, Simon Glass wrote: >>> >>> At present the pinctrl nodes are not enabled in pre-relocation U-Boot so >>> the UARTs do not correctly select the pinconfig to enable the UART pins. >>> Fix this so that the U-Boot banner is printed. >>> >>> This fixes serial output on rpi_3b_32b with the following config.txt >>> options: >>> >>>enable_uart=1 >>>gpu_freq=250 >>> >>> Signed-off-by: Simon Glass >>> Fixes: 9821636b64 (bcm2835_pinctrl: Probe pre-reloc) >>> --- >>> >>> Changes in v2: >>> - Update commit message >>> >>> arch/arm/dts/bcm283x-u-boot.dtsi | 8 >>> 1 file changed, 8 insertions(+) >> >> Any thoughts on this series? At present all my lab tests fail. > > I don't know if the problem is my firmware is too old (and so works) or > your firmware is too old (and so fails) or if there's some > phase-of-the-moon problem. So while I'd like to know _why_ my 3B is > fine and yours is not, we should just take this I suppose. > I agree with Tom, we should try to find out what's the problem. Do you know which version (e.g. git commit or which version of rasbian etc) of the RPi FW you are using? If not, can you provide me with the md5sum's so that I can try to reproduce this. Regards, Matthias
Re: [PATCH 2/2] uboot: fs/btrfs: Fix LZO false decompression error caused by pending zero
Hi Qu,
On 19/03/2020 13:30, Qu Wenruo wrote:
> [BUG]
> For certain btrfs files with compressed file extent, uboot will fail to
> load it:
>
> btrfs_read_extent_reg: disk_bytenr=14229504 disk_len=73728 offset=0
> nr_bytes=131
> 072
> decompress_lzo: tot_len=70770
> decompress_lzo: in_len=1389
> decompress_lzo: in_len=2400
> decompress_lzo: in_len=3002
> decompress_lzo: in_len=1379
> decompress_lzo: in_len=88539136
> decompress_lzo: header error, in_len=88539136 clen=65534 tot_len=62580
>
> NOTE: except the last line, all other lines are debug output.
>
> [CAUSE]
> Btrfs lzo compression uses its own format to record compressed size
> (segmant header, LE32).
>
> However to make decompression easier, we never put such segment header
> across page boundary.
>
> In above case, the xxd dump of the lzo compressed data looks like this:
>
> 1fe0: 4cdc 02fc 0bfd 02c0 dc02 0d13 0100 0001 L...
> 1ff0: 0008 0300 0011 |
> 2000: 4705 0001 cc02 1e01 G...
>
> '|' is the "expected" segment header start position.
>
> But in that page, there are only 2 bytes left, can't contain the 4 bytes
> segment header.
>
> So btrfs compression will skip that 2 bytes, put the segment header in
> next page directly.
>
> Uboot doesn't have such check, and read the header with 2 bytes offset,
> result 0x0547 (88539136), other than the expected result
> 0x0547 (1351), resulting above error.
>
> [FIX]
> Follow the btrfs-progs restore implementation, by introducing tot_in to
> record total processed bytes (including headers), and do proper page
> boundary skip to fix it.
>
> Signed-off-by: Qu Wenruo
> ---
> fs/btrfs/compression.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
> index 4ef44ce11485..2a6ac8bb1029 100644
> --- a/fs/btrfs/compression.c
> +++ b/fs/btrfs/compression.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -17,6 +18,7 @@
> static u32 decompress_lzo(const u8 *cbuf, u32 clen, u8 *dbuf, u32 dlen)
> {
> u32 tot_len, in_len, res;
> + u32 tot_in = 0;
> size_t out_len;
> int ret;
>
> @@ -27,6 +29,7 @@ static u32 decompress_lzo(const u8 *cbuf, u32 clen, u8
> *dbuf, u32 dlen)
> cbuf += LZO_LEN;
> clen -= LZO_LEN;
> tot_len -= LZO_LEN;
> + tot_in += LZO_LEN;
>
> if (tot_len == 0 && dlen)
> return -1;
> @@ -36,6 +39,9 @@ static u32 decompress_lzo(const u8 *cbuf, u32 clen, u8
> *dbuf, u32 dlen)
> res = 0;
>
> while (tot_len > LZO_LEN) {
> + size_t mod_page;
> + size_t rem_page;
> +
> in_len = le32_to_cpu(get_unaligned((u32 *)cbuf));
> cbuf += LZO_LEN;
> clen -= LZO_LEN;
> @@ -44,6 +50,7 @@ static u32 decompress_lzo(const u8 *cbuf, u32 clen, u8
> *dbuf, u32 dlen)
> return -1;
>
> tot_len -= (LZO_LEN + in_len);
> + tot_in += (LZO_LEN + in_len);
>
> out_len = dlen;
> ret = lzo1x_decompress_safe(cbuf, in_len, dbuf, &out_len);
> @@ -56,6 +63,19 @@ static u32 decompress_lzo(const u8 *cbuf, u32 clen, u8
> *dbuf, u32 dlen)
> dlen -= out_len;
>
> res += out_len;
> +
> + /*
> + * If the 4 bytes header does not fit to the rest of the page we
> + * have to move to next one, or we read some garbage.
> + */
> + mod_page = tot_in % PAGE_SIZE;
in U-Boot we use 4K page sizes, but the OS could use another page size (16K or
64k). Would we need to adapt that code to reflect which page size is used on the
medium we want to access?
Regards,
Matthias
> + rem_page = PAGE_SIZE - mod_page;
> + if (rem_page < LZO_LEN) {
> + cbuf += rem_page;
> + tot_in += rem_page;
> + clen -= rem_page;
> + tot_len -= rem_page;
> + }
> }
>
> return res;
>
Re: [PATCH 2/2] uboot: fs/btrfs: Fix LZO false decompression error caused by pending zero
On 19/03/2020 14:56, David Sterba wrote: > On Thu, Mar 19, 2020 at 02:33:28PM +0100, Matthias Brugger wrote: >>> dlen -= out_len; >>> >>> res += out_len; >>> + >>> + /* >>> +* If the 4 bytes header does not fit to the rest of the page we >>> +* have to move to next one, or we read some garbage. >>> +*/ >>> + mod_page = tot_in % PAGE_SIZE; >> >> in U-Boot we use 4K page sizes, but the OS could use another page size (16K >> or >> 64k). Would we need to adapt that code to reflect which page size is used on >> the >> medium we want to access? > > Yes, it is the 'sectorsize' as it's set up in fs_info or it's equivalent > in uboot. For kernel the page size == sectorsize is kind of implicit and > verified at mount time. > Does this mean we would need to add a Kconfig option to set the sectorsize in U-Boot? Regards, Matthias
Re: bootp problems with rpi4
Hi Nicolas, On 21/03/2020 19:57, Nicolas Meaux wrote: > Hello, > > I use u-boot for raspberry, but i have a different behavior between rpi3b and > rpi4b. > * i use the same u-boot source files (2020.04-rc3-00161-g14eb12a3c8) > * i use the same method for compiling ( make -j4 ARCH=arm > CROSS_COMPILE=aarch64-linux-gnu- all ) > * i use the same dhcp/tftp server in both case . > * i just load a different config : rpi_3_defconfig & rpi_4_defconfig > > When i boot with my rpi3b, it happens the following : > * 1st bootp ok > * tftp download boot.scr.uimg file > * 2nd bootp ok > * tftp load the "bootfile filename" setup in the dhcp config which is an efi > application > * efi application is loaded and the rest of the boot process is fine. > > When i boot with my rpi4b, it happens the following : > * 1st bootp ok > * tftp download boot.scr.uimg file > * 2nd bootp nok and goes into timeout, with a tcpdump on the ethernet > interface > connected to the pi, absolutely 0 bootp requested are made by u-boot at this > step. > > * U-boot log with rpi3b : > U-Boot 2020.04-rc3-00161-g14eb12a3c8 (Mar 21 2020 - 18:41:52 +0100) > > DRAM: 948 MiB > RPI 3 Model B (0xa02082) > MMC: mmc@7e202000: 0, sdhci@7e30: 1 > Loading Environment from FAT... WARNING at > drivers/mmc/bcm2835_sdhost.c:411/bcm2835_send_command()! > WARNING at drivers/mmc/bcm2835_sdhost.c:411/bcm2835_send_command()! > Card did not respond to voltage select! > In: serial > Out: vidconsole > Err: vidconsole > Net: No ethernet found. > starting USB... > Bus usb@7e98: scanning bus usb@7e98 for devices... 3 USB Device(s) > found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > WARNING at drivers/mmc/bcm2835_sdhost.c:411/bcm2835_send_command()! > WARNING at drivers/mmc/bcm2835_sdhost.c:411/bcm2835_send_command()! > WARNING at drivers/mmc/bcm2835_sdhost.c:411/bcm2835_send_command()! > Card did not respond to voltage select! > Card did not respond to voltage select! > > Device 0: unknown device > Waiting for Ethernet connection... done. > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > DHCP client bound to address 10.0.0.3 (2245 ms) > Using smsc95xx_eth device > TFTP from server 10.0.0.254; our IP address is 10.0.0.3 > Filename 'boot.scr.uimg'. > Load address: 0x240 > Loading: ## 322 Bytes > 34.2 KiB/s > done > Bytes transferred = 322 (142 hex) > ## Executing script at 0240 > WARNING at drivers/mmc/bcm2835_sdhost.c:411/bcm2835_send_command()! > WARNING at drivers/mmc/bcm2835_sdhost.c:411/bcm2835_send_command()! > WARNING at drivers/mmc/bcm2835_sdhost.c:411/bcm2835_send_command()! > Card did not respond to voltage select! > WARNING at drivers/mmc/bcm2835_sdhost.c:411/bcm2835_send_command()! > WARNING at drivers/mmc/bcm2835_sdhost.c:411/bcm2835_send_command()! > WARNING at drivers/mmc/bcm2835_sdhost.c:411/bcm2835_send_command()! > Card did not respond to voltage select! > Bad Linux ARM64 Image magic! > Waiting for Ethernet connection... done. > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > *** Unhandled DHCP Option in OFFER/ACK: 60 > *** Unhandled DHCP Option in OFFER/ACK: 60 > DHCP client bound to address 10.0.0.3 (2195 ms) > Using smsc95xx_eth device > TFTP from server 10.0.0.254; our IP address is 10.0.0.3 > Filename 'snp.efi'. > Load address: 0x100 > Loading: ## 162.7 KiB > 2.4 MiB/s > done > Bytes transferred = 166624 (28ae0 hex) > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 10.0.0.254; our IP address is 10.0.0.3 > Filename 'dtb/broadcom/bcm2837-rpi-3-b.dtb'. > Load address: 0x260 > Loading: ## 19.1 KiB > 83 KiB/s > done > Bytes transferred = 19530 (4c4a hex) > WARNING at drivers/mmc/bcm2835_sdhost.c:411/bcm2835_send_command()! > WARNING at drivers/mmc/bcm2835_sdhost.c:411/bcm2835_send_command()! > WARNING at drivers/mmc/bcm2835_sdhost.c:411/bcm2835_send_command()! > Card did not respond to voltage select! > Scanning disk m...@7e202000.blk... > Disk m...@7e202000.blk not ready > Card did not respond to voltage select! > Scanning disk sd...@7e30.blk... > Disk sd...@7e30.blk not ready > Found 0 disks > efi_load_pe: Invalid DOS Signature > iPXE initialising devices...ok > > > > iPXE 1.20.1+ (g18dc) -- Open Source Network Boot Firmware -- http://ipxe.org > > > * U-boot log with rpi4b : > U-Boot 2020.04-rc3-00161-g14eb12a3c8 (Mar 19 2020 - 22:02:29 +) > > DRAM: 1.9 GiB > RPI 4 Model B (0xb03111) > MMC: emmc2@7e34: 0, mmcnr@7e30: 1 > Loading Environment from FAT... Card did not respond to voltage select! > In: serial > Out: serial > Err: serial > Net: eth0: genet@7d58 > Hit any key to stop autoboot: 0 > Card did not respond to voltage select! > Card did not respond to voltage sel
Re: [PATCH v3 3/3] configs: rpi_4_32b_defconfig: enable SDHCI_SDMA config
On 24/03/2020 23:58, Jaehoon Chung wrote: > Enable SDHCI_SDMA configuration. > > Signed-off-by: Jaehoon Chung > Reviewed-by: Peng Fan > Reviewed-by: Minkyu Kang > --- > configs/rpi_4_32b_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig > index 72cda5d949..7189914606 100644 > --- a/configs/rpi_4_32b_defconfig > +++ b/configs/rpi_4_32b_defconfig > @@ -25,6 +25,7 @@ CONFIG_DFU_MMC=y > CONFIG_DM_KEYBOARD=y > CONFIG_DM_MMC=y > CONFIG_MMC_SDHCI=y > +CONFIG_MMC_SDHCI_SDMA=y RPi4 can only do DMA transfers to the first GiB of memory. I wasn't sucessfull in understanding the mmc/sdhci code to see where we take the dma-ranges property into account so that we don't use an address > 1 GiB. Are we safe in this regard? If we are, then we can also enable this for rpi_4_defconfig and rpi_arm64_defconfig I think. Regards, Matthias > CONFIG_MMC_SDHCI_BCM2835=y > CONFIG_DM_ETH=y > CONFIG_BCMGENET=y >
Re: [PATCH v3 3/3] configs: rpi_4_32b_defconfig: enable SDHCI_SDMA config
On 26/03/2020 05:51, Jaehoon Chung wrote: > On 3/26/20 1:09 AM, Matthias Brugger wrote: >> >> >> On 24/03/2020 23:58, Jaehoon Chung wrote: >>> Enable SDHCI_SDMA configuration. >>> >>> Signed-off-by: Jaehoon Chung >>> Reviewed-by: Peng Fan >>> Reviewed-by: Minkyu Kang >>> --- >>> configs/rpi_4_32b_defconfig | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig >>> index 72cda5d949..7189914606 100644 >>> --- a/configs/rpi_4_32b_defconfig >>> +++ b/configs/rpi_4_32b_defconfig >>> @@ -25,6 +25,7 @@ CONFIG_DFU_MMC=y >>> CONFIG_DM_KEYBOARD=y >>> CONFIG_DM_MMC=y >>> CONFIG_MMC_SDHCI=y >>> +CONFIG_MMC_SDHCI_SDMA=y >> >> RPi4 can only do DMA transfers to the first GiB of memory. I wasn't >> sucessfull >> in understanding the mmc/sdhci code to see where we take the dma-ranges >> property >> into account so that we don't use an address > 1 GiB. > > Sorry i don't understand clearly what you said. > I'll try to rephrase: How do we make sure that DMA uses only addresses the in the first GiB of RAM for it's transactions. That a limitation the RPi4 has. >> >> Are we safe in this regard? If we are, then we can also enable this for >> rpi_4_defconfig and rpi_arm64_defconfig I think. > > I checked rpi_arm64_defconfig history. it's unified config for RPi3/RPI4. > As i know, RPi3 doesn't support SDMA mode. So i don't have a plan to apply > rpi_arm64_defconfig. > (If i understood wrong, let me know,plz.) > Yes, well we have two different device tree compatibles for them. We have to change the driver to make sure only sdhci of RPi4 does enable SDMA. Regards, Matthias > I have tested SDMA mode With rpi_4_defconfig / rpi_4_32b_defconfig. > Test Environment > - Target : RPI4 (1G/2G/4G) target > - config : rpi_4_defconfig / rpi_4_32b_defconfig > > Read/write some files from Sd-card. > Read/write performance is increased than before. > > I will resend with rpi_4_defconfig, except rpi_arm64_defconfig. > > Best Regards, > Jaehoon Chung > >> >> Regards, >> Matthias >> >>> CONFIG_MMC_SDHCI_BCM2835=y >>> CONFIG_DM_ETH=y >>> CONFIG_BCMGENET=y >>> >> >> >
Re: [Patch V4 3/3] configs: rpi_4 : enable SDHCI_SDMA config
Hi Jaehoon, On 27/03/2020 05:08, Jaehoon Chung wrote: > Enable SDHCI_SDMA configuration. > > Signed-off-by: Jaehoon Chung > Reviewed-by: Peng Fan > Reviewed-by: Minkyu Kang > --- > configs/rpi_4_32b_defconfig | 1 + > configs/rpi_4_defconfig | 1 + > 2 files changed, 2 insertions(+) > Please address the comments I had in v3 of this patch: https://patchwork.ozlabs.org/patch/1261047/ If you just send a new version of the patch that won't convince me to take it. We will need to make sure that we are fine with patch. Especially I'm concerned about the limitation of the device to only be able to access the first GiB of RAM for DMA. I'd like to see an explanation why this won't happen on U-Boot. Regards, Matthias > diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig > index 72cda5d949..7189914606 100644 > --- a/configs/rpi_4_32b_defconfig > +++ b/configs/rpi_4_32b_defconfig > @@ -25,6 +25,7 @@ CONFIG_DFU_MMC=y > CONFIG_DM_KEYBOARD=y > CONFIG_DM_MMC=y > CONFIG_MMC_SDHCI=y > +CONFIG_MMC_SDHCI_SDMA=y > CONFIG_MMC_SDHCI_BCM2835=y > CONFIG_DM_ETH=y > CONFIG_BCMGENET=y > diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig > index 6d148dab07..454d28ea2b 100644 > --- a/configs/rpi_4_defconfig > +++ b/configs/rpi_4_defconfig > @@ -25,6 +25,7 @@ CONFIG_DFU_MMC=y > CONFIG_DM_KEYBOARD=y > CONFIG_DM_MMC=y > CONFIG_MMC_SDHCI=y > +CONFIG_MMC_SDHCI_SDMA=y > CONFIG_MMC_SDHCI_BCM2835=y > CONFIG_DM_ETH=y > CONFIG_BCMGENET=y >
Re: Bug: qemu_arm64: Cannot access the second flash bank
Hi Robin,
On 09/01/2020 16:21, Robin Randhawa wrote:
> On Thu, 2020-01-09 at 15:57 +0100, Matthias Brugger wrote:
>
> [...]
>
>> The property expects size-cells to be two, but U-Boot will use one
>> cell if no
>> size-cells are defined in the device node (which is not the case) and
>> therefor
>> will see
>>
>> Bank1: Flashbase 0x0 0x0 Flashsize 0x400
>> Bank2: Flashbase 0x400 0x0 Flashsize 0x400
>
> My knowledge of DT is superficial. However, looking at the following
> lines from the spec:
>
> - A |spec|-compliant boot program shall supply #address-cells and
> #size-cells on all nodes that have children.
>
> - If missing, a client program should assume a default value of 2 for
> #address-cells, and a value of 1 for #size-cells.
>
> .. and contrasting with the root node and device node in question from
> the DTS for this platform:
>
> / {
> interrupt-parent = <0x8001>;
> #size-cells = <0x2>;
> #address-cells = <0x2>;
> compatible = "linux,dummy-virt";
> .
> .
>
> flash@0 {
> bank-width = <0x4>;
> reg = <0x0 0x0 0x0 0x400 0x0 0x400 0x0 0x400>;
> compatible = "cfi-flash";
> };
>
> .. it seems to me that while the flash node is missing #size-cells,
> given that #size-cells _is_ defined in the parent node ("the node that
> has children") then that value (0x2) is the one u-boot should have used
> but didn't.
>
> Maybe the u-boot DT interpreting logic needs to check if the parent
> node also does not specify #size-cells before making the assumption
> that the value 1 is to be used ?
>
Sorry for taking so long. Yes you are correct, I found the issue in U-Boot and
I'm working on a patch. Please stay tuned.
Regards,
Matthias
Re: [PATCH v3] usb: dfu: Migrate CONFIG_SYS_DFU_DATA_BUF_SIZE and CONFIG_SYS_DFU_MAX_FILE_SIZE to Kconfig
On 01/06/2021 13:21, Aswath Govindraju wrote: > Currently the config options CONFIG_SYS_DFU_DATA_BUF_SIZE and > CONFIG_SYS_DFU_MAX_FILE_SIZE are being set in include/configs/.h > files and also in _defconfig files without a Kconfig option. It > is easier for users to set these configs in defconfig files than in config > header files as they are a part of the source code. > > Add Kconfig symbols, and update the defconfigs by using tools/moveconfig.py > script. > > Suggested-by: Pratyush Yadav > Signed-off-by: Aswath Govindraju > Acked-by: Oleksandr Suvorov For Raspberry Pi parts: Acked-by: Matthias Brugger > --- > > Changes since v2: > - Rebased the patch on top of current HEAD > - Picked up Oleksandr Suvorov's Acked-by > > Link to v2 patch, > https://patchwork.ozlabs.org/project/uboot/patch/20210226071849.29070-1-a-govindr...@ti.com/ > > Changes since v1: > - Removed CONFIG_SYS_DFU_MAX_FILE_SIZE in defconfig files, where it was > not defined previously. The list of files in which this change is made > are listed below, > configs/colibri-imx6ull_defconfig > configs/colibri_vf_defconfig > configs/corvus_defconfig > configs/dh_imx6_defconfig > configs/draco_defconfig > configs/etamin_defconfig > configs/odroid-xu3_defconfig > configs/odroid_defconfig > configs/origen_defconfig > configs/pico-dwarf-imx6ul_defconfig > configs/pico-hobbit-imx6ul_defconfig > configs/pico-imx6_defconfig > configs/pico-imx6ul_defconfig > configs/pico-pi-imx6ul_defconfig > configs/pxm2_defconfig > configs/rastaban_defconfig > configs/rut_defconfig > configs/s5p_goni_defconfig > configs/s5pc210_universal_defconfig > configs/smartweb_defconfig > configs/socfpga_arria5_defconfig > configs/socfpga_cyclone5_defconfig > configs/socfpga_dbm_soc1_defconfig > configs/socfpga_de0_nano_soc_defconfig > configs/socfpga_de10_nano_defconfig > configs/socfpga_mcvevk_defconfig > configs/socfpga_sockit_defconfig > configs/socfpga_socrates_defconfig > configs/socfpga_vining_fpga_defconfig > configs/taurus_defconfig > configs/thuban_defconfig > configs/topic_miami_defconfig > configs/topic_miamilite_defconfig > configs/topic_miamiplus_defconfig > configs/trats2_defconfig > configs/trats_defconfig > configs/warp7_bl33_defconfig > configs/warp7_defconfig > configs/warp_defconfig > configs/xilinx_versal_virt_defconfig > configs/xilinx_zynq_virt_defconfig > configs/xilinx_zynqmp_virt_defconfig > > Link to v1, > https://patchwork.ozlabs.org/project/uboot/patch/20210223061427.20742-1-a-govindr...@ti.com/ > > > configs/am65x_evm_a53_defconfig | 2 ++ > configs/am65x_evm_r5_usbdfu_defconfig | 2 ++ > configs/am65x_hs_evm_a53_defconfig| 2 ++ > configs/beaver_defconfig | 2 ++ > configs/cei-tk1-som_defconfig | 2 ++ > configs/colibri-imx6ull_defconfig | 1 + > configs/colibri_vf_defconfig | 1 + > configs/corvus_defconfig | 1 + > configs/dalmore_defconfig | 2 ++ > configs/dh_imx6_defconfig | 1 + > configs/draco_defconfig | 1 + > configs/etamin_defconfig | 1 + > configs/jetson-tk1_defconfig | 2 ++ > configs/nyan-big_defconfig| 2 ++ > configs/odroid-xu3_defconfig | 1 + > configs/odroid_defconfig | 1 + > configs/origen_defconfig | 1 + > configs/p2371-_defconfig | 2 ++ > configs/p2371-2180_defconfig | 2 ++ > configs/p2571_defconfig | 2 ++ > configs/p3450-_defconfig | 2 ++ > configs/pico-dwarf-imx6ul_defconfig | 1 + > configs/pico-hobbit-imx6ul_defconfig | 1 + > configs/pico-imx6_defconfig | 1 + > configs/pico-imx6ul_defconfig | 1 + > configs/pico-pi-imx6ul_defconfig | 1 + > configs/pxm2_defconfig| 1 + > configs/rastaban_defconfig| 1 + > configs/rpi_4_32b_defconfig | 2 ++ > configs/rpi_4_defconfig | 2 ++ > configs/rut_defconfig | 1 + > configs/s5p_goni_defconfig| 1 + > configs/s5pc210_universal_defconfig | 1 + > configs/smartweb_defconfig| 1 + > configs/socfpga_arria5_defconfig | 1 + > configs/socfpga_cyclone5_defconfig| 1 + > configs/socfpga_dbm_soc1_defconfig| 1 + > configs/socfpga_de0_nano_soc_defconfig| 1 + > configs/socfpga_de10_nano_defconf
Re: [PATCH v2 2/2] console: Don't start/stop console if stdio device invalid
On 28/01/2021 16:52, Andy Shevchenko wrote:
> On Thu, Jan 28, 2021 at 02:12:40PM +0100, Nicolas Saenz Julienne wrote:
>> Don't start/stop an stdio device that might have been already freed.
>>
>> Signed-off-by: Nicolas Saenz Julienne
>> Fixes: 70c2525c0d3c ("IOMUX: Stop dropped consoles")
>
> ...
>
>> +/*
>> + * TODO: This is a workaround to avoid accessing freed memory:
>> + * console_stop() might be called on an stdio_dev that has already been
>> + * de-registered, due to the fact that stdio_deregister_dev()
>> + * doesn't update the global console_devices array.
>> + */
>
> I see now. I think I have experienced this issue from time to time. I will
> look
> at it. Tom, Simon, please hold on applying these for a while.
>
Just for the notes, the failing tests hold back Nicolas series to support
RPi400/CM4 [1] as it does not run the new tests added successfully. If it takes
a long time to fix the test environment, I'd vote to take this series as a
stop-gap so that we can support that HW in the next release.
Regards,
Matthias
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=223890
Re: [QUESTION] Kernel 5.10 image might be too big to be loaded by U-Boot on RPi 4B
On Thu, Jan 28, 2021 at 04:54:03PM +0800, Jian-Hong Pan wrote: > Load u-Boot environment ... from mmc 0:2 > 622 bytes read in 24 ms (24.4 KiB/s) > Load device tree ... > 25693 bytes read in 30 ms (835.9 KiB/s) > fdt_addr_r @ 0x0260 , size= 645d > Load kernel and unzip it ... > 13013555 bytes read in 574 ms (21.6 MiB/s) > Uncompressed size: 38742528 = 0x24F2A00 > kernel_addr_r @ 0x0008 , size= 24f2a00 > Load RAM disk ... > 54360540 bytes read in 2298 ms (22.6 MiB/s) > ramdisk_addr_r @ 0x0270 , size= 33d79dc > Boot ... > Moving Image from 0x8 to 0x20, end=282 > ERROR: RD image overlaps OS image (OS=0x20..0x282) > SCRIPT FAILED: continuing... > Card did not respond to voltage select! > genet@7d58 Waiting for PHY auto negotiation to complete > > It shows error: "RD image overlaps OS image (OS=0x20..0x282)" > > So, I calculated the memory address and space: > > 0x20 (kernel start address) + 0x24F2A00 (kernel size) = 0x26F2A00 < > 282 (kernel end), but > 0x270 (ramdisk start address) & > 0x260 > (FDT start address) > > The kernel image size 0x24F2A00 bytes is too fat to sit in the memory space > prepared by U-Boot and overlaps ramdisk and FDT's memory spaces. > It is more than 36.9MB, which is over 36MB mentioned in U-Boot's comment > [2]. > If I did the math right, we should have a lot of space left. You could try to bump up fdt_addr_r=0x0290 and ramdisk_addr_r=0x02A0 and see what happens. Regards, Matthias > We understand this can be fixed by a workaround like tuning/reducing the > kernel's build config. However, is it possible to have another way to > resolve this problem? > > [1] > https://kernel.ubuntu.com/git/ubuntu/unstable.git/tree/?h=Ubuntu-5.10-5.10.0-10.11 > [2] > https://github.com/u-boot/u-boot/blob/v2021.01/include/configs/rpi.h#L140 > > Jain-Hong Pan
Re: [RFC PATCH] efi_loader: disable GRUB workaround by default
On 09/02/2021 13:22, Heinrich Schuchardt wrote: > On 09.02.21 12:38, matthias@kernel.org wrote: >> From: Matthias Brugger >> >> GRUB version 2.04 was published over a year ago. We should expect that >> distros use this version now. So disable the workaround by default. >> As we know that i.MX6 CPUs lack proper handling of caches, enable the >> workaround on these only. > > Hello Matthias, > > Where did the current setting hurt? > I hit this on BananaPi R2 where the time from exiting the boot services until the kernel gets loaded was three times bigger with the workaround. Similar numbers, ~40 down to 12 seconds. > Did you really check all 32bit ARM defconfig? No I didn't, that's why I send it as RFC. If you think this is a can of worms we would open, then I just disable the workaround for these two defconfigs. Regards, Matthias > Which other devices have caches that are not controlled by CP15? > How about all non-i.mx6 devices using CONFIG_SYS_L2_PL310? > > Best regards > > Heinrich > >> >> Signed-off-by: Matthias Brugger >> >> --- >> >> configs/imx6dl_icore_nand_defconfig | 1 + >> configs/imx6dl_mamoj_defconfig | 1 + >> configs/imx6q_icore_nand_defconfig | 1 + >> configs/imx6q_logic_defconfig| 1 + >> configs/imx6qdl_icore_mipi_defconfig | 1 + >> configs/imx6qdl_icore_mmc_defconfig | 1 + >> configs/imx6qdl_icore_nand_defconfig | 1 + >> configs/imx6qdl_icore_rqs_defconfig | 1 + >> configs/imx6ul_geam_mmc_defconfig| 1 + >> configs/imx6ul_geam_nand_defconfig | 1 + >> configs/imx6ul_isiot_emmc_defconfig | 1 + >> configs/imx6ul_isiot_nand_defconfig | 1 + >> lib/efi_loader/Kconfig | 2 +- >> 13 files changed, 13 insertions(+), 1 deletion(-) >> >> diff --git a/configs/imx6dl_icore_nand_defconfig >> b/configs/imx6dl_icore_nand_defconfig >> index 06005c4288..44fbbe6bd1 100644 >> --- a/configs/imx6dl_icore_nand_defconfig >> +++ b/configs/imx6dl_icore_nand_defconfig >> @@ -68,3 +68,4 @@ CONFIG_SPLASH_SCREEN=y >> CONFIG_SPLASH_SCREEN_ALIGN=y >> CONFIG_VIDEO_BMP_RLE8=y >> CONFIG_BMP_16BPP=y >> +CONFIG_EFI_GRUB_ARM32_WORKAROUND=y >> diff --git a/configs/imx6dl_mamoj_defconfig b/configs/imx6dl_mamoj_defconfig >> index fa2adaf47d..7ebbb5830b 100644 >> --- a/configs/imx6dl_mamoj_defconfig >> +++ b/configs/imx6dl_mamoj_defconfig >> @@ -57,3 +57,4 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL" >> CONFIG_USB_GADGET_VENDOR_NUM=0x0525 >> CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 >> CONFIG_CI_UDC=y >> +CONFIG_EFI_GRUB_ARM32_WORKAROUND=y >> diff --git a/configs/imx6q_icore_nand_defconfig >> b/configs/imx6q_icore_nand_defconfig >> index f38b06dab9..cef5f3448d 100644 >> --- a/configs/imx6q_icore_nand_defconfig >> +++ b/configs/imx6q_icore_nand_defconfig >> @@ -69,3 +69,4 @@ CONFIG_SPLASH_SCREEN=y >> CONFIG_SPLASH_SCREEN_ALIGN=y >> CONFIG_VIDEO_BMP_RLE8=y >> CONFIG_BMP_16BPP=y >> +CONFIG_EFI_GRUB_ARM32_WORKAROUND=y >> diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig >> index 36dc24d080..b5a4d3d24d 100644 >> --- a/configs/imx6q_logic_defconfig >> +++ b/configs/imx6q_logic_defconfig >> @@ -103,3 +103,4 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525 >> CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 >> CONFIG_CI_UDC=y >> CONFIG_USB_GADGET_DOWNLOAD=y >> +CONFIG_EFI_GRUB_ARM32_WORKAROUND=y >> diff --git a/configs/imx6qdl_icore_mipi_defconfig >> b/configs/imx6qdl_icore_mipi_defconfig >> index f1b5389470..1d9e021844 100644 >> --- a/configs/imx6qdl_icore_mipi_defconfig >> +++ b/configs/imx6qdl_icore_mipi_defconfig >> @@ -63,3 +63,4 @@ CONFIG_PINCTRL=y >> CONFIG_PINCTRL_IMX6=y >> CONFIG_MXC_UART=y >> CONFIG_IMX_THERMAL=y >> +CONFIG_EFI_GRUB_ARM32_WORKAROUND=y >> diff --git a/configs/imx6qdl_icore_mmc_defconfig >> b/configs/imx6qdl_icore_mmc_defconfig >> index a32ae6a75d..b46d19ad88 100644 >> --- a/configs/imx6qdl_icore_mmc_defconfig >> +++ b/configs/imx6qdl_icore_mmc_defconfig >> @@ -86,3 +86,4 @@ CONFIG_SPLASH_SCREEN_ALIGN=y >> CONFIG_VIDEO_BMP_RLE8=y >> CONFIG_BMP_16BPP=y >> CONFIG_IMX_WATCHDOG=y >> +CONFIG_EFI_GRUB_ARM32_WORKAROUND=y >> diff --git a/configs/imx6qdl_icore_nand_defconfig >> b/configs/imx6qdl_icore_nand_defconfig >> index f38b06dab9..cef5f3448d 100644 >> --- a/configs/imx6qdl_icore_nand_defconfig >> +++ b/configs/imx6qdl_icore_nand_defconfig >> @@ -69,3 +69,4 @@ CONFIG_SPLASH_SCREEN=y >> CONFIG_SPLASH_SCREEN_ALIGN=y >> CONFIG_V
[GIT PULL] rpi: updates for v2021.04
Hi Tom, Please find below the updates for the Raspberry Pi for v202.04. The most important are the support for Compute Module 4 and RPi400. Apart from that we now have support for the RNG device found on RPi4. I run the patches through the gitlab CI: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/6416 https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/6415 It took quite a while to get all this patches ready for mainline, as the pytests were failing. This is got fixed by Andy Shevchenko and is now merge upstream, so everything is green :) Regards, Matthias --- The following changes since commit 496f49464d90b564da5f1a2f4eecb5553e01edf9: Merge branch '2021-02-16-assorted-improvements' (2021-02-16 15:14:34 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-next-2021.04 for you to fetch changes up to 0059ef0be903a1f0a9afe5259fb2e0874f78a8ac: video: arm: rpi: Add brcm,bcm2711-hdmi0 compatible (2021-02-18 11:59:08 +0100) - add iProc RNG2000 driver for RPi4 - add support for CM4 and RPi400 Marek Szyprowski (1): rpi: limit size of the RAM to the multiple of the MMU_SECTION_SIZE Matthias Brugger (2): rng: Add iProc RNG200 driver config: Enable iProc RNG200 driver in RPi4 configs Nicolas Saenz Julienne (15): usb: xhci-pci: Add DM_FLAG_OS_PREPARE flag pci: brcmstb: Cleanup controller state before handover rpi: Add identifier for the new RPi400 rpi: Add identifier for the new CM4 pci: pcie-brcmstb: Fix inbound window configurations dm: Introduce xxx_get_dma_range() dm: test: Add test case for dev_get_dma_ranges() dm: Introduce DMA constraints into the core device model dm: test: Add test case for dev->dma_offset dm: Introduce dev_phys_to_bus()/dev_bus_to_phys() dm: test: Add test case for dev_phys_to_bus()/dev_bus_to_phys() xhci: translate virtual addresses into the bus's address space mmc: Introduce mmc_phys_to_bus()/mmc_bus_to_phys() configs: rpi4: Enable DM_DMA across all RPi4 configurations video: arm: rpi: Add brcm,bcm2711-hdmi0 compatible arch/sandbox/dts/test.dts | 21 + board/raspberrypi/rpi/rpi.c| 17 common/fdt_support.c | 73 +++ configs/rpi_4_32b_defconfig| 1 + configs/rpi_4_defconfig| 3 + configs/rpi_arm64_defconfig| 3 + configs/sandbox64_defconfig| 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_spl_defconfig | 1 + drivers/core/Kconfig | 10 ++ drivers/core/device.c | 41 drivers/core/of_addr.c | 78 drivers/core/ofnode.c | 9 ++ drivers/core/read.c| 6 ++ drivers/mmc/sdhci.c| 10 +- drivers/pci/pcie_brcmstb.c | 32 +-- drivers/rng/Kconfig| 6 ++ drivers/rng/Makefile | 1 + drivers/rng/iproc_rng200.c | 185 + drivers/usb/host/xhci-mem.c| 45 - drivers/usb/host/xhci-pci.c| 2 +- drivers/usb/host/xhci-ring.c | 13 ++- drivers/usb/host/xhci.c| 4 +- drivers/video/bcm2835.c| 1 + include/dm/device.h| 13 +++ include/dm/of_addr.h | 17 include/dm/ofnode.h| 16 include/dm/read.h | 21 + include/fdt_support.h | 14 +++ include/mmc.h | 6 ++ include/phys2bus.h | 17 include/usb/xhci.h | 20 +++- test/dm/Makefile | 2 + test/dm/core.c | 30 ++ test/dm/phys2bus.c | 37 test/dm/read.c | 49 ++ 37 files changed, 766 insertions(+), 41 deletions(-) create mode 100644 drivers/rng/iproc_rng200.c create mode 100644 test/dm/phys2bus.c create mode 100644 test/dm/read.c
Re: [PATCH] rng: iProc rng200: Rename ..._platdata variables to just ..._plat
On Fri, Feb 19, 2021 at 04:00:50PM -0500, Tom Rini wrote:
> On Thu, Feb 18, 2021 at 08:39:42PM +, Peter Robinson wrote:
> > On Thu, Feb 18, 2021 at 8:36 PM Heinrich Schuchardt
> > wrote:
> > >
> > > On 18.02.21 21:06, Peter Robinson wrote:
> > > > In 8a8d24bd Simon dropped data from all the various _platdata calls
> > > > but it seems this wasn't caught for the RNG200 driver from when it
> > > > was posted to merged. This fixes that issue.
> > > >
> > > > Fixes: 537f0018 (rng: Add iProc RNG200 driver)
> > > > Signed-off-by: Peter Robinson
> > > > ---
> > > > drivers/rng/iproc_rng200.c | 20 ++--
> > > > 1 file changed, 10 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/rng/iproc_rng200.c b/drivers/rng/iproc_rng200.c
> > > > index f71f285f53..1126bbd797 100644
> > > > --- a/drivers/rng/iproc_rng200.c
> > > > +++ b/drivers/rng/iproc_rng200.c
> > > > @@ -33,11 +33,11 @@
> > > > #define RNG_FIFO_COUNT_OFFSET0x24
> > > > #define RNG_FIFO_COUNT_RNG_FIFO_COUNT_MASK 0x00FF
> > > >
> > > > -struct iproc_rng200_platdata {
> > > > +struct iproc_rng200_plat {
> > >
> > > The renaming of the structure seems to be unrelated to the commit message.
> > >
> > > You are moving from allocating via plat_auto to priv_auto. So a
> > > reasonable name for the structure would be iproc_rng200_priv.
> > >
> > > > fdt_addr_t base;
> > > > };
> > > >
> > > > -static void iproc_rng200_enable(struct iproc_rng200_platdata *pdata,
> > > > bool enable)
> > > > +static void iproc_rng200_enable(struct iproc_rng200_plat *pdata, bool
> > > > enable)
> > > > {
> > > > fdt_addr_t rng_base = pdata->base;
> > > > u32 val;
> > > > @@ -52,7 +52,7 @@ static void iproc_rng200_enable(struct
> > > > iproc_rng200_platdata *pdata, bool enable
> > > > writel(val, rng_base + RNG_CTRL_OFFSET);
> > > > }
> > > >
> > > > -static void iproc_rng200_restart(struct iproc_rng200_platdata *pdata)
> > > > +static void iproc_rng200_restart(struct iproc_rng200_plat *pdata)
> > > > {
> > > > fdt_addr_t rng_base = pdata->base;
> > > > u32 val;
> > > > @@ -84,7 +84,7 @@ static void iproc_rng200_restart(struct
> > > > iproc_rng200_platdata *pdata)
> > > >
> > > > static int iproc_rng200_read(struct udevice *dev, void *data, size_t
> > > > len)
> > > > {
> > > > - struct iproc_rng200_platdata *priv = dev_get_plat(dev);
> > > > + struct iproc_rng200_plat *priv = dev_get_plat(dev);
> > >
> > > At the end of the patch you move from plat_auto to priv_auto. So
> > > shouldn't you call dev_get_priv(dev)?
> > >
> > > > char *buf = (char *)data;
> > > > u32 num_remaining = len;
> > > > u32 status;
> > > > @@ -136,7 +136,7 @@ static int iproc_rng200_read(struct udevice *dev,
> > > > void *data, size_t len)
> > > >
> > > > static int iproc_rng200_probe(struct udevice *dev)
> > > > {
> > > > - struct iproc_rng200_platdata *priv = dev_get_plat(dev);
> > > > + struct iproc_rng200_plat *priv = dev_get_plat(dev);
> > > >
> > > > iproc_rng200_enable(priv, true);
> > > >
> > > > @@ -145,16 +145,16 @@ static int iproc_rng200_probe(struct udevice *dev)
> > > >
> > > > static int iproc_rng200_remove(struct udevice *dev)
> > > > {
> > > > - struct iproc_rng200_platdata *priv = dev_get_plat(dev);
> > > > + struct iproc_rng200_plat *priv = dev_get_plat(dev);
> > > >
> > > > iproc_rng200_enable(priv, false);
> > > >
> > > > return 0;
> > > > }
> > > >
> > > > -static int iproc_rng200_ofdata_to_platdata(struct udevice *dev)
> > > > +static int iproc_rng200_of_to_plat(struct udevice *dev)
> > > > {
> > > > - struct iproc_rng200_platdata *pdata = dev_get_plat(dev);
> > > > + struct iproc_rng200_plat *pdata = dev_get_plat(dev);
> > > >
> > > > pdata->base = dev_read_addr(dev);
> > > > if (!pdata->base)
> > > > @@ -180,6 +180,6 @@ U_BOOT_DRIVER(iproc_rng200_rng) = {
> > > > .ops = &iproc_rng200_ops,
> > > > .probe = iproc_rng200_probe,
> > > > .remove = iproc_rng200_remove,
> > > > - .plat_auto = sizeof(struct iproc_rng200_platdata),
> > > > - .of_to_plat = iproc_rng200_ofdata_to_platdata,
> > > > + .priv_auto = sizeof(struct iproc_rng200_plat),
> > > > + .of_to_plat = iproc_rng200_of_to_plat,
> > >
> > > Why do you set of_to_plat if you are using priv_auto data?
> > > I would have expected the probe function to fill the auto allocated
> > > private data.
> >
> > I based the change on Simon's changes
>
> Yeah, this is fine, it was generally a global search and replace on all
> the structs and funcs. I'll pick this up (and some similar patches)
> soon, and just be a little annoyed at all the code that's clearly not
> getting built somehow today. It'd be great to figure out if it should
> be in some defconfig or what.
>
Tom, please keep me in the loop when you notify that you pushed this to
master. I have some patches in my queue that will en
[GIT PULL] rpi: second round of updates for v2021.04
Hi Tom, Below are the second round of updates for Raspberry Pi aimed for the v2021.04 release. The green CI loop can be found here: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/6579 Please have a look. Regards, Matthias --- The following changes since commit c5219c4a18f2b27547ecd799914f94e48b0fa86f: Prepare v2021.04-rc3 (2021-03-01 22:46:41 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-next-2021.04.2 for you to fetch changes up to fae165b5a1991ca55acfb3dc78f3c473275b3faf: configs: rpi4_32: Enable iProc RNG200 (2021-03-02 13:53:53 +0100) - Disable Grub workaround for RPi2 - enable HS200 mode for iproc sdhci - add armv7 support for iproc_rng200 Bharat Gooty (1): drivers: mmc: iproc_sdhci: enable HS200 mode Matthias Brugger (4): configs: RPi2: Disable EFI Grub workaround MAINTAINERS: Update info for Raspberry Pi rng: iproc_rng200: Enable support for RPi4 armv7 configs: rpi4_32: Enable iProc RNG200 MAINTAINERS | 4 +- configs/rpi_2_defconfig | 1 + configs/rpi_4_32b_defconfig | 2 + drivers/mmc/iproc_sdhci.c | 92 - drivers/rng/iproc_rng200.c | 8 ++-- 5 files changed, 93 insertions(+), 14 deletions(-)
Re: [PATCH v4 0/9] USB host support for Raspberry Pi 4 board (64-bit)
On 25/05/2020 13:39, Sylwester Nawrocki wrote: Hi all, This patch series adds USB host support for Raspberry Pi 4 board. It includes the Broadcom STB PCIe controller driver ported from Linux kernel, a memory mapping update for the xHCI controller on PCIe bus for 64-bit builds and some related fixes and updates in the usb/xhci and the pci driver core code. The 32-bit ARM part has be excluded from the series and will be posted separately. The difference comparing to previous version is only in the config update patch "configs: Enable support for the XHCI controller on RPI4 board (ARM 64-bit)". The patch series is based on v2020.07-rc1 tree. Thanks, Sylwester Marek Szyprowski (3): rpi4: shorten a mapping for the DRAM rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit) configs: Enable support for the XHCI controller on RPI4 board (ARM 64-bit) Nicolas Saenz Julienne (1): linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian Sylwester Nawrocki (5): usb: xhci: Add missing cache flush in the scratchpad array initialization usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq pci: Move some PCIe register offset definitions to a common header pci: Add some PCI Express capability register offset definitions pci: Add driver for Broadcom BCM2711 SoC PCIe controller Applied now to rpi-next Thanks! arch/arm/mach-bcm283x/init.c | 20 +- configs/rpi_4_defconfig | 9 + configs/rpi_arm64_defconfig | 8 +- drivers/pci/Kconfig | 9 + drivers/pci/Makefile | 1 + drivers/pci/pci-rcar-gen3.c | 8 - drivers/pci/pcie_brcmstb.c| 623 ++ drivers/pci/pcie_intel_fpga.c | 3 - drivers/usb/host/xhci-mem.c | 3 + include/linux/bitfield.h | 52 include/pci.h | 22 +- include/usb/xhci.h| 8 - 12 files changed, 740 insertions(+), 26 deletions(-) create mode 100644 drivers/pci/pcie_brcmstb.c
Re: [PATCH v6 0/4] usb: xhci: Load Raspberry Pi 4 VL805's firmware
On 29/06/2020 18:37, Nicolas Saenz Julienne wrote:
Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be
loaded explicitly. Earlier versions didn't need that as they where using
an EEPROM for that purpose. This series takes care of setting up the
relevant infrastructure and run the firmware loading routine at the
right moment.
Note that this builds on top of Sylwester Nawrocki's "USB host support
for Raspberry Pi 4 board" series.
This also depends on a DT/bindings patch available on the linux-mailing lists:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2205783.html
Here is the relevant bit for reference/discussion:
&pcie0 {
pci@1,0 {
#address-cells = <3>;
#size-cells = <2>;
ranges;
reg = <0 0 0 0 0>;
usb@1,0 {
reg = <0x1 0 0 0 0>;
resets = <&reset
RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
};
};
};
---
Changes since v5:
- Properly handle !CONFIG_IS_ENABLED(DM_RESET) in xchi code
Changes since v4:
- Correct DT PCI topology, I separated the root bridge and controller
DT nodes
- Get rid of PCI core patch as not needed with correct DT PCI topology
- Move reset support to xchi core
Changes since v3:
- Use reset controller
Changes since v2:
- Correct comment on patch #1
- Address Matthias' comments
Changes since v1:
- Rename function
- Use callback in xhci-pci.c
Nicolas Saenz Julienne (4):
arm: rpi: Add function to trigger VL805's firmware load
reset: Add Raspberry Pi 4 firmware reset controller
configs: Enable support for reset controllers on RPi4
usb: xhci: Add reset controller support
Applied now to rpi-next
Thanks!
arch/arm/mach-bcm283x/include/mach/mbox.h | 13
arch/arm/mach-bcm283x/include/mach/msg.h | 7 +++
arch/arm/mach-bcm283x/msg.c | 46 ++
configs/rpi_4_32b_defconfig | 1 +
configs/rpi_4_defconfig | 1 +
configs/rpi_arm64_defconfig | 1 +
drivers/reset/Kconfig | 10
drivers/reset/Makefile| 1 +
drivers/reset/reset-raspberrypi.c | 60 +++
drivers/usb/host/xhci-mem.c | 2 +
drivers/usb/host/xhci.c | 33 ++
.../reset/raspberrypi,firmware-reset.h| 13
include/usb/xhci.h| 2 +
13 files changed, 190 insertions(+)
create mode 100644 drivers/reset/reset-raspberrypi.c
create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h
CONFIG_NR_DRAM_BANKS in configs/rpi_4* deleted
Hi Tom,
I just realized that
88bd5b1793 ("configs: Resync with savedefconfig")
Delete the CONFIG_NR_DRAM_BANKS entries as added in this patch, which leads to a
regression in RPi4 (only one GB of memory visible to the kernel if you use Grub
for booting).
Is it generally wrong to add CONFIG_NR_DRAM_BANKS to the config files? What is
the correct approach then?
Regards,
Matthias
On 29/05/2020 16:42, matthias@kernel.org wrote:
From: Matthias Brugger
With the new RPi4 which has 8 GB of RAM, we can have up to four DRAM
banks. Bump up the configuration files to detect all the memory in
U-Boot.
Signed-off-by: Matthias Brugger
---
configs/rpi_4_32b_defconfig | 2 +-
configs/rpi_4_defconfig | 2 +-
configs/rpi_arm64_defconfig | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
index b22316cbcb..f369bb93bd 100644
--- a/configs/rpi_4_32b_defconfig
+++ b/configs/rpi_4_32b_defconfig
@@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x8000
CONFIG_TARGET_RPI_4_32B=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_ENV_SIZE=0x4000
-CONFIG_NR_DRAM_BANKS=2
+CONFIG_NR_DRAM_BANKS=4
CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_ARCH_FIXUP_FDT_MEMORY=y
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index 165e166bbd..9b90790f06 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x0008
CONFIG_TARGET_RPI_4=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_ENV_SIZE=0x4000
-CONFIG_NR_DRAM_BANKS=2
+CONFIG_NR_DRAM_BANKS=4
CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_ARCH_FIXUP_FDT_MEMORY=y
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index 0cc4efad70..db375eeba7 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x0008
CONFIG_TARGET_RPI_ARM64=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_ENV_SIZE=0x4000
-CONFIG_NR_DRAM_BANKS=2
+CONFIG_NR_DRAM_BANKS=4
CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_USE_PREBOOT=y
Re: [PATCH] config: Enable USB Keyboard support on RPi4
On 05/05/2020 16:51, Nicolas Saenz Julienne wrote: Supporting USB keyboards out of the box is both handy for development and production. Notably if u-boot is used to boot into GRUB. Signed-off-by: Nicolas Saenz Julienne Applied to rpi-next now. I dropped the hunk for 32 bit for now, please resend once 32 bit support got accepted. Regards, Matthias --- Note that rpi_arm64_defconfig already supports USB keyboard. This is to be applied on top of Sylwester Nawrocki's PCIe/xHCI on RPi4 series. configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig index dd7da1cf06..9c5ad7684e 100644 --- a/configs/rpi_4_32b_defconfig +++ b/configs/rpi_4_32b_defconfig @@ -42,6 +42,7 @@ CONFIG_DM_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PCI=y +CONFIG_USB_KEYBOARD=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="FSL" CONFIG_USB_GADGET_VENDOR_NUM=0x0525 diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig index 6eeec4592e..1a92cd637e 100644 --- a/configs/rpi_4_defconfig +++ b/configs/rpi_4_defconfig @@ -42,6 +42,7 @@ CONFIG_DM_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PCI=y +CONFIG_USB_KEYBOARD=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="FSL" CONFIG_USB_GADGET_VENDOR_NUM=0x0525
Re: [PATCH v5 0/6] ARM: arbitrary virtual-physical mappings for RPi4 XHCI support
Hi Marek, On 09/07/2020 08:33, Marek Szyprowski wrote: Hi Matthias, On 11.06.2020 10:39, Matthias Brugger wrote: ... Series looks good to me. The problem is that on RPi4 with 8 GB the USB FW get's loaded via the RPi FW. Nicolas provided a series which is under review right now. Without this series the 8 GB RPi4 won't boot. As soon as the series is ready I'll take all the RPi4 PCI/USB related patches into the next branch. I've noticed that You took both required patchsets to rpi-next branch. May I ask for taking this one too? I didn't forgot that series. The thing is, that it is assigned to Tom in patchwork, so I wanted to sync with him, if he is OK that I take the series. He provided already his Reviewed-by tags for the parts that I was concerned about. @Tom, is it OK if I take this series through my rpi-next branch? Regards, Matthias
Re: [PATCH v4 6/9] linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian
On 25/05/2020 13:39, Sylwester Nawrocki wrote:
From: Nicolas Saenz Julienne
Imports Al Viro's original Linux commit 00b0c9b82663a, which contains
an in depth explanation and two fixes from Johannes Berg:
e7d4a95da86e0 "bitfield: fix *_encode_bits()",
37a3862e12382 "bitfield: add u8 helpers".
Signed-off-by: Nicolas Saenz Julienne
[s.nawrocki: added empty lines between functions and macros]
Signed-off-by: Sylwester Nawrocki
This seems to break compilation of
arch/arm/mach-uniphier/clk/pll-base-ld20.c
https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/jobs/121248
Nicolas, Sylwester, can you please have a look.
Regards,
Matthias
---
Changes since v3:
- none.
Changes since v2:
- added some more missing whitespaces as pointed out by checkpatch.pl.
Changes since v1:
- added empty lines between functions and macros.
Changes since RFC:
- new patch.
---
include/linux/bitfield.h | 52
1 file changed, 52 insertions(+)
diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index 8b9d6ff..7ad8b08 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -103,4 +103,56 @@
(typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
})
+extern void __compiletime_error("value doesn't fit into mask")
+__field_overflow(void);
+extern void __compiletime_error("bad bitfield mask")
+__bad_mask(void);
+
+static __always_inline u64 field_multiplier(u64 field)
+{
+ if ((field | (field - 1)) & ((field | (field - 1)) + 1))
+ __bad_mask();
+ return field & -field;
+}
+
+static __always_inline u64 field_mask(u64 field)
+{
+ return field / field_multiplier(field);
+}
+
+#define MAKE_OP(type, base, to, from) \
+static __always_inline __##type type##_encode_bits(base v, base field) \
+{ \
+ if (__builtin_constant_p(v) && (v & ~field_mask(field)))\
+ __field_overflow(); \
+ return to((v & field_mask(field)) * field_multiplier(field)); \
+} \
+static __always_inline __##type type##_replace_bits(__##type old, \
+ base val, base field) \
+{ \
+ return (old & ~to(field)) | type##_encode_bits(val, field); \
+} \
+static __always_inline void type##p_replace_bits(__##type * p, \
+ base val, base field) \
+{ \
+ *p = (*p & ~to(field)) | type##_encode_bits(val, field);\
+} \
+static __always_inline base type##_get_bits(__##type v, base field)\
+{ \
+ return (from(v) & field) / field_multiplier(field); \
+}
+
+#define __MAKE_OP(size)
\
+ MAKE_OP(le##size, u##size, cpu_to_le##size, le##size##_to_cpu) \
+ MAKE_OP(be##size, u##size, cpu_to_be##size, be##size##_to_cpu) \
+ MAKE_OP(u##size, u##size, ,)
+
+MAKE_OP(u8, u8, ,)
+__MAKE_OP(16)
+__MAKE_OP(32)
+__MAKE_OP(64)
+
+#undef __MAKE_OP
+#undef MAKE_OP
+
#endif
Re: [PATCH v4 6/9] linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian
On 09/07/2020 17:35, Matthias Brugger wrote:
On 25/05/2020 13:39, Sylwester Nawrocki wrote:
From: Nicolas Saenz Julienne
Imports Al Viro's original Linux commit 00b0c9b82663a, which contains
an in depth explanation and two fixes from Johannes Berg:
e7d4a95da86e0 "bitfield: fix *_encode_bits()",
37a3862e12382 "bitfield: add u8 helpers".
Signed-off-by: Nicolas Saenz Julienne
[s.nawrocki: added empty lines between functions and macros]
Signed-off-by: Sylwester Nawrocki
This seems to break compilation of
arch/arm/mach-uniphier/clk/pll-base-ld20.c
https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/jobs/121248
Nicolas, Sylwester, can you please have a look.
Just in case you can't access the URL:
https://pastebin.com/KhDHf8e1
Regards,
Matthias
---
Changes since v3:
- none.
Changes since v2:
- added some more missing whitespaces as pointed out by checkpatch.pl.
Changes since v1:
- added empty lines between functions and macros.
Changes since RFC:
- new patch.
---
include/linux/bitfield.h | 52
1 file changed, 52 insertions(+)
diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index 8b9d6ff..7ad8b08 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -103,4 +103,56 @@
(typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
})
+extern void __compiletime_error("value doesn't fit into mask")
+__field_overflow(void);
+extern void __compiletime_error("bad bitfield mask")
+__bad_mask(void);
+
+static __always_inline u64 field_multiplier(u64 field)
+{
+ if ((field | (field - 1)) & ((field | (field - 1)) + 1))
+ __bad_mask();
+ return field & -field;
+}
+
+static __always_inline u64 field_mask(u64 field)
+{
+ return field / field_multiplier(field);
+}
+
+#define MAKE_OP(type, base, to, from) \
+static __always_inline __##type type##_encode_bits(base v, base field) \
+{ \
+ if (__builtin_constant_p(v) && (v & ~field_mask(field))) \
+ __field_overflow(); \
+ return to((v & field_mask(field)) * field_multiplier(field)); \
+} \
+static __always_inline __##type type##_replace_bits(__##type old, \
+ base val, base field) \
+{ \
+ return (old & ~to(field)) | type##_encode_bits(val, field); \
+} \
+static __always_inline void type##p_replace_bits(__##type * p, \
+ base val, base field) \
+{ \
+ *p = (*p & ~to(field)) | type##_encode_bits(val, field); \
+} \
+static __always_inline base type##_get_bits(__##type v, base field) \
+{ \
+ return (from(v) & field) / field_multiplier(field); \
+}
+
+#define __MAKE_OP(size) \
+ MAKE_OP(le##size, u##size, cpu_to_le##size, le##size##_to_cpu) \
+ MAKE_OP(be##size, u##size, cpu_to_be##size, be##size##_to_cpu) \
+ MAKE_OP(u##size, u##size, ,)
+
+MAKE_OP(u8, u8, ,)
+__MAKE_OP(16)
+__MAKE_OP(32)
+__MAKE_OP(64)
+
+#undef __MAKE_OP
+#undef MAKE_OP
+
#endif
Re: [PATCH v6 4/4] usb: xhci: Add reset controller support
On 29/06/2020 18:37, Nicolas Saenz Julienne wrote:
Some atypical users of xhci might need to manually reset their xHCI
controller before starting the HCD setup. Check if a reset controller
device is available to the PCI bus and trigger a reset.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v5:
- Take !CONFIG_IS_ENABLED(DM_RESET) into account
drivers/usb/host/xhci-mem.c | 2 ++
drivers/usb/host/xhci.c | 33 +
include/usb/xhci.h | 2 ++
3 files changed, 37 insertions(+)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index f446520528..108f4bd8cf 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -180,6 +180,8 @@ void xhci_cleanup(struct xhci_ctrl *ctrl)
xhci_free_virt_devices(ctrl);
free(ctrl->erst.entries);
free(ctrl->dcbaa);
+ if (reset_valid(&ctrl->reset))
+ reset_free(&ctrl->reset);
memset(ctrl, '\0', sizeof(struct xhci_ctrl));
}
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ebd2954571..e252964d0d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -190,6 +190,35 @@ static int xhci_start(struct xhci_hcor *hcor)
return ret;
}
+/**
+ * Resets XHCI Hardware
+ *
+ * @param ctrl pointer to host controller
+ * @return 0 if OK, or a negative error code.
+ */
+static int xhci_reset_hw(struct xhci_ctrl *ctrl)
+{
+ int ret;
+
+ ret = reset_get_by_index(ctrl->dev, 0, &ctrl->reset);
That seems to break arm32 builds:
https://pastebin.com/eHBf7Xp0
https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/jobs/121247
Nicolas, can you have a look?
Thanks
Matthias
+ if (ret && ret != -ENOENT && ret != -ENOTSUPP) {
+ dev_err(ctrl->dev, "failed to get reset\n");
+ return ret;
+ }
+
+ if (reset_valid(&ctrl->reset)) {
+ ret = reset_assert(&ctrl->reset);
+ if (ret)
+ return ret;
+
+ ret = reset_deassert(&ctrl->reset);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
/**
* Resets the XHCI Controller
*
@@ -1508,6 +1537,10 @@ int xhci_register(struct udevice *dev, struct xhci_hccr
*hccr,
ctrl->dev = dev;
+ ret = xhci_reset_hw(ctrl);
+ if (ret)
+ goto err;
+
/*
* XHCI needs to issue a Address device command to setup
* proper device context structures, before it can interact
diff --git a/include/usb/xhci.h b/include/usb/xhci.h
index 1170c0ac69..7d34103fd5 100644
--- a/include/usb/xhci.h
+++ b/include/usb/xhci.h
@@ -16,6 +16,7 @@
#ifndef HOST_XHCI_H_
#define HOST_XHCI_H_
+#include
#include
#include
#include
@@ -1209,6 +1210,7 @@ struct xhci_ctrl {
#if CONFIG_IS_ENABLED(DM_USB)
struct udevice *dev;
#endif
+ struct reset_ctl reset;
struct xhci_hccr *hccr; /* R/O registers, not need for volatile */
struct xhci_hcor *hcor;
struct xhci_doorbell_array *dba;
Re: [PATCH] xhci: Only build xhci_reset_hw() if CONFIG_DM_USB is enabled
On 09/07/2020 19:31, Nicolas Saenz Julienne wrote: This was breaking build on some configurations. Signed-off-by: Nicolas Saenz Julienne --- Matthias, I don't know if it's possible at this stage, but I'd ideally squash this into the offending patch. I'll test the patch and squash. Thanks! drivers/usb/host/xhci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index e252964d0d..f635bb39f6 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -190,6 +190,7 @@ static int xhci_start(struct xhci_hcor *hcor) return ret; } +#if CONFIG_IS_ENABLED(DM_USB) /** * Resets XHCI Hardware * @@ -218,6 +219,7 @@ static int xhci_reset_hw(struct xhci_ctrl *ctrl) return 0; } +#endif /** * Resets the XHCI Controller
Re: [PATCH] include/bitfield.h: include byteorder.h
On 09/07/2020 19:41, Nicolas Saenz Julienne wrote: This is needed in order to use the cpu_to_*()/*_to_cpu() family of functions. Signed-off-by: Nicolas Saenz Julienne --- IMO the ideal thing would be to squash this into the original patch. I'll test and squash, thanks! include/linux/bitfield.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h index 7ad8b088ed..7ad02f8cbb 100644 --- a/include/linux/bitfield.h +++ b/include/linux/bitfield.h @@ -16,6 +16,7 @@ #define _LINUX_BITFIELD_H #include +#include /* * Bitfield access macros
[GIT PULL] rpi-next for v2020.10
Hi Tom, Please have a look on the first pull request for RPi for the future v2020.10 release. With this patches accepted we will have USB support on 64 bit. 32 bit support is in the works and should land in v2020.10 as well. Please pull :) Regards, Matthias --- The following changes since commit 61608f395e7dcb2be6060407a72a1149b046430a: Merge branch '2020-07-08-misc-features-and-fixes' (2020-07-08 20:20:24 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-next-2020.10 for you to fetch changes up to d6ecb71a1f0c764c94f1bb381f085734d57e94e9: config: Enable USB Keyboard support on RPi4 (2020-07-10 11:50:36 +0200) - add support for PCI and XHCI for RPi4 (64 bit only) - optionally reset XHCI device on registration - enable USB_KEYBOARD for rpi_4_defconfig Marek Szyprowski (3): rpi4: shorten a mapping for the DRAM rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit) configs: Enable support for the XHCI controller on RPI4 board (ARM 64-bit) Nicolas Saenz Julienne (6): linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian arm: rpi: Add function to trigger VL805's firmware load reset: Add Raspberry Pi 4 firmware reset controller configs: Enable support for reset controllers on RPi4 usb: xhci: Add reset controller support config: Enable USB Keyboard support on RPi4 Sylwester Nawrocki (5): usb: xhci: Add missing cache flush in the scratchpad array initialization usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq pci: Move some PCIe register offset definitions to a common header pci: Add some PCI Express capability register offset definitions pci: Add driver for Broadcom BCM2711 SoC PCIe controller arch/arm/mach-bcm283x/include/mach/mbox.h | 13 + arch/arm/mach-bcm283x/include/mach/msg.h | 7 + arch/arm/mach-bcm283x/init.c | 20 +- arch/arm/mach-bcm283x/msg.c| 46 ++ configs/rpi_4_32b_defconfig| 1 + configs/rpi_4_defconfig| 11 + configs/rpi_arm64_defconfig| 9 +- drivers/pci/Kconfig| 9 + drivers/pci/Makefile | 1 + drivers/pci/pci-rcar-gen3.c| 8 - drivers/pci/pcie_brcmstb.c | 623 + drivers/pci/pcie_intel_fpga.c | 3 - drivers/reset/Kconfig | 11 + drivers/reset/Makefile | 1 + drivers/reset/reset-raspberrypi.c | 60 ++ drivers/usb/host/xhci-mem.c| 5 + drivers/usb/host/xhci.c| 35 ++ .../dt-bindings/reset/raspberrypi,firmware-reset.h | 13 + include/linux/bitfield.h | 53 ++ include/pci.h | 22 +- include/usb/xhci.h | 10 +- 21 files changed, 935 insertions(+), 26 deletions(-) create mode 100644 drivers/pci/pcie_brcmstb.c create mode 100644 drivers/reset/reset-raspberrypi.c create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h
Re: [GIT PULL] rpi-next for v2020.10
On 10/07/2020 16:50, Matthias Brugger wrote: Hi Tom, Please have a look on the first pull request for RPi for the future v2020.10 release. With this patches accepted we will have USB support on 64 bit. 32 bit support is in the works and should land in v2020.10 as well. Like many times I forgot to add the links to the CI pipelines: https://travis-ci.org/github/mbgg/u-boot/builds/706819202 https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/pipelines/3987 The branch is rpi-next but the commit ID should be the same as the tag. Regards, Matthias Please pull :) Regards, Matthias --- The following changes since commit 61608f395e7dcb2be6060407a72a1149b046430a: Merge branch '2020-07-08-misc-features-and-fixes' (2020-07-08 20:20:24 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-next-2020.10 for you to fetch changes up to d6ecb71a1f0c764c94f1bb381f085734d57e94e9: config: Enable USB Keyboard support on RPi4 (2020-07-10 11:50:36 +0200) - add support for PCI and XHCI for RPi4 (64 bit only) - optionally reset XHCI device on registration - enable USB_KEYBOARD for rpi_4_defconfig Marek Szyprowski (3): rpi4: shorten a mapping for the DRAM rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit) configs: Enable support for the XHCI controller on RPI4 board (ARM 64-bit) Nicolas Saenz Julienne (6): linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian arm: rpi: Add function to trigger VL805's firmware load reset: Add Raspberry Pi 4 firmware reset controller configs: Enable support for reset controllers on RPi4 usb: xhci: Add reset controller support config: Enable USB Keyboard support on RPi4 Sylwester Nawrocki (5): usb: xhci: Add missing cache flush in the scratchpad array initialization usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq pci: Move some PCIe register offset definitions to a common header pci: Add some PCI Express capability register offset definitions pci: Add driver for Broadcom BCM2711 SoC PCIe controller arch/arm/mach-bcm283x/include/mach/mbox.h | 13 + arch/arm/mach-bcm283x/include/mach/msg.h | 7 + arch/arm/mach-bcm283x/init.c | 20 +- arch/arm/mach-bcm283x/msg.c | 46 ++ configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 11 + configs/rpi_arm64_defconfig | 9 +- drivers/pci/Kconfig | 9 + drivers/pci/Makefile | 1 + drivers/pci/pci-rcar-gen3.c | 8 - drivers/pci/pcie_brcmstb.c | 623 + drivers/pci/pcie_intel_fpga.c | 3 - drivers/reset/Kconfig | 11 + drivers/reset/Makefile | 1 + drivers/reset/reset-raspberrypi.c | 60 ++ drivers/usb/host/xhci-mem.c | 5 + drivers/usb/host/xhci.c | 35 ++ .../dt-bindings/reset/raspberrypi,firmware-reset.h | 13 + include/linux/bitfield.h | 53 ++ include/pci.h | 22 +- include/usb/xhci.h | 10 +- 21 files changed, 935 insertions(+), 26 deletions(-) create mode 100644 drivers/pci/pcie_brcmstb.c create mode 100644 drivers/reset/reset-raspberrypi.c create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h
Re: RPI4: fail too boot with an initrd
On 17/02/2020 11:37, LABBE Corentin wrote:
> On Fri, Feb 14, 2020 at 06:15:27PM +, James Morse wrote:
>> Hi Corentin,
>>
>> On 14/02/2020 13:27, LABBE Corentin wrote:
>>> Since the inclusion of the "enable network support in RPi4 config" serie on
>>> uboot, I
>>> have started to work on adding the rpi4 in kernelCI.
>>> But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp.
>>>
>>> Using booti I hit:
>>> [0.00] Linux version 5.6.0-rc1-next-20200212
>>> (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02
>>> revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (LinaroGCC
>>> 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 2020
>>> [0.00] Machine model: Raspberry Pi 4 Model B
>>> [0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
>>> [0.00] printk: bootconsole [uart0] enabled
>>> [0.00] efi: Getting EFI parameters from FDT:
>>> [0.00] efi: UEFI not found.
>>
>> So no EFI,
>>
>>> [0.00] OF: reserved mem: failed to allocate memory for node
>>> 'linux,cma'
>>
>> Out of memory.
>>
>>> [0.00] cma: Failed to reserve 32 MiB
>>> [0.00] Kernel panic - not syncing: Failed to allocate page table
>>> page
>>
>> Out of memory...
>>
>>> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
>>> 5.6.0-rc1-next-20200212 #66
>>> [0.00] Hardware name: Raspberry Pi 4 Model B (DT)
>>> [0.00] Call trace:
>>> [0.00] dump_backtrace+0x0/0x1a0
>>> [0.00] show_stack+0x14/0x20
>>> [0.00] dump_stack+0xbc/0x104
>>> [0.00] panic+0x16c/0x37c
>>> [0.00] early_pgtable_alloc+0x30/0xa0
>>
>> ... really early!
>>
>>> [0.00] __create_pgd_mapping+0x36c/0x588
>>> [0.00] map_kernel_segment+0x70/0xa4
>>> [0.00] paging_init+0xf4/0x528
>>> [0.00] setup_arch+0x250/0x5d8
>>> [0.00] start_kernel+0x90/0x6d8
>>>
>>>
>>> Since the same kernel boot with bootefi and that bootefi lack ramdisk
>>> address,
>>
>> Booting with EFI will cause linux to use the EFI memory map.
>>
>> Does your DT have a memory node? (or does it expect EFI to provide the
>> information)
>>
>>
>>> I tried to add the address in the dtb via:
>>> fdt addr 0x0240; fdt resize; fdt set /chosen linux,initrd-start
>>> 0x0270; fdt set /chosen linux,initrd-end 0x1000; bootefi 0x0008
>>> 0x0240
>>> But with that, I get:
>>> initrd not fully accessible via the linear mapping -- please check your
>>> bootloader ...
>>
>> So this one is an EFI boot, but you can't find where to put the initramfs
>> such that the
>> kernel agrees its in memory.
>>
>> If you boot with 'efi=debug', linux will print the EFI memory map. Could you
>> compare that
>> to where U-Boot thinks memory is?
>>
>> (it sounds like your DT memory node is missing, and your EFI memory map is
>> surprisingly small)
>
> Hello
>
> Thanks for your advices.
>
> In the dtb of mainline linux:
> /* Will be filled by the bootloader */
> memory@0 {
> device_type = "memory";
> reg = <0 0 0>;
> };
>
> In uboot I have:
> static struct mm_region bcm2711_mem_map[] = {
> {
> .virt = 0xUL,
> .phys = 0xUL,
> .size = 0xfe00UL,
> .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> PTE_BLOCK_INNER_SHARE
> }, {
> .virt = 0xfc00UL,
> .phys = 0xfc00UL,
> .size = 0x0380UL,
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> PTE_BLOCK_NON_SHARE |
> PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* List terminator */
> 0,
> }
> };
> But I dont know if uboot use that for filling the memory node.
No it doesn't. U-Boot uses the DT from the firmware and passes this to the
kernel. But it seems you pass instead your own device-tree to the kernel, so you
will need to update the memory node to show the available memory on you board.
Regards,
Matthias
>
>
> Booting the rpi4 with efi=debug give:
> EFI stub: Booting Linux Kernel...
> EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> [0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
> [0.00] Linux version 5.6.0-rc1-next-20200214
> (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02
> revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02))
> #70 SMP PREEMPT Fri Feb 14 10:54:54 UTC 2020
> [0.00] Machine model: Raspberry Pi 4 Model B
> [0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
> [0.00] printk: bootconsole [uart0] enabled
> [0.00] efi: Getting EFI parameters
Re: RPI4: fail too boot with an initrd
On 17/02/2020 13:53, LABBE Corentin wrote:
> On Mon, Feb 17, 2020 at 11:50:04AM +0100, Matthias Brugger wrote:
>>
>>
>> On 17/02/2020 11:37, LABBE Corentin wrote:
>>> On Fri, Feb 14, 2020 at 06:15:27PM +, James Morse wrote:
>>>> Hi Corentin,
>>>>
>>>> On 14/02/2020 13:27, LABBE Corentin wrote:
>>>>> Since the inclusion of the "enable network support in RPi4 config" serie
>>>>> on uboot, I
>>>>> have started to work on adding the rpi4 in kernelCI.
>>>>> But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp.
>>>>>
>>>>> Using booti I hit:
>>>>> [0.00] Linux version 5.6.0-rc1-next-20200212
>>>>> (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213
>>>>> [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4]
>>>>> (LinaroGCC 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 2020
>>>>> [0.00] Machine model: Raspberry Pi 4 Model B
>>>>> [0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
>>>>> [0.00] printk: bootconsole [uart0] enabled
>>>>> [0.00] efi: Getting EFI parameters from FDT:
>>>>> [0.00] efi: UEFI not found.
>>>>
>>>> So no EFI,
>>>>
>>>>> [0.00] OF: reserved mem: failed to allocate memory for node
>>>>> 'linux,cma'
>>>>
>>>> Out of memory.
>>>>
>>>>> [0.00] cma: Failed to reserve 32 MiB
>>>>> [0.00] Kernel panic - not syncing: Failed to allocate page table
>>>>> page
>>>>
>>>> Out of memory...
>>>>
>>>>> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
>>>>> 5.6.0-rc1-next-20200212 #66
>>>>> [0.00] Hardware name: Raspberry Pi 4 Model B (DT)
>>>>> [0.00] Call trace:
>>>>> [0.00] dump_backtrace+0x0/0x1a0
>>>>> [0.00] show_stack+0x14/0x20
>>>>> [0.00] dump_stack+0xbc/0x104
>>>>> [0.00] panic+0x16c/0x37c
>>>>> [0.00] early_pgtable_alloc+0x30/0xa0
>>>>
>>>> ... really early!
>>>>
>>>>> [0.00] __create_pgd_mapping+0x36c/0x588
>>>>> [0.00] map_kernel_segment+0x70/0xa4
>>>>> [0.00] paging_init+0xf4/0x528
>>>>> [0.00] setup_arch+0x250/0x5d8
>>>>> [0.00] start_kernel+0x90/0x6d8
>>>>>
>>>>>
>>>>> Since the same kernel boot with bootefi and that bootefi lack ramdisk
>>>>> address,
>>>>
>>>> Booting with EFI will cause linux to use the EFI memory map.
>>>>
>>>> Does your DT have a memory node? (or does it expect EFI to provide the
>>>> information)
>>>>
>>>>
>>>>> I tried to add the address in the dtb via:
>>>>> fdt addr 0x0240; fdt resize; fdt set /chosen linux,initrd-start
>>>>> 0x0270; fdt set /chosen linux,initrd-end 0x1000; bootefi
>>>>> 0x0008 0x0240
>>>>> But with that, I get:
>>>>> initrd not fully accessible via the linear mapping -- please check your
>>>>> bootloader ...
>>>>
>>>> So this one is an EFI boot, but you can't find where to put the initramfs
>>>> such that the
>>>> kernel agrees its in memory.
>>>>
>>>> If you boot with 'efi=debug', linux will print the EFI memory map. Could
>>>> you compare that
>>>> to where U-Boot thinks memory is?
>>>>
>>>> (it sounds like your DT memory node is missing, and your EFI memory map is
>>>> surprisingly small)
>>>
>>> Hello
>>>
>>> Thanks for your advices.
>>>
>>> In the dtb of mainline linux:
>>> /* Will be filled by the bootloader */
>>> memory@0 {
>>> device_type = "memory";
>>> reg = <0 0 0>;
>>> };
>>>
>>> In uboot I have:
>>> static struct mm_region bcm2711_mem_map[] = {
>>> {
>>> .virt = 0xUL,
>>> .phys = 0xUL,
>>> .size = 0xfe00UL,
>>>
Re: RPI4: fail too boot with an initrd
On 18/02/2020 11:01, LABBE Corentin wrote: > On Mon, Feb 17, 2020 at 02:07:09PM +0100, Matthias Brugger wrote: >> >> >> On 17/02/2020 13:53, LABBE Corentin wrote: >>> On Mon, Feb 17, 2020 at 11:50:04AM +0100, Matthias Brugger wrote: >>>> >>>> >>>> On 17/02/2020 11:37, LABBE Corentin wrote: >>>>> On Fri, Feb 14, 2020 at 06:15:27PM +, James Morse wrote: >>>>>> Hi Corentin, >>>>>> >>>>>> On 14/02/2020 13:27, LABBE Corentin wrote: >>>>>>> Since the inclusion of the "enable network support in RPi4 config" >>>>>>> serie on uboot, I >>>>>>> have started to work on adding the rpi4 in kernelCI. >>>>>>> But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp. >>>>>>> >>>>>>> Using booti I hit: >>>>>>> [0.00] Linux version 5.6.0-rc1-next-20200212 >>>>>>> (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 >>>>>>> [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] >>>>>>> (LinaroGCC 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC >>>>>>> 2020 >>>>>>> [0.00] Machine model: Raspberry Pi 4 Model B >>>>>>> [0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '') >>>>>>> [0.00] printk: bootconsole [uart0] enabled >>>>>>> [0.00] efi: Getting EFI parameters from FDT: >>>>>>> [0.00] efi: UEFI not found. >>>>>> >>>>>> So no EFI, >>>>>> >>>>>>> [0.00] OF: reserved mem: failed to allocate memory for node >>>>>>> 'linux,cma' >>>>>> >>>>>> Out of memory. >>>>>> >>>>>>> [0.00] cma: Failed to reserve 32 MiB >>>>>>> [0.00] Kernel panic - not syncing: Failed to allocate page >>>>>>> table page >>>>>> >>>>>> Out of memory... >>>>>> >>>>>>> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted >>>>>>> 5.6.0-rc1-next-20200212 #66 >>>>>>> [0.00] Hardware name: Raspberry Pi 4 Model B (DT) >>>>>>> [0.00] Call trace: >>>>>>> [0.00] dump_backtrace+0x0/0x1a0 >>>>>>> [0.00] show_stack+0x14/0x20 >>>>>>> [0.00] dump_stack+0xbc/0x104 >>>>>>> [0.00] panic+0x16c/0x37c >>>>>>> [0.00] early_pgtable_alloc+0x30/0xa0 >>>>>> >>>>>> ... really early! >>>>>> >>>>>>> [0.00] __create_pgd_mapping+0x36c/0x588 >>>>>>> [0.00] map_kernel_segment+0x70/0xa4 >>>>>>> [0.00] paging_init+0xf4/0x528 >>>>>>> [0.00] setup_arch+0x250/0x5d8 >>>>>>> [0.00] start_kernel+0x90/0x6d8 >>>>>>> >>>>>>> >>>>>>> Since the same kernel boot with bootefi and that bootefi lack ramdisk >>>>>>> address, >>>>>> >>>>>> Booting with EFI will cause linux to use the EFI memory map. >>>>>> >>>>>> Does your DT have a memory node? (or does it expect EFI to provide the >>>>>> information) >>>>>> >>>>>> >>>>>>> I tried to add the address in the dtb via: >>>>>>> fdt addr 0x0240; fdt resize; fdt set /chosen linux,initrd-start >>>>>>> 0x0270; fdt set /chosen linux,initrd-end 0x1000; bootefi >>>>>>> 0x0008 0x0240 >>>>>>> But with that, I get: >>>>>>> initrd not fully accessible via the linear mapping -- please check your >>>>>>> bootloader ... >>>>>> >>>>>> So this one is an EFI boot, but you can't find where to put the >>>>>> initramfs such that the >>>>>> kernel agrees its in memory. >>>>>> >>>>>> If you boot with 'efi=debug', linux will print the EFI memory map. Could >>>>>> you compare that >>>>>> to where U-Boot thi
Re: [PATCH] net: bcmgenet: Don't set ID_MODE_DIS when not using RGMII
On 20/02/2020 17:36, Nicolas Saenz Julienne wrote: > As per Linux's driver, ID_MODE_DIS is only set when the PHY interface is > RGMII. Don't enable it for the rest of setups. > > This has been seen to misconfigure RPi4's PHY when booting Linux. > > Signed-off-by: Nicolas Saenz Julienne > --- > drivers/net/bcmgenet.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c > index 8f4848aec6..e971b556ac 100644 > --- a/drivers/net/bcmgenet.c > +++ b/drivers/net/bcmgenet.c > @@ -448,7 +448,10 @@ static int bcmgenet_adjust_link(struct bcmgenet_eth_priv > *priv) > } > > clrsetbits_32(priv->mac_reg + EXT_RGMII_OOB_CTRL, OOB_DISABLE, > - RGMII_LINK | RGMII_MODE_EN | ID_MODE_DIS); > + RGMII_LINK | RGMII_MODE_EN); > + > + if (phy_dev->interface == PHY_INTERFACE_MODE_RGMII) > + setbits_32(priv->mac_reg + EXT_RGMII_OOB_CTRL, ID_MODE_DIS); Is this given because by different DTS? Shouldn't that be uniform on the RPi4? BTW Joe, will you take patches for this driver through your branch? For now I delegated it to me, but I'm fine either way. Regards, Matthias > > writel(speed << CMD_SPEED_SHIFT, (priv->mac_reg + UMAC_CMD)); > >
Re: [PATCH] net: phy: Fix overlong PHY timeout
Hi Joe,
On 30/01/2020 12:00, Matthias Brugger wrote:
>
>
> On 03/01/2020 23:08, Andre Przywara wrote:
>> Commit 27c3f70f3b50 ("net: phy: Increase link up delay in
>> genphy_update_link()") increased the per-iteration waiting time from
>> 1ms to 50ms, without adjusting the timeout counter. This lead to the
>> timeout increasing from the typical 4 seconds to over three minutes.
>>
>> Adjust the timeout counter evaluation by that factor of 50 to bring the
>> timeout back to the intended value.
>>
>> Signed-off-by: Andre Przywara
>
> I tested this on RPi4 with the genet patches on top. Now the timeout is
> reasonable :)
>
> Tested-by: Matthias Brugger
>
Friedly reminder, are you planning to take this fix for v2020.04?
Regards,
Matthias
>> ---
>> drivers/net/phy/phy.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
>> index 80a7664e49..5cf9c165b6 100644
>> --- a/drivers/net/phy/phy.c
>> +++ b/drivers/net/phy/phy.c
>> @@ -244,7 +244,7 @@ int genphy_update_link(struct phy_device *phydev)
>> /*
>> * Timeout reached ?
>> */
>> -if (i > PHY_ANEG_TIMEOUT) {
>> +if (i > (PHY_ANEG_TIMEOUT / 50)) {
>> printf(" TIMEOUT !\n");
>> phydev->link = 0;
>> return -ETIMEDOUT;
>>
Re: [PATCH] raspberrypi: reserve first two pages in efi memory map
On 26/02/2020 15:03, kev...@freebsd.org wrote: > From: Kyle Evans > > The psci stub provided by Raspberry Pi is around 5k in size, thus residing > in the first two pages of memory. Without this reservation, the next stage > or OS assume they're free to use the second page and may get catastrophic > results from clobbering it. > > Signed-off-by: Kyle Evans > Cc: Matthias Brugger > --- > board/raspberrypi/rpi/rpi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c > index e367ba3092..d3f9bd16ac 100644 > --- a/board/raspberrypi/rpi/rpi.c > +++ b/board/raspberrypi/rpi/rpi.c > @@ -488,8 +488,8 @@ int ft_board_setup(void *blob, bd_t *bd) > lcd_dt_simplefb_add_node(blob); > > #ifdef CONFIG_EFI_LOADER > - /* Reserve the spin table */ > - efi_add_memory_map(0, 1, EFI_RESERVED_MEMORY_TYPE, 0); > + /* Reserve the first two pages for spin table/psci stub. */ > + efi_add_memory_map(0, 2, EFI_RESERVED_MEMORY_TYPE, 0); Is this that changed recently or was the memory reservation wrong from the beginning? Reagrds, Matthias > #endif > > return 0; >
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
