<lkcl>
does anyone have a recommended dtb and kernel for the firefly that actually works?
<vagrantc>
the one shipped in debian jessie-backports, stretch or sid work for me
<vagrantc>
though i just run headless machines
<vagrantc>
so there may be features that don't work
<vagrantc>
lkcl: but it works for serial console with rootfs on USB, ethernet works, detects all CPUs and ram (though the ram detection is in recent versions of u-boot)
<vagrantc>
don't think i've successfully loaded u-boot from eMMC, just microSD
vagrantc has quit [Ping timeout: 252 seconds]
jason____ has joined #linux-rockchip
<lkcl>
that's very helpful of vagrant... i'd say thank you but his irc client timed out :)
vagrantc has joined #linux-rockchip
<lkcl>
vagrantc: thx
<lkcl>
vagrantc: i've got microsd u-boot working
<vagrantc>
lkcl: glad it was helpful.
* vagrantc
waves
vagrantc has quit [Quit: leaving]
<stdint>
there is a bug in u-boot for firefly
<stdint>
you need a patch to boot from emmc, because it does not have a maskrom button
jason____ has quit [Ping timeout: 260 seconds]
dlezcano has quit [Ping timeout: 260 seconds]
zzarr has joined #linux-rockchip
matthias_bgg has quit [Quit: Leaving]
muvlon has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
dlezcano has joined #linux-rockchip
matthias_bgg_ has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 258 seconds]
npl has joined #linux-rockchip
<lkcl>
stdint: ah appreciated.
<lkcl>
stdint: btw do you have a firefly, and if so what kernel source and dtb do you use?
eebrah_ has joined #linux-rockchip
twink0r has quit [Ping timeout: 258 seconds]
eebrah has quit [Ping timeout: 258 seconds]
lkcl has quit [Ping timeout: 258 seconds]
lerc_ has joined #linux-rockchip
lerc has quit [Ping timeout: 258 seconds]
phh has quit [Ping timeout: 258 seconds]
twink0r has joined #linux-rockchip
phh has joined #linux-rockchip
lkcl has joined #linux-rockchip
libv_ has joined #linux-rockchip
libv has quit [Ping timeout: 260 seconds]
npl has quit [Quit: Page closed]
npl has joined #linux-rockchip
libv has joined #linux-rockchip
libv_ has quit [Ping timeout: 240 seconds]
<stdint>
lkcl, I only use upstream kernel
<stdint>
both firefly release and reload
<stdint>
you could find a kernel fork on my github
<npl>
(im getting a little bit confused with those multiple pseudonyms)
<npl>
I am trying to get GPU acc working with my Firefly RK3288 (non-reloaded) and starting with this
<stdint>
npl, there is a little problem with pwm and edp there
<stdint>
but the gpu is fine
<stdint>
this month I am very busy with HEVC decoder, have no time to fix it
<npl>
I doubt I need this if I use HDMI?
<stdint>
I don't have hdmi screen so I never test it
<stdint>
I only have vga and dvi screen at home
<stdint>
but the kernel 4.4 work for it
<npl>
Which of the 3 userspace mali drivers am I gonna need? theres a fbdev, a X11 and a Wayland one
<muvlon>
well, do you want to use X, wayland or just a raw fbdev?
<npl>
i just wonder that they are exclusive. X and Wayland (Gnome with debian stretch)
<stdint>
none, there is a xserver fork which supports mali
<stdint>
in ugly way
<npl>
lol, now I am terminally confused. you`d still need the userspace since the Graphics apis are supported there (OpenGL, and hopefully Vulkan)
<npl>
are you saing I cant get gnome to work with either of them, but I need a xserver fork?
<stdint>
we never make the standard x work on this platform or it would work very slow
<stdint>
I think there is a driver in xserver which supports drm driver
<stdint>
but the rockchip xserver fork use opengl from mali and drm at the same time
<npl>
sounds like wayland cant come soon enough
<npl>
the xserver fork then has the mali userspace included?
<stdint>
no, the mali is packaged as an independence library
<stdint>
you could find it at rockchip-linux
<stdint>
somebody plan to offer wayland, but it won't be in short time
<stdint>
such as the hevc driver and userspace is ready for beta
<stdint>
but still under internal review
<npl>
lotsa important information, would`ve used ARMs drm and userspace
<npl>
so to sum up, my best bet is using your branch, the userspace from rockchip-linux and plain old X11
<npl>
is this a general problem with ARM mali and X11, I was assuming alot platforms would run on these
eebrah_ is now known as eebrah
ayaka has quit [Read error: Connection reset by peer]
ayaka has joined #linux-rockchip
paulk-collins has joined #linux-rockchip
<lkcl>
stdint: i'm getting output on the early printk console but it's like the dtb file is complete garbage or something
<lkcl>
Failed to find PMU node
<lkcl>
rockchip-pinctrl ff770000.pinctrl: bank gpio0 is not valid
<lkcl>
rockchip-pinctrl ff770000.pinctrl: bank gpio1 is not valid
<lkcl>
rockchip-pinctrl: probe of ff770000.pinctrl failed with error -22
<lkcl>
of_amba_device_create(): amba_device_add() failed (-2) for /amba/pdma@ffb20000
<lkcl>
finally, even though console=ttyS0, i get this:
<lkcl>
rockchip-saradc: probe of ff100000.adc failed with error -22
<lkcl>
NET: Registered protocol family 17
<lkcl>
bootconsole [earlycon0] disabled
<lkcl>
Registering SWP/SWPB emulation handler
<lkcl>
and that's the last thing that's displayed
afaerber has joined #linux-rockchip
<lkcl>
stdint: ok so there's no config specifically for the firefly at https://github.com/hizukiayaka/linux-kernel/ in either the dev-4.4 or the gpu branch, but i am seeing a rockchip_linux_defconfig
<lkcl>
however i have absolutely no idea what i'm supposed to set, and i'm keenly aware that the PMIC could potentially be set with dangerous values - completely wrong voltages - that could destroy a board.
<lkcl>
is there a documented working kernel config that is available that matches that exact kernel which is known to work on the firefly?
afaerber has quit [Ping timeout: 245 seconds]
afaerber has joined #linux-rockchip
<npl>
lkcl: are you sure you are setting the right fdt address in u-boot? There is one fdt bundled in u-boot, and it wont work well if at all with the kernel
<lkcl>
npl: no i'm not sure... as in, this is the first time i've dealt with this
<lkcl>
oh, do you mean "am i using the fdt from u-boot"? no
<npl>
I cant vouch for the branch, but I built a kernel from 4.8 mainline some time ago with multi_v7_defconfig
<lkcl>
i'm using the one from the linux kernel source
<lkcl>
npl: what happened? you used the rk3288-firefly.dtb and it worked fine?
<npl>
with mainline kernel, yes
<lkcl>
ok great, i'll try that. now. what kernel cmdline did you use?
<npl>
I looked at the gpu branch yesterday and din`t found any alarming changes
<lkcl>
aaand... nada (ok, lots of earlyprintk but nothing else)
<lkcl>
ok then i have a starting point.
<npl>
I have the exact commands at home, not here at work
<lkcl>
npl: ack. no problem so it's just straight "git checkout v4.8" something like that?
<npl>
yeah, it should work fine
<lkcl>
awesome.
<npl>
appart from the missing gpu and some usb troubles
<lkcl>
yeah that i don't mind - i just need a starting point, y'know?
<npl>
you just need to enable rockchips mmc drivers and a few more so you can access root
<lkcl>
npl: ahh.... ok.
<npl>
or you build a ramdrive, but I found this to be errorprone and icky
<lkcl>
ok... hmmm.... let me do a compare against the rk3288-firefly-defconfig, see what it comes up with...
<npl>
(I also loaded up the stock kernel from debian, with the 4.8 dts akair)
<npl>
afair
<lkcl>
yeah vagrantc managed that as well: i prefer to actually compile something up
<npl>
no problem, I did that out of desperation, since nothing worked initially =)
<lkcl>
so i have a "known starting point" - remember, i'm developing my own hardware so i need to know what to adjust... can't do that if i don't have a working starting point!
<lkcl>
okaaay... CONFIG_MMC_DW_ROCKCHIP=y is set and common between the two configs (4.8 and rk3288-firefly-defconfig)...
<npl>
hmmm, you might need a few more, think a voltage regulator. but you should be able to boot
<npl>
and you can lsmod to see what else is needed
chris2 has quit [Ping timeout: 250 seconds]
<lkcl>
wow there's a whole stack of crap enabled in the multiv7 config :)
<npl>
beats something that doesnt work
<lkcl>
:)
<lkcl>
okaaay, ACT8865 is enabled (built-in) in the multiv7 config sooo that shouuuld be okaay...
chris2 has joined #linux-rockchip
<lkcl>
i don't really like enabling make -j3 or greater on this laptop, it tends to push it a bit harder than i'm comfortable with
* lkcl
just had an SSD fail without warning. f*****g thing
<lkcl>
okay! built. let's try it...
<npl>
you could use ccache, and then spend 2 days hunting mysterious issues
<lkcl>
aaand nothing. wtf??
<lkcl>
i like ccache - i find it works well. just not using it now as i was using too much disk space a few months back
<lkcl>
ok so even earlyprintk is being ignored.
<npl>
lkcl, for earlyprinkt you need to configure the uart
<lkcl>
npl: ah duh :)
<lkcl>
npl: yep i have the rk3288-firefly_defconfig for that....
<npl>
i use ccache too, but it seems it doesnt picks up the changes in the kernel confi
<lkcl>
npl: i found that if you make major changes, best thing to do is a "make clean" then just use the fact that ccache picks everything back out *real* fast
<lkcl>
ccache only uses the gcc cmdline arguments and gcc version number on a sha checksum, to reproduce its stdout and stderr. that's all it does.
<npl>
I dare you to try it with the kernel, I am not exactly new to ccache =)
<lkcl>
it *really* shouldn't be causing "problems" per se
<npl>
ccache doesnt realize if the real compilation would pick up a similar named file *from another directory as before*
<lkcl>
npl: i did a "git bisect fest" once for about 3 days using ccache... did about... 100 compiles with it
* lkcl
*thinks*.....
<lkcl>
ohhh.... i get it: ccache should be using the cwd as well.... and what else....
<npl>
no.
<npl>
you can have a file with the same name in multiple dirs
<npl>
say you have asm/a.h and asm/armv7/a.h
<lkcl>
yes....
<npl>
you compile a with asm/a.h, ccache stores this
<lkcl>
ah. right. the "preprocessor" mode *should* catch that
* lkcl
is just looking up the man page
<npl>
now you cange the configuration and the compiler would prefer the path /asm/armv7
<lkcl>
npl: yeah i Get It. that's the case that "preprocessor mode" is supposed to catch
<npl>
ccahce doesnt knows this, it knows a wants asm/a.h and this file did not chagne
<lkcl>
whereas direct mode would, obviously, not know.
<npl>
yeah, and the default is direct mode
<lkcl>
i'm also looking at some stuff about CCACHE_BASEDIR which should also help...
<npl>
I brought ccache to our CI buildsystem and development, I know a fair bit about it.
<lkcl>
damnit. still no output
<lkcl>
argh let's just try the rk3288_firefly-defconfig
<lkcl>
npl: any chance when you're at work tomorrow you could email me that working multiv7 config you set up for v4.8 mainline? luke.leighton@gmail.com
<npl>
hmm, you have to change like 3 options for the uart
<npl>
sure
<lkcl>
npl: unless i know exactly what to change, and to what, i'm guessing blind, 3 options or not.
<lkcl>
YAY! okaaay, i got earlyprintk *and* console, whew.
<lkcl>
that's with 4.8 and the rk3288_firefly-defconfig
<npl>
I actually found the .config on USB, is that any help?
<npl>
if you got it working, dont mind ;)
<lkcl>
npl: yes please
<lkcl>
i got a boot.... but it's full (again) of "rockchip-pinctrl ff770000.pinctrl: bank gpio0 is not valid
<lkcl>
"
<lkcl>
gpio1 not valid
<lkcl>
...
<lkcl>
...
<lkcl>
gpio15 not valid
<lkcl>
which probably goes a looong way to explaining why absolutely none of the peripherals are up and running
<lkcl>
ok it's not hugely fast, but not "ridiculous"
<npl>
I had to wait *minutes* for the page to load
<lkcl>
npl: yeah.... that's how long it takes for me to load up gmail over a VPN from shenzhen... and that's the "basic" version. i did some investigating and i was getting TEN kilobytes per second
<lkcl>
here in zhuhai i'm getting anywhere between 20 and 50k/sec which is enough to be able to use the standard version
<npl>
dont you thing you should get a server to host the firefly website? =)
<lkcl>
bottom line: it's not you.... it's the pipe between china and the west
<lkcl>
an associated investigated (he has a server sitting on the big fat pipe in china) and found that it's EIGHTY PERCENT saturated with botnet traffic
<lkcl>
packet loss of 20% is "normal", and during that DDOS attack, packet loss was the other way round: 80%.
<lkcl>
completely insane
<npl>
somehow I managed to live without mobile phone and inet 20 years ago. I dont remember how
<lkcl>
okaaay we're getting somewhere
<lkcl>
npl: haha. i bought a dual-sim GSM-only phone for exactly that reason
<lkcl>
okaaay, so i'm getting sdhc recognised now
<lkcl>
[ 1.128746] sdhci: Secure Digital Host Controller Interface driver
<lkcl>
[ 1.135264] sdhci: Copyright(c) Pierre Ossman
<lkcl>
[ 1.150182] sdhci-pltfm: SDHCI platform and OF driver helper
<npl>
did you use rootfs= as key instead of root= ?
<lkcl>
didn't set rootfstype....
<lkcl>
npl: for mmcblk0p2 is that partition 2 or partition 3 you're intending to refer to?
<lkcl>
i have two partitions, the 2nd is the one i want as root
<npl>
mmcblk0p2 is 3rd partition
<lkcl>
oh.... apparently i did set rootfstype... to ext4
<lkcl>
npl: ack
<npl>
I have a fake uboot partition and a boot part before the filesystem
<lkcl>
npl: yeah for me i have a real boot partition, containing the zImage and dtb file. and a few useful scripts (mkbootimg.sh for example). and boot.scr
<lkcl>
does anyone else get " rockchip-pinctrl ff770000.pinctrl: bank gpio0 is not valid
<lkcl>
"
<lkcl>
mmind00: ^
<lkcl>
npl: ^
<lkcl>
?
<lkcl>
rockchip-pinctrl ff770000.pinctrl: wrong pins number or pins and configs should be by 4
<lkcl>
hmmm....
<mmind00>
lkcl: nope on 4.9-rc5
<lkcl>
mmind00: ok... i can probably try that next - i at least am getting debug output.
<lkcl>
mmind00: and that works well for you, does it? (for a firefly)?
<npl>
lkcl: cant tell now, firefly is not with me. And its resting in software pieces ATM since the last setup was a mess and I am redoing it
<lkcl>
npl: :)
<mmind00>
lkcl: depends ... mainline is of course the cleanliest, but our use-cases of course differ very much, as I'm mainly doing development / maintenace on them and don't have any target project I want to use them for
<mmind00>
lkcl: so everything is mounted into a netboot farm, but also my rk3368-based central unit is running mainline, as I generally simply don't tinker with forked kernels ;-)
<lkcl>
mmind00: my current goal is to get something - anything and i mean absolutely anything - up and running.
<lkcl>
3.10, 4.8, 4.9.999rc999
<lkcl>
i genuinely don't care as long as i can get an OS boot.
<lkcl>
3.10 from t-firefly.com segfaulted on reading the emmc, so that's out for now
<lkcl>
but, also, as i'm developing my own *hardware*, keeping up-to-date would seem to be a sensible idea :)
<lkcl>
i shouldn't need to be doing any kernel devwork (yet) but will _definitely_ need to make a new dts
<lkcl>
it's gonna be fuuuun
* lkcl
thinks....
JohnDoe_71Rus has joined #linux-rockchip
<lkcl>
btw... am i supposed to do any "munging" of the dtb file before loading it into memory?
<lkcl>
for the sunxi stuff it was possible to just use fatload mmc 0:1 0x490000 sunxi-a20.dtb
<lkcl>
and that was enough
<mmind00>
lkcl: don't know, I'm always just using FIT images in my setup
* lkcl
goes to look up FIT on acronymfinder... ahhh ok :)
<lkcl>
ah ha!
<npl>
depends, if you have a recent u-boot it does the "munging" for you
<npl>
if you mean that the loader will add some informations
<lkcl>
npl: it's a recent u-boot
<lkcl>
npl: yes. add something at the front to make the linux kernel recognise it...
<lkcl>
but i'm loading it direct into memory, so...
<npl>
just do a bootz ${kernel_addr_r} - ${fdt_addr_r}
<mmind00>
npl: I just converted to sjg1_ 's uboot network-branch yesterday ... so now my firefly is now finally free of the legacy uboot
<npl>
works fine for me
<npl>
how old is that branch? I took the patches from him and made my own branch
<mmind00>
npl: Simon resurrected (and adapted) the patches 3 days ago to include them finally (http://git.denx.de/?p=u-boot/u-boot-rockchip.git;a=shortlog;h=refs/heads/gmac-working)
<npl>
(I branched of 2016.11 and had to fixup some of his patches)
<npl>
oh great
lkcl has quit [Ping timeout: 248 seconds]
lkcl has joined #linux-rockchip
<lkcl>
ok i got it - wrong dtb name (older, wrong one)
<lkcl>
ok that's better
<mmind00>
lkcl: also ... just refreshed and build 4.9-rc7 using multi_v7_defconfig ... works just fine :-)
matthias_bgg has quit [Ping timeout: 250 seconds]
<lkcl>
mmind00: helps if i use the right dtb binary, right? :)
<lkcl>
mmind00: getting somewhere...
<mmind00>
lkcl: yep that might be a tiny bit helpful ;-)
<lkcl>
aw fer f***'s sake, "couldn't mount ext2 due to feature incompatibilities"
<lkcl>
*sigh*....
<lkcl>
fortunately i've had this happen before - i had to remove some features like 64bit or... something.
<lkcl>
i'll recognise it when i see it...
<lkcl>
hooraaay!
<lkcl>
thank you both of you
<lkcl>
npl: ^
<lkcl>
mmind00: ^
* lkcl
is very happy
<npl>
you are welcome
<npl>
are you planning to get a graphical environment and GPU support running?
<npl>
gonna be my next target, but this seems complicated since apparently a rockchip forked xserver is needed
<npl>
hoped it would be just a plain debian + mali drm and userspace
matthias_bgg has joined #linux-rockchip
matthias_bgg has quit [Remote host closed the connection]
matthias_bgg has joined #linux-rockchip
<lkcl>
npl: yes i am... i'll have to see how it goes. i'm happy with a plain framebuffer for now.
<lkcl>
my primary goal is: get something working, optimise later
<lkcl>
fbturbo would be the first priority
<lkcl>
mali is completely out of the question until it's been reverse-engineered
<npl>
hmm, trying to get this thing usable as desktop replacement or settop box. Means desktop should be fluid, browser should be easily playing highres youtube videos
<npl>
Some acceleration is key to that. I doubt we will see an OS Mali anytime soon
<npl>
but I would be interested to RE it, just someone has to take care of my expenses if I quit work =)
<lkcl>
npl: keep in touch, then: at some point i'd like to help do a crowd-funded mali reverse-engineering effort
dlezcano has quit [Remote host closed the connection]
<npl>
I was kidding, at least a bit. I would be interested and have some experience with RE - but that also means I know how much work it is
npl has quit [Quit: Page closed]
dlezcano has joined #linux-rockchip
afaerber has quit [Quit: Ex-Chat]
vagrantc has joined #linux-rockchip
muvlon has quit [Quit: Leaving]
<sjg1_>
mmind00: Great! You could send a Tested-by report to mainline
<mmind00>
sjg1_: done (as reply to the mails about the 100/1000 hickup)