<apritzel>
argh, I found some log of someone messing around with a B300 ereader and FEL, and he redacted the SoCID!
<apritzel>
Florian, if you read this: the SoC ID identifies the SoC type, not a particular chip, it's not a serial number
ftg has quit [Read error: Connection reset by peer]
<apritzel>
so can you please share this number, we need it to confirm if the B300 is the same chip as the A50
<apritzel>
that would make things so much easier, as we have a user manual for the A50
<apritzel>
Florianclume: ^^^^
<anarsoul>
Hey folks, it looks like pinebook has issues with recent kernels, I tried 6.12.1 and 6.11.5, built-in LCD doesn't work with either. Is it a known issue before I start to debug it?
<anarsoul>
and I have a strong suspicion that reverting ca1170b69968233b34d26432245eddf7d265186b will fix the issue for me
<apritzel>
yeah, looks like a good candidate ...
<anarsoul>
6.7.5 is also broken, trying 6.1.0 now
<anarsoul>
and 6.1.0 works
<anarsoul>
I guess it's bisect time
<anarsoul>
for 6.1.0 tcon0 parent is pll-video0-2x, not pll-mipi
<anarsoul>
and tcon is at 1.8GHz vs 1.1Ghz
smaeul_ has joined #linux-sunxi
<anarsoul>
and pll-mipi cannot go above 1.4Ghz
smaeul has quit [Ping timeout: 480 seconds]
smaeul has joined #linux-sunxi
smaeul_ has quit [Ping timeout: 480 seconds]
smaeul has quit [Ping timeout: 480 seconds]
smaeul has joined #linux-sunxi
<anarsoul>
jernej: do you happen to remember is there a requirement for tcon0 clock to be a certain multiply of dclk?
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<anarsoul>
yeah, it's this patch and something else that forces pll-mipi when this patch is reverted
anarsoul[m] has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Soupborsh_ has joined #linux-sunxi
Soupborsh_ has left #linux-sunxi [#linux-sunxi]
gsz has joined #linux-sunxi
<anarsoul>
changing tcon0 parent in runtime by poking CCU regs also fixes the issue
<anarsoul>
e.g. 'devmem2 0x01c20118 w 0x82000000' changes TCON0 parent to pll-video-2x, and even with it running much slower than pll-mipi, it still works
gsz has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
<Soupborsh>
Hello if I enter FEL using keys and then sunxi-fel writel 0x1C20508 0x5AA5A55A and sunxi-fel wdreset it reboots and boot0 enters FEL
<Soupborsh>
Next I can load boot0 using spl and I will be in FEL with initialized dram
<Soupborsh>
apritzel: I loaded u-boot-dtb.bin and now in it's console
<apritzel>
Soupborsh: ah, that's good progress! I was halfway through with that boot0 hack...
<apritzel>
Please do not simply copy existing board descriptions, but strip it down to the minimum, then bring back features
<apritzel>
just copying defconfig and DTs can be dangerous, setting the wrong GPIOs or blasting 3.3V on a 1.8V voltage rail can destroy hardware
<apritzel>
in your case remove the Ethernet (SUN8I_EMAC), the regulator (CONFIG_SY8106A_POWER) and the VBUS pins from the defconfig
<apritzel>
and you should also strip down the DT, and remove the respective items (mostly the regulators)
<apritzel>
and of course most importantly: rename the whole thing!!!
<apritzel>
and we should really remove those boot1 references from the wiki, I don't think Allwinner used that anywhere in the past 10 years or so, still many people waste their time looking for boot1 ...
aggi_ has quit []
aggi has joined #linux-sunxi
warpme has joined #linux-sunxi
hentai has quit [Ping timeout: 480 seconds]
hentai has joined #linux-sunxi
gsz has joined #linux-sunxi
dsimic is now known as Guest3067
dsimic has joined #linux-sunxi
Guest3067 has quit [Ping timeout: 480 seconds]
<apritzel>
BroderTuck: good news, Florianclume confirmed it's 0x1755 for the B300, so it's the same SoC as the A50
<apritzel>
BroderTuck: so thanks again for finding this breadcrumb in the logs
BroderTuck has joined #linux-sunxi
<BroderTuck>
apritzel: Good! ( I recognize the name as the user who added the B300 and the device page on the wiki)
<BroderTuck>
So, a bit of wiki work would then be needed on the A50, B300 and "Allwinner Soc Family" pages, where the latter would involve moving B300 from the "TODO: Add to the following table: " to the table itself
ity has quit [Remote host closed the connection]
ity has joined #linux-sunxi
<apritzel>
exactly
ftg has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
psydroid has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
gsz has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
codekipper7 has joined #linux-sunxi
codekipper7 is now known as codekipper
warpme has quit []
<Soupborsh>
After executing boot0 with spl command you have to wait some time and then FEL commands will work.
<electricworry>
apritzel: I'm just getting around to trying tokyovigilante_'s patches in that branch you gave me the link to. If I'm reading it correctly, that branch includes the DE33 v5 patches and additional HDMI patches. Despite enabling hdmi, de, gpu and tcon_lcd0 in the dtb unfortunately I don't get any output. I just wanted to check is that where we're at or should that have worked?
<apritzel>
electricworry: I think that's supposed to work, but I don't know any details. Are there Anberic DT updates in that branch to copy from?
<anarsoul>
OK, so apparently on A64 RGB output only works when TCON0 clock parent is pll-video-2x, while DSI only works while TCON0 parent is pll-mipi
<electricworry>
apritzel: Thanks, there are. I'll try those tomorrow.
<anarsoul>
what would be a proper way to select clock parent in the driver?
<anarsoul>
what about specifying default tcon0 parent in sun50i-a64.dtsi, override it where necessary, reparent tcon0 clock when probing tcon0?
<apritzel>
Not sure that should be in the DT in the first, though, haven't looked at the problem in detail
<anarsoul>
last time I used it, it was frowned upon :)
<anarsoul>
apritzel: I pretty much described the problem. Depending on what TCON0 is used for (RGB output or DSI output), it must be clocked from different clocks. pll-video-2x in the first case, pll-mipi in the second
<anarsoul>
that is determined by trial and error, I cannot find such restrictions in A64 user manual
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Quasar 5.2.6, revision: 5.2.6+git-7606-51f3abb83, build type: debug, sources date: 20160102, built on: 2024-11-13 20:14:24 UTC 5.2.6+git-7606-]
<apritzel>
but the kernel's common clock framework doesn't really expose methods to select certain parent clocks, right? So video drivers couldn't do this even if they wanted to?
<anarsoul>
but anyway, with pll-video-2x and pll-mipi configured to the identical clock I'm getting the picture with pll-video-2x, but not with pll-mipi
<apritzel>
which sounds like an A64 hardware limitation indeed
<anarsoul>
apritzel: clk_set_parent, but you need to get the parent clock somehow (e.g. by specifying it in DT)
<apritzel>
anarsoul: what in the DT actually selects RGB over DSI for the Pinebook? Shouldn't there be a reg property in &tcon0_out_anx6345, setting this apart from &tcon0_out_dsi in the .dtsi?
<apritzel>
or does the TCON blast it out on both, and you select one via the activated pinmuxes?
<apritzel>
that's what I found as well, and which made me think it's the pinmux only. But that would make a driver based solution really dodgy
<anarsoul>
yeah, I'm leaning towards specifying clock parent in DT
<apritzel>
I think this being caused by a hardware limitation and there apparently being no other selector provides good arguments for a DT based solution
<apritzel>
anarsoul: what was the situation before the patch? Was it selecting PLL-VIDEO-2X by default somehow, and this patch changed that to MIPI instead?
<anarsoul>
apritzel: yeah, the patch forces pll-mipi as a parent
<anarsoul>
it was pll-video0-2x by default prior to that
<anarsoul>
now the question is should I submit it as a single patch, since separate patches would introduce issues for bisectability, or separate patches for ccu and DT changes?
<apritzel>
DT and code patches MUST be separate anyway
<apritzel>
is the code just a revert of that force-MIPI patch?
<Soupborsh>
Entering FEL mode after loading boot0 using spl seems to be random and most of the time it does not.
<apritzel>
Soupborsh: OK, let me finish my hack on this. There are only six bytes left at the location I was looking at, but I think I know where to find some more space ...
<apritzel>
Soupborsh: how did you come up with that magic 0x1C20508 write anyway? By reading some code?
<Soupborsh>
Thank you. I found that address in BSP u-boot.
<Soupborsh>
SUNXI_RUN_EFEX_ADDR is the address of FEL flag.
<Soupborsh>
#define SUNXI_RUN_EFEX_FLAG (0x5AA5A55A). The value for boot0 to jump to FEL.
<anarsoul>
apritzel: it is a partial revert. My concern is that if the patches go through a different trees there might be a kernel release that is broken for all the A64 platforms
<anarsoul>
I left CLK_SET_RATE_NO_REPARENT flag, since we do not want to reparent TCON0 clock
<apritzel>
well, looks like the only tcon0 users in the tree are the Teres-I and the Pinebook?
<apritzel>
anarsoul: DT and kernel code are supposed to be independent anyway, they just happen to live in the same tree
<apritzel>
both patches should get Fixes: tags, I think that's the best we can do
<apritzel>
actually from what I can see, Roman's patch broke the only two supported users, so by partly reverting this we would improve the situation already (Pinebook would work again?)
<apritzel>
the DT change is then just the bullet-proof and sustainable solution
<apritzel>
I wonder which one between the driver's code and the DT's assigned-clocks would actually win?
dliviu has quit [Ping timeout: 480 seconds]
<apritzel>
if DT wins, putting the DT patch first should this bisecting issue?
<apritzel>
BroderTuck: I can send you something that drops you into mainline U-Boot on the X96QPro+ later
smaeul has quit [Ping timeout: 480 seconds]
smaeul has joined #linux-sunxi
<BroderTuck>
U-boot would be nice indeed. I have a tinyrootfs that I'm planning to start with, so a kernel that starts just 1 cpu would be a good start. Haven't looked at the arm64 defconfig, but I would like a kernel where these optios are in:
<BroderTuck>
But I'm, still waiting on that microsd card, the one with fel-sdboot in the machine now is in rather bad condition
gsz has quit [Ping timeout: 480 seconds]
colinsane1 has quit []
<apritzel>
BroderTuck: I got v6.13-rc1 plus my A523 patches booted, with USB and microSD working, UART of course as well. eMMC is goatish, though, at the moment, but I will hopefully find the culprit soon enough
colinsane has joined #linux-sunxi
<apritzel>
BroderTuck: do you have some decent distro running on your H3 box? then you should be able to "apt-get" an aarch64 cross compiler, just need quite some patience then ;-)
<BroderTuck>
Depends on if you call Slackware decent :) but no, it does not support apt-get
<apritzel>
hey, nothing against Slackware, using that on my PCs since 2001 or so. Nice to meet the other user :-D
<apritzel>
https://github.com/apritzel/cross supports creating Slackware packages, and for the kernel you just need stage1. Brings your required patience level to that of a Tibetan monk, though
<apritzel>
that's your boot0_reference_pb618 file, hacked to save LR and SP at the beginning, and restore them after the "DRAM simple test OK." message, then branch back to FEL
<apritzel>
after you entered FEL mode via your button trick, try to run it with "sunxi-fel spl"
<apritzel>
argh, wait, didn't correct the checksum, just one sec