Summary:
- I noticed that the hello (ELF) application causes a memory leak.
- Finally, I found that the data section is not deallocated.
- This commit fixes this issue.
Impact:
- ELF loader with CONFIG_ARCH_ADDRENV=n
Testing:
- Tested with the following configs
- sprensense:elf, esp32-devkitc:elf, sabre-6quad:elf
- spresense:wifi_smp, rv-virt:nsh64, sabre-6quad:netnsh
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Initialize .domains_init function entry point in sbi_platform_operations when
CONFIG_OPENSBI_DOMAINS=y. In this case, the board specific code must provide
the "board_domains_init" function.
Signed-off-by: Jouni Ukkonen <jouni.ukkonen@unikie.com>
Summary:
- This commit enables to test C++ static object in ELF (hello++3)
Impact:
- elf defconfig only
Testing:
- Tested with QEMU and sabre-6quad board
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- This commit enables to test C++ static object in ELF (hello++3)
Impact:
- elf defconfig only
Testing:
- Tested with spresense
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- This commit enables to test C++ static object in ELF (hello++3)
Impact:
- elf defconfig only
Testing:
- Tested with both QEMU and esp32-devkitc board
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
server:
at accept last nxsem_post(&client->lc_waitsem);
client:
connect wait(&client->lc_waitsem) then local_open_client_rx();
But if the server priority is higher then client,
and after server accept return, immediately call send().
At this time the client has no way do local_open_client_rx().
Then server send() return error.
Fix:
add lc_done sem to client
Signed-off-by: ligd <liguiding1@xiaomi.com>
some toolchain provider remove const qualifier from global_impure_ptr
(e.g. Espressif) but other provider keep it(e.g. ARM or Cadence), so
let's define const to empty macro to pass the compile and more safety.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
'putarea' function now has to select the appropriate values from the
whole frame buffer instead of the previous expectation of having just
specified rectangle passed to it.
This required extension of WRRAM handling function as we now are not
writing simply buffer but we want to skip some values and do that
multiple times. Having two implementation in this case is worst as this
function is actually called only twice in the whole code (thus making
dedicated function for every call if we would have two variants).
Calling `st7789_wrram` multiple times is not an option as command
ST7789_RAMWR resets the position and thus calling it multiple times just
overwrites the previous values.
The putarea documentation originally suggested that provided buffer
contains just the rectangle to be updated.
The commit 664d45dcba changed the expected
behavior for lcd_framebuffer but failed to propagate this change to the
driver's documentation. Now the expected behavior is that the whole
frame is passed in buffer and it is driver's responsibility to pick the
correct pixels according to the provided rectangle coordinates.
This change requires update of the LCD drivers if they implement this
function.
I found an issue in the APA102 framebuffer that wasn't spot
before by fb test because this application draw symetric squares
Normally in a display each line starts at left and increase to the
right, however for this APA102 matrix the next line starts at the
end of previous line and move the opposite direction, forming a
zig-zag pattern.
