Re: installer: pine64: better firmware dd
On Sun, Mar 26, 2023 at 11:01:07AM +1100, Jonathan Gray wrote:
> this diff is incomplete
> the pine64 part in ramdisk/list is still there
Forgot to unhook them, thanks.
Index: install.md
===
RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
retrieving revision 1.37
diff -u -p -r1.37 install.md
--- install.md 25 Mar 2023 18:29:37 - 1.37
+++ install.md 25 Mar 2023 23:23:04 -
@@ -40,7 +40,6 @@ md_installboot() {
case $(sysctl -n machdep.compatible) in
apple,*)_plat=apple;;
- pine64,pine64*(+)) _plat=pine64;;
raspberrypi,*) _plat=rpi;
esac
@@ -63,10 +62,6 @@ md_installboot() {
(cd /etc/firmware
pax -rw apple-bwfm /mnt/etc/firmware)
fi
- ;;
- pine64)
- dd if=$_mdec/u-boot-sunxi-with-spl.bin of=${_disk}c \
- bs=1024 seek=8 status=none
;;
rpi)
mount ${MOUNT_ARGS_msdos} ${_disk}i /mnt/mnt
Index: list
===
RCS file: /cvs/src/distrib/arm64/ramdisk/list,v
retrieving revision 1.20
diff -u -p -r1.20 list
--- list28 Jan 2023 18:40:53 - 1.20
+++ list26 Mar 2023 00:32:19 -
@@ -116,9 +116,6 @@ COPY/usr/local/share/raspberrypi-firmwa
COPY /usr/local/share/raspberrypi-firmware/boot/overlays/disable-bt.dtbo
usr/mdec/rpi/disable-bt.dtbo
COPY /usr/local/share/u-boot/rpi_arm64/u-boot.bin usr/mdec/rpi/u-boot.bin
-MKDIR usr/mdec/pine64
-COPY /usr/local/share/u-boot/pine64_plus/u-boot-sunxi-with-spl.bin
usr/mdec/pine64/u-boot-sunxi-with-spl.bin
-
# copy the MAKEDEV script and make some devices
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIALcd dev; sh MAKEDEV ramdisk
Re: installer: pine64: better firmware dd
On Sat, Mar 25, 2023 at 11:34:08PM +, Klemens Nanni wrote:
> On Sat, Mar 25, 2023 at 08:36:06PM +0100, Mark Kettenis wrote:
> > To be honest I think we should remove this from the installer scripts.
> >
> > This code tries to handle the case where we've just whacked the disk
> > we've booted from since we're trying to install on it. My current
> > advice to people is to put the "system" firmware on a different disk
> > than the OS (e.g. the firmware on uSD and the OS on USB). This only
> > tries to handle the pine64. The only thing that sets pine64 apart
> > from many other boards is that it was the first board we ran on.
>
> This pine64 code was added in 2017 and never changed since then, no other
> boards except apple and rpi (for good reasons) were handled, either.
>
> I've installed on a Pinebook Pro just find without md_installboot() bits
> for it, although probably never on the same disk I booted from.
>
> Here's the removal diff if anyone wants to commit or OK it.
this diff is incomplete
the pine64 part in ramdisk/list is still there
why keep the remaining parts in the boot images after that?
>
> > If we want to have support for updating the "system" firmware, we
> > probably should follow the apple model, where we handle this in
> > installboot. But the we probably should do a better job at curating
> > these firmwares. At this point I'm not even confident the firmware we
> > ship for pine64 actually works. We've basically stopped updating the
> > u-boot package because each update broke a subset of the boards we
> > supported.
>
> Can't speak for the pine64, but the Pinebook Pro is equally bad and I've
> already tried numerous other u-boot flavours, firmwares and what not to
> fix stuff... such a mess.
>
> The rpi case is a different story and must remain.
>
>
> Index: install.md
> ===
> RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
> retrieving revision 1.37
> diff -u -p -r1.37 install.md
> --- install.md25 Mar 2023 18:29:37 - 1.37
> +++ install.md25 Mar 2023 23:23:04 -
> @@ -40,7 +40,6 @@ md_installboot() {
>
> case $(sysctl -n machdep.compatible) in
> apple,*)_plat=apple;;
> - pine64,pine64*(+)) _plat=pine64;;
> raspberrypi,*) _plat=rpi;
> esac
>
> @@ -63,10 +62,6 @@ md_installboot() {
> (cd /etc/firmware
> pax -rw apple-bwfm /mnt/etc/firmware)
> fi
> - ;;
> - pine64)
> - dd if=$_mdec/u-boot-sunxi-with-spl.bin of=${_disk}c \
> - bs=1024 seek=8 status=none
> ;;
> rpi)
> mount ${MOUNT_ARGS_msdos} ${_disk}i /mnt/mnt
>
>
Re: installer: pine64: better firmware dd
On Sat, Mar 25, 2023 at 08:36:06PM +0100, Mark Kettenis wrote:
> To be honest I think we should remove this from the installer scripts.
>
> This code tries to handle the case where we've just whacked the disk
> we've booted from since we're trying to install on it. My current
> advice to people is to put the "system" firmware on a different disk
> than the OS (e.g. the firmware on uSD and the OS on USB). This only
> tries to handle the pine64. The only thing that sets pine64 apart
> from many other boards is that it was the first board we ran on.
This pine64 code was added in 2017 and never changed since then, no other
boards except apple and rpi (for good reasons) were handled, either.
I've installed on a Pinebook Pro just find without md_installboot() bits
for it, although probably never on the same disk I booted from.
Here's the removal diff if anyone wants to commit or OK it.
> If we want to have support for updating the "system" firmware, we
> probably should follow the apple model, where we handle this in
> installboot. But the we probably should do a better job at curating
> these firmwares. At this point I'm not even confident the firmware we
> ship for pine64 actually works. We've basically stopped updating the
> u-boot package because each update broke a subset of the boards we
> supported.
Can't speak for the pine64, but the Pinebook Pro is equally bad and I've
already tried numerous other u-boot flavours, firmwares and what not to
fix stuff... such a mess.
The rpi case is a different story and must remain.
Index: install.md
===
RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
retrieving revision 1.37
diff -u -p -r1.37 install.md
--- install.md 25 Mar 2023 18:29:37 - 1.37
+++ install.md 25 Mar 2023 23:23:04 -
@@ -40,7 +40,6 @@ md_installboot() {
case $(sysctl -n machdep.compatible) in
apple,*)_plat=apple;;
- pine64,pine64*(+)) _plat=pine64;;
raspberrypi,*) _plat=rpi;
esac
@@ -63,10 +62,6 @@ md_installboot() {
(cd /etc/firmware
pax -rw apple-bwfm /mnt/etc/firmware)
fi
- ;;
- pine64)
- dd if=$_mdec/u-boot-sunxi-with-spl.bin of=${_disk}c \
- bs=1024 seek=8 status=none
;;
rpi)
mount ${MOUNT_ARGS_msdos} ${_disk}i /mnt/mnt
Patch to stop tearing on Intel modesetting in Xenocara
Hi,
I noticed the "TearFree" patch was merged upstream in the XOrg
modesetting driver. Long time ago when it was sent I patched it into
my local Xenocara and used it ever since. Zero issues, zero tearing.
Maybe let's consider adding it to Xenocara too? I am attaching the
patch, commit message is from my local git repo, I am of course NOT an
author. It adds the "TearFree" option to the modesetting section of
your xorg.conf.
Feel free to fetch it directly from the Merge Request, the real author
is https://gitlab.freedesktop.org/kerneltoast:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1006
I am just sending this as is, but I don't know enough about XOrg to
follow up with extra fixes to the code. I can only confirm that it
worked flawlessly on my Intel NUC 11 for a really long time.
Thanks,
Igor.
From ba437abd59efa8a18426748b5edd2ce7f67c5dbe Mon Sep 17 00:00:00 2001
From: Igor Petruk
Date: Sun, 4 Dec 2022 23:00:50 +
Subject: [PATCH] Added tearfree patch
---
xserver/dix/pixmap.c | 15 +-
.../hw/xfree86/drivers/modesetting/driver.c | 68 ++
.../hw/xfree86/drivers/modesetting/driver.h | 3 +
.../drivers/modesetting/drmmode_display.c | 202 ++
.../drivers/modesetting/drmmode_display.h | 16 ++
.../drivers/modesetting/modesetting.man | 11 +
.../hw/xfree86/drivers/modesetting/pageflip.c | 108 --
.../hw/xfree86/drivers/modesetting/present.c | 22 +-
xserver/hw/xfree86/modes/xf86Crtc.h | 5 +
xserver/hw/xfree86/modes/xf86Rotate.c | 22 +-
xserver/include/pixmap.h | 5 +
xserver/present/present.h | 4 +-
xserver/present/present_execute.c | 4 +-
xserver/present/present_priv.h| 1 +
xserver/present/present_scmd.c| 60 --
xserver/present/present_vblank.c | 12 ++
16 files changed, 465 insertions(+), 93 deletions(-)
diff --git a/xserver/dix/pixmap.c b/xserver/dix/pixmap.c
index 5a0146bbb..0b01c4ee0 100644
--- a/xserver/dix/pixmap.c
+++ b/xserver/dix/pixmap.c
@@ -262,12 +262,11 @@ PixmapStopDirtyTracking(DrawablePtr src, PixmapPtr secondary_dst)
return TRUE;
}
-static void
-PixmapDirtyCopyArea(PixmapPtr dst,
-PixmapDirtyUpdatePtr dirty,
+void
+PixmapDirtyCopyArea(PixmapPtr dst, DrawablePtr src,
+int x, int y, int dst_x, int dst_y,
RegionPtr dirty_region)
{
-DrawablePtr src = dirty->src;
ScreenPtr pScreen = src->pScreen;
int n;
BoxPtr b;
@@ -294,9 +293,8 @@ PixmapDirtyCopyArea(PixmapPtr dst,
h = dst_box.y2 - dst_box.y1;
pGC->ops->CopyArea(src, >drawable, pGC,
- dirty->x + dst_box.x1, dirty->y + dst_box.y1, w, h,
- dirty->dst_x + dst_box.x1,
- dirty->dst_y + dst_box.y1);
+ x + dst_box.x1, y + dst_box.y1, w, h,
+ dst_x + dst_box.x1, dst_y + dst_box.y1);
b++;
}
FreeScratchGC(pGC);
@@ -408,7 +406,8 @@ Bool PixmapSyncDirtyHelper(PixmapDirtyUpdatePtr dirty)
RegionTranslate(, -dirty->x, -dirty->y);
if (!pScreen->root || dirty->rotation == RR_Rotate_0)
-PixmapDirtyCopyArea(dst, dirty, );
+PixmapDirtyCopyArea(dst, dirty->src, dirty->x, dirty->y,
+dirty->dst_x, dirty->dst_y, );
else
PixmapDirtyCompositeRotate(dst, dirty, );
pScreen->SourceValidate = SourceValidate;
diff --git a/xserver/hw/xfree86/drivers/modesetting/driver.c b/xserver/hw/xfree86/drivers/modesetting/driver.c
index 62d471a26..e7691645f 100644
--- a/xserver/hw/xfree86/drivers/modesetting/driver.c
+++ b/xserver/hw/xfree86/drivers/modesetting/driver.c
@@ -151,6 +151,7 @@ static const OptionInfoRec Options[] = {
{OPTION_VARIABLE_REFRESH, "VariableRefresh", OPTV_BOOLEAN, {0}, FALSE},
{OPTION_USE_GAMMA_LUT, "UseGammaLUT", OPTV_BOOLEAN, {0}, FALSE},
{OPTION_ASYNC_FLIP_SECONDARIES, "AsyncFlipSecondaries", OPTV_BOOLEAN, {0}, FALSE},
+{OPTION_TEARFREE, "TearFree", OPTV_BOOLEAN, {0}, FALSE},
{-1, NULL, OPTV_NONE, {0}, FALSE}
};
@@ -521,6 +522,64 @@ GetRec(ScrnInfoPtr pScrn)
return TRUE;
}
+static void
+ms_tearfree_update_damages(ScrnInfoPtr scrn, RegionPtr dirty)
+{
+xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
+modesettingPtr ms = modesettingPTR(scrn);
+int c, i;
+
+if (!ms->drmmode.tearfree_enable)
+return;
+
+for (c = 0; c < xf86_config->num_crtc; c++) {
+xf86CrtcPtr crtc = xf86_config->crtc[c];
+drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
+drmmode_tearfree_ptr trf = _crtc->tearfree;
+RegionRec region;
+
+/* Skip CRTCs which aren't using TearFree */
+if (!trf->buf[0].px)
+continue;
+
+/* Compute how much of the damage intersects with this CRTC */
+
Re: installer: pine64: better firmware dd
25.03.2023 19:36, Mark Kettenis пишет: > To be honest I think we should remove this from the installer scripts. Please, be my guest! arm64 md_installboot() and its lack of softraid awareness on certain boards is why we don't have instller support for guided disk encryption on this platform, yet. > This code tries to handle the case where we've just whacked the disk > we've booted from since we're trying to install on it. My current > advice to people is to put the "system" firmware on a different disk > than the OS (e.g. the firmware on uSD and the OS on USB). This only > tries to handle the pine64. The only thing that sets pine64 apart > from many other boards is that it was the first board we ran on. I don't have the big picture of arm64 devices, but similar ones like the Pinebook Pro are fine without md_installboot() hunks and instruct users to flash firmware through INSTALL.arm64, so exceptions in md_installboot() certainly seem odd. > If we want to have support for updating the "system" firmware, we > probably should follow the apple model, where we handle this in > installboot. But the we probably should do a better job at curating > these firmwares. At this point I'm not even confident the firmware we > ship for pine64 actually works. We've basically stopped updating the > u-boot package because each update broke a subset of the boards we > supported. I also thought about moving this stuff to installboot(8), but again, no idea what board needs what in terms of firmware and quirks. If you think this stuff can go and other arm64 hackers agree, please go ahead, it makes my work much easier.
Re: installer: pine64: better firmware dd
> Date: Sat, 25 Mar 2023 16:32:17 +
> From: Klemens Nanni
>
> We must not throw away all errors, dd(1) can be silenced properly.
>
> OK?
>
> I don't have the hardware to test, but will need to tweak this MD code soon
> for get softraid installs working on those boards.
To be honest I think we should remove this from the installer scripts.
This code tries to handle the case where we've just whacked the disk
we've booted from since we're trying to install on it. My current
advice to people is to put the "system" firmware on a different disk
than the OS (e.g. the firmware on uSD and the OS on USB). This only
tries to handle the pine64. The only thing that sets pine64 apart
from many other boards is that it was the first board we ran on.
If we want to have support for updating the "system" firmware, we
probably should follow the apple model, where we handle this in
installboot. But the we probably should do a better job at curating
these firmwares. At this point I'm not even confident the firmware we
ship for pine64 actually works. We've basically stopped updating the
u-boot package because each update broke a subset of the boards we
supported.
> Index: ramdisk/install.md
> ===
> RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
> retrieving revision 1.36
> diff -u -p -r1.36 install.md
> --- ramdisk/install.md6 Feb 2023 08:41:00 - 1.36
> +++ ramdisk/install.md25 Mar 2023 16:28:50 -
> @@ -66,7 +66,7 @@ md_installboot() {
> ;;
> pine64)
> dd if=$_mdec/u-boot-sunxi-with-spl.bin of=${_disk}c \
> - bs=1024 seek=8 >/dev/null 2>&1
> + bs=1024 seek=8 status=none
> ;;
> rpi)
> mount ${MOUNT_ARGS_msdos} ${_disk}i /mnt/mnt
>
>
Re: recv.c: consistency wrt NULL for pointers
On Sat, 25 Mar 2023 20:13:35 +0100, Otto Moerbeek wrote: > Last arg also is a pointer, so pass NULL. Looks like it's been that way since the initial CSRG commit. OK millert@ - todd
recv.c: consistency wrt NULL for pointers
Hi,
Last arg also is a pointer, so pass NULL.
-Otto
Index: recv.c
===
RCS file: /home/cvs/src/lib/libc/net/recv.c,v
retrieving revision 1.6
diff -u -p -r1.6 recv.c
--- recv.c 4 Oct 2015 07:17:27 - 1.6
+++ recv.c 23 Mar 2023 06:00:37 -
@@ -36,6 +36,6 @@
ssize_t
recv(int s, void *buf, size_t len, int flags)
{
- return (recvfrom(s, buf, len, flags, NULL, 0));
+ return (recvfrom(s, buf, len, flags, NULL, NULL));
}
DEF_WEAK(recv);
Re: installer: arm64: better disk variable handling
On Sat, Mar 25, 2023 at 07:02:24PM +, Klemens Nanni wrote:
> Call the function argument `_disk' and construct full device paths where
> needed, so that other code can reuse the mnemonic variable.
>
> This matches install.sub's convention around ROOTDISK=sd0, ROOTDEV=sd0a and
> other disk/device code.
>
> Since it touches the installboot block, hoist it before the sysctl block
> which merely assigns `_plat'.
>
> A future diff then turns out much better.
> - dd if=$_mdec/u-boot-sunxi-with-spl.bin of=${_disk}c \
> + dd if=$_mdec/u-boot-sunxi-with-spl.bin of=/dev/${_disk}c \
Just noticed that this should use the raw device as done elsewhere across
distrib/ and explained in INSTALL.* docs.
Easily missed before the diff, obvious with it.
OK?
Index: ramdisk/install.md
===
RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
retrieving revision 1.37
diff -u -p -r1.37 install.md
--- ramdisk/install.md 25 Mar 2023 18:29:37 - 1.37
+++ ramdisk/install.md 25 Mar 2023 19:06:43 -
@@ -36,7 +36,13 @@ NCPU=$(sysctl -n hw.ncpufound)
MOUNT_ARGS_msdos="-o-l"
md_installboot() {
- local _disk=/dev/$1 _mdec _plat
+ local _disk=$1 _mdec _plat
+
+ if ! installboot -r /mnt $_disk; then
+ echo "\nFailed to install bootblocks."
+ echo "You will not be able to boot OpenBSD from ${_disk}."
+ exit
+ fi
case $(sysctl -n machdep.compatible) in
apple,*)_plat=apple;;
@@ -44,12 +50,6 @@ md_installboot() {
raspberrypi,*) _plat=rpi;
esac
- if ! installboot -r /mnt ${1}; then
- echo "\nFailed to install bootblocks."
- echo "You will not be able to boot OpenBSD from ${1}."
- exit
- fi
-
# Apply some final tweaks on selected platforms
_mdec=/usr/mdec/$_plat
@@ -65,11 +65,11 @@ md_installboot() {
fi
;;
pine64)
- dd if=$_mdec/u-boot-sunxi-with-spl.bin of=${_disk}c \
+ dd if=$_mdec/u-boot-sunxi-with-spl.bin of=/dev/r${_disk}c \
bs=1024 seek=8 status=none
;;
rpi)
- mount ${MOUNT_ARGS_msdos} ${_disk}i /mnt/mnt
+ mount ${MOUNT_ARGS_msdos} /dev/${_disk}i /mnt/mnt
cp $_mdec/{bootcode.bin,start*.elf,fixup*.dat,*.dtb} /mnt/mnt/
cp $_mdec/u-boot.bin /mnt/mnt/
mkdir -p /mnt/mnt/overlays
installer: arm64: better disk variable handling
Call the function argument `_disk' and construct full device paths where
needed, so that other code can reuse the mnemonic variable.
This matches install.sub's convention around ROOTDISK=sd0, ROOTDEV=sd0a and
other disk/device code.
Since it touches the installboot block, hoist it before the sysctl block
which merely assigns `_plat'.
A future diff then turns out much better.
OK?
Index: ramdisk/install.md
===
RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
retrieving revision 1.37
diff -u -p -r1.37 install.md
--- ramdisk/install.md 25 Mar 2023 18:29:37 - 1.37
+++ ramdisk/install.md 25 Mar 2023 18:50:27 -
@@ -36,7 +36,13 @@ NCPU=$(sysctl -n hw.ncpufound)
MOUNT_ARGS_msdos="-o-l"
md_installboot() {
- local _disk=/dev/$1 _mdec _plat
+ local _disk=$1 _mdec _plat
+
+ if ! installboot -r /mnt $_disk; then
+ echo "\nFailed to install bootblocks."
+ echo "You will not be able to boot OpenBSD from ${_disk}."
+ exit
+ fi
case $(sysctl -n machdep.compatible) in
apple,*)_plat=apple;;
@@ -44,12 +50,6 @@ md_installboot() {
raspberrypi,*) _plat=rpi;
esac
- if ! installboot -r /mnt ${1}; then
- echo "\nFailed to install bootblocks."
- echo "You will not be able to boot OpenBSD from ${1}."
- exit
- fi
-
# Apply some final tweaks on selected platforms
_mdec=/usr/mdec/$_plat
@@ -65,11 +65,11 @@ md_installboot() {
fi
;;
pine64)
- dd if=$_mdec/u-boot-sunxi-with-spl.bin of=${_disk}c \
+ dd if=$_mdec/u-boot-sunxi-with-spl.bin of=/dev/${_disk}c \
bs=1024 seek=8 status=none
;;
rpi)
- mount ${MOUNT_ARGS_msdos} ${_disk}i /mnt/mnt
+ mount ${MOUNT_ARGS_msdos} /dev/${_disk}i /mnt/mnt
cp $_mdec/{bootcode.bin,start*.elf,fixup*.dat,*.dtb} /mnt/mnt/
cp $_mdec/u-boot.bin /mnt/mnt/
mkdir -p /mnt/mnt/overlays
installer: apple arm64: simplify firmware copy
Less duplicate code, simpler to cope with newer firmware.
Same idiom is used in install.sub already.
OK?
Index: ramdisk/install.md
===
RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
retrieving revision 1.37
diff -u -p -r1.37 install.md
--- ramdisk/install.md 25 Mar 2023 18:29:37 - 1.37
+++ ramdisk/install.md 25 Mar 2023 18:35:52 -
@@ -55,14 +55,9 @@ md_installboot() {
case $_plat in
apple)
- if [[ -d /etc/firmware/apple ]]; then
- (cd /etc/firmware
- pax -rw apple /mnt/etc/firmware)
- fi
- if [[ -d /etc/firmware/apple-bwfm ]]; then
- (cd /etc/firmware
- pax -rw apple-bwfm /mnt/etc/firmware)
- fi
+ (cd /etc/firmware; for _dir in apple{,-bwfm}; do
+ [[ -d $_dir ]] && pax -rw $_dir /mnt/etc/firmware
+ done)
;;
pine64)
dd if=$_mdec/u-boot-sunxi-with-spl.bin of=${_disk}c \
Re: installer: simplify MAKEDEV invocation
On Sat, Mar 25, 2023 at 04:17:06PM +, Klemens Nanni wrote:
> The script takes multiple arguments and loops over them on its own,
> so no reason to handroll the loop.
>
> OK?
This makes sense to me. I wonder if MAKEDEV changed to allow multiple
arguments or if the original author didn't realize it.
> In case anyone wonders why explicit devices are passed while "all" is used:
> it only creates that many devices, so if during install you created,
> e.g. sd14, that won't be covered by "all", hence passing explicit devices.
>
> Index: install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.1234
> diff -u -p -r1.1234 install.sub
> --- install.sub 10 Mar 2023 10:33:40 - 1.1234
> +++ install.sub 14 Mar 2023 16:47:32 -
> @@ -2931,13 +2931,9 @@ finish_up() {
> fi
>
> echo -n "Making all device nodes..."
> - (cd /mnt/dev; sh MAKEDEV all
> - # Make sure any devices we found during probe are created in the
> - # installed system.
> - for _dev in $(get_dkdevs) $(get_cddevs); do
> - sh MAKEDEV $_dev
> - done
> - )
> + # Make sure any devices we found during probe are created in the
> + # installed system.
> + (cd /mnt/dev; sh MAKEDEV $(get_dkdevs) $(get_cddevs) all)
> echo " done."
>
> # We may run some programs in chroot, and some of them might be
>
Re: timer(4/sparc64): remove driver
On Fri, Mar 24, 2023 at 09:56:55AM +0100, Claudio Jeker wrote: > On Thu, Mar 23, 2023 at 05:37:05PM -0500, Scott Cheloha wrote: > > On Sat, Mar 18, 2023 at 12:17:33PM -0600, Ted Bullock wrote: > > > On 2023-03-17 12:29 p.m., Mike Larkin wrote: > > > > On Thu, Mar 16, 2023 at 12:25:15PM -0500, Scott Cheloha wrote: > > > >> This code has been dead since we switched sparc64 to clockintr several > > > >> months ago. Nobody has come forward asking for a timer(4/sparc64) > > > >> intrclock. > > > >> > > > >> As of now, you need %TICK_CMPR or %STICK_CMPR to run OpenBSD on > > > >> sparc64. The only machines maybe lacking these registers are certain > > > >> early HAL/Fujitsu models like SPARC64 I and II, and maybe SPARC64 III. > > > >> > > > >> We can remove the driver now or wait until after unlock. > > > >> > > > >> The driver implementation is mixed into sparc64/clock.c. I think I > > > >> got everything, but I'm not positive. > > > > > > > > I would just wait until after unlock. ok mlarkin for removing dead code > > > > once unlock happens. > > > > > > Is that specific to Fujitsu variants of Sparc64 or will that hit Sun > > > variants too? I use the sunblade 100, which uses has a IIe I think but > > > this one is a sun branded chip as far as I'm aware. > > > > Your SunBlade 100 is unaffected by this change. > > > > All Sun/Oracle SPARC V9 CPUs ever shipped have ASR23 (%TICK_CMPR). > > Starting with the UltaSPARC IIe, they all also have the %STICK and > > %STICK_CMPR registers. > > > > The only machines that maybe don't have %TICK_CMPR, and are possibly > > already broken by changes I made months ago, are the first HAL CPUs: > > SPARC64 I and II. I can't be sure because I can't find documentation > > for those specific CPUs online. > > > > The HAL SPARC64 III and all later HAL/Fujitsu CPUs have ASR23 (dubbed > > %TICK_MATCH in the early HAL docs), so all those CPUs are unaffected, > > too. > > HAL SPARC64 I - III are currently not supported. The TLB and IIRC cache > handling is different. Wonderful! Nothing to worry about then. Removing this driver impacts no supported CPUs.
installer: pine64: better firmware dd
We must not throw away all errors, dd(1) can be silenced properly.
OK?
I don't have the hardware to test, but will need to tweak this MD code soon
for get softraid installs working on those boards.
Index: ramdisk/install.md
===
RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
retrieving revision 1.36
diff -u -p -r1.36 install.md
--- ramdisk/install.md 6 Feb 2023 08:41:00 - 1.36
+++ ramdisk/install.md 25 Mar 2023 16:28:50 -
@@ -66,7 +66,7 @@ md_installboot() {
;;
pine64)
dd if=$_mdec/u-boot-sunxi-with-spl.bin of=${_disk}c \
- bs=1024 seek=8 >/dev/null 2>&1
+ bs=1024 seek=8 status=none
;;
rpi)
mount ${MOUNT_ARGS_msdos} ${_disk}i /mnt/mnt
installer: simplify MAKEDEV invocation
The script takes multiple arguments and loops over them on its own,
so no reason to handroll the loop.
OK?
In case anyone wonders why explicit devices are passed while "all" is used:
it only creates that many devices, so if during install you created,
e.g. sd14, that won't be covered by "all", hence passing explicit devices.
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1234
diff -u -p -r1.1234 install.sub
--- install.sub 10 Mar 2023 10:33:40 - 1.1234
+++ install.sub 14 Mar 2023 16:47:32 -
@@ -2931,13 +2931,9 @@ finish_up() {
fi
echo -n "Making all device nodes..."
- (cd /mnt/dev; sh MAKEDEV all
- # Make sure any devices we found during probe are created in the
- # installed system.
- for _dev in $(get_dkdevs) $(get_cddevs); do
- sh MAKEDEV $_dev
- done
- )
+ # Make sure any devices we found during probe are created in the
+ # installed system.
+ (cd /mnt/dev; sh MAKEDEV $(get_dkdevs) $(get_cddevs) all)
echo " done."
# We may run some programs in chroot, and some of them might be
