ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | IRC log | Community GH | Rockchip GH | ML
nasuga has quit [Ping timeout: 252 seconds]
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
cnxsoft has joined #linux-rockchip
lurchi__ is now known as lurchi_
stdint has quit [Ping timeout: 248 seconds]
stdint has joined #linux-rockchip
stdint has quit [Ping timeout: 248 seconds]
lurchi_ is now known as lurchi__
stdint has joined #linux-rockchip
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 248 seconds]
vstehle has joined #linux-rockchip
aalm has quit [Ping timeout: 260 seconds]
jelly has quit [Quit: ""]
jelly-home has joined #linux-rockchip
aalm has joined #linux-rockchip
fixmer has joined #linux-rockchip
bbelos has quit [Ping timeout: 240 seconds]
bbelos has joined #linux-rockchip
nighty- has quit [Remote host closed the connection]
<Ke> obviously bricked the bootloader and just now noticed they just could not add switch for the mask rom mode...
<Ke> why would you not add a switch for it
<vagrantc> it's more "fun" to document shorting eMMC to force it into mask rom mode
LongChair has quit [Quit: LongChair]
LongWork is now known as LongChair
LongChair1 has joined #linux-rockchip
<Ke> has anyone soldered a switch there, is it feasible with less than 10% chance of hw damage
<vagrantc> probably depends on your soldering skills ... which board?
<Ke> firefly-rk3399
<Ke> there are some decent electronics hobbyists where I work
<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
<vagrantc> yes, or that
* vagrantc has only booted mainline u-boot from microSD using miniloader
<Ke> hmm
<Ke> and yeah, I have the emmc disabled, I can see it being skipped
<Ke> SdmmcInit=0 0
<Ke> could that line mean that SD card bus is initialized
ayaka has quit [Ping timeout: 255 seconds]
<Ke> perhaps I missundersstood that page so that SD card can only be chainladed
<Ke> I guess I could try mainline u-boot
<Ke> obviously it could be, that this board is broken beyond just the emmc
<Ke> so my first stage loader should have been at sector 64 rather than sector 0 originally?
<beeble> yes
<beeble> 32k offset for the first stage
<Ke> SdmmcInit=0 20
<Ke> apparently that code is different when sd card is missing
<Ke> guess there is hope
<Ke> which u-boot image should I place there, I assumed u-boot-spl-nodtb.bin
<Ke> which got ignored
<beeble> if you try to boot a spl you have to prepare it with mkimage
<Ke> well I just want to boot anything to make sure I get at least something right
<beeble> i don't know where you get your u-boot-spl-nodtb.bin from
aalm has joined #linux-rockchip
<Ke> mainline u-boot with make ARCHV=aarch64 CROSS_COMPILE=aarch64-linux-gnu- firefly-rk3399_defconfig
<beeble> you should read board/rockchip/evb_rk3399/README
<beeble> there are some spl patches for firefly missing. so you will still need miniloader
<beeble> the evb readme describes you how to do that
<Ke> thanks, will do
<Ke> yeah, seems to be what I wanted
nasuga has quit [Ping timeout: 246 seconds]
ayaka has joined #linux-rockchip
<topi`> does the rk3399 have 1MB or 2MB l2 cache?
<beeble> 1mb for the a72 and 512kb for the a53
<Ke> yeah, I guess there are definite signs of SD boot being possible, I just seem to be not able to do it
<Ke> rkbin repo changed a bit since that doc was written, even when checking out old revisions is possible, it does not do, what I want
<Ke> I guess I'll postpone, until I have time to study things more thoroughly
cyteen has joined #linux-rockchip
<Ke> beeble: thanks for help
<Ke> and others again
JohnDoe1 has joined #linux-rockchip
JohnDoe_71Rus has quit [Ping timeout: 260 seconds]
nasuga has joined #linux-rockchip
afaerber has joined #linux-rockchip
afaerber has quit [Quit: Leaving]
akaizen has quit [Max SendQ exceeded]
akaizen has joined #linux-rockchip
aalm has quit [Ping timeout: 264 seconds]
nasuga has quit [Ping timeout: 240 seconds]
lkcl has quit [Read error: Connection reset by peer]
lkcl has joined #linux-rockchip
nasuga has joined #linux-rockchip
nasuga has quit [Ping timeout: 248 seconds]
gnufan has joined #linux-rockchip
JohnDoe1 has quit [Quit: KVIrc 4.9.2 Aria]
m0nt3 has joined #linux-rockchip
<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( 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:" 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/ 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
<m0nt3> then most likely that
<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 (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
<amstan> grr, why is my paste not working
<amstan> 3288 is in the MALI-400 series bucket
<m0nt3> oh, i was talking with a few people in #lima earlier, and i do plan on contributing to it. however, support for t764 isn't there yet, so....
<m0nt3> oh
<amstan> maybe? no?
<m0nt3> i have T764
<m0nt3> i wish i had the 400
<amstan> nvm, seems that i'm wrong
<amstan> we're just hopeless
<m0nt3> its cool. some day soon, hopefully in the next 2 years, there will be solid support for it.
<amstan> "soon" :)
<m0nt3> i'll be on this board until it dies, so i'll still be at it
<amstan> it's encouraging seeing support for so many options (including wayland)
<m0nt3> looked into that too. it seems that i have looked into every available documentation of gpu for T7xx series.
<m0nt3> it is
<amstan> it just has to match the ddk (i think)
<m0nt3> true
<amstan> you def can't do that with the upstream kernel, you'll have to modify it
<m0nt3> yeah. that's what i have been trying to accomplish. unfortunately, i'm still missing a few parts
<m0nt3> thanks for the pointer towards ddk though
<amstan> it's in the first paragraph, with a link to
<m0nt3> oh, yeah, i've seen the pages. i'm just looking for a way to do it, as i've only found bits and pieces on how to do so
<m0nt3> this is one of the few times i've been building a kernel by hand
<m0nt3> haven't had reason before
<amstan> yeah, it's not trivial..
<m0nt3> that i am finding. i also have been unsure which kernel to use with what modules and such
<m0nt3> oh, and that dts file
<m0nt3> i mean, i have lots of docs saved, but using them to build something worthwhile is the hard part
<amstan> given that i've already seen my setup work with the chromeos kernel i believe that'll be the easiest way for you
<m0nt3> using debian?
<m0nt3> or arch?
<amstan> arch
<amstan> linux-veyron, xf86-video-armsoc-rockchip, veyron-libgl
<amstan> don't use the upstream kernel (unless you want to be patching DDKs in)
<m0nt3> using the kernel from the archlinuxarm page?
<amstan> essentially you just follow the instructions from
<amstan> ignore the "Mainline Kernel" section
<m0nt3> oh
<m0nt3> maybe i should have tried that one
<amstan> you can run egl_glxgears and egl_info (i might have forgotten the exact commands) to test the setup when ready
<amstan> it should say mali midgard in the vendor field
<m0nt3> alright
<amstan> and disclaimer: i have not tried running that in quite a while, it might be broken
<m0nt3> it probably is.
<amstan> though you might have the option to downgrade your kernel, something from Dec 2015 should be ok
<m0nt3> oh