<pnill>
"<apritzel> at the end of the day it remains a hack: if you want a game console, buy one
<pnill>
<apritzel> or use any other, well supported SBC and some gaming distro" well exactly it's fun unlocking hardware to do more especially closed hardware haha.
<pnill>
I didn't think it'd be a walk in the park was just curious if there was another option and I'm perfectly fine with booting a totally different OS over USB
<pnill>
which I think would be possible over U-Boot
lkcl has joined #linux-sunxi
rzerres has quit [Ping timeout: 260 seconds]
rzerres has joined #linux-sunxi
<smaeul>
yes, U-Boot can boot from USB. U-Boot itself still has to be on the NAND, and that is supported for mainline, I believe
Mangy_Dog has quit [Ping timeout: 246 seconds]
victhor has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
libv has quit [Ping timeout: 245 seconds]
libv has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
buzzmarshall has quit [Remote host closed the connection]
gediz0x539 has joined #linux-sunxi
faruk has joined #linux-sunxi
hlauer has joined #linux-sunxi
shailangsa has quit [Ping timeout: 265 seconds]
asdf28 has joined #linux-sunxi
apritzel has joined #linux-sunxi
cmeerw has joined #linux-sunxi
apritzel has quit [Ping timeout: 240 seconds]
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-sunxi
cmeerw has quit [Ping timeout: 245 seconds]
Shailangsa_ has joined #linux-sunxi
Shailangsa_ has quit [Ping timeout: 252 seconds]
shailangsa has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
chewitt has quit [Quit: Adios!]
reinforce has joined #linux-sunxi
tnovotny has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme_ has joined #linux-sunxi
<hlauer>
apritzel: Thanks for updating the R40 wiki. btw: banana M2 Ultra SATA works fine
<apritzel>
hlauer: Was there ever a doubt or problem over the M2U's SATA?
<hlauer>
Not seen anything here, it's solid since I bought the device and put mainline on it :-)
simosx has joined #linux-sunxi
simosx has quit [Quit: Yakkety Bye!]
prefixcactus has joined #linux-sunxi
<apritzel>
mripard: wens: so do I get this correctly that this new timing mode in the later MMC controllers requires the mod clock to be programmed *4* times higher than it actually should be?
<apritzel>
at least for the eMMC HighSpeed DDR mode (50 MHz)?
<wens>
no idea
<apritzel>
I see clk_summary saying 100 MHz, but the divider in the mod clock is 6, so it's actually 200 MHz (the PLL running at 1200)?
<apritzel>
trying to sort out the U-Boot situation, where we apparently miss some of those "quirks"
<mripard>
the parent should be the pll-periph (pll6?) that runs at 600MHz?
<apritzel>
on the H6 the parent is PLL-Periph0(2x), so 1200 MHz
<apritzel>
pll-periph0-2x 1 1 0 1200000000 0 0 50000 Y
<apritzel>
mmc2 0 0 0 100000000 0 0 50000 N
<mripard>
ah right
<mripard>
if I remember well (and it's a bit fuzzy honestly)
<mripard>
the new mode requires that we double the clock
<mripard>
and DDR does too
<mripard>
so for HS DDR we end up with x4
<apritzel>
right, makes sense
<apritzel>
is the DDR doubling a general MMC thing, or another Allwinner speciality?
<mripard>
something specific to the controller
<apritzel>
I see, many thanks, that clears it up!
<mripard>
with DDR you sample on rising and falling edges, but the clock rate stays the same
<apritzel>
yeah, that's why I would expect the actual SDC_CLK line really running at 50 MHz
<mripard>
I guess it depends on how the device is designed :)
<mripard>
the FIFOs and internal logic would need to run at twice the speed
<apritzel>
indeed, I guess the controller has twice the work to do, so it needs more speed
<wens>
IIRC there's an internal divider for SDC_CLK
<apritzel>
Allwinner must have got some "remaining stock" on the A73 ;-) really? in 2022? But then again they still use A7s all over the place ...
<apritzel>
But I guess they realised that A76 does AArch32 only in EL0, so they would have to rewrite the BROM (and port U-Boot)
Mangy_Dog has joined #linux-sunxi
Mangy_Dog has quit [Changing host]
Mangy_Dog has joined #linux-sunxi
victhor has joined #linux-sunxi
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-sunxi
vbmithr_ has quit [Ping timeout: 248 seconds]
vbmithr has joined #linux-sunxi
elros1 has joined #linux-sunxi
<maz>
apritzel: the answer is obvious: broken timers are a feature for AW. So picking A73 is an obvious choice, as they don't even have to fsck-up the integration!
victhor has quit [Remote host closed the connection]
<apritzel>
maz: right, good point, keep compatibility to the A64 ;-)
Net147 has quit [Quit: Quit]
Irenes has quit [Ping timeout: 245 seconds]
DrFrankensteinUK has quit [Ping timeout: 240 seconds]
camus has joined #linux-sunxi
DrFrankensteinUK has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
Irenes has joined #linux-sunxi
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 252 seconds]
specing_ is now known as specing
Net147 has joined #linux-sunxi
Net147 has quit [Client Quit]
Net147 has joined #linux-sunxi
Net147 has quit [Remote host closed the connection]
Net147 has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
chewitt has joined #linux-sunxi
elros1 has quit [Read error: Connection reset by peer]
elros1 has joined #linux-sunxi
elros1 has quit [Read error: Connection reset by peer]
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
faruk has quit [Quit: Leaving]
tnovotny has quit [Quit: Leaving]
buzzmarshall has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
elros1 has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
JohnDoe_71Rus has joined #linux-sunxi
cmeerw has joined #linux-sunxi
<jernej>
apritzel: if it gets job done, why not
<jernej>
I think that many times peripherals are just as important as core, ocassionally even more
<apritzel>
jernej: yeah, I was just disappointed - and was hoping for at least an A75 or A76
<apritzel>
I know
<jernej>
(I'm working with 8-bit soft-core MCUs last few years, which are better suited for the job than off the shelf 32-bit MCUs)
<apritzel>
yeah, many times you just need some kind of better DMA controller
popolon has joined #linux-sunxi
elros1 has quit [Remote host closed the connection]
<apritzel>
bauen1: smaeul: there was this "felreset" trick for the H6, where we write the magic plus address into RTC_BASE + 0x1b8/0x1bc, then do a watchdog reset
<apritzel>
but the H616 seems to use different addresses, do you know which?
<apritzel>
we use R_CPUCFG_BASE + 0x1c0 in the SPL, but that does not work this way
<apritzel>
I guess this location do not survive the watchdog reset? (For the H6 it's in the RTC registers)
<apritzel>
and writes to the H6 addresses (0x70001b8) do not stick on the H616
rzerres has quit [Ping timeout: 252 seconds]
<apritzel>
bauen1: smaeul: and this super standby is different right, both in terms of the key and trigger mechanism and also that it requires an eGON image in memory?
jstein has joined #linux-sunxi
clementp[m] has quit [Quit: Idle for 30+ days]
rzerres has joined #linux-sunxi
rzerres has quit [Ping timeout: 260 seconds]
kevans91_ is now known as kevans91
<bauen1>
apritzel: i don't have a h616 and haven't taken a look at its brom yet
<bauen1>
but iirc the super standby detection is in very very early boot, so the magic values / addresses should be easy to find out
<bauen1>
it's actually been quite a while since i last touched my h6 :/
choozy has joined #linux-sunxi
elros1 has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 252 seconds]
camus is now known as kaspter
prefixcactus has quit [Ping timeout: 268 seconds]
kaspter has quit [Ping timeout: 265 seconds]
kaspter has joined #linux-sunxi
elros1 has quit [Remote host closed the connection]
elros1 has joined #linux-sunxi
lukedashjr has joined #linux-sunxi
luke-jr has quit [Ping timeout: 260 seconds]
lukedashjr is now known as luke-jr
jernej is now known as jerSTART_CODEnej
jerSTART_CODEnej is now known as jernej
jstefanop has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
sunshavi has quit [Remote host closed the connection]
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
gaston1980 has quit [Ping timeout: 246 seconds]
apritzel has joined #linux-sunxi
elros1 has quit [Remote host closed the connection]
<apritzel>
bauen1: so the first thing the H616 BROM checks, is bit 15 at 0x070001a0, but it just writes something different back, depending on the result
<apritzel>
then it checks the MPIDR to sort out the secondaries
tuxillo has quit [Ping timeout: 252 seconds]
thefloweringash has quit [Ping timeout: 245 seconds]
<apritzel>
and then cores 0 checks the first standby register at 0x70005c0 for the magic, if that matches, it branches to the address in 0x70005c4
<apritzel>
which is the mechanism we use for the SPL FEL return
<apritzel>
so this is very early, but does not survive a watchdog reset
<apritzel>
(I guess because it's in R_CPUCFG, and not in the RTC)
thefloweringash has joined #linux-sunxi
<apritzel>
I keep looking, but this BROM code makes me cringe everytime I read it
<apritzel>
any chance you could send that to the list?
<apritzel>
or at least provide a summary of what you fixed in there?
<megi>
I tried once, but setting up CI for u-boot was too much of a bother
<apritzel>
why would you need that?
<megi>
I was told to do that
<apritzel>
really? interesting ...
<megi>
to verify it compiles on I don't know with how many configs
<apritzel>
that's solved
<megi>
it was loong time ago, though, so maybe things changed
<apritzel>
it just grab one of my servers, do: "tools/buildman/buildman sunxi"
<apritzel>
and a few minutes later it returns a summary of all 156 sunxi boards
<apritzel>
and I believe Tom Rini does this as well before actually merging stuff into master
<apritzel>
anyway, I believe in good ol' review being more valuable than those sophisticated CI systems ...
<apritzel>
mmh, DMA for MMC, what does that give you?
<apritzel>
do you care so much about the speed increagse?
<megi>
with DDR eMMC, it gives 80MiB/s load speeds
<megi>
kernel loaded in 100ms :) and booting
<megi>
at that point U-Boot has other code that wastes much more time
<megi>
but the same mmc code in p-boot just gives 150ms boot times
<megi>
from eMMC
<megi>
it's still the longest part of the bootloader process
<apritzel>
megi: I can believe that it's faster, but do you have the number for the PIO transfers (at the same fixed MMC clock speed)?
<megi>
for regular SD card speeds, it's not that interesting
<megi>
maybe 5% rise in speed
netlynx has quit [Quit: Ex-Chat]
<megi>
also it's async, you start it and you can do other stuff for those 100ms on your boot CPU, so that's other reason I implemented it
<apritzel>
so you hit an MMIO penalty wall if you do faster (e)MMC modes?
<megi>
I don't think I tested with eMMC
<megi>
because I implemented DDR support after having DMA already working
<megi>
s/tested/comapred DMA vs PIO/
shailangsa has quit [Ping timeout: 268 seconds]
<megi>
I guess I can send some of the patches, but I don't update U-Boot anymore, so I'd have to first rebase over several releases and then re-test... so it's probably not going to be anytime soon
<apritzel>
well, I will have a look and might pick some fixes
<megi>
great :)
<apritzel>
and that's the advantage of being mainline: you don't need to rebase ;-)
<megi>
yeah, some of that was already fixed independently. the useless mdelay(500) was too
<apritzel>
med
<apritzel>
megi: you don't have any H6 U-Boot HDMI patches, by any chance?
<megi>
no
dev1990 has quit [Quit: Konversation terminated!]
dev1990 has joined #linux-sunxi
<apritzel>
megi: actually I was wondering the other day how much useful the code sharing between SPL and U-Boot proper really is
<apritzel>
I mean these days, with DM driver in proper, and non-DM hacks on top, for the SPL
<apritzel>
for instance sunxi_mmc.c is somewhat of a mess because of this, and we can't do much about it
<apritzel>
but I think that's actually one of the few places where we actually share code between SPL and U-Boot proper
<apritzel>
and we have somewhat clean interface between the SPL and proper (via FIT or the legacy image)
shailangsa has joined #linux-sunxi
cmeerw has quit [Ping timeout: 250 seconds]
<megi>
I don't have any ideas about that
warpme_ has quit [Quit: Connection closed for inactivity]
<apritzel>
I mean we could have a more lean SPL replacement, just being able to load U-Boot proper (or a kernel directly)
<megi>
oh, right, it would only have to understand mmc and dram init, and bunch other smaller things :)
<apritzel>
we would just need basic clock setup, DRAM init, MMC read and SPI flash support, and could then possibly afford a FAT read driver
<apritzel>
ah, yes
<apritzel>
we already have this for the SPI flash
<apritzel>
where the drivers for SPL and proper are actually separate
<megi>
mmc one is kinda big though
<apritzel>
but I agree that for the SPL purpose we go through quite some unnecessary U-Boot churn
<megi>
so sharing that is useful
<apritzel>
well, somewhat
<apritzel>
for instance we need only raw reads
<apritzel>
as I said, this is indeed probably the only place where we really share code
<apritzel>
so that would be a sacrifice to make
<apritzel>
but maybe it's worth it, if we can get FAT support, for instance
<apritzel>
but I don't know, just some thoughts ....
<megi>
well, having a simple sunxi mmc specific code for raw reads would be nice (instead of generic mmc.c/sunxi_mmc.c split that contains quite a bit of abstraction), I though about making one for p-boot, just to save space and to have more control
<megi>
but it seems like a largish amount of work :)
<megi>
and p-boot is basically just a SPL
<megi>
so I guess whoever gets to that project first will be able to share the other's code ;)
<megi>
it would also probably allow some fun stuff in U-Boot spl too, if it implemented DMA... like starting the transfer and do some other stuff not waiting for it to finish
<megi>
sunxi mmc can basically DMA the whole kernel at once if it's stored in a single consecutive amount of blocks on the card
<megi>
in a single transaction :)
<apritzel>
well, the whole design idea of U-Boot is to be single threaded and linear, so no multi tasking, not even interrupt driven DMA in the background
<megi>
no need for interrupts
<apritzel>
so not sure what U-Boot would do meanwhile
<megi>
just start DMA do something else, and once you have that done, poll for end of DMA
<apritzel>
I understand, but what would this "else" be?
tuxillo has joined #linux-sunxi
<megi>
not sure what in U-Boot, but p-boot has display support and loads 4MiB image backgrounds for menu items, etc. so being able to do that asynchronously would be good
<apritzel>
I see, I was wondering about U-Boot in particular
<megi>
currently the u-boots mmc code doesn't allow that
<apritzel>
so in p-boot you pull in the MMC code from U-Boot?
<apritzel>
and this is part of the blob loaded by the BROM?
<megi>
you can still do some HW init that takes some time, or whatever in the meantime, but for SPL that aims to only do minimum necessary, I don't know
<megi>
yes
matthias_bgg has quit [Ping timeout: 268 seconds]
<megi>
p-boot has copy of mmc code from u-boot + my perf patches
<apritzel>
so how big is your eGON image then?
<megi>
it's ~32kib
<apritzel>
IIUC you search for a special boot partition, and load the rest from there?
<megi>
yes
<megi>
with display support disabled it's around 25KiB
<megi>
so without display support there would be enough for FAT support
<megi>
enough space
<apritzel>
ah, I was just wondering what makes up the space you save ...
<apritzel>
DE2 & LCD?
<megi>
DE2,LCD,DSI driver,DPHY,panel driver,menu GUI,bunch of other things
<megi>
fonts
<apritzel>
do you actually need that in the SPL? Is that already interactive?
<megi>
yes
<apritzel>
have you tried compiling this as Arm32 Thumb2?
<megi>
I was thinking about it :)
<apritzel>
the 32-bit "mainline" SPL shrunk from 32KiB to ~20KiB
<apritzel>
so there is quite something to gain
<apritzel>
(I was once playing around with ILP32, was this wasn't worth the hassle, there was not much saving)
<megi>
yeah, I expect it to be :)
<megi>
there's no way forward without that, because 32kib are already used up, so that's the next thing to do
<apritzel>
megi: do you have an idea of how much HDMI would add?
<megi>
depending on how it's done
<megi>
p-boot uses some tricks to achieve small size of display init code