@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.
and optimize the critical section usage
1.Remove the unnecessary critical section in ramlog_readnotify
2.Move the enter/leave critical section out of ramlog_pollnotify loop
3.Move the critical section of ramlog_addchar to caller
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
1.Remove RAMLOG_OVERWRITE option and related code
2.Broadcast the readability to all reader and poller
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
-The qemu wifi fucntion only supports the STA mode and the following
operations:
wapi mode wlan0 2
wapi scan wlan0
wapi psk wlan0 password 3
wapi essid wlan0 wifi_name 1
wapi show wlan0
wapi disconnect wlan0
-Eanble the virtual wifi function with the MACRO `CONFIG_DRIVERS_WIFI_SIM`.
Signed-off-by: liqinhui <liqinhui@xiaomi.com>
As pointed out in #11322 there is a hardware design issue in RISC-V that
affects RV64 relocations. The problem is with how address bits are loaded
into registers via lui / auipc and sign extension.
If the hi20 relocation value happens to have its 32-bit sign bit set, i.e.
value is 0x80000000 (but not negative! i.e. negative in 64-bit format) the
relocation will fail, as the address is erroneously sign extended:
0x00000000_80000000 becomes 0xffffffff_80000000 which is not correct.
Also, make sure the correct opcode is used with PCREL_HI20, it expects
AUIPC (not LUI). The C compiler will never emit such code but when hand-
writing assembly code this can happen.
chao an