Re: touchpad input driver: testing needed
On Mon, Jul 31, 2017 at 11:02:28PM +0200, Ulf Brosziewski wrote: > > If you have a new snapshot (from July 27 or later) on a laptop with a > Synaptics, Apple, Alps, or Elantech-4 touchpad, you could help with > tests, more tests, and tests. In order to activate the driver, add the Hi, I'm using an August 3 snapshot on an asus x205ta where the touchpad never worked really well. It's an elantech touchpad detected as HID over I2C bus, through the ims driver. Partial dmesg: dwiic4 at acpi0: I2C4 addr 0x9092c000/0x1000 irq 35 iic3 at dwiic4 ihidev1 at iic3 addr 0x15 irq 72, vendor 0x4f3 product 0x401, ELAN0100 ihidev1: 93 report ids ims0 at ihidev1 reportid 1: 2 buttons, Z dir wsmouse0 at ims0 mux 0 hid at ihidev1 reportid 11 not configured hid at ihidev1 reportid 12 not configured hid at ihidev1 reportid 13 not configured hid at ihidev1 reportid 93 not configured "ELAN0100" at acpi0 not configured "INTCFD9" at acpi0 not configured It's a a version 4 touchpad? Will tests on this hardware be of any help? Regargs, Michele Full dmesg: OpenBSD 6.1-current (GENERIC.MP) #44: Thu Aug 3 12:12:07 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 3f real mem = 2056572928 (1961MB) avail mem = 1987952640 (1895MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7c31a010 (16 entries) bios0: vendor American Megatrends Inc. version "X205TA.212" date 09/04/2015 bios0: ASUSTeK COMPUTER INC. X205TA acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP TCPA UEFI OEM0 DBG2 HPET LPIT APIC MCFG SSDT SSDT SSDT SSDT FPDT SSDT SSDT SSDT SSDT TPM2 BGRT CSRT MSDM acpi0: wakeup devices WLAN(S0) acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0 cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.58 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu0: 1MB 64b/line 16-way L2 cache cpu0: TSC frequency 1333579040 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 83MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu2: 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu3: 1MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 87 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiec0 at acpi0: not present acpicpu0 at acpi0 C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0 C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0 C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0 C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PLPE acpipwrres1 at acpi0: USBC, resource for XHC1, EHC1, OTG1 acpipwrres2 at acpi0: CLK0, resource for CAM1 acpipwrres3 at acpi0: CLK1, resource for CAM0 acpipwrres4 at acpi0: P28X acpipwrres5 at acpi0: P18X acpipwrres6 at acpi0: P28P acpipwrres7 at acpi0: P18P acpipwrres8 at acpi0: P28T, resource for CAM0, CAM1 acpipwrres9 at acpi0: P18T, resource for CAM0, CAM1 acpipwrres10 at acpi0: P1XT acpitz0 at acpi0: no critical temperature defined "INT3396" at acpi0 not configured bytgpio0 at acpi0: GPO2 uid 3 addr 0xfed0e000/0x
Re: Doubts about the successors of OpenBSD leadership and development
On Mon, Jul 10, 2017 at 11:16:36PM +0200, Stefan Sperling wrote: > On Mon, Jul 10, 2017 at 06:04:53PM -0300, SOUL_OF_ROOT 55 wrote: > > Who will succeed Theo de Raadt in the leadership and development of OpenBSD? > > Obviously, Theo de Raadt will succeed Theo de Raadt in the leadership and > development of OpenBSD: http://marc.info/?l=openbsd-misc&m=137609553004700&w=2 > Obviously a RAIT 1 (Redundant Array of Independent Theos). -- Michele
Re: OpenBSD 6.1: BOOTIA32 3.32 issue
On Sun, May 14, 2017 at 07:31:09PM +0900, YASUOKA Masahiko wrote:
> On Fri, 12 May 2017 16:15:52 +0200
>
> It seems the problem which had been fixed previous is happening again.
> Does efidev.c have following $OpenBSD$?
>
> /* $OpenBSD: efidev.c,v 1.25 2017/05/11 01:37:24 yasuoka Exp $ */
>
You are right, I wasn't following HEAD, so cvs update did not
retrieved the latest version.. Sorry for the trouble.
>
> Also let me update the diff.
Works for me :)
Thank you,
Michele
>
> diff --git a/sys/arch/amd64/stand/efiboot/efiboot.c
> b/sys/arch/amd64/stand/efiboot/efiboot.c
> index efa371f2ecd..19df6b1dc64 100644
> --- a/sys/arch/amd64/stand/efiboot/efiboot.c
> +++ b/sys/arch/amd64/stand/efiboot/efiboot.c
> @@ -52,7 +52,9 @@ static EFI_GUID blkio_guid = BLOCK_IO_PROTOCOL;
> static EFI_GUID devp_guid = DEVICE_PATH_PROTOCOL;
> u_longefi_loadaddr;
>
> -static intefi_device_path_cmp(EFI_DEVICE_PATH *, EFI_DEVICE_PATH *, int);
> +static intefi_device_path_depth(EFI_DEVICE_PATH *dp, int);
> +static intefi_device_path_ncmp(EFI_DEVICE_PATH *, EFI_DEVICE_PATH *,
> + int);
> static void efi_heap_init(void);
> static void efi_memprobe_internal(void);
> static void efi_video_init(void);
> @@ -159,7 +161,7 @@ struct disklist_lh efi_disklist;
> void
> efi_diskprobe(void)
> {
> - int i, bootdev;
> + int i, bootdev = 0, depth = -1;
> UINTNsz;
> EFI_STATUS status;
> EFI_HANDLE *handles = NULL;
> @@ -180,8 +182,10 @@ efi_diskprobe(void)
> if (handles == NULL || EFI_ERROR(status))
> panic("BS->LocateHandle() returns %d", status);
>
> + if (efi_bootdp != NULL)
> + depth = efi_device_path_depth(efi_bootdp, MEDIA_DEVICE_PATH);
> +
> for (i = 0; i < sz / sizeof(EFI_HANDLE); i++) {
> - bootdev = 0;
> status = EFI_CALL(BS->HandleProtocol, handles[i], &blkio_guid,
> (void **)&blkio);
> if (EFI_ERROR(status))
> @@ -193,53 +197,57 @@ efi_diskprobe(void)
> di = alloc(sizeof(struct diskinfo));
> efid_init(di, blkio);
>
> - if (efi_bootdp == NULL)
> + if (efi_bootdp == NULL || depth == -1 || bootdev != 0)
> goto next;
> status = EFI_CALL(BS->HandleProtocol, handles[i], &devp_guid,
> (void **)&dp);
> if (EFI_ERROR(status))
> goto next;
> - if (!efi_device_path_cmp(efi_bootdp, dp, HARDWARE_DEVICE_PATH)&&
> - !efi_device_path_cmp(efi_bootdp, dp, ACPI_DEVICE_PATH) &&
> - !efi_device_path_cmp(efi_bootdp, dp, MESSAGING_DEVICE_PATH))
> + if (efi_device_path_ncmp(efi_bootdp, dp, depth) == 0) {
> + TAILQ_INSERT_HEAD(&efi_disklist, di, list);
> bootdev = 1;
> + continue;
> + }
> next:
> - if (bootdev)
> - TAILQ_INSERT_HEAD(&efi_disklist, di, list);
> - else
> - TAILQ_INSERT_TAIL(&efi_disklist, di, list);
> + TAILQ_INSERT_TAIL(&efi_disklist, di, list);
> }
>
> free(handles, sz);
> }
>
> static int
> -efi_device_path_cmp(EFI_DEVICE_PATH *dpa, EFI_DEVICE_PATH *dpb, int dptype)
> +efi_device_path_depth(EFI_DEVICE_PATH *dp, int dptype)
> {
> - int cmp;
> - EFI_DEVICE_PATH *dp, *dpt_a = NULL, *dpt_b = NULL;
> + int i;
>
> - for (dp = dpa; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
> - if (DevicePathType(dp) == dptype) {
> - dpt_a = dp;
> - break;
> - }
> - }
> - for (dp = dpb; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
> - if (DevicePathType(dp) == dptype) {
> - dpt_b = dp;
> - break;
> - }
> + for (i = 0; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp), i++) {
> + if (DevicePathType(dp) == dptype)
> + return (i);
> }
>
> - if (dpt_a && dpt_b) {
> - cmp = DevicePathNodeLength(dpt_a) - DevicePathNodeLength(dpt_b);
> + return (-1);
> +}
> +
> +static int
> +efi_device_path_ncmp(EFI_DEVICE_PATH *dpa, EFI_DEVICE_PATH *dpb, int deptn)
> +{
> + int i, cmp;
> +
> + for (i = 0; i < deptn; i++) {
> + if (IsDevicePathEnd(dpa) || IsDevicePathEnd(dpb))
> + return ((IsDevicePathEnd(dpa) && IsDevicePathEnd(dpb))
> + ? 0 : (IsDevicePathEnd(dpa))? -1 : 1);
> + cmp = DevicePathNodeLength(dpa) - DevicePathNodeLength(dpb);
> + if (cmp)
> + return (cmp);
> + cmp = memcmp(dpa, dpb, DevicePathNodeLength(dpa));
>
Re: OpenBSD 6.1: BOOTIA32 3.32 issue
On Fri, May 12, 2017 at 06:01:35PM +0900, YASUOKA Masahiko wrote: > > > And something like this? > > Yes. What we need to do is comparing the device path node before > MEDIA_DEVICE_PATH type. So I rewrote it like > > media_idx = device_path_index(rootdp, MEDIA_DEVICE_PATH); > for (...) > if (device_path_ncmp(rootdp, dp, media_idx) == 0) >bootdev = 1; > > ok? comment? > The device order is correct, the laptop boots without problems, but executing "machine diskinfo" prints a source file now.. https://www.youtube.com/watch?v=EUao9Fq5Bww It seems gnu/llvm/lib/Target/Mips/AsmParser/MipsAsmParser.cpp Michele
Re: OpenBSD 6.1: BOOTIA32 3.32 issue
On Fri, May 12, 2017 at 07:27:45AM +0200, Michele Curti wrote:
>
> The efi_device_path_cmp() compares only a path node.
> I tried the following diff just to see if I undestood something,
> hd0 is now set corrctly to the 29GB disk.
>
>
> Index: efiboot/efiboot.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 efiboot.c
> --- efiboot/efiboot.c 3 Mar 2017 08:56:18 - 1.17
> +++ efiboot/efiboot.c 12 May 2017 05:23:21 -
> @@ -233,10 +233,21 @@ efi_device_path_cmp(EFI_DEVICE_PATH *dpa
> }
>
> if (dpt_a && dpt_b) {
> - cmp = DevicePathNodeLength(dpt_a) - DevicePathNodeLength(dpt_b);
> - if (cmp)
> - return (cmp);
> - return (memcmp(dpt_a, dpt_b, DevicePathNodeLength(dpt_a)));
> + for (;!IsDevicePathEnd(dpt_a);) {
> + cmp = DevicePathNodeLength(dpt_a) -
> DevicePathNodeLength(dpt_b);
> + if (cmp)
> + return (cmp);
> + cmp = memcmp(dpt_a, dpt_b, DevicePathNodeLength(dpt_a));
> + if (cmp)
> + return (cmp);
> + dpt_a = NextDevicePathNode(dpt_a);
> + dpt_b = NextDevicePathNode(dpt_b);
> + cmp = IsDevicePathEnd(dpt_a) - IsDevicePathEnd(dpt_b);
> + if (cmp)
> + return (cmp);
> + }
> +
> + return 0;
> }
>
> return ((uintptr_t)dpt_a - (uintptr_t)dpt_b);
And something like this?
Index: efiboot/efiboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.17
diff -u -p -r1.17 efiboot.c
--- efiboot/efiboot.c 3 Mar 2017 08:56:18 - 1.17
+++ efiboot/efiboot.c 12 May 2017 07:02:10 -
@@ -52,7 +52,7 @@ static EFI_GUIDblkio_guid = BLOCK_IO_
static EFI_GUID devp_guid = DEVICE_PATH_PROTOCOL;
u_long efi_loadaddr;
-static int efi_device_path_cmp(EFI_DEVICE_PATH *, EFI_DEVICE_PATH *, int);
+static int efi_device_path_cmp(EFI_DEVICE_PATH *, EFI_DEVICE_PATH *);
static void efi_heap_init(void);
static void efi_memprobe_internal(void);
static void efi_video_init(void);
@@ -199,9 +199,7 @@ efi_diskprobe(void)
(void **)&dp);
if (EFI_ERROR(status))
goto next;
- if (!efi_device_path_cmp(efi_bootdp, dp, HARDWARE_DEVICE_PATH)&&
- !efi_device_path_cmp(efi_bootdp, dp, ACPI_DEVICE_PATH) &&
- !efi_device_path_cmp(efi_bootdp, dp, MESSAGING_DEVICE_PATH))
+ if (efi_device_path_cmp(efi_bootdp, dp) == 0)
bootdev = 1;
next:
if (bootdev)
@@ -214,32 +212,29 @@ next:
}
static int
-efi_device_path_cmp(EFI_DEVICE_PATH *dpa, EFI_DEVICE_PATH *dpb, int dptype)
+efi_device_path_cmp(EFI_DEVICE_PATH *dpa, EFI_DEVICE_PATH *dpb)
{
- int cmp;
- EFI_DEVICE_PATH *dp, *dpt_a = NULL, *dpt_b = NULL;
+ int cmp;
- for (dp = dpa; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
- if (DevicePathType(dp) == dptype) {
- dpt_a = dp;
- break;
- }
- }
- for (dp = dpb; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
- if (DevicePathType(dp) == dptype) {
- dpt_b = dp;
- break;
- }
- }
-
- if (dpt_a && dpt_b) {
- cmp = DevicePathNodeLength(dpt_a) - DevicePathNodeLength(dpt_b);
- if (cmp)
- return (cmp);
- return (memcmp(dpt_a, dpt_b, DevicePathNodeLength(dpt_a)));
- }
+ cmp = IsDevicePathEnd(dpa) - IsDevicePathEnd(dpb);
+ if (cmp)
+ return cmp;
+ if (IsDevicePathEnd(dpa))
+ return 0;
+ cmp = DevicePathType(dpa) - DevicePathType(dpb);
+ if (cmp)
+ return cmp;
+ cmp = DevicePathSubType(dpa) - DevicePathSubType(dpb);
+ if (cmp)
+ return cmp;
+ cmp = DevicePathNodeLength(dpa) - DevicePathNodeLength(dpb);
+ if (cmp)
+ return cmp;
+ cmp = memcmp(dpa, dpb, DevicePathNodeLength(dpa));
+ if (cmp)
+ return cmp;
- return ((uintptr_t)dpt_a - (uintptr_t)dpt_b);
+ return efi_device_path_cmp(NextDevicePathNode(dpa),
NextDevicePathNode(dpb));
}
/***
Re: OpenBSD 6.1: BOOTIA32 3.32 issue
On Fri, May 12, 2017 at 11:05:13AM +0900, YASUOKA Masahiko wrote:
> On Thu, 11 May 2017 23:45:17 +0200
> Michele Curti wrote:
>
> All disks are identical in HARDWARE_DEVICE_PATH and ACPI_DEVICE_PATH
> and they all don't have MESSAGING_DEVICE_PATH. So the boot loader
> mistakenly treats all of them as the bootdisk..
>
> I'd like to know whether there is a way to distigish those disks. Can
> you try the diff following?
>
> diff --git a/sys/arch/amd64/stand/efiboot/efiboot.c
> b/sys/arch/amd64/stand/efiboot/efiboot.c
> index efa371f2ecd..891b6c75cc9 100644
> --- a/sys/arch/amd64/stand/efiboot/efiboot.c
> +++ b/sys/arch/amd64/stand/efiboot/efiboot.c
> @@ -208,6 +208,14 @@ next:
> TAILQ_INSERT_HEAD(&efi_disklist, di, list);
> else
> TAILQ_INSERT_TAIL(&efi_disklist, di, list);
> +
> + printf("%d\n", i);
> + for (; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
> + int ii;
> + for (ii = 0; ii < DevicePathNodeLength(dp); ii++)
> + printf("%x ", *((u_char *)dp + ii));
> + printf("\n");
> + }
> }
>
> free(handles, sz);
>
0
2 1 c 0 d0 41 3 a 0 0 0 0
1 1 6 0 0 17
1 5 8 0 0 0 0 0
1
2 1 c 0 d0 41 3 a 0 0 0 0
1 1 6 0 0 17
1 5 8 0 1 0 0 0
2
2 1 c 0 d0 41 3 a 0 0 0 0
1 1 6 0 0 17
1 5 8 0 2 0 0 0
The efi_device_path_cmp() compares only a path node.
I tried the following diff just to see if I undestood something,
hd0 is now set corrctly to the 29GB disk.
Index: efiboot/efiboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.17
diff -u -p -r1.17 efiboot.c
--- efiboot/efiboot.c 3 Mar 2017 08:56:18 - 1.17
+++ efiboot/efiboot.c 12 May 2017 05:23:21 -
@@ -233,10 +233,21 @@ efi_device_path_cmp(EFI_DEVICE_PATH *dpa
}
if (dpt_a && dpt_b) {
- cmp = DevicePathNodeLength(dpt_a) - DevicePathNodeLength(dpt_b);
- if (cmp)
- return (cmp);
- return (memcmp(dpt_a, dpt_b, DevicePathNodeLength(dpt_a)));
+ for (;!IsDevicePathEnd(dpt_a);) {
+ cmp = DevicePathNodeLength(dpt_a) -
DevicePathNodeLength(dpt_b);
+ if (cmp)
+ return (cmp);
+ cmp = memcmp(dpt_a, dpt_b, DevicePathNodeLength(dpt_a));
+ if (cmp)
+ return (cmp);
+ dpt_a = NextDevicePathNode(dpt_a);
+ dpt_b = NextDevicePathNode(dpt_b);
+ cmp = IsDevicePathEnd(dpt_a) - IsDevicePathEnd(dpt_b);
+ if (cmp)
+ return (cmp);
+ }
+
+ return 0;
}
return ((uintptr_t)dpt_a - (uintptr_t)dpt_b);
Re: OpenBSD 6.1: BOOTIA32 3.32 issue
On Wed, May 10, 2017 at 08:35:28PM +0200, Patrick Wildt wrote:
>
> I don't think this is the correct fix. It might solve your issue, but I
> don't think it's completely right. So EFI has those so called device
> paths. A path is basically a list of nodes. To compare two paths you
> need to compare the whole path and not just a single node of it. If you
> store dp instead of dp0 you will basically only save a part of the path,
> not the full path.
>
> What you can do is print the full path of efi_bootdp like..
>
> for (dp = efi_bootdp; !IsDevicePathEnd(dp);
> dp = NextDevicePathNode(dp)) {
> printf("%x %x - ", DevicePathType(dp), DevicePathSubType(dp));
> }
> printf("\n");
>
> And do the same for the DPs that are being put into the
> efi_device_path_cmp function. That will at least print the types, but
> not the content of the nodes. That's a start into figuring out why it
> does not correctly compare the paths.
>
> Maybe there's a bug in the compare code?
Sorry, only now I understood what you said... Got
2 1 - 1 1 - 1 5 - 4 1 -
(2 1) (2 1) da db cmp da db cmp diff bootdev 1
(2 1) (2 1) da db cmp da db cmp diff bootdev 1
(2 1) (2 1) da db cmp da db cmp diff bootdev 1
with the following diff
Index: efiboot/efiboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.17
diff -u -p -r1.17 efiboot.c
--- efiboot/efiboot.c 3 Mar 2017 08:56:18 - 1.17
+++ efiboot/efiboot.c 11 May 2017 21:39:14 -
@@ -89,6 +89,8 @@ efi_main(EFI_HANDLE image, EFI_SYSTEM_TA
if (status == EFI_SUCCESS) {
for (dp = dp0; !IsDevicePathEnd(dp);
dp = NextDevicePathNode(dp)) {
+ printf("%x %x - ", DevicePathType(dp),
+ DevicePathSubType(dp));
if (DevicePathType(dp) == MEDIA_DEVICE_PATH &&
DevicePathSubType(dp) == MEDIA_HARDDRIVE_DP) {
bios_bootdev = 0x80;
@@ -96,6 +98,7 @@ efi_main(EFI_HANDLE image, EFI_SYSTEM_TA
break;
}
}
+ printf("\n");
}
#ifdef __amd64__
@@ -199,10 +202,18 @@ efi_diskprobe(void)
(void **)&dp);
if (EFI_ERROR(status))
goto next;
+ printf("(%x %x) (%x %x) ",
+ DevicePathType(efi_bootdp),
+ DevicePathSubType(efi_bootdp),
+ DevicePathType(dp),
+ DevicePathSubType(dp)
+ );
if (!efi_device_path_cmp(efi_bootdp, dp, HARDWARE_DEVICE_PATH)&&
!efi_device_path_cmp(efi_bootdp, dp, ACPI_DEVICE_PATH) &&
!efi_device_path_cmp(efi_bootdp, dp, MESSAGING_DEVICE_PATH))
bootdev = 1;
+
+ printf("bootdev %d\n", bootdev);
next:
if (bootdev)
TAILQ_INSERT_HEAD(&efi_disklist, di, list);
@@ -222,12 +233,14 @@ efi_device_path_cmp(EFI_DEVICE_PATH *dpa
for (dp = dpa; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
if (DevicePathType(dp) == dptype) {
dpt_a = dp;
+ printf("da ");
break;
}
}
for (dp = dpb; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
if (DevicePathType(dp) == dptype) {
dpt_b = dp;
+ printf("db ");
break;
}
}
@@ -236,8 +249,11 @@ efi_device_path_cmp(EFI_DEVICE_PATH *dpa
cmp = DevicePathNodeLength(dpt_a) - DevicePathNodeLength(dpt_b);
if (cmp)
return (cmp);
+ printf("cmp ");
return (memcmp(dpt_a, dpt_b, DevicePathNodeLength(dpt_a)));
}
+
+ printf("diff ");
return ((uintptr_t)dpt_a - (uintptr_t)dpt_b);
}
Re: OpenBSD 6.1: BOOTIA32 3.32 issue
On Thu, May 11, 2017 at 05:48:34PM +0900, YASUOKA Masahiko wrote: > Hi, > > Thank you for your tests, > > On Thu, 11 May 2017 07:40:42 +0200 > ... > > So I can use the stock bootloader without changes but I must do a > > > > boot> set device hd2a > > I'm not clear whether we still have a problem. > > Does the boot loader select the booted disk as "hd0" correctly? > > If you booted from 29GB disk, "machine diskinfo" must be: > > DiskBlkSiz IoAlign SizeFlags Checksum > hd0 512 1 29GB0x2 0xad4a42c3 > hd1 512 1 4MB 0x0 0x0 > hd2 512 1 4MB 0x0 0x0 > There is still a problem because I booted from the 29GB disk, the bootloader selects hd0, but the machine diskinfo order is: DiskBlkSiz IoAlign SizeFlags Checksum hd0 512 1 4MB 0x0 0x0 hd1 512 1 4MB 0x0 0x0 hd2 512 1 29GB0x2 0xad4a42c3 I don't know if it is related but a problem is probably (efiboot.c, line 87) here: status = EFI_CALL(BS->HandleProtocol, imgp->DeviceHandle, &devp_guid, (void **)&dp0); where status is EFI_SUCCESS but dp0 remains NULL, so the following for loop loops through invalid device paths until a causal IsDevicePathEnd() true. I not sure of what I'm saying because I have not investigated yet, I have to read some EFI documentation first to understand what's happening. Thank you for the help, Michele > --yasuoka
Re: OpenBSD 6.1: BOOTIA32 3.32 issue
On Wed, May 10, 2017 at 08:35:28PM +0200, Patrick Wildt wrote: > On Wed, May 10, 2017 at 03:14:30PM +0200, Stefan Sperling wrote: > > On Tue, May 09, 2017 at 09:47:14PM +0200, Michele Curti wrote: > > > On Tue, May 09, 2017 at 09:36:02PM +0200, Michele Curti wrote: > > > > On Tue, May 09, 2017 at 10:20:03AM +0200, Michele Curti wrote: > > > > > Hi all, I tried to upgrade to OpenBSD 6.1 on an Asus X205TA (bay > > > > > trail, 32 bit efi, 64 bit os) but the bootloader do not correctly > > > > > detect the internal disk. > > > > > > > > > > I also tried a fresh install, but things do not change. Boot fails > > > > > and when I do a "machine diskinfo" I got a lot of "?" symbols (a video > > > > > here https://www.youtube.com/watch?v=fsomNX-oFTQ ) > > > > > Thanks to yasuoka fix I just noted that using dp0 instead of dp changes the diskinfo disks order # setting efi_bootdp = dp; DiskBlkSiz IoAlign SizeFlags Checksum hd0 512 1 29GB0x2 0xad4a42c3 hd1 512 1 4MB 0x0 0x0 hd2 512 1 4MB 0x0 0x0 # setting efi_bootdp = dp0; DiskBlkSiz IoAlign SizeFlags Checksum hd0 512 1 4MB 0x0 0x0 hd1 512 1 4MB 0x0 0x0 hd2 512 1 29GB0x2 0xad4a42c3 So I can use the stock bootloader without changes but I must do a boot> set device hd2a Do not know how much useful is this info... Michele
Re: OpenBSD 6.1: BOOTIA32 3.32 issue
On Thu, May 11, 2017 at 10:42:04AM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> On Tue, 9 May 2017 10:20:03 +0200
> Michele Curti wrote:
> > I also tried a fresh install, but things do not change.
> > Boot fails and when I do a "machine diskinfo" I got a lot of "?"
> > symbols (a video here https://www.youtube.com/watch?v=fsomNX-oFTQ )
>
> Hanging on "machine diskinfo" seems to be a different problem.
> The diff is already committed. Can you test this?
Yes, no more hangs, thank you!
boot> machine diskinfo
DiskBlkSiz IoAlign SizeFlags Checksum
hd0 512 1 4MB 0x0 0x0
hd1 512 1 4MB 0x0 0x0
hd2 512 1 29GB0x2 0xad4a42c3
Michele
>
> (I'll look into another problem later)
>
> Index: sys/arch/amd64/stand/efiboot/efidev.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efidev.c,v
> retrieving revision 1.24
> diff -u -p -r1.24 efidev.c
> --- sys/arch/amd64/stand/efiboot/efidev.c 24 Dec 2016 08:41:13 -
> 1.24
> +++ sys/arch/amd64/stand/efiboot/efidev.c 11 May 2017 01:31:13 -
> @@ -789,7 +789,7 @@ efi_dump_diskinfo(void)
> printf("hd%d\t%u\t%u\t%u%s\t0x%x\t0x%x\t%s\n",
> (bdi->bios_number & 0x7f),
> ed->blkio->Media->BlockSize,
> - ed->blkio->Media->IoAlign, siz, sizu,
> + ed->blkio->Media->IoAlign, (int)siz, sizu,
> bdi->flags, bdi->checksum,
> (ed->blkio->Media->RemovableMedia)? "Removable" : "");
> }
>
Re: OpenBSD 6.1: BOOTIA32 3.32 issue
On Wed, May 10, 2017 at 08:35:28PM +0200, Patrick Wildt wrote:
> On Wed, May 10, 2017 at 03:14:30PM +0200, Stefan Sperling wrote:
> > On Tue, May 09, 2017 at 09:47:14PM +0200, Michele Curti wrote:
> > > bios_bootdev = 0x80;
> > > - efi_bootdp = dp0;
> > > + efi_bootdp = dp;
> > > break;
> > > }
> > > }
> > >
> >
>
> I don't think this is the correct fix. It might solve your issue, but I
> don't think it's completely right. So EFI has those so called device
> paths. A path is basically a list of nodes. To compare two paths you
> need to compare the whole path and not just a single node of it. If you
> store dp instead of dp0 you will basically only save a part of the path,
> not the full path.
>
> What you can do is print the full path of efi_bootdp like..
>
> for (dp = efi_bootdp; !IsDevicePathEnd(dp);
> dp = NextDevicePathNode(dp)) {
> printf("%x %x - ", DevicePathType(dp), DevicePathSubType(dp));
> }
> printf("\n");
>
4e 6f - 5f 2d - 22 4e - 4e 55 - 3a 48 - 1e ce - and many others
I got the same values starting the for loop with dp = dp0 or dp = NULL
So dp0 was not intialized by the EFI_CALL() above?
if (status == EFI_SUCCESS)
status = EFI_CALL(BS->HandleProtocol, imgp->DeviceHandle,
&devp_guid, (void **)&dp0);
if (status == EFI_SUCCESS) {
I'm going to study a bit about EFI.. :p
Thanks,
Michele
> And do the same for the DPs that are being put into the
> efi_device_path_cmp function. That will at least print the types, but
> not the content of the nodes. That's a start into figuring out why it
> does not correctly compare the paths.
>
> Maybe there's a bug in the compare code?
Re: OpenBSD 6.1: BOOTIA32 3.32 issue
On Tue, May 09, 2017 at 09:36:02PM +0200, Michele Curti wrote:
> On Tue, May 09, 2017 at 10:20:03AM +0200, Michele Curti wrote:
> > Hi all, I tried to upgrade to OpenBSD 6.1 on an Asus X205TA (bay
> > trail, 32 bit efi, 64 bit os) but the bootloader do not correctly
> > detect the internal disk.
> >
> > I also tried a fresh install, but things do not change. Boot fails
> > and when I do a "machine diskinfo" I got a lot of "?" symbols (a video
> > here https://www.youtube.com/watch?v=fsomNX-oFTQ )
> >
> > How can I debug the issue?
> >
>
> Compiling bootia32.efi :p
>
> With sys/arch/amd64/stand/efiboot/efiboot.c revision 1.15 it works,
> revision 1.16 it fails.
>
> I'll try to understand, thanks, Michele
With the following diff it works, bye!
Index: efiboot/efiboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.17
diff -u -p -r1.17 efiboot.c
--- efiboot/efiboot.c 3 Mar 2017 08:56:18 - 1.17
+++ efiboot/efiboot.c 9 May 2017 19:44:30 -
@@ -92,7 +92,7 @@ efi_main(EFI_HANDLE image, EFI_SYSTEM_TA
if (DevicePathType(dp) == MEDIA_DEVICE_PATH &&
DevicePathSubType(dp) == MEDIA_HARDDRIVE_DP) {
bios_bootdev = 0x80;
- efi_bootdp = dp0;
+ efi_bootdp = dp;
break;
}
}
Re: OpenBSD 6.1: BOOTIA32 3.32 issue
On Tue, May 09, 2017 at 10:20:03AM +0200, Michele Curti wrote: > Hi all, > I tried to upgrade to OpenBSD 6.1 on an Asus X205TA (bay trail, 32 bit > efi, 64 bit os) but the bootloader do not correctly detect the internal > disk. > > I also tried a fresh install, but things do not change. > Boot fails and when I do a "machine diskinfo" I got a lot of "?" > symbols (a video here https://www.youtube.com/watch?v=fsomNX-oFTQ ) > > How can I debug the issue? > Compiling bootia32.efi :p With sys/arch/amd64/stand/efiboot/efiboot.c revision 1.15 it works, revision 1.16 it fails. I'll try to understand, thanks, Michele > Thanks, > Michele >
OpenBSD 6.1: BOOTIA32 3.32 issue
Hi all, I tried to upgrade to OpenBSD 6.1 on an Asus X205TA (bay trail, 32 bit efi, 64 bit os) but the bootloader do not correctly detect the internal disk. I also tried a fresh install, but things do not change. Boot fails and when I do a "machine diskinfo" I got a lot of "?" symbols (a video here https://www.youtube.com/watch?v=fsomNX-oFTQ ) How can I debug the issue? Thanks, Michele
