Draft: Update to RTEMS 6

[c-mauderer]

I have rebased the necessary patches for RTEMS and libbsd to RTEMS 6 and updated the grisp2-rtems-toolchain. It was more a side effect of some other work. So I didn't test the new version yet on the hardware (therefore the Draft-status). If you want, you can test it and pull in the changes if everything works. That would solve #52. All patches for #42 and #50 are included too so that would close these pull requests too.

Note that I didn't push RTEMS and LibBSD to the GRiSP organization yet. The following two branches are necessary for this patch.

• https://github.com/c-mauderer/rtems/commits/cm/20240604_GRiSP_RTEMS6/
• https://github.com/c-mauderer/rtems-libbsd/commits/cm/20240604_GRiSP_RTEMS6/

[c-mauderer]

Note that at the moment building the toolchain doesn't work. Reason for this is the transition of the RTEMS environment to gitlab. Seems that the git.rtems.org has been switched off before the rtems-source-builder has been adapted to work with that. I asked about that on the RTEMS discord and someone is already working on it. So I think I can updated the pull request in a few days.

[ziopio]

I tried to build OTP and deploy on the board but unfortunatly it did not work.
The code mounts the partition of the SD card but fails at reading the grisp.ini

[ziopio]

Why is the bsp_specs file gone? Is'nt it needed anymore?

[c-mauderer]

The bsp_specs have been removed from RTEMS. They are not necessary any more. I'm not even sure whether they had been necessary in your version or whether they have been an empty file already.

Please note: The bsp.mk is also something that is not supported by RTEMS any more. It's a compatibility hack that it's still in the grisp2-rtems-toolchain. Maybe it would be a good idea to remove it some-when. The usual method now is to have an application specific make file that collects the necessary flags using pkg-config. For example that one:

https://gitlab.com/c-mauderer/rtems-simulation-environment/-/blob/b4f11188ed3467a0a5808e8ab2324ffe07012825/demo/Makefile

There is also the rtems_waf repo that you can use if you want to write an application with a waf based build system.

[c-mauderer]

I tried to build OTP and deploy on the board but unfortunatly it did not work. The code mounts the partition of the SD card but fails at reading the grisp.ini

Do you have a console output of the boot process?

[ziopio]

shell_output.txt
In(erl_main.c) we check if ini_parse returns -1 and then print the warning. Looking into rtems, ini_parse returns -1 if there is an error when opening the file. Now I want to test which error this might be if I try to open any other file...

[c-mauderer]

Thanks for the output.

mmcsd-0 has a few additional partitions (in the sense of these odd hardware partitions that appear as separate devices) like mmcsd0boot0, mmcsd0boot1 and mmcsd0rpmb which is typical for eMMC. Is it expected that the eMMC has that number or did the numbering change for some reason? I think I remember something that you had some special requirements there.

From the output:

• mmcsd-0-0 (first partition table entry on eMMC) seems to be mounted and ready.
• mmcsd-0-1 (second partition table entry on eMMC) where the mount failed.
• mmcsd-1-0 (first partition table entry on SD) seems to be mounted and ready.

But - and that could be important: The mount for the mmcsd-1-0 seemed to take longer than expected. There is already a line

[ERL] Reading /media/mmcsd-1-0/grisp.ini
[ERL] WARNING: /media/mmcsd-1-0/grisp.ini not found, using defaults

before the partition is mounted some lines later:

media listener: event = MOUNT, state = SUCCESS, src = /dev/mmcsd-1-0

[ziopio]

@c-mauderer The fact that we print SD card mounted but the media listener prints only later the success of the mount is sus. I thought that it was only a delay in the print and not in the actual mounting. I'll see if waiting a bit solves the issue.

[ziopio]

I can report that adding a delay skips this issue, looks like grisp_init_wait_for_sd doesn't do its job properly.
Now I finally get an erlang shell but strangely does not find the erl_inetrc. shell_output1.txt

Another interesting crash happens if I enable the wpa_supplicant:
shel_output2.txt

[c-mauderer]

Thanks for the tests. That are not the kind of problems I would have expected. Seems that there will be some debugging necessary.

Regarding the filesystem, it will be necessary to do some lower level checks. Like trying ls or cp on some files to see whether everything works as expected.

The WLAN is a bit odd too. It clearly detected the USB device which means that a lot of stuff worked. But it's a "device not configured". Maybe a problem with the firmware.

I'm not sure yet, when I'll find time to debug that.

[ziopio]

Ok the erl_inetrc was just me forgetting to put the file there, and the wpa_supplicant crashes if the erl_inetrc is not provided. So the only real problem for now is the grisp_init_wait_for_sd

[c-mauderer]

Ok the erl_inetrc was just me forgetting to put the file there, and the wpa_supplicant crashes if the erl_inetrc is not provided. So the only real problem for now is the grisp_init_wait_for_sd

That sounds great.

The grisp_init_wait_for_sd can return a RTEMS_SUCESSFUL or a RTEMS_TIMEOUT. I assume that your Erlang initialization checks that return value and would print some error if it is a timeout?

Maybe we have some conflict with the event number in libgrisp. Could be worth to replace that with a binary semaphore. If you can confirm, that you don't have a RTEMS_TIMEOUT, I'll replace that in libgrisp.

[ziopio]

Yep, we do not get a timeout, the code in erl_main.c is this one

  /* Wait for the SD card */
  grisp_led_set1(true, false, true);
  sc = grisp_init_wait_for_sd();
  if (sc == RTEMS_SUCCESSFUL) {
    printf("[ERL] SD card mounted\n");
  } else {
    printf("[ERL] ERROR: SD card could not be mounted after timeout\n");
    grisp_led_set1(true, false, false);
  }

I always see [ERL] SD card mounted so the catched event EVT_MOUNTED is the wrong one somehow.
Which is very odd since we check this in init.c in the media listener:

	if (event == RTEMS_MEDIA_EVENT_MOUNT &&
	    state == RTEMS_MEDIA_STATE_SUCCESS) {
		rtems_event_send(wait_mounted_task_id, EVT_MOUNTED);
	}

[ziopio]

@c-mauderer if you check https://github.com/user-attachments/files/15924257/shell_output.txt you can spot that
media listener: event = MOUNT, state = SUCCESS, src = /dev/mmcsd-0-0, dest = /media/mmcsd-0-0 precedes /media/mmcsd-1-0 logs. Is it possible that media_listener leaks the MOUNT SUCCESS -> EVT_MOUNTED event for mmcsd-0-0 when we are waiting for mmcsd-1-0 ?

[c-mauderer]

Is it possible that media_listener leaks the MOUNT SUCCESS -> EVT_MOUNTED event for mmcsd-0-0 when we are waiting for mmcsd-1-0 ?

Quite possible. The event is a bit hacked into that and doesn't differ between the SD cards. It just sends the event if anything has been successfully mounted.

We maybe would need some kind of interface to specify which SD card is the one the task waits for. Do you know that before the call to the grisp_init_wait_for_sd? In that case, we maybe could add a simple string argument.

You control quite some aspects from your Erlang code. Would it be more useful to process the media listener events there too so you have access to the full information? In that case, we maybe can just throw that part out of libgrisp and you register the media listener in your Erlang initialization code.

[ziopio]

We maybe would need some kind of interface to specify which SD card is the one the task waits for. Do you know that before the call to the grisp_init_wait_for_sd? In that case, we maybe could add a simple string argument.

Exactly, I tried moving the fdt code that sets the rootdir variable before SD initialization and works. So my plan would be to modify grisp_init_sd_card and pass rootdir to it. Then in media_listener use rootdir as argument and signal the mount event only when the destination matches what we got from the fdt.

You control quite some aspects from your Erlang code. Would it be more useful to process the media listener events there too so you have access to the full information? In that case, we maybe can just throw that part out of libgrisp and you register the media listener in your Erlang initialization code.

Not sure how much code would need to be rewritten to use erlang, plus we need the mount to succeed BEFORE we start the erlang VM, because we read the boot arguments from the grisp.ini file. So I do not see how it would be possible with a standard erlang app.

[c-mauderer]

We maybe would need some kind of interface to specify which SD card is the one the task waits for. Do you know that before the call to the grisp_init_wait_for_sd? In that case, we maybe could add a simple string argument.

Exactly, I tried moving the fdt code that sets the rootdir variable before SD initialization and works. So my plan would be to modify grisp_init_sd_card and pass rootdir to it. Then in media_listener use rootdir as argument and signal the mount event only when the destination matches what we got from the fdt.

If you touch that area, I would suggest to also replace the event by a condition variable. With that, you can avoid that you get problems if you call the grisp_init_wait_for_sd when the mount already happened.

You only need it once in the system, so a global variable that you set before the rtems_media_server_initialize would work. Alternatively (if you want the clean solution) you can pass it as a context parameter to the rtems_media_listener_add that can be used in the media_listener.

You control quite some aspects from your Erlang code. Would it be more useful to process the media listener events there too so you have access to the full information? In that case, we maybe can just throw that part out of libgrisp and you register the media listener in your Erlang initialization code.

Not sure how much code would need to be rewritten to use erlang, plus we need the mount to succeed BEFORE we start the erlang VM, because we read the boot arguments from the grisp.ini file. So I do not see how it would be possible with a standard erlang app.

I noted some [Erl] in the log before the SD so I thought you might have some minimal system running there already. If that's not the case, it's not worth the effort.

[ziopio]

I tried with the rtems condition variable and while it works, I loose the reaction to the timeout which I cannot set with those functions, we probably want to keep the old behaviour in case of mount errors.

[ziopio]

no_wpa.txt

Ethernet is ok and I can connect using TLS and the secure element, so that is nice. But the WPA supplicant looks like is stuck, it gets initialized but does not negotiate anything...

[c-mauderer]

Can you run the default shell ifconfig on the wlan0 interface? The FreeBSD ifconfig prints a lot of status information with that.

There has also been an update in the wpa supplicant during some libbsd update. If I remember correctly, there have been some problems with that software because an independent port upstreamed some changes that conflicted with the ones in our libbsd. I'm not sure whether it has been tested after that update. I maybe have to test that on some other platform.

[ziopio]

wlan0_not_exist.txt
I only managed to run ifconfig with the demo code. The ifconfig log is suspicious sayng interface wlan0 does not exist right before an info about wlan0...
info: wlan0: _bsd_ieee80211_new_state_locked: pending INIT -> SCAN transition lost
Looks like where it gets stuck