#Kyuthare (sounds like "cute hair")

Kyuthare? Thanks! It's all natural :P

Jokes aside, Kyuthare is Kyu + hare: Tom Trebisky's Kyu RTOS as a Harelang runtime.

The build system is a little unconventional and based on haredo and POSIX sh scripts. To build kyuthare, copy it to a tftpd server dir, and generate debugging files:

cd build/
haredo

Everything is controlled by the .do files in build/. First we compile all of the C sources, and then we pass them to the hare build driver to link with. The linker script used by hare (rt/hare+$arch.sc) is a symbolic link to the Kyu target linker script, which meets both hare's and Kyu's linking needs.

The entry point is provided by Kyu, and the hare runtime exposes itself to Kyu as the user_init() hook. Real user code may then export a main(arg: int64) void hare function for the runtime to execute, along with any functions tagged with @init and @fini as per usual.

Currently @test functions and +test sources are not supported.

Notice also that directories like net and console are both C source directories which produce module-like object files (net.o and console.o in this example) and hare modules interfacing that object for usage from hare code.

#Now / Status

working on fleshing out / re-enabling the init system, in hare (at least the H5-specific parts).

#Next

Of course! Tom still hasn't gotten H5 interrupts I don't think...

Also: see direct_vs_struct_gic_bypass

Try enabling interrupts and porting some of Tom's interrupt tests. Could work on a debuging console and start thinking about a test suite.

#Then

Try porting the spinlocks code.

Try porting Tom's interrupt-based uart. (rename the old uart_init to differentiate it, of course)

I figure the polling_uart implementation should remain as a fallback, but I don't yet know how that transition should go. My current rt/ does not have any fallback mechanism. As a first pass, I can probably just manually switch back to the polling interface in the handlers of certain fault/error cases.

Further thoughts: I can't actually use a proper interrupt UART until the cpu has interrupts enabled, so the fallback mechanism should be aware of whether or not interrupts are on...

#Later

in the future:

• I can probably use C inline functions to set mem_barriers (like is done in entry.S with macros) in my C sys_init
• I can write thread_abort() and thread_assert() to wrap rt/

#Design

target : board | laptop | desktop | server ...

sys : soc | motherboard ...

    arch_
    system_
    target_
    thread_
    mem_
    net_
    console_

    _intrpt_
    _timer_
    _uart_
    _gpio_

I expect that the soc (or motherboard) will be the most tightly-coupled component of the system, and so shall need the most tightly-coupled or complex code. I think that arch, being the most highly generalized, should be the most à la carte and function as a library for soc.

#Init

Startup call sequence:

1. arch_entry()
   • should do the bare minimum to get to...
2. sys_init()
   • should set up the basics for
     • interrupts
     • uart
     • mmu
     • caches (best effort)
3. target_init()
   • hmmm...
4. kyu_main()

Then kyu_main() may initialize system resources as needed by the user. For example:

• register interrupt handlers
• register timer call-backs
• change clock speeds

And some which are only needed if the user wants certain features like:

• multicore:
  • initialize other cores, with or without threads
• threads
  • timers (besides watchdog?)
• net:
  • emac
• gpio:
  • leds
  • direct pin control
  • pwm

#API

ToDo

#Headers

/types.h <---> /target/sys/arch/types.h

/target/board.h must include /types.h and one each of:

• clocks.h
• cores.h
• gpio.h
• uart.h
• interrupts.h
• memory.h
• spinlocks.h

from /target/, /target/../*common*/, or /target/sys/

so that code outside of /targets/ need only include /target/board.h

#Original README

Kyu project October 5, 2016

Kyu is a real time operating system for:

1. the BBB (Beaglebone Black).
2. the Orange Pi PC (H3 based board)

Eventually there will be more documentation here:

http://cholla.mmto.org/kyu

This is free software, protected under the GPL version 2 Kyu config system and file organization.

1-14-2017

At this point Kyu supports two boards in actual fact:

bbb - the Beaglebone Black orange_pi - the Orange Pi PC and PC plus

The "config" script should be used to set things up to build Kyu for a given board and/or to switch between boards>

Type:

./scripts/config bbb make

In the new scheme of things we have "board" and "arch" to keep things straight. "board" is a link to "bbb" or "orange_pi" and "arch" is a link to "arm" or "x86". This seems like a good scheme and has already led to a fair bit of code cleanup and simplification.

Someday we may introduce an include directory, and perhaps even a drivers directory to hold drivers that are shared between different boards.

In theory, Kyu also supports the x86 (Skidoo, which preceded Kyu only ran on a legacy x86). However Kyu has not run on an x86 for years and it is absolutely certain that the current codebase will not do so and will need serious work before it does.

It is entirely possible that the Intel Galileo will be the first (or next) x86 board to actually run Kyu, but making this happen is not a priority. The Galileo is interesting primarily because it has IO facilities, but the current crop of ARM based boards are both more powerful and less expensive, so the motivation even to work with the Galileo is weak. This ignores the additional fact that ARM is a much nicer architecture.

Modern desktop x86 systems provide little motivation for running Kyu. A system like Kyu is all about hardware access and modern x86 desktop machines have done away with parallel ports and the ISA bus and virtually every hardware interface with general purpose options.

The following are some old notes from when I was first thinking this through.

This is a proposed schema for supporting a multitude of boards (and perhaps architectures) under the same source tree. This would involve a reorganization of files, with the major benefit being that when board independent enhancements were made, it would be easy to simply rebuild all targets to pull in the changes. The alternative is a separate source tree (and kyu project) for every target and merging changes by hand.

boards and targets --

I use these terms interchangeably, but the file schema uses board exclusively

board and arch ... and config --

The case motivating this is a second ARM target. We have the BBB, but are adding the Orange Pi. What we would like to do someday is to type "config bbb; make" and get the build for a given board target. This would require a config script and a config directory holding Makefiles and perhaps scripts like "config_bbb" for each target. The Makefiles could be handled via symbolic links, as could many other things.

I plan to avoid adding drivers and include directories, at least for the first run. Where do we put directories with board files? For starters I plan to just leave them hanging off the main directory as bbb and orange_pi.

What about x86? I am simply going to procrastinate for now and leave all of this in the x86 directory. Ultimately we need board directories like "pc_x86" and "galileo". Maybe pc_legacy for the old skidoo target with lots of ISA stuff (maybe pc_isa). But for now we ignore all this and issue the disclaimer that all x86 target builds are broken at this time.

arch and board.

arch is a link to either arm or x86 board is a link to either bbb or orange_pi

There should be no direct references to anything other than arch or board.

The make process will produce machine.o from "arch" and board.o from "board".

We could someday move all of the arch independent stuff from the root directory to "common" or "core" (I like common myself).