Re: [GSoC] Emulating missing Linux syscalls project questions

[Jared McNeill]

Hi Theodore --

The Linux Test Project (http://linux-test-project.github.io) would help 
not only with finding missing syscalls, but also with finding bugs / 
missing functionality in the existing Linux emul code. It would be nice to 
have this running on NetBSD.


Take care,
Jared


On Mon, 13 Mar 2023, Theodore Preduta wrote:

As the subject suggests, I think the emulating missing Linux syscalls project 
might be fun. I am just wondering


(1) Is there any documentation on the internals of this subsystem? (manpage 
and wiki seem to just be how to use it)


(2) Is there a better binary-finding strategy than trying Linux binaries on 
NetBSD, and if they fail (have a script) compare the output of strace from a 
Linux run of the program with the table in 
sys/compat/linux/arch/*/linux_syscalls.c?


(3) Do y'all have any suggestions for binaries? :P

(4) Most of the (failing) binaries I've found so far seem to have the epoll 
set of system calls in common, is there's some technical reason why that's 
not been implemented yet? (or it it just a matter of no one has done it yet)


Thanks in advance,

Theo(dore)

Re: kernel goes dark on boot

[Jared McNeill]

Yeah sorry you can’t just not exit boot services and boot the OS. UEFI code has 
certain expectations around the execution environment (MMU on, 1:1 PA to VA for 
example) that starting the kernel is going to interfere with. The moment the 
kernel touches the MMU, all of the resident UEFI code will cease to function. 
This includes code that may be running asynchronously (timers etc) that are not 
stopped properly due to the missing ExitBootServices call.

Sent from my iPhone

> On Feb 21, 2023, at 9:46 AM, Emmanuel Dreyfus  wrote:
> 
> On Tue, Feb 21, 2023 at 08:05:00AM -0400, Jared McNeill wrote:
>> After calling ExitBootServices(), the only things that work are UEFI runtime
>> services. You'll have to find another way to print to the console.
> 
> I can skip the ExitBootServices call and keep printing, I have already
> done thatn at least in C functions. I have no experience of doing that
> from assembly code.
> 
> The same bug exists with a XEN3_DOM0 kernel. Xen starts up, and the 
> kernel crash without displaying anything. I wonder if there are tools
> to trace the dom0 with help from Xen.
> 
> -- 
> Emmanuel Dreyfus
> m...@netbsd.org

Re: kernel goes dark on boot

[Jared McNeill]

After calling ExitBootServices(), the only things that work are UEFI 
runtime services. You'll have to find another way to print to the console.


On Mon, 20 Feb 2023, Emmanuel Dreyfus wrote:


On Wed, Jan 11, 2023 at 08:30:20AM +, Emmanuel Dreyfus wrote:

An interesting problem on an all-in-one HP PC. Booting
NetBSD-10.0_BETA/amd64 (or prior versions) works fine until the
kernel starts displaying its messages. At that point the screen
turns dark.


I patched bootx64.efi to comment out the vbe_commit() call,
the screen does not go dark, but system still crashes.

By commenting out the uefi_call_wrapper() for ExitBootServices
I can printf up to the startprog64() call, then the bootstrap
jump into assembly code, and it is much more difficult
to figure what is going on. All I can say is that startprog64()
arguments do not look insane.

I am looking for debug hints. Is there some sample code somewhere
that calls UEFI Print method from assembly? Any other suggestion?

--
Emmanuel Dreyfus
m...@netbsd.org

Re: Adding ESRT and EFI vars support for fwupd

[Jared McNeill]

Hi Paweł --

After introducing /dev/efi I ported libefi and efivar from FreeBSD, at 
least enough to work with EFI vars, but there were some things left to do 
-- notably, all of the logic to convert between EFI device paths and disks 
needs to be sorted out. No geom on NetBSD, and the current state of things 
is a bit of a mess IMHO, so I didn't get around to tackling it.


I think extending /dev/efi to support this feature is reasonable, and it 
makes sense to keep compatibility with the FreeBSD APIs here.


We have other platforms that use EFI today (armv7 and aarch64), with more 
in the pipeline (riscv) so whatever solution you come up with should be 
MI. So sys/dev/efi.c makes sense, probably with a new MD hook added to 
struct efi_ops.


I realize that this doesn't cover x86 today -- as far as I'm aware, the 
x86 based NetBSD ports don't support UEFI runtime services at all. But 
when they do, this is how support will be added.


Hope this helps, and feel free to reach out if you have any follow up 
questions.


Take care,
Jared


On Wed, 17 Aug 2022, Paweł Cichowski wrote:


Hello NetBSD devs,

Background
--

As some might know, FreeBSD gained an interface for querying ESRT about a 
year ago ([1], [2]), which was done as part of [3].


[1]: https://reviews.freebsd.org/rGd12d651f8692cfcaf6fd0a6e8264c29547f644c9
[2]: https://reviews.freebsd.org/rG24f398e7a153a05a7e94ae8dd623e2b6d28d94eb
[3]: https://nlnet.nl/project/fwdup-BSD/

Adding it allowed to make UEFI capsule plugin of fwupd [4] work for FreeBSD 
[5] to perform firmware updates on EFI systems.
Now it's turn for NetBSD and we would like to ask about requirements and 
recommendations on the API and its implementation such that they would be 
accepted by the upstream.


[4]: https://fwupd.org/
[5]: 
https://github.com/fwupd/fwupd/blob/main/plugins/uefi-capsule/fu-uefi-backend-freebsd.c


The same project is being done for OpenBSD as well [6]

[6]: https://www.mail-archive.com/tech@openbsd.org/msg70825.html

ESRT


The initial idea for accessing ESRT from userland is to use sysctl() like so:
```
void *esrt;
size_t esrt_len;
int mib[] = { CTL_HW, HW_ESRT };
esrt_len = 0;
if (sysctl(mib, 2, NULL, _len, NULL, 0) == -1 && errno != ENOMEM)
err(1, "sysctl");esrt = malloc(esrt_len);
if (esrt == NULL)
err(1, "malloc");
if (sysctl(mib, 2, esrt, _len, NULL, 0) == -1)
err(1, "sysctl");
```

However, FreeBSD decided in favour of ioctl() on /dev/efi.

The main question is - where should the implementation of ESRT tables go 
into?
Should it be generic and span multiple architectures, or should it be limited 
to for example only x86?


I found out that EFI is already handled by the x86 architecture, in 
`src/sys/arch/x86/x86/efi.c`. So, the implementation would probably go there 
or a new file in the same location, if the decision was to reduce the scope 
of this feature to a single arch.


EFI variables
-

I don't see an implementation of `efivar` or `efiboot` or anything similar, 
so it needs to be added and provide at least this API subset to be usable 
with fwupd:
* efi_append_variable() appends data of size to the variable specified by 
guid and name

* efi_del_variable() deletes the variable specified by guid and name
* efi_get_variable() gets variable's data_size, and its attributes are stored 
in attributes
* efi_get_variable_attributes() gets attributes for the variable specified by 
guid and name
* efi_get_variable_size() gets the size of the data for the variable 
specified by guid and name
* efi_get_next_variable_name() iterates across the currently extant 
variables, passing back a guid and name

* efi_guid_to_name() translates from an efi_guid_t to a well known name
* efi_guid_to_symbol() translates from an efi_guid_t to a unique (within 
libefivar) C-style symbol name
* efi_guid_to_str() allocates a suitable string and populates it with string 
representation of a UEFI GUID

* efi_name_to_guid() translates from a well known name to an efi_guid_t
* efi_set_variable() sets the variable specified by guid and name
* efi_str_to_guid() parses a UEFI GUID from string form to an efi_guid_t
* efi_variables_supported() checks if EFI variables are accessible
* efi_generate_file_device_path() generates an EFI file device path for an 
EFI binary from a filesystem path


Probably should be implemented as a minimal port of efivar [7] with 
sufficient functionality rather than a separate project. Either way, this too 
needs new kernel API for accessing EFI variables. Will sysctl() do or a new 
pseudo-device or is something else needed? Usage of existing implementations 
can be seen in FreeBSD [8] and Linux [9] (Linux uses sysfs for this). I also 
saw an implementation of a pseudo-driver which allows operations on EFI 
variables [10], which would suffice as an API, but unfortunately it wasn't 
merged yet. Could it be used in our case?


[7]: https://github.com/rhboot/efivar
[8]: 

Re: Intel GPIO

[Jared McNeill]

Hi Emmanuel --

I see a call to acpi_event_create_gpio but the callback doesn't do 
anything and the intr handler doesn't call acpi_event_notify. Can you wire 
the rest of that up? Should be pretty straight forward and you can use 
plgpio_acpi.c as an example.


Where I have seen this used, in practice, is for platforms that have their 
power button wired to a GPIO pin. The acpi_event framework is a way for 
the GPIO driver to notify firmware of the event, which in turn causes a 
button notification on the power button device.


Not the only use, but a common example.

Other than that LGTM.

Take care,
Jared


On Tue, 25 Jan 2022, Emmanuel Dreyfus wrote:


Hello

In order to get Goodix touchscreen working, I have been working on
Intel GPIO support, which I understand is required. Here is the
code so fat, inspired from Linux's drivers/pinctrl/intel:
ftp://ftp.netbsd.org/pub/NetBSD/misc/manu/igpio20220125.patch

I had very little success for now with the touchscreen, therefore I
am not even sure this code works. Is anyone in position to give it
a try in another setup? Should I commit it as experimental?

--
Emmanuel Dreyfus
m...@netbsd.org

Re: protect pmf from network drivers that don't provide if_stop

[Jared McNeill]

Not really a fan of this as it doesn't protect other potential if_stop 
users (and "temporary fix" rarely is..). How about something like this 
instead?



--- sys/net/if.c29 Jun 2021 21:19:58 -  1.486
+++ sys/net/if.c1 Jul 2021 09:46:10 -
@@ -761,11 +761,13 @@ void
 if_register(ifnet_t *ifp)
 {
/*
-* If the driver has not supplied its own if_ioctl, then
-* supply the default.
+* If the driver has not supplied its own if_ioctl or if_stop,
+* then supply the default.
 */
if (ifp->if_ioctl == NULL)
ifp->if_ioctl = ifioctl_common;
+   if (ifp->if_stop == NULL)
+   ifp->if_stop = if_nullstop;

sysctl_sndq_setup(>if_sysctl_log, ifp->if_xname, >if_snd);



On Tue, 29 Jun 2021, Brett Lymn wrote:



Folks,

I turned up a fix I had put into my source tree a while back, I think at
the time the wireless driver (urtwn IIRC) did not set an entry for
if_stop.  This resulted in a kernel panic if you tried to sleep the
machine pmf_class_network_suspend would try to call a null if_stop.

I crafted the following to preserve my sanity, ok to commit?


Index: kern_pmf.c
===
RCS file: /cvsroot/src/sys/kern/kern_pmf.c,v
retrieving revision 1.45
diff -u -r1.45 kern_pmf.c
--- kern_pmf.c  11 Jun 2020 02:30:21 -  1.45
+++ kern_pmf.c  29 Jun 2021 01:27:01 -
@@ -892,11 +892,18 @@
struct ifnet *ifp = device_pmf_class_private(dev);
int s;

-   s = splnet();
-   IFNET_LOCK(ifp);
-   (*ifp->if_stop)(ifp, 0);
-   IFNET_UNLOCK(ifp);
-   splx(s);
+   if (ifp == NULL)
+   return true;
+
+   if ((*ifp->if_stop) == NULL)
+   printf("device %s has no if_stop\n", ifp->if_xname);
+   else {
+   s = splnet();
+   IFNET_LOCK(ifp);
+   (*ifp->if_stop)(ifp, 0);
+   IFNET_UNLOCK(ifp);
+   splx(s);
+   }

return true;
}

--
Brett Lymn
--
Sent from my NetBSD device.

"We are were wolves",
"You mean werewolves?",
"No we were wolves, now we are something else entirely",
"Oh"

Re: usb: does USBMALLOC_ZERO work correctly?

[Jared McNeill]

Good catch! I've committed a slightly modified version of your patch.

Take care,
Jared


On Thu, 27 May 2021, sc.dy...@gmail.com wrote:


hi,

sometimes memories allocated by usb_allocmem with USBMALLOC_ZERO
are not cleared.
usb_block_allocmem, called from usb_allocmem, returns with valid dmap
if it has found a block in usb_blk_freelist. In that path memset is not done.


--- src/sys/dev/usb/usb_mem.c.orig  2021-01-05 22:12:39.913414469 +
+++ src/sys/dev/usb/usb_mem.c   2021-05-27 01:36:53.189148366 +
@@ -135,6 +135,11 @@ usb_block_allocmem(bus_dma_tag_t tag, si
usb_blk_nfree--;
*dmap = b;
DPRINTFN(6, "free list size=%ju", b->size, 0, 0, 0);
+   if ((flags & USBMALLOC_ZERO) != 0) {
+   memset(b->kaddr, 0, b->size);
+   bus_dmamap_sync(b->tag, b->map, 0, b->size,
+   BUS_DMASYNC_PREWRITE);
+   }
return 0;
}
}

panic with 'vmstat -e' on -current kernel with 9.1 userland

[Jared McNeill]

I hit this panic (repeatable 100%) trying to run 'vmstat -e' with a 
-current kernel and 9.1 userland:


[  78.872] panic: Trap: Data Abort (EL1): Translation Fault L1 with read 
access for , PAN Set: pc c0806d68: ldrb w2, [x1]

[  78.8104731] cpu0: Begin traceback...
[  78.8104731] trace fp c0004c767720
[  78.8104731] fp c0004c767750 vpanic() at c04e3b0c 
netbsd:vpanic+0x14c
[  78.8104731] fp c0004c7677b0 panic() at c04e3c04 netbsd:panic+0x44
[  78.8104731] fp c0004c767840 data_abort_handler() at c0090d8c 
netbsd:data_abort_handler+0x1ec
[  78.8104731] tf c0004c7678b0 el1_trap() at c0092784 
netbsd:el1_trap
[  78.8104731]  trapframe 0xc0004c7678b0 (304 bytes) 
[  78.8104731] pc=c0806d68,   spsr=6045
[  78.8104731]esr=9605,far=
[  78.8104731] x0=5de9a11c, x1=
[  78.8104731] x2=5de9a11c, x3=0003
[  78.8206028] x4=000f, x5=
[  78.8206028] x6=, x7=002f
[  78.8206028] x8=5b3b6400, x9=0001
[  78.8206028]x10=5593f900,x11=003f
[  78.8206028]x12=fc000177a684,x13=fc000177a68c
[  78.8206028]x14=03bd,x15=5de9a320
[  78.8206028]x16=f27a428708b0,x17=f27a428089e4
[  78.8206028]x18=,x19=000b
[  78.8206028]x20=,x21=09a0
[  78.8206028]x22=08a0,x23=f27a42ab8970
[  78.8206028]x24=c11a9780,x25=0001
[  78.8206028]x26=c37baaf0,x27=0030
[  78.8206028]x28=5de9a100, fp=x29=c0004c767be0
[  78.8305824] lr=x30=c04d0da8, sp=c0004c767be0
[  78.8305824] 
[  78.8305824] fp c0004c767be0 strcpy() at c0806d68 
netbsd:strcpy+0x8
[  78.8305824] fp c0004c767c00 sysctl_doevcnt() at c04d0da4 
netbsd:sysctl_doevcnt+0x13c
[  78.8305824] fp c0004c767cc0 sysctl_dispatch() at c04b6ff4 
netbsd:sysctl_dispatch+0xb4
[  78.8305824] fp c0004c767d30 sys___sysctl() at c04b7248 
netbsd:sys___sysctl+0xb0
[  78.8305824] fp c0004c767db0 syscall() at c008ed94 
netbsd:syscall+0x18c
[  78.8305824] fp c0004c767e60 trap_el0_sync() at c0090240 
netbsd:trap_el0_sync+0x378
[  78.8407101] tf c0004c767ed0 el0_trap() at c00927f0 
netbsd:el0_trap
[  78.8407101]  trapframe 0xc0004c767ed0 (304 bytes) 
[  78.8407101] pc=f27a428089e8,   spsr=8000
[  78.8407101]esr=56ca,far=f27a4273ca10
[  78.8407101] x0=ffbfb440, x1=0004
[  78.8407101] x2=f27a42ab8000, x3=ffbfb540
[  78.8407101] x4=, x5=
[  78.8407101] x6=2220, x7=0001
[  78.8407101] x8=f27a42885e40, x9=03e4
[  78.8407101]x10=,x11=00700874f000
[  78.8407101]x12=f27a42ac53e8,x13=001d
[  78.8407101]x14=03bd,x15=f27a42202768
[  78.8407101]x16=f27a428708b0,x17=f27a428089e4
[  78.8510494]x18=,x19=f27a4286f000
[  78.8510494]x20=f27a42ab8000,x21=
[  78.8510494]x22=004f,x23=1210
[  78.8510494]x24=00020011a000,x25=
[  78.8510494]x26=,x27=00020011aca8
[  78.8510494]x28=, fp=x29=ffbfb220
[  78.8510494] lr=x30=f27a428084dc, sp=ffbfb220
[  78.8510494] 
[  78.8510494] cpu0: End traceback...

[  78.8510494] dump to dev 92,33 not possible
[  78.8775739] rebooting...

ahcisata and "clearing WDCTL_RST failed"

[Jared McNeill]

Hi folks --

I'm working with an Arm board (SolidRun Honeycomb LX2K) and it is supposed 
to have standard AHCI SATA controllers. I have confirmed that the generic 
driver attaches in Linux when booting in ACPI mode, so there shouldn't be 
any vendor specific magic going on here.


Drives that I've tried are detected properly by firmware (Tianocore EDK2) 
and Linux (Fedora 31), but NetBSD seems to have trouble with them. Debug 
output is below. Any help would be appreciated! I have been banging my 
head on the desk trying to sort this one out and have had no luck so far.


Device is:

[ 1.07] ahcisata0 at acpi0 (SAT0, NXP0004-0): mem 
0x320-0x320,0x700100520-0x700100523 irq 165,166,167
[ 1.07] ahcisata0: using 64-bit DMA
[ 1.07] ahcisata0: AHCI revision 1.31, 1 port, 32 slots, CAP 
0xe537ff80

Probing the disk looks like this:

orange# drvctl -r -a ata_hl atabus0
[ 351.5569230] ata_queue_alloc_slot: channel 0 qavail 0x qact 0orange# 
ahcisata0 port 0: device present, speed: 6.0Gb/s
[ 352.1669178] ahcisata0 ahci_intr 0x1
[ 352.1669178] ahci_intr_port ahcisata0 port 0 is 0x4822 CI 0x0 SACT 0x0 
TFD 0x451
[ 352.1669178] ahcisata0 port 0: TFE: sact 0x0 is 0x4822 tfd 0x451
[ 352.1669178] ahcisata0 port 0: SERR 0x200500
[ 352.1669178] ata_channel_freeze_locked(chp=0xc5ddc218) -> 1
[ 352.1669178] ata_channel_thaw_locked(chp=0xc5ddc218) -> 0
[ 352.1669178] ata_thread_run flags 0x0 ch_flags 0x0
[ 352.1669178] ata_channel_freeze_locked(chp=0xc5ddc218) -> 1
[ 352.1669178] ahcisata0 ahci_intr 0x1
[ 352.1669178] ahci_intr_port ahcisata0 port 0 is 0x0 CI 0x0 SACT 0x0 TFD 0x451
ahcisata0 port 0: clearing WDCTL_RST failed for drive 0
[ 353.5419060] ata_thread_run flags 0x8 ch_flags 0x8000
[ 353.5419060] ata_channel_freeze_locked(chp=0xc5ddc218) -> 2
[ 353.5529529] ata_read_log_ext_ncq
[ 353.5529529] ata_channel_thaw_locked(chp=0xc5ddc218) -> 1
[ 353.5529529] ata_channel_thaw_locked(chp=0xc5ddc218) -> 0
[ 353.5681382] atastart(chp=0xc5ddc218): channel 0 queue_xfer is empty
[ 353.5750819] wd0 at atabus0 drive 0wdattach

[ 353.5750819] ata_get_params
[ 353.5750819] ahci_exec_command port 0 CI 0x0
[ 353.5750819] ata_exec_xfer 0xdb746040 channel 0 drive 0
[ 353.5750819] atastart from ata_exec_xfer, flags 0x0
[ 353.5750819] ata_queue_alloc_slot: channel 0 qavail 0x qact 
0atastart(chp=0xc5ddc218): xfer 0xdb746040 channel 0 drive 0
[ 353.5750819] ahci_cmd_start CI 0x0 timo 3000
[ 353.5750819]  slot 0ahcisata0 port 0 tbl 0xd94a1000
[ 353.5750819] ahcisata0 port 0 header 0xd949f000
[ 353.5750819] atastart(chp=0xc5ddc218): channel 0 queue_xfer is empty
[ 356.6213159] ata_timeout: slot 0
[ 356.6213159] ahci_cmd_complete port 0 CMD 0x1000c017 CI 0x1
[ 356.6213159] ahci_cmd_done port 0 flags 0x12/0x109
[ 356.6345178] ata_get_parms: ata_c.flags=0x129
[ 356.6345178] ata_queue_alloc_slot: channel 0 qavail 0x qact 
0ahcisata0 port 0: setting WDCTL_RST failed for drive 0
[ 357.2313100] ata_get_params
[ 357.2413096] ahci_exec_command port 0 CI 0x0
[ 357.2413096] ata_exec_xfer 0xdb746040 channel 0 drive 0
[ 357.2513096] atastart from ata_exec_xfer, flags 0x0
[ 357.2513096] ata_queue_alloc_slot: channel 0 qavail 0x qact 
0atastart(chp=0xc5ddc218): xfer 0xdb746040 channel 0 drive 0
[ 357.2713094] ahci_cmd_start CI 0x0 timo 3000
[ 357.2713094]  slot 0ahcisata0 port 0 tbl 0xd94a1000
[ 357.2713094] ahcisata0 port 0 header 0xd949f000
[ 357.2813092] atastart(chp=0xc5ddc218): channel 0 queue_xfer is empty
[ 360.2812795] ata_timeout: slot 0
[ 360.2812795] ahci_cmd_complete port 0 CMD 0x1000c017 CI 0x1
[ 360.2812795] ahci_cmd_done port 0 flags 0x12/0x109
[ 360.2944759] ata_get_parms: ata_c.flags=0x129
[ 360.2944759] wd0: IDENTIFY failed
[ 360.3012793] wd0: fixing 0 sector size
[ 360.3012793] wd0: secperunit and ncylinders are zero
[ 360.3012793] wdopen
[ 360.3112793] ata_get_params
[ 360.3112793] ahci_exec_command port 0 CI 0x1
[ 360.3112793] ata_exec_xfer 0xdb746040 channel 0 drive 0
[ 360.3212791] atastart from ata_exec_xfer, flags 0x0
[ 360.3212791] ata_queue_alloc_slot: channel 0 qavail 0x qact 
0atastart(chp=0xc5ddc218): xfer 0xdb746040 channel 0 drive 0
[ 360.3412789] ahci_cmd_start CI 0x1 timo 3000
[ 360.3412789]  slot 0ahcisata0 port 0 tbl 0xd94a1000
[ 360.3512789] ahcisata0 port 0 header 0xd949f000
[ 360.3512789] atastart(chp=0xc5ddc218): channel 0 queue_xfer is empty
[ 363.3512493] ata_timeout: slot 0
[ 363.3512493] ahci_cmd_complete port 0 CMD 0x1000c017 CI 0x1
[ 363.3512493] ahci_cmd_done port 0 flags 0x12/0x109
[ 363.3644453] ata_get_parms: ata_c.flags=0x129

panic: softint screwup

[Jared McNeill]

First time seeing this one.. an arm64 board sitting idle at the login 
prompt rebooted itself with this panic. Unfortunately the default 
ddb.onpanic=0 strikes again and I can't get any more information than 
this:


[ 364.3342263] curcpu=0, spl=4 curspl=7
[ 364.3342263] onproc=0x00237f743080 => l_stat=7 l_flag=2201 l_cpu=0
[ 364.3342263] curlwp=0x00237f71e580 => l_stat=1 l_flag=0200 l_cpu=0
[ 364.3342263] pinned=0x00237f71e100 => l_stat=7 l_flag=0200 l_cpu=0
[ 364.3342263] panic: softint screwup
[ 364.3342263] cpu0: Begin traceback...
[ 364.3342263] trace fp ffc101da7be0
[ 364.3342263] fp ffc101da7c00 vpanic() at ffc0004ad728 
netbsd:vpanic+0x160
[ 364.3342263] fp ffc101da7c70 panic() at ffc0004ad81c netbsd:panic+0x44
[ 364.3342263] fp ffc101da7d40 softint_dispatch() at ffc00047bda4 
netbsd:softint_dispatch+0x5c4
[ 364.3342263] fp ffc101d9fc30 cpu_switchto_softint() at ffc85198 
netbsd:cpu_switchto_softint+0x68
[ 364.3342263] fp ffc101d9fc80 splx() at ffc040d4 netbsd:splx+0xbc
[ 364.3342263] fp ffc101d9fcb0 callout_softclock() at ffc000489e04 
netbsd:callout_softclock+0x36c
[ 364.3342263] fp ffc101d9fd40 softint_dispatch() at ffc00047b8dc 
netbsd:softint_dispatch+0xfc
[ 364.3342263] fp ffc101d3fcc0 cpu_switchto_softint() at ffc85198 
netbsd:cpu_switchto_softint+0x68
[ 364.3342263] fp ffc101d3fdf8 cpu_idle() at ffc86128 
netbsd:cpu_idle+0x58
[ 364.3342263] fp ffc101d3fe40 idle_loop() at ffc0004546a4 
netbsd:idle_loop+0x174
address 0x100 is invalid
address 0xe8 is invalid
[ 364.3342263] cpu0: End traceback...

[ 364.3342263] dump to dev 92,33 not possible
[ 364.3342263] rebooting...

Re: COMPAT_NETBSD32 broken on aarch64 due to UVM bug

[Jared McNeill]

On Mon, 30 Sep 2019, Rin Okuyama wrote:


http://gnats.netbsd.org/54395

With the patch attached in the PR, that KASSERT does no longer fire on
aarch64 with 32-bit binaries, as far as I can see. Also, the patched
kernels just work for me on amd64, earm, and m68k.


I have been running with the patch in this PR doing bulk builds on arm64 
for both arm64 and armv7 in parallel and the KASSERT no longer fires for 
me either. Nicely done!

Re: Interface description support

[Jared McNeill]

I think if_description in struct ifnet should be moved before the #ifdef 
_KERNEL block so it stays at the same offset for non-_KERNEL users.


Cheers,
Jared

On Mon, 24 Jun 2019, KUSABA Takeshi wrote:


Hi,

I would like to propose a feature: a description of a network interface.
(FreeBSD and OpenBSD support this feature.)

Here is a patch.

https://gist.githubusercontent.com/maleic1618/f4881717cbd3b1e3182984f9773b1001/raw/114b5d6c4fbe1fd9cd473fdc802b003c072c2794/description.patch

The sammary of this patch is:

ioctl(2):
- support the commands SIOCGIFDESCR/SIOCSIFDESCR to get/set the description.

ifconfig(8):
- add the commands description,descr/-description,-descr to set/clear the 
description.



Could you comment on this patch?
I hope that this patch will be merged.

Thanks,

--
Internet Initiative Japan Inc.

Device Engineering Section
Product Development Department
Product Division

KUSABA Takeshi 

Re: Support for "pshared" POSIX semaphores

[Jared McNeill]

On Feb 2, 2019, at 1:04 PM, Jason Thorpe  wrote:
> 
> I’ll go ahead and check it in later today (I want to add a couple of more 
> unit tests that exercise the low-level _ksem_*() calls directly, as I made 
> some object lifecycle changes there).

It might be worth requesting a pull-up to netbsd-8 as well.

Re: pci_intr_alloc() vs pci_intr_establish() - retry type?

[Jared McNeill]

On Mon, 3 Dec 2018, Jaromír Doleček wrote:


ahcisata(4) works for me on two different computers in MSI mode. I
don't have any ahcisata device which supports MSI-X, but it is working
on Cavium which has MSI-X. Perhaps some different BAR wierdness than
Cavium, or simply the boards using MSI-X should use the "cavium" BAR?


IIUC we don't actually have confirmation that ThunderX AHCI works yet.. 
Nick is having issues with his board.

Re: pci_intr_alloc() vs pci_intr_establish() - retry type?

[Jared McNeill]

On Fri, 30 Nov 2018, Martin Husemann wrote:


On Fri, Nov 30, 2018 at 02:22:37PM -0400, Jared McNeill wrote:

The driver can call pci_intr_type on the handle returned by pci_intr_alloc
to see what kind of interrupt (INTx/MSI/MSI-X) was negotiated.


Yeah, but the fear was that some hardware could either do a single INT
or (lots of) MSI{X}, and now you end up with (lots of) INT returned
from pci_intr_alloc() and can just use the first.

Does this not happen for real world hardware, or is the driver supposed to
check with pci_*_count() upfront?


I don't think pci_intr_alloc will ever return more than one INTx..

Re: pci_intr_alloc() vs pci_intr_establish() - retry type?

[Jared McNeill]

On Wed, 28 Nov 2018, Mouse wrote:


This reminds me - how does a driver know if any kind of MSI support
is even available?

it shouldn't need to.


Okay, then I'm missing something.  I've seen hardware where enabling
MSI is something device-specific (a value in a register, typically),
meaning _something_ MD, presumably the driver, has to be involved if
MSI is to be used.

And how can a driver do this without knowing whether it's supported?


The driver can call pci_intr_type on the handle returned by pci_intr_alloc 
to see what kind of interrupt (INTx/MSI/MSI-X) was negotiated.

Re: pci_intr_alloc() vs pci_intr_establish() - retry type?

[Jared McNeill]

On Wed, 28 Nov 2018, Jaromír Doleček wrote:


pci_intr_alloc() checks what the device claims to support down the
call stack, reading the PCI config space. I assume there some
negotiation between the PCI bus and the device. I hope device can't
claim to support e.g. MSI-X if the bus doesn't.


Device claiming to support MSI-X is fine. The bus should only set 
PCI_FLAGS_MSIX_OKAY in its pcibus_attach_args pba_flags in the case that 
MSI-X is supported, and then the MD code will filter it out:


https://nxr.netbsd.org/xref/src/sys/arch/arm/pci/pci_msi_machdep.c#90
https://nxr.netbsd.org/xref/src/sys/arch/x86/pci/pci_msi_machdep.c#256

Re: Help with a bug in mmap

[Jared McNeill]

On Wed, 31 Oct 2018, Taylor R Campbell wrote:


For the moment, as a provisional workaround to make progress, you can
probably get by with `pa << PGSHIFT', where pa is the physical (byte)


I think this should be `pa >> PGSHIFT`, or even better use `atop(pa)`.

Re: Too many PMC implementations

[Jared McNeill]

On Sun, 15 Jul 2018, Maxime Villard wrote:


Now I want to move:

arch/x86/x86/tprof_pmi.c
arch/x86/x86/tprof_amdpmi.c

into

dev/tprof/tprof_intel.c
dev/tprof/tprof_amd.c

I guess people are fine? I think it is better to gather all the pieces in
one dir.


I don't really have an opinion here, but I've just committed a new 
backend as dev/tprof/tprof_armv8.c. So I guess that's a vote for the 
latter :)


Cheers,
Jared

Re: Resizing root file-system vs wedges

[Jared McNeill]

On Fri, 29 Jun 2018, Martin Husemann wrote:


For resize_ffs it should be simple to add that - for the others it does not
exactly make sense, as they alway operate on the parent device of the wedge.


Sometimes dkctl operates on the wedge itself - "getwedgeinfo" for example.

Resizing root file-system vs wedges

[Jared McNeill]

Hi folks --

I'm trying to add support for auto-detecting the boot device to the armv7 
and arm64 images. Seemed like the easiest way was to use GPT, wedges, and 
mount by name.


I've hit a few issues:

 - I need a reliable way to find the backing device for a given wedge so I
   can "gpt resizedisk" and "gpt resize" from an rc script. It looks like
   I can get this today with 'dkctl dk1 getwedgeinfo' but it doesn't look
   like the output is meant to be parsed.

 - Inconsistent / nonexistent support for mount by name in the system. The
   kernel wants "wedge:name", fstab wants "NAME=name", and none of the
   tools (gpt, dkctl, resize_ffs) I am using seem to accept a label at
   all.

 - DIOCMWEDGES fails if one of the partitions is opened. In this case it
   is the root partition, which is mounted read-only. It looks like the
   changes actually do get applied, but since the kernel doesn't see the
   changes, "resize_ffs -c" doesn't work until after I reboot.

Any suggestions?

Thanks,
Jared

Re: PWM and user space API

[Jared McNeill]

On Mon, 28 May 2018, Jason Thorpe wrote:


I’m going to be writing a driver for the NXP PCA9685, and want to glue it into 
the PWM kernel API jmcneill@ added… but I have a bunch of uses for this device 
that won’t really be covered by FDT, so I think there needs to be some sort of 
user space API as well.

I have to say that I’m growing frustrated with the proliferation of ioctl-based 
APIs and *ctl programs.  I’m tempted to start doing more of this stuff with 
sysctl(), and then perhaps hiding the details from applications inside a shared 
library API that exposes only opaque types and accessors / mutators.  (Gawd, 
historically, BSD has done such a terrible job at API design…)

My concern about sysctl(), though, is that because of the way it’s structured, 
you’ve got a latency problem, which is not a concern in my application, but 
might be an issue if you have an application that needs to control a servo 
using PWM.

Curious to hear your thoughts on this.


I do this from time to time, mostly out of laziness (sys/dev/led.c for 
example). Biggest issue I have is that with sysctl we lose the ability to 
use chmod/chown/chgrp.

Re: sunxi graphic console, try 2

[Jared McNeill]

Looks good to me! Thanks for your patience with me on this one.

Cheers,
Jared

On Sat, 7 Apr 2018, Manuel Bouyer wrote:


Hello,
with Jared's feedback, I reimplemented console handling for the sunxi graphic
drivers. There are 3 problems to solve:
- proper handling for console=xxx in the bootargs. I want to switch from
 graphic to serial, or back, from bootargs without changing
 /chosen/stdout-path entry in the device tree each time.
 The kernel can change stdout-path early in the boot process,
 and at this time it's not pratical to make it point to anything
 but serial or /chosen/framebuffer (we don't want to parse the whole
 device tree at this time).
 So I just change sunxi_platform_bootstrap() to understand console=serial
 in bootargs, so is stdout-path points to some graphic device in the
 device tree we can switch back to serial.

- attaching the graphic console to the graphic pipeline instead of simplefb.
 The graphic driver doesn't want to claim the consle at FDT_CONSOLE() time,
 because at this time it doens't know if it will be active or not
 (not to mention which of the 2 pipelines will be active, and will be console).
 In addition, simplefb may be functional until the graphic driver takes over.
 So in sunxi_debe I use FDT_CONSOLE() only to remember the
 simple-framebuffer phandle, which sunxi_debe will need to decide if
 it's console later.

- preventing simplefb from attaching. Once the graphic drivers have attached
 simplefb is not functional any more. So even if there is an active
 simple-framebuffer compatible not in the fdt, we should not attach it.
 I could add a sunxi_simplefb driver which return a higther match
 score, but I don't like the idea of adding a void driver just
 to prevent another one from attaching. Among others, this could
 cause strange effects if the kernel config omits it, hard to debug as
 this is touching the console.
 Basically we have several fdt nodes pointing to the same hardware,
 and we don't want to use them all.
 I added public fdt functions to explicitely inactivate arbitrary
 fdt nodes (here I remove them from the node list but that's implementation
 detail). There is fdt_remove_bycompat(const char *[]) to remove nodes
 matching on compatible strings; for completeness I also added
 fdt_remove_byhandle(int) but I don't need it.

--
Manuel Bouyer 
NetBSD: 26 ans d'experience feront toujours la difference
--

Re: graphic drivers and simplefb

[Jared McNeill]

On Thu, 5 Apr 2018, Manuel Bouyer wrote:


For simplefb I have everything I need..


OK, so in this case you'd want to have simplefb be the console,
until a more complete graphic driver attaches and take over
(much like we do with vga vs drm drivers in the x86 world).


Yeah maybe we should focus on that instead.


Boards exist where serial console is difficult or impossible to access. Lets
come up with a solution that satisfies all cases..


Sure. In this case I guess stdout-path will not be set to the serial port
though, so it should not use the serial port at all. I don't think we have
anything to change for this.

What I'm talking about is: stdout-path is set to the serial port, but
we have console=fb in the bootargs. In this case I think we could use
the serial port as console util the graphic driver (be it simplefb or
something else) is attached, at which point it will attach as console and
replay the dmesg buffer.

For this we need either to have the serial port attach before the
graphic drivers, or have a way to reset the console status of the serial
port when needed.


The serial port will only attach as console if you have chosen it to be 
the console (stdout-path). I want to solve this problem the right way, not 
relying on device attach order, because device order hacks become 
unmanageable when you are dealing with multiple SoC families, shared 
drivers, and GENERIC kernels.


We need a solution that covers these use cases:

 - Console is UART (may or may not have display capabilities)
 - Console is FB (laptop, tablet, etc where UART is difficult to access)
 - Console device can be either UART or FB (like a dev board, where we
   support both with WSDISPLAY_MULTICONS)

Currently the armv7.img/arm64.img configs use 'console=fb' to get correct 
behavior in these 3 cases. This setup has been working well so far, but 
there is definite room for improvement. I just want to make sure that the 
existing functionality doesn't get broken.


Cheers,
Jared

Re: graphic drivers and simplefb

[Jared McNeill]

On Thu, 5 Apr 2018, Manuel Bouyer wrote:


On Thu, Apr 05, 2018 at 07:40:35AM -0300, Jared McNeill wrote:

On Thu, 5 Apr 2018, Manuel Bouyer wrote:


Does it really do that ?
Reading the sources nothing is displayed until simplefb_attach() is called.
simplefb_console_consinit() calls genfb_cnattach() but it does nothing.
The dmesg buffer is replayed when genfb attaches with the console flag.


Doh, you're right. I'll have to fix that :)


but that's not easy. You'd need not only simplefb but also the
raster stuff to be set up. I'm not sure we want to go that far
in the early stages of the kenrel boot.
Things are even worse when we have to set up a full graphic pipeline.
You may even need interrupts ...


For simplefb I have everything I need..




Actually FDT_CONSOLE doens't prevent the serial port from taking over the
console if the stdout-path says so - and even if the command line says
otherwise.


Looks like we're missing a call to com_is_console in sunxi_com. This should
be fixed too..


I've been wondering about it too. But anyway, something, somewhere, it DTRT.
I have 3 serial ports active in my platform, and only com0 is console.
And if I change stdout-path (like my patch does, or in the fdt) then
com0 is not console any more.


This is because we call comcnattach (via FDT_CONSOLE) only for the one 
specified by stdout-path, and com.c:com_attach_subr only attaches console 
to that one.



Actually it works with simplefb because /chosen/framebuffer is probed and
attaches after com0 (and it's not an ordering kludge: it's just luck).
As sunxidep is attached before com0, com0 has the last word.


Not behavior I want to rely on :/


Note that this is also how allwniner works: com0 is console,
until a graphic driver attaches. In allwinner serial ports are attached
before graphics.
And I'd like to keep this behavior, it's very usefull for debugging.


Boards exist where serial console is difficult or impossible to access. 
Lets come up with a solution that satisfies all cases..

Re: graphic drivers and simplefb

[Jared McNeill]

On Thu, 5 Apr 2018, Manuel Bouyer wrote:


Does it really do that ?
Reading the sources nothing is displayed until simplefb_attach() is called.
simplefb_console_consinit() calls genfb_cnattach() but it does nothing.
The dmesg buffer is replayed when genfb attaches with the console flag.


Doh, you're right. I'll have to fix that :)


Actually FDT_CONSOLE doens't prevent the serial port from taking over the
console if the stdout-path says so - and even if the command line says
otherwise.


Looks like we're missing a call to com_is_console in sunxi_com. This 
should be fixed too..



Actually it works with simplefb because /chosen/framebuffer is probed and
attaches after com0 (and it's not an ordering kludge: it's just luck).
As sunxidep is attached before com0, com0 has the last word.


Not behavior I want to rely on :/

Cheers,
Jared

Re: graphic drivers and simplefb

[Jared McNeill]

On Thu, 5 Apr 2018, Manuel Bouyer wrote:


But still, being able to switch the console from the bootargs is convenient.
On the device I'm working with, the normal stdout-path would be the
graphic display, but when doing developement I switch to serial console.
It's much easier to switch using bootargs (which I can always do using the
serial console) than updating the device tree (especially as I can't easily
extract the sd card, I have to dissasemble the boards for that).


Totally agree, that's why the console=fb vs stdout-path logic is there in 
the first place.



I think there's a simple way to get it working: leave stdout-path to the
serial port, and move sunxi_com to pass 4, so that it's probed before
sunxi_dep. This way the kernel starts with console on serial, and switches
to graphic if the command line says so when the graphic drivers are activated.


This would be a regression to the current simplefb setup, which gives 
early kernel output to the selected console device. I'd prefer to use 
FDT_CONSOLE here rather than relying on device attach ordering kludges.


Cheers,
Jared

Re: graphic drivers and simplefb

[Jared McNeill]

On Thu, 5 Apr 2018, Manuel Bouyer wrote:


looking closer at it I can't see how this change would be a problem.
With this /chosen/stdout-path may point to a path that doens't
exists, or is not okay.
If it's not okay the driver will not attach because the fdt bus logic will
skip it.
It it doesn't exists, fdtbus_get_stdout_phandle() will return -1, which should
prevent of_match_compatible() from matching.
Did I miss something ?


The default stdout-path is usually defined in board specific .dts files:

https://nxr.netbsd.org/xref/src/sys/external/gpl2/dts/dist/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts#58

Re: graphic drivers and simplefb

[Jared McNeill]

On Wed, 4 Apr 2018, Manuel Bouyer wrote:


On Wed, Apr 04, 2018 at 06:45:12PM -0300, Jared McNeill wrote:

This will crash simplefb if the framebuffer is not configured. U-Boot will
set status to okay to signal to OS that simplefb handoff is available.


Doens't simplefb itself check the existence and status in the dtb ?
AFAIK I have simplefb in my kernel, but u-boot doesn't configure it,
yet I boot with console=fb and if works ...


Sorry I re-read the code and I was wrong about a crash. The idea here was 
to make console=fb fallback to the serial port (or whatever the default is 
in the devicetree) if the framebuffer is not available.


Not sure off the top of my head how to solve this cleanly for non-simplefb 
drivers, let me think about it...

Re: graphic drivers and simplefb

[Jared McNeill]

There is a more specific compatible string on /chosen/framebuffer that you 
can match on ("allwinner,simple-framebuffer"). If your driver claims that 
node, you won't have to worry about handoff at all...


https://www.kernel.org/doc/Documentation/devicetree/bindings/display/simple-framebuffer-sunxi.txt

You'll want to add FDT_CONSOLE support to your DE driver as well.

Cheers,
Jared


On Wed, 4 Apr 2018, Manuel Bouyer wrote:


Hello,
What's missing from the sunxi video drivers is console handling.
I got this working, but this needs some change to the simplefb driver.

the /chosen/framebuffer node is (if I understood is properly) set up by
the firmware/bootloader and will always exists if a framebuffer has been
set up. Or, we can't have a framebuffer in the firmware/bootloader without
a valid /chosen/framebuffer node (if I understood it properly).
Our simplefb driver will attach to it.
In addition, if this is going to be the OS's console, our simplefb
driver will match it very early.

Now if we attach and configure the display hardware in the OS, the
simplefb won't be functional as the display driver. Also, the
display drivers needs to know if they will be the console, and the simplefb
driver knows this.

So I propose to add 2 public functions to dev/fdt/simplefb.c, for use
by display drivers:
- int fdt_simplefb_get_console(void) which returns the phandle of
 the /chosen/framebuffer node, if it has been selected as console.
 The display driver may need more information from here
 (like the content of allwinner,pipeline in my case).
- void fdt_simplefb_disable(void) which, once called, will prevent the
 simplefb from matching.

The attached patch implements this, as well as console handling the
the sunxi drivers. In addition to 'console=fb', console=fb0 or fb1 is
supported to select a specific pipeline, which may not have been set up
by the bootloader.

For this to work, the display pipelines have to be fully configured before
simplefb could be matched. So I has to move
sunxidep*  at fdt?
to pass 5.

I believe that with this, the display drivers could be enabled by default
in the sunxi kernel.

--
Manuel Bouyer 
NetBSD: 26 ans d'experience feront toujours la difference
--

Re: graphic drivers and simplefb

[Jared McNeill]

This will crash simplefb if the framebuffer is not configured. U-Boot will 
set status to okay to signal to OS that simplefb handoff is available.


On Wed, 4 Apr 2018, Manuel Bouyer wrote:


On Wed, Apr 04, 2018 at 06:24:44PM +0200, Manuel Bouyer wrote:

Hello,
What's missing from the sunxi video drivers is console handling.
I got this working, but this needs some change to the simplefb driver.


I also need the attached change. Without it, if u-boot did use the serial
port and no framebuffer as console, the kernel's console will end up on the
serial port whatever the content of the bootargs is.

With this change the kernel may end up with no console at all if
bootargs has bee set wrongly, but then it's an operator mistake :)

--
Manuel Bouyer 
NetBSD: 26 ans d'experience feront toujours la difference
--

Re: RFC: device tree ports, connectors and panels

[Jared McNeill]

LGTM.

Any way I could convince you to ditch the _t typedefs? Only for 
consistency, because the rest of the FDT code (for better or worse) 
doesn't use this style.


I'd like to see this evolve at some point to work closer with the DRM2 
APIs, as it seems that there may be quite a bit of overlap.


Thanks again for working on this!

Jared


On Sun, 1 Apr 2018, Manuel Bouyer wrote:


Hello,
while porting the allwinner graphic drivers from arm/allwinner to arm/sunxi,
I had to deal with ports and endpoinds defined in the device tree.
ports and endpoinds defines how the different elements of a video pipeline
are connected together, and are defined in
linux/Documentation/devicetree/bindings/graph.txt

I came up with the API and implementation available at
http://www.netbsd.org/~bouyer/fdt_video.tgz
For details about the port/endpoint API see comments in fdt_port.h

For completeness I also had to implement a connector driver.
This one is quite trivial, it's only there to register its endpoint,
so that e.g. the upper level in the pipeline can know if the HDMI output
is useable. It is incomplete at this time, as e.g. it doesn't deal
with getting the video timings from an external i2c controller
(the allwinner hdmi controller has its own i2c driver). This can be adder
later, by someone with the right hardware to test.

With this I could get the HDMI output on an A20 board working as well as
the old allwinner kernel.

I'm now working on LVDS panel support. For this I had to implement a
panel driver. This one will get the display timing from the device tree,
and control the power and (if needed) backlight of the panel.
Here I had a problem: the linux specifications and drivers don't say anything
about dual-link lvds panels. The few drivers that support dual-link do
it in an ad-hoc way (e.g. with a driver-specific property in the controller's
device tree to enable/disable the dual-lvds interface), and their
sunxi driver doesn't support dual-lvds at all. Of course my panel is
dual-lvds. Anyway this is a physical feature of the panel so I think
this information should be in the panel entry, not the LVDS controller entry.
To solve this I added a new compatible type: panel-dual-lvds, in addtition to
the specified panel-lvds. There could be other ways to do it, like
different data-mapping. As this is a different physical interface I think
a different panel type is more appropriate, but suggestions are welcome.

I've not finished the tcon part of the LVDS at this time but I'm confident
that this panel interface won't need much changes to get a working display.

The panel driver is incomplete (it misses the backlight handling, and could
also support non-lvds panels) but I'll leave this to someone with the hardware.

--
Manuel Bouyer 
NetBSD: 26 ans d'experience feront toujours la difference
--

Re: clk_set_parent() by name ?

[Jared McNeill]

On Tue, 20 Mar 2018, Manuel Bouyer wrote:


Ok, I'd be happy with something like that (but I'm bad at naming things, so
feel free to make a better suggestion -- clk_calc_rate() maybe?)


linux calls it round_rate() and it's really what it's doing.
so clk_round_rate() ?


Works for me!

Cheers,
Jared

Re: clk_set_parent() by name ?

[Jared McNeill]

On Tue, 20 Mar 2018, Manuel Bouyer wrote:


The code for the pixel clock would be part of the display driver. The parent
of that clock is part the CCU. Maybe we need a clk_try_rate or something to
help the pixel clock driver set the best parent rate.


but parts of the pixel clock registers are in the CCU too. For example
the divider for ch0 is in the tcon, but the divider for ch1 is in the CCU.

I don't know why is was done this way, but that's how it is, unfortunably.


Yes this is expressed in the device tree! There is a "pixel clock" clock 
on the tcon node used for CH0.


So TCON driver creates a clock in its own domain for the pixel clock. The 
parent of this clock is the "tcon-ch0" clock. All of this code lives in 
sunxi_tcon.c (or whatever you call it).


When you need to set the CH0 rate, you clk_set_rate on the pixel clock 
(which is responsible for configuring its parent clock, "tcon-ch0").


When you need to set the CH1 rate, you clk_set_rate directly on the 
"tcon-ch1" xref.



How does the sunxi-ng driver solve this?


This is in sun4i_dclk_round_rate(). Basically it tries to set the
parent clock rate for every possible divider value and keep the best one.

THere indeed is something like a clk_try_rate().


Ok, I'd be happy with something like that (but I'm bad at naming things, 
so feel free to make a better suggestion -- clk_calc_rate() maybe?)



Somewhat related question, since you seem to be porting the existing driver
over, are you DRM-ifying it in the process? We really need to go that way
for dynamic output config (think xrandr) and to support the GPU in the
future.


No that's not in my plans. I know nothing about DRM and I'm not even sure
what we have in sys/external/bsd/drm2/ is up to the task. it looks
awfully x86-centric. What's in linux/drivers/gpu/drm/ is completely
different now.


Not sure what gave you the impression that it's x86-centric -- we use it 
today on NetBSD/arm for the NVIDIA Tegra K1 display driver. IMHO it really 
simplifies things (separates things like encoders, crtcs, planes, etc) and 
if you're just doing a simple unaccelerated driver it is fairly straight 
forward. Something to think about for the future.


Cheers,
Jared

Re: clk_set_parent() by name ?

[Jared McNeill]

On Tue, 20 Mar 2018, Manuel Bouyer wrote:


But yeah, you can see them on the tcon nodes, named by the
"clock-output-names" property. It looks like those clocks use the "tcon-ch0"
xref as their parent, and are used by CH0. The "tcon-ch1" xref is used
directly by CH1.


Yes. tcon-ch0 is an example of the problem I'm talking about: to generate
the pixel clock we have to setup a multiplier and a divider; but the
multiplier is in the CCU (it's pll3/pll7) and the divider is in tcon.
In order to compute the best divider the tcon driver has to know what
the CCU can generate.


The code for the pixel clock would be part of the display driver. The 
parent of that clock is part the CCU. Maybe we need a clk_try_rate or 
something to help the pixel clock driver set the best parent rate.



In allwinner this is awin_tcon0_set_video(). It calls awin_tcon_set_pll(),
which will compute multiplier and divider, but in this case
awin_tcon_set_pll() won't use the divider itself: it stores it in
sc_clk_div, for use by awin_tcon0_set_video() later.


I don't know that I would use the allwinner code as a shining example of 
how to do this stuff :) There's a reason I started from scratch..



awin_tcon1_set_video() doens't have this issue; the divider is in the CCU.

hdmi also has the divider in its register, but in this case the pll is already
setup (by awin_tcon1_set_video()). Actually it retrives the
divider from tcon but it could recompute it locally.


How does the sunxi-ng driver solve this?

--

Somewhat related question, since you seem to be porting the existing 
driver over, are you DRM-ifying it in the process? We really need to 
go that way for dynamic output config (think xrandr) and to support the 
GPU in the future.


I started down this path late last year but lost steam/motiviation as it's 
the third time I've done a DE driver.. happy to see that you've picked 
this up!


Cheers,
Jared

Re: clk_set_parent() by name ?

[Jared McNeill]

On Tue, 20 Mar 2018, Manuel Bouyer wrote:


but pushing driver-specific clock setup in the ccu also looks wrong
to me, and could appear as black magic.


It's not driver specific. The TCON needs a clock input at a certain 
frequency and requests it from the clk driver. The clk driver for that soc 
knows how to program the video PLL to supply a clock at that frequency.



It seems they have display-specific clock drivers (e.g.
./drivers/clk/sunxi/clk-sun4i-display.c
./drivers/clk/sunxi/clk-sun4i-tcon-ch1.c
)
So we'll probably have to do the same, instead of using the
PLL generic drivers.
This will also probably need an update of the clock interface (like
reference counts for enable/disable, "exclusive" clocks, maybe others).


Those are old clock drivers, you should look in drivers/clk/sunxi-ng for 
the new style bindings (which is all we support in NetBSD).


But yeah, you can see them on the tcon nodes, named by the 
"clock-output-names" property. It looks like those clocks use the 
"tcon-ch0" xref as their parent, and are used by CH0. The "tcon-ch1" xref 
is used directly by CH1.

Re: clk_set_parent() by name ?

[Jared McNeill]

I see what you mean now. The issue I have with clk_set_parent_byname is 
that it pushes internals of the clk provider into device drivers. The 
names are arbitrary and not consistent across ccu drivers, only really 
meant for printing/debugging etc.


If you're using static clock parents, you can just initialize them in your 
ccu driver's attach function.


If you need to dynamically adjust clock parents, do you have enough 
context in the ccu driver on a clk_set_rate call to auto-select the 
correct parent?


Cheers,
Jared

On Mon, 19 Mar 2018, Manuel Bouyer wrote:


On Mon, Mar 19, 2018 at 04:03:56PM -0300, Jared McNeill wrote:

On Mon, 19 Mar 2018, Manuel Bouyer wrote:


Looking at what we have now, I see 2 ways for doing this:
- clk_set_parent(). But this one takes a "struct clk*" as parent,
 and I don't have this handy in the driver. There is clk_get(), but it
 need the ckock domain, which I also don't have it in the driver.
 There is no clk_get_domain()
- clk->set_parent(), which takes a clock name. But for this I need to
 use a struct sunxi_ccu_clk * instead of struct clk *.

So what should I do to solve this ? Introduce clk_get_domain() or
clk_set_parent_byname() in sys/dev/clk/, or use struct sunxi_ccu_clk in
the sunxi drivers ?


The dt should have references to the parent clocks - the hdmi node has:

   clocks = < CLK_AHB_HDMI0>, < CLK_HDMI>,
< 9>,
< 18>;
   clock-names = "ahb", "mod", "pll-0", "pll-1";

So you can do something like:

   struct clk *clk_hdmi = fdtbus_clock_get(phandle, "mod");
   struct clk *clk_video0 = fdtbus_clock_get(phandle, "pll-0");
   struct clk *clk_video1 = fdtbus_clock_get(phandle, "pll-1");

   ...

   clk_set_parent(clk_hdmi, use_video0 ? clk_video0 : clk_video1);


But for the tcons we have:
   clocks = < CLK_AHB_LCD0>,
< CLK_TCON0_CH0>,
< CLK_TCON0_CH1>;
   clock-names = "ahb",
 "tcon-ch0",
 "tcon-ch1";

the tcon-ch0 and tcon-ch1 can source from A10_CLK_PLL_VIDEO0,
A10_CLK_PLL_VIDEO1, A10_CLK_PLL_VIDEO0X2 or A10_CLK_PLL_VIDEO1X2 which
we don't have in the device tree (well, some of them happens to be in the
hdmi node, but what if we don't use the hdmi ?)

Similary, for debe:
   clocks = < CLK_AHB_DE_BE1>, < CLK_DE_BE1>,
< CLK_DRAM_DE_BE1>;
   clock-names = "ahb", "mod",
 "ram";
and CLK_DE_BE1 can source from A10_CLK_PLL_VIDEO0, A10_CLK_PLL_VIDEO1, or
A10_CLK_PLL_DDR_BASE, which we don't have in the fdt.

Also for hdmi it's more complicated because it can source from 4 different
clocks ...

I don't think clock mux parameters are supposed to be in the fdt.

--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--

Re: clk_set_parent() by name ?

[Jared McNeill]

On Mon, 19 Mar 2018, Manuel Bouyer wrote:


Looking at what we have now, I see 2 ways for doing this:
- clk_set_parent(). But this one takes a "struct clk*" as parent,
 and I don't have this handy in the driver. There is clk_get(), but it
 need the ckock domain, which I also don't have it in the driver.
 There is no clk_get_domain()
- clk->set_parent(), which takes a clock name. But for this I need to
 use a struct sunxi_ccu_clk * instead of struct clk *.

So what should I do to solve this ? Introduce clk_get_domain() or
clk_set_parent_byname() in sys/dev/clk/, or use struct sunxi_ccu_clk in
the sunxi drivers ?


The dt should have references to the parent clocks - the hdmi node has:

   clocks = < CLK_AHB_HDMI0>, < CLK_HDMI>,
< 9>,
< 18>;
   clock-names = "ahb", "mod", "pll-0", "pll-1";

So you can do something like:

   struct clk *clk_hdmi = fdtbus_clock_get(phandle, "mod");
   struct clk *clk_video0 = fdtbus_clock_get(phandle, "pll-0");
   struct clk *clk_video1 = fdtbus_clock_get(phandle, "pll-1");

   ...

   clk_set_parent(clk_hdmi, use_video0 ? clk_video0 : clk_video1);


Cheers,
Jared

Re: hw.acpi.sleep.vbios

[Jared McNeill]

We can do better. 0 is a reasonable default for when a kms driver is 
attached, but will usually fail in other cases. I've commited the 
following change:


  http://mail-index.netbsd.org/source-changes/2016/09/21/msg077860.html

Now the defaults work like this:

  If KMS driver is attached, =0
  If non-KMS driver is attached and VGA_POST option is present, =2
  If non-KMS driver is attached and VGA_POST option is absent, =1

Cheers,
Jared


On Tue, 20 Sep 2016, co...@sdf.org wrote:


This value cannot stay 1.
It should be either 0 (drmkms) or 2.

I find it extremely hard to imagine there's any machine that can suspend
& resume properly with the value of 1 (feel free to tell me about your
15 year old hardware, though).

Pick one, commit.

attached diff for 0.

Re: gpio interrupts

[Jared McNeill]

On Thu, 7 Apr 2016, Manuel Bouyer wrote:


On Thu, Apr 07, 2016 at 05:34:00PM -0300, Jared McNeill wrote:

Hi Manuel --

A few comments:


The attached patch adds two functions to gpio.c:
gpio_pin_wait() is called by a thread that wants to wait on an interrupt.
A thread can wait only on a single pin.


Any particular reason you went with this approach instead of say, something
that follows the typical foo_intr_establish pattern? I think "register a
callback" would be a much more typical use-case for a device driver here.


In a SMP world you want to do less in interrupt handlers and more in
kernel threads, basically. Also, in this kind of setup, the
device raising an interrupt is most likely behind a bus that itself needs
interrupts to work (i2c, spi, uart, ...). So the action triggered by
the interrupt can't be part of the interrupt handler, it has to execute
in a thread.
Also, if we ever makes this usable up to userland, condvar will be needed.


Maybe it makes sense to have both a low level "gpio_intr_establish", and a 
higher level function that builds on top of that for convenience of 
drivers that prefer a synchronous API.


Thinking of fdtbus gpiokeys driver, where its job is to receive the 
notification and dispatch that event to sysmon. Sysmon already has a 
thread, and having only a synchronous-only API means the gpiokeys driver 
needs to manage yet another one.



I could add a callback scheme if there is a need for that, but this
raises a question: how to handle IPL properly ?
AFAIK the only MI interface is splfoo()/splx(), splraise/spllower are
not mandatory.


Good question. I ran into the same issue with the PCIe driver for tegra 
(sys/arch/arm/nvidia/tegra_pcie.c) and didn't come up with a good 
solution there either.


Cheers,
Jared

Re: Very slow transfers to/from micro SD card on a RPi B+

[Jared McNeill]

Regular RPI / RPI2 kernel build does this for you -- simply rename 
netbsd.bin to kernel.img.


On Tue, 18 Aug 2015, Stephan wrote:


Sorry, I meant objcopy (it was already too late yesterday). I need a kernel.img 
file for the boot partition on
the Pi. Jared said that needs to be extracted from the ELF kernel resulting 
from a regular build.

2015-08-18 12:55 GMT+02:00 Nick Hudson sk...@netbsd.org:
  On 08/17/15 19:08, Stephan wrote:
I have just rebooted with WAPBL enabled. Some quick notes:

-Sequential write speed is a little lower, around 5,4 MB/s.

-Creating 1000 files takes 0,25 sec. while almost no xfers happen. 
(It just
goes to the log I guess).

-When creating more files (say 10.000), a known issue comes to 
light. One
CPU core gets utilized 100% in kernel mode while there are almost 
no xfers.
It takes ages until the operation completes. In contrast, a 
non-WAPBL
mounted FS experiences many xfers until the drive limit gets hit 
(100
xfers/sec.).

I am pretty certain that there is a regression in WAPBL. Can you 
tell me
how I can extract a kernel for the Pi using objdump, so I can 
conduct some
experimentation?


  What do you want to do with objdump?

  Nick

Re: Converting kernel printf() to aprint_*() or log()

[Jared McNeill]

On Tue, 11 Nov 2014, Martin Husemann wrote:


- create a log_dev(device_t, const char *fmt, ...) function and use that
  in drivers instead of printf() when not in the driver's *_attach()
  function (or functions only called from that); use log(9) where
  appropriate instead for printfs not using device_xname().


We already have device_printf() for this.

Re: HDMI transmitter interface

[Jared McNeill]

On Tue, 23 Sep 2014, Manuel Bouyer wrote:

Sure; how big does it need to be ? Or should it be dynamically allocated ?


The standard allows for up to 255 extension blocks, so theoretically 256 * 
128 = 32KB. Probably best to make it dynamic.

Re: HDMI transmitter interface

[Jared McNeill]

On Mon, 22 Sep 2014, Manuel Bouyer wrote:

   /*
* data we got from the monitor. Can be filled either by the
* transmitter or the controller driver
*/
   uint8_t vdt_edid_data[128];
   struct edid_info vdt_edid_info;


Maybe change this a bit to make room for EDID 1.3 extension blocks as 
well?

Re: HDMI transmitter attachement

[Jared McNeill]

Does it have you appear in the device tree at all? I had a similar 
situation with the DTV host controller drivers, and I ended up not 
attaching them to the device tree at all.


So e.g. sys/dev/usb/auvitek_i2c.c implements struct i2c_controller but 
doesn't appear in the device tree. There are separate drivers for the 
different tuners and demodulators but they are used directly by the host 
controller drivers (au8522, lg3303, xc3028, xc5k, tvpll, nxt2k, mt2131, 
cx24227).


Hope this helps
Jared



On Tue, 16 Sep 2014, Manuel Bouyer wrote:


Hello,
I'm looking for advice about the design for a new driver.

the AM335x arm SoC includes a framebuffer, which outputs a parallel digital
video signal. A HDMI transmitter which will serialize this video signal
can be connected to the SoC, which then allows to connect external monitors.
The beaglebone black includes a TDA19988 HDMI transmitter.

A driver is needed for the TDA19988, to get the EDID from the monitor, and
also configure the transmitter appropriately. So, in addition to the
video output lines, the TDA19988 is connected to one of the I2C controller
of the AM335x (one the beaglebone black it's the I2C0 controller, but
other boards could use any of the AM335x's I2C controllers).
In addition, the TDA19988 can transmit a digital audio signal, which it
gets from the SoC's multichannel audio serial port.

Now my question is how should the TDA19988 appears in the device tree ?
I could make it a child of the I2C controller, with the framebuffer and
audio drivers using ad-hoc callbacks to the TDA19988 driver.
Or I could make it a child of the framebuffer, the framebuffer driver
redirecting I2C requests to the I2C controller driver.

I think the second solution is less hackish and more flexible;
but I'd like to hear from people more familiar than I am with
video hardware and drivers.

--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--

Re: HDMI transmitter attachement

[Jared McNeill]

On Tue, 16 Sep 2014, Manuel Bouyer wrote:


How do you say which driver you want in the kernel config file then ?


In my case I have vendor / product IDs to help determine the board type.

Interesting problem though -- and I missed the part where you were using 
an external i2c controller the first time through. I'm working on a 
similar driver for the Cubieboard2 at the moment but the i2c controller is 
part of the HDMI module, so I can simply use dev/i2c/ddc.c from there.


Do you plan on running the HDMI output and framebuffer at the same 
resolution? The reason I ask is that for cubie I was thinking to run the 
framebuffer at a fixed resolution, let HDMI configure itself 
automatically, and use the scaler to make it all work. Then to get a 
native mode right mode for X, expose the display info with 
WSDISPLAYIO_GET_EDID and have the X driver pick a new mode to use. I'm 
not confident in wsdisplay's ability to handle hotplug / mode changes for 
the console device. Maybe someone can prove me wrong :)

Re: HDMI transmitter attachement

[Jared McNeill]

On Tue, 16 Sep 2014, Manuel Bouyer wrote:

And what about other boards ? Or beaglebone capes using a different
wiring, or a different video driver (e.g. VGA output).


I would leave that as a problem for other boards :)

Capes have their own EEPROM I think for detecting them.

Re: HDMI transmitter attachement

[Jared McNeill]

On Tue, 16 Sep 2014, Manuel Bouyer wrote:


Actually I'd like to see my work reusable for other boards ...


Doesn't mean that it's not reusable, just that other boards 
device_register have to specify the tranceiver type.



Capes have their own EEPROM I think for detecting them.


Not all of them (I have one which did came with an empty prom).
And when I proposed to use the a device tree to drive the kernel's autoconf
(among other things to be able to reuse the beablebone's eprom contents)
it was rejected ...


Device tree would be great! Or at least fixing uboot to pass uenv 
variables.

Module auto-unloading (was Re: CVS commit: src/sys/arch/x86/x86)

[Jared McNeill]

We could use the reference counter in struct cfdriver to keep driver 
modules busy, but I'm not sure if the system can figure out what's 
unneeded if a needed driver might be one for a hotpluggable device. 
Would you treat those drivers differently? What about drivers (if_ath_pci 
comes to mind) that can be used both for fixed or hotplug devices?


I played around with driver module autoloading a while back, and it worked 
pretty well but the implementation I came up with required duplicating 
match data in module.plist.


On Tue, 18 Oct 2011, Warner Losh wrote:



On Oct 18, 2011, at 4:39 AM, Jared McNeill wrote:

I would argue that any manually loaded module shouldn't be autounloaded. What 
do you think about flagging modules as autoloaded and only autounloading the 
autoloaded ones?


If I manually load a dozen drivers at boot because I have a dozen different boards with 
different devices.  I'd kinda like the system to automatically figure out what isn't 
needed and unload those drivers.

Warner


On Tue, 18 Oct 2011, Jukka Ruohonen wrote:


On Tue, Oct 18, 2011 at 08:43:46AM +0200, Marc Balmer wrote:

Am 18.10.11 06:27, schrieb Jukka Ruohonen:

On Tue, Oct 18, 2011 at 12:07:45AM +, Jared D. McNeill wrote:

Module Name:src
Committed By:   jmcneill
Date:   Tue Oct 18 00:07:45 UTC 2011

Modified Files:
src/sys/arch/x86/x86: vmt.c

Log Message:
don't allow module autounload


I wonder should autounloading be prohibited for all driver-class modules?


Why?  When the parent goes away, why not autounload a driver?


I am not sure. But have we thought about all the consequences and corner-
cases? Unloading happens while modifying hardware state? Deferred calls
in the drivers? And so on? To me it also seems that if I manually load
a driver-module, I expect it to stay loaded until I unload it.

- Jukka.

Re: Module auto-unloading (was Re: CVS commit: src/sys/arch/x86/x86)

[Jared McNeill]

I think you'd just need to find a way to supply that data for built-in 
modules too.


On Tue, 18 Oct 2011, David Young wrote:


On Tue, Oct 18, 2011 at 11:28:22AM -0400, Jared McNeill wrote:

I played around with driver module autoloading a while back, and it
worked pretty well but the implementation I came up with required
duplicating match data in module.plist.


This sounds like a step in the right direction (recording match data
in a plist, not duplicating it). What would it take to get rid of the
non-plist match data?

Dave

--
David Young OJC Technologies is now Pixo
dyo...@pixotech.com Urbana, IL   (217) 344-0444 x24

Re: pci_mapreg_map(9) and prefetchable BARs

[Jared McNeill]

On Wed, 10 Aug 2011, Michael wrote:
I don't think there's any MMU out there which could apply anything like 
this to something smaller than a page. No idea which granularity x86 
MTRRs allow but it's probably not that small either.


FYI for BUS_SPACE_MAP_PREFETCHABLE on x86 we actually use the Page 
Attribute Table (PAT), not MTRRs.


http://en.wikipedia.org/wiki/Page_Attribute_Table

Cheers,
Jared

Re: xorg pci probing

[Jared McNeill]

One nit:

+wsdisplayio_busid_pci(device_t self, pci_chipset_tag_t pc,
+pcitag_t tag, void *data)
+{
+   struct wsdisplayio_bus_id *busid = data;
+
+   busid-bus_type = WSDISPLAYIO_BUS_PCI;
+   busid-ubus.pci.domain = device_unit(device_parent(self));

Please add a KASSERT here, as this doesn't do the right thing in all 
cases, consider the following:


  mymfdev0 at pci1 dev 3 function 0
  mymfdevfb0 at mymfdev0
  wsdisplay0 at mymfdevfb0

   ^ will get a 'domain' of 0 instead of the desired 1

The KASSERT should look like this:

  KASSERT(device_is_a(device_parent(self), pci))