<apritzel>
lschmid: thanks, so it looks like it returns at least, but the second core got stuck somewhere, or doesn't spring to life at all. Interestingly we end up in SVC, not HYP. I need to check that later on my board ...
<lschmid>
I still got the unfused board here. Do you want to see what it reports?
<apritzel>
oh yeah, that would be helpful. Did you change anything else in U-Boot, during those experiments?
<lschmid>
And not that i'd know of. But i'll go ahead and clean the other stuff i have messed around with
<apritzel>
right, that looks fine, so it's something that goes wrong with the secure-boot version only. Can you boot the kernel with "maxcpus=1" added on the command line, to see if at least core 0 starts in HYP?
ungeskriptet has quit [Remote host closed the connection]
<lschmid>
No, it's in SVC too "CPU: All CPU(s) started in SVC mode."
ungeskriptet has joined #linux-sunxi
<lschmid>
Oh wait. I disabled "CONFIG_ARMV7_VIRT" when testing earlier. Is that it?
<lschmid>
Ah okay, it's booting in HYP now
<lschmid>
And we got two cores!
<apritzel>
\o/
<lschmid>
So secure-boot/mode on T113-s3 works?
<lschmid>
Is there anything I should test before jumping to conclusions?
bauen1 has joined #linux-sunxi
<apritzel>
oh, btw, can you try whether writing just 0xff instead of 0xffffffff to the SPC registers works as well? And the code should go to tzpc.c, which would need to be enabled (alongside the H3)
<apritzel>
writing the specific values for the H3 is probably pointless, I think we should write 0xff everywhere, which means that can shared between the H3 and R528/T113
<apritzel>
lschmid: if you want to make a patch, that'd be great. Otherwise I will have a stab at it on the weekend, but of course cannot test it.
<apritzel>
and this would be unconditional of secure boot or not, as it is for the H3 already. The SPC gets ignored with the fuse not burnt, but it doesn't hurt to set up the SPC anyway
<lschmid>
I see. So the H3 only writes the first three regs. Do we change the writing to one in the style of the ATF code, or would I make bigger struct in case of the r528?
<lschmid>
0xff does not work btw
<lschmid>
And where would the writes to "CCM", "PRCM" and "DMA" go? I assume tzpc.c would be wrong
Schimsalabim has joined #linux-sunxi
<apritzel>
so for CCM, it's probably SUNXI_CCM_BASE+0xf00. Can you try to write 0xffffffff there from the U-Boot command line, and see if this write sticks?
<lschmid>
Oh sorry, I meant where would i put the writes in the code/patch later. I have used the same writes as in ATF and they make Ethernet work. without them ethernet is not working
<lschmid>
But yes the write is to SUNXI_CCM_BASE+0xf00 aka CCM_SEC_SWITCH_REG
<lschmid>
And i am writing 0x7 there
<lschmid>
Actually, if you don't mind. Could you maybe do the patch for this? I'd be happy to test the patch on my system if needed. I already have one patch pending and another one in the works for enabeling TWI3 (which for some reason does only work in late init)
iscle has joined #linux-sunxi
radxanaoki has quit [Quit: radxanaoki]
iscle has quit [Quit: Konversation terminated!]
<apritzel>
sure, can do that
sdfgsdfs has joined #linux-sunxi
sdfgsdfs has quit [Remote host closed the connection]
<lschmid>
Do you wan't me to put the things i've hacked into the board.c somewhere? Or should I just commit it to my git and send a link here?
warpme has quit []
warpme has joined #linux-sunxi
Sensu_Bean has joined #linux-sunxi
Sensu_Be1 has quit [Read error: Connection reset by peer]
<apritzel>
just a link would be fine, I think I know what to do, and you can then comment on the list
Sensu_Be1 has joined #linux-sunxi
Sensu_Bean has quit [Read error: No route to host]
Sensu_Bean has joined #linux-sunxi
Sensu_Be1 has quit [Read error: Connection reset by peer]
Schimsalabim has quit [Ping timeout: 480 seconds]
ungeskriptet has quit [Remote host closed the connection]
<lschmid>
One other thing I wanted to ask on here. Does anyone have an idea why the pinctrl register for PG10, PG11 gets reset somewhere between i2c_init_board and board_late_init?
<apritzel>
lschmid: for I2C3? Why do you need that? Please note that i2c_init_board() is just to set up the I2C pins for the PMIC, in the SPL
<lschmid>
It's related to my other patch I sent. I am loading the boards/soms Mac-Address from an I2C attached eeprom.
warpme has joined #linux-sunxi
<lschmid>
And this eeprom is on TWI3
<apritzel>
for U-Boot proper you would use the normal DM pinctrl driver
<lschmid>
Okay so I need to implement TWI3 for PG in the pinctrl driver? That would then be configured using the device tree, right?
<apritzel>
exactly. Look for sun20i_d1_pinctrl_functions[] and add the name and respective pinmux there
<lschmid>
So I just add "twi3" and the alt function number?
<apritzel>
it's "i2c3" in mainline, but yes, just a line with the string and pinmux encoding (0x3 here). Refer to either the manuals or the Linux driver
<lschmid>
ah right. I'll give it a shot
<lschmid>
Nice, that seems to work. Thanks!
<lschmid>
Can I add this TWI3 patch to my (related) nvmem patch since, or should I just send another one?
<apritzel>
patches to the sunxi pinctrl driver should be separate, if that's your question, but you should put them in the same series
<lschmid>
Okay, even if i already sent the series but nothing has been done with it yet from the upstream side of things?
<lschmid>
Oh nevermind. I think i'll send the TWI3 patch with the defconfig for the SoM since that isn't out there yet anyways
<apritzel>
yeah, a reply to your patch is rotting in my drafts folder ...
Schimsalabim has joined #linux-sunxi
<lschmid>
One question regarding the soon-to-be patch series for the SoM. May I add a generic defconfig for the som, or (since it would use the basic-carrier devicetree) does the defconfig need to be named after the carrier?
<lschmid>
I'm asking because I do not see the point of 2 defconfigs that each are the same except for the dt
<apritzel>
Is the SoM usable on its own? I guess not, and you probably has a som.dtsi and carrier.dts, right? Then it's just one defconfig for the carrier. If other people have their own setup, they are welcome to send a patch ;-)
<lschmid>
Okay, so I'd send two defconfigs for my two carrier boards that have a device-tree pending in the kernel atm?