Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
gsz has joined #linux-sunxi
<Soupborsh>
I added some H3 properties to B288 in soc_info.c and spl now works! I can boot boot0 using spl and it initializes dram and keeps being in FEL mode. Howewer script.bin and boot1.header recieved from FEL is random garbage.
<Soupborsh>
I started porting u-boot based on orangepi_plus which has H3. Is it correct choice or I am doing something wrong? Almost without changes except copying orangepi_plus_defconfig into pb618_defconfig I get this when booting sunxi-spl.bin:```U-Boot SPL 2025.01-rc4-00024-g88bd5701efdc (Dec 13 2024 - 16:58:03 +0500)
<apritzel>
you can even write that on one line with the "spl boot0.bin" part, sunxi-fel executes that in order
<Soupborsh>
apritzel: I edited message multiple times but it instead always resent message, maybe IRC does not support editing, also it sends not full messages.
<kepstin>
I think that was caused by editing a message in matrix; the bridge re-sends it with the edit like that. Matrix users need to be aware they're on an IRC channel so they can avoid doing things that translate poorly to the irc side :/
<apritzel>
I see Matrix causing quite some trouble here, I honestly wonder why people don't either use a multi-protocol messenger or just pick a native IRC client? Or use the OFTC web interface for the occasional messages?
<kepstin>
well, the bridge is basically a way to use a matrix client _as_ a multi-protocol messenger. The problem is that matrix clients are unaware about the limitations of IRC channels, so there's no way to inform users that certain things don't work, or don't work well :/
<Soupborsh>
I am sorry when booting boot0 with spl it outputs "usb_bulk_send() ERROR -9: Pipe error"
<Soupborsh>
So I cannot then write and execute uboot uboot
<apritzel>
Soupborsh: but you said above: "I can boot boot0 using spl and it initializes dram and keeps being in FEL mode"?
<apritzel>
kepstin: I do understand the idea, but apparently it doesn't really work, does it? I mean those hiccups like above are not the only problems, I remember multiple "does it work?" or "I saw my last messages weren't sent" posts in the past
<apritzel>
plus the occasional multi-line messages being redirected to the web, etc.
<kepstin>
issues with missing messages are a problem with the public bridge implementation specifically. some software changes should have improved it a bit in the last years.
<Soupborsh>
apritzel: Yes, I thought it did but was confused.
<kepstin>
the reposts on edits and redirecting long messages to web (instead of spamming the channel) are intentional features.
<kepstin>
(fwiw, I'm also using a matrix client, but via a private irc bridge rather than the big public one)
<apritzel>
well, spamming the channel seems to be a feature of those matrix bridges, see above ;-)
<apritzel>
and yes, IRC netiquette strongly discourages *dumps* into the channel, but how this is mapped by the bridges isn't really helpful either: sometimes it teases parts, and pushes the rest to the web
<apritzel>
but often it seems to redirect normal text as well, instead of splitting this up in multiple lines
<Soupborsh>
<kepstin> "(fwiw, I'm also using a matrix..." <- My "Allline" ISP does not give me public ipv4 and ipv6 is not supported. I have xiaomi-daisy with postmarketos, I want to use it as server but have no public ip.
<Soupborsh>
Maybe I should stop talking offtopic, I will fix my IRC and email sometime.
warpme is now known as Guest2975
warpme has joined #linux-sunxi
<apritzel>
Soupborsh: was partly a genuine question, I didn't know that restrictive ISPs are still a problem today
<Soupborsh>
How do I patch boot0 to make it execute FEL after initializing DRAM?
<apritzel>
Soupborsh: so without isolated DRAM code mainline U-Boot is very hard to load, that's indeed the biggest hurdles we face when using "new" SoCs
<apritzel>
Soupborsh: that's not easy, but basically you find code that executes *after* the DRAM init, and overwrite it with something like "mov r0, #0x20; bx r0"
<apritzel>
and then run this boot0 from SD card
<apritzel>
for pure FEL loading you would need to save SP and LR at the beginning, and then restore this after the DRAM init
<Soupborsh>
Having SD card inserted and not makes no difference.
<apritzel>
so you only have FEL then?
<Soupborsh>
No, after this I have usb_bulk_recv() ERROR -9: Pipe error
<Soupborsh>
as well as "usb_bulk_recv() ERROR -8: Overflow" and "usb_bulk_recv() ERROR -7: Operation timed out"
<apritzel>
I meant to boot anything custom at all: you enter FEL via some buttons, IIRC? And this works, but when trying to run boot0 via the spl command it does not return?
<apritzel>
if you put your boot0 binary somewhere, I might have a go at patching it to return to FEL (but only later tonight)
<Soupborsh>
apritzel: Sorry for confusion, I enter FEL ny holding central home button and pressing power button.
<Soupborsh>
Thank you apritzel. You do not have to patch it, patch it only if you want.
<apritzel>
you could try to set CONFIG_DRAM_ZQ=3881977 in your mainline SPL U-Boot, but I doubt it will change anything
<apritzel>
the B288 SoC is similar to the H3, but typically the DRAM controllers differ a bit here and there, so won't work out of the box
<Soupborsh>
I did add CONFIG_DRAM_ZQ to pb618_defconfig.
<apritzel>
Soupborsh: do you have a device with the B300, by any chance? Or know someone who has? We would be curious about the SoCID reported by sunxi-fel, to confirm it's the same chip as the A50
<Soupborsh>
apritzel: Sorry, no.
balguito has joined #linux-sunxi
balguito has quit []
geosback has quit []
Guest2975 has quit []
JohnDoe_71Rus has joined #linux-sunxi
ftg has joined #linux-sunxi
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
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
geosback has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
<enthdegree>
I just ordered a Pocketbook Era BW, for kernel dev, apritzel's messages have me thinking about sending it back for an Era Color
<enthdegree>
Well, maybe I've misinterpreted what he's saying
warpme has joined #linux-sunxi
warpme has quit []
<enthdegree>
ah nevermind the pinenote is on sale
<enthdegree>
im just getting that, i give up
apritzel has joined #linux-sunxi
<apritzel>
enthdegree: what are you after by saying "kernel dev", exactly? Creating mainline kernel support for that SoC?
<apritzel>
or running something usable on that device?
<enthdegree>
creating mainline kernel support. i falsely assumed the difficulty would be contained to specific platform subdevices like the screen
<apritzel>
enthdegree: yes, creating mainline support for a new SoC is quite some task, especially without a manual
<apritzel>
you need some patience and endurance, and some help ;-) but it seems like it's already two of you ...
<apritzel>
and if you hope for anything on the display soon, I have to disappoint you: the first steps are: clocks, pinctrl, RTC
<apritzel>
I wouldn't be aware of any prior art for mainlining Allwinner eink support, so that's completely uncharted territory
<enthdegree>
it is unclear how close even the published far-from-mainline source is to functioning on known devices
warpme has joined #linux-sunxi
<hlauer>
Just mailed patch v2 for the PH23 removal in m2ultra dts after testing it with 6.13rc2. Btw. noticed that V1.1 has an additional red led, which is lit with BSP kernel, but not with vanilla
<apritzel>
hlauer: lit by the kernel, or by U-Boot earlier? Or even always-on? Or could you identify a GPIO for that LED, at least?
Hypfer has joined #linux-sunxi
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-]
bauen1_ has joined #linux-sunxi
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
bauen1 has quit [Ping timeout: 480 seconds]
<hlauer>
lit by the kernel, in early init before the console messages are spit out
smaeul has quit [Quit: Down for maintenance...]
smaeul has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
tokyovigilante_ has joined #linux-sunxi
tokyovigilante has quit [Ping timeout: 480 seconds]