Hi
On 22.01.22 15:45, Daniel Palmer wrote:
Hi Dafna,
On Sat, 22 Jan 2022 at 22:06, Dafna Hirschfeld
<dafna.hirschfeld@xxxxxxxxxxxxx> wrote:
Hi, I compared the flow of the probe between the ido-sbc2d70 and the beaglev on which I tested the driver.
I noticed that only on the ido-sbc2d70 the field p_attr->support_vcore_backbone is true which then cause accessing the reg W5_BACKBONE_BUS_CTRL_VCORE0
which is not mentioned in the Programmer's Guide I have. Not sure what's that mean.
Interesting. It's possible they've moved things around.
That gives me a good hint. I can compare what the code in the binary
module seems to be doing.
On the beaglev I have the flow for the case:
p_attr->support_backbone = true;
p_attr->support_vcore_backbone = false;
p_attr->support_vcpu_backbone = false;
p_attr->support_dual_core = false;
It's possible this is a slightly different version of this IP or they
moved things around.
They got rid of the product id register for example so it's possible
they removed other bits they thought they didn't need and there is
hardcoding in their version of the driver.
I wanted to ask, How did you set the dt-binding for the codec of the .dts file? Was it from a datasheet you have or was it from a reference source code? or both?
The vendor DTS is here:
https://github.com/linux-chenxing/linux-ssc325/blob/979122be45d470e959c2245c996fa93dea10069b/arch/arm/boot/dts/infinity2m.dtsi#L160
You'll notice the weird bank thing instead of reg. The bank has to be
multiplied by 0x200 to get the address.. but that result doesn't
actually line up with the real address. So I looked at the binary
module in ghidra and they have it hard coded there. It's a total mess.
Hi,
which binary was that? the kernel module?
So in your code the reg is 'reg = <0x344800 0x800>;' , is that what was hard coded?
For the IRQ and clocks it's a bit easier as there are headers:
https://github.com/linux-chenxing/linux-ssc325/blob/89341c7012404c72e192f198b2ea6405ec80d15d/drivers/sstar/include/infinity2m/irqs.h
https://github.com/linux-chenxing/linux-ssc325/blob/89341c7012404c72e192f198b2ea6405ec80d15d/drivers/sstar/include/infinity2m/reg_clks.h
Could you send me the resources you have for that?
Also, maybe you have the schematic for the board? could you also send that if you do?
I don't have a schematic for the board as they wouldn't send it to me.
I had to probe it with a multimeter.
I'm not sure the schematic helps too much though as everything is
internal to the SoC.
I have some messy notes here of what I found out so far, some dumps of
the vendor driver running etc:
https://github.com/linux-chenxing/linux-chenxing.org/blob/master/ip/vdec.md
I see that you test the content of 0x1f344000 with 'devmem', what make you test this specific address?
Thanks,
Dafna
Cheers,
Daniel
