Shut the RPi2 down to connect a LED to gpio 19 to be sure it's working.
View attachment 303855
View attachment 303859
gpio 19 jumper connected to D1 (led) on the gertboard.

View attachment 303856
echo 0 > /sys/class/leds/moo/brightness
View attachment 303858
echo 1 > /sys/class/leds/moo/brightness

With:
root@raspberrypi:~# echo cpu > /sys/class/leds/moo/trigger
root@raspberrypi:~# echo heartbeat > /sys/class/leds/moo/trigger

It blinks.

If I ever make a post-democracy dystoian future movie featuring the janky rebel/anti-empire spaceship crewed with misfits—I am going to have you build the spaceship set. Heck, I might cast you as the brilliant autodidact ship’s engineer who has to buld and maintain the ship with whatever can be bought, borrowed, or slavaged including everything from the latest SotA empire technology to 200-year old Eimac power tubes.

Of course the ship will always just be on the verge of failing but somehow it will not only keep running but outrun the latest empire pursuit craft.

 

If I ever make a post-democracy dystoian future movie featuring the janky rebel/anti-empire spaceship crewed with misfits—I am going to have you build the spaceship set. Heck, I might cast you as the brilliant autodidact ship’s engineer who has to buld and maintain the ship with whatever can be bought, borrowed, or slavaged including everything from the latest SotA empire technology to 200-year old Eimac power tubes.

Of course the ship will always just be on the verge of failing but somehow it will not only keep running but outrun the latest empire pursuit craft.

I have a deep and very dusty electronic junk box.

Maybe, I'm part Russian.

 

I've gone through the provided code, and it appears that these are kernel driver programs. They seem to be responsible for managing LED triggers

Yes, it means another trip down the abstraction rabbit-hole to the Linux gpio sub-system: https://www.kernel.org/doc/html/v4.17/driver-api/gpio/intro.html

Here, again is a simple GPIO driver example.
https://embetronicx.com/tutorials/linux/device-drivers/gpio-driver-basic-using-raspberry-pi/

Accessing the GPIO in Linux Kernel
If anyone wants to access the GPIO from the Kernel GPIO subsystem, they have to follow the below steps.

1. Verify whether the GPIO is valid or not.
2. If it is valid, then you can request the GPIO from the Kernel GPIO subsystem.
3. Export the GPIO to sysfs (This is optional).
4. Set the direction of the GPIO
5. Make the GPIO to High/Low if it is set as an output pin.
6. Set the debounce interval and read the state if it is set as an input pin. You enable IRQ also for edge/level triggered.
7. Then release the GPIO while exiting the driver or once you are done.

The APIs used to do the above steps are given below. Keep reading guys.

It's possible, at the kernel driver level, to bypass (talk directly to registers like on a typical controller) the gpio sub-system but that's cheating and is completely non-portable even across the RPi board spectrum.
The kernel abstraction of gpio seems complex until you compare it to what you need to know to write to the bare-metal hardware starting from zero knowledge of hardware drivers..

https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

The BCM2708 is an ARM SoC from Broadcom. It is the primary SoC in a series which contains the BCM2835 amongst other variants.
Bare-metal bit-banging example with kernel level system permissions.

#define PERI_BASE   0x3F000000
#define BCM2708_PERI_BASE        PERI_BASE

#define ST_BASE                  (BCM2708_PERI_BASE + 0x3000) 
#define GPIO_BASE                (BCM2708_PERI_BASE + 0x200000) /* GPIO */

/*
    gpioToGPSET:
    (Word) offset to the GPIO Set registers for each GPIO pin
 */

static uint8_t gpioToGPSET [] = {
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
    8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
    8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
};

/*
    gpioToGPCLR:
    (Word) offset to the GPIO Clear registers for each GPIO pin
 */

static uint8_t gpioToGPCLR [] = {
    10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
    10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
    11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11,
    11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11,
};

    dev->iobase = GPIO_BASE; /* bcm iobase */
    /* 
     * dev->mmio is a void pointer with 8bit pointer indexing, 
     * we need 32bit indexing so mmio is casted to a (__iomem uint32_t*) 
     * pointer for GPIO R/W operations 
     */
    dev->mmio = ioremap(dev->iobase, SZ_16K);
    if (!dev->mmio) {
        dev_err(dev->class_dev, "invalid gpio io base address!\n");
        return -EINVAL;
    }

static void digitalWriteGpio(struct comedi_device *dev,
    int32_t pin,
    int32_t value)
{

    pin &= 63;
    if (value == LOW)
        iowrite32(1 << (pin & 31), (__iomem uint32_t*) dev->mmio
        + gpioToGPCLR [pin]);
    else
        iowrite32(1 << (pin & 31), (__iomem uint32_t*) dev->mmio
        + gpioToGPSET [pin]);
}

 

Yes, it means another trip down the abstraction rabbit-hole to the Linux gpio sub-system:

I've reviewed the codes you shared in the link, but I'm struggling to understand their purpose. Could you please explain the benefits of these codes and why we need a device driver? It seems like having a device driver is essential for creating application programs

 

I've reviewed the codes you shared in the link, but I'm struggling to understand their purpose. Could you please explain the benefits of these codes and why we need a device driver? It seems like having a device driver is essential for creating application programs

No. Simply for the reason of my telling you does nothing to make you understand what's happening. The struggle is a necessary step to understanding. If you don't have the required background at this point to answer your questions, then you need to start from from the beginning to gain that knowledge.

 

No. Simply for the reason of my telling you does nothing to make you understand what's happening. The struggle is a necessary step to understanding. If you don't have the required background at this point to answer your questions, then you need to start from from the beginning to gain that knowledge.

I'm reading books and online documents , I decided to get hands-on with Raspberry Pi and LEDs to gain practically knowledge. I successfully downloaded the kernel source and compiled the code. However, when I looked into the source files across various folders like memory management, file management, and network management, and so many I found myself a bit lost.

I took your advice to explore device tree and managed to make an LED blink using a DTS file. My ultimate goal here is to write device drivers . I've come to realize that if the kernel lacks the necessary driver for a device, we must write our own.