<apritzel>
Jookia: what is: "the board I am using"? Is that a MangoPi MQ-R board where you connected a different UART or is it in fact some other T113s board that just happens to be close?
<Jookia>
mangopi mq-r with a different UART
<Jookia>
default uart is unpopulated i think
warpme has joined #linux-sunxi
<Jookia>
i went with the model of SPI NAND being its own boot device instead of regular NAND
<Jookia>
Ideally I'll work on pushing all these upstream, but that's a next year job :)
<apritzel>
the UART seems to be a major pain on this board. We had a discussion before, I was using UART1, but got convinced that UART3 is better, mostly because it's explicitly named as the console UART in the schematic
<Jookia>
UART1 is probably the best default I think as it has R/T labeled on the board
<Jookia>
and populated by default
<apritzel>
nothing is populated out of the box?
<Jookia>
UART1 and UART3 are on the populated pin headers
<apritzel>
at least my board came naked, with the two headers separately
<Jookia>
Huh.
<Jookia>
The boards I bought came with the two headers populated
<Jookia>
I would have to turn that in to a dtsi wouldn't I? and arch/arm/boot/dts/allwinner/sunxi-d1s-t113-mangopi-mq-r.dtsi is already a dtsi that has everything
<Jookia>
ideally ./arch/arm/boot/dts/allwinner/sunxi-d1s-t113-mangopi-mq-r.dtsi and arch/riscv/boot/dts/allwinner/sun20i-d1s-mangopi-mq.dts would be merged
<apritzel>
that would be subject to a quick discussion on the list, we had two different approaches for the MQ-R already
<apritzel>
and you can include .dts files as well
apritzel has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
<apritzel>
though in this case this won't work, I guess, since the MQ .dts already includes the D1 .dtsi
<apritzel>
so this would need to be split: one arch agnostic MQ .dtsi, and then two .dts files, one for ARM, one for RISC-V
<Jookia>
where would the MQ-R fit in to that? just be a board that includes the MQ dtsi with its own compatible?
<apritzel>
well, if the MQ and MQ-R are really that close, then one .dtsi should carry the bulk of the DT nodes, and then the four variants (MQ-D1s, MQ-T113s, MQ-R-D1s, MQ-R-T113s) include that
<Jookia>
the mq and mq-r are identical down to copy pasted schematics, though i think they did add some pull-up resistors on spi0
<Jookia>
i'll try reworking this in my u-boot tree and see how it goes
<Jookia>
thanks for the feedback :) gotta sleep!
warpme has quit []
warpme has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
dsimic is now known as Guest9630
dsimic has joined #linux-sunxi
Guest9630 has quit [Ping timeout: 480 seconds]
apritzel has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
evgeny_boger1 has quit []
JohnDoe_71Rus has quit []
vpeter has quit [Remote host closed the connection]
vpeter has joined #linux-sunxi
Daanct12 has quit [Quit: WeeChat 4.1.2]
JohnDoe_71Rus has joined #linux-sunxi
kuba2k2 has quit [Ping timeout: 480 seconds]
warpme has quit []
mripard has quit [Remote host closed the connection]
kuba2k2 has joined #linux-sunxi
warpme has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
kuba2k2 has quit [Ping timeout: 480 seconds]
kuba2k2 has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
norton has quit [Quit: WeeChat 4.1.1]
JohnDoe_71Rus has quit []
digetx has quit [Ping timeout: 480 seconds]
kuba2k2 has quit [Ping timeout: 480 seconds]
kuba2k2 has joined #linux-sunxi
<Jookia>
are device tree sources stable APIs? or can i rename labels as i want?
jkm has quit [Quit: leaving]
digetx has joined #linux-sunxi
apritzel has joined #linux-sunxi
ftg has joined #linux-sunxi
<apritzel>
Jookia: *labels* are typically not a problem, because they only exist in the .dts, but not the .dtb (ignoring overlays)
<apritzel>
but whatever you do: it needs to work with older and newer kernels (or DT consumers, really)
<apritzel>
and needs to pass through the Linux review process
<Jookia>
i might be thinking of phandles! i'll have a better idea later today when i look through all this and take some notes
<apritzel>
yes, phandles are roughly what labels turn to, when compiling from .dts to .dtb
<apritzel>
so you see phandles in a decompiled .dtb, but never write them into a .dts
<Jookia>
i may have to avoid unifying mq/mqr device trees then as they have different regular handle names
<apritzel>
well, the phandles only need to be consistent within a particular .dtb file, and the DT compiler takes care of that
<apritzel>
so as long as you change label names and their references in all .dts files in one patch, that's typically fine
<apritzel>
Jookia: so did I get this right that the BROM tries multiple offsets when loading the SPL/boot0 from SPI NAND? I guess this is to cater for worn out blocks?
<Jookia>
yes
<apritzel>
and the number of the successful one ends up in the boot source indicator in SRAM?
<apritzel>
in the high nibble of it, I mean
<Jookia>
Yep, from what I can see
<apritzel>
do you know how far apart these offsets are?
<Jookia>
it's listed in the wiki somewhere
<Jookia>
'the BROM tries to read a valid first stage bootloader starting from page number 0, 32, 64, 96, 128, 160, 192 and 224'
<apritzel>
ah, thanks
<Jookia>
I'm pretty disheartened at having wasted work on my own patches when someone else has done that. I'll probably replace my patches with theirs and send a tested-by. I guess one less thing of mine to get stuck in the patch queue
<apritzel>
that's a common problem, and not easy to avoid. But announcing your work early, and be it with RFC patches on the list, is typically a good way. Or ask here in the channel
<apritzel>
Jookia: if you have patches of your own, you could compare them, and since you know about this, could then even provide a Reviewed-by:
<Jookia>
That's true
<Jookia>
I'm not too upset by it, I have no idea how much I will bother mainlining anyway
<Jookia>
It's more just the wasted effort :)
<Jookia>
Part of the reason I'm trying to use u-boot is so I can port over my Linux patches for an LCD display and display an LCD on boot
<Jookia>
But I've given up mainlining that patch series so this will live out of tree :\
<apritzel>
that's a shame!
<Jookia>
It also holds up my theoretical patch for a second LCD because they share vendor prefixes
<Jookia>
So I'm reaaally not sure if I should put effort in now to try and fix this mango pi mq device tree situation
<Jookia>
It's kind of the same with reviewing/putting work in to other people's patches
<apritzel>
what do you mean?
<apritzel>
if no one cares to post or review, there will be no progress, patches will rot somewhere and people will do double work
<apritzel>
and the key power of Open Source is really the peer review, before that it's just someone's random patches
<Jookia>
I get that, but there's no real path to getting things merged, even if it is reviewed
<apritzel>
why do you say that? did you try?
<Jookia>
Yeah, this LCD patch has like 4 revisions and all the patches are reviewed with the device tree stuff acked. No sign of merging. Somewhat the same with SUNIV SPL patch
<Jookia>
It seems common to just have patches fizzle out
<apritzel>
and you asked about this one the list?
<apritzel>
on* the list
<apritzel>
patches fizzle out if not enough people care to push on them
<Jookia>
I didn't ask about the SUNIV SPL patch, I've heard from you that it's not done how you'd like it but I don't think that's written on the list
<Jookia>
I think mainlining requires a more aggressive personality than I have
<apritzel>
I think persistence is important
<Jookia>
I think the T113 PWM patch is also out of date now
<Jookia>
(not my patch but I tested it)
<apritzel>
and there were open comments about the suniv SPL SPI patches, and they would need at least a rebase anyway
<apritzel>
anyone is welcome to pick this up, and push on the patches, and be it with announcing interest in them, and annoying maintainers
<Jookia>
How do you find comments for patch series if they're not in the patch thread itself?
<apritzel>
you don't, they need to be in the thread. lore.kernel.org is good for finding series and chasing the thread
<Jookia>
Didn't you have some reservations about how the patch is done?
<apritzel>
but again: announcing interest on the list about this and asking for the status, or offering a rebase/repost/test would be helpful
<apritzel>
yeah, I didn't particularly like it, but am not sure there is a better way
<apritzel>
also there is the question of priorities:
<Jookia>
Hmm
<apritzel>
in the past months there was quite some pressure and support for T113s and H618, so this is what gets done
<Jookia>
Can you post RFCs with other people's patches in them?
<Jookia>
Or maybe I should just announce the branch
<apritzel>
yes, it's absolutely fine to take over other people's series - it's customary to ask them first, though
<Jookia>
I would like to group up the SUNIV patches, the patches posted here today, and then on top of that add the BOOT_DEVICE_SPINAND changes I've done as an RFC.
<apritzel>
it happens often that people lose interest and simple don't have time or motivation anymore
<apritzel>
Jookia: yes, please do that
<Jookia>
I think I'm willing to argue that BOOT_DEVICE_SPINAND is the correct solution for handling SPI NAND because the NAND subsystem is for the most part really intertwined with parallel NAND
<apritzel>
I had some smaller comments while briefly skimming over your patches this morning, answering them on the list would be best
<apritzel>
but the more pressing question is to agree on the SPI NAND booting approach in general:
<apritzel>
MoeIcenowy's approach seems to be a straight forward "read from the first sectors and hope for the best", IIUC
<apritzel>
where a single early block wearout would break the boot
<Jookia>
For my approach I've chosen to use UBI as the second stage
<Jookia>
With multiple SPI NAND first stages
<apritzel>
yes, that seems smarter
<Jookia>
I know you can get the offset for SPI NAND but the size of u-boot just encouraged bad blocks
<apritzel>
though it needs to be discussed whether the whole UBI layer is really necessary, or whether we can just get away with a simpler method just for loading U-Boot proper
<Jookia>
yeah
<apritzel>
where for instance the offset to U-Boot proper is encoded in the SPL header, and written at flashing time
<Jookia>
The problem with that is that if there's a bad block in U-Boot you would have to just look for other U-Boots and hope they're in the right places
<Jookia>
I'll stop discussing this now and maybe write an email on monday opening this discussion
<Jookia>
Thank you for the encouragement!
<apritzel>
that's what I mean: the flashing process tries writing, verifies the success, then encodes the successful U-Boot proper context in the SPL header
<apritzel>
s/context/offset/
kuba2k2 has quit []
<apritzel>
Jookia: please also note that there is some replies to patch 0/8, where Sam argues about something, including bad blocks
<Jookia>
Yeah I read that. Thanks
<Jookia>
Oh also, has anyone figured out why USB gadget is very slow on the T113?
<apritzel>
very slow compared to what? There is no DMA support for OTG on sunxi in general, which limits the performance and increases CPU load, on basically all Allwinner boards
<Jookia>
I think it maxes out at 70KiB/s
<Jookia>
Maybe that's normal speeds for DFU?
<apritzel>
in U-Boot?
<Jookia>
Yes
<Jookia>
I don't have another sunxi board at the moment to compare
<Jookia>
I know that in Linux USB OTG is much faster
<Jookia>
I use it with SSH to copy over rootfs images in seconds
<apritzel>
I don't really use OTG in U-Boot much, beyond testing, and then it's mostly Ethernet and mass storage
<Jookia>
Something to post to the mailing list too then
<Jookia>
Ok, time to sleep. Thanks for this talk.
<apritzel>
yw, happy to continue later
<apritzel>
and thanks for your work!
<MoeIcenowy>
apritzel: I must admit my approach is naive
<apritzel>
well, I didn't think about it as well, until realising that SPI NAND chips apparently don't do wear levelling (although they do ECC correction, and are not prone to things like read disturbance?)
<apritzel>
which is probably true for SPI NOR as well, but less of a problem there with much higher erase cycles
<apritzel>
MoeIcenowy: I think a first step could be to just read the successful SPL offset from the high nibble of the boot source indicator, and then add this to find U-Boot proper
<apritzel>
or: have a SPL header field, initalised to 0xff, then overwrite this with the U-Boot proper offset, *after* a verification step in the flashing process