<Ke>
those points seem quite huge, but there are other components nearby
* vagrantc
is in the middle of building linux 4.14-rc1 to test on the firefly-rk3399...
<Ke>
vagrantc: yeah, that's what I am doing as well
<Ke>
just considering they have the button for entering usb loader, why not use that button for mask rom mode
* vagrantc
concurns
<vagrantc>
er, concurs
jelly-home is now known as jelly
wadim_ has joined #linux-rockchip
<stdint>
amstan, the correct command is the db
<vagrantc>
ok, cpu frequency scaling works with the cortex-a53 cluster, but not the cortex-a72 cluster on the firefly-rk3399
<vagrantc>
and both eMMC and microSD are recognized ...
<vagrantc>
and my theory about running at some very slow default speed before cpufreq was working seems right: [ 37.217795] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 200000 KHz
<vagrantc>
[ 37.218702] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 408000 KHz
<Ke>
oh dear
vagrantc has quit [Ping timeout: 252 seconds]
aalm has quit [Quit: xyz 1.9]
kloczek has quit [Remote host closed the connection]
wouterstreamit has joined #linux-rockchip
<wouterstreamit>
When booting Yocto linux kernel 4.4 on a Firefly RK3288 it works if no monitor or a 1080p monitor is attached, but booting fails if a 4k monitor is attached, u-boot seems to hang
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 has joined #linux-rockchip
cnxsoft1 is now known as cnxsoft
nighty- has joined #linux-rockchip
<Ke>
yay, coworker was able to wire the testpoints for me
aalm has joined #linux-rockchip
<Ke>
and you really have to short the testpoints for a long time, it's almost an impossible task with my motoric function
kaspter has joined #linux-rockchip
aalm has quit [Ping timeout: 240 seconds]
aalm has joined #linux-rockchip
aalm has quit [Ping timeout: 260 seconds]
nasuga has joined #linux-rockchip
aalm has joined #linux-rockchip
kloczek has joined #linux-rockchip
cnxsoft has quit [Remote host closed the connection]
LongWork has joined #linux-rockchip
LongWork has quit [Client Quit]
LongChair has quit [Ping timeout: 240 seconds]
LongChair1 is now known as LongChair
JohnDoe_71Rus has joined #linux-rockchip
LongWork has joined #linux-rockchip
aalm has quit [Ping timeout: 246 seconds]
vagrantc has joined #linux-rockchip
cyteen has joined #linux-rockchip
<vagrantc>
hrm... with linux 4.14-rc1, i'm sometimes getting both eMMC and microSD to show up, but lately i've only been seeing the microSD ... hrm.
topi` has joined #linux-rockchip
<topi`>
just received my Rock64's. Nifty boards, but the cpu perf is disappointing
<topi`>
I have an algo which has a really large cache footprint and I think the rk3328's L2 cache is not enough
<vagrantc>
so, cpufreq with linux 4.14-rc1 is only working for the a53 cores on the firefly-rk3399 ... the a72 cores are probably still running at some default speed
<topi`>
anyone know of ARM SoCs that would implement 2MB or more L2 cache?
<topi`>
I think the A53 core is just fine for many purposes, but the amount of L2 cache needs a boost
wouterstreamit has quit [Ping timeout: 260 seconds]
<beeble>
topi`: rk3399 has 1mb l2 for the big cluster. the bigger armada stuff (8040) has 1mb l3, if you go into the even more datacenter stuff like xgene and thunderx you have 8-32mb l3
nighty- has quit [Remote host closed the connection]
cyteen has quit [Ping timeout: 255 seconds]
<topi`>
xgene and thunderx are fairly expensive chips
<topi`>
I'm looking at mobile SoCs because of volumes of scale bring the price down
<xevious>
Kwiboo: I'm trying to build your kernel-4.4-rock64 branch and it failed with the error "drivers/built-in.o: In function `mtd_vendor_erase': /mnt/ramdisk/linux-build/kernel/drivers/soc/rockchip/sdmmc_vendor_storage.c:109: undefined reference to `mtd_erase'" Any suggestions?
<phh>
topi`: well, cache is very expensive
<topi`>
maybe the Hikey 960 board with a Kirin 960 Soc, but that one doesn't have an Ethernet connector :(
<Ke>
does anyone know, whether the SPI from firefly-rk3399 can be used to boot the device
<Ke>
assuming I broke the emmc
<phh>
topi`: no but it has mini pci-e if i'm not mistaken
<Ke>
SPI in the io header that is
<Ke>
in general rk3399 can boot from SPI
<beeble>
Ke: spi1 is the controller used by the bootrom. should be on J21
<Ke>
I guess that is yes?
<beeble>
schematics say yes. but i didn't try it, don't own a firefly
<Ke>
we did a oscilloscope measurement and there was some activity, just checking, if someone know whether it should work before ging through the effort
<beeble>
i can tell you it's working with the rk3399 on spi1 and with mainline
<beeble>
+ u-boot
<Ke>
though none of us were able to account for the failure mode, bootrom tries to load stuff from the emmc and succeeds to some extent, but rkdeveloptool does not seem to be able to read or write stuff
<Ke>
the same tool was working before
<Ke>
beeble: thanks, I'll order some spi stuff and check it out
<Ke>
not too expensive anyway
<Ke>
actually externally flashable SPI nand is preferrable option to emmc for the first bootloader
<Ke>
if only there was SD boot, that rk3399 claims to support
<beeble>
it does
<beeble>
works fine for me
<Ke>
firefly board does not seem to support it
<Ke>
and it's documented not to be supported
<Ke>
beeble: could it be that you can only get one of emmc/sd as bootable?
<beeble>
no, works fine with all three sources. and it probes in spi, emmc, sd card order
<beeble>
and i can't see a reason why it shouldn't work at the first glance at the firefly schematics
<beeble>
do they give a reason?
<Ke>
not that I can see
<beeble>
if not you could try u-boot mainline
<Ke>
well at least their original image does not boot
<Ke>
and more importantly serial log shows no signs of sd card ever being tried as boot source
<vagrantc>
the firefly-rk3399 definitely can boot from microSD, but in my experience it is a bit unreliable
<vagrantc>
if it finds something on eMMC, it boots from that first ... so you have to wipe the eMMC at the right places to get it to boot from microSD
<beeble>
or use the "maskrom" pads to short the clock line
<m0nt3>
hey. i am currently working with a RK3288 with arch linux arm and trying to get the 3d parts of gpu working. is there anyone here that could provide some assistance?
vstehle has quit [Ping timeout: 248 seconds]
<amstan>
m0nt3: there's very few of us that got it working
<amstan>
m0nt3: it's generally a pain
<m0nt3>
oh. i see. that's unfortunate :(
<amstan>
i had it running 2 years ago, with the xf86-video-armsoc-rockchip package and the veyron-libgl(libmali.so) package
<amstan>
but last DE that worked with it was KDE4, KDE5 crashes as soon as it starts with it
<m0nt3>
i had those, but i think in current state it doesn't work. i always get the "no driver found: rockchip_dri.so" error or something like that
<amstan>
i think that was always there
<amstan>
what kernel are you running?
<m0nt3>
oh.
<m0nt3>
uhmm
<m0nt3>
h/o
<amstan>
h/o?
<m0nt3>
hold on.
<m0nt3>
sorry
<amstan>
it's possible the DDK and libmali versions don't match
<m0nt3>
oooo
<amstan>
ddk is essentially the tiny glue logic that's part of the kernel that makes libmali work
<amstan>
(it provides the /dev/libmali.so device for example)
<m0nt3>
oh, well, that may be the case
<amstan>
gah, i meant /dev/mali0
<m0nt3>
acutally, i think im running 4.4
<amstan>
well, there's your problem
<m0nt3>
im not certain because im currently in Chrome OS
<amstan>
4.4 from where?
<m0nt3>
arch linux arm
<amstan>
that's a strange version to run on 3288
<m0nt3>
the most updated kernel
<m0nt3>
not entirely sure
<amstan>
the armv7h mainline kernel from arch linux arm is 4.13
<amstan>
then you probably don't even have a ddk in there
<m0nt3>
ive been looking at a number of kernel versions recently, and i haven't booted it in 3 days-ish, so my memory of the version is foggy
<m0nt3>
oo
<m0nt3>
snap
<amstan>
mainline simply does not support mali
<m0nt3>
oh
<amstan>
since mainline does not want to include the ddk, the ddk has no point besides running libmali.so (which is all proprietary)
<amstan>
so mainline doesn't want to include it
<m0nt3>
what about OnDebian? i saw that if it's used, one *could* get the gpu running with the ChromeOS kernel stuff
<amstan>
depends on the kernel used
<m0nt3>
ah
<amstan>
i'm not sure what they do
<amstan>
if you want to get it working on arch you have a few options: include the ddk yourself and recompile the kernel
<amstan>
run linux-veyron instead (kernel used by chromeos), it comes with the ddk, it should match the veyron-libgl package too
<amstan>
even then getting gfx is kinda bad
<m0nt3>
mmm
<m0nt3>
it seems that i might just need to switch over to Chromium OS...because the auto-update system in ChromeOS is really messing with me
<amstan>
but at least you'll be running the exact kernel that chromeos uses, which i'm not sure how much of a positive it is anymore (given that upstream has caught up)
<amstan>
auto updates are messing with you?
<m0nt3>
keep blowing up my /etc/init folder
<amstan>
well, the point of Chrome OS was so you never had to care about your /etc/init folder, i'm not surprised it's not respecting your wishes
<m0nt3>
yeah. i've found this out. too bad i had this device before i started changing things
<amstan>
even if you switch to chromium os only and build it yourself, are you going to be reinstalling every 2 months in order to keep the software up to date?
<m0nt3>
nah. i don't utilize much in it. most programs i compile manually.
<m0nt3>
i just need the gl components
<amstan>
it's just a bad idea to run old web browsers
<m0nt3>
true.
<amstan>
have you looked into crouton?
<amstan>
it's in theory possible to do libmali stuff in there
<amstan>
i had a friend that got it working a while ago
<m0nt3>
i was using it extensively for a while. then i switched to chromebrew, because i didn't agree with the battery drain of running another windowing system.
<amstan>
but it'll essentially be the same thing as arch
<amstan>
i wish this was easier
<amstan>
i have tried many times, given up many times too
<m0nt3>
yeah. it is quite the pickle.
<amstan>
apparently lima might be happening: you have a few options: include the ddk yourself and recompile the kernel