ftg has quit [Read error: Connection reset by peer]
<Jookia>
i'll test the musb stuff this week with no DM- if it's more stable i'll use that and stop bothering about it :)
<Jookia>
i promised myself i'd only work on one sunxi patch at a time, so i have the tcon patch to do
<apritzel>
fair enough, though dropping the DM-MUSB efforts would be a shame, really. no-DM has to go anyway, and I feel like it's not too hard to get DM-MUSB fully going, just one or two little fixes *somewhere*
<apritzel>
but take your time and your priorities
<Jookia>
i still have no idea what i'll do about all my u-boot patches that i abandoned. any suggestions?
<Jookia>
i was thinking that using DM in SPL would make SPI NAND booting easier :)
<Jookia>
and probably have a better chance of being merged
<apritzel>
I disagree, before we go down the DM_SPL rabbit hole I would like to see a proper killer feature
<apritzel>
SPI NAND support was already posted some time ago, I think, I just didn't have any chance of testing it, and think had some questions on it
<apritzel>
as mentioned, we would need to support both DM_SPL and non-DM_SPL, for legacy reasons, which sounds troublesome
<apritzel>
and I like the idea of considering the SPL the continuation of the BootROM, which works without any board specific knowledge (so no DT needed)
<apritzel>
Jookia: if you have something clean and generic that you want to have merged, please rebase it and send a new version
<Jookia>
i haven't changed anything in most patches i've sent off, they're mostly waiting for feedback in the mailing list
<Jookia>
though maybe abandoning them has abandoned interest in them too
<Jookia>
i think it's more about what maintainers have interest in and what i can sell to them
<Jookia>
my first priority for u-boot mainlining is spi nand booting at the moment which is kind of in purgatory
<Jookia>
i'd really appreciate if you looked at the series
<veremitz>
o,O sounds useful to me ..
<apritzel>
but this was post when? more than a year ago? I doubt it applies cleanly anymore? So rebasing and re-sending would be the best, and be it to show that you need it
<veremitz>
I still have an olinuxino A13? board on the floor here I was gonna tinker with getting the onboard memory to hold uboot at least .. maybe a kernel, I can't remember the config
<apritzel>
veremitz: please note that SPI NAND is something different from "raw NAND flash" as used on many old boards
<Jookia>
apritzel: i guess i genuinely don't understand just what needs to be done to get feedback or have things merged, so i'm really reluctant to re-spin the series when it's already the 6th iteration for half of it
<veremitz>
apritzel: yes I was thinking that..
<Jookia>
there were some comments on it asking to change a few things but they didn't get back to me after that :\
<veremitz>
a lot of these kinda parts of FOSS do benefit from some prodding/poking ..
<apritzel>
Jookia: please put a link in here, but I won't be able to look at it the next two or three weeks, I guess (too much context switching atm, and also on the road)
<Jookia>
the series is from april, so 7 months ago. it won't apply cleanly to mainline
hipboi has joined #linux-sunxi
<apritzel>
to everyone with A523/T527 hardware: I put the first version of patches out: check out the three series here: https://lore.kernel.org/linux-sunxi/
<Jookia>
i'd be interested in knowing what type of patches you have time for so i can focus on mainlining things you're interested in
<apritzel>
DM-MUSB would be one of them ;-)
<apritzel>
I remember SPI-NAND being somewhat nasty, so I need to take some extra time to look at this
<apritzel>
I think one of my newer boards has SPI NAND, so might be able to test this as well
<Jookia>
unfortunately that doesn't really overlap with anything i want mainlined :(
<veremitz>
doh
<Jookia>
it really feels like there's no path for me getting my patches in to u-boot, which is disappointing but it means i can adjust my expectations
<veremitz>
I sense there's just some refactoring to make it 'fit' uboot
<Jookia>
i think it's more just priorities, there are other things to work on instead
<veremitz>
often that happens
<Jookia>
having these priorities made a bit clearer would be helpful
<apritzel>
Jookia: ??? I thought DM-MUSB is something you were after
<apritzel>
Jookia: also: find someone who is interested as well, as get them to help you
<Jookia>
nobody else is interested in what i'm working on
montjoie_ has joined #linux-sunxi
<Jookia>
i'm not sure how they could help get things merged though unless they're maintainers?
<MasterR3C0RD>
Having someone review your code and test it is a good step I'd think, at least based on other projects (though note I'm still green to contributing to the kernel/U-Boot)
<apritzel>
Jookia: with proper review, for instance
montjoie has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
That's where having some people interested helps. I.e., I think that's why I've had what I consider to be a relatively smooth road getting the second-stage support for A100 mainlined
<Jookia>
well if you see anyone intersted please direct them to my fork i guess :(
<Jookia>
i think i misunderstood the process a lot
<MasterR3C0RD>
Yeah, it took me a bit of studying, and I was pretty stressed out about submitting my code to the mailing list. I still made mistakes (forgot suppress-cc and sent a patch to people when I intended to just send to self, kept an Acked-by I shouldn't have, didn't realize I should have kept version numbers in another submission I made, etc)
<Jookia>
i just wish people weren't so hostile to forks and tell me i should upstream my code when i can't
<Jookia>
apritzel: as far as i can tell DM-MUSB works in my fork so most the talk has been about how to get it mainline, but it's not too pressing of an issue for me compared to all the things that makes my fork incompatible with mainline
<Jookia>
some patches are never going to get mainlined such as UART1 and UART2 in SPL so there's always going to be a fork to some extent
apritzel has quit [Ping timeout: 480 seconds]
<Jookia>
I've sent patches to Linux and got those merged despite being the only user so I don't really understand why that's different here
<Jookia>
there was also a lot more interest in my video patches earlier this year that has now disappeared :\
<Jookia>
so i need to send patches, then find people interested in reviewing them, then have them review them, then poke the maintainer, then ... i don't know?
colinsane has quit []
<MasterR3C0RD>
Jookla: Then I think it's just waiting. I think poking might not be appreciated by some maintainers; I think the preferred option is to resubmit if you don't hear anything after a while
<MasterR3C0RD>
*Jookia
<MasterR3C0RD>
It may be easier if you're able to find someone willing to review before submitting, though that's simply conjecture
colinsane has joined #linux-sunxi
<Jookia>
it seems to me there's no clear instructions on what i'm supposed to do here or what i should expect and a lot of the process is based around social cues and understandings i don't have
<Jookia>
right now it seems i'm the only person who wants SPI NAND and LCD support for the T113 in mainline, and that's not enough
<Jookia>
the contributing docs don't explain what i need to get something merged :\
<MasterR3C0RD>
Maybe it'd help to look at examples of patches that did make it in; look for small differences between how they formatted their patches/wrote their cover letter/etc
<MasterR3C0RD>
And your patches that you're hoping to get in
<Jookia>
i have, i don't see anything different
<Jookia>
i get the impression i'm the problem here because nobody else is having these issuess
<Jookia>
contributing to open source is an extremely difficult process that requires guessing what people are thinking or wanting or why they do things or why they don't do things
<MasterR3C0RD>
It's possible that might've reduced the reach of your patches, making it only really possible to properly review on Patchwork (which might not be the optimal workflow for reviewers/maintainers)
<Jookia>
yes i replied
<Jookia>
they didn't follow-up to my reply after that
<Jookia>
did you want to review my SPI NAND patches?
hipboi has quit [Quit: hipboi]
<MasterR3C0RD>
I have some patches in progress myself for the A100 that are necessary to unblock mainline U-Boot support, so wouldn't be able to do it for a while at least. I might be able to take a look in the future though, but can't make any promises atm
<Jookia>
thats okay
<MasterR3C0RD>
On the other hand, if you ever get the DM-MUSB patches into a state to be mainlined, I would be happy to provide a Tested-by on that
<Jookia>
gotcha
<MasterR3C0RD>
Though I understand that isn't a priority for you, it is definitely something that there's interest in already, and might help you figure out if there's something you're missing that isn't clear yet
<Jookia>
true
colinsane has quit [Ping timeout: 480 seconds]
colinsane has joined #linux-sunxi
hipboi has joined #linux-sunxi
parthiban has joined #linux-sunxi
parthiban has quit [Remote host closed the connection]
parthiban has joined #linux-sunxi
jason123onirc has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
jason123onirc has joined #linux-sunxi
parthiban has quit []
hipboi has quit [Quit: hipboi]
parthiban has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
hipboi has joined #linux-sunxi
ungeskriptet is now known as Guest9058
ungeskriptet has joined #linux-sunxi
Guest9058 has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
parthiban: Looks like everything from the "second stage" patch series is making it in for 6.13; hopefully we'll be able to get RTC, ethernet, and crypto for 6.14, but I'll have to wait for the next window before I can submit those
<parthiban>
MasterR3C0RD: Great. Thanks for sharing. I do started monitoring linux-sunxi mainline list.
<parthiban>
Btw, Jookia was right about the IOMMU for the DE. We need IOMMU to do that mapping, otherwise the memory is accessible. I think that's the main reason for DE's address space being random values.
sh1 has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
Ah, and we don't have an IOMMU driver yet do we?
<parthiban>
There is one in the upstream for h616 and h6.
<parthiban>
Also apritzel added it comptaible for A523.
<parthiban>
Am cross checking the registers.
<MasterR3C0RD>
I mean for the A100; was hoping we'd have pre-existing code to work off of
<parthiban>
In fact, T113 also needs one. But not sure how it managed to work with DE there.
<parthiban>
drivers/iommu/sun50i-iommu.c this should already work. Cross checking the registers.
<Jookia>
parthiban: glad you figured it out :D
<parthiban>
Jookia: still trying, thanks
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
jason123onirc has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
jason123onirc has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
hipboi has quit [Quit: hipboi]
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 joined #linux-sunxi
hipboi has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
Jookia: I am sad and sorry that you feel frustrated again so quickly. Can I ask you for a little bit more patience at this point?
<apritzel>
I will eventually look at the SPI NAND patches, but it's not my top priority
<Jookia>
apritzel: sure! like, to be clear, i'm not blaming you or anyone
<apritzel>
as much you have your priorities, I also have some ;-)
<apritzel>
and yeah, being the only one that is pushing on something is not nice (been there, done that)
<Jookia>
i'm a good 90% sure this is just autism confusion about unwritten social cues. still, i'm here and hopefully trying to build bridges instead of burning them :)
<apritzel>
Jookia: don't blame yourself, I feel like most if is just bad luck
<Jookia>
bad open source RNG? :)
<apritzel>
I wonder if the T113-s3 is too embedded to draw proper mainline attention
<apritzel>
as in: people have most of it, hack the rest in their repos, and ship it
<apritzel>
and don't care about mainlining - which includes reviews and test comments on the list
colinsane has quit []
<apritzel>
Jookia: in any case: I don't feel like digging in those old threads, about old patches that probably don't apply anymore anyway. So can you prepare a new clean rebased series?
<apritzel>
and then we take it from there?
<Jookia>
apritzel: sure, i'll think about it. i'm a little worried now that it's a waste of both our time to mainline something that has such little interest though
Schimsalabim has quit [Ping timeout: 480 seconds]
<apritzel>
SPI NAND has quite some future, I see more and more board shipped with it
<Jookia>
okay! i think though for now i'll try and work on the musb dm code. i think i need a plain positive experience of a bugfix
<apritzel>
thanks!
Schimsalabim has joined #linux-sunxi
<Jookia>
thank you for being very patient with me :)
colinsane has joined #linux-sunxi
hipboi has quit [Quit: hipboi]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
colinsane has quit []
colinsane 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]
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
dsimic is now known as Guest9105
dsimic has joined #linux-sunxi
Guest9105 has quit [Ping timeout: 480 seconds]
colinsane has quit []
smaeul_ has quit []
smaeul has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
wingrime-ww has quit [Remote host closed the connection]
wingrime-ww has joined #linux-sunxi
colinsane has joined #linux-sunxi
colinsane has quit []
colinsane has joined #linux-sunxi
<apritzel>
MasterR3C0RD: regarding new patches: typically after -rc1 is a good time for sending new stuff, that also gives you a good base commit to rebase on
<MasterR3C0RD>
apritzel: Yeah, that's what I was thinking; I'd have to wait anyways since I need to add a new ethernet entry which I believe means I'll need to submit to netdev? So I have to wait for netdev-next to open, which won't be until rc1's tagged if I'm understanding things correctly
<apritzel>
but you can as well send patches earlier, to just get the reviews and comments started. I know that some maintainers are snubbed about new patches send at "inappropriate times", but sunxi is cool about that, I'd say
<apritzel>
netdev might be indeed picky, though, but it's just a matter of the right tag there - netdev vs. netdev-next?
<MasterR3C0RD>
It's a new configuration entry, not a fix, so I think that'd be netdev-next?
<apritzel>
do you need to add something to the *code*, or just the DT?
<MasterR3C0RD>
I do, I need to add a new compatible because the reset value is different on A100
<apritzel>
I never really got why we have this value, the rationale doesn't make much sense to me
<apritzel>
either we have undocumented bits in there, then we just leave them alone (mask them)
<apritzel>
or we know what the bits mean, then we can surely figure out the right value to set for operation and poweroff
<apritzel>
but the value is not the only difference, right? There is also .support_mii = false?
<MasterR3C0RD>
Yeah, though that actually doesn't change anything at the moment
<apritzel>
so could you solve the Gigabit link problem?
<MasterR3C0RD>
The value appears to be completely unused, so I'm not entirely sure why it's there, but in modelling the hardware as described by the user manual I set it to false anyways
<apritzel>
interesting, you are right
<apritzel>
maybe worth checking the history if it was ever used before
<MasterR3C0RD>
I'm still not sure if the Gigabit issue is due to the driver or something else; a single time it managed to negotiate 1Gbps but then downlinked
<apritzel>
sounds more like a PHY problem then?
<MasterR3C0RD>
Yeah, it might be power related considering the behavior I noticed with the LEDs getting dimmer when VDD_PC/PL are dropped to 1.8V instead of 3.3V
<MasterR3C0RD>
This device does not appear to have well thought out power routing
<MasterR3C0RD>
So I suppose there's a possibility dropping aldo1 to 1.8V causes the PHY to get underpowered, and gets it stuck at 100Mbps, but I'll have to dig into the datasheet a little more to see if that even makes sense
<apritzel>
so looking at the descriptions: would it work with an H6 or A64 fallback compatible then, considering it's only the syscon value and the unused .support_mii that differ?
<apritzel>
regardless of the value of having this default, one could argue that the syscon doesn't belong to the MAC
<MasterR3C0RD>
Without the correct syscon reset value the PHY starts up and negotiates a link, and the kernel knows there's an uplink, but I can't get any traffic through
<MasterR3C0RD>
Every write to the syscon registers uses the reset value as a base instead of the current register value, which I agree is just bad design
<apritzel>
montjoie_: do you remember the deeper purpose of this syscon default in Linux' dwmac-sun8i.c? Was it to fix broken firmware?
ftg has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<MasterR3C0RD>
Side note, I might end up messing with the address mapping code a bit to see if I can make it more sensible. The current DRAM code copies the methodology used by boot0, but I see no reason why we couldn't use a more reasonable mapping
<MasterR3C0RD>
I.e, a more reasonable HIF bit ordering of columns, banks, bankgroups, rows, ranks
<apritzel>
MasterR3C0RD: you are clearly on a higher level, now fixing boot0! ;-)
<MasterR3C0RD>
HAHA! Well, considering the uMCTL2 IP used for DDRCTL is well documented, it's easy to mess around with; it's the only part of the DRAM code that makes sense to me. The PHY is still a mystery though, so I'll have to leave that alone for now
colinsane has quit []
colinsane has joined #linux-sunxi
jason123onirc has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
jason123onirc has joined #linux-sunxi
<apritzel>
does the PHY affect any timing at all? Or is it "just" voltage levels and pin assignments?
linkmauve has left #linux-sunxi [Error from remote client]
jason123onirc has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
jason123onirc has joined #linux-sunxi
linkmauve has joined #linux-sunxi
<MasterR3C0RD>
apritzel: It seems like some values on the PHY are adjusted depending on the clock frequency, but I haven't been able to dig into that too much yet
<MasterR3C0RD>
Aside from that, DDRCTL handles setting up master timings (tRAS, tCL, etc)
<MasterR3C0RD>
PHY also handles DQS remapping, and is what runs the DRAM calibrations (read gate, read/write DQ deskew, CA/DQ eye, ZQ, etc)
apritzel has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
And of course drives and ODT
<MasterR3C0RD>
The deskews would likely count as "timings" in my book, but those are affected by a mix of the mode registers (controlled by DDRCTL) and the "test patterns" (written by DDRPHY)