ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
damxsa_ has quit [Remote host closed the connection]
Turingtoast has joined #armlinux
damxsa has quit [Ping timeout: 265 seconds]
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
jlinton has quit [Ping timeout: 256 seconds]
Nact has joined #armlinux
apritzel has joined #armlinux
Nact has quit [Quit: Konversation terminated!]
jlinton has joined #armlinux
Misotauros has quit [Ping timeout: 240 seconds]
apritzel has quit [Ping timeout: 265 seconds]
Tokamak_ has quit [Ping timeout: 268 seconds]
Misotauros has joined #armlinux
Tokamak has joined #armlinux
mraynal has joined #armlinux
<mraynal>
geertu: hello! I am trying to adapt an out-of-tree DT (which works with an upstream kernel) so that it only uses mainline binding/drivers but I'm facing boot issues of course
<mraynal>
I was wondering if you had aside a working earlyprintk configuration?
<mraynal>
(for a rzn1d400 based board)
<geertu>
mraynal: I don't have any RZ/N1 hardware.
<geertu>
And it uses a non-Renesas UART, right?
Turingtoast has joined #armlinux
<geertu>
Well, I mean Synopsis-based
<geertu>
:q
<mraynal>
hehe
<geertu>
mraynal: I'm afraid you have to add DEBUG_LL support for snps,dw-apb-uart first
<mraynal>
geertu: it's uart0 with compatible snps,dw-apb-uart
<mraynal>
oh damn
<mraynal>
:)
<geertu>
mraynal: I take it "earlycon keep_bootcon" is not sufficient?
<mraynal>
mmmh, I haven't tried that yet
<geertu>
That should be good enough for all but debugging the earliest parts. So if you start with a DTS that works, it's probably good enough.
<mraynal>
I've got a beautiful Oops, and this makes me very happy :) I actually never use these bootargs but they are pretty useful
iivanov__ has joined #armlinux
<geertu>
mraynal: good!
iivanov_ has joined #armlinux
iivanov_ has quit [Remote host closed the connection]
iivanov_ has joined #armlinux
iivanov has quit [Ping timeout: 240 seconds]
iivanov__ has quit [Ping timeout: 252 seconds]
alexels has quit [Quit: WeeChat 3.3]
tre has quit [Remote host closed the connection]
rbutler1728 has joined #armlinux
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rfs613>
mraynal: sorry, just seeing this now, did you get it sorted?
<rfs613>
seems like it, but if not, feel free to ping me.
<mraynal>
rfs613: well, partially, my issue is that some early clock code accesses a base address that has not been yet initialized
<rfs613>
mraynal: debugging the early startup is a pain. I've fought with a number of use-before-clock-enabled on the RZ/N1...
<mraynal>
the problem is, this static pointer has no real initialization point. I can't init from the arch code because it is too early (ioremap fails because nothing on this side has been initialized), so I have to guess what will be the first user and call the init helper at that point ^^
<rfs613>
mraynal: hmm, that sounds backwards (and fragile)
<rfs613>
mraynal: are you working with the my 5.15 tree (did Milan share it with you?)
<mraynal>
rfs613: I'm on a 5.15-rc2 (yeah, I might rebase that soon :) )
<rfs613>
mraynal: mainline or with patches?
<mraynal>
rfs613: mainline + DT changes only
<mraynal>
I need to understand why the DT from Milan does work (I'm still investigating)
<rfs613>
mraynal: cool, I didn't expect that would even boot... I'e got close to 100 patches on top, from Renesas and Milan
<mraynal>
well, it does not yet boot :p but we are very close to something working
<mraynal>
timers, irqs, ddr and uart are what is left
linusw_ has quit [Quit: Connection closed for inactivity]
<rfs613>
yup, makes sense... can add back in later. There's also quite a lot of custom-ish hardware, like all the ethernet switch and converters. Also some really invasive patch to workaround some hardware errata.
matthias_bgg has quit [Ping timeout: 265 seconds]
<mraynal>
rfs613: baby steps =)
<mraynal>
rfs613: btw, the r9a06g032-db device tree contains a renesas,r9a06g032 compatible but not the renesas,rzn1 compatible
<mraynal>
while in the arm machine code, only renesas,rzn1 is provided in the dt_compat hook
<rfs613>
mraynal: totally agreed, baby steps
sakman has joined #armlinux
<mraynal>
this cannot work and in my case I need either to add renesas,r9a06g032 to the dt_compat hook or add renesas,rzn1 to the main compatible
<mraynal>
I believe the latter is the right solution, do you agree ?
<rfs613>
mraynal: AFAIK r9a06g032-db is for the Renesas eval board, which I don't have... the SE stuff has its own ARCH (not really sure if that's truly justified, but that's how it currently is)
<mraynal>
well, geertu nicely remarked that I should provide the two compatibles for the NAND controller because one is most specific than the other
<mraynal>
IMHO we should have the same thing at board level: compatible = <board>, "renesas,r9a06g032", "renesas,rzn1";
<mraynal>
rfs613: don't you think?
<rfs613>
mraynal: from a practical point, I can easily change DT, so it doesn't matter to me which compatible is used.
<rfs613>
mraynal: AFAIK the r90ag032 is very specific, it's the actual part number for RZ/N1D... but this NAND controller is certainly used in other RZ devices
<mraynal>
yes, that is why the driver primarily matches against rzn1, but the bindings describe both
<mraynal>
and so should be the main compatible
headless has joined #armlinux
<rfs613>
I just did a quick check of RZ/A2M (r7s921.*) and it seems to have same NAND controller
<mraynal>
great, if the IP is similar it shouldn't take more time than adding a second compatible in the list :)
<rfs613>
hmm, i noticed the two patches I posted to the list got applied, but in patchwork they still show as "new". Do I need to do anything to address this, or it will just happen magically eventually?
<mraynal>
rfs613: what patches are you talking about?
<mraynal>
rfs613: actually I was wrong, I am based on your 100+ patches branch :') I just "forgot" about it...
<rfs613>
ah okay, that makes more sense! I would love to see mainline run on it, but there's a way to go for that...
Tokamak has quit [Read error: Connection reset by peer]
<mraynal>
yeah, I thought the machine code I was touching was mainline but it's not
<mraynal>
and indeed, should be adapted before being sent
Tokamak has joined #armlinux
<geertu>
mraynal: The toplevel compatible should not include "renesas,rzn1"
<rfs613>
geertu: the same IP is present in multiple SoC devices within the RZ family. Perhaps even in other families, I dunno.
<rfs613>
it seems that listing each board, or each soc, would be rather tedious. Is that what we want?
<geertu>
rfs613: Where do you have to list each board in the code?
<geertu>
or even each SoC?
<geertu>
There are no matches for "renesas,rzn1d400-db" or "renesas,r9a06g032" in the (upstream) code
<rfs613>
geertu: maybe I am mis-understanding you, but the point here is the same IP exists in many SoC devices, which are used on even more boards.
<rfs613>
both those names you just listed are specific board and a specific soc, AFAIK
<rfs613>
(well, the part after the comma, anyway)
<geertu>
rfs613: for the nandc, we would have just "renesas,rzn1-nand-controller" in the code.
<geertu>
And "renesas,rza-nand-controller" or so if it turns out to be (somehwat) compatible
<rfs613>
geertu: okay, that's what I was figuring "renesas,rzn1" would be used for. But it can be "renesas,rzn1-nand-controller" if that's better. I suspect it might even be just "rz" rather than "rzn" or "rza". Though I would need to check a lot of data sheets to know that for sure.
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<geertu>
rfs613: There's RZ/G1, RZ/G2, RZ/G2L, RZ/A1, RZ/A2, RZ/T1, RZ/N1, so no "rz" is not a good idea (we do have "renesas,rspi-rz", from before we know about the proliferation of completely different RZ families)
<geertu>
s/know/knew/
<geertu>
rfs613: "renesas,rzn1" is a top-level compatible that can be used if we ever have to match on that specific SoC model to fix an integration issue (i.e. not related to the individual IP cores, but to how they're connected to each other)
Tokamak has quit [Ping timeout: 268 seconds]
<rfs613>
geertu: not sure I entirely follow that, but that's pretty normal for me... I guess it will become clear eventually :)
apritzel has joined #armlinux
Tokamak has joined #armlinux
headless has quit [Quit: Konversation terminated!]
ardb has quit [Ping timeout: 268 seconds]
ardb has joined #armlinux
rbutler1728 has quit [Read error: Connection reset by peer]