f_ changed the topic of ##raspberrypi-internals to: The inner workings of the Raspberry Pi (Low level VPU/HW) -- for general queries please visit #raspberrypi -- open firmware: https://librerpi.github.io/ -- VC4 VPU Programmers Manual: https://github.com/hermanhermitage/videocoreiv/wiki -- chat logs: https://libera.irclog.whitequark.org/~h~raspberrypi-internals -- bridged to matrix and discord
jcea has quit [Ping timeout: 264 seconds]
Stromeko_ has joined ##raspberrypi-internals
Stromeko has quit [Ping timeout: 264 seconds]
Stromeko_ is now known as Stromeko
jcea has joined ##raspberrypi-internals
fury999io has quit [Quit: will be back]
fury999io has joined ##raspberrypi-internals
Stromeko has quit [Quit: Going… gone.]
Stromeko has joined ##raspberrypi-internals
jcea has quit [Quit: jcea]
jcea has joined ##raspberrypi-internals
<Bitweasil> So, question. If I want to boot a Pi3 (ARMv8 core) in AArch32/MON mode, is there a way to do that? I think I'm getting dumped out in hypervisor mode, but it's... unclear, stuff broadly isn't working unless I use the old kernel option and load at 0x0, coming in at SVC.
<clever> Bitweasil: with the open or closed firmware?
<Bitweasil> Stock Pi foundation stuff.
<clever> Bitweasil: arm_64bit=0 will force the arm core to start in arm32 mode
<Bitweasil> My conclusions so far: (1) The armstubs still exist, and they're part of the firmware blob now, instead of being separate files. (2) they pass execution into the kernel in, depending on config parameters, either in hyp mode or svc mode.
<clever> keep in mind, the kernel load addr differs, so if your kernel is not 100% PIC, things mal malfunction in fun ways
<Bitweasil> And (3) I think I can override the armstub to just pass me on to my kernel in mon mode, which is what I want.
<clever> i believe they pass control off in HYP mode now
<Bitweasil> That's what seems to be the case.
<Bitweasil> Unless you set some old kernel parameters, at which point you show up in SVC mode.
<clever> if you set kernel_old=1, then your kernel gets loaded to 0 and replace the armstubs entirely
<Bitweasil> Yes. I agree. And if I build a kernel for that, it works, I just end up in SVC mode on the ARMv8 chips.
<Bitweasil> (vs MON mode on the ARMv7 chips)
<Bitweasil> Anyway, yes, I know, I'm nuts, doing AArch32 stuff on the ARMv8 chips, but we need to ground truth a few instructions. :/
<clever> i was booting 32bit linux on the pi3 for the longest time, because my 64bit bootloader lacked kexec
<Bitweasil> Linux. Woah. Nosebleed. :p
<clever> so, do you need to replace the stubs and use your own kernel, or can you work stubless?
<Bitweasil> I'm pretty sure I can work stubless, if it'll call me in AArch32 Monitor mode.
<clever> the "stubless" way, actually did have a stub, originally, you had to manually prepend the stub onto your linux build, when making kernel.img
<Bitweasil> If I load myself as armstub=kernel7.img (or whatever), I should get execution at 0x0?
<clever> yeah
<clever> and kernel_old=1 should do the same thing
<Bitweasil> kernel_old=1 was loading me in SVC mode.
<clever> it should load your kernel= to 0 and skip the stub entirely
<Bitweasil> Right, but it was entering in the wrong mode.
<clever> thats weird
<clever> because it shouldnt be able to change modes
<clever> without a stub, you control the first opcode out of reset
<Bitweasil> I know. :/
<Bitweasil> Anyway, that matches what I'm finding, just... weirdness. I'll keep troubleshooting. Thanks!
<clever> Bitweasil: behind the scenes, there is a magic control bit in the arm core
<Bitweasil> Is there a way to say "Only load the armstub, not the kernel"?
<Bitweasil> I'm stomping myself. :/
<clever> Bitweasil: if this control bit is set, the core can boot in aarch64 mode
<clever> you can set a kernel load address, so its higher up
<Bitweasil> ah, kernel_address ?
<clever> yep, thats the one
<Bitweasil> ... and I'm being loaded in SVC mode. :(
<clever> what is your full config.txt content?
<Bitweasil> Random stock crap up top, then:
<Bitweasil> enable_uart=1
<Bitweasil> uart_2ndstage=1
<Bitweasil> dtoverlay=disable-bt
<Bitweasil> arm_64bit=0
<Bitweasil> armstub=kernel7.img
<Bitweasil> kernel_address=0x1000000
<Bitweasil> It's loading me at 0x0, and I get execution, just CSPR isn't what I expect.
<Bitweasil> CPSR
<clever> what does kernel7.img contain? what is output on the serial?
<Bitweasil> It's my own stuff.
<Bitweasil> I get my initial serial output after the "gpioman" line from the second stage.
<clever> can you paste the source somewhere? and the full uart logs?
<Bitweasil> But if I use the stock armstub, I end up in HYP mode.
<Bitweasil> ... not the slightest bit easily, sorry.
<Bitweasil> I should print my own execution address, just to see where I actually am.
<Bitweasil> Work project. :/
<Bitweasil> But this is helpful, it helps sort out what is going on.
<Bitweasil> I just don't get how I'm in SVC mode in what ought be the armstub. :/
<clever> are you initializing the stacks for every other mode?
<Bitweasil> No, because I didn't have permissions to msr them over from SVC mode.
<clever> you normally do
<Bitweasil> Actually, maybe that was troubleshooting.
<clever> svc and irq have access
<Bitweasil> I shouldn't be taking abort/undefined/etc.
<Bitweasil> Not sp_mon and sp_hyp
<clever> this code will save the current mode, switch to irq, setup sp, switch to svc, setup irq, then restore the previous mode
<clever> and if you do anything with cpsr, you might taint the results
<clever> read the decompile, rather then the source
<Bitweasil> _nods_ Well, I'm just reading it, on initial reporting.
<Bitweasil> Anyway, getting into hyp mode is probably fine, just not what my code was planning on initially.
<Bitweasil> This isn't an actual end product goal, just... "to test some stuff out."
<Bitweasil> So I honestly don't care if it's as I hoped, as long as it does what I need. We need ground truth on a few instructions.
<clever> ive had the reverse issue, the kernel i was using assumed it enters in SVC mode
<clever> so it sets up the SVC mmu, then enables the mmu in the current mode
<clever> RPF changed things to enter in HYP :P
<Bitweasil> Which doesn't work if you... yeah.
<clever> that took days to figure out