00:19 <hanetzer> yuh. upstream is best stream

07:37 <micken> robmur01: thanks

08:10 <micken> robmur01: ok, but smc enters something in ATF (monitor?) and then exists?

08:10 <micken> exits

08:12 <micken> I am reading smc calling convention gguide

08:40 <micken> robmur01: just replacing hvc with smc , give 0x0 in r0 , so if the psci function actually runs, it would indicate success. But it doesn't jump to the entrypoint address

08:44 <micken> robmur01: and if I enter a bogus value in arg 2 (r1) it returns -2

09:15 <micken> and a read of mpidr returns with only bit 31 set

09:16 <micken> that doesnt sound right

09:32 <micken> robmur01: and settinbg target core to 0x0 returns already on ... so I must miss something

09:46 <micken> I meant , it means that CPU_ON is ok, but it doesn't jump to entry_point_address

12:15 <robmur01> micken: welcome to herding cats ;)

12:15 <robmur01> don't expect anything to "jump" as such - after the SMC returns, the boot CPU will simply carry on executing - it's up to you what to do with it

12:16 <robmur01> at the same time, the new CPU will start executing from the entrypoint in AArch64 EL2

12:22 <robmur01> so you probably want the entrypoint to at least initialise VBAR and do some basic setup

15:04 <micken> robmur01: ok. thanks again. I didnt expect it to switch to aarch64 (from aarch32)

15:06 <micken> psci code in u-boot is just a shell

15:06 <micken> quite empty

15:29 <micken> writing a small handler now for it

15:31 <mmind00> micken: you might want arm-trusted-firmware instead, maybe?

15:31 <micken> dunno yet

15:31 <mmind00> micken: aka there is a complete process already established to build uboot+atf ... with working psci

15:31 <micken> that handler was for the switch , not u-boot

15:33 <micken> mmind00: ok? I am using BLOB uboot (cant get to aarch32 in mainline)

15:33 <mmind00> ok

15:36 <robmur01> is RiscOS itself SMP these days?

15:40 <robmur01> because if not, then you may as well leave the boot CPU in AArch64 at EL2 to do the juggling and launch the big CPU straight at your current "drop to 32-bit EL1 and continue" routine

15:42 <robmur01> otherwise, yes, you'll need a tiny "hypervisor" at EL2 to marshal between AArch32 EL1 and AArch64 EL3

15:43 <micken> ok

15:44 <micken> not much smp in riscos

15:46 <micken> if the hypervisor needs to be aarch64, then do it in u-boot is the only option

15:48 <robmur01> in principle I think you could build upstream ATF to enter EL2 in aarch32, but then you'd have to build a 32-bit u-boot for RK3399

15:48 <robmur01> which would almost certainly be "fun"

15:48 <micken> heh :D

16:51 <micken> sigh , time to learn arm64 asm

16:52 <maz> pretty much the same as 32bit, tbh...

16:53 <maz> just without conditionals....

18:39 <pcbBob> Hi :) Anyone here who might want to share the TRM for the RK2918?

18:45 <pcbBob> Or give me a hint where I might be able to find it? I only found a very short TRM and the datasheet (which doesn't provide enough information)

19:40 <pcbBob> Not much happening in the linux for rockchip world?

19:41 <vagrantc> plenty happening

19:44 <pcbBob> But not TRM for RK2918?

19:44 <pcbBob> *no

19:46 <vagrantc> many people from a wide variety of timezones in here ... patience :)

19:52 <micken> soo

19:53 <micken> as soon as I touch mon mode I end up in atf?

19:53 <micken> seems like it

20:18 <micken> cant overwrite mvbar

20:18 <micken> cant switch to mon32 for doing it

20:19 <micken> I am too stupid to understand the macro asm that switches to el1-aarch32 :D

20:49 <pcbBob> there were some people asking for RK2918 datasheet and they never got a successfull response so I guess Rockchip just doesn't want to know us about the RK2918?

20:54 <inode> pcbBob: my guess is it's possibly a case of appeasing large customers who believe in security through obfuscation

20:55 <inode> i've been looking for the RK3229 TRM for a while

20:56 <inode> obfuscation/obscurity

20:56 <pcbBob> What is so interesting about the RK2918 is that it actually supports SRAM, DDR, DDR2 and DDR3 as external memory

20:57 <pcbBob> But what you are saying is that there is one large customer which does not want anyone else to know about this chip but this customer only bugs RK2918 (and RK3229) but not the other ones for which TRMs have been released?

20:57 <pcbBob> *buys

20:57 <inode> yes, but like i said it's just a guess

21:01 <inode> i came to this conclusion after i wrote a request for the reference manual to rockchip, and once i had disclosed that i'm just an individual without any business interest in its application - i was then told to consider making use of single board computers which feature their other SoCs with publically available documentation instead

21:02 <pcbBob> So you actually got an answer?

21:02 <pcbBob> That's surprising to me

21:02 <inode> yes i did

21:02 <pcbBob> Maybe I write an e-mail about the RK2918

21:02 <pcbBob> What was your contact? Just their webpage?

21:02 <inode> i hope you have better luck than i did :)

21:02 <inode> let me check my mailbox, brb

21:03 <pcbBob> Thanks!

21:06 <inode> i wrote to opensource@rock-chips.com initially, and i probably got this address from their website

21:06 <pcbBob> Thanks, I will try :)

21:07 <inode> pushing my luck here - but do you by any chance have the TRMs for MT8321 or SC7731? ;)

21:09 <pcbBob> No I am sorry. I have access to one chinese forum and they freely share some datasheets, but that forum doesn't have any information about the two ICs you just mentioned

21:11 <inode> thanks for checking

21:40 <pcbBob> May I ask you why those specific CPUs? inode

21:45 <micken> robmur01: OK: so trying many different aproches , but I need to know what catches my smc 0

21:46 <micken> robmur01: I am not sure of where the best place is to do the cpu_on , right now I try it as first thing in the switch to aarch32

21:47 <micken> setting up the cpu can be done in kernel

21:50 <micken> Hoho

21:50 <micken> I am returning

21:57 <micken> I do the smc and after the smc I have a stoploop

21:57 <micken> at the entry point defined I print a 'E' and I get that 'E'

22:02 <inode> pcbBob: the SC7731 is fairly common in low cost smartphones, and the MT8321 seems to serve a similar role for low cost tablets

22:10 <inode> it would be ideal to be able to pick up an affordable mobile device right off the shelf of a local shop and then have the option to ditch the questionable software/firmware that is inevitably shipped with it

22:41 <micken> robmur01: after the macro for switching to el1 it stops.. I assume that it should be loading from boot entry by then

22:42 <micken> the function in transisitions.S calls the macro and do no more

23:35 <micken> I am in rom again!