Re-check RX queue status after uart_enablerxint() and before blocking
the reading task on the receive semaphore. cdcacm (and maybe other UART
drivers) can push buffered data into the receive queue during
uart_enablerxint(), leading to a blocked task while data is already
available.
Signed-off-by: Tido Klaassen <tido@4gh.eu>
Summary:
- Apply the same logic added to cxd56_cpupause.c
Impact:
- SMP only
Testing:
- Tested with esp32-core:smp (QEMU)
- Run smp and ostest
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- Apply the same logic added to cxd56_cpupause.c
Impact:
- SMP only
Testing:
- Tested with maix-bit:smp (QEMU)
- Run smp and ostest
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- Apply the same logic added to cxd56_cpupause.c
Impact:
- SMP only
Testing:
- Tested with lc823450-xgevk:rndis
- Run smp and ostest
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- Apply the same logic added to cxd56_cpupause.c
Impact:
- SMP only
Testing:
- Tested with sabre-6quad:smp (QEMU and dev board)
- Run smp and ostest
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- I noticed that sched_add_readytorun() runs on multiple CPUs simultaneously
- Finally, I found the root cause which was described in TODO
- Actually, the task newly scheduled on remote CPU did not acquire g_cpu_irqlock
- This commit fixes this issue by adding a critical section to the pause handler
- Which will acquire g_cpu_irqlock on the remote CPU explicitly
Impact:
- SMP only
Testing:
- Tested with spresense:wifi_smp (NCPUS=2 and 4)
- Run smp, ostest, nxplayer
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
This reverts commit 97be116a39.
This commit broke nxffs. This leaves the first block as empty which
then exposes another bug where when the pack is called because we
have reached the end of flash and need to look for deleted inodes
we search the first block find no inode and assume that there
are no more inodes. This then results in corrupting the filesystem
by writing over existing inodes.
This can be seen by runing the sim:nxffs configuration.
Prior to this commit the first pass of writing files would look like
this:
NXFFS Dump:
BLOCK:OFFS TYPE STATE LENGTH
0:5 INODE OK 2680
0:78 DATA OK 424
1:5 DATA OK 497
2:5 DATA OK 497
3:5 DATA OK 497
4:5 DATA OK 497
5:5 DATA OK 268
5:283 INODE OK 7410
5:425 DATA OK 77
6:5 DATA OK 497
With this commit:
NXFFS Dump:
BLOCK:OFFS TYPE STATE LENGTH
0:0 BLOCK ERASED 512
1:5 INODE OK 6394
1:39 DATA OK 463
2:5 DATA OK 497
3:5 DATA OK 497
Signed-off-by: Brennan Ashton <bashton@brennanashton.com>
Summary:
- Remove comments on up_idle() which is old information
- Add L2CC info with QEMU
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- I noticed that Cortex-A SGI can be masked
- We thought the SGI is not maskable
- Although I can not remember how I tested it before
- It actually works as expected now
- Also, fixed the number of remaining bugs in TODO
Impact:
- No impact
Testing:
- Tested with sabre-6quad:smp (QEMU and dev board)
- Add the following code in up_idle() before calling asm("WFI");
+ if (0 != up_cpu_index())
+ {
+ up_irq_save();
+ }
- Run the hello app, you can see "Hello, World!!"
- But nsh will freeze soon because arm_pause_handler is not called.
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
If size_t != uint32_t, this can give a build error:
mtd/mtd_progmem.c:134:16: error: conflicting types for 'progmem_log2'
134 | static int32_t progmem_log2(uint32_t blocksize)
| ^~~~~~~~~~~~
mtd/mtd_progmem.c:82:16: note: previous declaration of 'progmem_log2' was here
82 | static int32_t progmem_log2(size_t blocksize);
| ^~~~~~~~~~~~
Makefile:118: recipe for target 'mtd_progmem.o' failed
Signed-off-by: Juha Niskanen <juha.niskanen@haltian.com>
