ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
juri_ has joined #linux-sunxi
juri__ has joined #linux-sunxi
juri_ has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
apritzel_ has quit [Ping timeout: 480 seconds]
sunshavi_ has quit [Ping timeout: 480 seconds]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
norton has joined #linux-sunxi
apritzel_ has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
warpme has joined #linux-sunxi
mripard has joined #linux-sunxi
warpme has quit []
apritzel has joined #linux-sunxi
<Jookia> ok i've published my SPI NAND u-boot/ubi work! https://github.com/Jookia/u-boot/tree/jookia_t113 . will write SPI NAND sunxi page using this sometime soon.
<Jookia> jkm: ^
<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> Oh no! I'm using the https://mangopi.org/mangopi_mq
<Jookia> The schematics are basically identical so I've been referring to mq-r
<apritzel> ah, a Linux DT patch opportunity for you ;-)
<Jookia> i'll have to re-do some patches
<apritzel> there seems to be a D1 DT for the MangoPi MQ
<Jookia> I would like to share the dt with the mq-r
<Jookia> Not literally share the file
<Jookia> But I might include the mq-r dtsi
<apritzel> why not share the file with the RISC-V MQ?
<apritzel> arch/riscv/boot/dts/allwinner/sun20i-d1s-mangopi-mq.dts
<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
<Jookia> ah
<Jookia> thanks for the advice
<apritzel> Jookia: also there are already patches for T113s SPL SPI: https://lore.kernel.org/u-boot/20231111133432.755363-1-bigunclemax@gmail.com/
<Jookia> oh cool! time to grab those then
<Jookia> finding patches for u-boot is a rather difficult process so i just don't bother if it's small
<Jookia> those patches look similar to the ones i indepedently wrote so i'll just leave mine until those get merged
<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> https://lore.kernel.org/u-boot/20221014030520.3067228-1-uwu@icenowy.me/ doesn't seem to have any comments about it?
<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
<apritzel> or: use UBI as Jookia suggested
wasutton3 has quit []
wasutton3 has joined #linux-sunxi