EPOS issueshttps://gitlab.lisha.ufsc.br/epos/epos/-/issues2023-11-18T17:07:40Zhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/20RISCV sp and epc corruption2023-11-18T17:07:40ZThiago Augusto BewiahnRISCV sp and epc corruptionSporadic exceptions appear in most applications, but at an increased rate when running multicore with kernel (i.e. philosophers_dinner). Kernel and user stack pointers get swapped and corrupted, or epc is zeroed.
Timer interrupt influen...Sporadic exceptions appear in most applications, but at an increased rate when running multicore with kernel (i.e. philosophers_dinner). Kernel and user stack pointers get swapped and corrupted, or epc is zeroed.
Timer interrupt influence was already discarded. The main hypotheses are in Context's push/pop or interrupt handling, with a possibility of not dealing with privilege chances correctly.
Initial debug code was committed to the branch 'bewiahn'.EPOS 2.3Thiago Augusto BewiahnThiago Augusto Bewiahnhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/19Follow-up from "FZ3"2023-10-26T17:01:13ZAntônio Augusto Fröhlichguto@lisha.ufsc.brFollow-up from "FZ3"The following discussions from !44 should be addressed:
- [ ] @guto started a [discussion](https://gitlab.lisha.ufsc.br/epos/epos/-/merge_requests/44#note_1032):
> Doesn't make sense: there are two shorts in sequence!
- [ ] @guto...The following discussions from !44 should be addressed:
- [ ] @guto started a [discussion](https://gitlab.lisha.ufsc.br/epos/epos/-/merge_requests/44#note_1032):
> Doesn't make sense: there are two shorts in sequence!
- [ ] @guto started a [discussion](https://gitlab.lisha.ufsc.br/epos/epos/-/merge_requests/44#note_1036): (+1 comment)
> ???
- [ ] @guto started a [discussion](https://gitlab.lisha.ufsc.br/epos/epos/-/merge_requests/44#note_1037):
> This is done by the ERR handling if sterically_debugged is set!EPOS 2.3Leonardo Passig HorstmannLeonardo Passig Horstmannhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/18Memory overlap with SiFive U NIC2023-11-17T13:19:21ZThiago Augusto BewiahnMemory overlap with SiFive U NICWhen initializing the GEM descriptors, the heap pointer address (log_addr=0x80400060) is overwritten when writing to word 0 of the 13th RX descriptor. This descriptor has the same log address as the heap pointer. Then, in the next Heap::...When initializing the GEM descriptors, the heap pointer address (log_addr=0x80400060) is overwritten when writing to word 0 of the 13th RX descriptor. This descriptor has the same log address as the heap pointer. Then, in the next Heap::alloc() call, _this_ pointer is 0x21feef60 (phy_addr of the 13th descriptor buffer).
When using less than 13 buffers for RX and TX each (e.g. 8), even though a descriptor (now TX) is the same as the heap pointer address, writing to it doesn't cause the same behavior as before. Instead, the system becomes locked inside Alarm::init() when calling the Alarm_Timer constructor (probably corrupting a further heap address instead of the pointer).
The heap size is configured to be (MAX_THREADS + CPUS) * STACK_SIZE. When adding more memory (e.g. 100MB), the errors happen at the same places and behave the same, only with another DMA phy address.
The branch being used is [this](https://gitlab.lisha.ufsc.br/epos/epos/-/tree/MMU-bug-fix).
[nic_test_log_8_bufs.txt](/uploads/c120882f0e432dca4b3e0bcc5cde2e7b/nic_test_log_8_bufs.txt)
[nic_test_log_16_bufs.txt](/uploads/99adea79e29d0c291cfcf175a151b46a/nic_test_log_16_bufs.txt)Thiago Augusto BewiahnThiago Augusto Bewiahnhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/17Bug Report: Philosophers Dinner @ VisionFive22023-09-26T22:44:49ZJoão Paulo BonomoBug Report: Philosophers Dinner @ VisionFive2The philosophers dinner isn't working in **EPOS for INE5424** @ VisionFive 2.
The code generates an exception (id=5) that **means data protection violation (read)**.
With debugs, we can see that the exception is in **epc=0x00000000400012...The philosophers dinner isn't working in **EPOS for INE5424** @ VisionFive 2.
The code generates an exception (id=5) that **means data protection violation (read)**.
With debugs, we can see that the exception is in **epc=0x000000004000129a**, following the objdump, we see that this address contains the instruction {_ld a0,0(s1)_}. The protection violation occurs in register _a0_. This is inside the philosopher function, and the exception occurs before the chopstick Semaphore call _p()_ (line 93). I commented the _Delay thinking(1000000);_ (line 86), but the exception still occurs. In log file, we see that _wakeup_all()_ is the last function called before the exception occurs. This function is called 11 times in philosophers dinner, but the exception occursrs just in the 5 first (1 time for each philosopher thread before _Thread exit()_) and the debug added (line 292 in thread.cc) inside the _if(!q->empty())_ conditional wasn't printed.
To see the code, follow to
[https://gitlab.lisha.ufsc.br/epos/ine5424/-/tree/nic-plic-integration](epos/ine5424 nic-plic-integration).
OBS: The philosophers dinner execution log at VisionFive 2 and objdump are attached at this post.
[log_philosophers_dinner.txt](/uploads/fd7398fa7aaaad77acb109ca4b4ff848/log_philosophers_dinner.txt)
[objdump_symbols.txt](/uploads/f7f0fc72ebc45847b75fdb172f717919/objdump_symbols.txt)João Paulo BonomoJoão Paulo Bonomohttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/16NIC is defined for eMoteIII, which makes no sense2023-08-18T18:58:34ZLucas YotsuiNIC is defined for eMoteIII, which makes no senseI've been having some trouble when trying to compile the test program for the EposMoteIII. After talking to professor Antônio Augusto Fröhlich we were able to track it down to a couple macros on the _include/system/config.h_ file.
I cou...I've been having some trouble when trying to compile the test program for the EposMoteIII. After talking to professor Antônio Augusto Fröhlich we were able to track it down to a couple macros on the _include/system/config.h_ file.
I couldn't figure out a way to make a pull request so I'll post the fix here: All it takes is to remove lines 132-135 from the config.h files and it just works.
Before changes:
```cpp
#ifdef __mmod_emote3__
#define __cortex_m__
#define __cortex_m3__
#define __TSC_H __HEADER_ARCH(tsc)
#define __EEPROM_H __HEADER_MACH(eeprom)
#define __UART_H __HEADER_MACH(uart)
#define __SPI_H __HEADER_MACH(spi)
#define __RS485_H __HEADER_MACH(rs485)
#define __USB_H __HEADER_MACH(usb)
#define __I2C_H __HEADER_MACH(i2c)
#define __GPIO_H __HEADER_MACH(gpio)
#define __ADC_H __HEADER_MACH(adc)
#define __PWM_H __HEADER_MACH(pwm)
#define __WATCHDOG_H __HEADER_MACH(watchdog)
#define __NIC_H __HEADER_MACH(nic)
#define __modem__
#define __ieee802_15_4__
#define __tstp__
#define __ACCELEROMETER_H __HEADER_TRAN(accelerometer)
#define __GYROSCOPE_H __HEADER_TRAN(gyroscope)
#define __CO2_SENSOR_H __HEADER_TRAN(co2_sensor)
#define __PLUVIOMETER_H __HEADER_TRAN(pluviometer)
#define __PRESSURE_SENSOR_H __HEADER_TRAN(pressure_sensor)
#define __THERMOMETER_H __HEADER_TRAN(thermometer)
#define __HYGROMETER_H __HEADER_TRAN(hygrometer)
#endif
```
After changes:
```cpp
#ifdef __mmod_emote3__
#define __cortex_m__
#define __cortex_m3__
#define __TSC_H __HEADER_ARCH(tsc)
#define __EEPROM_H __HEADER_MACH(eeprom)
#define __UART_H __HEADER_MACH(uart)
#define __SPI_H __HEADER_MACH(spi)
#define __RS485_H __HEADER_MACH(rs485)
#define __USB_H __HEADER_MACH(usb)
#define __I2C_H __HEADER_MACH(i2c)
#define __GPIO_H __HEADER_MACH(gpio)
#define __ADC_H __HEADER_MACH(adc)
#define __PWM_H __HEADER_MACH(pwm)
#define __WATCHDOG_H __HEADER_MACH(watchdog)
#define __ACCELEROMETER_H __HEADER_TRAN(accelerometer)
#define __GYROSCOPE_H __HEADER_TRAN(gyroscope)
#define __CO2_SENSOR_H __HEADER_TRAN(co2_sensor)
#define __PLUVIOMETER_H __HEADER_TRAN(pluviometer)
#define __PRESSURE_SENSOR_H __HEADER_TRAN(pressure_sensor)
#define __THERMOMETER_H __HEADER_TRAN(thermometer)
#define __HYGROMETER_H __HEADER_TRAN(hygrometer)
#endif
```
OBS: Btw, this fix was tested for both the develop and master branch and it worked for bothhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/15__CTOR_END__ not at the end of .init_array for the EPOS Library Architecture2021-02-26T01:14:13ZAlek Fröhlich__CTOR_END__ not at the end of .init_array for the EPOS Library ArchitectureThe previous linkage order had `link_libs` after `LINK_OBJL`, which caused some global constructors to appear after `__CTOR_END__` in the `.init_array` section of the final executable. With this, some objects were not being constructed a...The previous linkage order had `link_libs` after `LINK_OBJL`, which caused some global constructors to appear after `__CTOR_END__` in the `.init_array` section of the final executable. With this, some objects were not being constructed at all [recall `__do_global_ctors_aux` begins at `__CTOR_END__-1` and proceeds backwards].
We propose to fix the problem by redefining `link_libs` as follows:
```link_libs="$link_libs $LINK_OBJL"```
Note that, for this to work, `LIB/system_$MMOD.o` must be moved from the beginning of `LINK_OBJL_LIBRARY` to the end of `LINK_OBJN_LIBRARY`.https://gitlab.lisha.ufsc.br/epos/epos/-/issues/14NIC test2020-05-03T23:20:36ZAntônio Augusto Fröhlichguto@lisha.ufsc.brNIC testNIC test is tesing only one NIC at a time and only for PC. We should have tests for all NICs just by changing the traits. It is also not testing some specificities of each NIC, like the new Configuration interface.NIC test is tesing only one NIC at a time and only for PC. We should have tests for all NICs just by changing the traits. It is also not testing some specificities of each NIC, like the new Configuration interface.EPOS 2.2.2José Luis Conradi HoffmannJosé Luis Conradi Hoffmannhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/13Raspberry Pi32020-03-10T22:43:52ZJosé Luis Conradi HoffmannRaspberry Pi3Tests needed:
1) RT_Thread; (DONE)
2) Monitor; (DONE)
3) Thread Statistics Accounting; (DONE)
4) Add FANN;
5) Reconfigure Stress Test;
General Changes needed:
1) Add a watchdog for the reboot.
2) Rework UART Base address;
3) Add SPI imp...Tests needed:
1) RT_Thread; (DONE)
2) Monitor; (DONE)
3) Thread Statistics Accounting; (DONE)
4) Add FANN;
5) Reconfigure Stress Test;
General Changes needed:
1) Add a watchdog for the reboot.
2) Rework UART Base address;
3) Add SPI implementation;José Luis Conradi HoffmannJosé Luis Conradi Hoffmannhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/12No System Info for Cortex2021-06-22T02:04:56ZAntônio Augusto Fröhlichguto@lisha.ufsc.brNo System Info for Cortexmkbi is throwing out SI for machines without boot:
// Reserve space for System_Info if necessary
System_Info si;
bool need_si = true;
if(image_size == 0) {
need_si = false;
} else
so all Cortex machines are ...mkbi is throwing out SI for machines without boot:
// Reserve space for System_Info if necessary
System_Info si;
bool need_si = true;
if(image_size == 0) {
need_si = false;
} else
so all Cortex machines are not receiving important things such as geographic coordinates. This must be fixed both at mkbi and in Machine::pre_init(), so a valid SI is present throughout EPOS initialization.
Cortex_System_Info can be shrunk eliminating everything not used anymore.EPOS 2.2Leonardo Passig HorstmannLeonardo Passig Horstmann2020-03-20https://gitlab.lisha.ufsc.br/epos/epos/-/issues/11Bug: broken libgcc for ARM thumb2020-03-02T16:31:58ZAntônio Augusto Fröhlichguto@lisha.ufsc.brBug: broken libgcc for ARM thumbThe libgcc.a in /usr/local/arm/gcc-7.2.0/lib/gcc/arm-epos-eabi/7.2.0/thumb/libgcc.a has several functions that seems to be ARM (not thumb) and causes the processor in Cortex-M3 machines to misbehave. The bug can be reproduced in any Cort...The libgcc.a in /usr/local/arm/gcc-7.2.0/lib/gcc/arm-epos-eabi/7.2.0/thumb/libgcc.a has several functions that seems to be ARM (not thumb) and causes the processor in Cortex-M3 machines to misbehave. The bug can be reproduced in any Cortex-M3 with this simple test:
#include <utility/ostream.h>
using namespace EPOS;
OStream cout;
int main()
{
unsigned long long a = 1234;
cout << "a=" << a << endl;
return 0;
}
which produces a call to libgcc's __udivdi3 (for uul software handling), which, in turn, calls __clzdi2, a non-thumb function. Since Cortex-M3 are thumb-only machines, this ARM mode code wreaks havoc.
The problem was also reported [here](https://answers.launchpad.net/gcc-arm-embedded/+question/268630) and [here](https://bugzilla.redhat.com/show_bug.cgi?id=1099782), apparently without a solution.
I see two alternatives: fight with compilation flags to recompile gcc and lead it to produce a correct libgcc (not sure if this is possible) or patch the ligcc.a by hand (i.e. extract all object files, look for non-thumb ones, recompile them by hand with -mthumb, and repacking the lib).EPOS 2.2Alek FröhlichAlek Fröhlich2020-02-14https://gitlab.lisha.ufsc.br/epos/epos/-/issues/10Constexpr arrays in pmu_test2021-01-27T02:58:33ZJosé Luis Conradi HoffmannConstexpr arrays in pmu_testThe new PMU constexpr *_events* array is working fine in the Clerk. However, its usage in pmu_test generates a compile-time error indicating an undefined reference to the *_events* array, even though the process is very similar (PMU::con...The new PMU constexpr *_events* array is working fine in the Clerk. However, its usage in pmu_test generates a compile-time error indicating an undefined reference to the *_events* array, even though the process is very similar (PMU::config in a new inside the inline function vs. config as an explicit call inside main). All the necessary information seems to be available at compile-time, and the constexpr vector should not be necessary during the linkage process. We still need to investigate this problem.https://gitlab.lisha.ufsc.br/epos/epos/-/issues/9EDF Priority update2020-01-30T15:07:48ZJosé Luis Conradi HoffmannEDF Priority updateThe current implementation of priority as an int incur that long runs using EDF scheduling will generate priority inversion, thus a thread that reaches a negative priority will be the highest priority of the system, generating a run-time...The current implementation of priority as an int incur that long runs using EDF scheduling will generate priority inversion, thus a thread that reaches a negative priority will be the highest priority of the system, generating a run-time bug. However, modifying the type of priority to be related to the Life_Span Traits when using EDF (and its derivatives) will generate a lot of overhead when using a 64bits attribute in a 32bits architecture, due to the high frequency of scheduling operations. A new way to reset the priority count should be provided.https://gitlab.lisha.ufsc.br/epos/epos/-/issues/8std:tuple2020-01-14T12:51:21ZAntônio Augusto Fröhlichguto@lisha.ufsc.brstd:tupleWe definitely need something like std:tuple for EPOS. However, as always, the STL implementation (https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/tuple) is too heavy and too zealous for things that never happen...We definitely need something like std:tuple for EPOS. However, as always, the STL implementation (https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/tuple) is too heavy and too zealous for things that never happen in system-land. Would someone date to produce a light version of it (similar to what I did for OStream and meta.h)?EPOS 2.3https://gitlab.lisha.ufsc.br/epos/epos/-/issues/7I2C::ready_to_put @ EPOS-2.2 @ EPOSMote III2020-02-04T14:41:34ZAntônio Augusto Fröhlichguto@lisha.ufsc.brI2C::ready_to_put @ EPOS-2.2 @ EPOSMote IIIThe while(!ready_to_put()) in I2C::ready_to_put() is causing a deadlock. I could easily replace by a limited loop, but the I2C refactoring is certainly broken since this loop used to work in 2.1.The while(!ready_to_put()) in I2C::ready_to_put() is causing a deadlock. I could easily replace by a limited loop, but the I2C refactoring is certainly broken since this loop used to work in 2.1.EPOS 2.2Mateus Martínez de LucenaMateus Martínez de Lucenahttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/6Makefiles dependencies2020-01-07T00:24:50ZAntônio Augusto Fröhlichguto@lisha.ufsc.brMakefiles dependenciesOur makefiles include makedefs, which parses traits again for each include. Exporting the variables from the main makefile, so descendant makefiles would not need to (re)-include makedefs seems an easy solution, but it didn't work as exp...Our makefiles include makedefs, which parses traits again for each include. Exporting the variables from the main makefile, so descendant makefiles would not need to (re)-include makedefs seems an easy solution, but it didn't work as expected.EPOS 2.2https://gitlab.lisha.ufsc.br/epos/epos/-/issues/5Math test2020-03-09T11:40:42ZAntônio Augusto Fröhlichguto@lisha.ufsc.brMath testUtility math.h is not being tested. Simple tests should be added (e.g. pow(sin(x), 2) + pow(cos(x), 2) = 1).Utility math.h is not being tested. Simple tests should be added (e.g. pow(sin(x), 2) + pow(cos(x), 2) = 1).EPOS 2.2José Luis Conradi HoffmannJosé Luis Conradi Hoffmannhttps://gitlab.lisha.ufsc.br/epos/epos/-/issues/4SPI Slave2020-01-02T22:33:06ZAntônio Augusto Fröhlichguto@lisha.ufsc.brSPI SlaveImplement the slave mode for EPOS' SPI @ EPOSMote IIIImplement the slave mode for EPOS' SPI @ EPOSMote IIIEPOS 2.2Alek FröhlichAlek Fröhlich2020-01-10https://gitlab.lisha.ufsc.br/epos/epos/-/issues/3Readme2020-03-02T16:30:29ZAntônio Augusto Fröhlichguto@lisha.ufsc.brReadmeAdd a readme file with instruction on how to compile, where to get help, where to get code, etc, etc, etc.Add a readme file with instruction on how to compile, where to get help, where to get code, etc, etc, etc.EPOS 2.2Antônio Augusto Fröhlichguto@lisha.ufsc.brAntônio Augusto Fröhlichguto@lisha.ufsc.br2020-01-08https://gitlab.lisha.ufsc.br/epos/epos/-/issues/2Contributing2020-03-02T16:31:15ZAntônio Augusto Fröhlichguto@lisha.ufsc.brContributingAdd a contributing file.Add a contributing file.EPOS 2.2Mateus Martínez de LucenaMateus Martínez de Lucena2020-01-08https://gitlab.lisha.ufsc.br/epos/epos/-/issues/1License2020-03-02T16:31:00ZAntônio Augusto Fröhlichguto@lisha.ufsc.brLicenseMove EPOS to GPLv2.0Move EPOS to GPLv2.0EPOS 2.2José Luis Conradi HoffmannJosé Luis Conradi Hoffmann2020-01-08