February 2, 2023

Kyu networking -- Rip off the NetBSD startup for ARM (part 2)

I now have both armv6_start.S and cpufunc_asm_armv7.S compiling clean and linking into Kyu without unsatisfied externals. It is not quite ready to test yet. More stuff from the NetBSD locore.S needs to be assimilated, and some things need to be looked at.

DCCISW

This is described as "data cache clean and invalidate line by set/way". 
    mcr p15, 0, r3, c7, c14, 2
NetBSD uses this in "cpufunc" in the routine: 
armv7_dcache_wbinv_all().
The question is whether this is supported on all of the v7 chips I intend to work with. It is certainly available on the Cortex-A7 MPCore in the Allwinner H3.

Bring up the specific Cortex manual, go to "System Control" then "Register summary", then c7 registers. There it is for the A7 MPCore along with its brother DCCIMVAC.
They are there for the Cortex A8 (hence the BBB).
They are there for the Cortex A9 (hence the Zynq).

I have also seen this instruction described as "write back and invalidate". In other words "clean" and "write back" mean the same thing. Notice also that there is a separate instruction to do just "clean" and another to do just "invalidate". This instruction combines them both.

DTS files

As a bonux, while digging around for dts files, I find that U-boot has what looks like their dts compiler under tools/dtoc.

The "fdt" scheme (flattened device table) depends on a dtb file being placed by Uboot in a spot where NetBSD expects it. The dtb file itself is generated (compiled) from sources. We would like to find the sources for the allwinner-h3 (not to mention the BBB and the zynq). Using locate along with grep I find two places where likely sources can be found: 

/u1/NetBSD/Git/src/sys/arch/arm/dts/sun8i-h3-orangepi-one.dts
/u1/NetBSD/Git/src/sys/external/gpl2/dts/dist/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
Everything was once in the first place (arch/arm/dts), but apparently some GPL2 licensing concerns made the NetBSD group segregate many files to external/gpl2/dts/dist/arch/arm/boot/dts.

The first location has a number of things of interest: 

omap3-beagle.dts
sun8i-h3-nanopi-neo.dts

The first is mostly a link to external/gpl2/dts/dist/arch/arm/boot/dts/omap3-beagle.dts
The second is mostly a link to external/gpl2/dts/dist/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts

The second location (/u1/NetBSD/Git/src/sys/external/gpl2/dts/dist/arch/arm/boot/dts) is the gold mine. 

zynq-7000.dtsi
zynq-zybo.dts

omap34xx.dtsi
omap3-beagle.dts

sun8i-h3.dtsi
sun8i-h3-orangepi-pc.dts
sun8i-h3-orangepi-pc-plus.dts

sunxi-h3-h5.dtsi
sun8i-h3.dtsi
sun8i-h3-nanopi.dtsi
sun8i-h3-nanopi-neo.dts
I am at a loss to find a ram/memory declaration for any of the H3 boards. I have spent a fair while searching for this, and for my purposes I should just assume that an entry of the same form as one of the two following gets magically generated for the h3 boards.

The RAM declaration for the BBB is: 

        memory@80000000 {
                device_type = "memory";
                reg = <0x80000000 0x10000000>; /* 256 MB */
        };

For the Zynq/zybo we have: 

	memory@0 {
                device_type = "memory";
                reg = <0x0 0x20000000>;
        };

Peek at fdt a little

A starting point would be sys/arch/evbarm/fdt/fdt_machdep.c.. Here we find "initarm()" which calls fdt_memory_get in dev/fdt/fdt_memory.c. This calls OF_finddevice("/memory") and does not expect this to fail. So, I am baffled. I know that my OrangePi PC has 1G of ram starting at 0x40000000 and would expect to find this somewhere in the dts files.

MMU setup

This bears a close look because this will be board dependent according to where RAM is located. RAM can be cached, but IO addresses cannot be.

Have any comments? Questions? Drop me a line!

Kyu / tom@mmto.org