How to run FreeBSD on new boards built on Rockchip 35XX..

ok panfrost + iommu seems to work. i ran glmark2 fullscreen 4 times, firefox for a while and no crashes so far.
glmark2 score in 1920x1080 is 150
 
  • Thanks
Reactions: jsm
it seems that the iommu has be enabled in the vop driver for rk3399 ?
search for vop_mmu_en
however i can't find where this is enabled in the linux driver but the bit is described in the headers but does not seem to be actually used
C:
static const struct vop_common rk3399_common = {
    .standby = VOP_REG_SYNC(RK3399_SYS_CTRL, 0x1, 22),
    .gate_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 23),
    .mmu_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 20),
    .dither_down_sel = VOP_REG(RK3399_DSP_CTRL1, 0x1, 4),
    .dither_down_mode = VOP_REG(RK3399_DSP_CTRL1, 0x1, 3),
    .dither_down_en = VOP_REG(RK3399_DSP_CTRL1, 0x1, 2),
    .pre_dither_down = VOP_REG(RK3399_DSP_CTRL1, 0x1, 1),
    .dither_up = VOP_REG(RK3399_DSP_CTRL1, 0x1, 6),
    .dsp_lut_en = VOP_REG(RK3399_DSP_CTRL1, 0x1, 0),
    .update_gamma_lut = VOP_REG(RK3399_DSP_CTRL1, 0x1, 7),
    .lut_buffer_index = VOP_REG(RK3399_DBG_POST_REG1, 0x1, 1),
    .data_blank = VOP_REG(RK3399_DSP_CTRL0, 0x1, 19),
    .dsp_blank = VOP_REG(RK3399_DSP_CTRL0, 0x3, 18),
    .out_mode = VOP_REG(RK3399_DSP_CTRL0, 0xf, 0),
    .cfg_done = VOP_REG_SYNC(RK3399_REG_CFG_DONE, 0x1, 0),
};
 
I wish chinese soc manuals were written in a better english
1767983566422.png

find out that my iommu fault problem was due to the fact the window region disable bit is read only. you have to commit it via another reg
 
well the manual says you have but i see no where to be set in the linux driver. for vop2 there is no such thing. so i really don't know
Ok, so I think i incorporated your drm changes correctly. It works without the iommu loaded, with it, I see the two planes and can move the cursor plane within running X11, but the video is garbage. I wonder if it is some caching is involed or if the memory simply stays garbage. Any ideas how to debug this? (I modified to only use vop little for now)
 
this looks to me like the iommu is not working.
you can change vop's memory start address from userland with a tool like devmem2. if iommu is working you should get read faults. if it's not it should just change the onscreen garbage
 
  • Thanks
Reactions: jsm
this looks to me like the iommu is not working.
you can change vop's memory start address from userland with a tool like devmem2. if iommu is working you should get read faults. if it's not it should just change the onscreen garbage
The iommu uses the clock of vop big and sets it to double speed which destroys the hdmi output even with iommu not using the iommu allocator... So double trouble. I wonder if the iommu can work at the lower freq... so perhaps the original efi rk_cru.c freq fix is correct..
 
what board do you have ? Im looking at the pine64 dtb and the vop-lit and vop-big have diff iommus. also iommu code does not set any clock freq.
the vop lit/big set the clocks they have in common to the iommu. the dclk which is the pixel clock is not common
 
  • Thanks
Reactions: jsm
what board do you have ? Im looking at the pine64 dtb and the vop-lit and vop-big have diff iommus. also iommu code does not set any clock freq.
the vop lit/big set the clocks they have in common to the iommu. the dclk which is the pixel clock is not common
Well as far as I can tell from rk3399-base.dtsi the "aclk" in the iommu driver is the same as the aclk of the vop.. so my theory is that when iommu enables the clk the freq is taken from cru which is the double speed of what the vop should run at
 
YAML:
vopb_mmu: iommu@ff903f00 {
        compatible = "rockchip,iommu";
        reg = <0x0 0xff903f00 0x0 0x100>;
        interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH 0>;
        clocks = <&cru ACLK_VOP0>, <&cru HCLK_VOP0>;
        clock-names = "aclk", "iface";
        power-domains = <&power RK3399_PD_VOPB>;
        #iommu-cells = <0>;
        status = "disabled";
    };
`
clocks = <&cru ACLK_VOP0>, <&cru HCLK_VOP0>;
 
but the vop driver should set it right because the dtb has

assigned-clocks = <&cru ACLK_VOP0>, <&cru HCLK_VOP0>;
assigned-clock-rates = <400000000>, <100000000>;

the pre vop driver freq should be the reset value or set by u-boot if you have u-boot with video support
 
sysctl reports 800000000 and logs that rate set fails for aclk by the vop, perhaps because it is disabled by the iommu..
 
setting freq with clk disabled is ok, not an error. its probably more likely a wrong parent selection
what is the error of the clk_set_freq ? ERANGE ?

also iirc only the first clock consumer driver can set freq but i might be wrong about it.
 
rk_iommu3: LLLL 9abf5000 ffffa0009abf5000
if I manully writes 9abf5000 to 0xff903f00 with
./devmem2 0xff903f00 w 0x9abf5000 it works, it seems the code is intended to do it as well..?
N B I guarded out everything related to aclk enabling/disbling in this test
 
I have enabled the DRM stack + display controller and soon the panfrost driver on FreeBSD 15.0-RELEASE on the radxa zero 3W board. Can someome tell me what's the situation of iommu for this board ? I don't want to see this kind of errors anymore :


Senza titolo.jpeg


AFAIK iommu was not present at all or not complete ? Can you point me to the linux source code ? I want to try to port the code for FreeBSD for arm64. Can the same code be used for the RK3399 and the RK3566 the same ?
 
Thanks. Did u already develop the missing hacks ? Do you want to share them ? thanks.
For RK3399 and RK3566 the code is the same if it is ported from Linux ?
 
yes i have a kinda working system.
the zip files contains a tar file which contains all the files i modified versus a 14.3-RELEASE stock source
it has all drm-subtree + lots of allwinner and rockchip patches (includes Søren's patch set)
 

Attachments

Back
Top