[PATCH v2 0/3] Add AMD UFS platfrom driver support
Enable UFS DWC controller driver support and add AMD UFS platform driver support. NOTE: These changes are rebased on top of this series [PATCH 00/13] ufs: enhancements to support Qualcomm UFS controllers Changes in v2: - Removed the ufshcd_vops_phy_initialization function. - Removed the ufshcd_set_link_active function. Venkatesh Yadav Abbarapu (3): ufs: add support for DesignWare Controller ufs: ufs-amd-versal2: Add support for AMD UFS controller configs: versal2: Add support for AMD UFS platform driver configs/amd_versal2_virt_defconfig | 2 +- drivers/ufs/Kconfig| 8 + drivers/ufs/Makefile | 1 + drivers/ufs/ufs-amd-versal2.c | 501 + drivers/ufs/ufshcd-dwc.c | 133 drivers/ufs/ufshcd-dwc.h | 69 drivers/ufs/ufshci-dwc.h | 32 ++ drivers/ufs/unipro.h | 1 + 8 files changed, 746 insertions(+), 1 deletion(-) create mode 100644 drivers/ufs/ufs-amd-versal2.c create mode 100644 drivers/ufs/ufshcd-dwc.c create mode 100644 drivers/ufs/ufshcd-dwc.h create mode 100644 drivers/ufs/ufshci-dwc.h -- 2.17.1
Re: [PATCH v2 0/3] Add Android 14 bootflow support for AM62X and AM62P board
On September 12, 2024 thus sayeth Guillaume La Roque: > Ths patchset add support of Android 14 with boot image version 4 > for : > - AM62X-SK EVM: https://www.ti.com/tool/SK-AM62B > - BeaglePlay: https://beagleplay.org/ > - AM62PX-SK EVM: https://www.ti.com/tool/SK-AM62P-LP > > Android Images use to test this series are on the Official TI website: > - AM62x/BeaglePlay: https://www.ti.com/tool/PROCESSOR-SDK-AM62X > - AM62PX: https://www.ti.com/tool/PROCESSOR-SDK-AM62P > > Signed-off-by: Guillaume La Roque > --- > Changes in v2: > - Remove uneeded part in android fragment > - Update commit message. > - Link to v1: > https://lore.kernel.org/r/20240902-sitaraupstream-v1-0-0c478c33c...@baylibre.com > > --- > Guillaume La Roque (1): > board: ti: am62x_evm: Add android bootflow > > Mattijs Korpershoek (2): > board: beagle: beagleplay: Add android bootflow support > board: ti: am62px: Add android bootflow support > Looks great and thank you for the upstream Android support! Reviewed-by: Bryan Brattlof ~Bryan
[PATCH v2 0/3] Add Android 14 bootflow support for AM62X and AM62P board
Ths patchset add support of Android 14 with boot image version 4 for : - AM62X-SK EVM: https://www.ti.com/tool/SK-AM62B - BeaglePlay: https://beagleplay.org/ - AM62PX-SK EVM: https://www.ti.com/tool/SK-AM62P-LP Android Images use to test this series are on the Official TI website: - AM62x/BeaglePlay: https://www.ti.com/tool/PROCESSOR-SDK-AM62X - AM62PX: https://www.ti.com/tool/PROCESSOR-SDK-AM62P Signed-off-by: Guillaume La Roque --- Changes in v2: - Remove uneeded part in android fragment - Update commit message. - Link to v1: https://lore.kernel.org/r/20240902-sitaraupstream-v1-0-0c478c33c...@baylibre.com --- Guillaume La Roque (1): board: ti: am62x_evm: Add android bootflow Mattijs Korpershoek (2): board: beagle: beagleplay: Add android bootflow support board: ti: am62px: Add android bootflow support board/beagle/beagleplay/beagleplay.env | 30 ++ board/ti/am62px/am62px.env | 5 + board/ti/am62x/am62x.env | 5 + configs/am62x_a53_android.config | 21 + doc/board/ti/am62x_sk.rst | 14 ++ include/env/ti/android.env | 31 +++ 6 files changed, 106 insertions(+) --- base-commit: 57949a99b7bd0aa21abbde1ffa7e50e5d9e10a4e change-id: 20240830-sitaraupstream-5b18f3b9824f Best regards, -- Guillaume La Roque
[RESEND PATCH v2 0/3] mtd: spi-nor: Add support for S25FS-S family
From: Takahiro Kuwano Reset after rebasing and collecting R-b tags. The S25FS064S, S25FS128S, and S25FS256S are the same family of SPI NOR Flash devices with S25FS512S. Datasheets: https://www.infineon.com/dgdl/Infineon-S25FS064S_64_Mb_8_MB_FS-S_Flash_SPI_Multi-I_O_1-DataSheet-v10_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ed526b25412 https://www.infineon.com/dgdl/Infineon-S25FS128S_S25FS256S_1.8_V_Serial_Peripheral_Interface_with_Multi-I_O_MirrorBit(R)_Non-Volatile_Flash-DataSheet-v15_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ed6b5ab5758 Takahiro Kuwano (3): mtd: spi-nore-core: Fix 4KB erase opcode for s25fs-s mtd: spi-nor-id: Use INFO6 macro for S25FL-S mtd: spi-nor-id: Add S25FS064S, S25FS128S, S25FS256S IDs drivers/mtd/spi/spi-nor-core.c | 28 +--- drivers/mtd/spi/spi-nor-ids.c | 7 +-- 2 files changed, 26 insertions(+), 9 deletions(-) -- 2.34.1
[PATCH v2 0/3] Support for Qualcomm sm8150 SoC
This series picks up the work from Volodymyr Babchuk (https://lore.kernel.org/u-boot/20240306005230.2638972-1-volodymyr_babc...@epam.com). clk and pinctrl drivers are adjusted to work similarly to existing qcom drivers. I could only test this using android boot chainloading. Signed-off-by: Julius Lehmann --- Changes in v2: - fix: clk: qcom: sm8150 command registers for phy_aux_clk (usb) - refactor: pinctrl: qcom: sm8150 use special_pin_start and special_pins_data - Link to v1: https://lore.kernel.org/r/20240909155315.307026-1-lehma...@devpi.de --- Julius Lehmann (3): clk: qcom: add driver for SM8150 SoC pinctrl: qcom: add driver for SM8150 SoC config: qcom: add sm8150 to qcom_defconfig configs/qcom_defconfig| 2 + drivers/clk/qcom/Kconfig | 9 + drivers/clk/qcom/Makefile | 1 + drivers/clk/qcom/clock-sm8150.c | 300 ++ drivers/pinctrl/qcom/Kconfig | 8 + drivers/pinctrl/qcom/Makefile | 1 + drivers/pinctrl/qcom/pinctrl-sm8150.c | 156 ++ 7 files changed, 477 insertions(+) --- base-commit: 78d898eec080b02059c8dc09318b8761044fea85 change-id: 20240910-sm8150-patches-559cc2475ded Best regards, -- Julius Lehmann
[RESEND PATCH v2 0/3] cmd/mtd: add missed featuries
Some nand flashes (like spi-nand one) are registered with mtd subsystem only, thus nand command can't be used to work with such flashes. As result some functionality is missing. This patch series implements following subcommands: * markbad -- mark block as bad (copy of 'nand markbad') * torture -- destructive test of flash blocks (copy of 'nand torture') * nandtest -- non-destructive test of nand flashes v2 changes: * add cover letter Mikhail Kshevetskiy (3): cmd: mtd: add markbad command support cmd: mtd: add torture command support cmd: mtd: add nandtest command support cmd/Kconfig | 18 +++ cmd/mtd.c | 457 2 files changed, 475 insertions(+) -- 2.45.2
Re: [PATCH v2 0/3] Meson: R/W support for pages used by boot ROM
On 26.08.2024 09:15, Michael Nazzareno Trimarchi wrote:
> Hi Aresenly
>
> On Fri, Aug 23, 2024 at 10:53 AM Neil Armstrong
> wrote:
>>
>> On 23/08/2024 10:29, Arseniy Krasnov wrote:
>>> Hi! Got it, thanks!
>>>
>>> On 23.08.2024 11:10, Michael Nazzareno Trimarchi wrote:
Hi Arseniy
On Thu, Aug 22, 2024 at 9:04 AM Arseniy Krasnov
wrote:
>
> Hi, thanks!
>
> Thanks, Arseniy
>
> On 22.08.2024 00:17, Michael Nazzareno Trimarchi wrote:
>> Hi
>>
>> I will read them tomorrow ;)
>>
>> Thank you for understanding
>>
All the series are delegated to Neil. I will review anyway but I think
that will then pick from him
>>
>> Sure I can pick them if reviewed!
>>
>
> Can you please resend the series? I don't find in my mailbox (strange)
Hi, sure, done. With 'RESEND' prefix.
Thanks
>
> Michael
>
>> Neil
>>
Michael
>> Michael
>>
>> Il mer 21 ago 2024, 22:25 Arseniy Krasnov
>> ha
>> scritto:
>>
>>> Hi, sorry, pls ping 😄
>>>
>>> Thanks
>>>
>>> On 08.07.2024 10:13, Arseniy Krasnov wrote:
Patchset is based on patchset for Linux (today merged to nand-next):
>>> https://lore.kernel.org/linux-mtd/20240507230903.3399594-1-avkras...@salutedevices.com/
Here is description from it:
> Amlogic's boot ROM code needs that some pages on NAND must be
written
> in special "short" ECC mode with scrambling enabled. Such pages:
> 1) Contain some metadata about hardware.
> 2) Located with some interval starting from 0 offset, until some
> specified offset. Interval and second offset are set in the
> device tree.
>
> This patchset adds R/W support for such pages. To enable it we can
>>> setup
> it in dts:
>
> nand-is-boot-medium;
> amlogic,boot-pages = <1024>;
> amlogic,boot-page-step = <128>;
>
> It means that each 128th page in range 0 to 1024 pages will be
>>> accessed
> in special mode ("short" ECC + scrambling). In practice this
feature
>>> is
> needed when we want to update first block of NAND - driver will
>>> enable
> required mode by itself using value from device tree.
The only difference is that patchset for Linux updates DT bindings,
while
this adds NAND_IS_BOOT_MEDIUM flag support.
Changelog:
v1 -> v2:
* Pls see per-patch changelog.
Arseniy Krasnov (3):
mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag
mtd: rawnand: meson: refactor use of 'meson_nfc_cmd_access()'
mtd: rawnand: meson: read/write access for boot ROM pages
drivers/mtd/nand/raw/meson_nand.c | 84
+--
drivers/mtd/nand/raw/nand_base.c | 3 ++
include/linux/mtd/rawnand.h | 5 ++
3 files changed, 65 insertions(+), 27 deletions(-)
>>>
>>
>>
>
>
[RESEND PATCH v2 0/3] Meson: R/W support for pages used by boot ROM
Patchset is based on patchset for Linux (today merged to nand-next):
https://lore.kernel.org/linux-mtd/20240507230903.3399594-1-avkras...@salutedevices.com/
Here is description from it:
> Amlogic's boot ROM code needs that some pages on NAND must be written
> in special "short" ECC mode with scrambling enabled. Such pages:
> 1) Contain some metadata about hardware.
> 2) Located with some interval starting from 0 offset, until some
> specified offset. Interval and second offset are set in the
> device tree.
>
> This patchset adds R/W support for such pages. To enable it we can setup
> it in dts:
>
> nand-is-boot-medium;
> amlogic,boot-pages = <1024>;
> amlogic,boot-page-step = <128>;
>
> It means that each 128th page in range 0 to 1024 pages will be accessed
> in special mode ("short" ECC + scrambling). In practice this feature is
> needed when we want to update first block of NAND - driver will enable
> required mode by itself using value from device tree.
The only difference is that patchset for Linux updates DT bindings, while
this adds NAND_IS_BOOT_MEDIUM flag support.
Changelog:
v1 -> v2:
* Pls see per-patch changelog.
Arseniy Krasnov (3):
mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag
mtd: rawnand: meson: refactor use of 'meson_nfc_cmd_access()'
mtd: rawnand: meson: read/write access for boot ROM pages
drivers/mtd/nand/raw/meson_nand.c | 84 +--
drivers/mtd/nand/raw/nand_base.c | 3 ++
include/linux/mtd/rawnand.h | 5 ++
3 files changed, 65 insertions(+), 27 deletions(-)
--
2.30.1
Re: [PATCH v2 0/3] Meson: R/W support for pages used by boot ROM
Hi Aresenly
On Fri, Aug 23, 2024 at 10:53 AM Neil Armstrong
wrote:
>
> On 23/08/2024 10:29, Arseniy Krasnov wrote:
> > Hi! Got it, thanks!
> >
> > On 23.08.2024 11:10, Michael Nazzareno Trimarchi wrote:
> >> Hi Arseniy
> >>
> >> On Thu, Aug 22, 2024 at 9:04 AM Arseniy Krasnov
> >> wrote:
> >>>
> >>> Hi, thanks!
> >>>
> >>> Thanks, Arseniy
> >>>
> >>> On 22.08.2024 00:17, Michael Nazzareno Trimarchi wrote:
> Hi
>
> I will read them tomorrow ;)
>
> Thank you for understanding
>
> >>
> >> All the series are delegated to Neil. I will review anyway but I think
> >> that will then pick from him
>
> Sure I can pick them if reviewed!
>
Can you please resend the series? I don't find in my mailbox (strange)
Michael
> Neil
>
> >>
> >> Michael
> >>
> Michael
>
> Il mer 21 ago 2024, 22:25 Arseniy Krasnov
> ha
> scritto:
>
> > Hi, sorry, pls ping 😄
> >
> > Thanks
> >
> > On 08.07.2024 10:13, Arseniy Krasnov wrote:
> >> Patchset is based on patchset for Linux (today merged to nand-next):
> >>
> > https://lore.kernel.org/linux-mtd/20240507230903.3399594-1-avkras...@salutedevices.com/
> >>
> >> Here is description from it:
> >>
> >> > Amlogic's boot ROM code needs that some pages on NAND must be
> >> written
> >> > in special "short" ECC mode with scrambling enabled. Such pages:
> >> > 1) Contain some metadata about hardware.
> >> > 2) Located with some interval starting from 0 offset, until some
> >> > specified offset. Interval and second offset are set in the
> >> > device tree.
> >> >
> >> > This patchset adds R/W support for such pages. To enable it we can
> > setup
> >> > it in dts:
> >> >
> >> > nand-is-boot-medium;
> >> > amlogic,boot-pages = <1024>;
> >> > amlogic,boot-page-step = <128>;
> >> >
> >> > It means that each 128th page in range 0 to 1024 pages will be
> > accessed
> >> > in special mode ("short" ECC + scrambling). In practice this
> >> feature
> > is
> >> > needed when we want to update first block of NAND - driver will
> > enable
> >> > required mode by itself using value from device tree.
> >>
> >> The only difference is that patchset for Linux updates DT bindings,
> >> while
> >> this adds NAND_IS_BOOT_MEDIUM flag support.
> >>
> >> Changelog:
> >> v1 -> v2:
> >> * Pls see per-patch changelog.
> >>
> >> Arseniy Krasnov (3):
> >>mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag
> >>mtd: rawnand: meson: refactor use of 'meson_nfc_cmd_access()'
> >>mtd: rawnand: meson: read/write access for boot ROM pages
> >>
> >> drivers/mtd/nand/raw/meson_nand.c | 84
> >> +--
> >> drivers/mtd/nand/raw/nand_base.c | 3 ++
> >> include/linux/mtd/rawnand.h | 5 ++
> >> 3 files changed, 65 insertions(+), 27 deletions(-)
> >>
> >
>
> >>
> >>
> >>
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v2 0/3] Meson: R/W support for pages used by boot ROM
On 23/08/2024 10:29, Arseniy Krasnov wrote:
Hi! Got it, thanks!
On 23.08.2024 11:10, Michael Nazzareno Trimarchi wrote:
Hi Arseniy
On Thu, Aug 22, 2024 at 9:04 AM Arseniy Krasnov
wrote:
Hi, thanks!
Thanks, Arseniy
On 22.08.2024 00:17, Michael Nazzareno Trimarchi wrote:
Hi
I will read them tomorrow ;)
Thank you for understanding
All the series are delegated to Neil. I will review anyway but I think
that will then pick from him
Sure I can pick them if reviewed!
Neil
Michael
Michael
Il mer 21 ago 2024, 22:25 Arseniy Krasnov ha
scritto:
Hi, sorry, pls ping 😄
Thanks
On 08.07.2024 10:13, Arseniy Krasnov wrote:
Patchset is based on patchset for Linux (today merged to nand-next):
https://lore.kernel.org/linux-mtd/20240507230903.3399594-1-avkras...@salutedevices.com/
Here is description from it:
> Amlogic's boot ROM code needs that some pages on NAND must be written
> in special "short" ECC mode with scrambling enabled. Such pages:
> 1) Contain some metadata about hardware.
> 2) Located with some interval starting from 0 offset, until some
> specified offset. Interval and second offset are set in the
> device tree.
>
> This patchset adds R/W support for such pages. To enable it we can
setup
> it in dts:
>
> nand-is-boot-medium;
> amlogic,boot-pages = <1024>;
> amlogic,boot-page-step = <128>;
>
> It means that each 128th page in range 0 to 1024 pages will be
accessed
> in special mode ("short" ECC + scrambling). In practice this feature
is
> needed when we want to update first block of NAND - driver will
enable
> required mode by itself using value from device tree.
The only difference is that patchset for Linux updates DT bindings, while
this adds NAND_IS_BOOT_MEDIUM flag support.
Changelog:
v1 -> v2:
* Pls see per-patch changelog.
Arseniy Krasnov (3):
mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag
mtd: rawnand: meson: refactor use of 'meson_nfc_cmd_access()'
mtd: rawnand: meson: read/write access for boot ROM pages
drivers/mtd/nand/raw/meson_nand.c | 84 +--
drivers/mtd/nand/raw/nand_base.c | 3 ++
include/linux/mtd/rawnand.h | 5 ++
3 files changed, 65 insertions(+), 27 deletions(-)
Re: [PATCH v2 0/3] Meson: R/W support for pages used by boot ROM
Hi! Got it, thanks!
On 23.08.2024 11:10, Michael Nazzareno Trimarchi wrote:
> Hi Arseniy
>
> On Thu, Aug 22, 2024 at 9:04 AM Arseniy Krasnov
> wrote:
>>
>> Hi, thanks!
>>
>> Thanks, Arseniy
>>
>> On 22.08.2024 00:17, Michael Nazzareno Trimarchi wrote:
>>> Hi
>>>
>>> I will read them tomorrow ;)
>>>
>>> Thank you for understanding
>>>
>
> All the series are delegated to Neil. I will review anyway but I think
> that will then pick from him
>
> Michael
>
>>> Michael
>>>
>>> Il mer 21 ago 2024, 22:25 Arseniy Krasnov ha
>>> scritto:
>>>
Hi, sorry, pls ping 😄
Thanks
On 08.07.2024 10:13, Arseniy Krasnov wrote:
> Patchset is based on patchset for Linux (today merged to nand-next):
>
https://lore.kernel.org/linux-mtd/20240507230903.3399594-1-avkras...@salutedevices.com/
>
> Here is description from it:
>
> > Amlogic's boot ROM code needs that some pages on NAND must be written
> > in special "short" ECC mode with scrambling enabled. Such pages:
> > 1) Contain some metadata about hardware.
> > 2) Located with some interval starting from 0 offset, until some
> > specified offset. Interval and second offset are set in the
> > device tree.
> >
> > This patchset adds R/W support for such pages. To enable it we can
setup
> > it in dts:
> >
> > nand-is-boot-medium;
> > amlogic,boot-pages = <1024>;
> > amlogic,boot-page-step = <128>;
> >
> > It means that each 128th page in range 0 to 1024 pages will be
accessed
> > in special mode ("short" ECC + scrambling). In practice this feature
is
> > needed when we want to update first block of NAND - driver will
enable
> > required mode by itself using value from device tree.
>
> The only difference is that patchset for Linux updates DT bindings, while
> this adds NAND_IS_BOOT_MEDIUM flag support.
>
> Changelog:
> v1 -> v2:
> * Pls see per-patch changelog.
>
> Arseniy Krasnov (3):
> mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag
> mtd: rawnand: meson: refactor use of 'meson_nfc_cmd_access()'
> mtd: rawnand: meson: read/write access for boot ROM pages
>
> drivers/mtd/nand/raw/meson_nand.c | 84 +--
> drivers/mtd/nand/raw/nand_base.c | 3 ++
> include/linux/mtd/rawnand.h | 5 ++
> 3 files changed, 65 insertions(+), 27 deletions(-)
>
>>>
>
>
>
Re: [PATCH v2 0/3] Meson: R/W support for pages used by boot ROM
Hi Arseniy
On Thu, Aug 22, 2024 at 9:04 AM Arseniy Krasnov
wrote:
>
> Hi, thanks!
>
> Thanks, Arseniy
>
> On 22.08.2024 00:17, Michael Nazzareno Trimarchi wrote:
> > Hi
> >
> > I will read them tomorrow ;)
> >
> > Thank you for understanding
> >
All the series are delegated to Neil. I will review anyway but I think
that will then pick from him
Michael
> > Michael
> >
> > Il mer 21 ago 2024, 22:25 Arseniy Krasnov ha
> > scritto:
> >
> >> Hi, sorry, pls ping 😄
> >>
> >> Thanks
> >>
> >> On 08.07.2024 10:13, Arseniy Krasnov wrote:
> >>> Patchset is based on patchset for Linux (today merged to nand-next):
> >>>
> >> https://lore.kernel.org/linux-mtd/20240507230903.3399594-1-avkras...@salutedevices.com/
> >>>
> >>> Here is description from it:
> >>>
> >>> > Amlogic's boot ROM code needs that some pages on NAND must be written
> >>> > in special "short" ECC mode with scrambling enabled. Such pages:
> >>> > 1) Contain some metadata about hardware.
> >>> > 2) Located with some interval starting from 0 offset, until some
> >>> > specified offset. Interval and second offset are set in the
> >>> > device tree.
> >>> >
> >>> > This patchset adds R/W support for such pages. To enable it we can
> >> setup
> >>> > it in dts:
> >>> >
> >>> > nand-is-boot-medium;
> >>> > amlogic,boot-pages = <1024>;
> >>> > amlogic,boot-page-step = <128>;
> >>> >
> >>> > It means that each 128th page in range 0 to 1024 pages will be
> >> accessed
> >>> > in special mode ("short" ECC + scrambling). In practice this feature
> >> is
> >>> > needed when we want to update first block of NAND - driver will
> >> enable
> >>> > required mode by itself using value from device tree.
> >>>
> >>> The only difference is that patchset for Linux updates DT bindings, while
> >>> this adds NAND_IS_BOOT_MEDIUM flag support.
> >>>
> >>> Changelog:
> >>> v1 -> v2:
> >>> * Pls see per-patch changelog.
> >>>
> >>> Arseniy Krasnov (3):
> >>> mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag
> >>> mtd: rawnand: meson: refactor use of 'meson_nfc_cmd_access()'
> >>> mtd: rawnand: meson: read/write access for boot ROM pages
> >>>
> >>> drivers/mtd/nand/raw/meson_nand.c | 84 +--
> >>> drivers/mtd/nand/raw/nand_base.c | 3 ++
> >>> include/linux/mtd/rawnand.h | 5 ++
> >>> 3 files changed, 65 insertions(+), 27 deletions(-)
> >>>
> >>
> >
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v2 0/3] Meson: R/W support for pages used by boot ROM
Hi, thanks!
Thanks, Arseniy
On 22.08.2024 00:17, Michael Nazzareno Trimarchi wrote:
> Hi
>
> I will read them tomorrow ;)
>
> Thank you for understanding
>
> Michael
>
> Il mer 21 ago 2024, 22:25 Arseniy Krasnov ha
> scritto:
>
>> Hi, sorry, pls ping 😄
>>
>> Thanks
>>
>> On 08.07.2024 10:13, Arseniy Krasnov wrote:
>>> Patchset is based on patchset for Linux (today merged to nand-next):
>>>
>> https://lore.kernel.org/linux-mtd/20240507230903.3399594-1-avkras...@salutedevices.com/
>>>
>>> Here is description from it:
>>>
>>> > Amlogic's boot ROM code needs that some pages on NAND must be written
>>> > in special "short" ECC mode with scrambling enabled. Such pages:
>>> > 1) Contain some metadata about hardware.
>>> > 2) Located with some interval starting from 0 offset, until some
>>> > specified offset. Interval and second offset are set in the
>>> > device tree.
>>> >
>>> > This patchset adds R/W support for such pages. To enable it we can
>> setup
>>> > it in dts:
>>> >
>>> > nand-is-boot-medium;
>>> > amlogic,boot-pages = <1024>;
>>> > amlogic,boot-page-step = <128>;
>>> >
>>> > It means that each 128th page in range 0 to 1024 pages will be
>> accessed
>>> > in special mode ("short" ECC + scrambling). In practice this feature
>> is
>>> > needed when we want to update first block of NAND - driver will
>> enable
>>> > required mode by itself using value from device tree.
>>>
>>> The only difference is that patchset for Linux updates DT bindings, while
>>> this adds NAND_IS_BOOT_MEDIUM flag support.
>>>
>>> Changelog:
>>> v1 -> v2:
>>> * Pls see per-patch changelog.
>>>
>>> Arseniy Krasnov (3):
>>> mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag
>>> mtd: rawnand: meson: refactor use of 'meson_nfc_cmd_access()'
>>> mtd: rawnand: meson: read/write access for boot ROM pages
>>>
>>> drivers/mtd/nand/raw/meson_nand.c | 84 +--
>>> drivers/mtd/nand/raw/nand_base.c | 3 ++
>>> include/linux/mtd/rawnand.h | 5 ++
>>> 3 files changed, 65 insertions(+), 27 deletions(-)
>>>
>>
>
Re: [PATCH v2 0/3] Meson: R/W support for pages used by boot ROM
Hi
I will read them tomorrow ;)
Thank you for understanding
Michael
Il mer 21 ago 2024, 22:25 Arseniy Krasnov ha
scritto:
> Hi, sorry, pls ping 😄
>
> Thanks
>
> On 08.07.2024 10:13, Arseniy Krasnov wrote:
> > Patchset is based on patchset for Linux (today merged to nand-next):
> >
> https://lore.kernel.org/linux-mtd/20240507230903.3399594-1-avkras...@salutedevices.com/
> >
> > Here is description from it:
> >
> > > Amlogic's boot ROM code needs that some pages on NAND must be written
> > > in special "short" ECC mode with scrambling enabled. Such pages:
> > > 1) Contain some metadata about hardware.
> > > 2) Located with some interval starting from 0 offset, until some
> > > specified offset. Interval and second offset are set in the
> > > device tree.
> > >
> > > This patchset adds R/W support for such pages. To enable it we can
> setup
> > > it in dts:
> > >
> > > nand-is-boot-medium;
> > > amlogic,boot-pages = <1024>;
> > > amlogic,boot-page-step = <128>;
> > >
> > > It means that each 128th page in range 0 to 1024 pages will be
> accessed
> > > in special mode ("short" ECC + scrambling). In practice this feature
> is
> > > needed when we want to update first block of NAND - driver will
> enable
> > > required mode by itself using value from device tree.
> >
> > The only difference is that patchset for Linux updates DT bindings, while
> > this adds NAND_IS_BOOT_MEDIUM flag support.
> >
> > Changelog:
> > v1 -> v2:
> > * Pls see per-patch changelog.
> >
> > Arseniy Krasnov (3):
> > mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag
> > mtd: rawnand: meson: refactor use of 'meson_nfc_cmd_access()'
> > mtd: rawnand: meson: read/write access for boot ROM pages
> >
> > drivers/mtd/nand/raw/meson_nand.c | 84 +--
> > drivers/mtd/nand/raw/nand_base.c | 3 ++
> > include/linux/mtd/rawnand.h | 5 ++
> > 3 files changed, 65 insertions(+), 27 deletions(-)
> >
>
Re: [PATCH v2 0/3] Meson: R/W support for pages used by boot ROM
Hi, sorry, pls ping 😄
Thanks
On 08.07.2024 10:13, Arseniy Krasnov wrote:
> Patchset is based on patchset for Linux (today merged to nand-next):
> https://lore.kernel.org/linux-mtd/20240507230903.3399594-1-avkras...@salutedevices.com/
>
> Here is description from it:
>
> > Amlogic's boot ROM code needs that some pages on NAND must be written
> > in special "short" ECC mode with scrambling enabled. Such pages:
> > 1) Contain some metadata about hardware.
> > 2) Located with some interval starting from 0 offset, until some
> > specified offset. Interval and second offset are set in the
> > device tree.
> >
> > This patchset adds R/W support for such pages. To enable it we can setup
> > it in dts:
> >
> > nand-is-boot-medium;
> > amlogic,boot-pages = <1024>;
> > amlogic,boot-page-step = <128>;
> >
> > It means that each 128th page in range 0 to 1024 pages will be accessed
> > in special mode ("short" ECC + scrambling). In practice this feature is
> > needed when we want to update first block of NAND - driver will enable
> > required mode by itself using value from device tree.
>
> The only difference is that patchset for Linux updates DT bindings, while
> this adds NAND_IS_BOOT_MEDIUM flag support.
>
> Changelog:
> v1 -> v2:
> * Pls see per-patch changelog.
>
> Arseniy Krasnov (3):
> mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag
> mtd: rawnand: meson: refactor use of 'meson_nfc_cmd_access()'
> mtd: rawnand: meson: read/write access for boot ROM pages
>
> drivers/mtd/nand/raw/meson_nand.c | 84 +--
> drivers/mtd/nand/raw/nand_base.c | 3 ++
> include/linux/mtd/rawnand.h | 5 ++
> 3 files changed, 65 insertions(+), 27 deletions(-)
>
[RESEND PATCH v2 0/3] cmd/mtd: add missed featuries
Some nand flashes (like spi-nand one) are registered with mtd subsystem only, thus nand command can't be used to work with such flashes. As result some functionality is missing. This patch series implements following subcommands: * markbad -- mark block as bad (copy of 'nand markbad') * torture -- destructive test of flash blocks (copy of 'nand torture') * nandtest -- non-destructive test of nand flashes v2 changes: * add cover letter Mikhail Kshevetskiy (3): cmd: mtd: add markbad command support cmd: mtd: add torture command support cmd: mtd: add nandtest command support cmd/Kconfig | 18 +++ cmd/mtd.c | 457 2 files changed, 475 insertions(+) -- 2.39.2
Re: [PATCH v2 0/3] efi: Start tidying up memory management
Hi, On Thu, 1 Aug 2024 at 11:36, Simon Glass wrote: > > We have been discussing the state of EFI memory management for some > years so I thought it might be best to send a short series showing some > of the issues we have talked about. > > This one just deals with memory allocation. It updates EFI to use > U-Boot memory allocation for the pool where possible. Most functions use > that anyway and it is much more efficient. It also avoids allocating > things 'in space' in conflict with the loaded images. > > For v2 I have dropped patches which are not germane to the main idea. > > Note that this series is independent from Sugosh's lmb series[1], > although I believe it will point the way to simplifying some of the > later patches in that series. > > Overall, some issues which should be resolved in future are: > - allocation inconsistency, e.g. efi_add_protocol() uses malloc() but > efi_dp_dup() does not (this series makes a start) > - change efi_bl_init() to register events later, when the devices are > actually used > - rather than efi_set_bootdev(), provide a bootstd way to take note of > the device images came from and allow EFI to query that when needed > - EFI_LOADER_BOUNCE_BUFFER - can use U-Boot bounce buffers? > > Minor questions on my mind: > - is unaligned access useful? Is there a performance penalty? > - API confusion about whether something is an address or a pointer > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=416441 > > Changes in v2: > - Drop patch 'Show more information in efi index' > - Drop patch 'Avoid pool allocation in efi_get_memory_map_alloc()' > - Add the word 'warning', use log_warning() and show the end address > - Reorder patches a little > > Simon Glass (3): > efi: Allow use of malloc() for the EFI pool > efi: Convert device_path allocation to use malloc() > efi: Show the location of the bounce buffer > > common/dlmalloc.c| 7 ++ > include/efi_loader.h | 18 > include/malloc.h | 7 ++ > lib/efi_loader/efi_bootbin.c | 11 +++ > lib/efi_loader/efi_device_path.c | 43 + > lib/efi_loader/efi_device_path_to_text.c | 2 +- > lib/efi_loader/efi_memory.c | 110 +-- > 7 files changed, 148 insertions(+), 50 deletions(-) > > -- > 2.34.1 > Are there any comments on this series, please? Regards, Simon
[PATCH v2 0/3] ARM64: add symbol name lookup and print a backtrace on exception
U-Boot already emits frame pointers on ARM64, but lacks the code to parse them, as well as a mechanism for looking up symbol names at runtime. There was some (seemingly?) leftover code for symbols lookups in common/kallsyms.c and associated parts in the makefile, however it appears to be entirely unused and unsupported. It relied on generating one long string of all symbol addresses and names. The approach taken here is instead largely based on the implementation in the Xen hypervisor, it performs basic compression using non-ASCII bytes to tokenize repeated string segments which can later be expanded back out at runtime. This is then utilized in the ARM64 interrupt handling routine to dump a backtrace in the show_regs() debug function. As well as providing a general purpose unwind_stack() function which can be used for debugging. == Relocation == Since U-Boot relocates itself at runtime, and can be built to be position independent in the first place (effectively "relocating" itself when it first starts too), we can't really rely on gd->reloc_off. The approach taken here is to subtract CONFIG_TEXT_BASE from the address of each symbol in the lookup table (while it's being generated), then when decoding we just subtract the address of the _start label. Since this label address is updated to make U-Boot position independent and during relocation, it allows us to avoid re-implementing the relocation state handling stuff in the symbol decoder. == Size == By default this feature is off, and will not effect the size of U-Boot binaries. The generated symbols object file is ~85k with the (fairly hefty) qcom_defconfig, so there is certainly a cost to be taken into account. I hope that this implementation can be later extended for other platforms. However this is currently beyond my (skill, time) capabilities. --- Changes in v2: - Remove unused last_fp pointer - Apply Tom's suggestions (cleanup hunks, don't guard unwind_stack()). - Link to v1: https://lore.kernel.org/r/20240710-arm64-backtrace-v1-0-5a2ba5048...@linaro.org --- Caleb Connolly (3): drop unused kallsyms support add support for symbol lookups arm64: unwind stack on exception Makefile | 24 +- arch/arm/include/asm/ptrace.h | 2 + arch/arm/lib/interrupts_64.c | 75 + common/Makefile | 1 - common/kallsyms.c | 43 --- common/system_map.c | 8 - include/symbols.h | 19 ++ lib/Kconfig | 8 + lib/symbols.c | 126 tools/Makefile| 3 + tools/symbols.c | 646 ++ 11 files changed, 892 insertions(+), 63 deletions(-) --- change-id: 20240710-arm64-backtrace-2926f764dbdc base-commit: 13f9c5668411aa18ef64846d5bc86e9e6be52082 // Caleb (they/them)
[PATCH v2 0/3] efi: Start tidying up memory management
We have been discussing the state of EFI memory management for some years so I thought it might be best to send a short series showing some of the issues we have talked about. This one just deals with memory allocation. It updates EFI to use U-Boot memory allocation for the pool where possible. Most functions use that anyway and it is much more efficient. It also avoids allocating things 'in space' in conflict with the loaded images. For v2 I have dropped patches which are not germane to the main idea. Note that this series is independent from Sugosh's lmb series[1], although I believe it will point the way to simplifying some of the later patches in that series. Overall, some issues which should be resolved in future are: - allocation inconsistency, e.g. efi_add_protocol() uses malloc() but efi_dp_dup() does not (this series makes a start) - change efi_bl_init() to register events later, when the devices are actually used - rather than efi_set_bootdev(), provide a bootstd way to take note of the device images came from and allow EFI to query that when needed - EFI_LOADER_BOUNCE_BUFFER - can use U-Boot bounce buffers? Minor questions on my mind: - is unaligned access useful? Is there a performance penalty? - API confusion about whether something is an address or a pointer [1] https://patchwork.ozlabs.org/project/uboot/list/?series=416441 Changes in v2: - Drop patch 'Show more information in efi index' - Drop patch 'Avoid pool allocation in efi_get_memory_map_alloc()' - Add the word 'warning', use log_warning() and show the end address - Reorder patches a little Simon Glass (3): efi: Allow use of malloc() for the EFI pool efi: Convert device_path allocation to use malloc() efi: Show the location of the bounce buffer common/dlmalloc.c| 7 ++ include/efi_loader.h | 18 include/malloc.h | 7 ++ lib/efi_loader/efi_bootbin.c | 11 +++ lib/efi_loader/efi_device_path.c | 43 + lib/efi_loader/efi_device_path_to_text.c | 2 +- lib/efi_loader/efi_memory.c | 110 +-- 7 files changed, 148 insertions(+), 50 deletions(-) -- 2.34.1
[PATCH v2 0/3] cmd/mtd: add missed featuries
Some nand flashes (like spi-nand one) are registered with mtd subsystem only, thus nand command can't be used to work with such flashes. As result some functionality is missing. This patch series implements following subcommands: * markbad -- mark block as bad (copy of 'nand markbad') * torture -- destructive test of flash blocks (copy of 'nand torture') * nandtest -- non-destructive test of nand flashes v2 changes: * add cover letter Mikhail Kshevetskiy (3): cmd: mtd: add markbad command support cmd: mtd: add torture command support cmd: mtd: add nandtest command support cmd/Kconfig | 18 +++ cmd/mtd.c | 457 2 files changed, 475 insertions(+) -- 2.39.2
[PATCH v2 0/3] dwc3: gadget: properly fix cache operations
We experience huge problems with cache handling on Qualcomm systems, and it appears the dcache handling in the DWC3 gadget code is quite wrong and causes operational issues. This serie fixes the dcache operations on unaligned data, and properly invalidate buffers when reading back data from hardware. Signed-off-by: Neil Armstrong --- Changes in v2: - Fix typo in drivers/usb/dwc3/core.h and rewrite patch 1 commit message - Link to v1: https://lore.kernel.org/r/20240719-u-boot-dwc3-gadget-dcache-fixup-v1-0-58a5f026e...@linaro.org --- Neil Armstrong (3): usb: dwc3: allocate setup_buf with dma_alloc_coherent() usb: dwc3: fix dcache flush range calculation usb: dwc3: invalidate dcache on buffer used in interrupt handling drivers/usb/dwc3/core.h | 2 ++ drivers/usb/dwc3/ep0.c| 6 -- drivers/usb/dwc3/gadget.c | 10 ++ drivers/usb/dwc3/io.h | 13 - 4 files changed, 24 insertions(+), 7 deletions(-) --- base-commit: 3f772959501c99fbe5aa0b22a36efe3478d1ae1c change-id: 20240719-u-boot-dwc3-gadget-dcache-fixup-ea1e92758663 Best regards, -- Neil Armstrong
Re: [PATCH v2 0/3] Meson: R/W support for pages used by boot ROM
Hi, sorry, pls ping, 2 weeks :)
Thanks
On 08.07.2024 10:13, Arseniy Krasnov wrote:
> Patchset is based on patchset for Linux (today merged to nand-next):
> https://lore.kernel.org/linux-mtd/20240507230903.3399594-1-avkras...@salutedevices.com/
>
> Here is description from it:
>
> > Amlogic's boot ROM code needs that some pages on NAND must be written
> > in special "short" ECC mode with scrambling enabled. Such pages:
> > 1) Contain some metadata about hardware.
> > 2) Located with some interval starting from 0 offset, until some
> > specified offset. Interval and second offset are set in the
> > device tree.
> >
> > This patchset adds R/W support for such pages. To enable it we can setup
> > it in dts:
> >
> > nand-is-boot-medium;
> > amlogic,boot-pages = <1024>;
> > amlogic,boot-page-step = <128>;
> >
> > It means that each 128th page in range 0 to 1024 pages will be accessed
> > in special mode ("short" ECC + scrambling). In practice this feature is
> > needed when we want to update first block of NAND - driver will enable
> > required mode by itself using value from device tree.
>
> The only difference is that patchset for Linux updates DT bindings, while
> this adds NAND_IS_BOOT_MEDIUM flag support.
>
> Changelog:
> v1 -> v2:
> * Pls see per-patch changelog.
>
> Arseniy Krasnov (3):
> mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag
> mtd: rawnand: meson: refactor use of 'meson_nfc_cmd_access()'
> mtd: rawnand: meson: read/write access for boot ROM pages
>
> drivers/mtd/nand/raw/meson_nand.c | 84 +--
> drivers/mtd/nand/raw/nand_base.c | 3 ++
> include/linux/mtd/rawnand.h | 5 ++
> 3 files changed, 65 insertions(+), 27 deletions(-)
>
[PATCH v2 0/3] Meson: R/W support for pages used by boot ROM
Patchset is based on patchset for Linux (today merged to nand-next):
https://lore.kernel.org/linux-mtd/20240507230903.3399594-1-avkras...@salutedevices.com/
Here is description from it:
> Amlogic's boot ROM code needs that some pages on NAND must be written
> in special "short" ECC mode with scrambling enabled. Such pages:
> 1) Contain some metadata about hardware.
> 2) Located with some interval starting from 0 offset, until some
> specified offset. Interval and second offset are set in the
> device tree.
>
> This patchset adds R/W support for such pages. To enable it we can setup
> it in dts:
>
> nand-is-boot-medium;
> amlogic,boot-pages = <1024>;
> amlogic,boot-page-step = <128>;
>
> It means that each 128th page in range 0 to 1024 pages will be accessed
> in special mode ("short" ECC + scrambling). In practice this feature is
> needed when we want to update first block of NAND - driver will enable
> required mode by itself using value from device tree.
The only difference is that patchset for Linux updates DT bindings, while
this adds NAND_IS_BOOT_MEDIUM flag support.
Changelog:
v1 -> v2:
* Pls see per-patch changelog.
Arseniy Krasnov (3):
mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag
mtd: rawnand: meson: refactor use of 'meson_nfc_cmd_access()'
mtd: rawnand: meson: read/write access for boot ROM pages
drivers/mtd/nand/raw/meson_nand.c | 84 +--
drivers/mtd/nand/raw/nand_base.c | 3 ++
include/linux/mtd/rawnand.h | 5 ++
3 files changed, 65 insertions(+), 27 deletions(-)
--
2.30.1
[PATCH v2 0/3] arm64: add a software pagetable walker
MMU issues are some of the most frustrating to debug. To make this slightly less unbearable, introduce a software pagetable walker for ARMv8. This can be called to dump a pagetable with the default formatter, or a custom callback can be provided to implement more complicated parsing. This can also be useful to dump the pagetable used by a previous bootloader stage (by reading out the ttbr register). Here is an example of the output when walking U-Boot's own memory map on a Qualcomm RB3 board: Walking pagetable at 00017df9, va_bits: 36. Using 3 levels [0x17df91000] | Table | | [0x17df92000] | Table | | [0x01000 - 0x00020] | Pages | Device-nGnRnE | Non-shareable [0x00020 - 0x04000] | Block | Device-nGnRnE | Non-shareable [0x04000 - 0x08000] | Block | Device-nGnRnE | Non-shareable [0x08000 - 0x14000] | Block | Normal| Inner-shareable [0x17df93000] | Table | | [0x14000 - 0x17de0] | Block | Normal| Inner-shareable [0x17df94000] | Table | | [0x17de0 - 0x17dfa] | Pages | Normal| Inner-shareable --- Changes in v2: - Document the MMU debugging features in doc/arch/arm64.rst - Mention that functions are stripped out when unused. - Link to v1: https://lore.kernel.org/r/20240607-caleb-upstreaming-v1-0-99094dabb...@linaro.org --- Caleb Connolly (3): arm64: mmu.h: fix PTE_TABLE_AP arm64: add software pagetable walker doc: arch: arm64: describe pagetable debugging arch/arm/cpu/armv8/cache_v8.c| 202 +++ arch/arm/include/asm/armv8/mmu.h | 57 ++- doc/arch/arm64.rst | 37 +++ 3 files changed, 295 insertions(+), 1 deletion(-) --- change-id: 20240607-caleb-upstreaming-82744a2786b3 base-commit: 22ca7e13dc02be83c29450aeadd8e150ebdd // Caleb (they/them)
Re: [PATCH v2 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
On Fri, May 31, 2024 at 07:53:24PM +0300, Roger Quadros wrote: > Tom, > > On 31/05/2024 19:32, Roger Quadros wrote: > > Hi Tom, > > > > On 20/05/2024 18:56, Tom Rini wrote: > >> On Mon, 13 May 2024 15:13:53 +0300, Roger Quadros wrote: > >> > >>> Sync AM62 device tree files with Linux v6.9 and > >>> add in the missing bits in -u-boot.dtsi to get CPSW > >>> Ethernet working. > >>> > >>> CI testing > >>> https://github.com/u-boot/u-boot/pull/534 > >>> > >>> [...] > >> > >> Applied to u-boot/next, thanks! > >> > > > > I see that this series was applied to u-boot master as well > > and then later reverted by commit d678a59d2d719da9e807495b4b021501f2836ca5 > > as it was based on u-boot/next > > > > Can I re-send this series based on u-boot/master so it can be still applied > > to master? > > Without this Ethernet is broken on beagleplay. > > > > This series apply cleanly on u-boot/master so no need to resend. > > I've created a pull request for CI loop testing on u-boot/master. Note that the base commit was on -next I believe and so that's what lead b4 to pull in -next changes that I wasn't expecting. I have tooling in place now to catch this in the future. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
On 31/05/2024 19:47, Tom Rini wrote: > On Fri, May 31, 2024 at 07:32:37PM +0300, Roger Quadros wrote: >> Hi Tom, >> >> On 20/05/2024 18:56, Tom Rini wrote: >>> On Mon, 13 May 2024 15:13:53 +0300, Roger Quadros wrote: >>> Sync AM62 device tree files with Linux v6.9 and add in the missing bits in -u-boot.dtsi to get CPSW Ethernet working. CI testing https://github.com/u-boot/u-boot/pull/534 [...] >>> >>> Applied to u-boot/next, thanks! >>> >> >> I see that this series was applied to u-boot master as well >> and then later reverted by commit d678a59d2d719da9e807495b4b021501f2836ca5 >> as it was based on u-boot/next >> >> Can I re-send this series based on u-boot/master so it can be still applied >> to master? >> Without this Ethernet is broken on beagleplay. > > Was ethernet working on v2024.04? > Ah, probably not. -- cheers, -roger
Re: [PATCH v2 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
Tom, On 31/05/2024 19:32, Roger Quadros wrote: > Hi Tom, > > On 20/05/2024 18:56, Tom Rini wrote: >> On Mon, 13 May 2024 15:13:53 +0300, Roger Quadros wrote: >> >>> Sync AM62 device tree files with Linux v6.9 and >>> add in the missing bits in -u-boot.dtsi to get CPSW >>> Ethernet working. >>> >>> CI testing >>> https://github.com/u-boot/u-boot/pull/534 >>> >>> [...] >> >> Applied to u-boot/next, thanks! >> > > I see that this series was applied to u-boot master as well > and then later reverted by commit d678a59d2d719da9e807495b4b021501f2836ca5 > as it was based on u-boot/next > > Can I re-send this series based on u-boot/master so it can be still applied > to master? > Without this Ethernet is broken on beagleplay. > This series apply cleanly on u-boot/master so no need to resend. I've created a pull request for CI loop testing on u-boot/master. https://github.com/u-boot/u-boot/pull/572 -- cheers, -roger
Re: [PATCH v2 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
On Fri, May 31, 2024 at 07:32:37PM +0300, Roger Quadros wrote: > Hi Tom, > > On 20/05/2024 18:56, Tom Rini wrote: > > On Mon, 13 May 2024 15:13:53 +0300, Roger Quadros wrote: > > > >> Sync AM62 device tree files with Linux v6.9 and > >> add in the missing bits in -u-boot.dtsi to get CPSW > >> Ethernet working. > >> > >> CI testing > >> https://github.com/u-boot/u-boot/pull/534 > >> > >> [...] > > > > Applied to u-boot/next, thanks! > > > > I see that this series was applied to u-boot master as well > and then later reverted by commit d678a59d2d719da9e807495b4b021501f2836ca5 > as it was based on u-boot/next > > Can I re-send this series based on u-boot/master so it can be still applied > to master? > Without this Ethernet is broken on beagleplay. Was ethernet working on v2024.04? -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
Hi Tom, On 20/05/2024 18:56, Tom Rini wrote: > On Mon, 13 May 2024 15:13:53 +0300, Roger Quadros wrote: > >> Sync AM62 device tree files with Linux v6.9 and >> add in the missing bits in -u-boot.dtsi to get CPSW >> Ethernet working. >> >> CI testing >> https://github.com/u-boot/u-boot/pull/534 >> >> [...] > > Applied to u-boot/next, thanks! > I see that this series was applied to u-boot master as well and then later reverted by commit d678a59d2d719da9e807495b4b021501f2836ca5 as it was based on u-boot/next Can I re-send this series based on u-boot/master so it can be still applied to master? Without this Ethernet is broken on beagleplay. -- cheers, -roger
[PATCH v2 0/3] rockchip: ringneck-px30: migrate to common bss and stack addresses
PX30 Ringneck ran out of memory in the allocation pool of U-Boot proper pre-reloc. Something needed to be done. Jonas did migrate a few SoCs already to this common bss+stack addresses so it made sense to follow the same route for one additional SoC: PX30. The migration of other PX30-based boards will happen in next branch instead, this one however is required for Ringneck to still reach U-Boot CLI. Odroid-Go2 reaches the CLI without the patches in v1. Unknown status for the other boards. @Tom/Kever, please merge this on master. To: Simon Glass To: Philipp Tomsich To: Kever Yang To: Heiko Stuebner To: Jagan Teki To: Suniel Mahesh To: Quentin Schulz To: Klaus Goger Cc: tr...@konsulko.com Cc: jo...@kwiboo.se Cc: u-boot@lists.denx.de Signed-off-by: Quentin Schulz Changes in v2: - remove non-ringneck patches, they'll be for next instead - Link to v1: https://lore.kernel.org/r/20240521-px30-2024-07-rc-v1-0-62109c84d...@cherry.de --- Quentin Schulz (3): rockchip: px30: default TPL_SYS_MALLOC_F_LEN to 0x600 on PX30 Kconfig level rockchip: Use common bss and stack addresses on PX30 rockchip: ringneck_px30: Use common bss and stack addresses arch/arm/mach-rockchip/px30/Kconfig | 8 +++- configs/evb-px30_defconfig| 1 - configs/firefly-px30_defconfig| 1 - configs/odroid-go2_defconfig | 1 - configs/px30-core-ctouch2-of10-px30_defconfig | 1 - configs/px30-core-ctouch2-px30_defconfig | 1 - configs/px30-core-edimm2.2-px30_defconfig | 1 - configs/ringneck-px30_defconfig | 19 +++ 8 files changed, 10 insertions(+), 23 deletions(-) --- base-commit: a7f0154c412859323396111dd0c09dbafbc153cb change-id: 20240521-px30-2024-07-rc-7136f6241d29 Best regards, -- Quentin Schulz
Re: [PATCH v2 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
On Mon, 13 May 2024 15:13:53 +0300, Roger Quadros wrote: > Sync AM62 device tree files with Linux v6.9 and > add in the missing bits in -u-boot.dtsi to get CPSW > Ethernet working. > > CI testing > https://github.com/u-boot/u-boot/pull/534 > > [...] Applied to u-boot/next, thanks! -- Tom
[PATCH v2 0/3] cyclic/watchdog patches
A bit of a mixed bag. I've been wanting to submit something like 3/3 for a while. So when I stumbled on Marek's patch https://lore.kernel.org/u-boot/20240316201416.211480-1-marek.vasut+rene...@mailbox.org/ , I got reminded of that plan, and I think that patch could be more readable if we adopt this model. While actually doing those mostly mechanical changes, I stumbled on two separate issues that probably want fixing regardless of the fate of 3/3. For now only compile-tested. v2: Add R-bs from Stefan. Fixup whitespace in the doc/ part. Rebase to current master (676903c1b97), fixing trivial conflict with 301bac6047c8. Rasmus Villemoes (3): cyclic: stop strdup'ing name in cyclic_register() wdt-uclass: prevent multiple cyclic_register calls cyclic: make clients embed a struct cyclic_info in their own data structure board/Marvell/octeon_nic23/board.c | 9 --- cmd/cyclic.c | 12 -- common/cyclic.c| 24 +-- doc/develop/cyclic.rst | 26 drivers/watchdog/wdt-uclass.c | 38 -- include/cyclic.h | 36 ++-- 6 files changed, 71 insertions(+), 74 deletions(-) -- 2.40.1.1.g1c60b9335d
Re: [PATCH v2 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
On Mon, 13 May 2024 15:13:53 +0300, Roger Quadros wrote: > Sync AM62 device tree files with Linux v6.9 and > add in the missing bits in -u-boot.dtsi to get CPSW > Ethernet working. > > CI testing > https://github.com/u-boot/u-boot/pull/534 > > [...] Applied to u-boot/master, thanks! -- Tom
[PATCH v2 0/3] arm: dts: am62-beagleplay: Fix Beagleplay Ethernet
Sync AM62 device tree files with Linux v6.9 and add in the missing bits in -u-boot.dtsi to get CPSW Ethernet working. CI testing https://github.com/u-boot/u-boot/pull/534 Signed-off-by: Roger Quadros --- --- Changes in v2: - rebase on u-boot/next 13th May 2024 - drop 'not-for-merge' comment for patch 3 as it can now be merged - Link to v1: https://lore.kernel.org/r/20240425-for-2024-07-beagleplay-eth-v1-0-6c985de1c...@kernel.org --- Roger Quadros (3): arm: dts: k3-am62*: sync with Linux v6.9 arm: dts: k3-am625-beagleplay: get CPSW Ethernet to work arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset GPIO arch/arm/dts/k3-am62-main.dtsi | 126 ++--- arch/arm/dts/k3-am62-mcu.dtsi| 4 +- arch/arm/dts/k3-am62-thermal.dtsi| 5 +- arch/arm/dts/k3-am62-wakeup.dtsi | 38 +++-- arch/arm/dts/k3-am62.dtsi| 4 +- arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 63 + arch/arm/dts/k3-am625-beagleplay.dts | 66 - arch/arm/dts/k3-am625-sk.dts | 4 +- arch/arm/dts/k3-am625.dtsi | 4 +- arch/arm/dts/k3-am62a-main.dtsi | 201 +-- arch/arm/dts/k3-am62a-mcu.dtsi | 4 +- arch/arm/dts/k3-am62a-thermal.dtsi | 5 +- arch/arm/dts/k3-am62a-wakeup.dtsi| 4 +- arch/arm/dts/k3-am62a.dtsi | 4 +- arch/arm/dts/k3-am62a7-sk.dts| 162 - arch/arm/dts/k3-am62a7.dtsi | 4 +- arch/arm/dts/k3-am62x-sk-common.dtsi | 24 +++- 17 files changed, 621 insertions(+), 101 deletions(-) --- base-commit: c67199962b2a819a4b0ae8d57dc68b7cadee0c9e change-id: 20240305-for-2024-07-beagleplay-eth-f82a51197937 Best regards, -- Roger Quadros
[PATCH v2 0/3] riscv: Rename spl_soc_init() to spl_dram_init()
From: Lukas Funke This patch series renames spl_soc_init() to spl_dram_init() since the purpose of the function is to initialization the DRAM on sifive/starfive boards. spl_dram_init() is a commonly used function for this purpose. Changes in v2: - capitalized acronym DRAM Lukas Funke (3): arch: riscv: Rename spl_soc_init() to spl_dram_init() board: sifive: Call spl_dram_init() for DRAM initialization board: starfive: Call spl_dram_init() for DRAM initialization arch/riscv/cpu/fu540/spl.c | 2 +- arch/riscv/cpu/fu740/spl.c | 2 +- arch/riscv/cpu/jh7110/spl.c | 2 +- arch/riscv/include/asm/arch-fu540/spl.h | 2 +- arch/riscv/include/asm/arch-fu740/spl.h | 2 +- arch/riscv/include/asm/arch-jh7110/spl.h | 2 +- board/sifive/unleashed/spl.c | 4 ++-- board/sifive/unmatched/spl.c | 4 ++-- board/starfive/visionfive2/spl.c | 4 ++-- 9 files changed, 12 insertions(+), 12 deletions(-) -- 2.30.2
[PATCH v2 0/3] Introduce NET_PREFER_ROM_MAC_ADDR config
When there is a MAC address mismatch between ROM and environment, u-boot chooses the one from the environment. This config allows to prefer the MAC address from the ROM instead of the environment. See the first commit message for details. Changes since v1: - Simplify implementation with a NET_PREFER_ROM_MAC_ADDR config Detlev Casanova (3): net: eth-uclass: Introduce NET_PREFER_ROM_MAC_ADDR configs/rock5b: Set NET_PREFER_ROM_MAC_ADDR to y net: eth-uclass: Add driver source possibility configs/rock5b-rk3588_defconfig | 1 + net/Kconfig | 7 +++ net/eth-uclass.c| 17 + 3 files changed, 21 insertions(+), 4 deletions(-) -- 2.43.2
[PATCH v2 0/3] rockchip: rk3328: Add IO-domain driver and speed up boot
This series adds support for RK3328 to the IO-domain driver, it also enabled ARMv8 crypto extensions and OF_LIVE to speed up boot on rk3328 boards. Before this series init time is around 4.1 seconds on a Rock64 v2.0: => bootstage report Timer summary in microseconds (11 records): MarkElapsed Stage 63,628 SPL 284,173220,545 end phase 342,709 58,536 board_init_f 967,537624,828 board_init_r 2,980,332 2,012,795 eth_common_init 4,141,289 1,160,957 eth_initialize 4,141,545256 main_loop 4,146,525 4,980 cli_loop Accumulated time: 71,396 dm_spl 329,994 dm_f 12,355 dm_r After this series init time is around 1.3 seconds on same Rock64 v2.0: => bootstage report Timer summary in microseconds (12 records): MarkElapsed Stage 63,628 SPL 284,173220,545 end phase 303,282 19,109 board_init_f 942,973639,691 board_init_r 1,194,831251,858 eth_common_init 1,363,405168,574 eth_initialize 1,363,609204 main_loop 1,363,738129 cli_loop Accumulated time: 113,648 dm_spl 344,913 dm_f 6,788 of_live 17,895 dm_r Changes in v2: - Rebase on latest master bransh Jonas Karlman (3): rockchip: rk3328: Sort imply statements alphabetically rockchip: rk3328: Enable ARMv8 crypto extensions rockchip: io-domain: Add support for RK3328 arch/arm/mach-rockchip/Kconfig| 14 +++ arch/arm/mach-rockchip/rk3328/syscon_rk3328.c | 3 ++ configs/evb-rk3328_defconfig | 1 + drivers/misc/Kconfig | 2 +- drivers/misc/rockchip-io-domain.c | 38 +++ 5 files changed, 50 insertions(+), 8 deletions(-) -- 2.43.2
[PATCH v2 0/3] board: sophgo: milkv_duo: Add ethernet support for Milk-V Duo board
This series add init code for cv1800b ethernet phy and enable ethernet support for Sophgo Milk-V Duo board. In cv1800b, as the PHY register phy_id being initialized to 0, it is necessary to initialize the PHY before the ethernet driver initialization. Therefore, the initialization code is placed in the board_init function. For the Linux kernel, due to the presence of a hibernation mechanism, whether the phy id will be reset to 0 after hibernation and how to reassign it thereafter remains an issue to consider. Once this issue is resolved, the Ethernet driver for the Milk-V Duo will be sent to the kernel. Changes in v2: - Change compatible - Add clocks and interrupt properties. Kongyang Liu (3): board: milkv_duo: Add init code for Milk-V Duo ethernet riscv: dts: sophgo: Add ethernet node configs: milkv_duo: Add ethernet configs arch/riscv/dts/cv1800b-milkv-duo.dts | 7 ++- arch/riscv/dts/cv18xx.dtsi | 23 board/sophgo/milkv_duo/Makefile | 3 +- board/sophgo/milkv_duo/board.c | 4 ++ board/sophgo/milkv_duo/ethernet.c| 79 board/sophgo/milkv_duo/ethernet.h| 11 configs/milkv_duo_defconfig | 4 ++ drivers/net/designware.c | 1 + 8 files changed, 130 insertions(+), 2 deletions(-) create mode 100644 board/sophgo/milkv_duo/ethernet.c create mode 100644 board/sophgo/milkv_duo/ethernet.h -- 2.41.0
Re: [PATCH v2 0/3] qcom: serial_msm: calculate UARTDM_CSR automatically
On Mon, 15 Apr 2024 16:03:37 +0100, Caleb Connolly wrote: > The msm serial UART controller has a bit clock divider register which > much be programmed based on the UART clock. This changes per soc and > currently is expected to be specified in DT or otherwise selected per > board. > > This series fixes the apq8016 and ipq4019 clock drivers to return the > programmed UART clock rate in clk_set_rate(), it then uses this clock > rate and the hardcoded baud rate supported by this driver to calculate > the correct value for the UARTDM_CSR register. > > [...] Applied, thanks! [1/3] clk/qcom: apq8016: return valid rate when setting UART clock commit: f191853d77899c8a845f20f62068c4ee68d2a020 [2/3] clk/qcom: ipq4019: return valid rate when setting UART clock commit: b49b68909b5f4030869051073857d086c5292461 [3/3] serial: msm: calculate bit clock divider commit: 1aadf1ebc32c8bf7f4eae9ab2abaf63c1fea7d4f Best regards, -- // Caleb (they/them)
[PATCH v2 0/3] qcom: serial_msm: calculate UARTDM_CSR automatically
The msm serial UART controller has a bit clock divider register which much be programmed based on the UART clock. This changes per soc and currently is expected to be specified in DT or otherwise selected per board. This series fixes the apq8016 and ipq4019 clock drivers to return the programmed UART clock rate in clk_set_rate(), it then uses this clock rate and the hardcoded baud rate supported by this driver to calculate the correct value for the UARTDM_CSR register. --- Changes in v2: - use CONFIG_VAL(DEBUG_UART_CLOCK) for debug uart clk_rate. - Link to v1: https://lore.kernel.org/r/20240415-b4-msm-serial-bitrate-v1-0-5a89f84fd...@linaro.org --- Caleb Connolly (3): clk/qcom: apq8016: return valid rate when setting UART clock clk/qcom: ipq4019: return valid rate when setting UART clock serial: msm: calculate bit clock divider doc/device-tree-bindings/serial/msm-serial.txt | 10 --- drivers/clk/qcom/clock-apq8016.c | 4 +- drivers/clk/qcom/clock-ipq4019.c | 2 +- drivers/serial/serial_msm.c| 87 +- 4 files changed, 73 insertions(+), 30 deletions(-) --- base-commit: 42f6978987336cff3d98d9cc4643c54a1eb0f36d // Caleb (they/them)
Re: [PATCH v2 0/3] *** Introduce get_boot_device() for K3 platform ***
On Wed, Apr 03, 2024 at 03:59:08PM +0200, Wadim Egorov wrote: > It is handy to have some u-boot environment variables set based on > the current booting device. > Provide a way to obtain the boot device for non SPLs by factoring out > spl_boot_device() into an own function get_boot_device(). Applied to u-boot/master now (but I seem to have missed this in b4 ty), thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 0/3] qcom: support SPMI buttons on SM8550 and SM8650
On Wed, 10 Apr 2024 17:59:42 +0200, Neil Armstrong wrote: > First add PMIC gpio variant on pm8550-gpio, then rework the > qcom-pmic button driver to support data structs for each PMIC > variant and finally add the data for the pmk8350 button configs. > > Applied, thanks! [1/3] gpio: qcom_pmic_gpio: add support for pm8550-gpio commit: 21e19a823aba68fe585ab48ff89c1414554ac929 [2/3] button: qcom-pmic: move node name checks to btn_data struct commit: 28b264674fdd0b50a396a22115e097dae47945fa [3/3] button: qcom-pmic: add support for pmk8350 button configs commit: 43923bfb5040c245645aa91bc000b92117c587dd Best regards, -- Caleb Connolly
[PATCH v2 0/3] qcom: support SPMI buttons on SM8550 and SM8650
First add PMIC gpio variant on pm8550-gpio, then rework the qcom-pmic button driver to support data structs for each PMIC variant and finally add the data for the pmk8350 button configs. Signed-off-by: Neil Armstrong --- Changes in v2: - added missing qcom,pmk8350-pon compatible - Link to v1: https://lore.kernel.org/r/20240405-topic-sm8x50-spmi-clients-v1-0-c28603ebc...@linaro.org --- Neil Armstrong (3): gpio: qcom_pmic_gpio: add support for pm8550-gpio button: qcom-pmic: move node name checks to btn_data struct button: qcom-pmic: add support for pmk8350 button configs drivers/button/button-qcom-pmic.c | 99 --- drivers/gpio/qcom_pmic_gpio.c | 18 ++- 2 files changed, 87 insertions(+), 30 deletions(-) --- base-commit: f0e6aba1218bca578605697eed8aa94582bf57bb change-id: 20240404-topic-sm8x50-spmi-clients-d9a085aae979 Best regards, -- Neil Armstrong
[PATCH v2 0/3] mtd: spi-nor: Add support for S25FS-S family
From: Takahiro Kuwano The S25FS064S, S25FS128S, and S25FS256S are the same family of SPI NOR Flash devices with S25FS512S. Datasheets: https://www.infineon.com/dgdl/Infineon-S25FS064S_64_Mb_8_MB_FS-S_Flash_SPI_Multi-I_O_1-DataSheet-v10_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ed526b25412 https://www.infineon.com/dgdl/Infineon-S25FS128S_S25FS256S_1.8_V_Serial_Peripheral_Interface_with_Multi-I_O_MirrorBit(R)_Non-Volatile_Flash-DataSheet-v15_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ed6b5ab5758 Takahiro Kuwano (3): mtd: spi-nore-core: Fix 4KB erase opcode in s25fs-s mtd: spi-nor-id: Use INFO6 for S25FL-S mtd: spi-nor: Add support for Infineon S25FS-S family drivers/mtd/spi/spi-nor-core.c | 28 +--- drivers/mtd/spi/spi-nor-ids.c | 7 +-- 2 files changed, 26 insertions(+), 9 deletions(-) -- 2.34.1
[PATCH v2 0/3] *** Introduce get_boot_device() for K3 platform ***
It is handy to have some u-boot environment variables set based on the current booting device. Provide a way to obtain the boot device for non SPLs by factoring out spl_boot_device() into an own function get_boot_device(). v2: - Relocate bootindex to OCRAM, drop misleading comments and remove not needed changes - Make get_boot_device() read bootindex out of OCRAM - Add user for get_boot_device(), patch 3 v1: https://lists.denx.de/pipermail/u-boot/2024-February/546770.html Wadim Egorov (3): arm: mach-k3: am625: copy bootindex to OCRAM for main domain SPL arm: mach-k3: am625: Provide a way to obtain boot device for non SPLs board: phycore-am62x: Extend for better environment handling arch/arm/mach-k3/Makefile | 1 + arch/arm/mach-k3/am625_init.c | 103 ++ arch/arm/mach-k3/am62x/Makefile | 2 + arch/arm/mach-k3/am62x/boot.c | 103 ++ arch/arm/mach-k3/include/mach/am62_hardware.h | 1 + arch/arm/mach-k3/include/mach/hardware.h | 1 + board/phytec/phycore_am62x/phycore-am62x.c| 64 +++ configs/phycore_am62x_a53_defconfig | 1 + 8 files changed, 182 insertions(+), 94 deletions(-) create mode 100644 arch/arm/mach-k3/am62x/Makefile create mode 100644 arch/arm/mach-k3/am62x/boot.c -- 2.34.1
Re: [PATCH v2 0/3] Introduce mtdblock device
Hi guys! Ping. On Thu, Mar 07, 2024 at 04:07:23PM +0300, Alexey Romanov wrote: > Hello! > > This series adds support for the mtdblock device, which > allows to read/write data block by block. For example, > it can now be used for BCB or Android AB command: > > $ bcb load mtd 0 part_name > > Tested only on SPI NAND, so bind is made only for > SPI NAND drivers. > > --- > > Changes V1 -> V2 [1]: > > - Drop patch [2]. > - Add warning if bind NAND mtdblock device. > - Move documentation of mtdblock implementation > from commit message to the source code. > - Remove __maybe_unused from mtd partition functions > description. > - Use blk_enabled() instead of #ifdefs. > > Links: > > - [1] > https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/ > - [2] > https://lore.kernel.org/all/20240227100441.1811047-5-avroma...@salutedevices.com/ > > Alexey Romanov (3): > disk: support MTD partitions > drivers: introduce mtdblock abstraction > spinand: bind mtdblock > > disk/part.c | 5 +- > drivers/block/blk-uclass.c | 1 + > drivers/mtd/Kconfig | 1 + > drivers/mtd/Makefile| 1 + > drivers/mtd/mtdblock.c | 227 > drivers/mtd/mtdpart.c | 69 +++ > drivers/mtd/nand/spi/core.c | 20 > include/linux/mtd/mtd.h | 12 ++ > include/part.h | 2 + > 9 files changed, 337 insertions(+), 1 deletion(-) > create mode 100644 drivers/mtd/mtdblock.c > > -- > 2.34.1 > -- Thank you, Alexey
Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes
On 4/2/24 13:32, Laurent Pinchart wrote: Hi Florian, On Tue, Apr 02, 2024 at 01:18:35PM -0700, Florian Fainelli wrote: On 4/2/24 13:08, Laurent Pinchart wrote: On Tue, Apr 02, 2024 at 09:52:06PM +0200, Stefan Wahren wrote: Am 02.04.24 um 10:58 schrieb Ivan T. Ivanov: On 2024-03-28 01:37, Laurent Pinchart wrote: On Wed, Mar 27, 2024 at 07:49:38AM +0100, Stefan Wahren wrote: Hi, [add Peter and Ivan] Am 26.03.24 um 20:58 schrieb Laurent Pinchart: Hello, This small series includes a few drive-by fixes for DT validation errors. The first patch has been posted previously in v1 ([1], and now addresses a small review comment. I think it's good to go. The next two patches address the same issue as "[PATCH 1/2] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]), but this time with a (hopefully) correct approach. Patch 2/3 starts by fixing the raspberrypi-bcm2835-firmware driver, removing the need for DT properties that are specified in bcm2835-rpi.dtsi but not documented in the corresponding bindings. Patch 3/3 can then drop those properties, getting rid of the warnings. since this series drops properties from the device tree, does anyone have the chance to test it with a recent U-Boot? I don't have U-Boot running with my RPi, so I would appreciate if someone could help :-) Sorry for taking me so long to verify this. I think on RPi U-Boot side we are fine. API used when accessing Mbox device do not follow DM model and do not use DMA, but just access device directly using this nice macros phys_to_bus/bus_to_phys. I build new DTB files with this patch included and U-Boot build from the latest sources. No obvious issues on RPi3 and RPi4. Devices boot fine. Thank you for testing Ivan. Thanks you, Laurent and Ivan Reviewed-by: Stefan Wahren Stefan, I'm quite unfamiliar with the Raspberry Pi upstreaming process (despite having sent patches for ages :-)), do I understand correctly that this patch will go through your tree, or do I need to work with someone else to get it merged upstream ? I will be taking those via the Broadcom SoC tree. Thank you. If there's a chance to include patches 05/10, 07/10, 08/10 and 09/10 from [1] at the same time, that would be great :-) [1] https://lore.kernel.org/linux-media/20240402000424.4650-1-laurent.pinch...@ideasonboard.com Yes, now done, thanks! -- Florian smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes
Hi Florian, On Tue, Apr 02, 2024 at 01:18:35PM -0700, Florian Fainelli wrote: > On 4/2/24 13:08, Laurent Pinchart wrote: > > On Tue, Apr 02, 2024 at 09:52:06PM +0200, Stefan Wahren wrote: > >> Am 02.04.24 um 10:58 schrieb Ivan T. Ivanov: > >>> On 2024-03-28 01:37, Laurent Pinchart wrote: > On Wed, Mar 27, 2024 at 07:49:38AM +0100, Stefan Wahren wrote: > > Hi, > > > > [add Peter and Ivan] > > > > Am 26.03.24 um 20:58 schrieb Laurent Pinchart: > >> Hello, > >> > >> This small series includes a few drive-by fixes for DT validation > >> errors. > >> > >> The first patch has been posted previously in v1 ([1], and now > >> addresses > >> a small review comment. I think it's good to go. > >> > >> The next two patches address the same issue as "[PATCH 1/2] > >> dt-bindings: > >> arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]), > >> but this time with a (hopefully) correct approach. Patch 2/3 starts by > >> fixing the raspberrypi-bcm2835-firmware driver, removing the need for > >> DT > >> properties that are specified in bcm2835-rpi.dtsi but not documented in > >> the corresponding bindings. Patch 3/3 can then drop those properties, > >> getting rid of the warnings. > > > > since this series drops properties from the device tree, does anyone > > have the chance to test it with a recent U-Boot? > > I don't have U-Boot running with my RPi, so I would appreciate if > someone could help :-) > >>> > >>> Sorry for taking me so long to verify this. > >>> > >>> I think on RPi U-Boot side we are fine. API used when accessing Mbox > >>> device do not follow DM model and do not use DMA, but just access > >>> device directly using this nice macros phys_to_bus/bus_to_phys. > >>> > >>> I build new DTB files with this patch included and U-Boot build > >>> from the latest sources. No obvious issues on RPi3 and RPi4. > >>> Devices boot fine. > > > > Thank you for testing Ivan. > > > >> Thanks you, Laurent and Ivan > >> > >> Reviewed-by: Stefan Wahren > > > > Stefan, I'm quite unfamiliar with the Raspberry Pi upstreaming process > > (despite having sent patches for ages :-)), do I understand correctly > > that this patch will go through your tree, or do I need to work with > > someone else to get it merged upstream ? > > I will be taking those via the Broadcom SoC tree. Thank you. If there's a chance to include patches 05/10, 07/10, 08/10 and 09/10 from [1] at the same time, that would be great :-) [1] https://lore.kernel.org/linux-media/20240402000424.4650-1-laurent.pinch...@ideasonboard.com -- Regards, Laurent Pinchart
Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes
On 4/2/24 01:58, Ivan T. Ivanov wrote: Hi, On 2024-03-28 01:37, Laurent Pinchart wrote: On Wed, Mar 27, 2024 at 07:49:38AM +0100, Stefan Wahren wrote: Hi, [add Peter and Ivan] Am 26.03.24 um 20:58 schrieb Laurent Pinchart: > Hello, > > This small series includes a few drive-by fixes for DT validation > errors. > > The first patch has been posted previously in v1 ([1], and now addresses > a small review comment. I think it's good to go. > > The next two patches address the same issue as "[PATCH 1/2] dt-bindings: > arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]), > but this time with a (hopefully) correct approach. Patch 2/3 starts by > fixing the raspberrypi-bcm2835-firmware driver, removing the need for DT > properties that are specified in bcm2835-rpi.dtsi but not documented in > the corresponding bindings. Patch 3/3 can then drop those properties, > getting rid of the warnings. since this series drops properties from the device tree, does anyone have the chance to test it with a recent U-Boot? I don't have U-Boot running with my RPi, so I would appreciate if someone could help :-) Sorry for taking me so long to verify this. I think on RPi U-Boot side we are fine. API used when accessing Mbox device do not follow DM model and do not use DMA, but just access device directly using this nice macros phys_to_bus/bus_to_phys. I build new DTB files with this patch included and U-Boot build from the latest sources. No obvious issues on RPi3 and RPi4. Devices boot fine. Can I add this as a Tested-by tag from you while applying then? -- Florian
Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes
Hi Laurent, Am 02.04.24 um 22:08 schrieb Laurent Pinchart: Hello, ... Stefan, I'm quite unfamiliar with the Raspberry Pi upstreaming process (despite having sent patches for ages :-)), do I understand correctly that this patch will go through your tree, or do I need to work with someone else to get it merged upstream ? i'm not the maintainer, but i'm trying to help. Florian is the maintainer, so i would expect this series goes through his tree. So MAINTAINERS file is correct here.
Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes
On 4/2/24 13:08, Laurent Pinchart wrote: Hello, On Tue, Apr 02, 2024 at 09:52:06PM +0200, Stefan Wahren wrote: Am 02.04.24 um 10:58 schrieb Ivan T. Ivanov: On 2024-03-28 01:37, Laurent Pinchart wrote: On Wed, Mar 27, 2024 at 07:49:38AM +0100, Stefan Wahren wrote: Hi, [add Peter and Ivan] Am 26.03.24 um 20:58 schrieb Laurent Pinchart: Hello, This small series includes a few drive-by fixes for DT validation errors. The first patch has been posted previously in v1 ([1], and now addresses a small review comment. I think it's good to go. The next two patches address the same issue as "[PATCH 1/2] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]), but this time with a (hopefully) correct approach. Patch 2/3 starts by fixing the raspberrypi-bcm2835-firmware driver, removing the need for DT properties that are specified in bcm2835-rpi.dtsi but not documented in the corresponding bindings. Patch 3/3 can then drop those properties, getting rid of the warnings. since this series drops properties from the device tree, does anyone have the chance to test it with a recent U-Boot? I don't have U-Boot running with my RPi, so I would appreciate if someone could help :-) Sorry for taking me so long to verify this. I think on RPi U-Boot side we are fine. API used when accessing Mbox device do not follow DM model and do not use DMA, but just access device directly using this nice macros phys_to_bus/bus_to_phys. I build new DTB files with this patch included and U-Boot build from the latest sources. No obvious issues on RPi3 and RPi4. Devices boot fine. Thank you for testing Ivan. Thanks you, Laurent and Ivan Reviewed-by: Stefan Wahren Stefan, I'm quite unfamiliar with the Raspberry Pi upstreaming process (despite having sent patches for ages :-)), do I understand correctly that this patch will go through your tree, or do I need to work with someone else to get it merged upstream ? I will be taking those via the Broadcom SoC tree. -- Florian
Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes
Hello, On Tue, Apr 02, 2024 at 09:52:06PM +0200, Stefan Wahren wrote: > Am 02.04.24 um 10:58 schrieb Ivan T. Ivanov: > > On 2024-03-28 01:37, Laurent Pinchart wrote: > >> On Wed, Mar 27, 2024 at 07:49:38AM +0100, Stefan Wahren wrote: > >>> Hi, > >>> > >>> [add Peter and Ivan] > >>> > >>> Am 26.03.24 um 20:58 schrieb Laurent Pinchart: > >>> > Hello, > >>> > > >>> > This small series includes a few drive-by fixes for DT validation > >>> > errors. > >>> > > >>> > The first patch has been posted previously in v1 ([1], and now addresses > >>> > a small review comment. I think it's good to go. > >>> > > >>> > The next two patches address the same issue as "[PATCH 1/2] dt-bindings: > >>> > arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]), > >>> > but this time with a (hopefully) correct approach. Patch 2/3 starts by > >>> > fixing the raspberrypi-bcm2835-firmware driver, removing the need for DT > >>> > properties that are specified in bcm2835-rpi.dtsi but not documented in > >>> > the corresponding bindings. Patch 3/3 can then drop those properties, > >>> > getting rid of the warnings. > >>> > >>> since this series drops properties from the device tree, does anyone > >>> have the chance to test it with a recent U-Boot? > >> > >> I don't have U-Boot running with my RPi, so I would appreciate if > >> someone could help :-) > > > > Sorry for taking me so long to verify this. > > > > I think on RPi U-Boot side we are fine. API used when accessing Mbox > > device do not follow DM model and do not use DMA, but just access > > device directly using this nice macros phys_to_bus/bus_to_phys. > > > > I build new DTB files with this patch included and U-Boot build > > from the latest sources. No obvious issues on RPi3 and RPi4. > > Devices boot fine. Thank you for testing Ivan. > Thanks you, Laurent and Ivan > > Reviewed-by: Stefan Wahren Stefan, I'm quite unfamiliar with the Raspberry Pi upstreaming process (despite having sent patches for ages :-)), do I understand correctly that this patch will go through your tree, or do I need to work with someone else to get it merged upstream ? -- Regards, Laurent Pinchart
Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes
Am 02.04.24 um 10:58 schrieb Ivan T. Ivanov: Hi, On 2024-03-28 01:37, Laurent Pinchart wrote: On Wed, Mar 27, 2024 at 07:49:38AM +0100, Stefan Wahren wrote: Hi, [add Peter and Ivan] Am 26.03.24 um 20:58 schrieb Laurent Pinchart: > Hello, > > This small series includes a few drive-by fixes for DT validation > errors. > > The first patch has been posted previously in v1 ([1], and now addresses > a small review comment. I think it's good to go. > > The next two patches address the same issue as "[PATCH 1/2] dt-bindings: > arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]), > but this time with a (hopefully) correct approach. Patch 2/3 starts by > fixing the raspberrypi-bcm2835-firmware driver, removing the need for DT > properties that are specified in bcm2835-rpi.dtsi but not documented in > the corresponding bindings. Patch 3/3 can then drop those properties, > getting rid of the warnings. since this series drops properties from the device tree, does anyone have the chance to test it with a recent U-Boot? I don't have U-Boot running with my RPi, so I would appreciate if someone could help :-) Sorry for taking me so long to verify this. I think on RPi U-Boot side we are fine. API used when accessing Mbox device do not follow DM model and do not use DMA, but just access device directly using this nice macros phys_to_bus/bus_to_phys. I build new DTB files with this patch included and U-Boot build from the latest sources. No obvious issues on RPi3 and RPi4. Devices boot fine. Thanks you, Laurent and Ivan Reviewed-by: Stefan Wahren Regards, Ivan
Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes
Hi, On 2024-03-28 01:37, Laurent Pinchart wrote: On Wed, Mar 27, 2024 at 07:49:38AM +0100, Stefan Wahren wrote: Hi, [add Peter and Ivan] Am 26.03.24 um 20:58 schrieb Laurent Pinchart: > Hello, > > This small series includes a few drive-by fixes for DT validation > errors. > > The first patch has been posted previously in v1 ([1], and now addresses > a small review comment. I think it's good to go. > > The next two patches address the same issue as "[PATCH 1/2] dt-bindings: > arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]), > but this time with a (hopefully) correct approach. Patch 2/3 starts by > fixing the raspberrypi-bcm2835-firmware driver, removing the need for DT > properties that are specified in bcm2835-rpi.dtsi but not documented in > the corresponding bindings. Patch 3/3 can then drop those properties, > getting rid of the warnings. since this series drops properties from the device tree, does anyone have the chance to test it with a recent U-Boot? I don't have U-Boot running with my RPi, so I would appreciate if someone could help :-) Sorry for taking me so long to verify this. I think on RPi U-Boot side we are fine. API used when accessing Mbox device do not follow DM model and do not use DMA, but just access device directly using this nice macros phys_to_bus/bus_to_phys. I build new DTB files with this patch included and U-Boot build from the latest sources. No obvious issues on RPi3 and RPi4. Devices boot fine. Regards, Ivan
Re: [PATCH v2 0/3] crypto/fsl: allow accessing Job Ring from non-TrustZone
On Thu, Mar 28, 2024 at 7:18 AM Emanuele Ghidoli
wrote:
>
> From: Emanuele Ghidoli
>
> This series allows using Freescale CAAM Job Ring from Linux without having
> OP-TEE,
> this is needed for example on Toradex Colibri iMX7 where we just have U-Boot
> + Linux kernel.
>
> To achieve this add a new config option to allow the non-secure world to
> access job rings.
>
> The functionality has been broken since U-Boot v2019.07, with commit
> 51f1357f3428
> ("Revert "drivers/crypto/fsl: assign job-rings to non-TrustZone"")
>
> Link:
> https://lore.kernel.org/all/4b64a9de-a840-4065-a530-f81155b4b...@toradex.com/
>
> ---
> v2:
> * Kconfig: spelt "CAAM" instead of caam
> * Kconfig: removed "default=n"
> v1:
> https://lore.kernel.org/all/20240325114642.3664840-1-ghidoliemanu...@gmail.com/
Applied to u-boot-imx/next, thanks.
[PATCH v2 0/3] crypto/fsl: allow accessing Job Ring from non-TrustZone
From: Emanuele Ghidoli
This series allows using Freescale CAAM Job Ring from Linux without having
OP-TEE,
this is needed for example on Toradex Colibri iMX7 where we just have U-Boot +
Linux kernel.
To achieve this add a new config option to allow the non-secure world to access
job rings.
The functionality has been broken since U-Boot v2019.07, with commit
51f1357f3428
("Revert "drivers/crypto/fsl: assign job-rings to non-TrustZone"")
Link:
https://lore.kernel.org/all/4b64a9de-a840-4065-a530-f81155b4b...@toradex.com/
---
v2:
* Kconfig: spelt "CAAM" instead of caam
* Kconfig: removed "default=n"
v1:
https://lore.kernel.org/all/20240325114642.3664840-1-ghidoliemanu...@gmail.com/
Emanuele Ghidoli (3):
crypto/fsl: allow accessing Job Ring from non-TrustZone
configs: colibri-imx7: set non-secure boot mode as default
configs: colibri-imx7: allow accessing job-rings from non-TrustZone
configs/colibri_imx7_defconfig | 1 +
configs/colibri_imx7_emmc_defconfig | 2 +-
drivers/crypto/fsl/Kconfig | 6 ++
drivers/crypto/fsl/jr.c | 19 +++
drivers/crypto/fsl/jr.h | 2 ++
5 files changed, 29 insertions(+), 1 deletion(-)
--
2.34.1
Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes
Hi, > On 28 Mar 2024, at 1:37, Laurent Pinchart > wrote: > > On Wed, Mar 27, 2024 at 07:49:38AM +0100, Stefan Wahren wrote: >> Hi, >> >> [add Peter and Ivan] >> >> Am 26.03.24 um 20:58 schrieb Laurent Pinchart: >>> Hello, >>> >>> This small series includes a few drive-by fixes for DT validation >>> errors. >>> >>> The first patch has been posted previously in v1 ([1], and now addresses >>> a small review comment. I think it's good to go. >>> >>> The next two patches address the same issue as "[PATCH 1/2] dt-bindings: >>> arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]), >>> but this time with a (hopefully) correct approach. Patch 2/3 starts by >>> fixing the raspberrypi-bcm2835-firmware driver, removing the need for DT >>> properties that are specified in bcm2835-rpi.dtsi but not documented in >>> the corresponding bindings. Patch 3/3 can then drop those properties, >>> getting rid of the warnings. >> >> since this series drops properties from the device tree, does anyone >> have the chance to test it with a recent U-Boot? > > I don't have U-Boot running with my RPi, so I would appreciate if > someone could help :-) Sure, just give me some time :-) Regards, Ivan
Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes
On Wed, Mar 27, 2024 at 07:49:38AM +0100, Stefan Wahren wrote: > Hi, > > [add Peter and Ivan] > > Am 26.03.24 um 20:58 schrieb Laurent Pinchart: > > Hello, > > > > This small series includes a few drive-by fixes for DT validation > > errors. > > > > The first patch has been posted previously in v1 ([1], and now addresses > > a small review comment. I think it's good to go. > > > > The next two patches address the same issue as "[PATCH 1/2] dt-bindings: > > arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]), > > but this time with a (hopefully) correct approach. Patch 2/3 starts by > > fixing the raspberrypi-bcm2835-firmware driver, removing the need for DT > > properties that are specified in bcm2835-rpi.dtsi but not documented in > > the corresponding bindings. Patch 3/3 can then drop those properties, > > getting rid of the warnings. > > since this series drops properties from the device tree, does anyone > have the chance to test it with a recent U-Boot? I don't have U-Boot running with my RPi, so I would appreciate if someone could help :-) > > [1] > > https://lore.kernel.org/linux-arm-kernel/20240326004902.17054-3-laurent.pinch...@ideasonboard.com/ > > [2] > > https://lore.kernel.org/linux-arm-kernel/20240326004902.17054-2-laurent.pinch...@ideasonboard.com/ > > > > Laurent Pinchart (3): > >dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add gpio child > > node > >firmware: raspberrypi: Use correct device for DMA mappings > >ARM: dts: bcm283x: Drop unneeded properties in the bcm2835-firmware > > node > > > > .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 30 +++ > > .../gpio/raspberrypi,firmware-gpio.txt| 30 --- > > arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi | 4 --- > > drivers/firmware/raspberrypi.c| 7 +++-- > > 4 files changed, 34 insertions(+), 37 deletions(-) > > delete mode 100644 > > Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt > > -- Regards, Laurent Pinchart
Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes
Hi, [add Peter and Ivan] Am 26.03.24 um 20:58 schrieb Laurent Pinchart: Hello, This small series includes a few drive-by fixes for DT validation errors. The first patch has been posted previously in v1 ([1], and now addresses a small review comment. I think it's good to go. The next two patches address the same issue as "[PATCH 1/2] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]), but this time with a (hopefully) correct approach. Patch 2/3 starts by fixing the raspberrypi-bcm2835-firmware driver, removing the need for DT properties that are specified in bcm2835-rpi.dtsi but not documented in the corresponding bindings. Patch 3/3 can then drop those properties, getting rid of the warnings. since this series drops properties from the device tree, does anyone have the chance to test it with a recent U-Boot? [1] https://lore.kernel.org/linux-arm-kernel/20240326004902.17054-3-laurent.pinch...@ideasonboard.com/ [2] https://lore.kernel.org/linux-arm-kernel/20240326004902.17054-2-laurent.pinch...@ideasonboard.com/ Laurent Pinchart (3): dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add gpio child node firmware: raspberrypi: Use correct device for DMA mappings ARM: dts: bcm283x: Drop unneeded properties in the bcm2835-firmware node .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 30 +++ .../gpio/raspberrypi,firmware-gpio.txt| 30 --- arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi | 4 --- drivers/firmware/raspberrypi.c| 7 +++-- 4 files changed, 34 insertions(+), 37 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt
[PATCH v2 0/3] rockchip: spl: Cache boot source id for later use
This series fixes an issue where /chosen/u-boot,spl-boot-device prop cannot be resolved to the SPI flash node path in spl_perform_fixups() if the affected device was booted from SPI flash. Changes in v2: - Add patch that sync boot source id enum with bootrom - Add patch that adds missing SPI flash node path for SoCs with DTs having a jedec,spi-nor compatible flash@0 node. - Only cache boot source id that can be resolved to a node path - Make use of synced BROM_BOOTSOURCE_UNKNOWN enum value - Update commit message - Add fixes tag - Collect r-b tag Jason Zhu (1): rockchip: bootrom: Sync bootsource id enum from bootrom Jonas Karlman (2): rockchip: spl: Cache boot source id for later use rockchip: spl: Add SPI NOR flash to boot_devices array arch/arm/include/asm/arch-rockchip/bootrom.h | 3 +++ arch/arm/mach-rockchip/px30/px30.c | 1 + arch/arm/mach-rockchip/rk3288/rk3288.c | 1 + arch/arm/mach-rockchip/rk3308/rk3308.c | 1 + arch/arm/mach-rockchip/rk3368/rk3368.c | 1 + arch/arm/mach-rockchip/rv1126/rv1126.c | 1 + arch/arm/mach-rockchip/spl.c | 14 +++--- 7 files changed, 19 insertions(+), 3 deletions(-) -- 2.43.2
Re: [PATCH v2 0/3] imx93-phyboard-segin: Add USB support.
Hi Mathieu, On Thu, Mar 21, 2024 at 3:57 AM Mathieu Othacehe wrote: > Mathieu Othacehe (3): > arm: dts: imx93-phyboard-segin: Add USB support > configs: imx93-phyboard-segin: Add USB support > configs: imx93-phyboard-segin: Add fastboot support > > arch/arm/dts/imx93-phyboard-segin.dts | 13 + The addition of the i.MX93 USB support in the kernel devicetree is taking longer than expected: https://lore.kernel.org/linux-arm-kernel/20240321081439.541799-8-xu.yan...@nxp.com/T/#u To avoid getting out of sync with the upstream dts, please add the USB nodes inside imx93-phyboard-segin-u-boot.dtsi for now. Thanks
[PATCH v2 0/3] imx93-phyboard-segin: Add USB support.
Hello, This series adds USB support to imx93-phyboard-segin, in the same way as it has been done for imx93_var_som here: https://lists.denx.de/pipermail/u-boot/2024-February/546301.html Thanks, Mathieu Changelog: v1: https://lists.denx.de/pipermail/u-boot/2024-March/548613.html Mathieu Othacehe (3): arm: dts: imx93-phyboard-segin: Add USB support configs: imx93-phyboard-segin: Add USB support configs: imx93-phyboard-segin: Add fastboot support arch/arm/dts/imx93-phyboard-segin.dts | 13 + configs/imx93-phyboard-segin_defconfig | 14 ++ 2 files changed, 27 insertions(+) -- 2.41.0
Re: [PATCH v2 0/3] Introduce mtdblock device
Hello! Ping. On Thu, Mar 07, 2024 at 04:07:23PM +0300, Alexey Romanov wrote: > Hello! > > This series adds support for the mtdblock device, which > allows to read/write data block by block. For example, > it can now be used for BCB or Android AB command: > > $ bcb load mtd 0 part_name > > Tested only on SPI NAND, so bind is made only for > SPI NAND drivers. > > --- > > Changes V1 -> V2 [1]: > > - Drop patch [2]. > - Add warning if bind NAND mtdblock device. > - Move documentation of mtdblock implementation > from commit message to the source code. > - Remove __maybe_unused from mtd partition functions > description. > - Use blk_enabled() instead of #ifdefs. > > Links: > > - [1] > https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/ > - [2] > https://lore.kernel.org/all/20240227100441.1811047-5-avroma...@salutedevices.com/ > > Alexey Romanov (3): > disk: support MTD partitions > drivers: introduce mtdblock abstraction > spinand: bind mtdblock > > disk/part.c | 5 +- > drivers/block/blk-uclass.c | 1 + > drivers/mtd/Kconfig | 1 + > drivers/mtd/Makefile| 1 + > drivers/mtd/mtdblock.c | 227 > drivers/mtd/mtdpart.c | 69 +++ > drivers/mtd/nand/spi/core.c | 20 > include/linux/mtd/mtd.h | 12 ++ > include/part.h | 2 + > 9 files changed, 337 insertions(+), 1 deletion(-) > create mode 100644 drivers/mtd/mtdblock.c > > -- > 2.34.1 > -- Thank you, Alexey
[PATCH v2 0/3] mmc: sophgo: milkv_duo: Add SD card support for Milk-V Duo board
This series add sdhci driver for cv1800b SoC and enable SD card support for Sophgo Milk-V Duo board. Changes in v2: - Refactored and simplified some of the code. - Sync device tree with ptaches from Linux kernel Kongyang Liu (3): mmc: cv1800b: Add sdhci driver support for cv1800b SoC riscv: dts: sophgo: Add clk node and sdhci node configs: milkv_duo: Add SD card configs arch/riscv/dts/cv1800b-milkv-duo.dts | 8 ++ arch/riscv/dts/cv1800b.dtsi | 4 + arch/riscv/dts/cv18xx.dtsi | 22 + configs/milkv_duo_defconfig | 10 +++ drivers/mmc/Kconfig | 13 +++ drivers/mmc/Makefile | 1 + drivers/mmc/cv1800b_sdhci.c | 116 +++ 7 files changed, 174 insertions(+) create mode 100644 drivers/mmc/cv1800b_sdhci.c -- 2.41.0
[PATCH v2 0/3] Introduce mtdblock device
Hello! This series adds support for the mtdblock device, which allows to read/write data block by block. For example, it can now be used for BCB or Android AB command: $ bcb load mtd 0 part_name Tested only on SPI NAND, so bind is made only for SPI NAND drivers. --- Changes V1 -> V2 [1]: - Drop patch [2]. - Add warning if bind NAND mtdblock device. - Move documentation of mtdblock implementation from commit message to the source code. - Remove __maybe_unused from mtd partition functions description. - Use blk_enabled() instead of #ifdefs. Links: - [1] https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/ - [2] https://lore.kernel.org/all/20240227100441.1811047-5-avroma...@salutedevices.com/ Alexey Romanov (3): disk: support MTD partitions drivers: introduce mtdblock abstraction spinand: bind mtdblock disk/part.c | 5 +- drivers/block/blk-uclass.c | 1 + drivers/mtd/Kconfig | 1 + drivers/mtd/Makefile| 1 + drivers/mtd/mtdblock.c | 227 drivers/mtd/mtdpart.c | 69 +++ drivers/mtd/nand/spi/core.c | 20 include/linux/mtd/mtd.h | 12 ++ include/part.h | 2 + 9 files changed, 337 insertions(+), 1 deletion(-) create mode 100644 drivers/mtd/mtdblock.c -- 2.34.1
Re: [PATCH v2 0/3] Enable OSPI on j721e
On Fri, 23 Feb 2024 18:23:04 -0600, Jonathan Humphreys wrote:
> This series enables OSPI storage and boot.
>
> fixes: 58d61fb5a77e ("arm: dts: k3-j721e-sk: Add initial A72 specific dts
> support")
>
> Changes from v1:
> - added patch to remove the OSPI phy pattern partition, as it wasn't used
>
> [...]
Applied to u-boot/next, thanks!
--
Tom
[PATCH v2 0/3] Enable OSPI on j721e
This series enables OSPI storage and boot.
fixes: 58d61fb5a77e ("arm: dts: k3-j721e-sk: Add initial A72 specific dts
support")
Changes from v1:
- added patch to remove the OSPI phy pattern partition, as it wasn't used
v1: https://patchwork.ozlabs.org/project/uboot/list/?series=396241
Jonathan Humphreys (3):
configs: j721e: Enable OSPI memory
arm: mach-k3: j721e: Enable OSPI boot
arm: dts: k3-j721e-sk: Remove OSPI phypattern partition
arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 4
arch/arm/mach-k3/include/mach/j721e_spl.h | 5 +++--
arch/arm/mach-k3/j721e_init.c | 3 ++-
configs/j721e_evm_a72_defconfig | 7 +++
configs/j721e_evm_r5_defconfig| 6 ++
5 files changed, 18 insertions(+), 7 deletions(-)
--
2.34.1
Re: [PATCH v2 0/3] imx93_var_som: Enable AHAB support
On Fri, Feb 9, 2024 at 7:30 AM Mathieu Othacehe wrote: > > Hello, > > In this v2, I moved imx93_probe_mu to a dedicated header. Applied all, thanks.
[PATCH v2 0/3] imx93_var_som: Enable AHAB support
Hello, In this v2, I moved imx93_probe_mu to a dedicated header. Thanks, Mathieu Changelog: v2: Move imx93_probe_mu declaration to a header file Link to the previous revision: v1: https://lists.denx.de/pipermail/u-boot/2024-February/545528.html Mathieu Othacehe (3): imx93: Use a header for imx9_probe_mu declaration board: imx93_var_som: Probe ELE MU configs: imx93_var_som: Enable AHAB support arch/arm/include/asm/arch-imx9/mu.h | 13 + board/freescale/imx93_evk/spl.c | 2 +- board/phytec/phycore_imx93/spl.c| 2 +- board/variscite/imx93_var_som/spl.c | 5 +++-- configs/imx93_var_som_defconfig | 1 + 5 files changed, 19 insertions(+), 4 deletions(-) create mode 100644 arch/arm/include/asm/arch-imx9/mu.h -- 2.41.0
[PATCH v2 0/3] usb: ehci-generic: setup a bulk of phy when possible
one USB controller can have multiple ports specified in dts, all of them
should be setup to make use of all possible ports.
Signed-off-by: Yang Xiwen
---
Changes in v2:
- Rewrite generic_phy_setup_bulk(): Actually v1 is doing things
completely wrong. This series should work and it's tested on a real
machine.
- Link to v1:
https://lore.kernel.org/r/20240201-ehci-v1-0-bb506cb0f...@outlook.com
---
Yang Xiwen (3):
phy: add generic_setup(shutdown)_phy_bulk()
test: phy: test generic_setup(shutdown)_phy_bulk()
usb: ehci: Make usage of generic_{setup,shutdown}_phy_bulk() helpers
drivers/phy/phy-uclass.c| 41 +
drivers/usb/host/ehci-generic.c | 8
include/generic-phy.h | 29 +
test/dm/phy.c | 4
4 files changed, 78 insertions(+), 4 deletions(-)
---
base-commit: b6d8969bcb94321dfed1399f2eaa8768ba42caaa
change-id: 20240201-ehci-6c3aa7d97932
Best regards,
--
Yang Xiwen
[PATCH v2 0/3] rockchip: rk35xx: Fix writing to eMMC
Testing has shown that writing to eMMC using DDR52 mode does not seem to work on RK356x and RK3588 boards. This series fixes this issue by changing RK356x and RK3588 boards to prefer use of the more reliably HS200 mode. Changes in v2: - Update commit messages - Imply MMC_HS200_SUPPORT and SPL_MMC_HS200_SUPPORT in arch Kconfig instead of adding to each boards defconfig - Combine changes for rk356x and rk3588 in one patch - New patch to fix HS400 mode write on RK3568 Link to v1: https://patchwork.ozlabs.org/cover/1891692/ This series depend on the series "rockchip: rk35xx: Sync device tree with linux v6.8-rc1" [1]. [1] https://patchwork.ozlabs.org/cover/1891669/ Jonas Karlman (3): rockchip: rk35xx: Remove use of eMMC DDR52 mode rockchip: rk35xx: Enable eMMC HS200 mode by default rockchip: sdhci: Fix eMMC HS400 modes for RK3568 arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi| 1 - arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi| 1 - arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - arch/arm/mach-rockchip/Kconfig | 4 configs/nanopi-r5c-rk3568_defconfig | 2 -- configs/nanopi-r5s-rk3568_defconfig | 2 -- configs/radxa-e25-rk3568_defconfig | 2 -- drivers/mmc/rockchip_sdhci.c | 9 + 17 files changed, 9 insertions(+), 22 deletions(-) -- 2.43.0
[PATCH v2 0/3] arm: mvebu: helios-4: add config fragment for spi booting et al
This patch-set introduces a new config fragment for spi booting on kobol helios-4. Additionally add minor update for default defconfig to enable setexpr command, and fix u-boot command access to i2c0 bus. Signed-off-by: Josua Mayer --- Changes in v2: - replaced new defconfig with config fragment in board directory (suggested by Tom Rini ) - Link to v1: https://lore.kernel.org/r/20240113-helios4-spi-v1-0-2a5663a10...@solid-run.com --- Josua Mayer (3): arm: dts: armada-38x-solidrun-microsom: configure i2c0 bus arm: mvebu: helios4_defconfig: enable setexpr command board: helios-4: add config fragment for spi booting arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 5 + board/kobol/helios4/spiboot.config | 4 configs/helios4_defconfig | 1 - 3 files changed, 9 insertions(+), 1 deletion(-) --- base-commit: 050a9b981d6a835133521b599be3ae189ce70f41 change-id: 20240113-helios4-spi-144085c0bbc7 Sincerely, -- Josua Mayer
[PATCH v2 0/3] mmc: hi6220-dwmmc: handle resets and clocks
Also allow setup fifoth_val in driver Signed-off-by: Yang Xiwen --- Changes in v2: - dw-mmc: proceed if data busy found - hi6220-dw-mmc: add fifoth_val setup, separate hi3798mv200 data - Link to v1: https://lore.kernel.org/r/20240119-mmc-v1-1-aee6b2cf6...@outlook.com --- Yang Xiwen (3): mmc: hi6220-dwmmc: handle clocks and resets if CONFIG_CLK and CONFIG_DM_RESET enabled mmc: dw_mmc: Don't return error if data busy timeout mmc: hi6220_dw_mmc: add fifoth_val to private data and set it in .probe drivers/mmc/dw_mmc.c| 4 +-- drivers/mmc/hi6220_dw_mmc.c | 72 +++-- 2 files changed, 72 insertions(+), 4 deletions(-) --- base-commit: f7cca7ccc5117eaafcc2bde91ad1bed6fee7cfc3 change-id: 20240119-mmc-9cf7f3455cb4 Best regards, -- Yang Xiwen
[PATCH v2 0/3] Random Number Generator fixes
This series aim to fix smccc bind issue and add a list command for RNG devices. Changelog: v1 --> v2 - check SMCCC_ARCH_FEATURES - update commit message and rng help info Weizhao Ouyang (3): firmware: psci: Fix bind_smccc_features psci check driver: rng: Fix SMCCC TRNG crash cmd: rng: Add rng list command cmd/rng.c | 23 ++- drivers/firmware/psci.c | 9 - drivers/rng/smccc_trng.c | 2 +- include/linux/arm-smccc.h | 6 ++ 4 files changed, 33 insertions(+), 7 deletions(-) -- 2.39.2
[PATCH v2 0/3] riscv: separate .data and .text sections of EFI binaries
EFI binaries should not contain sections that are both writable and
executable. Separate the RX .text section from the RW .data section
Fix conflicting SPDX license information in linker scripts introduced by
commit 7215787c4ea4 ("SPDX: Convert single license tags to Linux Kernel
style").
Change the alignment of the relocation code in EFI binaries to match page
boundaries.
v2:
split patches
Heinrich Schuchardt (3):
riscv: conflicting SPDX license linker scripts
riscv: page align EFI binary section
riscv: separate .data and .text sections of EFI binaries
arch/riscv/lib/crt0_riscv_efi.S| 39 ++
arch/riscv/lib/elf_riscv32_efi.lds | 26
arch/riscv/lib/elf_riscv64_efi.lds | 26
3 files changed, 61 insertions(+), 30 deletions(-)
--
2.43.0
[PATCH v2 0/3] fix and refactoring of efi_disk.c
This series fixes the memory leak issue in lib/efi_loader/efi_disk.c and refactor the efi_disk_remove() implementation. [Changelog] v1 -> v2 - remove already merged patch - remove container_of() calls - add TODO comments - return immediately in UCLASS_EFI_LOADER removal Masahisa Kojima (3): efi_loader: avoid pointer access after calling efi_delete_handle efi_loader: create common function to free struct efi_disk_obj efi_loader: return immediately in UCLASS_EFI_LOADER removal lib/efi_loader/efi_disk.c | 55 +-- 1 file changed, 41 insertions(+), 14 deletions(-) -- 2.34.1
[PATCH v2 0/3] riscv: sophgo: milkv_duo: add support for Milk-V Duo board
The Milk-V Duo board is built upon Sophgo's CV1800B SoC, featuring two XuanTie C906 CPUs running at 1.0GHz and 700MHz, respectively. This series introduces fundamental support for the Milk-V Duo board, encompassing UART, CPU, and PLIC support. This ensures that U-Boot can operate in serial console mode. Changes in v2: - Fold the defconfig patch to first patch - Remove unnecessary environment settings of consoledev and baudrate in config Kongyang Liu (3): riscv: sophgo: milkv_duo: initial support added riscv: dts: sophgo: Add basic device tree for Milk-V Duo board doc: sophgo: milkv_duo: document Milk-V Duo board arch/riscv/Kconfig | 4 + arch/riscv/dts/Makefile | 1 + arch/riscv/dts/cv1800b-milkv-duo.dts | 38 + arch/riscv/dts/cv1800b.dtsi | 123 +++ board/sophgo/milkv_duo/Kconfig | 28 ++ board/sophgo/milkv_duo/MAINTAINERS | 6 ++ board/sophgo/milkv_duo/Makefile | 5 ++ board/sophgo/milkv_duo/board.c | 9 ++ configs/milkv_duo_defconfig | 24 ++ doc/board/index.rst | 1 + doc/board/sophgo/index.rst | 8 ++ doc/board/sophgo/milkv_duo.rst | 50 +++ include/configs/milkv_duo.h | 12 +++ 13 files changed, 309 insertions(+) create mode 100644 arch/riscv/dts/cv1800b-milkv-duo.dts create mode 100644 arch/riscv/dts/cv1800b.dtsi create mode 100644 board/sophgo/milkv_duo/Kconfig create mode 100644 board/sophgo/milkv_duo/MAINTAINERS create mode 100644 board/sophgo/milkv_duo/Makefile create mode 100644 board/sophgo/milkv_duo/board.c create mode 100644 configs/milkv_duo_defconfig create mode 100644 doc/board/sophgo/index.rst create mode 100644 doc/board/sophgo/milkv_duo.rst create mode 100644 include/configs/milkv_duo.h -- 2.41.0
Re: [PATCH v2 0/3] This series adds support for the phyGATE-Tauri-L.
On Wed, Jan 10, 2024 at 10:35 AM Yannic Moog wrote:
>
> The config is minimal and mostly a copy from the phycore-imx8mm. SPI
> (flash) is disabled as it is not populated by default.
> Also add documentation for the phyGATE-Tauri-L board. While at it, add
> the other PHYTEC doc files to MAINTAINERS; they were missing for
> existing phycore-imx8m{m,p} doc.
Applied all, thanks.
[PATCH v2 0/3] This series adds support for the phyGATE-Tauri-L.
The config is minimal and mostly a copy from the phycore-imx8mm. SPI
(flash) is disabled as it is not populated by default.
Also add documentation for the phyGATE-Tauri-L board. While at it, add
the other PHYTEC doc files to MAINTAINERS; they were missing for
existing phycore-imx8m{m,p} doc.
---
Changes in v2:
- readd TIDP83867; is populated on the SoM by default
- remove remnants from SPI config options (savedefconfig)
- add doc/board/phytec files to MAINTAINERS
---
Yannic Moog (3):
Add support for phyGATE-Tauri-L-iMX8MM
doc: board: phytec: Add phyGATE-Tauri board documentation
board: phytec: MAINTAINERS: add missing phytec doc files
arch/arm/dts/Makefile | 1 +
arch/arm/dts/imx8mm-phygate-tauri-l-u-boot.dtsi | 70
arch/arm/dts/imx8mm-phygate-tauri-l.dts | 489
board/phytec/phycore_imx8mm/MAINTAINERS | 6 +
board/phytec/phycore_imx8mp/MAINTAINERS | 1 +
configs/imx8mm-phygate-tauri-l_defconfig| 115 ++
doc/board/phytec/imx8mm-phygate-tauri-l.rst | 60 +++
doc/board/phytec/index.rst | 1 +
8 files changed, 743 insertions(+)
---
base-commit: c5e461fbf7cc72f0c1c8a79226b6a5170e56cb4d
change-id: 20231220-wip-y-moog-phytec-de-tauri-l_upstream-08c9648ac653
Best regards,
--
Yannic Moog
Re: [PATCH v2 0/3] rpi5: initial support
Hi Dmitry,
> First of all, thank you for all your reviews. I hope I can answer all
> your questions here. If I forget something please let me know.
Absolutely.
> I don't have much experience with arm/arm64 and I don't have previous
> experience with u-boot and contributing to it. So please guide me for
> next steps.
I think you're doing fine, generally the process is wait for some
review, incorporate the feedback into patches and after a little while
send a new rev.
> Also I don't think it makes sense to expect all devices or any device
> may/should work after initial boot support. I would suggest going with
> small steps and talking about gfx/usb/net/mmc in dedicated patchsets
> after initial support is being merged.
I agree with that point mostly, and that is my intention, from my PoV
it was more me replying to the comments you had made about outsanding
issues and what my thoughts were to address them.
That being said I think we need two things to be able to land this
upstream 1) working output such as serial console (this is ticket) 2)
working storage so it can load things like the Linux kernel off disk
and boot, the shortest path to this is likely MMC. Everything else
(gfx/net/usb etc) can be added later in incremental patches. I
apologies if my reply didn't come across at that, it was as much
documented my discoveries for everyone else on the list following
along.
> > Could this be the title for the patch, "initial support" is fine for
> > the cover letter, but doesn't really out line what this specific patch
> > actually does.
> Can confirm. My bad. Will fix it in the next patchset.
>
> >> includes:
> >> * 1GB of RAM (from 4GB or 8GB total)
> >> * VPU memory interface
> >> * SOC range (main peripherals)
>
> > Could you include details where this information came from as well please?
> By looking into FDT for memory, framebuffer, and soc nodes. I can add
> this info in v3.
>
>
> > When you say it doesn't work, does it just not output display or does
> > the device lock up and you need to disable it?
> There are artifacts on the screen and the system locks up.
OK, good to know, we can't really disable display ATM as it'll regress
other rpi devices supported in this config.
>
> > For the rpi4 it was as simple as adding a new compatible [1] for the
> > rev6 of the IP block as for the bits that we use in U-Boot nothing
> > changed, but the kernel changes for the rev7 that's in the RPi5 needed
> > updating registers [2] so I'm not sure if we're going to need to do
> > more for this or not.
> I've tried it by playing with "simple-fb" and with "bcm2712-hdmi0".
> And no luck. Still visible artifacts on the screen. I see valid debug
> output from bcm2835_video_probe() so the mailbox for set/get
> base/resolution/pitch/stride works. But still observe the same issue
> with artifacts and lock up. FYI by default the probing starts due to
> "bcm2708-fb".
>
>
> > Might be worth looking to see if there's changes in the kernel for
> > this. In an initial look I didn't see any changes to their kernel
> > here.
> I don't see any changes either. I'm not able to find any official
> confirmation. But most of 'tags' work except two or three. And all of
> them have response code 0x8000_0001. And FDT contains new info
> compared to old versions (for these tags). Which leads to the
> conclusion they are deprecated.
>
>
> > We probably need a patch to the identifier too similar to the following:
> > https://source.denx.de/u-boot/u-boot/-/commit/5e7e6619c85c090f6b62685a9d90f748f1729d12
> Honestly I didn't get the reason/goal besides old/new scheme except
> there is a final print:
> > printf("RPI %s (0x%x)\n", model->name, revision);
> which is kind of simular to my:
> > printf("FW FDT model : %s\n", fdt_model);
The main reason for the detection is if there needs to be a kernel DT
loaded off disk, it's a more definitive way of detecting the HW rev
because the fdt model could be repeated across different revs of the
same variant.
> Besides parsing the "Raspberry Pi 5 Model B Rev 1.0" string to get
> revision from it? Format is unknown and nobody knows what will be
> changed. Will it be "Raspberry Pi 5 Model B Rev 1.0a" or Raspberry Pi
> 5 Model B Rev 1.01"? I don't know. If it's really needed then I would
> suggest parsing OTP to get precise info with known format.
Hence the reason to use the official hex identifiers.
> P.S.: Please let me know if I answered all the questions so I can send v3.
I think so. The outstanding things we will need to resolve to land
this, other than the polish I've outlined in various replies, is:
1) working storage to load an OS
2) not disabling the display driver and not have it crash. The display
on the rpi5 doesn't need to work, we just don't want to regress
existing users.
This won't be landing in 2024.01 now so we have time to get this
ready. I'll start to play in the coming days.
Peter
Re: [PATCH v2 0/3] rpi5: initial support
Hi Dmitry,
> > I've given these a cursory look over, I have a system to test and will
> > give them a whirl in the next few days, I was planning to start
> > playing over the weekend so you've provided a great start :)
>
> Did you have any chance to test my patches?
Not yet, apologies, work has been a bit intense over the last couple
of weeks so I've not had many cycles in the free time I use for RPi
outside of work to do this. I do have the RPi5 up and running now
though so I can start to test.
I was going to reply to your last reply, I will do that in a moment.
Peter
> > Hi guys,
> >
> > First of all, thank you for all your reviews. I hope I can answer all
> > your questions here. If I forget something please let me know.
> >
> > I don't have much experience with arm/arm64 and I don't have previous
> > experience with u-boot and contributing to it. So please guide me for
> > next steps.
> >
> > Also I don't think it makes sense to expect all devices or any device
> > may/should work after initial boot support. I would suggest going with
> > small steps and talking about gfx/usb/net/mmc in dedicated patchsets
> > after initial support is being merged.
> >
> > > Could this be the title for the patch, "initial support" is fine for
> > > the cover letter, but doesn't really out line what this specific patch
> > > actually does.
> > Can confirm. My bad. Will fix it in the next patchset.
> >
> > >> includes:
> > >> * 1GB of RAM (from 4GB or 8GB total)
> > >> * VPU memory interface
> > >> * SOC range (main peripherals)
> >
> > > Could you include details where this information came from as well please?
> > By looking into FDT for memory, framebuffer, and soc nodes. I can add
> > this info in v3.
> >
> >
> > > When you say it doesn't work, does it just not output display or does
> > > the device lock up and you need to disable it?
> > There are artifacts on the screen and the system locks up.
> >
> >
> > > For the rpi4 it was as simple as adding a new compatible [1] for the
> > > rev6 of the IP block as for the bits that we use in U-Boot nothing
> > > changed, but the kernel changes for the rev7 that's in the RPi5 needed
> > > updating registers [2] so I'm not sure if we're going to need to do
> > > more for this or not.
> > I've tried it by playing with "simple-fb" and with "bcm2712-hdmi0".
> > And no luck. Still visible artifacts on the screen. I see valid debug
> > output from bcm2835_video_probe() so the mailbox for set/get
> > base/resolution/pitch/stride works. But still observe the same issue
> > with artifacts and lock up. FYI by default the probing starts due to
> > "bcm2708-fb".
> >
> >
> > > Might be worth looking to see if there's changes in the kernel for
> > > this. In an initial look I didn't see any changes to their kernel
> > > here.
> > I don't see any changes either. I'm not able to find any official
> > confirmation. But most of 'tags' work except two or three. And all of
> > them have response code 0x8000_0001. And FDT contains new info
> > compared to old versions (for these tags). Which leads to the
> > conclusion they are deprecated.
> >
> >
> > > We probably need a patch to the identifier too similar to the following:
> > > https://source.denx.de/u-boot/u-boot/-/commit/5e7e6619c85c090f6b62685a9d90f748f1729d12
> > Honestly I didn't get the reason/goal besides old/new scheme except
> > there is a final print:
> > > printf("RPI %s (0x%x)\n", model->name, revision);
> > which is kind of simular to my:
> > > printf("FW FDT model : %s\n", fdt_model);
> >
> > Besides parsing the "Raspberry Pi 5 Model B Rev 1.0" string to get
> > revision from it? Format is unknown and nobody knows what will be
> > changed. Will it be "Raspberry Pi 5 Model B Rev 1.0a" or Raspberry Pi
> > 5 Model B Rev 1.01"? I don't know. If it's really needed then I would
> > suggest parsing OTP to get precise info with known format.
> >
> > P.S.: Please let me know if I answered all the questions so I can send v3.
> >
> > Regards,
> > Dmitry
>
> I haven't heard any updates. Should I send v3?
Re: [PATCH v2 0/3] sunxi: add OrangePi Zero 3 board support
On Sun, 3 Dec 2023 21:57:51 -0800 Stephen Graf wrote: Hi Stephen, > I have tested a newly built u-boot with the patches you provided and it works > well. > It is the same configuration as what I have been testing with for the last > few weeks. > > I loaded the U-boot to SPI flash and tested with the SD card removed from the > system > and put in a USB card reader. The output for that test is below. thanks for your testing efforts! Is it OK if I convert this statement into a "Tested-by:" tag with your email, to become part of the commit? Cheers, Andre > For completeness you might want to mention that another difference between > the zero2 > and zero3 is the emac phy going from Realtek to Motorcomm. > > Thank you for fixing my patch attempt. It is the first one I have ever done. > Thank you also for your patience with my fumbling attempts. I have learned a > lot > from you in the last two weeks. > > U-Boot SPL 2024.01-rc3-00043-g5c4e9d0c74-dirty (Dec 03 2023 - 18:21:41 -0800) > DRAM: 1024 MiB > Trying to boot from sunxi SPI > NOTICE: BL31: v2.10.0 (debug):v2.10.0 > NOTICE: BL31: Built : 18:07:18, Nov 23 2023 > NOTICE: BL31: Detected Allwinner H616 SoC (1823) > NOTICE: BL31: Found U-Boot DTB at 0x4a0b2828, model: OrangePi Zero3 > INFO:ARM GICv2 driver initialized > INFO:Configuring SPC Controller > INFO:PMIC: Probing AXP305 on RSB > ERROR: RSB: set run-time address: 0x10003 > INFO:Could not init RSB: -65539 > INFO:BL31: Platform setup done > INFO:BL31: Initializing runtime services > INFO:BL31: cortex_a53: CPU workaround for erratum 855873 was applied > INFO:BL31: cortex_a53: CPU workaround for erratum 1530924 was applied > INFO:PSCI: Suspend is unavailable > INFO:BL31: Preparing for EL3 exit to normal world > INFO:Entry point address = 0x4a00 > INFO:SPSR = 0x3c9 > INFO:Changed devicetree. > > > U-Boot 2024.01-rc3-00043-g5c4e9d0c74-dirty (Dec 03 2023 - 18:21:41 -0800) > Allwinner Technology > > CPU: Allwinner H616 (SUN50I) > Model: OrangePi Zero3 > DRAM: 1 GiB > Core: 57 devices, 25 uclasses, devicetree: separate > WDT: Not starting watchdog@30090a0 > MMC: mmc@402: 0 > Loading Environment from SPIFlash... SF: Detected zb25vq128 with page size > 256 Bytes, erase size 4 KiB, total 16 MiB > OK > In:serial@500 > Out: serial@500 > Err: serial@500 > Allwinner mUSB OTG (Peripheral) > Net: eth0: ethernet@502using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in > MAC de:ad:be:ef:00:01 > HOST MAC de:ad:be:ef:00:00 > RNDIS ready > , eth1: usb_ether > starting USB... > Bus usb@520: USB EHCI 1.00 > Bus usb@5200400: USB OHCI 1.0 > scanning bus usb@520 for devices... Device NOT ready > Request Sense returned 02 3A 00 > Device NOT ready > Request Sense returned 02 3A 00 > Device NOT ready > Request Sense returned 02 3A 00 > 2 USB Device(s) found > scanning bus usb@5200400 for devices... 1 USB Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > Hit any key to stop autoboot: 0 > Card did not respond to voltage select! : -110 > > Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC > Type: Removable Hard Disk > Capacity: 15193.5 MB = 14.8 GB (31116288 x 512) > ... is now current device > Scanning usb 0:1... > Found U-Boot script /boot/boot.scr > 1052 bytes read in 1 ms (1 MiB/s) > ## Executing script at 4fc0 > Card did not respond to voltage select! : -110 > ** Bad device specification mmc 0 ** > 19472 bytes read in 3 ms (6.2 MiB/s) > No FDT memory address configured. Please configure > the FDT address via "fdt addr " command. > Aborting! > 7088139 bytes read in 324 ms (20.9 MiB/s) > 22491144 bytes read in 1025 ms (20.9 MiB/s) > Moving Image from 0x4008 to 0x4020, end=4180 > ## Loading init Ramdisk from Legacy Image at 4ff0 ... > Image Name: uInitrd > Image Type: AArch64 Linux RAMDisk Image (gzip compressed) > Data Size:7088075 Bytes = 6.8 MiB > Load Address: > Entry Point: > Verifying Checksum ... OK > ## Flattened Device Tree blob at 4fa0 > Booting using the fdt blob at 0x4fa0 > Working FDT set to 4fa0 > Loading Ramdisk to 4993d000, end 49fff7cb ... OK > Loading Device Tree to 49935000, end 4993cc0f ... OK > Working FDT set to 49935000 > > Starting kernel ... > > > Welcome to Debian GNU/Linux 12 (bookworm)! > > > > On 2023-12-03 4:59 p.m., Andre Przywara wrote: > > A small update for the OrangePi Zero 3 support series. This fixes > > USB support, and upgrades the DRAM clock to 792, for better stability > > (as the other DRAM parameters were tailored to that frequency). I added > > the tags on the way. > > Please test! > > > > = > > The OrangePi Zero 3 is a small development board featuring the Allwinner > > H618 SoC. Compared to its predecessor OrangePi Zero 2, the new board uses > > LPDDR4 DRAM in
[PATCH v2 0/3] binman: Add support for TI_DM entry
This series adds support for the TI_DM entry and moves all K3 platforms to using the same. With this feature introduced, if TI_DM argument is provided binman picks the pathname it provides; else, it defaults to picking up the ti-dm.bin file. This makes it flexible for users to build tispl.bin with custom DM binaries. Boot logs: https://gist.github.com/nehamalcom/37ce8a32e37ddf3e1afcc4c8bd941159 --- Changes from v1: https://lore.kernel.org/all/20231204112141.2036907-1-n-fran...@ti.com/ - s/ti-linux-firmware/BINMAN_INDIRS in documentation (Andrew) - No change to boot logs since only doc change Neha Malcom Francis (3): binman: etype: dm: Add entry type for TI DM arm: dts: k3-*-binman: Move to using ti-dm entry type doc: board: ti: k3: Mention TI_DM argument Makefile | 1 + arch/arm/dts/k3-am625-sk-binman.dtsi | 4 ++-- .../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 4 ++-- arch/arm/dts/k3-am62a-sk-binman.dtsi | 4 ++-- arch/arm/dts/k3-j7200-binman.dtsi | 4 ++-- arch/arm/dts/k3-j721e-binman.dtsi | 4 ++-- arch/arm/dts/k3-j721s2-binman.dtsi| 4 ++-- doc/board/ti/k3.rst | 7 ++ tools/binman/entries.rst | 14 tools/binman/etype/ti_dm.py | 22 +++ tools/binman/ftest.py | 7 ++ tools/binman/test/225_ti_dm.dts | 13 +++ 12 files changed, 76 insertions(+), 12 deletions(-) create mode 100644 tools/binman/etype/ti_dm.py create mode 100644 tools/binman/test/225_ti_dm.dts -- 2.34.1
Re: [PATCH v2 0/3] sunxi: add OrangePi Zero 3 board support
I have tested a newly built u-boot with the patches you provided and it works well. It is the same configuration as what I have been testing with for the last few weeks. I loaded the U-boot to SPI flash and tested with the SD card removed from the system and put in a USB card reader. The output for that test is below. For completeness you might want to mention that another difference between the zero2 and zero3 is the emac phy going from Realtek to Motorcomm. Thank you for fixing my patch attempt. It is the first one I have ever done. Thank you also for your patience with my fumbling attempts. I have learned a lot from you in the last two weeks. U-Boot SPL 2024.01-rc3-00043-g5c4e9d0c74-dirty (Dec 03 2023 - 18:21:41 -0800) DRAM: 1024 MiB Trying to boot from sunxi SPI NOTICE: BL31: v2.10.0 (debug):v2.10.0 NOTICE: BL31: Built : 18:07:18, Nov 23 2023 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0b2828, model: OrangePi Zero3 INFO:ARM GICv2 driver initialized INFO:Configuring SPC Controller INFO:PMIC: Probing AXP305 on RSB ERROR: RSB: set run-time address: 0x10003 INFO:Could not init RSB: -65539 INFO:BL31: Platform setup done INFO:BL31: Initializing runtime services INFO:BL31: cortex_a53: CPU workaround for erratum 855873 was applied INFO:BL31: cortex_a53: CPU workaround for erratum 1530924 was applied INFO:PSCI: Suspend is unavailable INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x4a00 INFO:SPSR = 0x3c9 INFO:Changed devicetree. U-Boot 2024.01-rc3-00043-g5c4e9d0c74-dirty (Dec 03 2023 - 18:21:41 -0800) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 1 GiB Core: 57 devices, 25 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@402: 0 Loading Environment from SPIFlash... SF: Detected zb25vq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK In:serial@500 Out: serial@500 Err: serial@500 Allwinner mUSB OTG (Peripheral) Net: eth0: ethernet@502using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready , eth1: usb_ether starting USB... Bus usb@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 for devices... Device NOT ready Request Sense returned 02 3A 00 Device NOT ready Request Sense returned 02 3A 00 Device NOT ready Request Sense returned 02 3A 00 2 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 Card did not respond to voltage select! : -110 Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC Type: Removable Hard Disk Capacity: 15193.5 MB = 14.8 GB (31116288 x 512) ... is now current device Scanning usb 0:1... Found U-Boot script /boot/boot.scr 1052 bytes read in 1 ms (1 MiB/s) ## Executing script at 4fc0 Card did not respond to voltage select! : -110 ** Bad device specification mmc 0 ** 19472 bytes read in 3 ms (6.2 MiB/s) No FDT memory address configured. Please configure the FDT address via "fdt addr " command. Aborting! 7088139 bytes read in 324 ms (20.9 MiB/s) 22491144 bytes read in 1025 ms (20.9 MiB/s) Moving Image from 0x4008 to 0x4020, end=4180 ## Loading init Ramdisk from Legacy Image at 4ff0 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size:7088075 Bytes = 6.8 MiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa0 Booting using the fdt blob at 0x4fa0 Working FDT set to 4fa0 Loading Ramdisk to 4993d000, end 49fff7cb ... OK Loading Device Tree to 49935000, end 4993cc0f ... OK Working FDT set to 49935000 Starting kernel ... Welcome to Debian GNU/Linux 12 (bookworm)! On 2023-12-03 4:59 p.m., Andre Przywara wrote: A small update for the OrangePi Zero 3 support series. This fixes USB support, and upgrades the DRAM clock to 792, for better stability (as the other DRAM parameters were tailored to that frequency). I added the tags on the way. Please test! = The OrangePi Zero 3 is a small development board featuring the Allwinner H618 SoC. Compared to its predecessor OrangePi Zero 2, the new board uses LPDDR4 DRAM instead of DDR3 DRAM, and an X-Powers AXP313 PMIC instead of the AXP305. U-Boot gained support for both LPDDR4 DRAM and the new PMIC just recently, so add a user for those features by adding a defconfig for the new board. To make this work, patch 1/3 introduces support for zBIT SPI NOR flash chip, and patch 2/3 removes the default AXP305 PMIC selection when compiling for H616 SoCs. Patch 3/3 then adds the defconfig. The DT was already synced from the Linux kernel repo a few weeks ago. Cheers, Andre Changel
[PATCH v2 0/3] sunxi: add OrangePi Zero 3 board support
A small update for the OrangePi Zero 3 support series. This fixes USB support, and upgrades the DRAM clock to 792, for better stability (as the other DRAM parameters were tailored to that frequency). I added the tags on the way. Please test! = The OrangePi Zero 3 is a small development board featuring the Allwinner H618 SoC. Compared to its predecessor OrangePi Zero 2, the new board uses LPDDR4 DRAM instead of DDR3 DRAM, and an X-Powers AXP313 PMIC instead of the AXP305. U-Boot gained support for both LPDDR4 DRAM and the new PMIC just recently, so add a user for those features by adding a defconfig for the new board. To make this work, patch 1/3 introduces support for zBIT SPI NOR flash chip, and patch 2/3 removes the default AXP305 PMIC selection when compiling for H616 SoCs. Patch 3/3 then adds the defconfig. The DT was already synced from the Linux kernel repo a few weeks ago. Cheers, Andre Changelog v1 .. v2: - add tags - set DRAM clock to 792 MHz (from the default 720 MHz) - fix USB support by supplying USB VBUS enable GPIO Andre Przywara (3): mtd: spi-nor: Add support for zBIT ZB25VQ128 sunxi: H616: remove default AXP305 selection sunxi: H616: Add OrangePi Zero 3 board support arch/arm/dts/Makefile| 1 + board/sunxi/MAINTAINERS | 5 + configs/orangepi_zero2_defconfig | 1 + configs/orangepi_zero3_defconfig | 32 configs/x96_mate_defconfig | 1 + drivers/mtd/spi/Kconfig | 5 + drivers/mtd/spi/spi-nor-ids.c| 5 + drivers/power/Kconfig| 1 - 8 files changed, 50 insertions(+), 1 deletion(-) create mode 100644 configs/orangepi_zero3_defconfig -- 2.35.8
Re: [PATCH v2 0/3] rpi5: initial support
Hi Dmitry,
On Fri, 1 Dec 2023 at 20:04, Dmitry Malkin wrote:
>
> Hi Peter,
>
> > I've given these a cursory look over, I have a system to test and will
> > give them a whirl in the next few days, I was planning to start
> > playing over the weekend so you've provided a great start :)
>
> Did you have any chance to test my patches?
>
>
>
> >
> > Hi guys,
> >
> > First of all, thank you for all your reviews. I hope I can answer all
> > your questions here. If I forget something please let me know.
> >
> > I don't have much experience with arm/arm64 and I don't have previous
> > experience with u-boot and contributing to it. So please guide me for
> > next steps.
> >
> > Also I don't think it makes sense to expect all devices or any device
> > may/should work after initial boot support. I would suggest going with
> > small steps and talking about gfx/usb/net/mmc in dedicated patchsets
> > after initial support is being merged.
> >
> > > Could this be the title for the patch, "initial support" is fine for
> > > the cover letter, but doesn't really out line what this specific patch
> > > actually does.
> > Can confirm. My bad. Will fix it in the next patchset.
> >
> > >> includes:
> > >> * 1GB of RAM (from 4GB or 8GB total)
> > >> * VPU memory interface
> > >> * SOC range (main peripherals)
> >
> > > Could you include details where this information came from as well please?
> > By looking into FDT for memory, framebuffer, and soc nodes. I can add
> > this info in v3.
> >
> >
> > > When you say it doesn't work, does it just not output display or does
> > > the device lock up and you need to disable it?
> > There are artifacts on the screen and the system locks up.
> >
> >
> > > For the rpi4 it was as simple as adding a new compatible [1] for the
> > > rev6 of the IP block as for the bits that we use in U-Boot nothing
> > > changed, but the kernel changes for the rev7 that's in the RPi5 needed
> > > updating registers [2] so I'm not sure if we're going to need to do
> > > more for this or not.
> > I've tried it by playing with "simple-fb" and with "bcm2712-hdmi0".
> > And no luck. Still visible artifacts on the screen. I see valid debug
> > output from bcm2835_video_probe() so the mailbox for set/get
> > base/resolution/pitch/stride works. But still observe the same issue
> > with artifacts and lock up. FYI by default the probing starts due to
> > "bcm2708-fb".
> >
> >
> > > Might be worth looking to see if there's changes in the kernel for
> > > this. In an initial look I didn't see any changes to their kernel
> > > here.
> > I don't see any changes either. I'm not able to find any official
> > confirmation. But most of 'tags' work except two or three. And all of
> > them have response code 0x8000_0001. And FDT contains new info
> > compared to old versions (for these tags). Which leads to the
> > conclusion they are deprecated.
> >
> >
> > > We probably need a patch to the identifier too similar to the following:
> > > https://source.denx.de/u-boot/u-boot/-/commit/5e7e6619c85c090f6b62685a9d90f748f1729d12
> > Honestly I didn't get the reason/goal besides old/new scheme except
> > there is a final print:
> > > printf("RPI %s (0x%x)\n", model->name, revision);
> > which is kind of simular to my:
> > > printf("FW FDT model : %s\n", fdt_model);
> >
> > Besides parsing the "Raspberry Pi 5 Model B Rev 1.0" string to get
> > revision from it? Format is unknown and nobody knows what will be
> > changed. Will it be "Raspberry Pi 5 Model B Rev 1.0a" or Raspberry Pi
> > 5 Model B Rev 1.01"? I don't know. If it's really needed then I would
> > suggest parsing OTP to get precise info with known format.
> >
> > P.S.: Please let me know if I answered all the questions so I can send v3.
> >
> > Regards,
> > Dmitry
>
> I haven't heard any updates. Should I send v3?
You may as well.
Do the Raspberry Pi Foundation or Broadcom help with this effort? I
wonder if it might be possible to coax them towards open source
firmware?
Regards,
Simon
Re: [PATCH v2 0/3] rpi5: initial support
Hi Peter,
> I've given these a cursory look over, I have a system to test and will
> give them a whirl in the next few days, I was planning to start
> playing over the weekend so you've provided a great start :)
Did you have any chance to test my patches?
>
> Hi guys,
>
> First of all, thank you for all your reviews. I hope I can answer all
> your questions here. If I forget something please let me know.
>
> I don't have much experience with arm/arm64 and I don't have previous
> experience with u-boot and contributing to it. So please guide me for
> next steps.
>
> Also I don't think it makes sense to expect all devices or any device
> may/should work after initial boot support. I would suggest going with
> small steps and talking about gfx/usb/net/mmc in dedicated patchsets
> after initial support is being merged.
>
> > Could this be the title for the patch, "initial support" is fine for
> > the cover letter, but doesn't really out line what this specific patch
> > actually does.
> Can confirm. My bad. Will fix it in the next patchset.
>
> >> includes:
> >> * 1GB of RAM (from 4GB or 8GB total)
> >> * VPU memory interface
> >> * SOC range (main peripherals)
>
> > Could you include details where this information came from as well please?
> By looking into FDT for memory, framebuffer, and soc nodes. I can add
> this info in v3.
>
>
> > When you say it doesn't work, does it just not output display or does
> > the device lock up and you need to disable it?
> There are artifacts on the screen and the system locks up.
>
>
> > For the rpi4 it was as simple as adding a new compatible [1] for the
> > rev6 of the IP block as for the bits that we use in U-Boot nothing
> > changed, but the kernel changes for the rev7 that's in the RPi5 needed
> > updating registers [2] so I'm not sure if we're going to need to do
> > more for this or not.
> I've tried it by playing with "simple-fb" and with "bcm2712-hdmi0".
> And no luck. Still visible artifacts on the screen. I see valid debug
> output from bcm2835_video_probe() so the mailbox for set/get
> base/resolution/pitch/stride works. But still observe the same issue
> with artifacts and lock up. FYI by default the probing starts due to
> "bcm2708-fb".
>
>
> > Might be worth looking to see if there's changes in the kernel for
> > this. In an initial look I didn't see any changes to their kernel
> > here.
> I don't see any changes either. I'm not able to find any official
> confirmation. But most of 'tags' work except two or three. And all of
> them have response code 0x8000_0001. And FDT contains new info
> compared to old versions (for these tags). Which leads to the
> conclusion they are deprecated.
>
>
> > We probably need a patch to the identifier too similar to the following:
> > https://source.denx.de/u-boot/u-boot/-/commit/5e7e6619c85c090f6b62685a9d90f748f1729d12
> Honestly I didn't get the reason/goal besides old/new scheme except
> there is a final print:
> > printf("RPI %s (0x%x)\n", model->name, revision);
> which is kind of simular to my:
> > printf("FW FDT model : %s\n", fdt_model);
>
> Besides parsing the "Raspberry Pi 5 Model B Rev 1.0" string to get
> revision from it? Format is unknown and nobody knows what will be
> changed. Will it be "Raspberry Pi 5 Model B Rev 1.0a" or Raspberry Pi
> 5 Model B Rev 1.01"? I don't know. If it's really needed then I would
> suggest parsing OTP to get precise info with known format.
>
> P.S.: Please let me know if I answered all the questions so I can send v3.
>
> Regards,
> Dmitry
I haven't heard any updates. Should I send v3?
Re: [PATCH v2 0/3] Xilinx SPI driver enhancements
On 11/16/23 17:43, Mayuresh Chitale wrote: This series makes the Xilinx XPS SPI driver compatible with the MMC_SPI driver and also includes an enhacement from the corresponding Linux driver. Changes in v2: - Improve comment and add reviewed-by tag in patch 3 Mayuresh Chitale (3): drivers: xilinx_spi: Use udevice in start_tranfer drivers: xilinx_spi: Add xfer callback drivers: xilinx_spi: Probe fifo_depth at runtime drivers/spi/xilinx_spi.c | 68 ++-- 1 file changed, 52 insertions(+), 16 deletions(-) Applied. M
RE: [PATCH v2 0/3] Xilinx SPI driver enhancements
> -Original Message- > From: Simek, Michal > Sent: 29 November 2023 13:55 > To: Mayuresh Chitale ; Jagan Teki > ; Kumar, Love > Cc: u-boot@lists.denx.de; Simon Glass ; Tom Rini > > Subject: Re: [PATCH v2 0/3] Xilinx SPI driver enhancements > > +Love > > On 11/16/23 17:43, Mayuresh Chitale wrote: > > This series makes the Xilinx XPS SPI driver compatible with the MMC_SPI > > driver and also includes an enhacement from the corresponding Linux > driver. > > > > Changes in v2: > > - Improve comment and add reviewed-by tag in patch 3 > > > > Mayuresh Chitale (3): > >drivers: xilinx_spi: Use udevice in start_tranfer > >drivers: xilinx_spi: Add xfer callback > >drivers: xilinx_spi: Probe fifo_depth at runtime > > > > drivers/spi/xilinx_spi.c | 68 ++- > - > > 1 file changed, 52 insertions(+), 16 deletions(-) > > Tested-by: Love Kumar
Re: [PATCH v2 0/3] Xilinx SPI driver enhancements
+Love On 11/16/23 17:43, Mayuresh Chitale wrote: This series makes the Xilinx XPS SPI driver compatible with the MMC_SPI driver and also includes an enhacement from the corresponding Linux driver. Changes in v2: - Improve comment and add reviewed-by tag in patch 3 Mayuresh Chitale (3): drivers: xilinx_spi: Use udevice in start_tranfer drivers: xilinx_spi: Add xfer callback drivers: xilinx_spi: Probe fifo_depth at runtime drivers/spi/xilinx_spi.c | 68 ++-- 1 file changed, 52 insertions(+), 16 deletions(-)
[PATCH v2 0/3] J721S2 Add remoteproc early boot support
The series adds the support to boot early remote cores from u-boot and changes the rproc_fw_binaries to be compatible with Linux DT Syncs. Logs: https://gist.github.com/manorit2001/2f2ef0699619e0b496367b400ff02d3c Cc: Apurva Nandan Cc: Udit Kumar Cc: Vignesh Raghavendra Cc: Neha Malcom Francis Cc: Nishanth Menon Cc: Andrew Davis Cc: To: Tom Rini Signed-off-by: Manorit Chawdhry Changes in v2: - Update the signoff --- Hari Nagalla (2): remoteproc: k3-r5: Extend support for R5F clusters on J721S2 SoCs remoteproc: k3-dsp: Extend support for C71x DSPs on J721S2 SoCs Manorit Chawdhry (1): env: ti: j721s2.env: Remove the processors that are in lockstep board/ti/j721s2/j721s2.env | 2 +- drivers/remoteproc/ti_k3_dsp_rproc.c | 4 +++- drivers/remoteproc/ti_k3_r5f_rproc.c | 6 -- 3 files changed, 8 insertions(+), 4 deletions(-) --- base-commit: 054222eb68f6d7500e21dd1f01af8b9a59b89fd4 change-id: 20231127-b4-upstream-j721e-rproc-support-15074716a401 Best regards, -- Manorit Chawdhry
[PATCH v2 0/3] efi: vars: Implement SPI Flash storage
With this patch series we implement SPI Flash storage for EFI variables. Changes in v2: - Refactored efi_var_file to move common parts out as requested - Changed ifdefs to use CONFIG_IS_DEFINED - Fixed typos Shantur Rathore (3): efi_var_file: refactor to move buffer functions efi_vars: Implement SPI Flash store defconfig: rockpro64: Enable SF EFI var store configs/rockpro64-rk3399_defconfig | 2 + include/efi_variable.h | 26 +++ lib/efi_loader/Kconfig | 25 ++ lib/efi_loader/Makefile| 3 +- lib/efi_loader/efi_var_common.c| 109 ++ lib/efi_loader/efi_var_file.c | 121 - lib/efi_loader/efi_var_sf.c| 91 ++ lib/efi_loader/efi_variable.c | 17 +++- 8 files changed, 270 insertions(+), 124 deletions(-) create mode 100644 lib/efi_loader/efi_var_sf.c -- 2.40.1
Re: [PATCH v2 0/3] rpi5: initial support
Hi guys,
First of all, thank you for all your reviews. I hope I can answer all
your questions here. If I forget something please let me know.
I don't have much experience with arm/arm64 and I don't have previous
experience with u-boot and contributing to it. So please guide me for
next steps.
Also I don't think it makes sense to expect all devices or any device
may/should work after initial boot support. I would suggest going with
small steps and talking about gfx/usb/net/mmc in dedicated patchsets
after initial support is being merged.
> Could this be the title for the patch, "initial support" is fine for
> the cover letter, but doesn't really out line what this specific patch
> actually does.
Can confirm. My bad. Will fix it in the next patchset.
>> includes:
>> * 1GB of RAM (from 4GB or 8GB total)
>> * VPU memory interface
>> * SOC range (main peripherals)
> Could you include details where this information came from as well please?
By looking into FDT for memory, framebuffer, and soc nodes. I can add
this info in v3.
> When you say it doesn't work, does it just not output display or does
> the device lock up and you need to disable it?
There are artifacts on the screen and the system locks up.
> For the rpi4 it was as simple as adding a new compatible [1] for the
> rev6 of the IP block as for the bits that we use in U-Boot nothing
> changed, but the kernel changes for the rev7 that's in the RPi5 needed
> updating registers [2] so I'm not sure if we're going to need to do
> more for this or not.
I've tried it by playing with "simple-fb" and with "bcm2712-hdmi0".
And no luck. Still visible artifacts on the screen. I see valid debug
output from bcm2835_video_probe() so the mailbox for set/get
base/resolution/pitch/stride works. But still observe the same issue
with artifacts and lock up. FYI by default the probing starts due to
"bcm2708-fb".
> Might be worth looking to see if there's changes in the kernel for
> this. In an initial look I didn't see any changes to their kernel
> here.
I don't see any changes either. I'm not able to find any official
confirmation. But most of 'tags' work except two or three. And all of
them have response code 0x8000_0001. And FDT contains new info
compared to old versions (for these tags). Which leads to the
conclusion they are deprecated.
> We probably need a patch to the identifier too similar to the following:
> https://source.denx.de/u-boot/u-boot/-/commit/5e7e6619c85c090f6b62685a9d90f748f1729d12
Honestly I didn't get the reason/goal besides old/new scheme except
there is a final print:
> printf("RPI %s (0x%x)\n", model->name, revision);
which is kind of simular to my:
> printf("FW FDT model : %s\n", fdt_model);
Besides parsing the "Raspberry Pi 5 Model B Rev 1.0" string to get
revision from it? Format is unknown and nobody knows what will be
changed. Will it be "Raspberry Pi 5 Model B Rev 1.0a" or Raspberry Pi
5 Model B Rev 1.01"? I don't know. If it's really needed then I would
suggest parsing OTP to get precise info with known format.
P.S.: Please let me know if I answered all the questions so I can send v3.
Regards,
Dmitry
Re: [PATCH v2 0/3] rpi5: initial support
Hi Dmitry, > These patches bring initial boot support for RPI5. Without it the I've given these a cursory look over, I have a system to test and will give them a whirl in the next few days, I was planning to start playing over the weekend so you've provided a great start :) > latest master fails with the message: > > DRAM: mbox: Timeout waiting for response > > bcm2835: Could not query ARM memory size > > With those patches and rpi_arm64_defconfig (with disabled > CONFIG_VIDEO_BCM2835) I'm able to get a working u-boot prompt (over > serial). FDT comes from firmware (EEPROM). > > > U-Boot 2024.01-rc3-3 > > > > DRAM: 1016 MiB (effective 8 GiB) > > mbox: Header response code invalid > > bcm2835: Could not query board revision > > FDT model : Raspberry Pi 5 Model B Rev 1.0 > > Core: 14 devices, 7 uclasses, devicetree: board > > MMC: > > Loading Environment from FAT... ** Bad device specification mmc 0 ** > > In:serial,usbkbd > > Out: serial,vidconsole > > Err: serial,vidconsole > > Net: No ethernet found. > > starting USB... > > No working controllers found > > Hit any key to stop autoboot: 0 > > No working controllers found > > No ethernet found. > > No ethernet found. > > U-Boot> > > These patches are based on v2024.01-rc3 and tested with RPI5 8GB. > > Known issues: > * CONFIG_VIDEO_BCM2835 doesn't work. When you say it doesn't work, does it just not output display or does the device lock up and you need to disable it? For the rpi4 it was as simple as adding a new compatible [1] for the rev6 of the IP block as for the bits that we use in U-Boot nothing changed, but the kernel changes for the rev7 that's in the RPi5 needed updating registers [2] so I'm not sure if we're going to need to do more for this or not. > * MBOX get board revision (0x10002) doesn't work (the response status > is 0x8000_0001). Looks like a number of tags doesn't work anymore > (board/serial/MAC) but could be fetched from FW FDT. Might be worth looking to see if there's changes in the kernel for this. In an initial look I didn't see any changes to their kernel here. We probably need a patch to the identifier too similar to the following: https://source.denx.de/u-boot/u-boot/-/commit/5e7e6619c85c090f6b62685a9d90f748f1729d12 Also probably worth adding a note about reviewing support in bcmstb_sdhci.c Regards, Peter > v2: > explicitly set .data section for rpi_bcm283x_mbox_addr due to relocation > issue > update memory map with VPU range > add a patch to get human readable model from FW FDT > > Dmitry Malkin (3): > rpi5: add initial memory map for bcm2712 > rpi5: add alternative way to get MBOX address via FDT node > rpi5: get_board is no longer works. Print model name from FW FDT > > arch/arm/mach-bcm283x/include/mach/base.h | 1 + > arch/arm/mach-bcm283x/include/mach/mbox.h | 4 +-- > arch/arm/mach-bcm283x/init.c | 40 ++- > board/raspberrypi/rpi/rpi.c | 6 > 4 files changed, 48 insertions(+), 3 deletions(-) [1] https://source.denx.de/u-boot/u-boot/-/commit/0059ef0be903a1f0a9afe5259fb2e0874f78a8ac [2] https://lists.freedesktop.org/archives/dri-devel/2023-October/428453.html
Re: [PATCH v2 0/3] rpi5: initial support
On Wed, Nov 22, 2023 at 06:54:11PM +, Peter Robinson wrote: > > > These patches bring initial boot support for RPI5. Without it the > > > latest master fails with the message: > > > > DRAM: mbox: Timeout waiting for response > > > > bcm2835: Could not query ARM memory size > > > > > > With those patches and rpi_arm64_defconfig (with disabled > > > CONFIG_VIDEO_BCM2835) I'm able to get a working u-boot prompt (over > > > serial). FDT comes from firmware (EEPROM). > > > > > > > U-Boot 2024.01-rc3-3 > > > > > > > > DRAM: 1016 MiB (effective 8 GiB) > > > > mbox: Header response code invalid > > > > bcm2835: Could not query board revision > > > > FDT model : Raspberry Pi 5 Model B Rev 1.0 > > > > Core: 14 devices, 7 uclasses, devicetree: board > > > > MMC: > > > > Loading Environment from FAT... ** Bad device specification mmc 0 ** > > > > In:serial,usbkbd > > > > Out: serial,vidconsole > > > > Err: serial,vidconsole > > > > Net: No ethernet found. > > > > starting USB... > > > > No working controllers found > > > > Hit any key to stop autoboot: 0 > > > > No working controllers found > > > > No ethernet found. > > > > No ethernet found. > > > > U-Boot> > > > > > > These patches are based on v2024.01-rc3 and tested with RPI5 8GB. > > > > > > Known issues: > > > * CONFIG_VIDEO_BCM2835 doesn't work. > > > * MBOX get board revision (0x10002) doesn't work (the response status > > > is 0x8000_0001). Looks like a number of tags doesn't work anymore > > > (board/serial/MAC) but could be fetched from FW FDT. > > > > Nice. I think it's the MMC controller that we should be able to support > > with just a little more work as it's shared with rockchip, and we just > > need to match the compatible, and mirror whatever tweak is also in the > > rpi kernel tree for it. > > Is it? According to the RPi DT the sdio1 interface is used to drive > the mSD card (it's SD Express capable which I think is essentially > PCIe/NVME) which has a "brcm,bcm2712-sdhci" compatible [2] which is > added to the sdhci-brcmstb.c driver[3]. We do have a driver for this > but it's not the rockchip driver, I think you may be confused with the > sdhci interface in the RP1 chip which is a designware sdhci IP called > dwcmshc [4]. Yes, you're right I confused it with the sdhci IP. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 0/3] rpi5: initial support
> > These patches bring initial boot support for RPI5. Without it the > > latest master fails with the message: > > > DRAM: mbox: Timeout waiting for response > > > bcm2835: Could not query ARM memory size > > > > With those patches and rpi_arm64_defconfig (with disabled > > CONFIG_VIDEO_BCM2835) I'm able to get a working u-boot prompt (over > > serial). FDT comes from firmware (EEPROM). > > > > > U-Boot 2024.01-rc3-3 > > > > > > DRAM: 1016 MiB (effective 8 GiB) > > > mbox: Header response code invalid > > > bcm2835: Could not query board revision > > > FDT model : Raspberry Pi 5 Model B Rev 1.0 > > > Core: 14 devices, 7 uclasses, devicetree: board > > > MMC: > > > Loading Environment from FAT... ** Bad device specification mmc 0 ** > > > In:serial,usbkbd > > > Out: serial,vidconsole > > > Err: serial,vidconsole > > > Net: No ethernet found. > > > starting USB... > > > No working controllers found > > > Hit any key to stop autoboot: 0 > > > No working controllers found > > > No ethernet found. > > > No ethernet found. > > > U-Boot> > > > > These patches are based on v2024.01-rc3 and tested with RPI5 8GB. > > > > Known issues: > > * CONFIG_VIDEO_BCM2835 doesn't work. > > * MBOX get board revision (0x10002) doesn't work (the response status > > is 0x8000_0001). Looks like a number of tags doesn't work anymore > > (board/serial/MAC) but could be fetched from FW FDT. > > Nice. I think it's the MMC controller that we should be able to support > with just a little more work as it's shared with rockchip, and we just > need to match the compatible, and mirror whatever tweak is also in the > rpi kernel tree for it. Is it? According to the RPi DT the sdio1 interface is used to drive the mSD card (it's SD Express capable which I think is essentially PCIe/NVME) which has a "brcm,bcm2712-sdhci" compatible [2] which is added to the sdhci-brcmstb.c driver[3]. We do have a driver for this but it's not the rockchip driver, I think you may be confused with the sdhci interface in the RP1 chip which is a designware sdhci IP called dwcmshc [4]. For the brcmstb sdhci driver we currently have I suspect it'll need at least a few patches to get the basics working, in the short term I'm not sure we need the extra bits to drive the SD Express side of things as I'm sure it can fall back to old modes, looking at the patch it maybe just enough to add the compatible for what we need, that's what I was going to start with as it looks like it's similar to other IP [5]. Peter [1] https://github.com/raspberrypi/linux/blob/rpi-6.1.y/arch/arm/boot/dts/bcm2712-rpi-5-b.dts#L354 [2] https://github.com/raspberrypi/linux/blob/rpi-6.1.y/arch/arm/boot/dts/bcm2712.dtsi#L1164 [3] https://github.com/raspberrypi/linux/commit/b627647c4500d39cb026924b608841fdf4d4d7e9 [4] https://github.com/raspberrypi/linux/commit/80dd8795ca631ac692fd3079487aea6d934a829c [5] https://github.com/raspberrypi/linux/commit/b627647c4500d39cb026924b608841fdf4d4d7e9#diff-8c952b8cbbb6b3d89e1a401d558b4bd0ecbdf1679cbc5004a31039bc5235c020R172
Re: [PATCH v2 0/3] rpi5: initial support
On Tue, Nov 21, 2023 at 11:54:07PM +0100, Dmitry Malkin wrote: > These patches bring initial boot support for RPI5. Without it the > latest master fails with the message: > > DRAM: mbox: Timeout waiting for response > > bcm2835: Could not query ARM memory size > > With those patches and rpi_arm64_defconfig (with disabled > CONFIG_VIDEO_BCM2835) I'm able to get a working u-boot prompt (over > serial). FDT comes from firmware (EEPROM). > > > U-Boot 2024.01-rc3-3 > > > > DRAM: 1016 MiB (effective 8 GiB) > > mbox: Header response code invalid > > bcm2835: Could not query board revision > > FDT model : Raspberry Pi 5 Model B Rev 1.0 > > Core: 14 devices, 7 uclasses, devicetree: board > > MMC: > > Loading Environment from FAT... ** Bad device specification mmc 0 ** > > In:serial,usbkbd > > Out: serial,vidconsole > > Err: serial,vidconsole > > Net: No ethernet found. > > starting USB... > > No working controllers found > > Hit any key to stop autoboot: 0 > > No working controllers found > > No ethernet found. > > No ethernet found. > > U-Boot> > > These patches are based on v2024.01-rc3 and tested with RPI5 8GB. > > Known issues: > * CONFIG_VIDEO_BCM2835 doesn't work. > * MBOX get board revision (0x10002) doesn't work (the response status > is 0x8000_0001). Looks like a number of tags doesn't work anymore > (board/serial/MAC) but could be fetched from FW FDT. Nice. I think it's the MMC controller that we should be able to support with just a little more work as it's shared with rockchip, and we just need to match the compatible, and mirror whatever tweak is also in the rpi kernel tree for it. -- Tom signature.asc Description: PGP signature
[PATCH v2 0/3] rpi5: initial support
These patches bring initial boot support for RPI5. Without it the latest master fails with the message: > DRAM: mbox: Timeout waiting for response > bcm2835: Could not query ARM memory size With those patches and rpi_arm64_defconfig (with disabled CONFIG_VIDEO_BCM2835) I'm able to get a working u-boot prompt (over serial). FDT comes from firmware (EEPROM). > U-Boot 2024.01-rc3-3 > > DRAM: 1016 MiB (effective 8 GiB) > mbox: Header response code invalid > bcm2835: Could not query board revision > FDT model : Raspberry Pi 5 Model B Rev 1.0 > Core: 14 devices, 7 uclasses, devicetree: board > MMC: > Loading Environment from FAT... ** Bad device specification mmc 0 ** > In:serial,usbkbd > Out: serial,vidconsole > Err: serial,vidconsole > Net: No ethernet found. > starting USB... > No working controllers found > Hit any key to stop autoboot: 0 > No working controllers found > No ethernet found. > No ethernet found. > U-Boot> These patches are based on v2024.01-rc3 and tested with RPI5 8GB. Known issues: * CONFIG_VIDEO_BCM2835 doesn't work. * MBOX get board revision (0x10002) doesn't work (the response status is 0x8000_0001). Looks like a number of tags doesn't work anymore (board/serial/MAC) but could be fetched from FW FDT. v2: explicitly set .data section for rpi_bcm283x_mbox_addr due to relocation issue update memory map with VPU range add a patch to get human readable model from FW FDT Dmitry Malkin (3): rpi5: add initial memory map for bcm2712 rpi5: add alternative way to get MBOX address via FDT node rpi5: get_board is no longer works. Print model name from FW FDT arch/arm/mach-bcm283x/include/mach/base.h | 1 + arch/arm/mach-bcm283x/include/mach/mbox.h | 4 +-- arch/arm/mach-bcm283x/init.c | 40 ++- board/raspberrypi/rpi/rpi.c | 6 4 files changed, 48 insertions(+), 3 deletions(-) -- 2.40.1
[PATCH v2 0/3] Xilinx SPI driver enhancements
This series makes the Xilinx XPS SPI driver compatible with the MMC_SPI driver and also includes an enhacement from the corresponding Linux driver. Changes in v2: - Improve comment and add reviewed-by tag in patch 3 Mayuresh Chitale (3): drivers: xilinx_spi: Use udevice in start_tranfer drivers: xilinx_spi: Add xfer callback drivers: xilinx_spi: Probe fifo_depth at runtime drivers/spi/xilinx_spi.c | 68 ++-- 1 file changed, 52 insertions(+), 16 deletions(-) -- 2.34.1
[PATCH v2 0/3] efi: Minor improvements for the EFI app
This series collects a few fixes and improvements useful when booting U-Boot as an EFI app. Changes in v2: - Drop duplicate acpi_xsdt patch - Put the board_early_init_r code into board/ Simon Glass (3): efi: Collect the ACPI tables in the app efi: Correct display of table GUIDs efi: Avoid using dm_scan_other() board/efi/efi-x86_app/Makefile | 5 + board/efi/efi-x86_app/efi_app.c | 205 cmd/efi_common.c| 4 +- configs/efi-x86_app64_defconfig | 1 + lib/efi/efi_app.c | 199 +++ 5 files changed, 227 insertions(+), 187 deletions(-) create mode 100644 board/efi/efi-x86_app/Makefile create mode 100644 board/efi/efi-x86_app/efi_app.c -- 2.42.0.869.gea05f2083d-goog
