| Age | Commit message (Collapse) | Author |
|---|
|
* [libcpu][risc-v] Refactor the RISC-V architecture port
Introduce an opt-in unified RISC-V common layer for RV32 and RV64 while keeping existing BSPs on the legacy implementation during migration.
- use ARCH_RISCV and ARCH_CPU_64BIT for architecture and XLEN selection
- unify context, trap, MMU, cache, timer, SBI, SMP and ISA handling
- add PLIC, CLIC, ACLINT, APLIC and IMSIC support
- map physical hart IDs to contiguous logical CPU IDs
- add T-Head vendor overrides while preserving legacy ports
- migrate qemu-virt64-riscv with RV32 and RV64 support
- update clock_time, MM, LWP, OFW, PCI and Rust integration
Existing BSPs continue using legacy_common or common64 unless they select RT_USING_RISCV_NEW_COMMON.
Signed-off-by: GuEe-GUI <[email protected]>
* [libcpu][risc-v] skip disabled CPU nodes in early FDT walk
Rbb666 noted that rt_hw_fdt_install_early() walked every /cpus child
without checking status, so disabled cores still joined hart registration
and MMU capability probing. Skip nodes that are not okay/ok via
rt_fdt_device_is_available() before reading reg or mmu-type.
Signed-off-by: seteiro <[email protected]>
* [libcpu][risc-v] Fix per-CPU page table mapping
- reuse existing non-leaf page table entries when mapping per-CPU areas
- reject leaf entry conflicts instead of overwriting mappings
Signed-off-by: GuEe-GUI <[email protected]>
---------
Signed-off-by: GuEe-GUI <[email protected]>
Signed-off-by: seteiro <[email protected]>
Co-authored-by: seteiro <[email protected]>
|
|
* [DM/OFW][PCI] Fix address translation and PCI resource enumeration
Rework OFW address translation to walk nested bus ranges in the correct
direction and cache "ranges" and "dma-ranges" independently. Handle PCI
three-cell addresses without treating the PCI flags cell as part of the
address, and fix CPU-to-DMA and DMA-to-CPU translation across nested
buses.
Fix PCI BAR sizing and assignment by disabling address decoding during
probing, preserving BAR attribute bits, and programming 64-bit BARs
correctly. Add device enable and disable helpers so resources and bus
mastering are enabled before driver probe.
Program bridge memory and prefetch windows while scanning downstream
buses, correctly link child buses into the PCI bus hierarchy, and avoid
unnecessary PCIe link retraining when the link is already active.
Allow host bridges without a device-tree pci-domain property by
allocating unique domains dynamically, while preserving explicit domain
assignments.
Fix MSI and MSI-X IRQ setup, rollback, vector addressing, and affinity
selection.
Add the Raspberry Pi PCI vendor ID for RP1 and other downstream devices.
Signed-off-by: GuEe-GUI <[email protected]>
* style: format code with clang-format
* style: format complete changed files with clang-format
* drivers: pci: address OFW review feedback
* style: format PCI and OFW changes for current master
---------
Signed-off-by: GuEe-GUI <[email protected]>
|
|
Signed-off-by: GuEe-GUI <[email protected]>
|
|
Some PCI device devicetree is like:
```dts
pcie@fe270000 {
device_type = "pci";
msi-map = <0x1000 0x9c 0x1000 0x1000>;
pcie@10 {
reg = <0x100000 0x00 0x00 0x00 0x00>;
#address-cells = <0x03>;
#size-cells = <0x02>;
pcie@10,0 {
reg = <0x00 0x00 0x00 0x00 0x00>;
};
};
};
```
that the pcie@10,0 have a private ofw node, it will find
property name `msi-map` or `msi-parent` fail.
We should only find the property in host bridge's ofw node.
Signed-off-by: GuEe-GUI <[email protected]>
|
|
PCI/PCIe have better performance and more devices support, such as
NVMe, GPU, Powerful NIC (Like RDMA). PCI/PCIe can access control by
IOMMU that the virtualiztion and userspace driver will more safety.
PCI/PCIe device could hot plugging, no design modifications SoC required,
PCI/PCIe on Embedded SoC is popular now.
We make a simple framework to support them.
Feature Lists:
1.PCI INTx: the INT[A-D] pin IRQ for legacy PCI, work with platform PIC.
2.MSI/MSI-X: the message write IRQ for PCIe, work with platform's PIC.
3.PME: we only support the D0, D1, D2, D3HOT, D3COLD init by framework.
4.Endpoint: a simple EP framework for PCI FPGA or NTB function.
5.OFW: we only support work on OFW SoC, ACPI support in the future maybe.
Host controller:
1. Common PCI host controller on ECAM.
2. Generic PCI host controller on ECAM.
Signed-off-by: GuEe-GUI <[email protected]>
|
