Re: U-Boot 2022.10 and dtb from Linux 6.0.8
Patrick Wildt wrote: > Well actually, maybe we should just rm -rf the whole port, then > there's no frustration on either end. ;) How does the port relate to the (IIUC neccessary) files in e.g. miniroot-am335x-*.img, if at all? Thanks //Peter
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
On Tue, May 09, 2023 at 09:54:59AM +1000, David Gwynne wrote: > > > > On 8 May 2023, at 22:44, Mark Kettenis wrote: > > > >> From: Patrick Wildt > >> Date: Mon, 8 May 2023 14:14:27 +0200 > >> > >>> Am 07.05.2023 um 19:54 schrieb Klemens Nanni : > >>> > >>> On Sun, May 07, 2023 at 06:30:55PM +0200, Mark Kettenis wrote: > As I've said before, the u-boot developers have poor quality control > and this will almost certainly break some targets. > > I think the way forward is to have a u-boot port per SoC such that we > can leave older SoCs using an older U-Boot version that we know to be > good while newer SoCs can switch to a newer version after testing a > few boards. > >>> > >>> That should always work. Not sure if pulling them out of the main u-boot > >>> port one by one or all at once is better, though. > >>> > >>> For the 2207.* update it seemed as if the Pinebook Pro's breakage alone > >>> kept > >>> all others boards on outdated versions and we practically have no other > >>> way > >>> of disentangling this mess, afaict. > >>> > >>> We already have sysutils/u-boot-asahi. > >>> > >>> Would mean some ports shuffling and installing more package where boot > >>> media > >>> is built, but that doesn't seem like too much work. > >> > >> Why don‘t we change the armv7 miniroots to not provide any U-Boot, > >> like we already do on arm64, > > > > Not against doing this, but by "old" I don't necessarily mean just > > armv7. > > > >> and then we can remove the whole U-Boot port and not have to > >> maintain it? > > > > Unfortunately there isn't a good source for pre-built U-Boot binaries, > > let alone a source of pre-built U-Boot binaries that didn't somehow > > fuck up EFI support. > > > > So I think the u-boot port *is* useful even if we don't use it to > > create bootable installer images. But only as long as we don't ship a > > package with broken images. It is clear that we don't have the > > manpower and infrastructure to test a large enough fraction of the > > u-boot binaries that our current u-boot package produces. Hence my > > suggestion to split the package (and mostly forget about the older > > ones where new versions of U-Boot don't really add any new > > functionality). > > I agree completely with Mark here. Honestly I'm not going to do the work of splitting of this U-Boot port into multiple "old but stable" ports. I'd rather have an up-to-date port where sometimes a machine doesn't boot because U-Boot people fucked up, than an old version that only works on machines built in 2020. If someone wants to split the port off into multiple ports for their favourite machine, please go ahead. But I guess I'll just continue to use a U-Boot git clone in my home directory to build one-time FW for my needs. Well actually, maybe we should just rm -rf the whole port, then there's no frustration on either end. ;) Cheers, Patrick
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
Mark Kettenis wrote: > Unfortunately there isn't a good source for pre-built U-Boot binaries, > let alone a source of pre-built U-Boot binaries that didn't somehow > fuck up EFI support. I'd like if EFI wasn't the only supported interface, especially since DTB is prefered over MSFT ACPI when available, but I suppose it's hard to put that genie back in the bottle. > So I think the u-boot port *is* useful even if we don't use it to > create bootable installer images. But only as long as we don't > ship a package with broken images. Agree. > It is clear that we don't have the manpower and infrastructure to > test a large enough fraction of the u-boot binaries that our > current u-boot package produces. Hence my suggestion to split the > package (and mostly forget about the older ones where new versions > of U-Boot don't really add any new functionality). Also agree. I've been working on something to help with automated testing for about half a year now, I'll let you know when that's ready. Meanwhile, freezing firmware is a classic approach that works until the OS requires new features, e.g. EFI.. But since EFI is already a requirement freezing is a good approach at the very least for now. Thanks //Peter
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
> On 8 May 2023, at 22:44, Mark Kettenis wrote: > >> From: Patrick Wildt >> Date: Mon, 8 May 2023 14:14:27 +0200 >> >>> Am 07.05.2023 um 19:54 schrieb Klemens Nanni : >>> >>> On Sun, May 07, 2023 at 06:30:55PM +0200, Mark Kettenis wrote: As I've said before, the u-boot developers have poor quality control and this will almost certainly break some targets. I think the way forward is to have a u-boot port per SoC such that we can leave older SoCs using an older U-Boot version that we know to be good while newer SoCs can switch to a newer version after testing a few boards. >>> >>> That should always work. Not sure if pulling them out of the main u-boot >>> port one by one or all at once is better, though. >>> >>> For the 2207.* update it seemed as if the Pinebook Pro's breakage alone kept >>> all others boards on outdated versions and we practically have no other way >>> of disentangling this mess, afaict. >>> >>> We already have sysutils/u-boot-asahi. >>> >>> Would mean some ports shuffling and installing more package where boot media >>> is built, but that doesn't seem like too much work. >> >> Why don‘t we change the armv7 miniroots to not provide any U-Boot, >> like we already do on arm64, > > Not against doing this, but by "old" I don't necessarily mean just > armv7. > >> and then we can remove the whole U-Boot port and not have to >> maintain it? > > Unfortunately there isn't a good source for pre-built U-Boot binaries, > let alone a source of pre-built U-Boot binaries that didn't somehow > fuck up EFI support. > > So I think the u-boot port *is* useful even if we don't use it to > create bootable installer images. But only as long as we don't ship a > package with broken images. It is clear that we don't have the > manpower and infrastructure to test a large enough fraction of the > u-boot binaries that our current u-boot package produces. Hence my > suggestion to split the package (and mostly forget about the older > ones where new versions of U-Boot don't really add any new > functionality). I agree completely with Mark here.
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
> From: Patrick Wildt > Date: Mon, 8 May 2023 14:14:27 +0200 > > > Am 07.05.2023 um 19:54 schrieb Klemens Nanni : > > > > On Sun, May 07, 2023 at 06:30:55PM +0200, Mark Kettenis wrote: > >> As I've said before, the u-boot developers have poor quality control > >> and this will almost certainly break some targets. > >> > >> I think the way forward is to have a u-boot port per SoC such that we > >> can leave older SoCs using an older U-Boot version that we know to be > >> good while newer SoCs can switch to a newer version after testing a > >> few boards. > > > > That should always work. Not sure if pulling them out of the main u-boot > > port one by one or all at once is better, though. > > > > For the 2207.* update it seemed as if the Pinebook Pro's breakage alone kept > > all others boards on outdated versions and we practically have no other way > > of disentangling this mess, afaict. > > > > We already have sysutils/u-boot-asahi. > > > > Would mean some ports shuffling and installing more package where boot media > > is built, but that doesn't seem like too much work. > > Why don‘t we change the armv7 miniroots to not provide any U-Boot, > like we already do on arm64, Not against doing this, but by "old" I don't necessarily mean just armv7. > and then we can remove the whole U-Boot port and not have to > maintain it? Unfortunately there isn't a good source for pre-built U-Boot binaries, let alone a source of pre-built U-Boot binaries that didn't somehow fuck up EFI support. So I think the u-boot port *is* useful even if we don't use it to create bootable installer images. But only as long as we don't ship a package with broken images. It is clear that we don't have the manpower and infrastructure to test a large enough fraction of the u-boot binaries that our current u-boot package produces. Hence my suggestion to split the package (and mostly forget about the older ones where new versions of U-Boot don't really add any new functionality).
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
> Am 07.05.2023 um 19:54 schrieb Klemens Nanni : > > On Sun, May 07, 2023 at 06:30:55PM +0200, Mark Kettenis wrote: >> As I've said before, the u-boot developers have poor quality control >> and this will almost certainly break some targets. >> >> I think the way forward is to have a u-boot port per SoC such that we >> can leave older SoCs using an older U-Boot version that we know to be >> good while newer SoCs can switch to a newer version after testing a >> few boards. > > That should always work. Not sure if pulling them out of the main u-boot > port one by one or all at once is better, though. > > For the 2207.* update it seemed as if the Pinebook Pro's breakage alone kept > all others boards on outdated versions and we practically have no other way > of disentangling this mess, afaict. > > We already have sysutils/u-boot-asahi. > > Would mean some ports shuffling and installing more package where boot media > is built, but that doesn't seem like too much work. Why don‘t we change the armv7 miniroots to not provide any U-Boot, like we already do on arm64, and then we can remove the whole U-Boot port and not have to maintain it?
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
> Date: Sun, 7 May 2023 17:54:17 + > From: Klemens Nanni > > On Sun, May 07, 2023 at 06:30:55PM +0200, Mark Kettenis wrote: > > As I've said before, the u-boot developers have poor quality control > > and this will almost certainly break some targets. > > > > I think the way forward is to have a u-boot port per SoC such that we > > can leave older SoCs using an older U-Boot version that we know to be > > good while newer SoCs can switch to a newer version after testing a > > few boards. > > That should always work. Not sure if pulling them out of the main u-boot > port one by one or all at once is better, though. I'd do it one-by-one. > For the 2207.* update it seemed as if the Pinebook Pro's breakage alone kept > all others boards on outdated versions and we practically have no other way > of disentangling this mess, afaict. > > We already have sysutils/u-boot-asahi. > > Would mean some ports shuffling and installing more package where boot media > is built, but that doesn't seem like too much work.
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
On Sun, May 07, 2023 at 06:30:55PM +0200, Mark Kettenis wrote: > As I've said before, the u-boot developers have poor quality control > and this will almost certainly break some targets. > > I think the way forward is to have a u-boot port per SoC such that we > can leave older SoCs using an older U-Boot version that we know to be > good while newer SoCs can switch to a newer version after testing a > few boards. That should always work. Not sure if pulling them out of the main u-boot port one by one or all at once is better, though. For the 2207.* update it seemed as if the Pinebook Pro's breakage alone kept all others boards on outdated versions and we practically have no other way of disentangling this mess, afaict. We already have sysutils/u-boot-asahi. Would mean some ports shuffling and installing more package where boot media is built, but that doesn't seem like too much work.
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
> Date: Sat, 6 May 2023 17:36:53 +0200
> From: Patrick Wildt
>
> On Fri, Nov 18, 2022 at 12:53:44PM +, Klemens Nanni wrote:
> > On Mon, Nov 14, 2022 at 11:37:05PM +0100, Patrick Wildt wrote:
> > > Hi,
> > >
> > > the u-boot and dtb ports haven't been updated in a while, mostly because
> > > updating those regularly breaks working machines. I think it's time for
> > > another update, so here's a diff for both.
> > >
> > > Before this heads into the tree it would be nice to get some testing
> > > from people with Pinebook Pro, RockPro64, and/or especially a BeagleBone
> > > Black.
> > >
> > > I reverted the change that switches from the 'old' cpsw switch driver
> > > model to the 'new' one. This should allow is to update the dtbs.
> > >
> > > I've personally verified that U-Boot+DTB boot fine on NanoPi R2s, but
> > > we have many more combinations.
> > >
> > > I can provide pre-built unsigned packages upon request.
> >
> > I installed u-boot-aarch64-2022.10.tgz built with dtb-6.0.8.tgz and
> > followed INSTALL.arm64 to flash the new files onto my Pinebook Pro's
> > eMMC.
> >
> > There's a u-boot logo visible in the upper right corner and OpenBSD
> > still boots, but the screen remains black now.
> >
> > Previously, I'd see X when xenodm started, now I don't see anything.
> > No warnings or errors on serial console.
> >
> > I also can't switch to another TTY to get a shell.
> >
> > Reflashing u-boot from ports makes X work again, no OS changes needed.
> >
> > I had the same issue on the same device when trying u-boot 2022.07 some
> > months ago.
>
> While I did not find the root cause of this back then, a U-Boot 2023.04
> with a dtb from Linux 6.3 does seem to work on my machine. Maybe that
> was something caused by U-Boot that is now fixed.
>
> ok?
As I've said before, the u-boot developers have poor quality control
and this will almost certainly break some targets.
I think the way forward is to have a u-boot port per SoC such that we
can leave older SoCs using an older U-Boot version that we know to be
good while newer SoCs can switch to a newer version after testing a
few boards.
> diff --git a/sysutils/u-boot/Makefile b/sysutils/u-boot/Makefile
> index d2dd2fad980..4c8acde3638 100644
> --- a/sysutils/u-boot/Makefile
> +++ b/sysutils/u-boot/Makefile
> @@ -7,8 +7,7 @@ FLAVORS= aarch64 arm riscv64
> FLAVOR?= arm
>
> COMMENT= U-Boot firmware
> -VERSION= 2021.10
> -REVISION=6
> +VERSION= 2023.04
> DISTNAME=u-boot-${VERSION}
> PKGNAME= u-boot-${FLAVOR}-${VERSION:S/-//}
> FULLPKGNAME= ${PKGNAME}
> @@ -24,7 +23,9 @@ PKG_ARCH= *
>
> BUILD_DEPENDS= devel/bison \
> devel/dtc \
> - devel/swig
> + devel/swig \
> + security/gnutls \
> + sysutils/e2fsprogs
>
> # for pkg_resources used in tools/binman/control.py
> BUILD_DEPENDS+= devel/py-setuptools${MODPY_FLAVOR}
> @@ -47,6 +48,7 @@ RK3328_BL31=
> "${LOCALBASE}/share/arm-trusted-firmware/rk3328-bl31.elf"
> RK3399_BL31= "${LOCALBASE}/share/arm-trusted-firmware/rk3399-bl31.elf"
> SUNXI_BL31= "${LOCALBASE}/share/arm-trusted-firmware/sun50i_a64-bl31.bin"
> SUNXI_H6_BL31=
> "${LOCALBASE}/share/arm-trusted-firmware/sun50i_h6-bl31.bin"
> +SUNXI_SCP= /dev/null
> .elif "${FLAVOR}" == "arm"
> BUILD_DEPENDS+= devel/arm-none-eabi/gcc,arm
> MAKE_ENV+= CROSS_COMPILE="arm-none-eabi-"
> @@ -163,7 +165,7 @@ FILES=\
> u-boot-sunxi-with-spl.bin \
> u-boot.imx \
> u-boot-dtb.imx \
> - u-boot-spl.kwb \
> + u-boot-with-spl.kwb \
> u-boot-with-spl.bin \
> u-boot.itb \
> u-boot-rockchip.bin \
> @@ -210,20 +212,20 @@ do-build:
> .if "${BOARD:M*_h64*}"
> cd ${WRKSRC} && \
> mkdir -p build/${BOARD} && \
> - ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} ${MAKE_PROGRAM} \
> - ${MAKE_FLAGS} O="build/${BOARD}" \
> + ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} SCP=${SUNXI_SCP} \
> + ${MAKE_PROGRAM} ${MAKE_FLAGS} O="build/${BOARD}" \
> -f ${MAKE_FILE} "${BOARD}"_defconfig && \
> - ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} ${MAKE_PROGRAM} \
> - ${MAKE_FLAGS} O="build/${BOARD}" \
> + ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} SCP=${SUNXI_SCP} \
> + ${MAKE_PROGRAM} ${MAKE_FLAGS} O="build/${BOARD}" \
> -f ${MAKE_FILE} ${ALL_TARGET}
> .else
> cd ${WRKSRC} && \
> mkdir -p build/${BOARD} && \
> - ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} ${MAKE_PROGRAM} \
> - ${MAKE_FLAGS} O="build/${BOARD}" \
> + ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} SCP=${SUNXI_SCP} \
> + ${MAKE_PROGRAM} ${MAKE_FLAGS} O="build/${BOARD}" \
> -f ${MAKE_FILE} "${BOARD}"_defconfig && \
> - ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} ${MAKE_PROGRAM} \
> - ${MAKE_FLAGS} O="build/${BOARD}" \
> + ${SETENV}
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
On Fri, Nov 18, 2022 at 12:53:44PM +, Klemens Nanni wrote:
> On Mon, Nov 14, 2022 at 11:37:05PM +0100, Patrick Wildt wrote:
> > Hi,
> >
> > the u-boot and dtb ports haven't been updated in a while, mostly because
> > updating those regularly breaks working machines. I think it's time for
> > another update, so here's a diff for both.
> >
> > Before this heads into the tree it would be nice to get some testing
> > from people with Pinebook Pro, RockPro64, and/or especially a BeagleBone
> > Black.
> >
> > I reverted the change that switches from the 'old' cpsw switch driver
> > model to the 'new' one. This should allow is to update the dtbs.
> >
> > I've personally verified that U-Boot+DTB boot fine on NanoPi R2s, but
> > we have many more combinations.
> >
> > I can provide pre-built unsigned packages upon request.
>
> I installed u-boot-aarch64-2022.10.tgz built with dtb-6.0.8.tgz and
> followed INSTALL.arm64 to flash the new files onto my Pinebook Pro's
> eMMC.
>
> There's a u-boot logo visible in the upper right corner and OpenBSD
> still boots, but the screen remains black now.
>
> Previously, I'd see X when xenodm started, now I don't see anything.
> No warnings or errors on serial console.
>
> I also can't switch to another TTY to get a shell.
>
> Reflashing u-boot from ports makes X work again, no OS changes needed.
>
> I had the same issue on the same device when trying u-boot 2022.07 some
> months ago.
While I did not find the root cause of this back then, a U-Boot 2023.04
with a dtb from Linux 6.3 does seem to work on my machine. Maybe that
was something caused by U-Boot that is now fixed.
ok?
Patrick
diff --git a/sysutils/u-boot/Makefile b/sysutils/u-boot/Makefile
index d2dd2fad980..4c8acde3638 100644
--- a/sysutils/u-boot/Makefile
+++ b/sysutils/u-boot/Makefile
@@ -7,8 +7,7 @@ FLAVORS=aarch64 arm riscv64
FLAVOR?= arm
COMMENT= U-Boot firmware
-VERSION= 2021.10
-REVISION= 6
+VERSION= 2023.04
DISTNAME= u-boot-${VERSION}
PKGNAME= u-boot-${FLAVOR}-${VERSION:S/-//}
FULLPKGNAME= ${PKGNAME}
@@ -24,7 +23,9 @@ PKG_ARCH= *
BUILD_DEPENDS= devel/bison \
devel/dtc \
- devel/swig
+ devel/swig \
+ security/gnutls \
+ sysutils/e2fsprogs
# for pkg_resources used in tools/binman/control.py
BUILD_DEPENDS+=devel/py-setuptools${MODPY_FLAVOR}
@@ -47,6 +48,7 @@ RK3328_BL31=
"${LOCALBASE}/share/arm-trusted-firmware/rk3328-bl31.elf"
RK3399_BL31= "${LOCALBASE}/share/arm-trusted-firmware/rk3399-bl31.elf"
SUNXI_BL31="${LOCALBASE}/share/arm-trusted-firmware/sun50i_a64-bl31.bin"
SUNXI_H6_BL31= "${LOCALBASE}/share/arm-trusted-firmware/sun50i_h6-bl31.bin"
+SUNXI_SCP= /dev/null
.elif "${FLAVOR}" == "arm"
BUILD_DEPENDS+=devel/arm-none-eabi/gcc,arm
MAKE_ENV+= CROSS_COMPILE="arm-none-eabi-"
@@ -163,7 +165,7 @@ FILES=\
u-boot-sunxi-with-spl.bin \
u-boot.imx \
u-boot-dtb.imx \
- u-boot-spl.kwb \
+ u-boot-with-spl.kwb \
u-boot-with-spl.bin \
u-boot.itb \
u-boot-rockchip.bin \
@@ -210,20 +212,20 @@ do-build:
.if "${BOARD:M*_h64*}"
cd ${WRKSRC} && \
mkdir -p build/${BOARD} && \
- ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} ${MAKE_PROGRAM} \
- ${MAKE_FLAGS} O="build/${BOARD}" \
+ ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} SCP=${SUNXI_SCP} \
+ ${MAKE_PROGRAM} ${MAKE_FLAGS} O="build/${BOARD}" \
-f ${MAKE_FILE} "${BOARD}"_defconfig && \
- ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} ${MAKE_PROGRAM} \
- ${MAKE_FLAGS} O="build/${BOARD}" \
+ ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} SCP=${SUNXI_SCP} \
+ ${MAKE_PROGRAM} ${MAKE_FLAGS} O="build/${BOARD}" \
-f ${MAKE_FILE} ${ALL_TARGET}
.else
cd ${WRKSRC} && \
mkdir -p build/${BOARD} && \
- ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} ${MAKE_PROGRAM} \
- ${MAKE_FLAGS} O="build/${BOARD}" \
+ ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} SCP=${SUNXI_SCP} \
+ ${MAKE_PROGRAM} ${MAKE_FLAGS} O="build/${BOARD}" \
-f ${MAKE_FILE} "${BOARD}"_defconfig && \
- ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} ${MAKE_PROGRAM} \
- ${MAKE_FLAGS} O="build/${BOARD}" \
+ ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} SCP=${SUNXI_SCP} \
+ ${MAKE_PROGRAM} ${MAKE_FLAGS} O="build/${BOARD}" \
-f ${MAKE_FILE} ${ALL_TARGET}
.endif
if [[ -f ${WRKSRC}/build/${BOARD}/spl/sunxi-spl.bin && \
diff --git a/sysutils/u-boot/distinfo b/sysutils/u-boot/distinfo
index 674a428905c..b30e5967428 100644
--- a/sysutils/u-boot/distinfo
+++ b/sysutils/u-boot/distinfo
@@ -1,2 +1,2 @@
-SHA256 (u-boot-2021.10.tar.bz2) = zecj4ZJi5kbyZw0l5exLGzaEkN6VDU4mJ1qYjDbfC9Q=
-SIZE (u-boot-2021.10.tar.bz2) = 17358295
+SHA256
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
> Date: Fri, 2 Dec 2022 18:44:27 + > From: Peter Stuge > > Jan Stary wrote: > > > > > Replacing the DTBs with those from the dtb package is not supposed to > > > > > work. > > > > Is this specific to the Raspberry, or is that true in general? > > I think this was specifically in response to the test on an RPi. No. My recommendation is that you don't use a separate DTB unless you really need to. The DTB that is built into U-Boot should be good enough. > > The content of the dtb package is a bunch of DTBs unde /usr/local/share > > - I am still not sure whether there is anything else to be done > > with them besides copying them over to the msdos partition > > (as created at install time). > > At least when using U-Boot there is nothing else to be done with them. > > The correct .dtb file is read by U-Boot, as Mark explained sometimes > modified or extended by U-Boot, then handed to the kernel in RAM on boot. > > I don't think the kernel ever reads .dtb files from disk, only what it > gets from the bootloader in RAM. > > It's not impossible for other software to also use the .dtb files but > the intended flow at least with U-Boot is to place the right one on > the msdos partition, tell U-Boot which one is right, let U-Boot read, > modify and pass it to the kernel. > > > //Peter > >
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
Jan Stary wrote: > > > > Replacing the DTBs with those from the dtb package is not supposed to > > > > work. > > Is this specific to the Raspberry, or is that true in general? I think this was specifically in response to the test on an RPi. > The content of the dtb package is a bunch of DTBs unde /usr/local/share > - I am still not sure whether there is anything else to be done > with them besides copying them over to the msdos partition > (as created at install time). At least when using U-Boot there is nothing else to be done with them. The correct .dtb file is read by U-Boot, as Mark explained sometimes modified or extended by U-Boot, then handed to the kernel in RAM on boot. I don't think the kernel ever reads .dtb files from disk, only what it gets from the bootloader in RAM. It's not impossible for other software to also use the .dtb files but the intended flow at least with U-Boot is to place the right one on the msdos partition, tell U-Boot which one is right, let U-Boot read, modify and pass it to the kernel. //Peter
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
On Nov 28 00:39:09, patr...@blueri.se wrote:
> Am Mon, Nov 28, 2022 at 12:22:30AM +0100 schrieb Patrick Wildt:
> > Am Fri, Nov 25, 2022 at 12:52:24AM + schrieb Peter Stuge:
> > > Jan Stary wrote:
> > > > Here is the cpsw problem:
> > > >
> > > > -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e
> > > > +cpsw0 at omsysc46: version 1.12 (0), address 00:00:00:00:00:00
> > >
> > > I confirm this on beaglebone black but I'm not sure it's actually a
> > > dtb bug, more on that below.
> > >
> > > I could anyway DHCP and ping with great success with the zero address.
> > >
> > >
> > > > > I reverted the change that switches from the 'old' cpsw switch driver
> > > > > model to the 'new' one. This should allow is to update the dtbs.
> > > >
> > > > I don't know what the old/new model is,
> > >
> > > I too am a bit confused, Patrick can you please clarify 'old' and 'new'?
> > >
> > >
> > > Does it have to do with these two sibling fragments?
> > >
> > > ethernet@0 {
> > > compatible = "ti,am335x-cpsw", "ti,cpsw";
> > >
> > > switch@0 {
> > > compatible = "ti,am335x-cpsw-switch", "ti,cpsw-switch";
> > >
> > > (Only the former is (currently) matched by OpenBSD if_cpsw.c.)
> > >
> >
> > Yup. Apparently the Linux device trees have both, and a commit in Linux
> > 5.15 switched the beaglebone from the one representation style to the
> > other.
> >
> > >
> > > > but the version in this dtb breaks my bbb.
> > >
> > > In a way it may be making things more correct, just not yet complete.
> >
> > Eh, well yes and no. If it causes a regression because our drivers
> > aren't expecting the changes in the .dts then it's a question of "does
> > anyone actually adjust our drivers?". I don't have the machine, so
> > instead of re-writing cpsw(4) to fit the new-style I'd rather have a
> > small revert that makes OpenBSD continue to work on the machine.
> >
> > > For one, both the dtb from Nov 1 snapshot miniroot-am335x-72.img and
> > > Patrick's dtb have mac-address = [00 00 00 00 00 00]; for both slaves
> > > (= PHYs). (Though I don't believe that this value is ever used.)
> > >
> > > Working on the cpsw driver I was silently wondering where the nonzero
> > > MAC on my beaglebone black comes from and I still don't know the answer.
> > >
> >
> > Either local-mac-address or from hardware registers. For cpsw(4) it's
> > local-mac-address. U-Boot configures those on bootup. Usually there
> > needs to be a /aliases/ethernet0 or so pointing to the correct node for
> > U-Boot to set it correctly. It's possible that this changes as well.
> > I will have a look.
>
> And that is exactly what happened, this should be reverted as well:
>
> - ethernet0 = _emac0;
> - ethernet1 = _emac1;
> + ethernet0 = _port1;
> + ethernet1 = _port2;
>
> Following diff changes that, and also reverts the changes for
> am335x-evm, am335x-evmsk and am335x-icev2, which are also included
> in our miniroots.
>
> Can you give this a shot?
On my beaglebone black, after rewriting the previous DTBs
with those from this latest version of the updated dtb port,
the cpsw comes up having a MAC address (without an explicit
lladdr in hostname.if as a previous workaround).
Thank you!
Jan
>
> diff --git a/sysutils/dtb/Makefile b/sysutils/dtb/Makefile
> index 23accca5c62..674663b3c47 100644
> --- a/sysutils/dtb/Makefile
> +++ b/sysutils/dtb/Makefile
> @@ -1,9 +1,7 @@
> ONLY_FOR_ARCHS= ${GCC4_ARCHS} ${CLANG_ARCHS}
>
> COMMENT= Device Tree Blobs
> -# 5.15 breaks cpsw(4) on bbb
> -VERSION= 5.14
> -REVISION=1
> +VERSION= 6.0.8
>
> # XXX Updating this port has a high chance of breaking drivers as breaking
> # XXX changes are frequently made to device trees in linux. See commit log
> @@ -17,7 +15,7 @@ HOMEPAGE= https://www.devicetree.org
> # dual GPL/BSD
> PERMIT_PACKAGE= Yes
>
> -MASTER_SITES=https://cdn.kernel.org/pub/linux/kernel/v5.x/
> +MASTER_SITES=https://cdn.kernel.org/pub/linux/kernel/v6.x/
> EXTRACT_SUFX=.tar.xz
> #MASTER_SITES= https://git.kernel.org/torvalds/t/
> PKG_ARCH=*
> diff --git a/sysutils/dtb/distinfo b/sysutils/dtb/distinfo
> index 2a1c1224b86..269f5365e57 100644
> --- a/sysutils/dtb/distinfo
> +++ b/sysutils/dtb/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (linux-5.14.tar.xz) = fgaLXg0mpisQ5TILJdzldYjLvG94HAkEQhOMnJwycbI=
> -SIZE (linux-5.14.tar.xz) = 120669872
> +SHA256 (linux-6.0.8.tar.xz) = DeT4OZaVHG+vmyIl209kWILEexoJGYGQ+XvUbl9folc=
> +SIZE (linux-6.0.8.tar.xz) = 133886436
> diff --git
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
> index d4d21ab8799..d341db3426f 100644
> ---
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
> +++
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
> @@
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
> > > > > This breakes my RPI4. > > > > > > > > > > After replacing the DTBs on the dos partition > > > > > with those from the new dtb port, the rpi4 > > > > > does not emit anything on the console, > > > > > and is not reachable over the network. > > > > > > Replacing the DTBs with those from the dtb package is not supposed to > > > work. > > > > Ah, in that case I misunderstood the whole effort. > > The entire content of the dtb package is /usr/local/share/dtb/.../*.dtb > > - what is supposed to happen with them, i.e. how does one "use" the package? > > The raspberry pi is an exception, as the dtb for the raspberry pi come > from a different firmware package. To be clear: this applies to all RPIs? (In particular, both RPI3 and RPI4?) What is this the other firmware package where OpenBSD gets the RPI dtbs? > So the ones from this dtb port > should not be tested on the raspberry pi. OK, I'll stick to the BeagleBone Black with this. > > > Replacing the DTBs with those from the dtb package is not supposed to > > > work. Is this specific to the Raspberry, or is that true in general? The content of the dtb package is a bunch of DTBs unde /usr/local/share - I am still not sure whether there is anything else to be done with them besides copying them over to the msdos partition (as created at install time). Jan
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
On Tue, Nov 22, 2022 at 04:18:55PM +0100, Jan Stary wrote: > On Nov 22 15:42:20, mark.kette...@xs4all.nl wrote: > > > Date: Tue, 22 Nov 2022 14:40:06 +0100 > > > From: Jan Stary > > > > > > On Nov 22 13:52:52, h...@stare.cz wrote: > > > > On Nov 14 23:37:05, patr...@blueri.se wrote: > > > > > the u-boot and dtb ports haven't been updated in a while, mostly > > > > > because > > > > > updating those regularly breaks working machines. I think it's time > > > > > for > > > > > another update, so here's a diff for both. > > > > > > > > > > Before this heads into the tree it would be nice to get some testing > > > > > from people with Pinebook Pro, RockPro64, and/or especially a > > > > > BeagleBone > > > > > Black. > > > > > > > > This breakes my RPI4. > > > > > > > > After replacing the DTBs on the dos partition > > > > with those from the new dtb port, the rpi4 > > > > does not emit anything on the console, > > > > and is not reachable over the network. > > > > > > > > I will take the SD card out and remove the com0 boot.conf > > > > to see what's happening once I am near the machine. > > > > > > My bad, it goes to com0 by default, so I did set tty fb0 > > > (as per INSTALL.arm64). Then I see this (jpeg attached, > > > as I have no cereal, and no ddb ps etc, as the usb keyboard > > > does not attach either); in short, > > > > > > panic: bcm_dwctwo_attach: intr_established failed! > > > > Replacing the DTBs with those from the dtb package is not supposed to > > work. > > Ah, in that case I misunderstood the whole effort. > The entire content of the dtb package is /usr/local/share/dtb/.../*.dtb > - what is supposed to happen with them, i.e. how does one "use" the package? > The raspberry pi is an exception, as the dtb for the raspberry pi come from a different firmware package. So the ones from this dtb port should not be tested on the raspberry pi. Sorry, didn't think about this when I sent out the diff, otherwise I would have mentioned it.
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
Mark Kettenis wrote: > > As I understand the driver, cpsw0 will always have a zero address if > > the "ti,cpsw" device tree node has either no child nodes at all or > > none named "local-mac-address". > > > > If a "local-mac-address" child node exists then that address is used. > > Small correction, you mean a "local-mac-address" property instead of a > node. Ah yes, thanks! > > (if_cpsw.c:364 cpsw_attach() calling cpsw_get_port_config() ff.) > > > > Neither the snapshot dtb nor Patrick's dtb contain "local-mac-address" so > > is U-Boot modifying only the older dtb (why!?) or what is going on here? > > Yes U-Boot will update the FDT with "local-mac-address" properties. > U-Boot typically uses "ethernetN" properties under /aliases to decide > where to place the "local-mac-address" properties. So if those > aliases aren't there you end up without "local-mac-address" > properties. Aha! Patrick Wildt wrote: > > > Working on the cpsw driver I was silently wondering where the nonzero > > > MAC on my beaglebone black comes from and I still don't know the answer. > > > > Either local-mac-address or from hardware registers. For cpsw(4) it's > > local-mac-address. U-Boot configures those on bootup. May cpsw(4) access the control module registers? If yes I'd rather make the driver read the fused address(es) instead of local-mac-address, to completely avoid any problems. At the very least do so when local-mac-address is zero or not found. It seems unneccessary to depend on another software (U-Boot) when the information is available in the hardware. > > Usually there needs to be a /aliases/ethernet0 or so pointing to > > the correct node for U-Boot to set it correctly. It's possible > > that this changes as well. I will have a look. > > And that is exactly what happened, this should be reverted as well: > > - ethernet0 = _emac0; > - ethernet1 = _emac1; > + ethernet0 = _port1; > + ethernet1 = _port2; Good find! > Can you give this a shot? Sure: U-Boot 2022.10 + new dtb-6.0.8 boots both 7.2 and Nov 1 snapshot kernels on BeagleBone Black with nonzero cpsw0 address and ping -f works fine. //Peter
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
Am Mon, Nov 28, 2022 at 12:22:30AM +0100 schrieb Patrick Wildt:
> Am Fri, Nov 25, 2022 at 12:52:24AM + schrieb Peter Stuge:
> > Jan Stary wrote:
> > > Here is the cpsw problem:
> > >
> > > -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e
> > > +cpsw0 at omsysc46: version 1.12 (0), address 00:00:00:00:00:00
> >
> > I confirm this on beaglebone black but I'm not sure it's actually a
> > dtb bug, more on that below.
> >
> > I could anyway DHCP and ping with great success with the zero address.
> >
> >
> > > > I reverted the change that switches from the 'old' cpsw switch driver
> > > > model to the 'new' one. This should allow is to update the dtbs.
> > >
> > > I don't know what the old/new model is,
> >
> > I too am a bit confused, Patrick can you please clarify 'old' and 'new'?
> >
> >
> > Does it have to do with these two sibling fragments?
> >
> > ethernet@0 {
> > compatible = "ti,am335x-cpsw", "ti,cpsw";
> >
> > switch@0 {
> > compatible = "ti,am335x-cpsw-switch", "ti,cpsw-switch";
> >
> > (Only the former is (currently) matched by OpenBSD if_cpsw.c.)
> >
>
> Yup. Apparently the Linux device trees have both, and a commit in Linux
> 5.15 switched the beaglebone from the one representation style to the
> other.
>
> >
> > > but the version in this dtb breaks my bbb.
> >
> > In a way it may be making things more correct, just not yet complete.
>
> Eh, well yes and no. If it causes a regression because our drivers
> aren't expecting the changes in the .dts then it's a question of "does
> anyone actually adjust our drivers?". I don't have the machine, so
> instead of re-writing cpsw(4) to fit the new-style I'd rather have a
> small revert that makes OpenBSD continue to work on the machine.
>
> > For one, both the dtb from Nov 1 snapshot miniroot-am335x-72.img and
> > Patrick's dtb have mac-address = [00 00 00 00 00 00]; for both slaves
> > (= PHYs). (Though I don't believe that this value is ever used.)
> >
> > Working on the cpsw driver I was silently wondering where the nonzero
> > MAC on my beaglebone black comes from and I still don't know the answer.
> >
>
> Either local-mac-address or from hardware registers. For cpsw(4) it's
> local-mac-address. U-Boot configures those on bootup. Usually there
> needs to be a /aliases/ethernet0 or so pointing to the correct node for
> U-Boot to set it correctly. It's possible that this changes as well.
> I will have a look.
And that is exactly what happened, this should be reverted as well:
- ethernet0 = _emac0;
- ethernet1 = _emac1;
+ ethernet0 = _port1;
+ ethernet1 = _port2;
Following diff changes that, and also reverts the changes for
am335x-evm, am335x-evmsk and am335x-icev2, which are also included
in our miniroots.
Can you give this a shot?
I updated the dtb package that I uploaded and sent you the link
for recently.
Cheers,
Patrick
diff --git a/sysutils/dtb/Makefile b/sysutils/dtb/Makefile
index 23accca5c62..674663b3c47 100644
--- a/sysutils/dtb/Makefile
+++ b/sysutils/dtb/Makefile
@@ -1,9 +1,7 @@
ONLY_FOR_ARCHS=${GCC4_ARCHS} ${CLANG_ARCHS}
COMMENT= Device Tree Blobs
-# 5.15 breaks cpsw(4) on bbb
-VERSION= 5.14
-REVISION= 1
+VERSION= 6.0.8
# XXX Updating this port has a high chance of breaking drivers as breaking
# XXX changes are frequently made to device trees in linux. See commit log
@@ -17,7 +15,7 @@ HOMEPAGE= https://www.devicetree.org
# dual GPL/BSD
PERMIT_PACKAGE=Yes
-MASTER_SITES= https://cdn.kernel.org/pub/linux/kernel/v5.x/
+MASTER_SITES= https://cdn.kernel.org/pub/linux/kernel/v6.x/
EXTRACT_SUFX= .tar.xz
#MASTER_SITES= https://git.kernel.org/torvalds/t/
PKG_ARCH= *
diff --git a/sysutils/dtb/distinfo b/sysutils/dtb/distinfo
index 2a1c1224b86..269f5365e57 100644
--- a/sysutils/dtb/distinfo
+++ b/sysutils/dtb/distinfo
@@ -1,2 +1,2 @@
-SHA256 (linux-5.14.tar.xz) = fgaLXg0mpisQ5TILJdzldYjLvG94HAkEQhOMnJwycbI=
-SIZE (linux-5.14.tar.xz) = 120669872
+SHA256 (linux-6.0.8.tar.xz) = DeT4OZaVHG+vmyIl209kWILEexoJGYGQ+XvUbl9folc=
+SIZE (linux-6.0.8.tar.xz) = 133886436
diff --git
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
index d4d21ab8799..d341db3426f 100644
--- a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
+++ b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
@@ -1,8 +1,8 @@
Index: arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
--- arch/arm64/boot/dts/rockchip/rk3328-rock64.dts.orig
+++ arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
-@@ -11,7 +11,7 @@
- compatible = "pine64,rock64", "rockchip,rk3328";
+@@ -16,7 +16,7 @@
+ };
chosen {
- stdout-path = "serial2:150n8";
diff --git
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
Am Fri, Nov 25, 2022 at 12:52:24AM + schrieb Peter Stuge:
> Jan Stary wrote:
> > Here is the cpsw problem:
> >
> > -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e
> > +cpsw0 at omsysc46: version 1.12 (0), address 00:00:00:00:00:00
>
> I confirm this on beaglebone black but I'm not sure it's actually a
> dtb bug, more on that below.
>
> I could anyway DHCP and ping with great success with the zero address.
>
>
> > > I reverted the change that switches from the 'old' cpsw switch driver
> > > model to the 'new' one. This should allow is to update the dtbs.
> >
> > I don't know what the old/new model is,
>
> I too am a bit confused, Patrick can you please clarify 'old' and 'new'?
>
>
> Does it have to do with these two sibling fragments?
>
> ethernet@0 {
> compatible = "ti,am335x-cpsw", "ti,cpsw";
>
> switch@0 {
> compatible = "ti,am335x-cpsw-switch", "ti,cpsw-switch";
>
> (Only the former is (currently) matched by OpenBSD if_cpsw.c.)
>
Yup. Apparently the Linux device trees have both, and a commit in Linux
5.15 switched the beaglebone from the one representation style to the
other.
>
> > but the version in this dtb breaks my bbb.
>
> In a way it may be making things more correct, just not yet complete.
Eh, well yes and no. If it causes a regression because our drivers
aren't expecting the changes in the .dts then it's a question of "does
anyone actually adjust our drivers?". I don't have the machine, so
instead of re-writing cpsw(4) to fit the new-style I'd rather have a
small revert that makes OpenBSD continue to work on the machine.
> For one, both the dtb from Nov 1 snapshot miniroot-am335x-72.img and
> Patrick's dtb have mac-address = [00 00 00 00 00 00]; for both slaves
> (= PHYs). (Though I don't believe that this value is ever used.)
>
> Working on the cpsw driver I was silently wondering where the nonzero
> MAC on my beaglebone black comes from and I still don't know the answer.
>
Either local-mac-address or from hardware registers. For cpsw(4) it's
local-mac-address. U-Boot configures those on bootup. Usually there
needs to be a /aliases/ethernet0 or so pointing to the correct node for
U-Boot to set it correctly. It's possible that this changes as well.
I will have a look.
Cheers,
Patrick
>
> Here's a boot log:
>
> --8<-- Nov 1 snapshot miniroot
> U-Boot SPL 2021.10 (Aug 13 2022 - 07:42:11 -0600)
> Trying to boot from MMC1
>
>
> U-Boot 2021.10 (Aug 13 2022 - 07:42:11 -0600)
>
> CPU : AM335X-GP rev 2.1
> Model: TI AM335x BeagleBone Black
> DRAM: 512 MiB
> WDT: Started with servicing (60s timeout)
> NAND: 0 MiB
> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
> not set. Validating first E-fuse MAC
> Net: eth2: ethernet@4a10, eth3: usb_ether
> Hit any key to stop autoboot: 0
> -->8--
>
> Does " not set. Validating first E-fuse MAC" mean that
> U-Boot reads the fused MAC_ID0 from the am335x control module and
> writes it into the CPSW registers?
>
>
> Booting Patrick's U-Boot (MLO and u-boot.img) with the older snapshot
> dtb I see the same message from U-Boot and cpsw0 has nonzero address.
>
> After also copying Patrick's dtb to the memory card I still see the
> same message from U-Boot but cpsw0 now has zero address.
>
> After writing the full Nov 1 snapshot again and copying only the new dtb
> over it I also see the message from U-Boot but cpsw0 again has zero address.
>
> In all these tries, env print ethaddr in U-Boot always shows nonzero address.
>
>
> As I understand the driver, cpsw0 will always have a zero address if
> the "ti,cpsw" device tree node has either no child nodes at all or
> none named "local-mac-address".
>
> If a "local-mac-address" child node exists then that address is used.
>
> (if_cpsw.c:364 cpsw_attach() calling cpsw_get_port_config() ff.)
>
> Neither the snapshot dtb nor Patrick's dtb contain "local-mac-address" so
> is U-Boot modifying only the older dtb (why!?) or what is going on here?
>
>
> //Peter
>
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
> Date: Fri, 25 Nov 2022 00:52:24 +
> From: Peter Stuge
>
> Jan Stary wrote:
> > Here is the cpsw problem:
> >
> > -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e
> > +cpsw0 at omsysc46: version 1.12 (0), address 00:00:00:00:00:00
>
> I confirm this on beaglebone black but I'm not sure it's actually a
> dtb bug, more on that below.
>
> I could anyway DHCP and ping with great success with the zero address.
>
>
> > > I reverted the change that switches from the 'old' cpsw switch driver
> > > model to the 'new' one. This should allow is to update the dtbs.
> >
> > I don't know what the old/new model is,
>
> I too am a bit confused, Patrick can you please clarify 'old' and 'new'?
>
>
> Does it have to do with these two sibling fragments?
>
> ethernet@0 {
> compatible = "ti,am335x-cpsw", "ti,cpsw";
>
> switch@0 {
> compatible = "ti,am335x-cpsw-switch", "ti,cpsw-switch";
>
> (Only the former is (currently) matched by OpenBSD if_cpsw.c.)
>
>
> > but the version in this dtb breaks my bbb.
>
> In a way it may be making things more correct, just not yet complete.
>
> For one, both the dtb from Nov 1 snapshot miniroot-am335x-72.img and
> Patrick's dtb have mac-address = [00 00 00 00 00 00]; for both slaves
> (= PHYs). (Though I don't believe that this value is ever used.)
>
> Working on the cpsw driver I was silently wondering where the nonzero
> MAC on my beaglebone black comes from and I still don't know the answer.
>
>
> Here's a boot log:
>
> --8<-- Nov 1 snapshot miniroot
> U-Boot SPL 2021.10 (Aug 13 2022 - 07:42:11 -0600)
> Trying to boot from MMC1
>
>
> U-Boot 2021.10 (Aug 13 2022 - 07:42:11 -0600)
>
> CPU : AM335X-GP rev 2.1
> Model: TI AM335x BeagleBone Black
> DRAM: 512 MiB
> WDT: Started with servicing (60s timeout)
> NAND: 0 MiB
> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
> not set. Validating first E-fuse MAC
> Net: eth2: ethernet@4a10, eth3: usb_ether
> Hit any key to stop autoboot: 0
> -->8--
>
> Does " not set. Validating first E-fuse MAC" mean that
> U-Boot reads the fused MAC_ID0 from the am335x control module and
> writes it into the CPSW registers?
>
>
> Booting Patrick's U-Boot (MLO and u-boot.img) with the older snapshot
> dtb I see the same message from U-Boot and cpsw0 has nonzero address.
>
> After also copying Patrick's dtb to the memory card I still see the
> same message from U-Boot but cpsw0 now has zero address.
>
> After writing the full Nov 1 snapshot again and copying only the new dtb
> over it I also see the message from U-Boot but cpsw0 again has zero address.
>
> In all these tries, env print ethaddr in U-Boot always shows nonzero address.
>
>
> As I understand the driver, cpsw0 will always have a zero address if
> the "ti,cpsw" device tree node has either no child nodes at all or
> none named "local-mac-address".
>
> If a "local-mac-address" child node exists then that address is used.
Small correction, you mean a "local-mac-address" property instead of a
node.
> (if_cpsw.c:364 cpsw_attach() calling cpsw_get_port_config() ff.)
>
> Neither the snapshot dtb nor Patrick's dtb contain "local-mac-address" so
> is U-Boot modifying only the older dtb (why!?) or what is going on here?
Yes U-Boot will update the FDT with "local-mac-address" properties.
U-Boot typically uses "ethernetN" properties under /aliases to decide
where to place the "local-mac-address" properties. So if those
aliases aren't there you end up without "local-mac-address"
properties.
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
Jan Stary wrote:
> Here is the cpsw problem:
>
> -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e
> +cpsw0 at omsysc46: version 1.12 (0), address 00:00:00:00:00:00
I confirm this on beaglebone black but I'm not sure it's actually a
dtb bug, more on that below.
I could anyway DHCP and ping with great success with the zero address.
> > I reverted the change that switches from the 'old' cpsw switch driver
> > model to the 'new' one. This should allow is to update the dtbs.
>
> I don't know what the old/new model is,
I too am a bit confused, Patrick can you please clarify 'old' and 'new'?
Does it have to do with these two sibling fragments?
ethernet@0 {
compatible = "ti,am335x-cpsw", "ti,cpsw";
switch@0 {
compatible = "ti,am335x-cpsw-switch", "ti,cpsw-switch";
(Only the former is (currently) matched by OpenBSD if_cpsw.c.)
> but the version in this dtb breaks my bbb.
In a way it may be making things more correct, just not yet complete.
For one, both the dtb from Nov 1 snapshot miniroot-am335x-72.img and
Patrick's dtb have mac-address = [00 00 00 00 00 00]; for both slaves
(= PHYs). (Though I don't believe that this value is ever used.)
Working on the cpsw driver I was silently wondering where the nonzero
MAC on my beaglebone black comes from and I still don't know the answer.
Here's a boot log:
--8<-- Nov 1 snapshot miniroot
U-Boot SPL 2021.10 (Aug 13 2022 - 07:42:11 -0600)
Trying to boot from MMC1
U-Boot 2021.10 (Aug 13 2022 - 07:42:11 -0600)
CPU : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM: 512 MiB
WDT: Started with servicing (60s timeout)
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
not set. Validating first E-fuse MAC
Net: eth2: ethernet@4a10, eth3: usb_ether
Hit any key to stop autoboot: 0
-->8--
Does " not set. Validating first E-fuse MAC" mean that
U-Boot reads the fused MAC_ID0 from the am335x control module and
writes it into the CPSW registers?
Booting Patrick's U-Boot (MLO and u-boot.img) with the older snapshot
dtb I see the same message from U-Boot and cpsw0 has nonzero address.
After also copying Patrick's dtb to the memory card I still see the
same message from U-Boot but cpsw0 now has zero address.
After writing the full Nov 1 snapshot again and copying only the new dtb
over it I also see the message from U-Boot but cpsw0 again has zero address.
In all these tries, env print ethaddr in U-Boot always shows nonzero address.
As I understand the driver, cpsw0 will always have a zero address if
the "ti,cpsw" device tree node has either no child nodes at all or
none named "local-mac-address".
If a "local-mac-address" child node exists then that address is used.
(if_cpsw.c:364 cpsw_attach() calling cpsw_get_port_config() ff.)
Neither the snapshot dtb nor Patrick's dtb contain "local-mac-address" so
is U-Boot modifying only the older dtb (why!?) or what is going on here?
//Peter
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
On Nov 18 15:59:01, mark.kette...@xs4all.nl wrote: > Let me explain the situation once more. In principle the only thing > you need is a (working) U-Boot for you board/machine. But in some > cases the DTB that comes with U-Boot is broken. In that case you may > be able to make your board/machine work by installing an updated DTB > for your board/machine (from the dtb package) on the "msdos" partition > of your disk. I simply _copied_ the DTBs from the dtb package onto the msdos partition; does "installing" the updated DTBs entail more than that? Jan
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
On Nov 22 15:42:20, mark.kette...@xs4all.nl wrote: > > Date: Tue, 22 Nov 2022 14:40:06 +0100 > > From: Jan Stary > > > > On Nov 22 13:52:52, h...@stare.cz wrote: > > > On Nov 14 23:37:05, patr...@blueri.se wrote: > > > > the u-boot and dtb ports haven't been updated in a while, mostly because > > > > updating those regularly breaks working machines. I think it's time for > > > > another update, so here's a diff for both. > > > > > > > > Before this heads into the tree it would be nice to get some testing > > > > from people with Pinebook Pro, RockPro64, and/or especially a BeagleBone > > > > Black. > > > > > > This breakes my RPI4. > > > > > > After replacing the DTBs on the dos partition > > > with those from the new dtb port, the rpi4 > > > does not emit anything on the console, > > > and is not reachable over the network. > > > > > > I will take the SD card out and remove the com0 boot.conf > > > to see what's happening once I am near the machine. > > > > My bad, it goes to com0 by default, so I did set tty fb0 > > (as per INSTALL.arm64). Then I see this (jpeg attached, > > as I have no cereal, and no ddb ps etc, as the usb keyboard > > does not attach either); in short, > > > > panic: bcm_dwctwo_attach: intr_established failed! > > Replacing the DTBs with those from the dtb package is not supposed to > work. Ah, in that case I misunderstood the whole effort. The entire content of the dtb package is /usr/local/share/dtb/.../*.dtb - what is supposed to happen with them, i.e. how does one "use" the package?
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
> Date: Tue, 22 Nov 2022 14:40:06 +0100 > From: Jan Stary > > On Nov 22 13:52:52, h...@stare.cz wrote: > > On Nov 14 23:37:05, patr...@blueri.se wrote: > > > the u-boot and dtb ports haven't been updated in a while, mostly because > > > updating those regularly breaks working machines. I think it's time for > > > another update, so here's a diff for both. > > > > > > Before this heads into the tree it would be nice to get some testing > > > from people with Pinebook Pro, RockPro64, and/or especially a BeagleBone > > > Black. > > > > This breakes my RPI4. > > > > After replacing the DTBs on the dos partition > > with those from the new dtb port, the rpi4 > > does not emit anything on the console, > > and is not reachable over the network. > > > > I will take the SD card out and remove the com0 boot.conf > > to see what's happening once I am near the machine. > > My bad, it goes to com0 by default, so I did set tty fb0 > (as per INSTALL.arm64). Then I see this (jpeg attached, > as I have no cereal, and no ddb ps etc, as the usb keyboard > does not attach either); in short, > > panic: bcm_dwctwo_attach: intr_established failed! Replacing the DTBs with those from the dtb package is not supposed to work.
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
On 2022/11/22 14:29, Jan Stary wrote: > On Nov 14 23:37:05, patr...@blueri.se wrote: > > I can provide pre-built unsigned packages upon request. > > How did you build on arm, when both u-boot > and the required arm-none-eabi-gcc-linaro > are marked BROKEN for arm? > > Trying to build u-boot on BeagleBone Black (arm), > I am naively commenting out the BROKEN lines. > > Jan > sysutils/u-boot can build on any arch where the deps are available, the port uses PKG_ARCH=* so the produced package can be installed on an arch other than the one where it's built
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
On Nov 22 13:50:58, s...@spacehopper.org wrote: > On 2022/11/22 14:29, Jan Stary wrote: > > On Nov 14 23:37:05, patr...@blueri.se wrote: > > > I can provide pre-built unsigned packages upon request. > > > > How did you build on arm, when both u-boot > > and the required arm-none-eabi-gcc-linaro > > are marked BROKEN for arm? > > > > Trying to build u-boot on BeagleBone Black (arm), > > I am naively commenting out the BROKEN lines. > > > > Jan > > > > sysutils/u-boot can build on any arch where the deps are available, > the port uses PKG_ARCH=* so the produced package can be installed on > an arch other than the one where it's built Thanks, that should also be much faster than trying to build on the BBB (once I unbreak my RPI4). jan
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
On Nov 14 23:37:05, patr...@blueri.se wrote: > I can provide pre-built unsigned packages upon request. How did you build on arm, when both u-boot and the required arm-none-eabi-gcc-linaro are marked BROKEN for arm? Trying to build u-boot on BeagleBone Black (arm), I am naively commenting out the BROKEN lines. Jan
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
On Nov 14 23:37:05, patr...@blueri.se wrote:
> the u-boot and dtb ports haven't been updated in a while, mostly because
> updating those regularly breaks working machines. I think it's time for
> another update, so here's a diff for both.
>
> Before this heads into the tree it would be nice to get some testing
> from people with Pinebook Pro, RockPro64, and/or especially a BeagleBone
> Black.
This breakes my RPI4.
After replacing the DTBs on the dos partition
with those from the new dtb port, the rpi4
does not emit anything on the console,
and is not reachable over the network.
I will take the SD card out and remove the com0 boot.conf
to see what's happening once I am near the machine.
Jan
> diff --git a/sysutils/dtb/Makefile b/sysutils/dtb/Makefile
> index 23accca5c62..674663b3c47 100644
> --- a/sysutils/dtb/Makefile
> +++ b/sysutils/dtb/Makefile
> @@ -1,9 +1,7 @@
> ONLY_FOR_ARCHS= ${GCC4_ARCHS} ${CLANG_ARCHS}
>
> COMMENT= Device Tree Blobs
> -# 5.15 breaks cpsw(4) on bbb
> -VERSION= 5.14
> -REVISION=1
> +VERSION= 6.0.8
>
> # XXX Updating this port has a high chance of breaking drivers as breaking
> # XXX changes are frequently made to device trees in linux. See commit log
> @@ -17,7 +15,7 @@ HOMEPAGE= https://www.devicetree.org
> # dual GPL/BSD
> PERMIT_PACKAGE= Yes
>
> -MASTER_SITES=https://cdn.kernel.org/pub/linux/kernel/v5.x/
> +MASTER_SITES=https://cdn.kernel.org/pub/linux/kernel/v6.x/
> EXTRACT_SUFX=.tar.xz
> #MASTER_SITES= https://git.kernel.org/torvalds/t/
> PKG_ARCH=*
> diff --git a/sysutils/dtb/distinfo b/sysutils/dtb/distinfo
> index 2a1c1224b86..269f5365e57 100644
> --- a/sysutils/dtb/distinfo
> +++ b/sysutils/dtb/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (linux-5.14.tar.xz) = fgaLXg0mpisQ5TILJdzldYjLvG94HAkEQhOMnJwycbI=
> -SIZE (linux-5.14.tar.xz) = 120669872
> +SHA256 (linux-6.0.8.tar.xz) = DeT4OZaVHG+vmyIl209kWILEexoJGYGQ+XvUbl9folc=
> +SIZE (linux-6.0.8.tar.xz) = 133886436
> diff --git
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
> index d4d21ab8799..d341db3426f 100644
> ---
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
> +++
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
> @@ -1,8 +1,8 @@
> Index: arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
> --- arch/arm64/boot/dts/rockchip/rk3328-rock64.dts.orig
> +++ arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
> -@@ -11,7 +11,7 @@
> - compatible = "pine64,rock64", "rockchip,rk3328";
> +@@ -16,7 +16,7 @@
> + };
>
> chosen {
> -stdout-path = "serial2:150n8";
> diff --git
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
> index 3f491bca66d..9284f71d631 100644
> ---
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
> +++
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
> @@ -1,8 +1,8 @@
> Index: arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
> --- arch/arm64/boot/dts/rockchip/rk3399-firefly.dts.orig
> +++ arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
> -@@ -14,7 +14,7 @@
> - compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
> +@@ -22,7 +22,7 @@
> + };
>
> chosen {
> -stdout-path = "serial2:150n8";
> diff --git
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
> index 2ad73484b0b..735c90c8109 100644
> ---
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
> +++
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
> @@ -1,9 +1,9 @@
> Index: arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
> --- arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi.orig
> +++ arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
> -@@ -18,7 +18,7 @@
> +@@ -24,7 +24,7 @@
> + };
>
> - / {
> chosen {
> -stdout-path = "serial2:150n8";
> +stdout-path = "serial2:115200n8";
> diff --git
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-pinebook-pro_dts
>
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-pinebook-pro_dts
> index 3126aee73a4..a45b88b43cf 100644
> ---
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-pinebook-pro_dts
> +++
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-pinebook-pro_dts
> @@ -1,8 +1,8 @@
> Index: arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
> --- arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts.orig
> +++ arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
> -@@ -19,7 +19,7 @@
> - compatible = "pine64,pinebook-pro", "rockchip,rk3399";
> +@@
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
> Here is the cpsw problem: > > -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e > +cpsw0 at omsysc46: version 1.12 (0), address 00:00:00:00:00:00 > > The booted BBB did assign an address to its cpsw0, > > cpsw0: flags=808843 mtu 1500 > lladdr 00:00:00:00:00:00 > index 1 priority 0 llprio 3 > groups: egress > media: Ethernet autoselect (100baseTX full-duplex) > status: active > inet 192.168.44.22 netmask 0xff00 broadcast 192.168.44.255 > > but without a MAC address, I cannot ssh to it (though I can ssh out of it); > arp says > > 192.168.44.22 00:00:00:00:00:00 em0 6m12s I am surprised dhcpd even talks to that, but dhcpd[37704]: DHCPDISCOVER from 00:00:00:00:00:00 via em0 dhcpd[37704]: DHCPOFFER on 192.168.44.22 to 00:00:00:00:00:00 via em0 dhcpd[37704]: DHCPREQUEST for 192.168.44.22 from 00:00:00:00:00:00 via em0 dhcpd[37704]: DHCPACK on 192.168.44.22 to 00:00:00:00:00:00 via em0
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
Am Fri, Nov 18, 2022 at 12:53:44PM + schrieb Klemens Nanni: > On Mon, Nov 14, 2022 at 11:37:05PM +0100, Patrick Wildt wrote: > > Hi, > > > > the u-boot and dtb ports haven't been updated in a while, mostly because > > updating those regularly breaks working machines. I think it's time for > > another update, so here's a diff for both. > > > > Before this heads into the tree it would be nice to get some testing > > from people with Pinebook Pro, RockPro64, and/or especially a BeagleBone > > Black. > > > > I reverted the change that switches from the 'old' cpsw switch driver > > model to the 'new' one. This should allow is to update the dtbs. > > > > I've personally verified that U-Boot+DTB boot fine on NanoPi R2s, but > > we have many more combinations. > > > > I can provide pre-built unsigned packages upon request. > > I installed u-boot-aarch64-2022.10.tgz built with dtb-6.0.8.tgz and > followed INSTALL.arm64 to flash the new files onto my Pinebook Pro's > eMMC. > > There's a u-boot logo visible in the upper right corner and OpenBSD > still boots, but the screen remains black now. > > Previously, I'd see X when xenodm started, now I don't see anything. > No warnings or errors on serial console. > > I also can't switch to another TTY to get a shell. > > Reflashing u-boot from ports makes X work again, no OS changes needed. > > I had the same issue on the same device when trying u-boot 2022.07 some > months ago. Are you seeing OpenBSD boot on the display? Or do you *only* see a U-Boot logo and nothing else?
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
> Date: Fri, 18 Nov 2022 12:53:44 + > From: Klemens Nanni > > On Mon, Nov 14, 2022 at 11:37:05PM +0100, Patrick Wildt wrote: > > Hi, > > > > the u-boot and dtb ports haven't been updated in a while, mostly because > > updating those regularly breaks working machines. I think it's time for > > another update, so here's a diff for both. > > > > Before this heads into the tree it would be nice to get some testing > > from people with Pinebook Pro, RockPro64, and/or especially a BeagleBone > > Black. > > > > I reverted the change that switches from the 'old' cpsw switch driver > > model to the 'new' one. This should allow is to update the dtbs. > > > > I've personally verified that U-Boot+DTB boot fine on NanoPi R2s, but > > we have many more combinations. > > > > I can provide pre-built unsigned packages upon request. > > I installed u-boot-aarch64-2022.10.tgz built with dtb-6.0.8.tgz and > followed INSTALL.arm64 to flash the new files onto my Pinebook Pro's > eMMC. Well, what you did makes no sense. The u-boot package does not depend on the dtb package as u-boot comes with its own set of DTBs. So the only thing you tested is that u-boot-aarch-2022.10 is still broken on your machine. Let me explain the situation once more. In principle the only thing you need is a (working) U-Boot for you board/machine. But in some cases the DTB that comes with U-Boot is broken. In that case you may be able to make your board/machine work by installing an updated DTB for your board/machine (from the dtb package) on the "msdos" partition of your disk. Another reason why you might want to install an updated DTB is when the DTB that comes with U-Boot is incomplete. In that case installing an updated DTB on the "msdos" partition may give you better hardware support (more drivers that attach) for your board/machine. Ultimately the missing bits should end up in U-Boot, but as you have experienced, newer versions of U-Boot might be broken for your board. So the possibility to update the DTB separately from U-Boot gives people a bit more flexibility. The whole thing sucks, and I don't really know how to make it better. Newer boards need newer U-Boot versions and could take advantage of newer DTBs. But those newer versions may break older boards. Ideally we'd keep an archive of "known good" versions somewhere. That raises issues with GPL compliance though as we can't just point people at ports if they'd ask us for the source code that was used to build the binaries we distribute.
Re: U-Boot 2022.10 and dtb from Linux 6.0.8
On Mon, Nov 14, 2022 at 11:37:05PM +0100, Patrick Wildt wrote:
> Hi,
>
> the u-boot and dtb ports haven't been updated in a while, mostly because
> updating those regularly breaks working machines. I think it's time for
> another update, so here's a diff for both.
>
> Before this heads into the tree it would be nice to get some testing
> from people with Pinebook Pro, RockPro64, and/or especially a BeagleBone
> Black.
>
> I reverted the change that switches from the 'old' cpsw switch driver
> model to the 'new' one. This should allow is to update the dtbs.
>
> I've personally verified that U-Boot+DTB boot fine on NanoPi R2s, but
> we have many more combinations.
>
> I can provide pre-built unsigned packages upon request.
I installed u-boot-aarch64-2022.10.tgz built with dtb-6.0.8.tgz and
followed INSTALL.arm64 to flash the new files onto my Pinebook Pro's
eMMC.
There's a u-boot logo visible in the upper right corner and OpenBSD
still boots, but the screen remains black now.
Previously, I'd see X when xenodm started, now I don't see anything.
No warnings or errors on serial console.
I also can't switch to another TTY to get a shell.
Reflashing u-boot from ports makes X work again, no OS changes needed.
I had the same issue on the same device when trying u-boot 2022.07 some
months ago.
>
> Cheers,
> Patrick
>
> diff --git a/sysutils/dtb/Makefile b/sysutils/dtb/Makefile
> index 23accca5c62..674663b3c47 100644
> --- a/sysutils/dtb/Makefile
> +++ b/sysutils/dtb/Makefile
> @@ -1,9 +1,7 @@
> ONLY_FOR_ARCHS= ${GCC4_ARCHS} ${CLANG_ARCHS}
>
> COMMENT= Device Tree Blobs
> -# 5.15 breaks cpsw(4) on bbb
> -VERSION= 5.14
> -REVISION=1
> +VERSION= 6.0.8
>
> # XXX Updating this port has a high chance of breaking drivers as breaking
> # XXX changes are frequently made to device trees in linux. See commit log
> @@ -17,7 +15,7 @@ HOMEPAGE= https://www.devicetree.org
> # dual GPL/BSD
> PERMIT_PACKAGE= Yes
>
> -MASTER_SITES=https://cdn.kernel.org/pub/linux/kernel/v5.x/
> +MASTER_SITES=https://cdn.kernel.org/pub/linux/kernel/v6.x/
> EXTRACT_SUFX=.tar.xz
> #MASTER_SITES= https://git.kernel.org/torvalds/t/
> PKG_ARCH=*
> diff --git a/sysutils/dtb/distinfo b/sysutils/dtb/distinfo
> index 2a1c1224b86..269f5365e57 100644
> --- a/sysutils/dtb/distinfo
> +++ b/sysutils/dtb/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (linux-5.14.tar.xz) = fgaLXg0mpisQ5TILJdzldYjLvG94HAkEQhOMnJwycbI=
> -SIZE (linux-5.14.tar.xz) = 120669872
> +SHA256 (linux-6.0.8.tar.xz) = DeT4OZaVHG+vmyIl209kWILEexoJGYGQ+XvUbl9folc=
> +SIZE (linux-6.0.8.tar.xz) = 133886436
> diff --git
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
> index d4d21ab8799..d341db3426f 100644
> ---
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
> +++
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
> @@ -1,8 +1,8 @@
> Index: arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
> --- arch/arm64/boot/dts/rockchip/rk3328-rock64.dts.orig
> +++ arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
> -@@ -11,7 +11,7 @@
> - compatible = "pine64,rock64", "rockchip,rk3328";
> +@@ -16,7 +16,7 @@
> + };
>
> chosen {
> -stdout-path = "serial2:150n8";
> diff --git
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
> index 3f491bca66d..9284f71d631 100644
> ---
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
> +++
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
> @@ -1,8 +1,8 @@
> Index: arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
> --- arch/arm64/boot/dts/rockchip/rk3399-firefly.dts.orig
> +++ arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
> -@@ -14,7 +14,7 @@
> - compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
> +@@ -22,7 +22,7 @@
> + };
>
> chosen {
> -stdout-path = "serial2:150n8";
> diff --git
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
> index 2ad73484b0b..735c90c8109 100644
> ---
> a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
> +++
> b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
> @@ -1,9 +1,9 @@
> Index: arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
> --- arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi.orig
> +++ arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
> -@@ -18,7 +18,7 @@
> +@@ -24,7 +24,7 @@
> + };
>
> - / {
> chosen {
> -stdout-path = "serial2:150n8";
> +stdout-path = "serial2:115200n8";
> diff --git
>
U-Boot 2022.10 and dtb from Linux 6.0.8
Hi,
the u-boot and dtb ports haven't been updated in a while, mostly because
updating those regularly breaks working machines. I think it's time for
another update, so here's a diff for both.
Before this heads into the tree it would be nice to get some testing
from people with Pinebook Pro, RockPro64, and/or especially a BeagleBone
Black.
I reverted the change that switches from the 'old' cpsw switch driver
model to the 'new' one. This should allow is to update the dtbs.
I've personally verified that U-Boot+DTB boot fine on NanoPi R2s, but
we have many more combinations.
I can provide pre-built unsigned packages upon request.
Cheers,
Patrick
diff --git a/sysutils/dtb/Makefile b/sysutils/dtb/Makefile
index 23accca5c62..674663b3c47 100644
--- a/sysutils/dtb/Makefile
+++ b/sysutils/dtb/Makefile
@@ -1,9 +1,7 @@
ONLY_FOR_ARCHS=${GCC4_ARCHS} ${CLANG_ARCHS}
COMMENT= Device Tree Blobs
-# 5.15 breaks cpsw(4) on bbb
-VERSION= 5.14
-REVISION= 1
+VERSION= 6.0.8
# XXX Updating this port has a high chance of breaking drivers as breaking
# XXX changes are frequently made to device trees in linux. See commit log
@@ -17,7 +15,7 @@ HOMEPAGE= https://www.devicetree.org
# dual GPL/BSD
PERMIT_PACKAGE=Yes
-MASTER_SITES= https://cdn.kernel.org/pub/linux/kernel/v5.x/
+MASTER_SITES= https://cdn.kernel.org/pub/linux/kernel/v6.x/
EXTRACT_SUFX= .tar.xz
#MASTER_SITES= https://git.kernel.org/torvalds/t/
PKG_ARCH= *
diff --git a/sysutils/dtb/distinfo b/sysutils/dtb/distinfo
index 2a1c1224b86..269f5365e57 100644
--- a/sysutils/dtb/distinfo
+++ b/sysutils/dtb/distinfo
@@ -1,2 +1,2 @@
-SHA256 (linux-5.14.tar.xz) = fgaLXg0mpisQ5TILJdzldYjLvG94HAkEQhOMnJwycbI=
-SIZE (linux-5.14.tar.xz) = 120669872
+SHA256 (linux-6.0.8.tar.xz) = DeT4OZaVHG+vmyIl209kWILEexoJGYGQ+XvUbl9folc=
+SIZE (linux-6.0.8.tar.xz) = 133886436
diff --git
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
index d4d21ab8799..d341db3426f 100644
--- a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
+++ b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
@@ -1,8 +1,8 @@
Index: arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
--- arch/arm64/boot/dts/rockchip/rk3328-rock64.dts.orig
+++ arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
-@@ -11,7 +11,7 @@
- compatible = "pine64,rock64", "rockchip,rk3328";
+@@ -16,7 +16,7 @@
+ };
chosen {
- stdout-path = "serial2:150n8";
diff --git
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
index 3f491bca66d..9284f71d631 100644
--- a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
+++ b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
@@ -1,8 +1,8 @@
Index: arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
--- arch/arm64/boot/dts/rockchip/rk3399-firefly.dts.orig
+++ arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
-@@ -14,7 +14,7 @@
- compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
+@@ -22,7 +22,7 @@
+ };
chosen {
- stdout-path = "serial2:150n8";
diff --git
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
index 2ad73484b0b..735c90c8109 100644
---
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
+++
b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
@@ -1,9 +1,9 @@
Index: arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
--- arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi.orig
+++ arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
-@@ -18,7 +18,7 @@
+@@ -24,7 +24,7 @@
+ };
- / {
chosen {
- stdout-path = "serial2:150n8";
+ stdout-path = "serial2:115200n8";
diff --git
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-pinebook-pro_dts
b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-pinebook-pro_dts
index 3126aee73a4..a45b88b43cf 100644
---
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-pinebook-pro_dts
+++
b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-pinebook-pro_dts
@@ -1,8 +1,8 @@
Index: arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
--- arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts.orig
+++ arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
-@@ -19,7 +19,7 @@
- compatible = "pine64,pinebook-pro", "rockchip,rk3399";
+@@ -26,7 +26,7 @@
+ };
chosen {
- stdout-path = "serial2:150n8";
diff --git
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-rock-pi-4_dtsi
