Fix the issue where fat driver is not using the last two clusters in
the file system.
The fat parameter fs->fs_nclusters is the maximum number of data clusters;
this doesn't include the two in the beginning. Many checks in the fat driver
treat the fs->fs_nclusters-1 as being the last accessible cluster, which is not
right, the last accessible one is actually this number + 2 when the cluster
count includes the two first ones.
Normally this is not an issue when writes are being done through the same
driver, the last two clusters are just never used. But if the filesystem is
modified by external driver, for example with a populated fat created with PC,
or modifying the FS via USB-MSC, this leads to the fat driver not being able to
read anything that uses the last two clusters.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Summary:
- I noticed that qemu-armv8a:netnsh_smp_hv does not detect
GICv2 on Raspi4B (ubuntu 22.04 server + qemu-8.1.2)
- According to the GIC-400 TRM, it says that the architecture
version can be obtained from GICC_IIDR (See Table 3-7)
- This commit fixes this issue.
Impact:
- Should be none
Testing:
- Tested with qemu-armv8a:netnsh_smp_hv on
- Raspi3B+ (ubuntu 22.04 server + qemu-8.1.2)
- Raspi4B (ubuntu 22.04 server + qemu-8.1.2)
- M1/MacBook Pro 2021 (macOS 13.6 + qemu-8.1.2)
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
@raiden00pl I'm surprised why this commit was reverted. It maintains the same functionality as tools/refresh.sh. this change is a good improvement because overwriting the original defconfig to prevent developers from missing out on enabled or disabled features during the development process. If you find any changes in the defconfig after saving it, you should manually restore it, git diff will tell you what has happened. and also this feature prevents more junior developers from forgetting to save their own defconfig
This reverts commit 751bc1528a.
Signed-off-by: chao an <anchao@lixiang.com>
Add a static port-based VLAN configuration for KSZ9477 switch. This doesn't
use the VLAN tagging, but is a switch's internal mechanism to simply configure
if the packet forwarding is allowed from one port to another.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
1. Solve wifi may not work bug for bbpll not lock or not stable when enable RF.
2. Improved timing tuning stability on ESP32-S3.
The root cause of the issue:
The application won't re-calibrate the BBPLL clock if it's already enabled.
We add a force-recalib function in the app startup code to make sure even if
the patch is applied by OTA, the clock is still re-calibrated.
Signed-off-by: chenwen@espressif.com <chenwen@espressif.com>
In order to obtain best accuracy over temperature range,
particularly in low temperature, it is recommended to
compensate the non-linearity over the temperature.
ref: ENG_DS_MS5611-01BA03_B3.pdf
ENG_DS_MS5607-02BA03_B4.pdf
Signed-off-by: Takumi Ando <t-ando@advaly.co.jp>
In function 'unlock_evtbufinst',
inlined from 'parse_altcompkt' at modem/alt1250/alt1250.c:919:7,
inlined from 'altcom_recvthread' at modem/alt1250/alt1250.c:968:21:
Error: modem/alt1250/alt1250.c:385:3: error: 'inst' may be used uninitialized [-Werror=maybe-uninitialized]
385 | nxmutex_unlock(&inst->stat_lock);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
modem/alt1250/alt1250.c: In function 'altcom_recvthread':
modem/alt1250/alt1250.c:822:26: note: 'inst' was declared here
822 | FAR alt_evtbuf_inst_t *inst;
| ^~~~
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
since gcc report the false alarm if the pointer offset from zero address:
inlined from 'up_vectormapping' at chip/dm320_boot.c:162:7,
inlined from 'arm_boot' at chip/dm320_boot.c:211:3:
Error: chip/dm320_boot.c:117:17: error: array subscript 0 is outside array bounds of 'uint32_t[0]' {aka 'long unsigned int[]'} [-Werror=array-bounds=]
117 | ctable[index] = (paddr | mmuflags);
| ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
arm-none-eabi-ld: /tools/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libsupc++.a(eh_alloc.o): in function `_GLOBAL__sub_I__ZN9__gnu_cxx9__freeresEv':
eh_alloc.cc:(.text.startup._GLOBAL__sub_I__ZN9__gnu_cxx9__freeresEv+0x12): undefined reference to `getenv'
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
The Goldfish FB register should be optimized by considering the need to pass in parameters for base and irq.
Signed-off-by: jianglianfang <jianglianfang@xiaomi.com>
The opening and closing of the window has been associated with the opening and closing of fb, but the LCD has not yet been optimized. The window will only open when sim_x11openwindow is called, and similarly, the window will only close when sim_x11closewindow is called.
Signed-off-by: jianglianfang <jianglianfang@xiaomi.com>
Once these messages are thrown during the system's bring-up, it is
advisable them to be output by the syslog considering the file
system initialization.
The SmartFS partition needs to be formatted before being mounted.
Otherwise, it would throw an error message. The error message now
contains a suggestion to format the partition when such an error
is detected.
Remove KEEP_ALIVE_HACK to avoid waking up the device periodly.
The workaround it's added by:
commit 6546fa39c7
Author: Gregory Nutt <gnutt@nuttx.org>
Date: Tue Aug 12 11:12:00 2014 -0600
Tickless Stuff: Back out the risky timer operations when the ready-to-run
list is modified. That is unsafe. An ugly workaround is just to keep an
interval timer going all of the time with a minimum duration equal to the
timeslice interval.
But look like it doesn't needed anymore.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
The code is mainly derived from the NuttX qemu-rv/rv-virt codebase.
Major changes:
- boards/Kconfig: add new BOARD_K230_CANMV
- arch/risc-v/Kconfig: add new CHIP_K230 chip and ARCH_RV_MMIO_BITS
- arch/risc-v/src/common/riscv_mtimer.c: use ARCH_RV_MMIO_BITS to
select MMIO access width
New additions:
- arch/risc-v/include/k230/: k230 SoC definitions
- arch/risc-v/src/k230/: k230 SoC sources
- boards/risc-v/k230/canmv230/: CanMV-K230 board sources and configs
- Documentation/platforms/risc-v/k230/: simple doc
Note that only FLAT build works for canmv230 now.
This PR has changes in RiscV common layer thus may affect other RiscV ports
It changes the mtime/mtimecmp access control from using config ARCH_RV64 to
newly intorduced config ARCH_RV_MMIO_BITS.
Original design uses ARCH_RV64 to select 64bit MMIO in riscv_mtimer.c, this
can't cope with the situation with K230 --- it has ARCH_RV64 but only can do
32bit MMIO. So a new ARCH_RV_MMIO_BITS config has been introduced. Its value
depicts the MMIO width in bits. The MMIO_BITS defaults to 32/64 for RV32/
RV64 respectively. This allows the macro to replace current use of ARCH_RV64
in riscv_mtimer.c.
The new MMIO_BITS config is a derived one, and for RiscV chips with
equal CPU and MMIO widths there is no need to explicitly set it as the
default rule will do that. Only chips with different CPU and MMIO widths
need set it in Kconfig.
So by design this change should be safe but RiscV ports should be checked.
"ostest" verification has been done for:
- canmv230/nsh
- rv-vivt/nsh
- rv-virt/nsh64
configuration generation and manual check of derived RV_MMIO_BITS has been
done for:
- star64/nsh
- arty_a7/nsh
- bl602evb/nsh
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
savedefconfig shouldn't overwrite the original defconfig, but only create a new
defconfig in the current directory. Otherwise, creating new configs based on
existing ones becomes irritating, because every time we use savedefconfig,
the original configuration is overwritten which is not the excepted behavior
The `xxx_ipv6multicast` function in each driver is not adapted to
multiple IPv6 addresses yet, and they're redundant, so try to take them
into common code.
Change:
1. Add MAC `g_ipv6_ethallnodes` and `g_ipv6_ethallrouters` in
`icmpv6_devinit` and call them in `netdev_register`
2. Add multicast MAC for Neighbor Solicitation when adding any IPv6
address, and remove them when IPv6 address is removed
3. Select `NET_MCASTGROUP` when `NET_ICMPv6` because now we need
`d_addmac` when we have ICMPv6
Note:
We want modules outside net stack to call functions like
`netdev_ipv6_add` and never touch the related MAC address, so these MAC
functions are added as internal functions to `net/netdev/netdev.h`
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
When CONFIG_NET_TCP_WRITE_BUFFERS is enabled, iobs are used for
both queuing data from application, and for assembling packets
for sending. If there is a system-wide shortage of iobs, it could
happen that there is not enough free space to form any packets
to send. The buffers allocated for TCP data also can't be released
until the packet is sent.
Normally this should be avoided by setting suitable values for
CONFIG_IOB_NBUFFERS and CONFIG_IOB_THROTTLE. The default values
are ok for light usage, but can run out when using multiple
simultaneous TCP streams.
Before this commit, iob shortage would cause TCP connections to
get stuck and eventually timeout. With this change, TCP stack
sends smaller packets, eventually freeing some buffers from the
write queue.
This PR adds support for PINE64 Ox64 64-bit RISC-V SBC, based on Bouffalo Lab BL808 SoC (T-Head C906 Core). Most of the code is derived from NuttX for Star64 JH7110. The source files are explained in the articles here: https://github.com/lupyuen/nuttx-ox64
### Modified Files
`boards/Kconfig`: Added Ox64 board
### New Files in boards/risc-v/bl808/ox64
`src/bl808_appinit.c`: Startup Code
`include/board.h`: Ox64 Definitions
`include/board_memorymap.h`: Memory Map
`src/etc/init.d/rc.sysinit`, `rcS`: Startup Script
`src/.gitignore`: Ignore the tmp filesystem
`scripts/ld.script`: Linker Script
`scripts/Make.defs`: Ox64 Makefile
`src/Makefile`: Ox64 Makefile
`Kconfig`: Ox64 Config
`configs/nsh/defconfig`: Build Config for `ox64:nsh`
### Updated Documentation
`platforms/risc-v/bl808/index.rst`: New page for Bouffalo Lab BL808 SoC
`platforms/risc-v/bl808/boards/ox64/index.rst`: Building and booting NuttX for Ox64
`platforms/risc-v/jh7110/boards/star64/index.rst`: Fix typo
DMA directly to user (virtual) memory won't work, as the DMA engine(s)
don't do address translations, i.e. they require a physical address.
Using kernel heap is fine as it is mapped vaddr=paddr. Also, the USB DMA
engine does not have any alignment requirements.
The hack just opens the entire SoC memory unconditionally, which is not
a good idea.
Test features can be used ad-hoc, they don't need to be supported by the
build.
