The youngest architecture addition to the mainline Linux kernel was C-Sky (arch/csky/).

I have a GX6605S board booting a downstream 4.9 kernel. It uses a proprietary GxLoader bootloader (similarities with U-Boot exist but no sources...) with uImage and gx6605s.dtb files in a FAT partition on USB stick.

I prepared a csky-elf GCC cross-toolchain and would like to try building and booting a mainline kernel on that board. This will involve writing a mainline-compatible .dts for this board that, if successful, I could contribute upstream.

Besides learning about this architecture and any commonalities and differences, I am curious whether I can use the 3 accessible GPIOs on the board for connecting any radio transceivers for testing my LoRa, FSK, etc. kernel network drivers. Too little for bit-banging SPI, I guess, and seemingly no pin-muxing to UART. Maybe some I²C sensor though?

Looking for hackers with the skills:

csky kernel

This project is part of:

Hack Week 18

Activity

  • over 5 years ago: lyan liked this project.
  • over 5 years ago: a_faerber added keyword "csky" to this project.
  • over 5 years ago: a_faerber added keyword "kernel" to this project.
  • over 5 years ago: a_faerber started this project.
  • over 5 years ago: a_faerber originated this project.

  • Comments

    • a_faerber
      over 5 years ago by a_faerber | Reply

      It was confirmed today that upstream GCC is still lacking support for ck610. So my sub-project of packaging a csky-elf abiv1 cross-compiler is dead for now.

    • a_faerber
      over 5 years ago by a_faerber | Reply

      Yesterday compiled and booted mainline and linux-next kernels (up to an error executing the init process), sending out a patch for the Device Tree I derived.

    Similar Projects

    Hacking on sched_ext by flonnegren

    Description

    Sched_ext upstream has some interesting issues open for grabs:

    Goals

    Send patches to sched_ext upstream

    Also set up perfetto to trace some of the example schedulers.

    Resources

    https://github.com/sched-ext/scx


    Create DRM drivers for VESA and EFI framebuffers by tdz

    Description

    We already have simpledrm for firmware framebuffers. But the driver is originally for ARM boards, not PCs. It is already overloaded with code to support both use cases. At the same time it is missing possible features for VESA and EFI, such as palette modes or EDID support. We should have DRM drivers for VESA and EFI interfaces. The infrastructure exists already and initial drivers can be forked from simpledrm.

    Goals

    • Initially, a bare driver for VESA or EFI should be created. It can take functionality from simpledrm.
    • Then we can begin to add additional features. The boot loader can provide EDID data. With VGA hardware, VESA can support paletted modes or color management. Example code exists in vesafb.


    Create a DRM driver for VGA video cards by tdz

    Yes, those VGA video cards. The goal of this project is to implement a DRM graphics driver for such devices. While actual hardware is hard to obtain or even run today, qemu emulates VGA output.

    VGA has a number of limitations, which make this project interesting.

    • There are only 640x480 pixels (or less) on the screen. That resolution is also a soft lower limit imposed by DRM. It's mostly a problem for desktop environments though.
    • Desktop environments assume 16 million colors, but there are only 16 colors with VGA. VGA's 256 color palette is not available at 640x480. We can choose those 16 colors freely. The interesting part is how to choose them. We have to build a palette for the displayed frame and map each color to one of the palette's 16 entries. This is called dithering, and VGA's limitations are a good opportunity to learn about dithering algorithms.
    • VGA has an interesting memory layout. Most graphics devices use linear framebuffers, which store the pixels byte by byte. VGA uses 4 bitplanes instead. Plane 0 holds all bits 0 of all pixels. Plane 1 holds all bits 1 of all pixels, and so on.

    The driver will probably not be useful to many people. But, if finished, it can serve as test environment for low-level hardware. There's some interest in supporting old Amiga and Atari framebuffers in DRM. Those systems have similar limitations as VGA, but are harder to obtain and test with. With qemu, the VGA driver could fill this gap.

    Apart from the Wikipedia entry, good resources on VGA are at osdev.net and FreeVGA


    Linux on Cavium CN23XX cards by tsbogend

    Before Cavium switched to ARM64 CPUs they developed quite powerful MIPS based SOCs. The current upstream Linux kernel already supports some Octeon SOCs, but not the latest versions. Goal of this Hack Week project is to use the latest Cavium SDK to update the Linux kernel code to let it running on CN23XX network cards.


    Officially Become a Kernel Hacker! by m.crivellari

    Description

    My studies as well my spare time are dedicated to the Linux Kernel. Currently I'm focusing on interrupts on x86_64, but my interests are not restricted to one specific topic, for now.

    I also "played" a little bit with kernel modules (ie lantern, a toy packet analyzer) and I've added a new syscall in order read from a task A, the memory of a task B.

    Maybe this will be a good chance to...

    Goals

    • create my first kernel patch

    Resources

    Achivements