<apritzel>
smaeul: the patch after this probably explains better why
<smaeul>
oh, it makes total sense. that's much better than the extern structs
<apritzel>
and it's WIP, I just fixed your easy comments on the other patches, so it's not ready yet (but works)
<apritzel>
smaeul: the external structs made total sense in your patch, until you need to compile them conditionally, and realise the subtleties between struct and pointer to struct ;-)
<smaeul>
apritzel: what do you think of `const plat_psci_ops_t *sunxi_get_scpi_psci_ops(void)` ?
<smaeul>
to turn two conditional functions into one
<apritzel>
smaeul: feel free to massage this, for instance I wonder if is_scpi_available() can do the assignment already
<apritzel>
as long as the idea works in the next patch (which is open for debate as well, not very seasoned in Makefile hacks)
<smaeul>
ok, I'll see how it looks when I clean up my existing patches
<apritzel>
smaeul: cool, thanks
apritzel has quit [Ping timeout: 240 seconds]
montjoie has quit [Ping timeout: 246 seconds]
kaspter has joined #linux-sunxi
kaspter has quit [Excess Flood]
montjoie has joined #linux-sunxi
kaspter has joined #linux-sunxi
<wens>
are we using SCPI now?
camus1 has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
camus1 is now known as kaspter
TheSeven has quit [Ping timeout: 264 seconds]
TheSeven has joined #linux-sunxi
tuxd3v has quit [Quit: Leaving]
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 272 seconds]
<gediz0x539>
mornin'
ChriChri_ is now known as ChriChri
<gediz0x539>
i got a warning on file upload page of wiki, fyi
<gediz0x539>
Warning: hash_equals(): Expected user_string to be a string, NULL given in /srv/http/sunxi/linux-sunxi.org/wiki/includes/GlobalFunctions.php on line 143
chewitt has quit [Quit: Zzz..]
dev1990_ has quit [Ping timeout: 260 seconds]
lurchi__ is now known as lurchi_
lurchi_ has quit [Ping timeout: 264 seconds]
tuxd3v has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
daregap has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
reinforce has joined #linux-sunxi
gediz0x539 has quit [Quit: Leaving]
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 264 seconds]
camus1 is now known as kaspter
AneoX has joined #linux-sunxi
cnxsoft1 has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
asdf28 has joined #linux-sunxi
apritzel has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
apritzel has quit [Ping timeout: 256 seconds]
luke-jr has quit [Remote host closed the connection]
<rellla>
is it ok from a legal point of view to remove the watermark and have the files in our wiki at all?
<rellla>
just a general question. though i'm not sure, if it's ok to have files marked as confidential in the wiki at all
bauen1 has quit [Ping timeout: 272 seconds]
bauen1 has joined #linux-sunxi
apritzel has joined #linux-sunxi
fl__0 has joined #linux-sunxi
fl_0 has quit [Ping timeout: 246 seconds]
fl__0 is now known as fl_0
AneoX has quit [Ping timeout: 256 seconds]
AneoX has joined #linux-sunxi
sunshavi has quit [Ping timeout: 260 seconds]
AneoX has quit [Ping timeout: 256 seconds]
AneoX has joined #linux-sunxi
AneoX has quit [Ping timeout: 264 seconds]
AneoX has joined #linux-sunxi
<apritzel>
wens: SCPI is used as a communication protocol between Trusted Firmware and crust
<apritzel>
wens: this "native" vs. "SCPI" in the discussion above is about Trusted Firmware checking at runtime whether crust is loaded, and using it, or using the original methods for turning off cores
* karlp
is only used to ascii control instrument usage of SCPI, what's scpi here like?
<karlp>
ieee488.2 stuff doesn't seem like what you'd reuse for comms between trusted firmware and crust?
AneoX has quit [Ping timeout: 246 seconds]
<apritzel>
wens: so far we always support both ways, and decide at runtime, but without the ARISC crust won't run on the H616, so we want to compile this out
<apritzel>
karlp: google for "ARM SCPI": SCPI stands for SCP interface, and SCP stands for System Control Processor
AneoX has joined #linux-sunxi
<apritzel>
karlp: so it's a standardised interface how to speak to a management processor and ask for things like CPU, power and clock management
<karlp>
thanks,
hlauer has joined #linux-sunxi
kaspter has quit [Ping timeout: 264 seconds]
<hlauer>
hello, just send the rgmii->rgmii-id patch for banana pro to linux-arm-kernel@lists.infradead.org - is this the right list?
kaspter has joined #linux-sunxi
gediz0x539 has joined #linux-sunxi
<apritzel>
hlauer: "scripts/get_maintainer.pl <patchfile>" gives you an indication who to send a patch to
<apritzel>
hlauer: so LAKML is the right list, as long as you have the maintainers (mripard, wens) and reviewers (jernej) in as well
<hlauer>
thx, will resend with the mentioned cc's added
minicom7 is now known as minicom
warpme_ has joined #linux-sunxi
<mru>
karlp: 488.2 is not something I'd reuse for anything whatsoever
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
<karlp>
which is why I was surprised :)
<karlp>
and wanted to check it was something else :)
<mru>
it's annoying enough for the intended purpose
<mru>
and the implementation in my tektronix scope is slightly buggy
<karlp>
most of them are all a little bit quirky
<mru>
still nice for taking the tedium out of making a series of measurements
<mru>
one thing that annoys me about the protocol is the lack of ack/error response to commands
<mru>
even modems can do that
AneoX has quit [Read error: Connection reset by peer]
lurchi__ has quit [Remote host closed the connection]
hlauer has quit [Read error: Connection reset by peer]
lurchi__ has joined #linux-sunxi
gediz0x539 has quit [Ping timeout: 256 seconds]
mirko has quit [Ping timeout: 256 seconds]
mirko has joined #linux-sunxi
hlauer has joined #linux-sunxi
toaster has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
toaster has quit [Quit: Ping timeout (120 seconds)]
atsampson has quit [Quit: that amdgpu black screen bug? yes, that one]
atsampson has joined #linux-sunxi
toaster has joined #linux-sunxi
<jernej>
apritzel: I'm doing some netbooting and it seems there is some regression in U-Boot v2021.01 and newer, at least for H3
<jernej>
I'm doing completely storageless boots - FEL boot U-Boot and tftp boot kernel + initramfs
<jernej>
with v2020.10 there is no issues, but with v2021.01, serial output finishes at "Starting kernel ..."
<jernej>
everything is the same, except U-Boot
<jernej>
any clue what could be wrong?
<mru>
same kernel build?
<jernej>
of course
<apritzel>
jernej: mmh, so I tested what I pushed on my OPi Zero, with TFTP in U-Boot, but didn't actually boot a kernel (bah, 32-bit kernels ...)
<mru>
git bisect is your friend
<apritzel>
and FEL + TFTP (kernel + initrd) is what I usually use as well
<jernej>
sure, but before I go down that route maybe someone already find the issue...
<apritzel>
jernej: did you check the TFTPed data with md5sum
<jernej>
no, I use PXE
<apritzel>
jernej: mmh, wait, I just remember something with U-Boot moving stuff around
<jernej>
so everything is pretty much automatic
<apritzel>
for instance the initrd got copied, for no good reason actually
<apritzel>
due to this stupid initrd_high mechanism
<apritzel>
jernej: do you see something printed by U-Boot in this regard?
<jernej>
let me ceck
<jernej>
*check
<apritzel>
jernej: => tftpboot $ramdisk_addr_r busybox.initrd.gz ... Load address: 0x4fe00000 .... booti .... Loading Ramdisk to 49cfc000, end 49ffffff ... OK
<apritzel>
this is for arm64, where there is virtually no need to move anything, but even for ARM32 we don't typically need to move with the default ramdisk_addr_r
<apritzel>
and I think I now remember that I indeed had issues when testing my BPi Berry lately
<apritzel>
jernej: yeah, as a quick check, try setting initrd_high=0xffffffff
<apritzel>
that should prevent U-Boot from moving the ramdisk
<jernej>
where? :)
<jernej>
I guess I need to hack sunxi-common.h
<apritzel>
on the U-Boot command line
<apritzel>
setenv
<jernej>
as I said, pxe
<jernej>
I hate scripts
<apritzel>
well, you should be able to stop the timeout, set the variable, then continue with "boot"?
<jernej>
ah, true
<apritzel>
those hacks and relocations come from the U-Boot dawn of time, I think they are mostly obsolete these days
<jernej>
give me few minutes to finish something else
<jernej>
apritzel: no change with "setenv initrd_high 0xffffffff"
<jernej>
otherwise v2021.01 works fine if pxe boot from SD is used instead
<jernej>
apritzel: wait
<jernej>
if v2021.01 is on SD card and boots kernel from SD card, it works
tuxd3v has quit [Remote host closed the connection]
<jernej>
if I FEL boot U-Boot and U-Boot boots kernel from SD card, it doesn't work
<jernej>
ok, this is strange
<apritzel>
and this is for H3, so nothing with the new ARM64 FEL, right?
<jernej>
correct
<jernej>
I put U-Boot on SD card and tried netboot and it failed
<jernej>
and FEL boot didn't boot from SD card
<jernej>
could it be toolchain related? working v2021.01 was build with different toolchain
<apritzel>
not sure, I had quite some issues lately with resetting to FEL not working properly, because of leakage from RX lines or OTG supplying the board, etc.
<jernej>
ok, different toolchain didn't help
<jernej>
but I noticed that working v2021.01 don't have emac driver enabled
<apritzel>
this is indeed looking weird, but if you can reproduce the error with FEL, then a bisect sounds not too bad?
<jernej>
yeah, I don't think there is better way currently
<jernej>
apritzel: f3866909e35074ea6f50226d40487a180de1132f is the first bad commit
<apritzel>
mmh, do you use EFI at all?
<jernej>
v2021.01 + revert works
<jernej>
no, I use zImage
<jernej>
orangepi_plus2e_defconfig for U-Boot and sunxi_defconfig for Linux
<jernej>
maybe some defaults are not ok?
<apritzel>
or the environment is growing too big and tips something over the edge?
<jernej>
that could be too
<apritzel>
that's 2GB DRAM on this board?
<jernej>
yes
<jernej>
disabling EFI_LOADER also helps, but I'm not sure if this is only masking real issue or not
<jernej>
anyway, I don't need it anyway
<apritzel>
jernej: so that would show when FEL loading U-Boot, loading kernel + initrd from TFTP?
<jernej>
yes
<apritzel>
smaeul: sorry, someone hit the CI button on your TF-A patches :-(
<jernej>
apritzel: check offending commit again, do you see how semantics changed?
<jernej>
now first command that is always executed is: load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/"BOOTEFI_NAME";
<jernej>
maybe this command breaks something
<apritzel>
it swaps the order of this load and the EFI bootmgr, IIUC
<apritzel>
jernej: do you have /EFI/BOOT on your SD card?
<jernej>
I have no SD card inserted :)
<jernej>
and no, I never worked with EFI on arm
<apritzel>
yeah, I didn't expect you to ;-)
<jernej>
these FEL + tfpd boots are very useful for quick driver tests
hlauer has quit [Ping timeout: 256 seconds]
<apritzel>
I know, I use them always exclusively for testing
<apritzel>
jernej: btw: I rebased the FIT image support for sunxi-fel and pushed it
<apritzel>
and it's sooo convenient to also do "sunxi-fel u-boot u-boot-sunxi-with-spl.bin" on the arm64 boards
<apritzel>
but I think I just found a sunxi-fel regression on the M2 Berry :-(
<jernej>
I know, I'm using it for H616 extensively
<jernej>
what kind of regression?
cmeerw has quit [Ping timeout: 260 seconds]
toaster has quit [Quit: Connection closed]
<apritzel>
SPL loading with sunxi-fel does not work on the R40 with my branch (mainline + FIT image support)
sunilmohan has quit [Read error: Connection reset by peer]
<apritzel>
jernej: so, FEL loading your h616-v2 branch, rebased on U-Boot master (what I had checked out), then TFTP loading 5.11-rc2 plus some busybox initrd worked on the R40
sunilmohan has joined #linux-sunxi
sunilmohan has quit [Changing host]
sunilmohan has joined #linux-sunxi
<apritzel>
on to my OPi Zero
Nakaori has quit [Read error: Connection reset by peer]
Naka has joined #linux-sunxi
Perlovka_ has quit [Ping timeout: 240 seconds]
Perlovka has joined #linux-sunxi
dev1990 has quit [Excess Flood]
dev1990 has joined #linux-sunxi
<apritzel>
works as well, tried both master and v2021.01
<apritzel>
but I don't use any of the actual distro boot commands
<apritzel>
just copy & pasting various tftpboot, bootz & friends commands
<apritzel>
jernej: does your TFTP server provide some PXE script for your board?
<jernej>
put it in pxelinux.cfg/<mac address> file
<jernej>
and of course update paths/file names
<apritzel>
jernej: the distro bootcmd goes through EFI first, right, then at the end falls back to PXE?
<jernej>
idk
<jernej>
yes, according to log I provided earlier, it can be seen that efi is tried before pxe
<jernej>
uh, maybe the fact that I still have Android on eMMC has something to do with it
<apritzel>
jernej: is your DHCP server also providing TFTP? So both on the same IP address?
<jernej>
DHCP and TFTPD are on my PC
<jernej>
yes, same IP, 10.42.0.1
<apritzel>
yeah, I think that's why I never used it, I always have to manually specify my laptop's IP first, as DHCP comes from the router
<jernej>
ah, I have dual NICs on PC, one is dedicated for netbooting boards
<jernej>
on laptop it's even easier - ethernet for boards, wifi for net
<apritzel>
jernej: I had this as well, but home office pushed me to update my whole network
<apritzel>
jernej: and I am not sure if U-Boot can actually use a separate TFTP server
asdf28 has quit [Ping timeout: 265 seconds]
asdf28 has joined #linux-sunxi
<apritzel>
just googled some solution where you can run a DHCP server only listening to PXE requests, so that can run on your PC/laptop that also does TFTP