Fishwaldo opened a new pull request, #19863:
URL: https://github.com/apache/nuttx/pull/19863
## Summary
The EIC7700X port has one board directory holding one board, with everything
in it whether it describes the SoC or the PCB. This restructures that into
the
common-plus-board layout NuttX provides, adds a second board, and makes the
arch side work on all four harts.
**Refactoring StarPro64.** `boards/risc-v/eic7700x/common` now holds what is
true of the SoC: the boot path that mounts the RAM disk and `/proc` before
calling the board's own bring-up, the linker script, the start-up scripts and
the image builder. `ARCH_CHIP_EIC7700X` selects `ARCH_BOARD_COMMON`, so the
symlinks the build makes always point at code that compiles. The StarPro64
directory keeps what is a fact about the PCB: its own `board.h` and
`board_memorymap.h`, since the include fallback is all or nothing, a bring-up
that owns the order its devices register in, and a `board_config.h` declaring
what that bring-up may call. This is the layout mpfs uses.
The image builder moves to `common/tools` and derives its output name from
the
configuration. It computes the padding between the kernel and the RAM disk
from
`_ebss` rather than assuming 64 KiB, which fails once BSS grows past it: the
disk lands below `_ebss` and the BSS clear zeroes it before anything looks
for
it.
**Adding the ESWIN EIC7700 EVB.** ESWIN's own evaluation board for this SoC,
and the board this port has been developed against. It brings out most of the
SoC's interfaces where the StarPro64 is a single board computer built around
the chip. Everything shared already lives in `common`, so the board
contributes
its own facts: which UART reaches which connector, which pads carry the boot
straps, and where its memory sits.
One warning for anyone reading the schematics: the summary tables on sheet 3
of
both boards are inherited from ESWIN's reference design and describe that
design, not the board in hand. On the EVB the console is UART0 through the
FT4232 bridge, UART1 goes to the M.2 socket and a header, and UART2 reaches
the
RS232 port. The summary agrees with none of them.
**Four harts.** The firmware does not hand over on a fixed hart, so nothing
may
assume one: the hart that arrives first records which it was, indexes its
idle
stack by its own ID, and restarts on hart 0. `CONFIG_SMP_NCPUS` below four is
refused at build time, because the hart the firmware picked might have no
slot
and would stop before it could restart. Secondary harts are released through
the common SBI helper. External interrupts are pinned to CPU0's PLIC context
rather than left wherever the boot loader routed them. The memory map gains
three corrections: the page pool no longer covers the RAM disk, the kernel
data
region is mapped with 2 MiB pages, and the linker script and page pool agree
on
where the pool starts.
## Impact
EIC7700X boards only. StarPro64 keeps its configuration name and gains SMP, a
larger RAM window and RAMLOG; its files move but its behaviour is intended to
be unchanged. No effect on any other architecture.
## Testing
EIC7700 EVB. OpenSBI's banner reported `Boot HART ID: 1` for this boot, so it
is also the demonstration of the hart-agnostic entry: the firmware handed
over
on hart 1 and NuttX still ran CPU0 on hart 0 with all four harts up.
```
A[CPU0] eic7700x_start_s: Firmware handed off on Hart 1, NuttX running on
Hart 0
BC
NuttShell (NSH) NuttX-13.0.0
nsh>
nsh> uname -a
NuttX 13.0.0 1fdf2da536 Aug 16 2026 18:11:21 risc-v eic7700-evb
nsh> cat /proc/cpuinfo
processor : 0
hart : 0
BogoMIPS : 1.12
cpu MHz : 0.000
isa : rv64imafdc
mmu : none
processor : 1
hart : 1
BogoMIPS : 1.12
cpu MHz : 0.000
isa : rv64imafdc
mmu : none
processor : 2
hart : 2
BogoMIPS : 1.12
cpu MHz : 0.000
isa : rv64imafdc
mmu : none
processor : 3
hart : 3
BogoMIPS : 1.12
cpu MHz : 0.000
isa : rv64imafdc
mmu : none
nsh> ls /dev
/dev:
console
kmsg
null
ram0
ttyS0
ttyS1
ttyS2
zero
nsh> free
total used free maxused maxfree nused nfree name
670994432 26152 670968280 51360 670946296 61 7 Kmem
266338304 638976 265699328 265699328 Page
nsh>
```
`/dev/ram0` is present, so the RAM disk survived the BSS clear with the
padding
`mkimage` computed from `_ebss`, 145128 bytes for this build where the old
fixed pad was 64 KiB. Repeated resets have handed over on different harts and
boot the same way.
Depends-On: https://github.com/apache/nuttx/pull/19856
Depends-On: https://github.com/apache/nuttx/pull/19857
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
