<Parthiban>
MasterR3C0RD: thanks. Let me check. Did you managed to boot with it? I have a custom PCB with A133 in it.
<MasterR3C0RD>
Only supports DDR4 at the moment with fixed parameters and on devices that don't require any trainings beside read calibration, but those are a WIP
<MasterR3C0RD>
parthiban: I haven't tested booting a kernel with it yet, but it gets into U-Boot. To boot an actual OS I think we might need patches to ARM-Trusted-Firmware as well
<Parthiban>
ok, I have lpddr4. shouldn't change much?
<MasterR3C0RD>
That does mean it won't work yet; LPDDR4 and DDR4 are completely different
<MasterR3C0RD>
You can probably see in that code that there's a load of checks for LPDDR4 in particular; there's a lot more trainings needed
<MasterR3C0RD>
I can see if I can get in some of the ground work for you to try it on your board though. Can you make a Gist or something with the boot0 logs? A few parameters are dumped there that I'll want to take a look at
<MasterR3C0RD>
It would be everything up until the U-Boot banner over serial
<Parthiban>
I can compile u-boot from source. But SPL parts are already .a or in binary forms from vendor.
<MasterR3C0RD>
Interesting, you have a slightly higher patch version of boot0 than I've been working off of (V0.697 vs V0.69). And there's indeed something else I will need to implement to support your board; there's a phy_dfs_clk routine there that I hadn't seen used up until now that might be needed
<MasterR3C0RD>
Also a different PMU (AXP2202), but that's likely supported by an existing SPL driver; not sure which one but I'll investigate further
<Parthiban>
no, PMU in u-boot is not properly setup in my end. It's AXP717C
<Parthiban>
I have these working in the kernel.
<MasterR3C0RD>
Ahhh okay. If you want to see if you can get it working, I did also post a kernel tree with rebased patchsets Allwinner submitted a few years ago: https://github.com/BrokenR3C0RD/linux-a100
<MasterR3C0RD>
It'd be very useful to see if it'd boot; you'll need to modify your device trees though. There's a DTS for the "Allwinner Perf1" you might be able to use as a base.
<Parthiban>
No worries w.r.t the kernel. I have MMC, watchdog, WiFI over SDIO, PMU for GPU working. Also have a custom devicetree for the custom PCB ( which I can't post to upstream),
<Parthiban>
I will be getting this SoM + board during this week (on the way). So I will add this instead of the custom PCB.
<Parthiban>
Also am getting a A523 from them. But that's not listed in their website for some reason.
<MasterR3C0RD>
Did you get the kernel stuff working on Allwinner's kernel or mainline?
<Parthiban>
My main idea is to get the DE with GE8300 working. but that's super long short to discuss now ;-)
<MasterR3C0RD>
s/kernel stuff/devices and such/
<Parthiban>
upstream 6.12 -rc 3
<Parthiban>
Vendor tree with 5.15 or 4.9, both already works.
JohnDoe_71Rus has joined #linux-sunxi
<MasterR3C0RD>
Sweet! The patchsets I rebased add support for USB, some additional MMC related things, and DVFS
<Parthiban>
Super. I will check then.
<MasterR3C0RD>
Will try to submit them to the mailing list sometime this week, would be great to get them tested first though
<Parthiban>
+1
<MasterR3C0RD>
In regards to the GE8300, I also mentioned above that I requested firmware and device info from Imagination a few days ago, so hopefully that gets the ball rolling for you on that front :)
<Parthiban>
Do you have an open issue somewere for that? In mesa3D or something?
<MasterR3C0RD>
Might look at ordering myself one of those HelperBoards as well, might ease development a bit. Do you know if it has SWD? From the pictures it seems to have a USB-C labelled "debug"
<Parthiban>
I can only confirm after getting that in hand.
<MasterR3C0RD>
Alright
<wens>
apritzel: the SDM pattern is just a fixed point value
<wens>
tokyovigilante: in that case the headphone switch should be an aux device to the existing sound card. the sun4i-codec driver can't do simple-card because it is already completely self contained
<apritzel>
wens: fixed point value> yes, I now figured that, the old comments in the code suggested otherwise. And the H616 and A523 manual actually describe the SDM setup
<apritzel>
MasterR3C0RD: you can paper over the missing TF-A code for now, that would just be needed for SMP, so it's not a real showstopper for kernel *development*
<apritzel>
parthiban: MasterR3C0RD: AXP2202 is just another name for the AXP717 (check here: https://linux-sunxi.org/AXP_PMICs). We support that already in both the kernel and U-Boot (incl. SPL)
<apritzel>
also please note that the GE8300 is really just for 3D, framebuffer and video output (LCD or HDMI) are handled completely separately by Allwinner IP
<apritzel>
chances are the IP is already supported, courtesy of H6 support
<Parthiban>
apritzel: yeah, DE and TCON needs to be enabled, which am checking already with custom PCB and helperboard.
<Parthiban>
apritzel: regarding the SPL and U-boot, we still need to LPDDR bits to get a working?
<apritzel>
for proper support: yes. But you might be able to play tricks with using boot0 to do the DRAM init, then loading mainline U-Boot (for instance via FEL)
<apritzel>
(to unblock you and allow working/testing on Linux patches)
colinsane has quit [Ping timeout: 480 seconds]
hipboi has quit [Quit: hipboi]
colinsane has joined #linux-sunxi
<Parthiban>
apritzel: I will try, to compile u-boot upstream for a133 then.
<apritzel>
it's just compile tested, but hopefully provides enough breadcrumbs for you to follow and base your work on
<Parthiban>
apritzel: Pulling it. Loading using fel?
<apritzel>
FEL doesn't work for me properly, as this tablet uses some kind of secure boot, and our SMC workaround doesn't seem to work properly
<apritzel>
but it might work for you, just give it a try
JohnDoe_71Rus has joined #linux-sunxi
<Parthiban>
apritzel: bl31 can be skipped as well?
MasterR3C0RD_ has joined #linux-sunxi
MasterR3C0RD is now known as Guest6983
MasterR3C0RD_ is now known as MasterR3C0RD
<apritzel>
yeah, for now, though I think you need to pull some tricks apart from: make BL31=/dev/null to make it boot from SD card
<apritzel>
I guess an 8 byte trampoline to jump to U-Boot proper should do the trick: mov x0, #0x4a000000; br x0
<MasterR3C0RD>
apritzel: Ah, I missed the wiki entry on the AXPs; thanks! As for the GE8300, was aware it wasn't necessary for a framebuffer; however the plan is to use the mainlined code to replace the current firmware for these devices, which run Klipper alongside Klipperscreen, and that relies on some GTK stuff; would be nice to have Zink running
<apritzel>
yeah, seemingly 3D support is becoming more and more required even for normal desktops
<jakllsch>
stupid
<apritzel>
but at least you might see something on the screen for now
<apritzel>
parthiban: in case you wonder: try to run some hex editor on a fake bl31.bin, with those bytes in: 00000000 00 40 a9 d2 00 00 1f d6
<Parthiban>
apritzel: I want to see the SPL in first place before trying that.
<Parthiban>
"SPL: eGON header is not found" it's missing header?
<apritzel>
sure! you should see the SPL banner on serial, even if PMIC and DRAM don't work
<apritzel>
parthiban: you would need to give spl/sunxi-spl.bin to sunxi-fel
<MasterR3C0RD>
Yeah, I still haven't brought up a kernel yet, but was messing around with trying to bring up ethernet in U-Boot last night (mainly to see if bringing it up might be a quick job). Looks like the syscon is missing from the base DTSI; added a simple entry based on that for h616 but no dice
<Parthiban>
"./sunxi-fel spl ../out_uboot/spl/sunxi-spl.bin" this is command which tried. Yes, I have your patches for A133 from your branch.
<apritzel>
parthiban: and make sure to not use the TOC0 flag I have used for my tablet, in that defconfig: you need the default EGON
<MasterR3C0RD>
Well, it got close but probing for the device failed, and attempting an MDIO read caused a sync abort
<Parthiban>
### ERROR ### Please RESET the board ###
<Parthiban>
I have something in the console now :-)
<apritzel>
\o/
<apritzel>
parthiban: and yeah, this is with MasterR3C0RD's DRAM code as you yesterday, so without any LPDDR4 bits
<apritzel>
s/as you/as of/
<MasterR3C0RD>
parthiban: Sweet! That's indeed due to missing DRAM timings; additionally it's currently hard coded to my device's DRAM code
<MasterR3C0RD>
s/code/config/
<Parthiban>
Great!
<apritzel>
MasterR3C0RD: I started to move some parameters to Kconfig, renaming the existing H616 parameter entries to make them re-usable
<MasterR3C0RD>
So it won't bring up DRAM on your device quite yet, but it's good that it's getting through clock, CTL and DFI initialization
dsimic is now known as Guest6985
dsimic has joined #linux-sunxi
<MasterR3C0RD>
apritzel: Awesome, thanks! That was something I was likely going to do after getting LPDDR4 timings extracted; annoyingly the structure of the DRAM code for setting timings is clunky, so it's a bit of a "fun" project getting it working.
<apritzel>
MasterR3C0RD: Ethernet is both useful, but also sometimes challenging, due to many details. I help myself with an USB->Ethernet adapter meanwhile, which typically works much easier
Guest6985 has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
parthiban: Have you tested out the kernel with the rebased patches?
<apritzel>
I haven't enabled USB in my branch, but I think it's trivial, given we know the bits, from the Linux patches
<Parthiban>
MasterR3C0RD: No, not yet. Will do once I get something working in the u-boot.
<Parthiban>
They have the same one for A523 as well.
<Parthiban>
I have a `sys_config.fex` with all these ddr param for lpddr4, ddr4 stuff. This needs to be decoded in the SPL parts?
<MasterR3C0RD>
parthiban: There are parameters from that which will be needed (dx_odt/dx_dri/ca_dri, TPRs, MRs), but what's currently missing is the JEDEC timings; the current ones are in `a133_ddr4.c`, which have to be extracted from reverse-engineering of the dram init code
<MasterR3C0RD>
I have the function decompiled, I just need to extract the LPDDR4 timings from the code, which takes a little bit of time
<MasterR3C0RD>
Won't be able to get that in until tonight (it's currently noon where I'm at), and I don't have a device to test the timings with. It'd be useful if you could send over your TPR10 and TPR13 though, those control which calibrations I'll need to implement before SPL will properly initialize DRAM on your device
<apritzel>
MasterR3C0RD: many thanks for spending all the time on this, btw. DRAM init is usually the showstopper for new SoC support, so having something here is a big win!
<apritzel>
parthiban: you can try throwing a vendor image/boot0 at https://github.com/apritzel/sunxi-fw, and hope that the extracted parameters under the H616 columns make sense
<MasterR3C0RD>
apritzel: It was an interesting challenge, and I had a great base to work off of (H616, init code with basic symbols, etc). Thanks for all your help in pointing me in the right direction!
<apritzel>
parthiban: that looks more expensive, and it's the one you get anyway, right? In my experience having different boards around among people improves the quality of the support
<MasterR3C0RD>
I might end up picking up an A133 Plus device in the near future to figure out whether or not it's just a better binning of the A133; there's a few "portable emulator" devices on Amazon with it
<Parthiban>
" TPR10 and TPR13" Do you mean to extract from the vendor spl binary?
<MasterR3C0RD>
Yes. I haven't actually verified if the numbers that get spit out by sunxi-fw are correct yet, my device fortunately had what appears to be the DRAM code compiled in debug mode, which meant I got a nice dump of the values contained in the DRAM parameters
<MasterR3C0RD>
If there doesn't appear to be one, I might ask if you would be willing to send over your DRAM library so I could look into the differences between DRAM init versions V0.69 and V0.697 at some point
<Parthiban>
I can share the files.
tiop has quit []
<MasterR3C0RD>
Hopefully at some point I'll catch jernej / junari and get some pointers on bank group autodetection; with that I'd be able to get rid of the dependency on the para1 parameter
<Parthiban>
MasterR3C0RD: I wanna help.
<Parthiban>
I was working for DENX in the past, so I know the u-boot parts. but not the DDR yet
<Parthiban>
there are libsun50iw10p1_fes.a libsun50iw10p1_nand.a libsun50iw10p1_sboot.a libsun50iw10p1_sdcard.a in the board path.
<Parthiban>
only thing which comes to my mind is to print dram_para_t the values in the nboot nboot/main/boot0_main.c. Is that the way?
<MasterR3C0RD>
Your device is likely using `libsun50iw10p1_sdcard.a`, since it's booting from eMMC and isn't in secure boot mode
<Parthiban>
I saw in some fex file that the secure boot is disabled.
<MasterR3C0RD>
And the dram_para_t struct is actually wrong; actual size is 128 bytes I think, whereas the one in the header is much shorter
<MasterR3C0RD>
I think I posted an explanation of the actual structure of dram_para_t in here at an earlier point...
<Parthiban>
I have board/a133/ and board/sun50iw10p1/, strange. Which one?
<MasterR3C0RD>
A133 would be the correct one I think, that was newer on my board
<MasterR3C0RD>
The easiest way to check is just to run strings, the correct one will have V0.697
<Parthiban>
One under board/sun50iw10p1 is even older 0.48
<MasterR3C0RD>
Order of members in the dram_para_t* struct ^^
<MasterR3C0RD>
Interesting; can you try running `grep` and searching for V0.697?
<Parthiban>
not from Tina 5.0 and 4.0. It was from Android longan.
<MasterR3C0RD>
In terms of help with the DRAM code: the DRAM bank group detection is the only completely original code that needs to be figured out, and it has an odd aliasing pattern that I haven't quite determined the source of yet. The rest are calibration functions and TPR flag checks that I need to port over, but I have the code decompiled and just need to implement them. However, the other drivers would be useful to investigate
<MasterR3C0RD>
eMMC worked for me after copying over the pinctrl and clock drivers; ethernet might need a little more work though
<Parthiban>
ethernet might help a lot for me to do the tftp thing. I can check that.
<MasterR3C0RD>
Awesome; there's a user manual on the linux-sunxi wiki page for A133 that has some info about ethernet, but you might have a copy of something similar already. There might be some syscon things that need to be set up as well in the device tree
<MasterR3C0RD>
That's about where I ended off last night anyways
<Parthiban>
MasterR3C0RD: apritzel: Many thanks, closing for the day. Will continue in the morning.
<MasterR3C0RD>
o/
<Parthiban>
apritzel: regarding the board, yes am yet to receive the helperboard for A133 and A523. But hopefully delivered before end of this week.
<Parthiban>
apritzel: Also I requested a small custom PCB for PCIe for the A523.
MasterR3C0RD has quit [Remote host closed the connection]
MasterR3C0RD has joined #linux-sunxi
<MasterR3C0RD>
apritzel: I took a quick look at the code in sunxi-fw; there's definitely a few fields I'll need to add for A133. More specifically, there are actually 14 TPRs, and TPR14 being used in the PHY data-bit delay compensation routines so it's not inconsequential. I'll make a PR later to add the structure
<MasterR3C0RD>
s/being/is being/
<MasterR3C0RD>
Really happy the version of the DRAM code I decomped had all the debug data, made it a lot easier to figure out the structure of the DRAM parameters used by boot0
<MasterR3C0RD>
s/data/prints/
<apritzel>
yeah, definitely the debug version of libdram were often the ones used for the rev-eng-ed drivers. But it's still a lot of tricky work, so kudos!
MasterR3C0RD6 has joined #linux-sunxi
MasterR3C0RD6 has left #linux-sunxi [#linux-sunxi]
MasterR3C0RD is now known as Guest7007
MasterR3C0RD has joined #linux-sunxi
MasterR3C0RD has quit [Quit: Bye-bye!]
MasterR3C0RD has joined #linux-sunxi
Guest7007 has quit []
<MasterR3C0RD>
apritzel: It was certainly a learning experience HAHA
colinsane has quit []
colinsane has joined #linux-sunxi
ftg has quit [Read error: Connection reset by peer]