<mifritscher>
the COPYING has also a explizit "NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work"."
<urjaman>
this isnt talking about the actual kernel, but the ARM mali_kbase kernel module ...
<urjaman>
(but yeah i agree with you on that... just that the license file for mali_kbase itself doesnt include that explicit note :P)
<mifritscher>
and I would say that if (even) Richard Stallman of the FSF says that then its rather safe *g*
<mifritscher>
additionally, the kernel module uses the syscall service from the kernel - so it falls under the explicit note as well in my oppinion
<tomeu>
my understanding is that the note clarifies what is considered normal use of the kernel and not derived work
<tomeu>
not so much as adding an exception for something that otherwise would be normally considered derived work
<tomeu>
but IANAL :)
<mifritscher>
jep, I understand it exactly this way
pH5 has joined #panfrost
<thefloweringash>
I swapped out Arch's CrOS 4.4.168 kernel + config for my distro's mainline 4.20 kernel + config and depthcharge just gives me a sad beep. Is there some magic config to make depthcharge happy, a size limit I need to stay under, or is there a way to debug why it makes the sad beep?
<hanetzer>
thefloweringash: which device?
<thefloweringash>
A kevin
<hanetzer>
oh, I'm getting one of those :)
<thefloweringash>
(Samsung Chromebook Plus v1)
<tomeu>
thefloweringash: depthcharge has indeed a hardcoded size limit
<hanetzer>
yep.
<tomeu>
thefloweringash: for these issues, eballetbo[m] in #armlinux and ezequielg here (but later) could help you
<thefloweringash>
do you happen to know what the limit is?
<tomeu>
they are very much interested in mainline working fine on the kevin
* hanetzer
will do u-boot when he gets his kevin :>
<thefloweringash>
I didn't realise that was an option. Can you still boot to ChromeOS?
<hanetzer>
maybe?
<urjaman>
i mean, CrOS fw updates will break for sure
<tomeu>
hanetzer: you mean chained boot?
<hanetzer>
note there is no support for kevin in current u-boot. same for speedy (though my final patch should be accepted for next go round)
<hanetzer>
tomeu: no, I mean u-boot on the spi flash
<tomeu>
cool
<urjaman>
:P
<hanetzer>
right now you just need my last patch for u-boot support for veyron-speedy
<hanetzer>
heading to work, later o/
BenG83 has quit [Ping timeout: 244 seconds]
<thefloweringash>
Spelunking a little through the depthcharge source, it looks like the expanded size should be <64mb. My entire kpart is ~45mb. I see lots of useful printf statements, is there a way to receive those?
<urjaman>
how big is the kernel partitions on kevin?
<urjaman>
(i remember them being 16M on speedy and going "that's gigantic" :P)
<thefloweringash>
looks like they're 16M
<thefloweringash>
my working kpart is 29M
<hanetzer>
thefloweringash: hmm. make the 'kernel' depthcharge loads u-boot and let that handle actual kernel load?
<mmind00>
for the record, my rk3399-google-scarlet (the tablet) refuses to boot with kparts > 32MB
<thefloweringash>
that's been on my todo list, but quite a long way down
<thefloweringash>
did you say there's no kevin support in u-boot yet? is there a patch somewhere?
<hanetzer>
no, though I intend to do it once I acquire mine :)
<hanetzer>
assuming the used vendor labeled it right on the listing and its actually the right one :{
<hanetzer>
thefloweringash: I take it you actually possess one? if so, feel like being my guinea pig? >:D
BenG83 has joined #panfrost
<thefloweringash>
uh, sure. would definitely be keen to boot my distro's kernel instead of building my own
<hanetzer>
can you get a cbmem dump on a coreboot->depthcharge->chromeos boot? (as vanilla as possible)
<thefloweringash>
would prefer to keep chromeos intact and continue to boot from my sd card (as painful as it is)
<hanetzer>
should be able to, probably. stick u-boot as a depthchare kernel on the sdcard, leave the other devices (emmc, spi) alone
<hanetzer>
are you capable of/willing to flash the spi for testing purposes?
<thefloweringash>
flashing to spi: if it comes to it, sure, so long as it's easy to recover from?
<hanetzer>
yeah. if you dump your current spi (do it a few times, check hashes/etc) you can always go back
robertfoss_ has joined #panfrost
<thefloweringash>
seems like lz4 is enough to get me under the sad-beep limit, but now I only have a blank display
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<thefloweringash>
the more I google the less confidence I have in recovering from a bad spi flash
<hanetzer>
its honestly pretty easy. I'm just getting impatient waiting on mine lol
<hanetzer>
shoulda took up those people's offer for rk3399 hardware :P
<hanetzer>
but, raspi-alikes are not very useful outside of sitting in one place and a decent lappy the kevin is :)
<thefloweringash>
They’re useful as CI servers for Kevins ;-)
<hanetzer>
suppose. I already have a bbb I could use for that tho
<thefloweringash>
Another build slave for more throughout is elate handy. It takes my rock64 about three days to build chromium.
<thefloweringash>
s/elate/always/
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
* hanetzer
would never build chromium, but believes firefox would take a similar amount of time :P
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
raster has joined #panfrost
<TheCycoONE>
Failed to load module: /usr/lib/libweston-5/drm-backend.so: undefined symbol: gbm_bo_get_offset - where should I be looking?
<hanetzer>
libgbm.so, maybe?
<hanetzer>
part of media-libs/mesa on gentoo
<TheCycoONE>
that's part of panfrost/mesa, and was built into the gfx-prefix/lib dir
<tomeu>
that symbol was added to mesa more than 2 years ago though
<tomeu>
check with strace which libgbm.so was opened at the end?
<TheCycoONE>
(as an aside, anyone know why weston-launch only produces output once per boot / another way to reset it?)
<raster>
what makes mesa want to open panfrost_dri.so?
<raster>
as my mesa build doesnt even try to open it...
<raster>
(it tries rockchip_dri.so and fails...)
<TheCycoONE>
libgbm and actually gfx-prefix at all doesn't show up in the strace
<raster>
wellit dlopens it and init fails
<raster>
somehow (havent put in debug yet to find out)
<TheCycoONE>
gfx-prefix/lib does show up in the strace for eglinfo though
<mmind00>
raster: for display output mesa should open the rockchip_dri which in turn should hand 3d over to panfrost_dri internally
<mmind00>
raster: some kmscube variants (like the one from yuq / lima) does have a dump mechanism which can run offscreen with just the gpu-related mesa parts
<raster>
ok
<raster>
bc rockchip fails - thus panfrost does
<raster>
well panfrost isnt even tried
<raster>
:)
<raster>
so need to debug rockchip first
<hanetzer>
is current panfrost still only workable for the t8xx gpu?
<TheCycoONE>
helps if I follow forks with strace; yeah it's reading the wrong libgbm
<tomeu>
hanetzer: that's what people are currently using for testing atm, afaik
<tomeu>
what gpu version are you interested in?
<TheCycoONE>
... why is weston not following LD_LIBRARY_PATH
<urjaman>
i'd assume the one on speedy (t760)
* urjaman
would get back to that ... given energy to do all the things :P
<TheCycoONE>
ah - because it's setuid
<TheCycoONE>
how did alyssa get around that?
<thefloweringash>
hanetzer: firefox is about 8 hours, iirc
<TheCycoONE>
ok, just run weston directly - avoids that problem. claims to start successfully and then exits without updating the screen. should be working though
<TheCycoONE>
*I should be working
<TheCycoONE>
so I'll look again in a few hours
yann has joined #panfrost
<hanetzer>
tomeu: I have 2x rk3288-veyron-speedy chromebooks, t7xx
<tomeu>
hanetzer: cool, would be interesting to know how well it works there :)
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
afaerber has quit [Quit: Leaving]
BenG83 has quit [Quit: Leaving]
afaerber has joined #panfrost
BenG83 has joined #panfrost
<tomeu>
yann: got any success with X?
<hanetzer>
tomeu: originally that's what alyssa was working on before it dead.
<tomeu>
hanetzer: yeah, I have seen references to it in the code
<tomeu>
I have a veyron on my desk, but have too many other boards piled on top to be able to check :p
<yann>
tomeu: not yet got around to it - since alyssa told I have to go through Xwayland for this, the priority of this option is a bit lower, I'm digging to understand what precisely does not work with libMali
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
cwabbott has quit [Client Quit]
cwabbott has joined #panfrost
vimuser is now known as _4of7
<alyssa>
mifritscher: ". It would take a substantial amount of code (coming from inline functions or macros with substantial bodies) to do that. " Arguably that's the case with the headers as we currently use them now
<alyssa>
thefloweringash: 32M is the limit for kernels on Kevin
<alyssa>
thefloweringash: And, uh, make sure it's packed right
<alyssa>
hanetzer: Yeah, t8xx only on current master.
<alyssa>
TheCycoONE: I have a dedicated machine that _only_ has Panfrost on it so I have it installed systemwide (/usr/local/lib), so no LD_LIBRRARY_PATH needed for me. Keeps me from accidentally using soft rast :p
<TheCycoONE>
ah, ok
<alyssa>
hanetzer: I have working veyron(s) in my posession now; I just haven't had time to dedicate to backporting stuff yet
cwabbott has quit [Ping timeout: 250 seconds]
robclark has quit [Remote host closed the connection]
robclark has joined #panfrost
pH5 has quit [Quit: bye]
robclark has quit [Ping timeout: 272 seconds]
robclark` has joined #panfrost
robclark` is now known as robclark
pH5 has joined #panfrost
<gtucker>
about the kernel size limit in depthcharge, there are a couple of things
<gtucker>
the first thing is that there's a build-time configuration with the size of a buffer to download an FIT image
<gtucker>
which may well be 32MB by default, but can be set to something larger
<gtucker>
the kevin in our lab has it set to 128MB
<gtucker>
the FIT image is kernel + dtb + ramdisk, so it's easy to get over 32MB
<gtucker>
the second thing is if you're getting the FIT image over TFTP, there was a bug in Depthcharge with files larger than 32MB
<gtucker>
due to some annoying block counter thing in the tftp protocol
<gtucker>
but that's fixed now in the latest Depthcharge
<gtucker>
if someone needs some help to flash a kevin with depthcharge having the debug cli and tftp boot enabled, let me know
<Lyude>
I'd say focus entirely on the 4.20 right now
<stikonas>
4.20 does not have HDMI output
<stikonas>
you need a patch
<raster>
there's a mali-t860 entry in it
<raster>
stikonas: this one does
<raster>
:)
<Lyude>
is there any chance you can/have (sorry-I haven't been keeping track) try with just the mainline kernel? or mainline + whatever patch you need for the hdmi output?
<stikonas>
well, I use the one from kernel.org and add a single patch
<stikonas>
to enable hdmi in device tree
<raster>
Lyude: i can't find the exact src tree with deb build stuff but it's
<Lyude>
stikonas: guessing the patch is waiting for acceptance into mainline or something like that?
<Lyude>
I meant just building a kernel off kernel.org
<stikonas>
only first two will be needed on 5.0
<NeuroScr>
stikonas: sounds like my problem
<stikonas>
yeah, I prefer mainline kernel form kernel.org
<raster>
yeah
<raster>
i woudl too
<raster>
but i'd need to patch too
<Lyude>
raster: any chance I might be able to get ssh access to this system at some point? Could probably figure this out a bit faster that way
<raster>
hmmm
<Lyude>
it's probably something very silly
<raster>
it possibly is
<Lyude>
also: is there any dmesg output when you try loading the mali_kbase ko?
<raster>
as this is the first rockchip board i have and basically the first thing i do after getting an existing os image to run, then update to deb testing .. and make the closed mali drivers work... (but with the working kernel).. and hen panfrost
<raster>
i dont have myc experience with these boards :)
<raster>
and the only dmes is the foreign module thing
<Lyude>
raster: I'm here all night, although I will be slow to respond since I'm also at work (and have not yet convinced RH to let me work on panfrost :p, so I need to multitask a lot)
<raster>
Lyude: oh sure :) hahahahah
<Lyude>
or rather, I should be here at least until 8:30
<raster>
well i dont think i can give u access to THIS one...
<raster>
well i could but i'd be punshing a hole through company firewall into the inner network
<raster>
BUT
<raster>
i have an identical board at home
<Lyude>
alright-that sounds like it should work
<raster>
i could do that for sure - add an account etc. if i can get your ssh pub key
<Lyude>
raster: any idea if this system has a working watchdog?
<raster>
i ... don't.... know
<raster>
it's debian...
<Lyude>
raster: alright, that just means I'll need to poke yuu if I end up crashing the machine :p
<raster>
if it cleanly reboots it'll reboot to everything set up properly
<raster>
but... that's about it
<Lyude>
alright, mind if I give that a shot? (working on people's systems remotely for long enough has taught me the first thing I need to do is make sure I can crash the machine and have it recover :p)
<raster>
sure
<Lyude>
aight, one second then
<raster>
i dont have a serial console working either... fyi
<raster>
:)
<Lyude>
ah
<raster>
i have tried on my other board but... all serial stuff before a login prompt is always junk bytes
<raster>
it might be baud rate.. but i have no idea hw the rate should be...
<Lyude>
sounds like something isn't hooked up right or wrong baud rate yeah
<Lyude>
usually the baud rate is pretty standard
<Lyude>
let me see what it is on my machines at home
<raster>
well to date 115200 was the std
<raster>
and thats worked just about everywhere...
<raster>
i tried 1500000
<Lyude>
yeah, I was gonna say that's what all of my machines seem to be on
<raster>
but not supported at leats by my serial usb thingy
<Lyude>
it's probably something not hooked up then somewhere, or the wrong serial console
<raster>
but it dfoes work as soon as a login prompt rolls by
<raster>
input and output
<raster>
so *shrug*
<Lyude>
alright I'm back in
<Lyude>
i'll give this a quick shot right now and if I can't figure it out I'll come back on the weekend
<raster>
no problems
<raster>
just hookinmg up my serial dongle right now... ned that usb extension cable....
<Lyude>
raster: any idea if there's somewhere I can clone the repo for the kernel you're running on this machine so I can build mali_kbase on my laptop locally?
<raster>
your home dir
<raster>
thats what i did
<raster>
my stuff is in ~raster/panfrost
<raster>
mali_kbase is there already
<raster>
you have sudo access :)
<raster>
ok serial console is working.. well login prompt is there
<raster>
and i can log in
<raster>
so if worst happens i have that
<Lyude>
tomeu: poke, you around?
<Lyude>
ah nvm, figured it out
<raster>
i see u startd the watchdog
<Lyude>
raster: /home/raster/panfrost/linux-kernel/ is where your kernel source dir is I'm guessing? or linux-mainline-kernel
<raster>
;]
<Lyude>
raster: I didn't actually o-o
<raster>
actually no
<raster>
the kernel is the .deb
<raster>
really?
<raster>
there is a kernel watchdogd thread...
<raster>
i've never messed with one before...
<Lyude>
raster: yeah that's just on by default, and doesn't ever really work very well in my experience :(
<Lyude>
raster: but I mean, where's the kernel source that you're building mali_kbase against? You've got to have an actual source directory somewhere
<Lyude>
or at least some place with kernel headers
<raster>
i wish i could find the src for those debs so i could build/update my own with mods
<raster>
i couldnt
<raster>
:(
<raster>
i found a raw kernel tree git ayfan maintains with patches for rcokpro64
<Lyude>
yeah, we should probably get a mainline kernel working on here at some point so we don't need to worry about that in the future. for now thugh I'll see what I can do
<raster>
and i used my config.gz there and that kernel didnt boot into anyting useful
<raster>
so i'm missing something in preparing it and thats in the deb control files which ... i cant fine
<raster>
find
<raster>
i didnt want todeal with patching in e.g. hdmi support - i'd like to have 1 problem at a time :)
<raster>
not sure what else i'd have to patch in tbh
<Lyude>
alright, got the kmod built
<Lyude>
let's see if I can poke around and see what's going wrong here
<raster>
and loaded
<raster>
but still nothing other than "it loaded" . no /dev/mali.... ?
<Lyude>
raster: yeah, I'm still figuring out why :p
<raster>
at least that is what has appeared before with prior kernel drivers .. unless kbase is different
<raster>
heheh thats hwy i was wondering if there was debug
<raster>
:)
<raster>
ok
<raster>
watchdog service running at least...
AntonioND has joined #panfrost
<Lyude>
raster: so I can't even et the kernel module to print anything in kbase_platform_device_probe() which should be the entrypoint for the module
<Lyude>
but-that's good because what I can infer from that is that we're probably not matching any of the device ids in kbase_dt_ids
yann has quit [Ping timeout: 268 seconds]
<Lyude>
raster: you said you say mali-t860 in your dts file, was it /exactly/ that string?
<Lyude>
alo, where did you find the dts file that told you that? I don't see anything that you linked that would have it, only dtb files (I'm loooking for dts)
<hanetzer>
well, you can decompile them :P
<raster>
Lyude: sorry was going around in circles in real life
<raster>
ummm
<Lyude>
oh you can? excuse me, I'm a bit new to devicetree stuff :p
<Lyude>
hanetzer: how does one do that?
<hanetzer>
yeah. pretty much a 1:1 decompilation, minus some nice things
<hanetzer>
its kinda like decompiling java tho. no comments, and you lose nice things like foo-property = &other-node
<Lyude>
that's ok, I should just be looking for the string raster mentioned
<hanetzer>
&other-node becomes a hex digit, and the actual node referenced by &other-node has a property called phandle or linux-phandle which matches that hex digit
<Lyude>
hold up, is /proc/device-tree toggled by a kernel config option?
<hanetzer>
unsure.
<raster>
it's there
<Lyude>
oh wait there it is
<Lyude>
must have typo'd something
<raster>
now if the kenrel is somehow using some other dtb that doesnt have this.. that'd make sense :)
<Lyude>
i honestly think that's the issue
<Lyude>
from reading the src the only way the platform probe code would be skipped is if there's no matching entries in the dt
<hanetzer>
prolly. if you're using uImage(zImage+dtb) then it prolly doesn't grab the one from fs
<hanetzer>
raster: how are you booting? what's the boot firmware, coreboot, u-boot, etc?
<Lyude>
gah, dtc just segfaulted on this board
<hanetzer>
Lyude: tar the filesystem and send it to another device, extract, do it again :)
<Lyude>
alright, let's see
<raster>
hanetzer: as i didnt build the kernel... i dont know what it's doing :)
<hanetzer>
raster: device?
<Lyude>
yeah.... that would help a lot to know :s
<raster>
hanetzer: rockpro64 - so extlinux or something new to me
<hanetzer>
raster: u-boot ?
<raster>
not that i know of
<hanetzer>
it prolly is, if its not a chromebook
<raster>
i never saw a uboot prompt on serial or anywhere... so '' that's why i don't know :)
<hanetzer>
or you could be in vendor hell and have some thing compiled from terrible asm files :P
<raster>
it is possible :)
<hanetzer>
raster: /proc/cmdline ?
<raster>
i have seen enough horrible stuff not to make any assumptions :)
<Lyude>
I'm assuuming that's just rockchip,rk3399-mali + arm,mali-t860
<hanetzer>
that's maybe ok... I'm unsure if the compiled dts is \0 deliminated
<raster>
Lyude: its in the dt right?
<Lyude>
status = "disabled"
<Lyude>
raster: yes
<raster>
ohoo
<raster>
disabled?
<raster>
wtf?
<Lyude>
appears so
<hanetzer>
ah yeah
<raster>
well dang
<hanetzer>
most everything is default 'status = "disabled"' in the cpu dtsi and is turned on by the board dts :)
<raster>
now i wonder if the dtb is on disk or in the img
<Lyude>
raster: anyway-that's definitely your problem
<hanetzer>
raster: does something akin to /boot/extlinux/extlinux.conf exist ?
<hanetzer>
rockpro is not meant to be a gfx consumer more or less, yeah?
<Lyude>
anyway-I'm going to go back to work now
<Lyude>
let me know if you guys have any issues once you have the dt stuff sorted out
<Lyude>
btw hanetzer: any progess with kernel stuff? I'm probably going to start trying to come up with some code this weekend, since it seems we (may???? it's still kind of up in the air) will have issues getting panfrost into mesa with deps on mali_kbase
<hanetzer>
Lyude: well since current panfrost is not in a status to work on arm32 I've been putting it off until I get my rk3399 device (anywhere from jan 10-16 it could arrive)
<Lyude>
makes sense
<raster>
hanetzer: that does seem to the what the bootloader uses - and since its in a normal filesystem (ext4 even) and it's extlinux... i thought it is some custom/different bootloader
* Lyude
reallllly needs to fix that :s
<hanetzer>
raster: its prolly u-boot. u-boot can find that extlinux.conf file and make a boot menu basically :)
<raster>
hanetzer: and yes - it exists. i've looked into it before :)
<Lyude>
hanetzer: also I happen to be waiiting for an rk3399 device as well :p
<Lyude>
what a coincidence
<hanetzer>
you may have u-boot compiled in such a way that is meant for fast booting and not tinkering
<stikonas>
I don't use extlinux.conf on rk3399...
<raster>
Lyude: tnx man. so dt problem eh? i wouldnt have thought given the same guy's 4.4 kernel works...
<stikonas>
just use ESP active partition... simpler...
<hanetzer>
I will, once i port kevin to u-boot :)
<Lyude>
raster: sure looks like it at least
<stikonas>
hmm, should read backlog here. Maybe upstream kernel on rockpro64 is also missing something in dts
<Lyude>
stikonas: no we found the entries in their dts
<Lyude>
they're just disabled
<hanetzer>
is rockpro rk3288 or what?
<stikonas>
rockpro is rk3399
<raster>
hanetzer: rk3399... its probably one of the better 3399 boards
<raster>
with 4gb ram, gig-e and a tonne of connectors....
<Lyude>
btw
<Lyude>
your devicetree probably lives in /boot/dtbs/4.20.0-1083-ayufan-g686e1f1aa461
<Lyude>
/boot/extlinux/extlinux.conf is present so that's probably what is determining the devicetree
<raster>
well thatas where i found them
<Lyude>
and your dtb definitely isn't built in
<raster>
i do wonder how it actually chooses the right dtb file tho
<hanetzer>
yeah. on current mainline rockpro64 dts the mali gpu is not enabled. you'll have to compile a custom dtb
<Lyude>
raster: it's in /boot/extlinux/extlinux.conf and it's determined by model name
<raster>
Lyude: this is what i was hoping as it means i can hack it more easily :)
<raster>
Lyude: it indicated the base dir for dtbs but not which
<hanetzer>
yeah. you can enable the gpu via &gpu {\n\tmali-supply = <&some-supply>;\n\tstatus = "okay";\n};
<hanetzer>
in the dts
<hanetzer>
unsure what supply you should use
<Lyude>
hanetzer: all the other info that they should need looks to be there, I think it's just a matter of changing the status line. let me post their dts
<hanetzer>
I think mali-supply is needed
<stikonas>
hmm, why would it be disabled in dts... what's the point of adding it there then
<raster>
it must find the model name string from some other rom/firmware as its not coming from extlinux.conf
<Lyude>
raster: well yeah-that part is determined by uboot iirc
<hanetzer>
oh, yeah, mali-supply is optional
<hanetzer>
so you can exclude that line
<hanetzer>
raster: yeah. assuming u-boot, well-supported mainline boards encode the default dtb name in the firmware
<hanetzer>
you can explicitly name a dtb though, I think
<Lyude>
(also-from that dtb your uboot does have the right model name in the firmware at least
<Lyude>
/boot/dtbs/4.20.0-1083-ayufan-g686e1f1aa461/rockchip/rk3399-rockpro64.dtb should be the one it's loading
<AntonioND>
stikonas: do you have any link to instructions on how to build everything from source for the rockpro64? I couldn't find unstructions for uboot
<raster>
well it seems to then be finding it right by some magic :)
<stikonas>
AntonioND: not written...
<stikonas>
I have some scripts
<AntonioND>
... ok, that's what I thought
<stikonas>
AntonioND: uboot is only non-upstream for now...
<raster>
this board needs better support. ayufan is doing a good job ... but he's missing some bits
<stikonas>
AntonioND: hopefully upstream support will come withing then next few months
<raster>
Lyude: how dodo u decompile? i get a segv evenon my pc
<AntonioND>
yeah, I have one and was quite disappointed to see that it wasn't that easy to actually get everything working, because I bought it because of panfrost actually...
<stikonas>
and there are still 2 binary blobs in my instructions
<stikonas>
AntonioND: it will be easier once upstream uboot is supported
<Lyude>
raster: I ended up having to give up on /proc/device-tree and I used /sys/firmware/fdt
<AntonioND>
hope so
<Lyude>
also though the file path I gave you above should work
<stikonas>
that's rockchip's fork but still better than reverse engineering
<hanetzer>
veyron-speedy is one patch away from mainline u-boot support :)
<raster>
HA
<raster>
gpu found
<AntonioND>
rk3399 is one of the few interesting SoCs that have open source ATF, so it would be a shame not to have support for this board as openly as possible
<stikonas>
AntonioND: well, if you have any progress with your open source self compiled ATF, let me know...
<raster>
gah
<raster>
mesa still fails to load rockchip
<raster>
failed to load driver: rockchip
<AntonioND>
that's the problem, if there are no instructions on how to bundle things... every single company that uses the TF uses it in a different way
<Lyude>
at least your GPU seems to be up
<stikonas>
AntonioND: I thought u-boot bundles it
<stikonas>
when you make u-boot.itb
<Lyude>
raster: make sure that youre running it in a context that has permissions to read /dev/mali-
<Lyude>
*/dev/mali0
<stikonas>
but since I couldn't get it working, I wasn't sure
<AntonioND>
stikonas: you can also have uboot as part of the fip and let the TF load uboot
<stikonas>
yeah, I think that's what happens on my system now
<stikonas>
when I make u-boot.itb
<raster>
Lyude: 0 crw-rw-rw- 1 root video 10, 57 Jan 9 22:22 /dev/mali0
<raster>
i'm good :)
<AntonioND>
there is also coreboot, which loads the TF
<raster>
udev already set up
<AntonioND>
so yeah... anything goes
<Lyude>
raster: darn, unfortunately I don't think I've got any more time to look at this todya
<stikonas>
well, with u-boot, you first load part of u-boot (SPL), that loads TF, then load another part of u-boot
<raster>
no problems
<raster>
go back to work :)
<raster>
thansk very muchly
<Lyude>
np, sorry for all the trouble!
<raster>
an intro to dtb's
<raster>
never had to mess with them before
<raster>
i learned something :)
<AntonioND>
stikonas: ok, I didn't know that part. in any case, enough of offtopic. so far my rockpro64 is in a box in a cupboard and it will have to stay there for a while because I don't have time to play with it
<raster>
waaait
<raster>
it isnt even trying to load rockchip_dri.so
<raster>
oh wait
<raster>
never mind
<raster>
ther eit is higher up
<raster>
weird... it doesnt seem to do anything with /dev/mali0 ....
<raster>
this is for another day i think....
<hanetzer>
yeah. spl inits registers/ram/etc, just enough to run real u-boot :)
<raster>
Lyude: hanetzer thnks muchly. got over this hump thnaks to your help and onto the next... i guess it's putting debug into mesa time
<Lyude>
raster: np, that's what we're here for :)
<raster>
tnx :)
<raster>
give me time and i'll actually try and get better support for these things
<raster>
like better out of the box stuff so people can work on panfrost more easily
<Lyude>
raster: that would be awesome, thanks! :)
<Lyude>
i'm working on trying to do the same as well with the vim2 that I got sent
<Lyude>
going to try at some point to get fedora's default kernel config working with it, and make sure that there aren't any patches for it missing upstream
<raster>
i was in the middle of doing it for my rpi too - too much manual "enable open souce 3d driver" magic for people ... so was going to prepackage a wayland compositor everything working right thing :)
AntonioND has quit [Quit: Quit]
<alyssa>
ezequielg: Pong
<alyssa>
I haven't done anything with AFBC scanout yet, so none. But FBOs are all AFBC, so at least in userspace we ought to be able to do it. Scanout is linear since, yeah, I don't want to deal with kernels and such yet :)
<Lyude>
alyssa: btw, re: 11:17 <@alyssa> mifritscher: ". It would take a substantial amount of code (coming from inline functions or macros with substantial bodies) to do that. " Arguably that's the case with the headers as we currently use them now
<Lyude>
where exactly is that the case might I ask?
<Lyude>
i didn't see any kind of functions in the header that were non-trivial
<alyssa>
Maybe it's a different set of headers than I thought
<alyssa>
(I haven't looked carefully at what we import and what we don't)