<courmisch>
K230 has SPL load U-boot (presumably in M mode)
<courmisch>
and then U-boot boots SBI which contains Linux
* courmisch
cries
<drewfustini>
Ah, that is fw_payload where the SBI build contains the Linux build
<courmisch>
yes
<courmisch>
very inconvenient if you want to recompile the kernel
<drewfustini>
yeah
<drewfustini>
fw_dynamic is more convenient in that case
<courmisch>
is that U-boot loading both SBI and kernel separately and SBI "somehow" finding the kernel in memory?
<drewfustini>
In case of fw_payload, U-boot spl wouldjust jump to OpenSBI and OpenSBI would know that the kernel is embedded in it's binary and know where to find it
<Esmil>
drewfustini: yes, that sounds right
stylefish has quit [Quit: stylefish]
solol has joined #riscv
<courmisch>
drewfustini: yes, I mean fw_dynamic
<solol>
what's up
<courmisch>
trying to get a sane boot flow on the K230, and seems it was not such a great idea
davidlt has quit [Ping timeout: 264 seconds]
<courmisch>
well at least I can compile a working boot without installing a VM and compiling buildroot
<drewfustini>
Esmil: thanks, so the DMA-capable peripheral then is using the 0xfa000000 range (cached) since those are is lower memory? I suppose cached doesn't matter for the peripheral since its DMA access doesn't go through a CPU cache? And then the kernel is using the 0x10_7a00_0000 uncached alias for those buffers so the CPU load/store bypasses the cache. Does that sound right?
<unlord>
courmisch: I've been offline a few days, what is the problem with the SDK boot flow?/
<courmisch>
unlord: are *you* asking me what's wrong with the SDK?
<drewfustini>
I have an unusually organized SoC where I need to do something similar and this is a great example. I had been wanting to hack the driver to progress the cached address in to the DMA-capable peripheral meanwhile the CPU would only be accessing the uncached address. I see now that dma-ranges is the solution for that
<drewfustini>
the tricky bit is that all memory is above 512GB so its been making everything more difficult
stolen has quit [Quit: Connection closed for inactivity]
<Esmil>
drewfustini: yeah, unfortunately this solution means the JH7100 needs the CONFIG_DMA_GLOBAL pool so all coherent dma memory is allocated from this range, but as you know from the TH1520 CONFIG_DMA_GLOBAL breaks other ways of allocating dma memory. so hopefully you won't need that
<drewfustini>
thanks... this has been a useful example. I'm really only trying to get one DMA-capable peripheral to work on the system I'm working on so this might do the trick.
<smaeul>
didn't you have a solution that used arch_set_dma_uncached() to avoid the global pool?
<Esmil>
smaeul: no, unfortunately it was a bit of a hack that would break in certain configurations :/
<unlord>
I'm debating if I want to go down this rabbit hole any further
<smaeul>
with fw_dynamic, SPL fills out a structure that tells OpenSBI where to find U-Boot
<courmisch>
smaeul: as I understand it, U-boot proper won't do that though, only SPL
<smaeul>
why is that a problem?
<courmisch>
because the current flow is SPL -> Uboot -> SBI -> Linux
<smaeul>
you can reconfigure U-Boot proper to run in S-mode, no?
<courmisch>
and inverting Uboot/SBI sounds like a whole new can of worms
<smaeul>
if you don't want SPL to load two images and use fw_dynamic, you can use fw_payload and embed U-Boot proper (built for S-mode) inside the OpenSBI image
<courmisch>
I would be somewhat surprised if vendor Uboot that was meant to run in M mode nicely ran in S mode
cousteau has joined #riscv
<smaeul>
one easy way to find out :)
<courmisch>
define "easy"... I don't have a JTAG, and in fact I don't think the board even has the pins for it if I had a JTAG
<courmisch>
so debugging is meh
<smaeul>
try the U-Boot-inside-fw_payload from the current boot flow -- it won't hurt to run through U-Boot twice
<smaeul>
if it doesn't crash with a illegal instruction or access fault exception, then it doesn't need M-mode
luna has joined #riscv
<courmisch>
I'm not familiar with the privileged ISA... is there even something like a CurrentEL register on RISC-V ?
<courmisch>
oh well. To be continued.
<courmisch>
thanks
vagrantc has quit [Quit: leaving]
<palmer>
courmisch: there's bits in {m,s}status, you'd probably need to synthesize exactly the same register (assuming that's arm)
<jrtc27>
CurrentEL deliberately doesn't exist
<jrtc27>
or something like that
<jrtc27>
of course M vs S is pretty leaky
<jrtc27>
I think the idea was more to avoid leaking H vs S back when that was the design rather than HS vs VS
<jrtc27>
for the debugger there's a virtual mprv register
luna has left #riscv [#riscv]
jmdaemon has joined #riscv
luxcid has joined #riscv
luxcid has quit [Read error: Connection reset by peer]
danilogondolfo has quit [Quit: Leaving]
BootLayer has quit [Read error: Connection reset by peer]
solol has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
agent314 has joined #riscv
khem has quit [Quit: Connection closed for inactivity]