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
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, Jare
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
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
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
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
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
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...
[
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
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
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
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
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
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
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
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
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.
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)`.
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
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.
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
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
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
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 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
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,
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
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
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
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...
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
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
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,
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
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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
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
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
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
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
52 matches
Mail list logo
