[9front] Debugging driver/kernel space

[9front] Debugging driver/kernel space

[Sebastian Gsänger]

Hi,

I'm trying to control a ws2812 led Hat via RPi GPIO pins using dma/pwm
(as done here: https://github.com/jgarff/rpi_ws281x).
This requires accessing RPi peripherals, i.e. writing to physical addresses.

My current plan is to write a driver similar to bcm/gpio.c and
bcm/devgpio.c.
Is there a way to have better debug cycle than recompile->reboot->hope
it works?
Any way to attach a debugger to kernel code, or even run code with
access to the registers from within a running system?

Thanks
Sebastian

Re: [9front] Debugging driver/kernel space

[adventures in9]

There is an option to setup an "arch" filesystem.  It shows up kernel
device '#P'.

It is used on amd64 to do things like read the cpu temperature or
check irq settings.  You can make a synthetic file that does pretty
much anything though, like read or write to some particular memory
address for IO on peripherals.

https://github.com/driusan/9front-A64/blob/main/devarch.c

This has some examples of setting up files to do debugging stuff on a
Pinephone, like read the cpu temp, set the cpu clock speed, check all
the interrupts, read from various gpio like pins.

On Sat, Apr 5, 2025 at 9:44 AM Sebastian Gsänger
<sebastian_gsaenger@web.de> wrote:
>
> Hi,
>
> I'm trying to control a ws2812 led Hat via RPi GPIO pins using dma/pwm
> (as done here: https://github.com/jgarff/rpi_ws281x).
> This requires accessing RPi peripherals, i.e. writing to physical addresses.
>
> My current plan is to write a driver similar to bcm/gpio.c and
> bcm/devgpio.c.
> Is there a way to have better debug cycle than recompile->reboot->hope
> it works?
> Any way to attach a debugger to kernel code, or even run code with
> access to the registers from within a running system?
>
> Thanks
> Sebastian
>

Re: [9front] Debugging driver/kernel space

[Sebastian Gsänger]

Thanks, looks like an interesting entry point for my first steps!

On 4/5/25 7:05 PM, adventures in9 wrote:
> There is an option to setup an "arch" filesystem.  It shows up kernel
> device '#P'.
>
> It is used on amd64 to do things like read the cpu temperature or
> check irq settings.  You can make a synthetic file that does pretty
> much anything though, like read or write to some particular memory
> address for IO on peripherals.
>
> https://github.com/driusan/9front-A64/blob/main/devarch.c
>
> This has some examples of setting up files to do debugging stuff on a
> Pinephone, like read the cpu temp, set the cpu clock speed, check all
> the interrupts, read from various gpio like pins.
>
> On Sat, Apr 5, 2025 at 9:44 AM Sebastian Gsänger
> <sebastian_gsaenger@web.de> wrote:
>> Hi,
>>
>> I'm trying to control a ws2812 led Hat via RPi GPIO pins using dma/pwm
>> (as done here: https://github.com/jgarff/rpi_ws281x).
>> This requires accessing RPi peripherals, i.e. writing to physical addresses.
>>
>> My current plan is to write a driver similar to bcm/gpio.c and
>> bcm/devgpio.c.
>> Is there a way to have better debug cycle than recompile->reboot->hope
>> it works?
>> Any way to attach a debugger to kernel code, or even run code with
>> access to the registers from within a running system?
>>
>> Thanks
>> Sebastian
>>