<jernej>
apritzel: I found macros in T527 BSP, which explain some things: SRAM A1 and SRAM A3 part 3 are for HIFI4 DSP, while SRAM A3 part 1 and 2 are for RISC-V.
igraltist has quit [Remote host closed the connection]
igraltist has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
junari: ah, those tablets indeed look better. I wouldn't really recommend the P50AI - as a tablet:
<apritzel>
spec wise it's not too bad (two USB-C, DP-over-USB-C, 11" screen, 6GB RAM), but the screen is only 1280x800, and looks pretty bad
<apritzel>
also it feels really slow and lagging, for instance the virtual keyboard sounds have a noticeable delay, and it does not feel snappy at all, even when just swiping the home screen
<apritzel>
and even though I just bought it to have early access to the SoC, I was hoping for having some modern(ish) tablet as plan B, which doesn't really feel like it
<apritzel>
jernej: oh, very nice finds, that's helpful!
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<jernej>
yeah, I just want to clarify things so we don't do something silly :)
<jernej>
I still can't find Cedrus and Display Engine SRAMs
<apritzel>
do you think we could live with a 64K SPL limit?
<jernej>
sure, why not?
<jernej>
current 64-bit SPL I have is about 33 KB
<jernej>
as I said, worst thing we had to do is relocation. In such case SPL and TF-A can have full 128 KB :)
arti has quit [Ping timeout: 480 seconds]
arti has joined #linux-sunxi
<apritzel>
right, so then I'd say: SPL load at 0x44000 (that's a BROM constant for MMC anyways), early SPL stack at same address (growing downwards), TF-A load address at 0x54000-0x64000
<apritzel>
SCP_SIZE can be zero, since that firmware will use a different region
<jernej>
works for me
<apritzel>
that gives us 64K for TF-A, which is not plenty, but we can use the upper SPL area at runtime, for instance for the page tables
<apritzel>
A64 only has 48K (since it needs to share 64K of SRAM A2 with crust), and this limit is a constant pain
<apritzel>
64K should be OK, just hoping we don't need much more code, for GICv3, A55, and dual cluster
<jernej>
well, you also have 16 KB in lower SRAM A2 region
<jernej>
hm, or will be this also used as TF-A stack?
nashpa has joined #linux-sunxi
codekipper0 has joined #linux-sunxi
codekipper0 is now known as codekipper
<apritzel>
the problem is code+data, as in the image, not so much runtime memory
<apritzel>
for the A64 we also use SRAM A1 already for stack, page tables and BSS, but TF-A is not very frugal with memory, and everything needs to page aligned and page sized
<apritzel>
for H6 (which has 0x14000 of available SRAMspace)
dliviu has quit [Ping timeout: 480 seconds]
<codekipper>
jernej, apritzel: Hi Guys, what magic is needed to build u-boot for the x96qpro+?, I'm having a issue with it not finding the sunxi-spl.bin....am I jumping the gun with your repos?
<apritzel>
jernej: ... *SRAM A2 space, we use 0xc000 for code and 0x5000 for data, so that's already exceeding 64K
<apritzel>
codekipper: that's work in progress, though it really comes together in the last few days
<apritzel>
codekipper: my github branch is U-Boot proper only atm, but I integrated jernej's DRAM and SPL code yesterday into that, so it works under lab conditions
Schimsalabim has quit [Read error: Connection reset by peer]
<apritzel>
codekipper: no TF-A yet, so no SMP, but jernej is working on that
<codekipper>
Ok....so it's in good hands then.
kepstin has quit [Remote host closed the connection]
Schimsalabim has joined #linux-sunxi
<apritzel>
codekipper: yeah, we will hopefully post something in the next days or weeks
kepstin has joined #linux-sunxi
<apritzel>
codekipper: there is plenty of work left on the Linux side, though, if you want to join us
<apritzel>
Ethernet looks not too far out, maybe it's just a clock missing. warpme has this running by adopting the *%&$%& BSP driver, so you could compare this to mainline
<codekipper>
I need jernej to whip me into shape....I've built the kernel side using warpme's patches but I usually netboot everything so getting uboot working for me is my next steo.
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
codekipper: USB works for me in U-Boot (the USB 2.0 side is compatible to the D1), so I use and USB Ethernet adaptor
<apritzel>
I think jernej's branch should work if you import the proper DT and enable USB in the defconfig
<codekipper>
do you have a bin you can share?....I can also have a go at playing with jernej's commits
<jernej>
codekipper: welcome back :)
<apritzel>
codekipper: jernej's code is actually one commit in his repo, but I have patches cooking to split this up
<apritzel>
codekipper: I can send you a bin for now, sure
<jernej>
I'm cosidering if I should go cleanup my U-Boot code or do TF-A first
<codekipper>
I've never really gone away just lurked on irclog
<codekipper>
apritzel: thanks...you're a star
<jernej>
codekipper: you need apritzel SPL since my code is missing DDR3 init
<apritzel>
jernej: I am about to clean up the SPL code, so don't worry about it
<jernej>
ah, great!
<apritzel>
I had a separate SPL branch before, though it didn't work as well as yours, so I am trying to combine both, and make it all clean
<apritzel>
I think the Syterkit sequence to be probably a good reference, when it comes about which bits to tickle
<jernej>
apritzel: while you're there, please add NSI init code from Systerkit to DRAM, this replaces MBUS init from before
<apritzel>
(though the Syterkit code and design is not very good otherwise, I must say)
<apritzel>
jernej: is that NSI init something that should be done in TF-A, or is it too late there
<apritzel>
I have that snippet in the SPL atm, but haven't checked if it's necessary
<codekipper>
what repos are needed to build the bin?....u-boot, TF-A and something else?
<apritzel>
I saw the BSP/Syterkit doing it in BL31?
<jernej>
as I said, this replaces MBUS setup, so best to keep it as before?
<jernej>
it will also lower TF-A size :)
<apritzel>
codekipper: there is no TF-A repo as of now, so I just use a two-instruction trampoline to make the U-Boot build system happy
<codekipper>
OK...is there any equivalent to crust?
<jernej>
apritzel: also, I have to improve DRAM code, but it's better to do on top of your cleaned up branch
<jernej>
codekipper: I believe RISC-V core can be used for that
<apritzel>
codekipper, no nothing yet, and the MCU is RISC-V now, so crust would need some preparations for that
<jernej>
although with 600 MHz isn't as efficient as OpenRISC on 32 kHz
<codekipper>
OK...I see that warpme is including bin files in his bootloader and I was wondering where they came from.
<apritzel>
codekipper: warpme is using Syterkit as a firmware base, so he uses the vendor provided binary TF-A and management core code
dliviu has joined #linux-sunxi
<apritzel>
TF-A is somewhat essential, for SMP operation, but crust would be highly optional, especially on a TV box
<codekipper>
I do appreciate his tinkering.....he does find ways to get over hurdles
<apritzel>
you would eventually gain suspend-to-RAM with crust, but that's quite some way out, and just "freeze" suspend and wakeup with the power button works already (thanks to loki666's patch!)
<jernej>
apritzel: did you check scp.bin? it's suspiciously similar to older OpenRISC binaries with endianess reversal...
<jernej>
apritzel: has someone figure out how scp.bin gets used on BSP? does TF-A need it?
nashpa has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
<jernej>
apritzel: looking at bl31.bin from Systerkit, there is indeed arisc core :)
<jernej>
apritzel: guess what? code is put in SRAM A2 :)
<jernej>
gamiee: rule of thumb - if you see scp.bin in BSP and strings in it are mangled, it has AR100
<gamiee>
jernej : ohh, good to know!
<apritzel>
jernej: ah, was it that the bus does the endianess conversion?
digetx has joined #linux-sunxi
<jernej>
apritzel: yes, openrisc is big endian
<apritzel>
sure, but then strings wouldn't need to be mangled. But since they expect communication between the ARM and arisc, I think they included a endianess conversion in hardware
<apritzel>
so that any number written as bigendian ends up as little endian in the actual memory?
<apritzel>
(and vice versa on the read back, so it's transparent to the arisc code)
<jernej>
to be honest I don't know details why they choose to do it that way
<apritzel>
I just dimly remember that the compiler output needed to be processed in some way, because the image file is actually little endian, as it's supposed to be written by the ARM cores
<apritzel>
anyway, good find, but now brings an annoying problem about *everyone* wanting into SRAM A2, including the SPL
<apritzel>
jernej: I guess what you suggested lately seems more promising now: let the TF-A code be loaded somewhere else, and then let it relocate itself to the beginning of SRAM A2
<jernej>
I just wanted to say that ;)
<jernej>
however, first take on TF-A will be without it
<apritzel>
sure, we have bigger fish to fry
<apritzel>
but we will need to address this before we push it into the repos, as this then creates nasty incompatibilities between firmware builds (the load address depends on the TF-A build, but is hardcoded in the SPL)
<apritzel>
but for a proof of concept and initial development this indeed does not matter
<jernej>
sure, first I want to have something that works, so we can figure best way how to put together this puzzle
BroderTuck has joined #linux-sunxi
<BroderTuck>
Lots of interesting stuff being discussed
<apritzel>
jernej: agreed!
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
junari has quit [Remote host closed the connection]
<jernej>
I haven't tried to boot linux as I don't have it set up
<BroderTuck>
I started out by having usd card with boot and root partitions, but with that special fel-booting spl code on sector 16
apritzel has joined #linux-sunxi
<BroderTuck>
jernej: Took a quick look at the code, didn't see anything obviously wrong (but then, that doesn't really mean much). Mostly surprised at how small the changes are.
<jernej>
yeah, I'm surprised too. It also worked on second try...
<apritzel>
swiftgeek: you can do this on the fly, in U-Boot, with the fdt command
<swiftgeek>
oh so it's merged, but only on relatively new kernels I guess?
<apritzel>
to be clear: the kernel recognises mmc aliases for a while, we just don't want them in the official DTs
<apritzel>
swiftgeek: define "relatively new"
<apritzel>
I'd say for a few years?
<apritzel>
swiftgeek: if you use U-Boot's DTB, by using "$fdtcontroladdr" instead of loading something to $fdt_addr_r, you get the aliases for free, since U-Boot adds them
<swiftgeek>
I would need to find the patch that made it happen then
<apritzel>
swiftgeek: why?
<apritzel>
are you running that old kernels? If yes, why?
<apritzel>
I'd say fa2d0aa96941e8dc347e49a04c75468e3002ee20 ?
<swiftgeek>
yeah running old kernels, and I just want to test those setups more easily, instead of using eMMC when I need to test them
<apritzel>
Linux v5.10
<swiftgeek>
so with that change I could more easily test old/vendor setups with just a tiny modification of DT
<apritzel>
hacking a firmware table sounds like not the right solution for this?
<apritzel>
but whatever: if you have at least v5.10, it should work
<swiftgeek>
there is a lot to change otherwise in vendor setups, so one place to change it all helps a lot
<swiftgeek>
and not everything has sources, so yeah
<swiftgeek>
but if I can make some silly setup like that, then I can have special SD card for running/tracing "that one special command" of whatever issue I'm having at a time and maybe I will be able to troubleshoot faster
<swiftgeek>
otherwise I just don't don't want touch eMMC, and I ignore the issue
<apritzel>
so you have /dev/mmcblk0 (or /dev/mmcblk1) hardcoded somewhere, and want that to point to either the SD card, or the eMMC?
<swiftgeek>
apritzel: anyway thank you for digging out the patch, thanks to that I can now test my idea on proper distro, and I will try my luck with spoofing as much as possible
<swiftgeek>
yep
<swiftgeek>
though it goes likely a bit deeper than that
<apritzel>
what about getting rid of the hardcoding, and using root=UUID=.... or root=LABEL=MySDroot or such, like distros do for more than a decade now?
<swiftgeek>
nah, that's just for running old vendor build for testing, just to run random command of the day
<swiftgeek>
trace that, and port it over to something sane
<swiftgeek>
and then there are distros that refuse to let go of hardcoding and I can't do anything about that
<apritzel>
sorry to hear that ;-)
<swiftgeek>
there is also some symlink action I can't quite grasp yet, maybe I just need to test things
<apritzel>
[ 0.156549] psci: failed to boot CPU1 (-22)
<apritzel>
(and the others as well)
<apritzel>
but it built and booted fine, so kudos for that
<swiftgeek>
oh, "of_node" is literally symlink of that name
<swiftgeek>
though incidentally, people seem to use it to create device symlinks from udev
<apritzel>
jernej I wonder if it's about the different MPIDR assignment: Cortex A53s typically (or always?) have the core number in Aff0, so the lowest byte
<apritzel>
A55s and later use Aff1 for that, so core 1 is 0x100, core 2 0x200
<apritzel>
I think the sunxi implementation needs to take that into account
<apritzel>
bah, why am I typing here, let me hack that up ;-)
ftg has quit [Read error: Connection reset by peer]