<eliasbakken>
apritzel: Thank you, that's the one place I've not looked. I'll check the TF-A.
Asara_ has joined #linux-sunxi
Asara has quit [Read error: Connection reset by peer]
<eliasbakken>
It looks like TF-A is not used in this ancient build. Is the boot0 binary a likely culprit for loading the scp? It looks to packaged with u-boot somehow.
<eliasbakken>
There is a file called monitor.fex.. which has several strings related to SCP in the binary, so that must be it. I'm getting this from the Orange pi build repository. Not sure how those binaries are made though.
<apritzel>
eliasbakken: don't waste too much time with this crap, it quite often doesn't make much sense
<apritzel>
Syterkit seems to be halfway sane: you find the binary for BL31 and SCP in the Syterkit github repo
<apritzel>
I guess you are just after that (ideally) one register to release the ARISC from reset?
<apritzel>
but keep in mind that we have enough of TF-A and U-Boot now to no longer any of the BSP firmware bits - minus the SCP maybe
<apritzel>
no longer need*
<apritzel>
so looking at the BSP is OK, but please don't contribute to or proliferate any of that, instead look at mainline bits
Asara_ is now known as Asara
<eliasbakken>
Right now, I'm mostly interested in trying to load my own ARSIC binaries, yes, so I need that register. I was hoping to find it somewhere in code, but perhaps looking through the binaries is the only way still?
apritzel has quit [Ping timeout: 480 seconds]
flyback has quit [Ping timeout: 480 seconds]
flyback has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
parthiban has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<loki666>
apritzel: thanks I'll try to reparent the GPU as done for CPU... Which PLL_PERI should I use ?
szemzoa has quit [Ping timeout: 480 seconds]
szemzoa_ is now known as szemzoa
szemzoa_ has joined #linux-sunxi
szemzoa_ has quit [Ping timeout: 480 seconds]
szemzoa_ has joined #linux-sunxi
szemzoa_ has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
szemzoa_ has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<apritzel>
loki666: you don't have any real choice, do you? The only other parent for GPU_CLK0 is GPU_CLK1, which is PLL_PERIPH0/m
<apritzel>
PLL_PERIPH(2x)/(m+1), to be precise, so you should also program m to at least 2, in the probe routine
eeschalier has joined #linux-sunxi
szemzoa_ has quit [Read error: Connection reset by peer]
szemzoa_ has joined #linux-sunxi
<eeschalier>
Hi! I have a Lichee RV Dock (Allwinner Nezha) that I'm trying to do bare metal programming on. I am currently trying to figure out how to write a boot0 binary, and I'm confused about the eGON.BT0 header. I looked through https://github.com/smaeul/sun20i_d1_spl earlier, and saw a great many fields in the boot0 header whose use is unclear to me, so I wanted to check if there was a better source of documentation on this.
<eeschalier>
It's also unclear to me which of those are actually used by the BROM beyond the initial jump instruction, magic string, checksum, and length.
<eeschalier>
Additionally, are there any foundational facilities (besides the DRAM controller) that need to be initialized by the boot0? I have experience with bare metal (on ARM), but not specifically with this kind of very-low-level boot process, so I'm worried there's some critical thing I might get bitten by.
f_ has joined #linux-sunxi
<apritzel>
eeschalier: the eGON header can be really minimal, you just need the first 20 bytes or so, I think
<apritzel>
so jump instruction, 8 byte magic, checksum, length
<apritzel>
U-Boot's mkimage can put that header in front of a binary you give it
<apritzel>
I think it expects the link address of that binary to be load_addr + 0x60
<apritzel>
as for the initial setup: the BROM does quite a lot already (bus clocks, etc), but you would need to initialise the UART
<eeschalier>
apritzel: Amazing! That's already just about the best case I can think of.
<apritzel>
look at sunxi-tools uart0-helloworld-sdboot.c, for instnace
<apritzel>
that covers all Allwinner SoCs, so it's more involved than you would need for a single board
<apritzel>
for the UART it's just: pinmux plus UART_BGR_REG in the clock
<eeschalier>
Another thing I'm a little confused about is where the BROM is loading the BOOT0 to. The uart0-helloworld-sdboot.lds seems to use 0x0 as the start of everything, but I thought that was where the BROM loaded to?
<apritzel>
uart0-helloworld-sdboot is position independent, as the load address differs between the SoCs
<apritzel>
typically it's SRAM A1, I guess 0x20000 in your case, but in the latest SoCs they changed that. Sigh.
<eeschalier>
Thank you so much for your help! I'll go try and get that going.
<eliasbakken>
jernej: I've been looking at the bl31.bin from Syterkit (Avaota A1 board) in Radare2, but I'm not that skilled with reverse engineering that I can get anything from it yet. So any help with that would be great!
<jernej>
eliasbakken: so, if you set base address at 0x48000000, arisc setup function will be at 0x4800b264
<jernej>
eliasbakken: long story short, it seems that start address is stored to 0x709010c and then run by setting bit 0 at 0x7050000
<gamiee>
eliasbakken : want to port recore to A526? :o
<jernej>
bl31.bin also clears dcache lines when loading arisc firmware
<eliasbakken>
Yes, looking at a T527 version gamiee
<jernej>
apritzel: do you know if BSP boot0 or TF-A enable data cache? I thought it is disabled at that stage...
<eliasbakken>
jernej, what is the start address used for? The program runs from SRAM A2 no?
<gamiee>
eliasbakken : oh very cool!
<jernej>
eliasbakken: seems you have some flexibility where to put it exactly
<jernej>
but SRAM A2 seems the best candidate to me
<eliasbakken>
Right, are there other SRAMs available? I'm looking to do a comparison between the ARSIC, the RISCV and the DSP to see what would be the best performer for real time stuff. Thought I'd start with the ARSIC, since Klipper is already ported to that.
<jernej>
I suspect best performer will be RISC-V core
<gamiee>
just wanted to say that. I think it will be better to use RISC-V core.
<eliasbakken>
It's only 200 MHz tho, but probably much more efficient. Should be interesting to see the predictability as well. The DSP is 600 MHz and Xtensa, so should be a fun candidate.
<jernej>
arisc doesn't come close to either afaik
<jernej>
but then again, do you really need such high speeds if it worked on arisc before?
<eliasbakken>
Probably not, but some of those printers are really pushing the limits on speed.
<eliasbakken>
So 0x709010c=0x0000B00F, and 0x7050000 is 0x1. The latter looks like it can be set to 0 without any consequences.
<eliasbakken>
So those addresses might be right. The 0xB00F offset, is that from 0x40000? (SRAM A2?)
<jernej>
i believe they should be absolute
<jernej>
although I don't know, I don't have much experience with arisc
<jernej>
hint, radxa bsp has arisc linker script and some (partial?) sources
<eliasbakken>
Absolute 0xB00F is not documented. It would be between S_BROM and M_BROM
<eliasbakken>
Oh.. is it not 0x40000 as pr the A527 manual?
<eliasbakken>
No wait, the offset of the A2 is not specified I think.
<jernej>
yeah, most likely different memory map
<jernej>
eliasbakken: sorry, I missed the obvious in bl31.bin: flush_dcache_range(0x40000,0x24000); so yeah, arisc address 0 maps to 0x40000
<jernej>
and size perfectly aligns to memory map above
apritzel__ has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
<apritzel>
jernej: I don't know about boot0, but TF-A quite surely enabled the D$
<jernej>
ah, then it makes sense, thanks
<apritzel>
it definitely enables the MMU, since it needs that to separate .rodata, .data and .text
<apritzel>
and I think some atomics/exclusive accesses (as used in locks) require cacheable memory
wingrime-ww has quit [Ping timeout: 480 seconds]
<apritzel>
and I think we should map out the DRAM usage between all the cores involved, to avoid disappointment and incompatibilities
<apritzel>
I think SRAM A2 should be ARISC/SPL, IIUC the DSP and RISC-V have ample SRAM of their own, higher up?
<eliasbakken>
Has anyone tried running their own code on the arsic? Should be useful for Crust at least.
<apritzel>
eliasbakken: do you mean on the T527?
<eliasbakken>
Yes
<apritzel>
I don't think so, but since it's there, we should definitely reserve the ARISC and SRAM A2 for crust
<apritzel>
sounds like the most reasonable scenario to me, crust would just need to be ported to that SoC, which should not be too hard
<apritzel>
then we can just piggy back on all the existing code
<jernej>
yeah, I agree
<apritzel>
that doesn't prevent anyone from overwriting or replacing crust, of course, but for the generic mainline deployment I would like to make this the common case
<apritzel>
if people want extra compute: this is where RISC-V can make itself useful ;-)
<apritzel>
this actually makes szemzoa's remoteproc driver a lot more interesting
<apritzel>
eliasbakken: so for any kind of experiments: sure, use the ARISC, but please don't count on it for wider deployment
<apritzel>
what are the reservations against using the RISC-V for realtime purposes? To much power consumption? Is that really a concern, in a 3D printer scenario?
<apritzel>
or is that that clipper already has a working OR100 port?
<eliasbakken>
The latter.
<apritzel>
is it written in assembly? If not, a port would be easy, since it's the same peripherals, just a different memory map?
<apritzel>
(minus interrupt handling, I suppose)
<eliasbakken>
I'm just testing out some stuff for now. I'm just about finished with the hardware, so I thought I'd test all possibilities regarding real time CPUs. It would be great to have something working out of the box more or less, and then work on what ever makes sense as a second step.
<eliasbakken>
Just about all is in C. Not much interrupt to talk about actually, since it's a pretty simple part that mostly toggles gpio.
<apritzel>
testing is perfectly fine, I just want to avoid that users need to decide between realtime offload and power management, because both use the ARISC
<apritzel>
and realtime code deployed via a mainline remoteproc driver, for a mainstream architecture, sounds much more sustainable
<eliasbakken>
Right, that is a bit of an issue regarding the double use. A 3D printer is not that sensitive when it comes to power usage though, so that has been my reasoning for doing it that way on the A64.
<apritzel>
I meant that people want to use the ARISC because it uses less power than the RISC-V core, but as you say, that's probably a moot issue
<eliasbakken>
It would be nice to be more in line with the rest of mainline, so the RISCV is probably the best choice.
<apritzel>
yes, as you probably know, OpenRISC is not really the newest and best supported architecture out there
<eliasbakken>
Not at all, but it does run Klipper, hehe.
<apritzel>
plus the extra Allwinner quirk of requiring the image to be byte-swapped ...
<MasterR3C0RD>
eliasbakken: Just took a look at your prior work; the fact you got Klipper on the A64 ARISC is really cool
<gamiee>
Recore is just great, I love that project.
<apritzel>
are you telling me that Klipper doesn't run on everybody's favourite free architecture?
apritzel has quit [Remote host closed the connection]
<eliasbakken>
Yeah, it was a great learning experience too.
apritzel has joined #linux-sunxi
<MasterR3C0RD>
apritzel: It doesn't appear anyone's bothered to port it yet; most control boards tend to use a STM32
<eliasbakken>
jernej, how did you find the registers in the bl31.bin file? Ghidra?
<jernej>
yes
<eliasbakken>
Ok, thanks, I'll try the same. I might have gotten my gpio toggle program to load, but I'm not certain it's running. No output on the gpios.
apritzel has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
apritzel has quit [Read error: Connection reset by peer]
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
apritzel has joined #linux-sunxi
<eliasbakken>
Yas! A beautiful square wave on the oscilloscope generated by the arisc CPU :D