Raspberry Pi port

[LdB]

I am going to start a port of ChibiOS for both 32 and 64 bit on all the various models of the Raspberry Pi

I recently completed the conversion of FreeRTOS 10.1.1 to that end and want to compare both
https://github.com/LdB-ECM/Raspberry-Pi ... TOSv10.1.1

I have downloaded ChibiOS 18.2.1 but the file layout is throwing me and I can't find any examples of porting help and I am trying to get my head around the different versions ChibiOS/RT, ChibiOS/HAL etc.

I would imagine the Pi will be like a Windows or Linux port, we have a CPU model, a board model at it's base and for debugging you can direct the kernel to uart or screen.

Anyhow who can throw me hints or a links would be greatly appreciated.

[Giovanni]

Hi,

There are 3 layers to consider:
- Kernel port.
- HAL port.
- Board port.

The kernel port should be the existing ARM one: /os/common/ports/ARM

The HAL port is where you support the peripherals of your devices, most work goes here: /os/hal/ports <- create a new one here

The board port is the setup for your specific board: /os/hal/boards <- create a new one here

Then you need a demo application to integrate and test the above. If you need to port just the RTOS without HAL then there is very little to do.

Giovanni

[LdB]

Nice, clean, easy setup ... cheers

Update:
Actually I have a quick problem to discuss.

The stack alignment on a Pi is just a defined size based on model, cpu mode etc it can't be a type .. this current definition doesn't really work
#define PORT_STACK_ALIGN sizeof (stkalign_t)
In that stkalign_t I want to define at runtime, not statically so I want something like
#define PORT_STACK_ALIGN (some size defined by a runtime variable)

Mostly there wasn't an issue as stkalign_t is used mainly in header stuff, but it does appear in osapi.c and I need to do a bit with it to make it work at runtime. There are a couple of ways to hack around it so just wondering if you have a preference.

The second part to that is when calling external ABI C code I need different alignment which I believe this is the same
#define PORT_WORKING_AREA_ALIGN sizeof (stkalign_t)

It doesn't talk about external ABI calls but "Working Areas alignment constant" but I don't recognize that term.
So in normal technical terms Pi the internal ABI calls and the external ABI calls have different alignment is that term referring to an external ABI call?

The PI3 AARCH64 is probably like Linux or Windows 64 bit in that any Chibios execution won't know if it is 32 or 64 bit until the demo/application itself launches, so this has to all be sorted out at runtime as you launch the bootstub for the RTOS. That is the complication that would probably never exist on a small MCU where that is all really static.

Is this CPU number okay, I don't see how I know what number to assign
#define ARM_CORE_CORTEX_A53 110

Finally I don't see any FPU register save options on context switching, is Chibios strictly soft FPU or am I blind?

[LdB]

Getting close just a few issues above to sort but I have another issue with the function "port_is_isr_context"
There is no way to detect that you are in an irq from any flags from the CPU in 64 bit mode as you are in EL1 in interrupt or O/S.

So needing a rethink of this .. my thought is do what freeRTOS does count nesting depth which when 0 means not in irq
Do you have any other CPU ports that have this issue?
So this is the translation you can see the issue I have at ?????

Code: Select all

static inline bool port_is_isr_context(void) {
  syssts_t sts;

#if defined(THUMB)
  sts = _port_get_cpsr();
#else
   #if __aarch64__ == 1
     ????? this can't be done in aarch64 need to rethink this
   #else
   __asm volatile ("mrs     %[p0], CPSR" : [p0] "=r" (sts) :);
   #endif
#endif

  /*lint -save -e530 [9.1] Asm instruction not seen by lint.*/
  return (sts & (syssts_t)0x1F) == (syssts_t)0x12;
  /*lint -restore*/
}

Finally I don't understand the difference between port_suspend and port_lock they even equate to the same opcodes as do port_enable and port_unlock.

If it helps this my current chcore.h changes to cater for AARCH64
https://github.com/LdB-ECM/Exchange/blo ... S/chcore.h

[steved]

There's a port of an older version of ChibiOS to the Pi which might give you some ideas:
http://www.stevebate.net/chibios-rpi/Ge ... arted.html
https://www.raspberrypi.org/forums/view ... p?p=185362

[LdB]

No the old port is 32bit almost nothing of it is of any use for 64bit not even the registers have the same name.

So I really just need to work thru a couple of these problems with how the Chibios maintainer wants to deal with them.
This is all low level stuff as you come up it gets easier because you can code around problems.

On AARCH64 for example FPU is manditory but the FPU exceptions are optional
A decent summary of the AARCH64 ABI and calling convention is shown here
http://shervinemami.info/arm64bit.html

In the short term I can get around the FPU by telling GCC to only use general registers but long term I will have to deal with the FPU which means
it has to go into the context switch.

Things like if I want to know if I am in an interrupt, I have to organize via the interrupt handler there are no flags or special states on the CPU.

[Giovanni]

AARCH64 would require a new port, similar to the ARM one but still a different thing. In addition you will also need to take care of startup files, link files, makefiles etc.

I suggest to start from the base: startup and anything required for build.

Giovanni

[LdB]

I am close to finishing!!!

The makefiles are trivial although you have a lot of directories I have to have on the include chain which is annoying like this

# The startup directory should have a directory to match the platform string
# In that directory is a Makerules file that specifies what .C and .S files to include
# They will appear in the C_FILES and S_FILES lists respectively
# (The startup should always be first entry, ensuring the image starts with it if you want multiple directories.)
SYSCOMPS := $(TOP_DIR)/os/common/startup/$(PLATFORM)
INCLUDEPATH1 ?= $(TOP_DIR)/os/common/startup/$(PLATFORM)
INCLUDEPATH2 ?= $(TOP_DIR)/os/rt/include
INCLUDEPATH3 ?= $(TOP_DIR)/os/common/ports/ARM
INCLUDEPATH4 ?= $(TOP_DIR)/os/common/ports/ARM/compilers/GCC
INCLUDEPATH5 ?= $(TOP_DIR)/os/license

I provide my own startup files, I carry it as a standard and it has all the context switch stuff already setup which is the reason for my next 2 question

Question 1)
what is the currently running thread called and is it a global thread_t* .. I haven't crawled thru the scheduler yet which is where I guess I will find it accessed.
Question 2)
Can I move the context structure up to the first item in ch_thread, the reason is it means in 32 or 64bit I know the offset (being 0) within the structure so the context switch code doesn't need to know the structure at all. At the moment depending if it launches 32 or 64 bit that offset in the structure moves because of struct padding.

Code: Select all

struct ch_thread {
  threads_queue_t       queue;      /**< @brief Threads queue header.       */
  tprio_t               prio;       /**< @brief Thread priority.            */
  struct port_context   ctx;        /**< @brief Processor context.          */

[LdB]

You have a couple of warnings being thrown from code as well ... I will pragma them out for now

./os/common/oslib/include/chfifo.h: In function 'chFifoSendObjectI':
./os/common/oslib/include/chfifo.h:238:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
msg = chMBPostI(&ofp->mbx, (msg_t)objp);
^
./os/common/oslib/include/chfifo.h: In function 'chFifoSendObjectS':
./os/common/oslib/include/chfifo.h:255:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
msg = chMBPostTimeoutS(&ofp->mbx, (msg_t)objp, TIME_IMMEDIATE);
^
./os/common/oslib/include/chfifo.h: In function 'chFifoSendObject':
./os/common/oslib/include/chfifo.h:272:36: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
msg = chMBPostTimeout(&ofp->mbx, (msg_t)objp, TIME_IMMEDIATE);

I am up to doing a demo app

[Giovanni]

Hi,

1) It is ch.rlist.current, you should not need to access it directly working on a port.

2) You can't because the thread structure is a list item, offsets are important, in general you should not touch anything in portable code, everything should be done in the port layer.

Giovanni