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

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
 
covacat said:
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
Click to expand...
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
covacat said:
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
Click to expand...
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
covacat said:
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
Click to expand...
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>;
github.com

freebsd-src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-base.dtsi at 9b54998d1bdd5098d5538052024f88edcd625b4f · freebsd/freebsd-src

The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests.... - freebsd/freebsd-src
github.com github.com
 
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
 
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
 
You must log in or register to reply here.
Back
Top