Raspberry Pi port

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome. This forum is NOT for support.
LdB
Posts: 9
Joined: Tue Dec 11, 2018 7:09 am

Raspberry Pi port

Postby LdB » Tue Dec 11, 2018 7:33 am

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.

User avatar
Giovanni
Site Admin
Posts: 13008
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 742 times
Been thanked: 620 times
Contact:

Re: Raspberry Pi port

Postby Giovanni » Tue Dec 11, 2018 8:45 am

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
Posts: 9
Joined: Tue Dec 11, 2018 7:09 am

Re: Raspberry Pi port

Postby LdB » Tue Dec 11, 2018 2:29 pm

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
Posts: 9
Joined: Tue Dec 11, 2018 7:09 am

Re: Raspberry Pi port

Postby LdB » Tue Dec 11, 2018 5:11 pm

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
Posts: 730
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 10 times
Been thanked: 105 times

Re: Raspberry Pi port

Postby steved » Tue Dec 11, 2018 10:21 pm

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
Posts: 9
Joined: Tue Dec 11, 2018 7:09 am

Re: Raspberry Pi port

Postby LdB » Wed Dec 12, 2018 2:30 am

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.

User avatar
Giovanni
Site Admin
Posts: 13008
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 742 times
Been thanked: 620 times
Contact:

Re: Raspberry Pi port

Postby Giovanni » Wed Dec 12, 2018 8:46 am

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
Posts: 9
Joined: Tue Dec 11, 2018 7:09 am

Re: Raspberry Pi port

Postby LdB » Wed Dec 12, 2018 4:38 pm

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
Posts: 9
Joined: Tue Dec 11, 2018 7:09 am

Re: Raspberry Pi port

Postby LdB » Wed Dec 12, 2018 5:04 pm

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 :-)
Last edited by LdB on Wed Dec 12, 2018 5:07 pm, edited 1 time in total.

User avatar
Giovanni
Site Admin
Posts: 13008
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 742 times
Been thanked: 620 times
Contact:

Re: Raspberry Pi port

Postby Giovanni » Wed Dec 12, 2018 5:06 pm

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


Return to “Development and Feedback”

Who is online

Users browsing this forum: Google [Bot] and 4 guests