<MasterR3C0RD>
Ghidra really does not like this function, and Binja's output seems somewhat nonsensical, but I think the gist of it is that it writes values to the first 16 words of RAM
<MasterR3C0RD>
Then it loops through to see if i + 16 == i. If it doesn't, then it checks to see if i + 32 == i
ftg has quit [Read error: Connection reset by peer]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<apritzel>
MasterR3C0RD, parthiban: btw: as a stop gap measure, you can use an H6 build of TF-A for the A133, for now. PSCI runtime services don't work, but it boots and does the secure setup correctly
<MasterR3C0RD>
I get part of it; it's writing odd numbered indices as-is, and NOT(index) to even numbered, and then trying to check for aliasing at +64. But then what even is the point of checking 128 if they both break to the same place?
<MasterR3C0RD>
Both Ghidra and Binja are getting this result; Ghidra has a much harder time though, it's jumping to labels and everything
Daanct12 has joined #linux-sunxi
<MasterR3C0RD>
The best part, of course, is that it doesn't work
<apritzel>
MasterR3C0RD: welcome to Allwinner ;-)
<apritzel>
So mainline boots for me now on my A133 tablet. Oddly enough the SD card doesn't work, though eMMC does
<MasterR3C0RD>
I presume someone else has run into this and had the same realization LOL
<MasterR3C0RD>
apritzel: Interesting; that's one of the few things I can't test, since my device doesn't have an SD card
<apritzel>
it's typically one of the least problematic devices, and it works in U-Boot: I loaded kernel and initrd from there
<apritzel>
I guess I need to put some su binary on the eMMC and check the regulators and other bits in Android (I disabled the AXP for now, to not accidentally kill something)
<MasterR3C0RD>
Oh, I think I might have bank group detection working?
Schimsalabim has quit [Read error: Connection reset by peer]
<MasterR3C0RD>
Well, considering there's only one DDR4 device between the 3 of us, there's no way for me to confirm whether the bank group autodetection works; however since it seems to work on my device for now, I've pushed it up and re-enabled DRAM autoconfig
<parthiban>
apritzel: MasterR3C0RD: Morning. SDIO in mmc1 for A133 still didn't work. Am moving to helperboard A133, which got SD card. I can try that.
<MasterR3C0RD>
parthiban: apritzel noted that he was having issues with his SD card slot, so that would be a very useful test
<parthiban>
SD in vendor works. So am sure there is no problem in the hardware side of it.
<MasterR3C0RD>
Also, apritzel caught the bug that was preventing LPDDR4 RAM from working, so that is now functional!
<parthiban>
Functional with LPDDR4?
<MasterR3C0RD>
Yes, he was able to boot into U-Boot
<MasterR3C0RD>
And then into mainline
<parthiban>
Wow. I really want to change the u-boot. Am super stuck with 2018 and always preparing the android kernel image to boot the upstream kernel.
<parthiban>
Can I pull the branch or something?
<MasterR3C0RD>
Yep, same branch as always
<MasterR3C0RD>
One nice thing is it should auto-detect the amount of RAM you have now
<parthiban>
Great, let me try
<MasterR3C0RD>
So any para1/para2 problems should be resolves
<MasterR3C0RD>
*resolved
JohnDoe_71Rus has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
jernej has quit [Read error: Connection reset by peer]
<MoeIcenowy>
MasterR3C0RD: is the pad what you are hacking?
<MasterR3C0RD>
MoeIcenowy: Yep, more specifically it's the "R818"; same chip
<MasterR3C0RD>
This whole project started from me just wanting to get into 3D printing...
<MoeIcenowy>
hahaha I started to hack Allwinner long before start 3d printing
<MasterR3C0RD>
Well, I didn't have anything with an Allwinner chip until now; then I did a bit of research, realized it's running hyper-proprietary bastardizations of open-source 3D printing tooling, and decided "you know what? It can't be that hard to get this running almost full OSS"
<MasterR3C0RD>
But some stuff's still closed source, like some of the Klipper stuff; they only post binaries for those
<MasterR3C0RD>
Someone else got Debian Bullseye running on it, but I decided to go a step deeper and figure out how to get this running as close to mainline as possible. And now I'm 3 weeks in, I have two Sonic Pads (in the words of one of my favorite YouTubers, "through the magic of buying two of them..."), and I've expanded my goals a little HAHA
<MoeIcenowy>
buying 2 of this sounds crazy
<MoeIcenowy>
(well my most recent Allwinner SBC is bought for 3d printing too -- Mellow Fly Lite 2, I bought it becuase I failed to properly organize the space of my Voron 0
<MasterR3C0RD>
Well that was so that I could at least do some 3D printing in the meantime
<MoeIcenowy>
so I need a SBC as small as possible
<MoeIcenowy>
hahahaha depends on this on the workflow sounds tragic
<MasterR3C0RD>
Well, I'll probably be working on the A133 for a while; it's been frustrating at times but also one of the more rewarding projects I've worked on in a while
<MasterR3C0RD>
parthiban: Hmm actually I might have spoke too soon... the potential alias value you got back was different the second time. You're testing this on the Helperboard, yes? DId you update all of your parameters, including MRs and TPRs, to match the values used by that board, rather than the prior board's?
indy has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<szemzoa>
theslowcoder: Do you've your v85x ccu driver in a pulbic repo somewhere? I've my own patches at my awboot's repo, but when I tried to add driver for the audio codec, I saw my audio clocks isn't working. Already fixed them and a playback is working now (still hackish), but I'm curious how you modelled that clocks.
warpme has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<parthiban>
MasterR3C0RD: Sorry, I was super swapped across and came back in.
<parthiban>
MasterR3C0RD: I did test this with Helperboard. Wait. let me test with helperboard and stick with it.
<parthiban>
That's the diff which is applied to defconfig
<parthiban>
oh wait, I used the wrong values
<parthiban>
I have "[275]DRAM SIZE =1024 MBytes, para1 = 30fa, para2 = 4000000, tpr13 = 7521" for the 1GB variant
<MasterR3C0RD>
The TPR13 would be important, but the other two shouldn't matter with autoscanning. Also, I don't see the updated DX_ODT, DX_DRI, CA_DRI
<parthiban>
Sorry, my mistake
<parthiban>
Changing it
<MasterR3C0RD>
Also TPR12 looks wrong
<MasterR3C0RD>
Those would cause funky things to happen; they control the drive strength of the command/address lines, the drive and on-die-termination of the data lines, and the calibration values for the data lines. LPDDR4 seems to be ultra sensitive to errors there
<parthiban>
Btw, can I load the U-boot as well with FEL?
<gamiee>
MasterR3C0RD : ping
<MasterR3C0RD>
Yep, that's how I've been testing. I don't have an SD card so that's the only way I can bring things up
theslowcoder has joined #linux-sunxi
<MasterR3C0RD>
gamiee: pong
<gamiee>
hi!
<gamiee>
apritzel mentioned me about H616 board, I guess you are interested about it?
<parthiban>
MasterR3C0RD: "./sunxi-fel uboot u-boot-sunxi-with-spl.bin" something like this? This is my first success test story with fel mode.
<MasterR3C0RD>
gamiee: Yep, I wanted to work on merging the A133 and H616 DRAM drivers together, but I wouldn't want to touch DRAM code for a chip I don't have
<MasterR3C0RD>
parthiban: Yes, that should be all you need
<MasterR3C0RD>
You might have to sudo if you don't have udev rules set up properly
<MasterR3C0RD>
Otherwise it'll give you a permission denied error
<parthiban>
"[187]DRAM SIZE =4096 MBytes, para1 = 310a, para2 = 10001000, tpr13 = 7525" I changed these 3 values for the 4GB variant. But it fails still.
<parthiban>
MasterR3C0RD: udev is setup properly in my end. When I run the "uboot", it still loads only SPL part.
<MasterR3C0RD>
parthiban: Does it fail initializing DRAM? If so, make sure all of your configuration settings are set up correctly for this board. If it's getting past init but failing, it might be due to ATF; you can try disabling it by undoing the commit in my repo that undid it, though you might be left single core
<gamiee>
MasterR3C0RD : great! I will contact you in DM's on IRC from gamiee_ account
<MasterR3C0RD>
parthiban: Hopping off for the night; if you still have no luck with DRAM on the 4GB board drop as much info as you can and I'll see if there's something causing issues due to other settings; I think that device is the first dual rank I've ran into thus far, which might be related
<parthiban>
MasterR3C0RD: able to get into u-boot in 1GB variant. 4GB variant still fails to SPL.
theslowcoder has joined #linux-sunxi
<apritzel>
parthiban: ah yes, sorry, I think I mentioned this a while ago, but didn't follow up on this. On my "secure" tablet switching to 64-bit doesn't work in the first place, so I could never test this
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<IlikeTech>
Can the boot ROM on the Sunxi SOCs load uboot from an SD/MMC off a FAT32 partition?
<IlikeTech>
or just off the immediate beginning of the card written directly?
theslowcoder has quit [Ping timeout: 480 seconds]
warpme has quit []
<jelly>
sigh. I have in my hands a projector device my brother bought for me that was supposedly advertised as "android 14". It's actually Android 11, a total of whooping 1GB RAM, and apparently a SoC called "H713" judging by the S/N. Is H713 a real thing?
<apritzel>
IlikeTech: the BootROM has no idea of any filesystems. It looks at sector 16, then at sector 256 or 512 of the SD card (or eMMC)
hipboi has quit [Quit: hipboi]
<apritzel>
IlikeTech: U-Boot's SPL supports filesystems, though, so you could theoretically load the remaining components (U-Boot proper, TF-A, DTB, crust) from a file
<apritzel>
but this is not supported for sunxi, and I guess it would get a bit nasty to support that
<apritzel>
jelly: we heard of the H713 before, used indeed in some projector. Apparently it's a separate die, so not just a relabelled chip
<jelly>
thanks!
<apritzel>
the Wiki says it's a sun50iw12p1
<jelly>
I wanted to look at firmware but they host it on a really suspicious file sharing site that requires either windows app installation or account registration or both, to even download
<jelly>
yes, that's the _only_ place on the wiki where H713 is even mentioned
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<apritzel>
yeah, which is not really great news, as we basically don't know much about it
<apritzel>
chances are it's close to the other quad-A53s, but the devil can really be in the details here
<apritzel>
and a projector doesn't strike me as the most hacker-friendly device
<apritzel>
MoeIcenowy: which firmware, exactly? grub?
Daanct12 has quit [Quit: WeeChat 4.4.2]
<alikates>
jelly: yeah it sounds quite similar to mine. I managed to use FEL through the USB-A port, but wasn't able to chainload uboot or linux. I got stuck there and decided to put it back together as I wanted to use it :P
<apritzel>
yeah, it's annoying if devices with an Allwinner chip are actually useful :-D
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
<MasterR3C0RD>
parthiban: My bad; happy you got up and running!
<MasterR3C0RD>
apritzel had mentioned it before; I didn't rememember configuring it but it appears I must have
<MasterR3C0RD>
As for the 4GB not booting, it's either due to address mapping or the simple read/write test, at least if that value you get from it is static
<MoeIcenowy>
apritzel: the firmware loaded by BROM, boot firmware
<MoeIcenowy>
`Fixed offsets to firmware data is supported only for legacy reasons. All new platforms are expected to use partitions to locate firmware files. A future version of this specification will disallow the use of fixed offsets.`
<jelly>
alikates, ah, yes, I got a HY320, apparent vendor: https://www.alliwava.com/pages/hy320 fw seems to have several ways of updating; if FEL works that's at leasat promising
<parthiban>
MasterR3C0RD: I got the SD and eMMC working in u-boot.
<parthiban>
Haven't tried the USB.
<parthiban>
Thought of giving a try for emac, this way I can play with tftp and possibly nfs booting the RFS.
<MasterR3C0RD>
parthiban: Awesome! I did get eMMC working, though I couldn't get any faster than HS (even though the eMMC on my board theoretically supports HS200)
<MasterR3C0RD>
It looks like that might just be lack of support in U-Boot though, and 52MHz is fine for boot
theslowcoder has joined #linux-sunxi
<parthiban>
Yeah, am fine with booting it for now.
<parthiban>
emac is good addition though.
<MasterR3C0RD>
I looked into trying to get it working early on, but didn't have any luck
dsimic is now known as Guest7870
dsimic has joined #linux-sunxi
<parthiban>
"Net: Could not get PHY for ethernet@5020000: addr 0" MAC seems fine, not able to get the PHY stuff.
<parthiban>
Am not sure how to find the PHY address the datasheet. Is it the PHY Identifier Register ?
<parthiban>
may be I should try in the kernel.
Guest7870 has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
parthiban: I believe the PHY is communicated with via MDIO
<parthiban>
Correct. Need PHY address
<parthiban>
Kernel doesn't expect it to get from the dts
<parthiban>
It loops for all values or something. But u-boot needs the correct value.
<parthiban>
yeah tried 1 already. technically am still missing some properties it seems. Also the regulator may be. I will dig further.
<parthiban>
But good thing is that the MAC address is read. So the emac is compatible as it is with a64
<parthiban>
Not sure how to map the reset pin in the devicetree.
<MasterR3C0RD>
Apparently you can just set reset-gpios on the PHY
<MasterR3C0RD>
If you succeed in getting ethernet up and running, do share the DTS nodes you're using; I might be able to get the emac added to my V2 patch series
<MasterR3C0RD>
Same with any of the remaining core peripherals, if they work with an existing compatible I might be able to get the DTS nodes mainlined in this series
indy has joined #linux-sunxi
warpme has quit []
theslowcoder has quit [Ping timeout: 480 seconds]
<apritzel>
alikates: jelly: if you do a github code search for "sun50iw12" there are some hits, looks like pinctrl and CCU drivers, which would be essential
<apritzel>
but it's still a lot of work, and surely a lot of unknowns left
<MasterR3C0RD>
Btw, does the `ums` command in U-Boot work on non-A133 devices when attached in gadget mode? I was getting some fsg assertion error whenever I tried it; never managed to get it working correctly
<loki666>
apritzel any new idea on the H700 issue. Do you think the u-boot flaky LPDDR4 detection issue could be linked to kernel crashes?
<MasterR3C0RD>
Was hoping it'd be an easy way to get an eMMC dump, but even when I commented out the assert I got it to enumerate correctly once before USB stopped responding; most other times it would have the fsg error after enumeration
<apritzel>
MasterR3C0RD: ums is tricky to configure, though it worked for me in the past on other SoCs
<apritzel>
loki666: I don't think that the twice-the-size detection is to blame, though it could of course be slightly wrong DRAM parameters
<loki666>
Do we have a way to extract these parameters from BSP boot0 ?
<apritzel>
loki666: you could do the other old trick: reduce the DRAM frequency by 24 or 48 MHz. This was a common hack in the past at least, to overcome unreliable DRAM operation under stress
<loki666>
I'll test that
<MasterR3C0RD>
What is the ratio of the claimed DRAM clock to the actual DDR clock, btw? 720/792MHz (the frequencies I've seen on A133) seem to be fairly weird frequencies to run DDR4/LPDDR4 memory at
<loki666>
For H616?
<loki666>
I mean H700 config?
<MasterR3C0RD>
For H616/A133 parameters
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
just times 2, I'd say
<MasterR3C0RD>
So it's running my DDR4 at 1440MHz? That is fairly weird
<apritzel>
if that sounds weird and slow, you would be spot on ;-)
<MasterR3C0RD>
*1440 MT/s
<apritzel>
welcome to Allwinner
<loki666>
+CONFIG_DRAM_CLK=672
parthiban has quit [Ping timeout: 480 seconds]
<jelly>
the fw on that H713 thing is flashed by using an "allwiner_resst" tool, I guess you have to be drunk to do it
<MasterR3C0RD>
Well, since I have control over raw timings and power now I might try sidequesting at some point into the really silly task of trying to overclock the RAM LOL
<MasterR3C0RD>
jelly: I saw that; it looks like PhoenixSuite to me
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<apritzel>
MasterR3C0RD: godspeed on that journey, and I would start with just applying the JEDEC parameters before doing "overclocking"
<apritzel>
but in the past I didn't have much luck with that (either H616 or T113s, don't remember which), some timing values just didn't make sense when comparing to the JEDEC numbers
<MasterR3C0RD>
It'll definitely be a palate cleanser project I'll try to take on at some point; I think I'll want to factor out some of the common timing setup code though so that extra timings are a little less boilerplate to copy