warpme_ has quit [Quit: Connection closed for inactivity]
dliviu has quit []
tllim has quit [Ping timeout: 480 seconds]
dliviu has joined #linux-sunxi
MangyDog has quit [Ping timeout: 480 seconds]
tllim has joined #linux-sunxi
tllim has quit [Ping timeout: 480 seconds]
tllim has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
tllim has quit [Ping timeout: 480 seconds]
<MoeIcenowy>
smaeul: nope, I just did 32-bit read on 0xbff8 and 0xbffc
<MoeIcenowy>
both returns 0
Danct12 has quit [Quit: Quitting]
Danct12 has joined #linux-sunxi
<smaeul>
MoeIcenowy: hmm, this is weird. I'm getting a load access fault when reading 0x1400bff8 from mainline OpenSBI (so I am in machine mode)
<smaeul>
how are you reading it?
cmeerw has joined #linux-sunxi
<MoeIcenowy>
smaeul: I read it in the debugger...
<MoeIcenowy>
(In fact I'm recently dealing with a FPGA kit with C906, not D1
cmeerw has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
Danct12 has quit [Ping timeout: 480 seconds]
gnarface has quit [Ping timeout: 480 seconds]
gnarface has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
gamiee has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
Daaanct12 has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
warpme_ has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
Daaanct12 has quit [Ping timeout: 480 seconds]
cnxsoft has quit []
cmeerw has joined #linux-sunxi
Daanct12 has quit [Quit: Quitting]
Danct12 has joined #linux-sunxi
arti has quit [Ping timeout: 480 seconds]
cmeerw has quit [Ping timeout: 480 seconds]
<smaeul>
apritzel: for SoCs without an SPL size limit, what problem do you have with DM in the SPL? this just makes porting easier
<apritzel>
smaeul: but we still have boards with an SPL limit which need I2C in the SPL (H5), so that would add a third option that needs to be supported?
<smaeul>
third option? beyond DM and non-DM
<apritzel>
smaeul: plus we usually need the information earlier, before we read the FIT image containing the DTB
<smaeul>
hmm, good point. isn't that what OF_PLATDATA is for?
<apritzel>
I mean we should still need non-DM for the H5, for instance, so we have DM, non-DM, and DM-SPL
<smaeul>
is there really any difference between DM and DM-SPL?
<apritzel>
smaeul: OF_PLATDATA is one workaround I was thinking about as well
<apritzel>
I mean in terms of different code paths that would need to be tested
<smaeul>
at least for risc-v, I'm trying to do as much with DM as possible, so I do not have to replicate arch/arm/include/asm/arch-sunxi
<smaeul>
but I am still using boot0 there, so I don't have to worry about SPL quite yet
<apritzel>
if the issue is really just about the base addresses, they could be easily derived from the SoC model, solely in code
<apritzel>
smaeul: boot0: yeah, I got a flashback to the beginning of A64 support, where we had to pull some nasty tricks to use boot0 as well
<apritzel>
smaeul: at least I was able to patch boot0 to load the image from 40KB instead of beyond 16MB
<smaeul>
well since boot0 is GPL, I was able to make it sane, so there are no hacks needed on the U-Boot side now
<smaeul>
even doing what we should be doing on ARM64: boot0 passes DTB to OpenSBI, which passes it to U-Boot, with no bundled DTB needed
<smaeul>
well, "should", but the current way works well enough
<smaeul>
turns out that the header in u-boot that tells you its size is ARM-specific, so I could not copy the DTB-finding hack to boot0
<apritzel>
yeah, that was indeed a hack, alternatively we could try to actually pass the address to TF-A, but it works (TM) for now
<apritzel>
smaeul: the reason for boot0 is DRAM support?
<smaeul>
yes, and the hairball that is arch/arm/include/asm/arch-sunxi
<apritzel>
yeah, I don't like this as well, but so far there was not enough reason to fix this
<smaeul>
dram is shipped as assembly, with symbols, DWARF, and debug prints, so it should be relatively easy to reverse, but so far wasn't a priority
<apritzel>
and there was some signs that it might be acceptable to add those values, and be it for U-Boot's purposes only
<smaeul>
generic pinctrl converts function="..." to the enum
<smaeul>
and similar to clock, we only have to include the mappings U-Boot actually needs
<apritzel>
yeah, this is what wanted to avoid
<apritzel>
I still don't really understand why we just don't put the mux value into the DT, and save us all this SoC tables for every stupid new SoC that Allwinner sends upon us
<smaeul>
well, U-Boot pinctrl-generic supports several bindings, so I can see if it can do something like that
<smaeul>
apritzel: while I don't really like lots of tables, one advantage of the table is it can be used for SPL too, e.g. pinctrl_request(pinctrl_dev, FUNC_I2C0), which would scan through the table and set up all FUNC_I2C0 muxes, with no DT needed
<smaeul>
apritzel: at least I think having a table of mux values in a pinctrl driver is better than every driver having #ifdef forest of mux values
palmer has quit [Remote host closed the connection]
palmer has joined #linux-sunxi
palmer has quit [Remote host closed the connection]
palmer has joined #linux-sunxi
palmer has quit [Remote host closed the connection]
palmer has joined #linux-sunxi
palmer has quit [Remote host closed the connection]
palmer has joined #linux-sunxi
<apritzel>
smaeul: yes, #ifdefs are a bad idea
<smaeul>
I like the "pinmux" property idea, although it doesn't match how the generic binding uses that property. I'm not so sure about the other part, especially now that the register layout is not always the same
<apritzel>
in case we go for hardcoded mux values, I wonder if the pinmux encoding can be short-cut, something like we do in sun8i-emac or in spi-sunxi.c
<smaeul>
what do you mean by short-cut? I think 4 bytes per pin is already pretty small
<apritzel>
like: if (socid == H3) iomux = SUN8I_IOMUX_H3;
<apritzel>
and then basically just map emac0 to this
<smaeul>
or do you mean still using the DT, and have a mapping of (SoC, function string) => pinmux value?
<apritzel>
I mean not having a table entry for every *pin*, but just mapping function_names x SoCs -> pinmux, and possibly doing this in cascaded if's, like in sun8i_emac.c
<apritzel>
yes ;-)
<smaeul>
hmm, and that means you only support one pin choice per function? (e.g. the various uart0 choices)
<apritzel>
yes, the UARTs are a problem, but for many devices there is only one mux (that we use)
<smaeul>
hmm, there are also CONFIG_MMC[123]_PINS, but those are already build-time options
<smaeul>
apritzel: I will try to implement one mux per function. I think it will work well enough
<apritzel>
smaeul: yeah, a quick grep&sort on the kernel's driver for A64 and H6 shows that it's only UART0 & 2 on the A64 that deviate from a single function-name -> pinmux mapping
<smaeul>
apritzel: I am also thinking of D1, which has 48 pinmuxes for 4 i2c controllers, and 74 pinmuxes for 6 UARTs :D
<smaeul>
and two sets of emac pinmuxes
<smaeul>
why? I have no idea
<apritzel>
never ask "why" questions about Allwinner designs ;-)
<smaeul>
now I wonder if you could do hub-and spoke with one of those i2c controllers... or if 6x internal pull-ups would be enough to drive the bus
warpme_ has quit [Quit: Connection closed for inactivity]
z3ntu has quit [Ping timeout: 480 seconds]
aperezdc has quit [Ping timeout: 480 seconds]
oliv3r[m] has quit [Ping timeout: 480 seconds]
MatrixTravelerbot[m] has quit [Ping timeout: 480 seconds]
Tooniis[m] has quit [Ping timeout: 480 seconds]
dittid[m] has quit [Ping timeout: 480 seconds]
Guest3147 has quit [Ping timeout: 480 seconds]
pgwipeout[m] has quit [Ping timeout: 480 seconds]
psydroid[m] has quit [Ping timeout: 480 seconds]
kayterina[m] has quit [Ping timeout: 480 seconds]
insep has quit [Ping timeout: 480 seconds]
JuniorJPDJ has quit [Ping timeout: 480 seconds]
ServerStatsDiscoverertraveler4 has quit [Ping timeout: 480 seconds]