Circle - C++ bare metal environment (with USB)

[rst]

@blippy For 32-bit operation I'm still using a slightly patched version of Andrew Baumann's QEMU fork for the RPi 2, which has USB support and provides the system timer, which is needed by Circle in 32-bit mode:

https://github.com/rsta2/qemu

You should add the following line before building the Circle libraries and samples for 32-bit QEMU usage to Config.mk then:

Code: Select all

DEFINE += -DNO_PHYSICAL_COUNTER -DUSE_QEMU_USB_FIX

This QEMU version will be started with:

Code: Select all

qemu-system-arm -M raspi2 -bios kernel7.img

You do not need to prepare a SD card image, if the sample program is not accessing a SD card and the firmware files do not need to be provided. This is all done by QEMU itself. Please note, that the option for providing the kernel image is "-bios" here, not "-kernel".

You may have a look at this file for more info on using QEMU with Circle.

[blippy]

Building the custom version of qemu is difficult. There are some warnings that cause the build to bail out. So I did

Code: Select all

../configure --disable-werror --target-list=arm-softmmu

Now I'm getting:

Code: Select all

  LINK  arm-softmmu/qemu-system-arm
/usr/bin/ld: cpus.o: in function `icount_warp_rt':
/home/pi/Documents/qemu/cpus.c:343: undefined reference to `__atomic_load_8'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:195: qemu-system-arm] Error 1
make: *** [Makefile:186: subdir-arm-softmmu] Error 2

Possibly I have to add a link to "-latomic".

Might there be a quick way to fix this without going through the whole build process again?

Update: scratch that! I managed to get a build from my Ubuntu box. qemu-system-arm now launches my image. And it works! Cool. I have some interesting ideas what to do with circle.

I've now got the console working, as well as keyboard input. Phew.

[rst]

Update: scratch that! I managed to get a build from my Ubuntu box. qemu-system-arm now launches my image. And it works! Cool. I have some interesting ideas what to do with circle.

Great!

Unfortunately this QEMU fork is relatively old and does not build on some platforms. But it's the only one I know, which supports the USB host controller of the RPi 2 and so networking too.

Thanks for being interested in Circle!

[blippy]

Thanks for being interested in Circle!

You're welcome. I've got a cool idea for a project.

I managed to get your version of qemu working on Ubuntu 18.10. 18.10 is out of support now, so I can't install the cross-platform compiler. But I can compile circle on my Pi3. So I compile it on Pi3 and run it on Ubuntu via a fuse mounted share drive. Oh well, the important thing is that it works.

Thanks for your help. It was invaluable.

[rst]

You should be able to use a cross toolchain from here on your Ubuntu. It only needs to be downloaded and extracted (no further install). Take the AArch32 bare-metal target (arm-none-eabi). The executables are in the bin/ subdirectory after extraction, which should be added to your PATH environment variable. You are welcome.

[blippy]

You should be able to use a cross toolchain from here on your Ubuntu.

Thanks for that. I went ahead with your suggestion, and it works fine. I'm glad I followed it, because I get better build times that way. Plus it's a more convenient solution, too.

I've managed to get my UK keyboard working, too, so everything is looking good.

[blippy]

@rst. I'm trying out sample/15-files on real hardware. It reports

Code: Select all

Partition not found: usmd1-1

I'm just trying to access the first partition (i.e. VFAT) on the SD card.

I also tried PARTITION umsd1-0, but that didn't work either.

[rst]

@rst. I'm trying out sample/15-files on real hardware. It reports

Code: Select all

Partition not found: usmd1-1

I'm just trying to access the first partition (i.e. VFAT) on the SD card.

This sample works with USB mass-storage devices (e.g. flash drives) only. For SD card access have a look on addon/SDCard or addon/fatfs. Both have a sample subdirectory.

[blippy]

This sample works with USB mass-storage devices (e.g. flash drives) only. For SD card access have a look on addon/SDCard or addon/fatfs. Both have a sample subdirectory.

Thanks. I checked out your suggestion, and it works!

Circle is impressive. I'm glad I didn't have to write all this stuff myself. The examples have proven vital, too.

I wonder, have you heard of the rumpkernel, whose aim is to make the drivers in NetBSD portable as a library? I've never used it myself, but it seems a good concept.

[rst]

@blippy Thanks. I heard of rump kernels for the first time now. I did some quick reading. The concept is interesting, but I'm not sure, if there is still much activity in this project?

[blippy]

@blippy Thanks. I heard of rump kernels for the first time now. I did some quick reading. The concept is interesting, but I'm not sure, if there is still much activity in this project?

I did read somewhere that the guy abandoned it to brew beer. I'm sure there's more to it than that, though. I'll be honest and say I've only the vaguest idea of it, and NetBSD, too.

My overall impression is that NetBSD is designed to be HIGHLY portable, and there's good separation between the drivers and the "kernel", which I think really means "scheduler". NetBSD, of course, provides its own scheduler, giving everyone a Unix-like clone. But you don't have to use it. It has an "AnyKernel", which I take to mean "insert your kernel here".

I don't think you necessarity even need a "scheduler". Maybe you just want to run one process.

I think Andy Tanenbaum is/was porting his Minix kernel to NetBSD.

If it all does what I think it does, then it seems like an excellent way of going about things: a librray OS ("unikernel") from which to build your own kernel. It almost seems like the Holy Grail, as NetBSD is designed with portability in mind. You get all the donkeywork of the drivers done for you, and you just add your own flavour of scheduler/security model (or lack)/anything else on top of it. Why write code for the Fat filesystem, when NetBSD will give it to you. Assuming I've understood it right.

I guess it's a bit like FreeRTOS, which aims to provide a whole bunch of libraries; although it does stipulate a scheduling model. RTOS (Real-Time Operating System) seems to be targetted more towards microcontrollers. I have used it on an ESP32, for example, and I liked it a lot.

I don't know the state of play of FreeRTOS on the Pi, though. FreeRTOS doesn't seem to think that the Pi is important; even though they target a tonne of MCUs (microcontrollers).

I'm surprised we don't have a really solid FreeRTOS port for the Pi, because it would seem like a really excellent thing to have. I've Googled around, and there seem to be ports, but I'm suspicious as to how well they work.

There are other RTOS's out there (Zephyr and ChibiOS spring to mind, although I have never tried them). I get the impression that what they promise they deliver and what they actually deliver are far apart.

[rst]

Removed

[macload1]

@blibby: I will not comment too much on FreeRTOS, as this thread is Circle related, but you may be assured, the FreeRTOS port located here: https://github.com/macload1/RPiFreeRTOSuGFX is working perfectly fine. I started from James Walmsley's port and ported it to the (then) actual version of FreeRTOS. I added graphics in form of the µGFX library and some low level libraries for UART, SPI, ... Dynamic heap (malloc, free) management also works as expected.
But you are right, these are user ports and not from (now) Amazon. I also only ported for the RPI Zero (W) and RPi 1, as I don't have the other versions.

[blippy]

the FreeRTOS port located here: https://github.com/macload1/RPiFreeRTOSuGFX

Thanks for the link.

[styro]

Hallo,
i am confused with a memory-problem, somehow delete / free doesn't give back the with new / malloc allocated memory.... probably i am doing something wrong :-/

Code: Select all

struct EventBox{
	lv_obj_t * EventContainer;
	lv_obj_t * HoriLine;
	lv_point_t HoriLine_points[2];
	lv_style_t HoriLine_style;
	lv_obj_t * HoriLabel;

	lv_obj_t * VertLine;
	lv_point_t VertLine_points[2];
	lv_style_t VertLine_style;
	lv_obj_t * VertLabel;
};

kernel.h

Code: Select all

class CKernel
{
public:
	CKernel (void);
	~CKernel (void);
private:
	EventBox *XXXEBox = NULL;
	and lots of other stuff...
}

kernel.cpp

Code: Select all

FormatText.Format("availpreXXXEBox mem %d",m_Memory.GetHeapFreeSpace(0));	
m_LVGScreen.SetErrorText((char *)&(*FormatText));
// XXXEBox = (EventBox*)malloc(sizeof(EventBox));
XXXEBox = new EventBox;
FormatText.Format("avail postXXXEBox mem %d",m_Memory.GetHeapFreeSpace(0));	
m_LVGScreen.SetErrorText2((char *)&(*FormatText));

the output of m_Memory.GetHeapFreeSpace(0)
967976672 before allocation
967975632 after malloc / new

Code: Select all

FormatText.Format("availpreXXXEBox Del mem %d",m_Memory.GetHeapFreeSpace(0));	
m_LVGScreen.SetErrorText((char *)&(*FormatText));
//free(XXXEBox);
delete XXXEBox;
FormatText.Format("avail postXXXEBox Del mem %d",m_Memory.GetHeapFreeSpace(0));	
m_LVGScreen.SetErrorText2((char *)&(*FormatText));

the output of m_Memory.GetHeapFreeSpace(0)
967975632 before
967975632 after free / delete

this is on a Raspi3B(+) with circle step 41.2 with gcc 9.2
Besides of that phenomenon, the rest of the project (with fatfs & littleVG) runs fine, its just something with the memory-allocating/freeing.

many thanks for some enlightenment!
good health and all the best!
styro

[rst]

i am confused with a memory-problem, somehow delete / free doesn't give back the with new / malloc allocated memory.... probably i am doing something wrong :-/

Hi styro, the value returned by m_Memory.GetHeapFreeSpace() is the free space, which has not been used for memory allocation at all before. If you have allocated a memory block and free it again, this block will be added to a free list of memory blocks and will be reused, if a block of the respective size is allocated again. But the free space reported by m_Memory.GetHeapFreeSpace() will not grow because of this. It would take too long to walk all free lists to calculate the exact free space. But don't worry, the memory space of the freed block is not lost.

good health and all the best!

The same to you!

[styro]

Many thanks for the clarification and keep up the excellent work!
all the best
styro

[_alex_p]

Congratulations Rene on great work you put in Circle! I have been following your work for a while now and it is getting better and better.
I have a question regarding the memory map in Circle. Looking at the memorymap.txt document it seems that there is a set limit to the size of kernel image (2MB Max):

Code: Select all

00008000	max. 2 MByte	Kernel image
				 .init			startup code
				 .text
				 .rodata
				 .init_array		static constructors
				 .ARM.exidx		C++ exception index
				 .eh_frame		unused
				 .data
				 .bss
...
				Kernel stacks
00208000	128 KByte	 for Core 0
00228000	128 KByte	 for Core 1		may be unused
00248000	128 KByte	 for Core 2		may be unused
00268000	128 KByte	 for Core 3		may be unused

I have looked in circle.ld and Rules.mk files and have not found where these addresses are defined. Is this rPI hardware related limitation? Is there a way to increase this to something larger like 16MB by shifting up the memory locations? Could a larger text section be moved to 0x00500000 and beyond?

[rst]

@_alex_p Thank you! The maximum size of the kernel image can be defined with the system option KERNEL_MAX_SIZE in include/circle/sysconfig.h or in Config.mk like that (e.g. for 16 MB):

Code: Select all

DEFINE += "-DKERNEL_MAX_SIZE=(16*MEGABYTE)"

The memory map in doc/memorymap.txt is for the default case of 2 MB.

[rdpdo]

@rst : Thanks you for information about memory avove 1GB

I've got another question (perhaps stupid one sorry)... Seems there is no class for accessing a camera module, so I'd like to play with it... My question is : For accessing CSI lines, may I used a special SPI interface ? Thanks !

EDIT : Sorry I've got the answer : https://github.com/6by9/raspiraw/blob/master/camera_i2c

But if someone have some ready to use code for circle for camera module V2 or HQ ... thanks !

[rst]

@rdpdo Camera support normally needs complex interaction with the firmware. Unfortunately this is not implemented in Circle.

[cjm42]

Is there a recommended way to use the standard C++ atomic classes within a Circle project?

Simply using "#include <atomic>" and adding the path to the .h files in the makefile seems to work. But is this the best way?

[rst]

@cjm42 The circle-stdlib project provides access to the C and C++ standard library and is based on Circle. Circle itself does not support classes from the C++ standard library.

[cjm42]

Thanks for the advice. I am now up and running with circle-stdlib.

[MikeDB]

Since I last looked at Circle almost a year ago I notice ARM have now added AArch64 Linux hosted cross compilers (https://developer.arm.com/tools-and-sof ... /downloads). Now we have the 64bit OS for the Pi4 this possibly means one could develop Circle on one Pi running Linux before transferring the compiled program to a second Pi. Or even with USB booting leave the SD card in the Pi and remove the USB boot so it reboots using Circle ?

Has anybody gone down this route - did it work or what were the roadblocks ?