hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
<MasterR3C0RD>
I think so; I need to look into it, but to me it makes a lot of sense. During the setup of timings, there's an extra "offset" that can be applied during the timing writes
<MasterR3C0RD>
The shadow registers are the "unknowns" written to in the H616 code
<MasterR3C0RD>
The A133's weird though, since there appears to be 8 banks of shadow registers on its controller block; the latter 4 of those are left unused
Daanct12 has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
montjoie has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
vagrantc has quit [Quit: leaving]
Schimsalabim has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
<parthiban>
MasterR3C0RD: wasn't aware about the nosmp in command line. I will use that. Thanks.
KREYREN_oftc has joined #linux-sunxi
<parthiban>
"hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 (0,8000003f) counters available" looks ok
<MasterR3C0RD>
Sweet!
<MasterR3C0RD>
parthiban: I can take a look at your custom board's RAM init issues sometime this weekend if you'll have continued access to test
<parthiban>
I will be here. Many thanks.
<parthiban>
Am in CET.
<parthiban>
"perf record" ok too IMO
<MasterR3C0RD>
I'm in ADT, which is 4 hours behind you I believe
<MasterR3C0RD>
And awesome, happy to see the PMU works!
<MasterR3C0RD>
I'm a bit of a night owl anyways, but I've been pushing it a little too much
<parthiban>
But it failed to work.
<parthiban>
Gave up on that and to used GPIO to enable and Turn the display on for now.
<MasterR3C0RD>
Assuming you set the pin functions, it's possible that the PWM block on the A100 series is different
<parthiban>
No, D1 and A133 are exactly same. Except D1 provides more channels.
<MasterR3C0RD>
Guessing this is another case where you're getting nothing in logs?
<parthiban>
No, enabled CONFIG_PWM_DEBUG and helped. Clock handling in the driver seems wrong. But don't wanna step on the developer's toes. May be I will report the state in the mainling list which can help him.
<parthiban>
that series is going on for a year now.
aggi has quit [Remote host closed the connection]
hipboi has joined #linux-sunxi
aggi has joined #linux-sunxi
<MasterR3C0RD>
Did you select the correct clock? A100 uses APB1 instead of APB0
<parthiban>
Yeah I did.
<MasterR3C0RD>
Likely worth mentioning on the mailing list; perhaps you could help them with testing, and they could help with getting PWM up and running on A133 while they're at it. It does seem like they might be missing tested-bys
<parthiban>
I will do that.
<MasterR3C0RD>
By the way, it seems like your emails aren't making it to me
<MasterR3C0RD>
I do see them on lore, but they don't seem to be making it to my email
<parthiban>
Not sure. Nothing special with my mail server.
<MasterR3C0RD>
Would you be willing to send me an email directly so I can see if it's a misconfiguration on my end?
<parthiban>
Wrote one now
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
<MasterR3C0RD>
Hmm, seems like it might be that my server's configured to only allow TLS1.3
KREYREN_oftc has quit [Ping timeout: 480 seconds]
<parthiban>
Hmm, I wasn't aware. I will check.
KREYREN_oftc has joined #linux-sunxi
<MasterR3C0RD>
I dropped my security settings to allow for TLSv1.2 for now, it might be your CloudFilter setup not supporting TLSv1.3. No big deal, as I still have the ciphersuites restricted and it still chose a decent one
<parthiban>
My IT team can figure that. I will ask them. Thanks
<MasterR3C0RD>
Anyways, back to sunxi stuff. Have you gotten any other peripherals aside from the GPU up and running, outside of the ones added in the device tree?
<parthiban>
Short answer, no.
<parthiban>
Tried emac, pwm. But not fully successful.
<MasterR3C0RD>
Alright, wanted to double check, as it would be quite silly if we duplicated work
<MasterR3C0RD>
Have you tried the DE or TCON?
<parthiban>
As I have the USB ethernet working, I have better dev environment.
<parthiban>
Tried DE and TCON too, it failed. Today and tomorrow is the day for display in my end.
<MasterR3C0RD>
Let me know if you have success with that; I'll try seeing if I can get something working with the PHY
<MasterR3C0RD>
s/PHY/EMAC/
<parthiban>
PHY is fine IMO
<parthiban>
Let me share the emac and phy's dts changes which i have
<parthiban>
Use the last one. Syscon was missing in previous.
<MasterR3C0RD>
I don't know what other peripherals you'll be able to test, but until my TrimUI device arrives I'll be limited to working on GPU/DE/TCON/PWM, EMAC, SDIO over MMC1 (turns out I have an XR819, though the firmware looks like it's ARMv7 so maybe reverse engineering that might be a way-in-the-future project...) and potentially the audio codec
<MasterR3C0RD>
Once the TrimUI arrives though I'll probably be able to test GPADC and LEDC as welll
<parthiban>
IMO GPU is fine. I pulled the pmdomain driver from vendor for now. And added few changes to the powervr driver.
<parthiban>
TCON is what am checking now.
<parthiban>
Not much details for DE in the manual.
<MasterR3C0RD>
Yeah DE is usually documented in a separate manual
<parthiban>
Anything open?
<MasterR3C0RD>
There doesn't appear to be at the moment
<parthiban>
Not for A133, in general for DE
<MasterR3C0RD>
But you can use source code from the Creality Sonic Pad's repo; I used that to determine it's a DE2.0
<parthiban>
Am cross checking the manuals actually
<parthiban>
D1 is more of a match for LCD atleast
<parthiban>
But D1 contains additional registers. So some there might be some surprises.
<MasterR3C0RD>
Hopefully we can work off the code of one of the TCONs as a base
<parthiban>
Yeah, hoping
<parthiban>
D1 got TCON TOP as well. Direct copy won't work at all.
<MasterR3C0RD>
According to the datasheet, the A133 PHY doesn't support MII; perhaps that's why it isn't working
<MasterR3C0RD>
Aside from that, looking at the vendor tree supports the idea that an A64 compatible should work for the syscon, as the offset is 0x30
<parthiban>
It's RGMII
<parthiban>
That's how it's wired in my PCB
<MasterR3C0RD>
Yeah, I was talking about the A64 compatible's driver configuration
<MasterR3C0RD>
There's a supports_mii field, but it doesn't seem to be used
<parthiban>
All the display pipeline is dsi so far in the upstream?
<parthiban>
Very strange, am missing something.
<MasterR3C0RD>
There's a separate GCON thing I believe
<parthiban>
GCON ?
<MasterR3C0RD>
Sorry, TCON
<parthiban>
TCON output goes to LCD panel directly.
<parthiban>
the only reference usage for that so far is arch/arm/boot/dts/allwinner/sun8i-a83t-tbs-a711.dts
<MasterR3C0RD>
Ohh you meant the upstream
<parthiban>
Yeah, am adding the tcon. So, yes
<MasterR3C0RD>
I'm working on the PHY, just got my device tree updated; it looks like you had the clocks misconfigured. EMAC_25M should be set as the PHY's clock I believe
<MasterR3C0RD>
Happy coincidence though, my board also has an RTL8211F. Finally decided to check my microscope's SD card to see if I got a decent picture of the PHY
<MasterR3C0RD>
Seems like some funky memory corruption is going on
hipboi has quit [Quit: hipboi]
Schimsalabim has joined #linux-sunxi
KREYREN_oftc has joined #linux-sunxi
apritzel has joined #linux-sunxi
KREYREN_oftc has quit [Ping timeout: 480 seconds]
warpme has quit []
ndufresne has joined #linux-sunxi
tech64 has joined #linux-sunxi
bauen1 has joined #linux-sunxi
<tech64>
hello, i am trying to get linux working on my tablet. which is a start 901.1, but there's already a re-badged version on the wiki, the gld kf026. i'm stuck at getting u-boot compiled since the defconfig for that device in u-boot is just missing
tech64 has quit [Remote host closed the connection]
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
dsimic is now known as Guest8227
dsimic has joined #linux-sunxi
Guest8227 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
tech64: well, I am afraid then it's not supported directly, despite the wiki entry. If you dare, you could try one of the generic configs, like q8_a13_tablet_defconfig, though this could be potentially dangerous
apritzel has quit [Ping timeout: 480 seconds]
<parthiban>
apritzel: Question about the display, for A133 there is 1 x DE, 1 x TCON_TOP, 1 x TCON (which am trying to enabled it as LVDS). Am sure that the TCON is same as the one in a83t. But regarding the tcon_top, there is no details in the manual. Also there is no details in the DE_CLK as well. The same goes with D1, H6 manuals. So the whole thing is reverse engineered or decoded from the vendor kernel's disp2? Or do we have reference/docs?
<apritzel>
same URL, just with DE3.0 instead for the newer version
<parthiban>
Wow, I should get one for A133?
<parthiban>
Reading it. Or is this general specification?
<apritzel>
this is more across SoCs, but chances are it's similar, if not the same as one of those SoCs mentioned there. But yeah, there might be an element of reverse engineering there
<apritzel>
or at least maybe correlating vendor code between a documented SoC and the A133
<parthiban>
Ok, I removed the TCON_TOP and used only the mixer using the existing CLK. Also added the lcd controller. Display pipeline didn't complain and also didn't work.
<parthiban>
Another question, D1 uses TCON_TOP and the support is added. So this is purely based on vendor code + existing spec + testing? Or do we have the DE specification for D1 somewhere?
<apritzel>
I don't know, I guess the authors of those patches would know. Maybe worth asking on the list?
<parthiban>
Yeah sure. I will do some reading of the specification and vendor code base. Thanks for sharing the specification, I wasn't aware there existed one.
<parthiban>
One other point, I tried using "devmem2", but it didn't work. Not sure why, but it always returns 0 and write doesn't complain either.
<MasterR3C0RD>
apritzel: Before I crashed last night, I was able to confirm that MMC2 (eMMC) works without the reparenting patch, as parthiban had said. In fact, I think it actually works better with it; either way it functions, just a little more stable
<MasterR3C0RD>
I'm thinking there's a possibility that's why MMC2 had NO_REPARENT, and then MMC1 and 0 were potentially copy-and-pasted from there
dok has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Quasar 5.2.4, revision: 5.2.4+git-7602-6f6dde446, build type: debug, sources date: 20160102, built on: 2024-10-29 17:47:19 UTC 5.2.4+git-7602-]
BroderTuck has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
<BroderTuck>
Taking a new look at what might be needed to supply a dts for the PengPod 1000 that I bought like 10 years ago, I believe starting with copying sun4i-a10-inet1.dts should work.
<BroderTuck>
All the values I see look correct between inet1.dts and my fex, but it's missing some stuff.
<BroderTuck>
(FEX file at https://palvencia.se/pp1k/pp1k.fex, I have an ancient 3.4 kernel on an sd-card for the device now, full lcd support)
<BroderTuck>
1) the pp1k has an internal sdcard slot, which I guess would be an mmc1, According to the FEX file, mmc1 has PH02 as sdc_det, should I just copy @mmc0 and use this value for cd-gpios? Anything else?
<BroderTuck>
2) usb0 looks correct (mini-usb with otg support). usb1 should be the A port, and usb2 for the wifi (Realtek 8188eu on my device, earlier models had 8192cu instead), I guess?
<BroderTuck>
fex says ph06 for usb1 usb_drv_vbus_gpio and ph03 for usb2 usb_drv_vbus_gpio, should these values be put in the dt somewhere, or is what's in there already enough?
<BroderTuck>
3) Device has an lcd screen and a (mini) hdmi port. How well (if at all) does linux handle 2 simultaneous outputs?
<BroderTuck>
4) I think just copying hdmi-connector, @de, @hdmi and @hdmi_out from e.g. sun4i-a10-a1000.dts should cover hdmi
<BroderTuck>
5) sun4i-a10-topwise-a721.dts seems to have a bunch of lcd-related stuff, can it be copied wholesale or would something have to be tweaked? (thinking mostly of the panel compatible)
<BroderTuck>
and finally, what would the model= and compatible= lines at the top look like?
<MasterR3C0RD>
5 is probably the easiest to answer; model should be set to the name of your device (i.e., "Peacock PengPod 1000"), and compatible I believe should be something like "manufacturer,device-name", "allwinner,sun4i-a10" (i.e., "peacock,pengpod-1000", "allwinner,sun4i-a10")
<MasterR3C0RD>
Definitely DE2, it has a slightly modified driver in the vendor tree in lowlevel_v2x
<apritzel>
ah, after stumbling around like an idiot in this whole recovery/adb/magisk/oem-unlock thicket, I am finally root on my A133 tablet
<MasterR3C0RD>
Heh, they really didn't make it easy for you huh?
<apritzel>
well, at the end it wasn't too bad (recovery mode, then fastboot oem unlock, then Magisk, patching boot.img), I just have no experience with that all, and found those instructions out there always quite confusing
<MasterR3C0RD>
I'm guessing there's no way you'll be able to completely replace the bootloader since it's in secure mode?
BroderTuck has quit [Quit: Ah well, anothery day perhaps]
<apritzel>
sure I can, it's Allwinner's fake secure mode, where the OEMs burn the "secure boot" fuse, but then do not burn an actual key. So a TOC0 image with signed by *any* key will be accepted
<MasterR3C0RD>
LOL
<apritzel>
it actually works already with mainline U-Boot, just ticking CONFIG_SPL_IMAGE_TYPE_SUNXI_TOC0=y and be done
<apritzel>
that's how I am booting it all the time from the SD card already, I just needed the regulator and GPIO assignments for the mainline DT
<MasterR3C0RD>
How often does a secure boot key actually get burned?