Summary:
- According to the Xtensa ISA document, this ISYNC instruction
between WSR SCOMPARE1 and S32C1I is unnecessary
Impact:
- SMP only
Testing:
- Tested with esp32-devkitc:wapi_smp
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- I noticed that DEBUGASSERT sometimes happens in nxsem_wait()
when testing Wi-Fi with esp32-devkitc:wsifi_smp
- The call stack was not from an interrupt handler and actually
g_current_regs[] were correct, even though asserted with
(up_interrupt_handler() == false)
- Finally, I found that we need to call rsync after we set
a new value to the PS register which is described in the
Xtensa document.
- This commit fixes this issue
Impact:
- All xtensa architectures
Testing:
- Tested with esp32-devkitc:wifi_smp and esp32-devkitc:wifi
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
* port didn't know about data-register fifo
* port didn't handle overrun condition
* driver could get stuck if interrupts were skipped due to saturation
Laurent Latil has submitted the ICLA
Gregory Nutt is the copyright holder for those files and he has submitted the
SGA as a result we can migrate the licenses to Apache.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Summary:
- This commit adds the following configs to spresense:elf
+CONFIG_DEBUG_FULLOPT=y
+CONFIG_DEBUG_SYMBOLS=y
+CONFIG_STACK_COLORATION=y
Impact:
- None
Testing:
- Tested with spresense
Signed-off-by: Masayuki Ishikawa <masayuki.ishikawa@gmail.com>
since the standard require the caller pass the name explicitly
https://pubs.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html:
The argument argv is an array of character pointers to null-terminated strings.
The last member of this array shall be a null pointer and is not counted in argc.
These strings constitute the argument list available to the new process image.
The value in argv[0] should point to a filename that is associated with the
process image being started by the posix_spawn() or posix_spawnp() function.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
I assume this was just an oversight because I couldn't
find any obvious reason to special-case only the first IOB.
The commit message of the original commit is cited below.
```
commit bf21056001
Author: chao.an <anchao@xiaomi.com>
Date: Fri Nov 27 09:50:38 2020 +0800
net/tcp: fallback to unthrottle pool to avoid deadlock
Add a fallback mechanism to ensure that there are still available
iobs for an free connection, Guarantees all connections will have
a minimum threshold iob to keep the connection not be hanged.
Change-Id: I59bed98d135ccd1f16264b9ccacdd1b0d91261de
Signed-off-by: chao.an <anchao@xiaomi.com>
```
since the standard require the caller pass the name explicitly
https://pubs.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html:
The argument argv is an array of character pointers to null-terminated strings.
The last member of this array shall be a null pointer and is not counted in argc.
These strings constitute the argument list available to the new process image.
The value in argv[0] should point to a filename that is associated with the
process image being started by the posix_spawn() or posix_spawnp() function.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Id79ffcc501ae9552dc4e908418ff555f498be7f1
The new configuration CONFIG_USBMSC_NOT_STALL_BULKEP avoids to go into
stall state when :
- Receiving SCSI_CMD_INQUIRY with flags or pagecode != 0
- Receiving SCSI_CMD_MODESENSE6 and return the result data shorter than
the requested data size.
Instead of stall, it just ignores the error condition.
Originally the usb driver goes into the stall under the conditions
mentioned above to inform to the USB host that the requested SCSI feature
is not supported, or the result data is shorter than the requested data
size.
But, at this moment, RP2040 USB device driver cannot handle entering and
leaving stall state of the bulk endpoints well. Once stalls, the host -
device communication stops and cannot be resumed.
I have investigated to solve the issue and found that the existing
RP2040 USB device driver implementation, TinyUSB
(https://github.com/hathach/tinyusb) mass-storage class driver doesn't
enter the stall state like the treatment of this patch.
So, I introduce this new configuration as the RP2040 workaround.
In the future, when the RP2040 USB device driver is fixed and can handle
the bulk endpoint stall correctly, this patch should be reverted.
Summary:
- Add Raspberry Pi Pico (RP2040) USB device controller support.
- Confirmed that CDC/ACM, MSC and these composite device are working.
- The current implementation have an unresolved issue and some workaround
for USB MSC SCSI driver is required.
See the comment in the patch "usbmsc: Add USBMSC_NOT_STALL_BULKEP for RP2040 workaround".
Impact:
- RP2040 only
Testing:
- Tested with Windows 10 and Ubuntu-18.04/20.04 as the USB host.
- Tested configurations:
- raspberrypi-pico:usbnsh
- raspberrypi-pico:usbmsc
- raspberrypi-pico:composite
* Fixes the case where the window was small but not zero.
* tcp_recvfrom: Remove tcp_ackhandler. Instead, simply schedule TX for
a possible window update and make tcp_appsend decide.
* Replace rcv_wnd (the last advertized window size value) with
rcv_adv. (the window edge sequence number advertized to the peer)
rcv_wnd was complicated to deal with because its base (rcvseq) is
also moving.
* tcp_appsend: Send a window update even if there are no other reasons
to send an ack.
Namely, send an update if it increases the window by
* 2 * mss
* or the half of the max possible window size
Summary:
- I noticed that stack coloring for the idle thread stacks does
not work due to the recent changes
- This commit fixes this issue
Impact:
- k210 only
Testing:
- Tested with both maix-bit (dev board) and QEMU
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Many device driver will call the host API to finish the simulation
which require the big stack in the most case, so let's utilize the
new DEFAULT_TASK_STACKSIZE(64KB on sim) option instead.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
