ftg has quit [Read error: Connection reset by peer]
apritzel has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
DasChaos1 has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
DasChaos1 has quit []
junari_ has joined #linux-sunxi
<DasChaos>
ls
arnd has quit [Server closed connection]
arnd has joined #linux-sunxi
lvrp16 has quit [Server closed connection]
lvrp16 has joined #linux-sunxi
bauen1 has joined #linux-sunxi
bauen1 has quit [Read error: Connection reset by peer]
Daaanct12 has joined #linux-sunxi
junari has joined #linux-sunxi
apritzel has joined #linux-sunxi
<junari>
What is the initialization order in the SPL? CLK, PMIC, DRAM? Or something else?
Daanct12 has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
<apritzel>
junari: yes, roughly. There is more, of course, like the UART, and not every SoC/board needs a PMIC
<junari>
apritzel: my devboard have pmic. I think that the output to the console will not appear until the PMIC provide a I/O voltage for UART
<apritzel>
junari: what SoC? Most modern SoCs can get away with the PMIC defaults, so there is no need to configure that first
<apritzel>
and I don't think you ever need the PMIC for the UART
<gamiee>
This reminds me, once power supply is available to PMIC, it have some default voltages which are supplied to SoC ?
<apritzel>
gamiee: yes, the PMIC has backed in defaults for almost every rail, and typically you get quite far without touching the PMIC
<junari>
apritzel: t507 with axp853t pmic
<apritzel>
the BROM cannot know about any PMIC, so the basic boot (SPI, MMC, UART) must work without configuring it
<apritzel>
junari: the H616 typically comes with the AXP305, and those boards needs PMIC setup for DRAM in the SPL, because something was messed up in the board/PMIC design
<apritzel>
junari: typically the PMICs have rails designed for DRAM, and one *pin* to configure the voltage
<apritzel>
if you wire that up correctly, you don't need the PMIC in the SPL, see the H6 and A64/H5
<gamiee>
apritzel: good to know, thanks ! 😊
<apritzel>
junari: DCDC5 is meant for DRAM (DDR) on the AXP853T
<apritzel>
junari: you can then wire the DC5SET pin according to the DRAM type you use
<junari>
There are several pads on the SoM for measuring output voltages from pmic. Some of them are 3V3, 1V8 and 0V9 in a loaded system. In fel mode most of them 0V. Unfortunately, there is no way to get to the RAM pad, which should be 1V1
<apritzel>
junari: if this is a SoM, I guess the DDR and the PMIC are on it, and are hopefully configured correctly?
<junari>
Yep, bsp os working
<apritzel>
junari: as I said, the PMIC's SYS and CPU rails need to be enabled by default, otherwise you cannot load even the SPL
<apritzel>
and most of the integrated peripherals are connected to SYS
<apritzel>
if you look at common designs, it's only the more demanding peripherals like Ethernet PHYs or USB that are connected to separate PMIC rails
sauce has quit [Server closed connection]
sauce has joined #linux-sunxi
<junari>
apritzel: Thank you. So pmic doesn't affect early startup.
<junari>
I watched how RAM is initialized in boot0_sdcard and there is a voltage setting for RAM. I thought it might matter
<apritzel>
junari: yes, boot always had this, but the setting should be redundant
DasChaos has quit [Quit: Bridge terminating on SIGTERM]
warpme___ has joined #linux-sunxi
DasChaos has joined #linux-sunxi
DasChaos is now known as Guest175
AntoniAloyTorrens[m] has joined #linux-sunxi
rajkosto has quit [Read error: Connection reset by peer]
<apritzel>
I meant "boot0 always had this"
<moteen>
is someone working on a patch for mmc driver for the D1, I have made progress on gpio driver by adding pinmux.c in arch/riscv and its object in makefile
<apritzel>
moteen: ah, I should push my patches somewhere then, even if they are not ready ;-)
<moteen>
yes, it would be really helpful else I have to start from scratch for the mmc driver😅
<apritzel>
moteen: what's the exact problem with the MMC driver? some <arch/..> include?
<moteen>
int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT) + 1;
<moteen>
int m = ((rval >> 1) & 0x1) + 1;
<moteen>
int p0 = ((rval >> 16) & 0x7) + 1;
<moteen>
/* The register defines PLL6-2X, not plain PLL6 */
<moteen>
return 24000000 / n / m / p0;
<moteen>
}
<apritzel>
yeah, just found it ...
<moteen>
which doesnt matches any standard SUNXI_CCM_BASE
<moteen>
also I found something weird happening with the headers, I have to put in absolute pats instead for it to work for some reason
<apritzel>
yeah, the headers are mess, almost everything in arch/arm has to move
<apritzel>
this might involve some refactoring
<moteen>
i was thinking of having the same file structure for riscv same as arm
<moteen>
for the headers, riscv based boards should be independent of arm based headers
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
<apritzel>
the headers shouldn't be in arch/arm in the first place
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
<karlp>
wouldn't be the first or last time things that are "arch" specific not "arm" specific end up there :)
<apritzel>
karlp: yeah, U-Boot dodged this problem before by treating ARMv7 and ARMv8 as the same arch
Daaanct12 has quit [Quit: Quitting]
rpirea__ has joined #linux-sunxi
rpirea_ has quit [Read error: Connection reset by peer]
moteen has joined #linux-sunxi
rpirea__ has quit [Read error: Connection reset by peer]
rpirea__ has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
<apritzel>
smaeul: can you please have a quick look at the pinctrl series I pushed to my Github? Not all patches are really needed, but I figured we can use the opportunity to clean this up.
<apritzel>
I haven't tried actually wiring up the D1, though, but it should remove the arch/arm includes from the GPIO and pinctrl DM drivers, and should take care of the different register layout
<apritzel>
the register layout is actually set at compile time, which we need for the R528/T113 SPL. If we really need to, we could try to let DM enforce this via the respective compatible string, but I am not sure we need that
moteen has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen_ has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
moteen_ is now known as moteen
<moteen>
apritzel thanks for the reference for pinctrl, if you have any references for the mmc driver support for D1 please share, I will work on other drivers for now
aedancullen has joined #linux-sunxi
aerospace[m] has joined #linux-sunxi
aperezdc has joined #linux-sunxi
Arthur[m]12 has joined #linux-sunxi
chuang[m] has joined #linux-sunxi
cmeerw[m] has joined #linux-sunxi
cperon has joined #linux-sunxi
dickenhobelix[m] has joined #linux-sunxi
dittid[m] has joined #linux-sunxi
JuniorJPDJ has joined #linux-sunxi
z3ntu has joined #linux-sunxi
mripard has joined #linux-sunxi
Newbyte has joined #linux-sunxi
insep has joined #linux-sunxi
DavidHeidelberg[m] has joined #linux-sunxi
oliv3r[m] has joined #linux-sunxi
pgwipeout[m] has joined #linux-sunxi
psydroid[m] has joined #linux-sunxi
sajattack[m] has joined #linux-sunxi
Skallwar[m] has joined #linux-sunxi
t4h4[m] has joined #linux-sunxi
Tooniis[m] has joined #linux-sunxi
MatrixTravelerbot[m]1 has joined #linux-sunxi
DavidHeidelberg[m] has quit []
DavidHeidelberg[m] has joined #linux-sunxi
JohnDoe_71Rus has quit []
moteen has quit [Ping timeout: 480 seconds]
Guest175 has quit []
<smaeul>
moteen: the correct thing to do is to implement .get_rate in the DM clock driver (drivers/clk/sunxi), so the MMC driver does not depend on any of those headers
enick_547 has joined #linux-sunxi
enick_547 has quit []
DasChaos has joined #linux-sunxi
hentai has joined #linux-sunxi
<DasChaos>
<smaeul> "you can also check that the..." <- I tried setting the config in this files, but it didn't help. What bits do you mean to check?
hentai has quit [Max SendQ exceeded]
hentai has joined #linux-sunxi
rpirea__ has quit []
rpirea has joined #linux-sunxi
moteen has joined #linux-sunxi
cnxsoft has quit []
JohnDoe_71Rus has joined #linux-sunxi
moteen_ has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
junari_ has quit [Ping timeout: 480 seconds]
rpirea has quit [Quit: Leaving]
moteen has joined #linux-sunxi
moteen_ has quit [Ping timeout: 480 seconds]
AntoniAloyTorrens[m] has quit []
MatrixTravelerbot[m]1 has quit []
psydroid[m] has quit []
aedancullen has quit []
cmeerw[m] has quit []
mripard has quit []
apritzel has quit [Ping timeout: 480 seconds]
dickenhobelix[m] has quit []
<jernej>
apritzel: default PMIC settings for DRAM are probably not messed up. H616 supports several DRAM types and not all types work with same voltage
<jernej>
so designers had to pick up some value, probably the one they thought will be most common choice
moteen_ has joined #linux-sunxi
moteen has quit [Read error: Connection reset by peer]
apritzel has joined #linux-sunxi
moteen_ has quit [Ping timeout: 480 seconds]
<apritzel>
jernej: I think the AXP305 is a bit weird: DCDC-B is clearly meant to DRAM, with the DCBSET pin selecting between 1.2 (LPDDR3), 1.5 (DDR3) and 1.1V (LPDDR4)
<apritzel>
jernej: but at the same time it's polyphased with DCDC-A, or both A and C
<apritzel>
so you cannot use it if you need two (or more) phases for the CPU
JohnDoe_71Rus has quit []
<jernej>
ah, these settings
<jernej>
yeah, that seems to be misconfigured
<apritzel>
and if OrangePi would have used LPDDR3, they could have used the default 1.2V of DCDC-D ...
<smaeul>
DasChaos: I meant to check the bits in the CCU and PIO registers with `md` at the U-Boot shell. but there is no need to do that if I2C works after fixing CONFIG_SYS_TCLK
ftg has quit [Read error: Connection reset by peer]