when downloading rtk firmware with vendor hci cmd sending to
bt bridge, which would not filter that hci cmd.
Signed-off-by: chengkai <chengkai@xiaomi.com>
h5 ack which send to controller always timeout, which causing
controller would send repend hci data until host send back h5 ack.
Signed-off-by: chengkai <chengkai@xiaomi.com>
bt bridge filter would not match when ACL in data
head with Packet_Boundary_Flag 0b10. in that case connect handle
is the first 3 octets of the packet, which not match
BT_HCI_EVT_LE_CONN_COMPLETE hci event alloc handle.
Signed-off-by: chengkai <chengkai@xiaomi.com>
Implement hartid<->cpuid mapping for RISC-V. This is necessary for some
platforms which cannot use 1:1 mapping between logical and physical CPU /
core IDs. One example is MPFS where hart0 cannot be used for NuttX SMP as
it is a less capable "monitor" core (E51) compared to the application
cores hart1...3 (E54).
Why not just use a generic offset then? We also need the physical hart ID
for many things:
- Communication between harts (IPI)
- External interrupt acknowledgment (interrupt claim for specific CPU)
- Communication to SBI
Thus, create procedures that can do this translation:
- The default mapping is still logical=physical.
- Another flavor is to use the existing CONFIG_ARCH_RV_HARTID_BASE config
variable, which is just a simple offset
- The final flavor is to overload hartid<->cpuid on a per chip basis (no
example for this is provided yet)
This implements empty hooks to the arch/chip layer, which can implement
an optional translation between logical<->physical CPU/core id.
The default mapping is 1:1 i.e. logical=physical.
The function is supposed to return the physical hart ID. It is needed
for e.g. external interrupt acknowledgment (see mpfs_plic.c).
This offset is moved initially to up_cpu_index (which is also wrong, but
less wrong than the current implementation). Finally, a translation
between physical <-> logical shall be provided.
This fixes issue where empty and unallocated sections are left without
a VMA. Some relocations depend on the section VMA being set even if there
is no data there, as the binary can refer to the symbols. Linker defined
symbols do not contain data -> they can produce empty sections.
This issue is seen when building a loadable file which declares _sctors /
_sdtors linker defined symbols for ctor/dtor sections which are empty.
crt0 references these symbols, so they need to be relocated, but the
section VMA is not set -> they go outside of the addressable range of the
user binary causing a potential crash.
this_task obtains the CPU ID through the GS register, so the initial value of GS needs to be configured in x86_64_cpu_priv_set
Signed-off-by: liwenxiang1 <liwenxiang1@xiaomi.com>
x86_64/intel64: fix SMP compilation warnings
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
Implement PIC loading in armv8-m qemu,
for example: load address-independent AP ELF in the bootloader,
and the text segment in AP ELF is XIP,
no need to apply for memory and modify it.
Two config:
bootloader abbreviation bl:
use romfs to load ap elf, use the boot command to parse and jump to ap
application abbreviation ap:
run os test
We need to compile ap first, then compile bl.
compile step:
./tools/configure.sh mps3-an547:ap
make -j20
mkdir -p pic
cp boot pic/.
genromfs -a 128 -f ../romfs.img -d pic
make distclean -j20
./tools/configure.sh mps3-an547:bl
make -j20
run qemu:
qemu-system-arm -M mps3-an547 -m 2G -nographic -kernel nuttx.bin \
-gdb tcp::1127 -device loader,file=../romfs.img,addr=0x60000000
nsh> boot /etc/boot
ap> ostest
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
Need to start up a new to setup special registers use
`arm_pic_setupxcp`.
Note that CONFIG_BUILD_PIC compiles the entire NuttX image
as position-independent(PIC), enable CONFIG_PIC to load PIC
application code.
Signed-off-by: anjiahao <anjiahao@xiaomi.com>