<amstan>
bashintosh: he's been in front of a fancy scope for a few weeks, trust him :)
<bashintosh>
amstan: that's sad news already then... :(
<amstan>
yeah :(
<akaizen>
Is it possible to use an external clock / crystal?
<amstan>
the only good news is that if your tv accepts the more jittery clock you could perhaps go out of spec and still do 4k at 60Hz
<amstan>
akaizen: i forgot what the values were, but from what i remember only like 10% of the jitter was caused by the xtal, the rest was added by the pll
<akaizen>
ok. I'll take this info to the hardware guys
<akaizen>
Are you guys based out of MTV?
<amstan>
yes
<akaizen>
Cool cool :) Do you get to work with the go-lang folks?
<bashintosh>
At the moment I can't get 2k at 60Hz(FPS) with a relatively common DCLK (268MHz) - had to force a different parent PLL (NPLL specifically) to get close to the target Fout - got 250MHz. The LCD image fades out after some time. Mmmh.
<amstan>
i think we had 2k working at 297MHz
<amstan>
maybe that was 4k
<amstan>
bashintosh: which tree are you using?
<bashintosh>
amstan: 3.10 Rockchip
<amstan>
bashintosh: i think there's been quite a few improvements since in both upstream and chromeos 3.14
<akaizen>
How is the HDMI-CEC support?
<amstan>
akaizen: not good
<akaizen>
lol
<amstan>
we just have wakeup from cec and that's it, anything more required libcec and we didn't want to use up too much time on it
<bashintosh>
amstan: mmh I have involved Rockchip which is munching through logs/patches I sent them but if I can't solve it by this week I'll get back on trying chomeos 3.14
<akaizen>
amstan: Ah so the hardware and driver exists and support it - just a matter of writing the higher level functions (or using lib-cec)
<amstan>
maybe?
<akaizen>
Why maybe? If the wakeup is working, the basics are there right?
<akaizen>
I was looking forward to the release which I read was summer but summer is over
<amstan>
yeah.... :)
<akaizen>
karlp: ah nope, they cancelled it
<akaizen>
I got a developer stick at their event though
<karlp>
it sounded like it was obsolete by the time they even announced it wasn't it?
<karlp>
rk3066?
<akaizen>
yea
<amstan>
oh... it wasn't the 3288?
<akaizen>
Well, having solid software platform is more important than bleeding edge performance IMHO
<karlp>
yeah, well, firefox os exploratory work wasn't the path for that...
<akaizen>
look at raspberry pi
<amstan>
yes, but i tought 3288 was better supported upstream than 3066
<akaizen>
lol
<akaizen>
b2g is mostly Android stuff and then HTML apps on top
<amstan>
so.. 3.10?
<akaizen>
Yes, maybe even 3.1?
<amstan>
lol
<akaizen>
3066 has been out longer so I figure better supported
<akaizen>
its also much cheaper now like <$10
<akaizen>
So more people using it
<karlp>
yar, but when the 3066 boards came out it was android 3.0.36+ shitz that was a nightmare, and the cool people were working withthe 3188, and around that time and then 3288 all the rk people got in on upstreaming
<karlp>
3066 has some trickle down, and it should work if you follow mmind/rperier, but it's clearly not nearly as tested as 3188 and newer.
<amstan>
akaizen: so yeah... i suggest you get a chromebook ;) get archlinux arm on it and try all the things to get the higher clock out of it
<amstan>
i might make an arch package soon for mmind's 4.2
<amstan>
kernel
<akaizen>
Is mmind's 4.2 available somehwere?
<karlp>
the 3066 boards were all pre device tree too, so you had to find the actual source of the right hardware you had to try and work out any extra hardware.
<akaizen>
I was just so excited when the first mk802 came out :)
<akaizen>
amstan / mmind00: Do you know what bootlaoder is used to boot 4.2 and debian?
<akaizen>
Specificalyl on the firefly?
<akaizen>
brb second lunch
<amstan>
i haven't done fancy stuff on the firefly(besides booting the sample android and loling at the 100C cpu temperature that the demo makes it go at)
<amstan>
so you'll have to wait for mmind, he's on GMT+1 time
<akaizen>
lol 100C?
<akaizen>
what demo is this
<amstan>
the gpu demo
<amstan>
the 4 screen split, they have a video playing, a random cube spinning and so on
<akaizen>
impressive, I only got to 65 / 70c
<amstan>
did you have a heatsink?
<akaizen>
nope
<amstan>
mine was at 100C somehow.. lol
<akaizen>
I used thte stability test gpu + cpu stress
<bashintosh>
amstan: same, never seen 100C even after hours of stress loads..
<akaizen>
maybe it was throttling
<akaizen>
amstan: was this linux?
<amstan>
from the android distro that the firefly comes with
<akaizen>
whats your ambient? did you use an enclosure or just the acrylic case?
<amstan>
no enclosure, 21C probably(office building)
<amstan>
maybe a light breeze
<akaizen>
haha thanks for the specifics :)
<akaizen>
sounds strange
<amstan>
i also have a desk fan for occasions like that, but i didn't use it at the time
<akaizen>
surprised it didnt catch fire
<amstan>
well, 100C is still fairly low for fire territory
<akaizen>
RK specs say thermal limit is like 90C I think
<bashintosh>
wouldn't it shut itself off at some point anyways?
<amstan>
yes, if it has the limits set
<bashintosh>
fire would be cool too see though :)
<akaizen>
yea, but if it starts melting no guarantees
<bashintosh>
ah right
<amstan>
it is a fire..fly after all
<bashintosh>
ahah +1
<akaizen>
lol you jokesters
<bashintosh>
:)
<amstan>
no offence to the board, it is a cool board
<akaizen>
ba dum tss
<amstan>
i just think it needs some heatsinking before throwing 3.10 with android on it
<akaizen>
crazy story of how i met those folks in shenzhen
<akaizen>
awesome people :)
<bashintosh>
just tried the RR2 - another world - they use EHCI USB controller and it solved TONS of issues compared to the FF
<bashintosh>
build quality is awesome and comes with the SoC on a module - pretty cool
<bashintosh>
re: dwc2 yes
<akaizen>
Oh they are available again!
<amstan>
i can't complain too much about dwc2 actually, besides the 5% performance hit, it works pretty well
<bashintosh>
no storming when using EHCI instead of DWC-OTG controller
<amstan>
it's the main usb ports on the chromebooks, so.. if it didn't work..
<akaizen>
interrupt storm sounds like some RTS spell
nighty^ has quit [Quit: Disappears in a puff of smoke]
<amstan>
that's what it is though
<amstan>
watch -n 0.1 cat /proc/interrupts
<amstan>
and plugin a usb device
<amstan>
you'll see that number increasing by 1000s every second
<bashintosh>
akaizen: it is terrible on the FF - HID devices go mad, 'sticky keys' issues and crackling sound when using external audio codecs (USB)...
<amstan>
try 3.14 :)
<amstan>
or 4.2
<amstan>
how do you think people are supposed to connect usb keyboards to the chromebit when they'
<amstan>
don't want to get bluetooth
<bashintosh>
amstan: don't you use EHCI on Chromebooks?
<amstan>
only for the builtin webcam
<amstan>
the 2 external ports are dwc
<amstan>
one of them is the otg
<bashintosh>
then the driver (DWC2) solved your issues I guess
<bashintosh>
Really need to get onto 3.14 :(
<amstan>
it's still storming, but it's not glitchy
<akaizen>
hmm i tried it and didnt see a storm
<akaizen>
i only plugged in usb mouse
<amstan>
just keep in mind that 3.14 only has dts files for the chromebooks
<amstan>
so no idea how you can get it working on the firefly easily
<akaizen>
dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb2 or dwc_otg, dwc_otg_hcd:usb3
<bashintosh>
yes I killed a stick a few weeks ago while preparing the DTS from Chomebook kernel - different PMIC
<amstan>
i frequently booted the 4.2 kernel without the proper dts files on chromebooks
<amstan>
it tried loading firefly
<akaizen>
dwc_otg, dwc_otg_hcd:usb3 just keep increasing furiously non-stop
<amstan>
but nothing bad happened
<amstan>
akaizen: dwc_otg(whatever the raspberry pi uses) mitigated the storm by moving the interrupt to an fiq
<bashintosh>
it was my bad, I messed the PMIC nodes in the DTS without too much care... Didn't like it..e
<amstan>
so it still happens, but a lot less code executes every interrupt
<amstan>
so it's a lot faster
<amstan>
part of that removed code might be the kernel interrupt counter, so you might not even see it increase
<akaizen>
bashintosh: have you tried your 2K diplsay on RR2?
<akaizen>
On my firefly: Linux firefly 3.10.0 #40 SMP PREEMPT Tue Jan 27 16:12:04 CST 2015 armv7l armv7l armv7l GNU/Linux running ubuntu
<bashintosh>
akaizen: the issue (at least here) is very visible if you use external hubs + multiple HIDs (say keyboard + mouse + touchscreen)
<bashintosh>
akaizen: not yet but I think the PLL issue would still be there
<akaizen>
do they use the same PLL
<akaizen>
is it SoC specific or board level?
<bashintosh>
SoC, embedded
<akaizen>
well damn :/
<bashintosh>
yeah, I hope Rockchip comes back with something but I am scared about the jitter I read a few lines above... :(
<akaizen>
I saw the ODROID-XU4, its only 79$ and has octa core ARM.bigLITTLE good for pure compute
<akaizen>
15W I'm told
<akaizen>
Only hdmi 1.4 :/
naobsd has joined #linux-rockchip
<amstan>
akaizen: there he is(naobsd)
robogoat has quit [Ping timeout: 260 seconds]
robogoat has joined #linux-rockchip
<akaizen>
amstan: thanks!
cappybob has joined #linux-rockchip
<akaizen>
naobsd: looks like lots of progress with linux-rockchip! :)
<akaizen>
naobsd: Seeing a lot of cool projects being worked on in different areas so I'm wondering how it all ties together.
<akaizen>
[ asking naobsd becasue hes one of the maintainers of linux-rockchip but really this is open to all in the community! :) ]
<naobsd>
akaizen: well, what projects specifically? usually if I found something cool, I try to invite here. but anyone can invite.
<naobsd>
no need to ask me to do it
<karlp>
what is "FF" bashintosh?
<karlp>
firefly I guess...
<akaizen>
I've been catching up with some folks here in chat
<akaizen>
so far: people are working on ChomeOS, barebox, u-boot + open SPL, coreboot/depthcahrge
<akaizen>
More clearly, my questions is: what are the goals for the community?
<akaizen>
I have to catch the train, but I'll catch up on the logs :)
<naobsd>
reading irc log now...
akaizen has quit [Remote host closed the connection]
<amstan>
akaizen: i think we're just all in here for no reason
<bashintosh>
karlp: yeah sorry, Firefly :)
<naobsd>
amstan: agree
<naobsd>
ChromeOS is developed by ChromeOS project and contributors. Linux mainline is developed by Linux project(?) and contributors. same for barebox, u-boot, etc.
<naobsd>
some of guys of those projects are also stay here
<naobsd>
bashintosh: good to hear about EHCI on rk3288
<naobsd>
cappybob: sorry, what's the "a lot of timing issues addressed here"? I can see only SDK link
<bashintosh>
naobsd: yes it's a great relief - still using Rockchip kernel 3.10 but according to amstan 3.14 should also fix USB issues with DWC-OTG so keen to try that too!
<naobsd>
mainline on firefly might be easy to try
<cappybob>
naobsd this is SDK for rk3368 chip. With the availablity of AArch32 and AArch 64 alot of timing values are discussed.
<naobsd>
anyway I think dwc otg driver in RK 3.0/3.10 is not so good
<naobsd>
cappybob: I know that SDK(I already downloaded several days ago). what I'm not sure is "a lot of timing values are discussed". where I can see that discussion?
<bashintosh>
+1 re: dwc-otg driver - yes, it can work "fine" with maybe 1 USB device but forget about using USB hubs.. Plus IRQs storming is bad bad bad.
<bashintosh>
naobsd: where can I grab a recent mainline source from?
<cappybob>
naobsd primarily through the whole SDK, for every parameter you have a 64Bit or a 32Bit set-up generally in the .c files.
<naobsd>
cappybob: well... I know there are .c files in SDK. I can read them myself. what's "a lot of timing issue"?
cnxsoft has joined #linux-rockchip
<naobsd>
cappybob: that SDK addressed/discussed some issues?
<bashintosh>
naobsd: thaaanks!
<naobsd>
ah, arm-soc tree might be better than linux-next?
<naobsd>
rperier's meta-rockchip for yocto might be handy to try mainline
<naobsd>
it seems I have to refresh my memory...
<cappybob>
naobsd yes many problems heard today on chat were discussed, just quick read of sdk to see what was possible with new chip.
<naobsd>
cappybob: on chat? here?
<naobsd>
I read yesterday/today log some minutes ago, but I can't find such a discussion
<naobsd>
if you are talking about PLL issue for 4K60p, I think what you need is scope, not (only) .c or datasheets
<naobsd>
and I'm not person who discussed about it
<naobsd>
in the past, I had to use a lot of time to explain some non-existing issue in Rockchip SDK. that fake issue was born by someone who cannot solve/achieve something because some issue was required to explain why it cannot be achieved.
<naobsd>
my output didn't have issue(because it's fake), but some people believed I have fix for it. I had to use a lot of time to explain I don't have fix because fix doesn't exist.
<cappybob>
naobsb sorry I wasted your time, there was no issue but just a new source to look at. No problem just more information.
<naobsd>
I don't want to use my time to explain non-existing issues for me anymore :(
<naobsd>
cappybob: thank you for your information about new SDK
<cappybob>
naobsd-san I fully understand.
<naobsd>
it will be better if someone make dev board with rk3368, and sdk with git history for it.
<naobsd>
dts is given with RK 3.10 kernel tree, nice, but it's possible to make board specific changes in .c. if we can see difference between board SDK and original Rockchip SDK, we can see such a change too.
<cappybob>
naobsd There are (2) dts the second in the Arch folder comment section, I believe. One 32Bit, the other 64Bit.
<cappybob>
naobsd We do need a git for this SDK, aarch64 with support fro foundation v8, and vexpress, should directly support linaro builds.
<cappybob>
There is also chromeo and ubuntu in this SDK.
<naobsd>
cappybob: what's chromeo(s?) and ubuntu in SDK?
<cappybob>
naobsd I guess to build, with this kernel and moduals I have drilled down and eventually end at the repos. SDK shows ubuntu, chromium, linaro, and android.
<naobsd>
cappybob: sorry, which SDK are you talking about? R68 SDK? can you point specifically?
<cappybob>
naobsd why we need git, shown on different folders r68, arch, arm64, but Ihave seen .build in comment section for these. Android is only given with the main page with android build
<naobsd>
cappybob: can you point "main page" specifically? I still cannot understand what you're talking about...
<cappybob>
This chip also from reading the arm discription has I believe the ability to be networked with the little indian chip for adding additional cores for the host unit.
ssvb has quit [Ping timeout: 240 seconds]
<naobsd>
sigh
<cappybob>
I am sorry for confusion, when opening SDK the comments section of the opening page has the sh.build for Android and no discription for linux, linaro,or chromium builds.
<naobsd>
I don't waste my time for non-existing thing anymore.
<cappybob>
naobsd good morning and have a nice day
ssvb has joined #linux-rockchip
cappybob has quit [Quit: Page closed]
naobsd has quit [Read error: Connection reset by peer]
naobsd has joined #linux-rockchip
<lautriv_>
darn, one of my sandisk extreme 64G SDXC cards now reporting a size of 1M :(
<lautriv_>
ok, so far i get this -> http://pastebin.ca/3148186 and nothing more, for me it looks like a try to start and fails somewhere in the early init of the kernel, thisone is a SD-Card image for radxa/ubuntu. I don't believe they use another UART but maybe don't use console on serial at all. suffestions ?
<lautriv_>
*sugg
akaizen has joined #linux-rockchip
nighty^ has joined #linux-rockchip
<lautriv_>
argh, just found this happens also when SD removed, so anything changed my flash ( i did not even touch rktool or even plugged OTG )
<mmind00>
akaizen: ah, forgot the bootloader question from the backlog ... chromebooks can boot external kernels directly via coreboot, the original rockchip uboot also boots kernels and Simon's mainline uboot patches are supposed to land any day now too
<sjoerd>
that branch also has my patches for booting from mmc \o/ so win
<sjoerd>
akaizen: You need to tweak the dts a bit to boot from emmc as the SPL from git always tries to load u-boot from SD
<akaizen>
Wow! This is very exciting. I'll need to update some documentation
<sjoerd>
akaizen: but that's a trivial tweak (once you know where)
<mmind00>
sjoerd: yep very great ... also had a nice chat with a Rockchip guy ... the rk3188 supposedly has the same ddr controller (except only 1 instead of 2 channels)
<sjoerd>
akaizen: and yeah i'm using that on my rock with a fimple GPT partition table and just one rootfs
<sjoerd>
mmind00: Oh so that might be trivial tweak then
<akaizen>
sjoerd: would you recommend RR2 or FF?
<sjoerd>
akaizen: I only use RR2 because a client of ours uses it as a reference for a product, i've got no experience with the FF
<akaizen>
RR2 pretty stable then?
<sjoerd>
I need to submit my patches for it to mainline still (devicetree etc), but i've been quite happy with it thusfar
<akaizen>
does the nand driver handle wear leveling?
<sjoerd>
RR2 is an eMMC
<sjoerd>
so there isn't a nand
<akaizen>
Sorry, I'm not to familiar with the difference w/ NAND vs eMMC
<akaizen>
Both are flash / solid state devices correct?
<mmind00>
akaizen: in a way ... emmc is like a sd card with a controller doing wear-leveling stuff inside the chip
<akaizen>
Ah ok. So the eMMC is a black box that presents a block device interface
<akaizen>
and handles the leveling behind the scenes with its own controller
<naobsd>
sjoerd: oh u-boot-rockchip branch! very nice :)
<mmind00>
akaizen: nand needs to do that in software ... also while the mmc controllers are nicely supported ... there is _no_ nand driver at all [as rockchip is keeping that secret due to their proprietary translation layer on top]
<mmind00>
akaizen: yep ... I think the general advice is to stay away from raw nand and use emmcs on Rockchip platforms if you value your sanity ;-)
ssvb has quit [Ping timeout: 252 seconds]
<akaizen>
So I build uboot and spl from the u-boot-rockchip branch
<akaizen>
then use updatetool to flash it?
<akaizen>
does it maintain LOADER mode to keep the device unbrickable?
<akaizen>
er MASK ROM
<sjoerd>
akaizen: mask rom is build into the SoC you can't remove it
<sjoerd>
akaizen: For testing i'd recommend flashing it to an SD card and booting from that, there is a readme file that explains how
<akaizen>
Thats what I thought .. some dev told me otherwise ..
<sjoerd>
akaizen: ooi what board are you using?
<akaizen>
Firefly, other custom RK3288 boards, and thining about getting a Radxa Rock 2
<sjoerd>
I think the firefly also has some instructions on how to force it to boot from SD ( the soc really wants to always try emmc first)
<sjoerd>
mmind00: oh btw did you try my u-boot network patches?
<mmind00>
sjoerd: I didn't try anything uboot related yet ... just following the development currently :-(
<sjoerd>
ah
<sjoerd>
akaizen: if you intend to play with firefly, i'd love it if you could test https://git.collabora.com/cgit/user/sjoerd/u-boot.git/log/?h=wip/rockchip-mmc-ethernet - which add support for the wired network card ot u-boot (so you can tftp boot and all that jazz)
<sjoerd>
should just work on firefly but only tried it on an RR2
<akaizen>
Sure - happy to test it
<akaizen>
Will PXE boot work as well?
<sjoerd>
yes
<sjoerd>
it's using the standard u-boot distro boot commands
<akaizen>
Cool. So it also supports signed images?
<akaizen>
but Seems this u-boot doesnt support HDMI yet
<sjoerd>
it doesn't
<sjoerd>
i don't know about signed images, that's not something that's platfrom specific i think?
ssvb has joined #linux-rockchip
<akaizen>
Possibly, but I thought / read that the code is supported in mainline uboot
<akaizen>
I'll also test if linaro toolchain works
<akaizen>
Cool, this should also make porting gentoo easier
<akaizen>
Do I go to sleep or get started on this ... :)
<sjoerd>
yeah should be far easier for normal dsitributions to support these devices now once this all lands
<sjoerd>
akaizen: hdmi support is somewhere on sjg's todo list though (i don't really care about it in u-boot tbh) and ofcousre your patchs are welcome ;)
<akaizen>
oh, kernel can still initialize and use HDMI then?
<akaizen>
oh so HDMI in uboot is like replacement for serial?
<akaizen>
Oh I hope we can get our boot time to <5 now!!
<akaizen>
So many exciting thingS!!
<sjoerd>
akaizen: yeah hdmi in the kernel works
<rperier>
hi all
<mmind00>
akaizen: for the vpu ... the chromeos kernel has support for it (encoding and decoding), but they depend on some v4l extensions that also haven't made it to mainline yet
<mmind00>
akaizen: haven't looked deeper yet though
<sjoerd>
mmind00: is it all open at least though ? (iirc for the nvida ones that part is still closed :/ while for exynos it's luckily open \o/)
akaizen has quit [Remote host closed the connection]
<sjoerd>
right similar but less polished then on the RR2 then
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 250 seconds]
<naobsd>
RR2 SoM released version has TP for it
<naobsd>
ah
<naobsd>
RR2 SoM released version has easy to access TP on top side
<sjoerd>
naobsd: TP ?
<naobsd>
beta version (which I have) is not ;)
<naobsd>
test point
<sjoerd>
ah yes
<sjoerd>
that's what i meant with it being more polished then on the firefly
<naobsd>
yes, RR2 SoM looks very nice :)
<naobsd>
(return to home...)
naobsd has quit [Quit: naobsd]
levd1 has quit [Quit: levd1]
apritzel has joined #linux-rockchip
<rperier>
sjoerd: btw, do you plan to send the dts to the ML ? (I did not see it)
<sjoerd>
rperier: yes, busy weeks and lots of stuff on my backlog i need to send upstream unfortunately
<karlp>
what do you people mean when you say "it has a ehci controller instead of dwc" ? dwc is an ehci implementation... ehci is just usb-hs...
<karlp>
bashintosh: that's for you I think really.
<rperier>
sjoerd: np :)
<sjoerd>
rperier: if you want to try, my wip's are in various git repos :)
<sjoerd>
but there are some hacks in there
<sjoerd>
and i also discovered that i was misled by the schematics and the pmic is on the som rather then the base board so need to move some bits around between those dts'
cosm has joined #linux-rockchip
cnxsoft1 has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 246 seconds]
cnxsoft1 is now known as cnxsoft
<rperier>
hobbyists: did you ever try to be sponsorised by the linux foundation (or equivalent) to go to a conference like ELP or LP ?
<rperier>
when I read the price as an hobbyist... that's expensive seriously :/
<rperier>
I mean, I completly understand that foundation ask companies to pay, but why hobbyist ? ^^
ssvb has quit [Ping timeout: 265 seconds]
<karlp>
linux isn't for hobbyiests anymore donchaknow.
naobsd has joined #linux-rockchip
ssvb has joined #linux-rockchip
<mmind00>
rperier: I regularly apply for the hobbyist discount (and get it granted without hassle) ... while 300USD ist still quite some money it is way better than the official fee
<mmind00>
sjoerd: btw. interesting, the memory controller itself also seems to be a Designware IP (with varying phys connected)
<sjoerd>
mmind00, rperier: the trick is to give talks ;)
<sjoerd>
mmind00: heh
<mmind00>
sjoerd: talks are really fun, but so far I'm still a bit to afraid to leave my mother tongue behind for the big audience ;-)
<sjoerd>
mmind00: btw the memory controller stuff reminded me, do you know if the timimgs and all the other settings alre also the same over various board/socs?
<mmind00>
sjoerd: I'm just trying to learn what all this memory stuff is doing ... so far I simply seem to have taken running memory for granted ;-)
<sjoerd>
oh i do too
<mmind00>
sjoerd: but it also looks like the upstream sources are very forthcoming with information
<sjoerd>
I'm a bit wary of touching those areas as it can cause fun subtle bugs
<mmind00>
in the worst case, you can simply read the information the proprietary loader puts in there
<sjoerd>
when skimming over the init code simon did i wasn't entirely sure of that
<mmind00>
from what I've seen so far all of rk3066, rk3188, rk3288 and even rk3368 use the same Designware memory controller, and all except the rk3368 also seem to use the ddrphy
<sjoerd>
whether one could retreive all information, it seemed like some things were setup by consequitive rights to one spot
<sjoerd>
nice
<sjoerd>
mmind00: once i have some random time to spare again (hah), i'd really love to first try getting the close loader to chainboot a u-boot image
<sjoerd>
then at least one can prod at some basiscs before entering that territory
<mmind00>
the interesting question might be, how strict the uboot people see the whole devicetree stability thing ... as I don't think the current dmc binding will live happily ever after
<karlp>
what's the alternative? they just keep having to have custom board support compiled in?
<sjoerd>
probably not very :p
<sjoerd>
karlp: alternative to what?
<karlp>
not looking at the devicetree
<mmind00>
sjoerd: that's nice to hear ... don't want to hinder Simon's work to much :-)
<sjoerd>
karlp: oh recent u-boot uses devicetree, but it has to be compiled into at least the spl
<rperier>
karlp: that's a free/libre software, even if a lot of companies use linux and send a lot of upstream contribution, I assure you that there are still a lot of hobbyiests...
<sjoerd>
and currently also be compiled into the u-boot image, although i guess in principle the spl could load that dynamically but i'm unsure how bit the use-case is foor that
<karlp>
rperier: sure, but there's an awful lot of employed people doing the major work now,
<rperier>
sjoerd,mmind00: even if agree, it is way better than the official fee... I don't really understand the concept behind... an open source foundation like it should really care about that, the base of libre and free software philosophy are : free, clearness, redistribution and "share knowledges"
<sjoerd>
rperier: Not sure about the LF, at least for guadec the gnome foundation does sponser students/hobbyist/contributers as well
<rperier>
sjoerd: the trick is to give talks ;) => hehe I know, I want to go to the conference first, to see how it works how many interesting people and conferences there are etc... perhaps later, why not
<rperier>
:)
<sjoerd>
and ofcourse fosdem is free for all but that's a rather different conference to the embedded linux ones
<apritzel>
rperier: isn't there more support for hobbyists from LinuxFoundation beside the reduced fee, like travel and lodging support?
<rperier>
yeah fosdem is really cool (technically too), but as you said rather different that the embedded linux ones, I guess...
<rperier>
apritzel: I don't know... perhaps that Heiko has more details... as I understood this is only for the conference itself (the ticket)... it's not a big deal, I can pay the travel and hostel myself, that is what I do usually... :)
<rperier>
like for fosdem
<rperier>
;)
<apritzel>
rperier: just heard about that travel support from a university guy from Germany, who made it to KVM forum in Seattle a fews weeks ago
<apritzel>
rperier: I guess it makes a difference in this case ;-)
<rperier>
oh okay, interesting
<rperier>
I don't say that it is a bad thing that the foudation does business... conferences and sponsorship are their main income... I just say that hobbyists and contributors in an open source community are the base of everything ;)
<rperier>
anyway, back to work
<mmind00>
rperier: I actually only ever use the hobbyist discount ... as this is regularly only needs a simpe email ... I read somewhere that there are travel sponsorships also available, but the administration overhead gets bigger then
_vaibhav_ has joined #linux-rockchip
_vaibhav_ has quit [Client Quit]
_vaibhav_ has joined #linux-rockchip
GriefNorth has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
_whitelogger has joined #linux-rockchip
cristian_c has joined #linux-rockchip
markm_ has joined #linux-rockchip
<cristian_c>
apritzel: hello
<apritzel>
cristian_c: hi
markm has quit [Ping timeout: 246 seconds]
<cristian_c>
apritzel: I've enabled bt rk903, but not rk903 wifi
<cristian_c>
apritzel: reading kernel sources, it seems it can be built only as module
<cristian_c>
obj-m
<cristian_c>
this explain because wifi launcher is never initialized
<cristian_c>
(I talk about wlan.c , for example
<apritzel>
cristian_c: are you sure about this module only? And what kernel are you talking about? There is no rk903 in my upstream kernel.
<cristian_c>
apritzel: I use rk30_kernel by crewrktablets
<cristian_c>
I don't know other kernel can include pcb configuration
<cristian_c>
apritzel: btw, now I can fix a particular brightness at startup
<cristian_c>
it's not so bad :)
<cristian_c>
apritzel: I've not yet found a tip about display issue
<cristian_c>
apritzel: I've a double screen on my display
<cristian_c>
a full screen and below this on, a second screen (1/3 of screen)
<cristian_c>
I don't figure out how it's possible
<cristian_c>
this issue happens already in boot process
<apritzel>
cristian_c: what kind of display device is there in the device tree?
<cristian_c>
messages are partially duplicated in low screen zone
<cristian_c>
apritzel: lg lp097x02
<cristian_c>
or similar name
<apritzel>
cristian_c: it usually describes the framebuffer layout in there, maybe that one is wrong?
<cristian_c>
it's the same lcd panel than ipad 1 and jpad 2
<cristian_c>
ipad
<apritzel>
the display controller is more important than the panel (for software purposes)
<cristian_c>
apritzel: I've tried to read the sources, but there are many parameters, it's much difficult figure out what goes wrong
<cristian_c>
apritzel: btw the hdmi framebuffer is not affected by the issue
<cristian_c>
it I connect the device to external display by hdmi cable, hdmi image is not affected by he issue
<cristian_c>
the
<cristian_c>
apritzel: issue seems related to internal display
<cristian_c>
anyway, native os (android) is not affected by the issue
<cristian_c>
with kernel built by me, I find this issue
<cristian_c>
(ubuntu)
<cristian_c>
apritzel: I've found If I type echo 1 > /sys/class/graphics/fb0/blank
<cristian_c>
the second screen becomes black
<cristian_c>
the first screen freezes, and it gradually obscures itself, as in suspend mode
<cristian_c>
apritzel: if I type, then: echo 0 > /sys/class/graphics/fb0/blank, screens enable themselves again
<cristian_c>
I've used 1 and fb0
<cristian_c>
but same results with whatever number different by 0
<cristian_c>
and also with fb1
<cristian_c>
fb2 , instead, is reserved for hdmi screen
<cristian_c>
apritzel: sorry for the long story :D
<cristian_c>
(I'm only giving more information as possible)
<cristian_c>
apritzel: I've not understood your question very well
<cristian_c>
about the display controller
<apritzel>
the device tree has to have some information about the display controller
<cristian_c>
I think I'm using fbdev
<cristian_c>
apritzel: ok, what have I to check?
<cristian_c>
:)
<apritzel>
if there is any information in there which describes the layout of the framebuffer
<apritzel>
and if that is wrong
<cristian_c>
apritzel: what file either command can I check?
<cristian_c>
'device tree'
<cristian_c>
sorry for my noobiness
<apritzel>
the .dts or .dtb file that you gave the kernel
<cristian_c>
uhm
<cristian_c>
it's the first time I read about 'dts' either 'dtb'
<cristian_c>
I'll try to mzke a search
<cristian_c>
apritzel: thank you :)
<apritzel>
if you have it booted and can login, you can check /proc/device-tree
<cristian_c>
apritzel: ah, ok
<cristian_c>
yeah, I can use ubuntu (with two screens O.o)
<apritzel>
or something in /sys/firmware
<cristian_c>
ok, but I don't think there is a firmware for lcd controller
<cristian_c>
but I'll make a search, anyway
<cristian_c>
thanks again
<apritzel>
no firmware, just a description of the lcd controller's properties like xres, yres, depth, stride, ...
<cristian_c>
(I'll search also in android tree)
<cristian_c>
to compare
<cristian_c>
apritzel: ok, thanks for the info :)
apritzel has left #linux-rockchip [#linux-rockchip]
apritzel has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
nighty^ has quit [Ping timeout: 244 seconds]
nighty^ has joined #linux-rockchip
cristian_c has quit [Quit: Bye]
gb_master has joined #linux-rockchip
<akaizen>
ANy reason for not using hard float toolchain to compile u-boot?
<amstan>
akaizen: do you need hardfloat?
<akaizen>
Well we'll be doing a lot of GPU stuff once in linux
<akaizen>
lots of graphics and gl effects
<amstan>
in u-boot?
<akaizen>
possibly in u-boot if we need to load a spash screen
<amstan>
-.-
<akaizen>
haha
<akaizen>
I'd prefer not to have to maintain and use two separate toolchains
<akaizen>
If I run into issues I'll drop to soft
cristian_c has joined #linux-rockchip
<amstan>
fair enough
<akaizen>
Anyway testing linaro's latest and sjoerd u-boot-branch
<apritzel>
akaizen: I use hardfloat tool chain on upstream, I had to patch one dodgy Rockchip tree to make it work there, though
<akaizen>
hmm.. "*** Your dtc is too old, please upgrade to dtc 1.4 or newer"
<akaizen>
~_~ I guess at somepoint I should upgrade the build server from 12.04
<akaizen>
anyone know a quick hack to temporarily set a path for a command for Make?
<sjoerd>
akaizen: u-boot/linux don't use floating point, so whether or not your toolchain is hardfloat or not is rather irrelevant
<akaizen>
sjoerd: yay! hope that would be the case
<sjoerd>
akaizen: does DTC=mydtcpath not work?
<akaizen>
I figured that would be too obvious and hence not work
<sjoerd>
akaizen: i build eveyrthing with the hardfloat toolchain in debian fwiw so
<lautriv__>
it appears my first SD-Card boot changed something on flash, now i found the stock image for that device. The image is starting with RKFW, does this need winblows mask-rom or may i use it with linux-tools ?
<akaizen>
sjoerd: it worked after placing the option after make
_vaibhav_ has quit [Quit: Leaving.]
<akaizen>
"CROSS_COMPILE=<path>/bin/arm-linux-gnueabihf- make O=firefly DTC=<path>/dtc firefly-rk3288_defconfig all" works vs DTC=<path>/dtc "CROSS_COMPILE=<path>/bin/arm-linux-gnueabihf- make O=firefly firefly-rk3288_defconfig all" fails
<akaizen>
I should stop before I get sucked into the nuances of shell variables sequences and lose the the rest of my day..
<apritzel>
lautriv__: doesn't rkflashtool do the job for you? It should cover maskrom as well, AFAIK
<apritzel>
lautriv__: my copy has a commit from last October: rkflashtool: support mask rom mode
<apritzel>
lautriv__: haven't tested it yet, though
apritzel has quit [Ping timeout: 264 seconds]
xcasex has quit [Remote host closed the connection]
xcasex has joined #linux-rockchip
<karlp>
akaizen: what readme?
rk3188_kernel_gu has joined #linux-rockchip
<rk3188_kernel_gu>
hello
<rk3188_kernel_gu>
can I get some help with rk3188 kernel compile, please?
GriefNorth has quit [Ping timeout: 240 seconds]
<rk3188_kernel_gu>
guess not lol
rk3188_kernel_gu has quit [Quit: Page closed]
<lautriv__>
is there a default offset for stock firmware using rkflashtool ?
<akaizen>
karlp: u-boot-rockchip by : Simon Glass (sjg) http://git.denx.de/?p=u-boot/u-boot-rockchip.git;a=blob;f=doc/README.rockchip;h=87ce9d2e9f3aa59f261209908c8ec29d2a7370dd;hb=fb199e88b7b0dca58559c02090ddf3013a9f6be2
<karlp>
meh, 3288 only
<karlp>
nice key in the readme. where'd that come from?
<sjoerd>
that key is all over the interwebs
<sjoerd>
just google for it
<sjoerd>
karlp: just 3288 should make it lots easier to add other boards over time though :)
<JohnDoe_71Rus>
somebody work at rk3168?
cappybob has joined #linux-rockchip
akaizen has quit [Remote host closed the connection]
cappybob has quit [Client Quit]
<mmind00>
karlp: the only "obstacle" for rk3188 is the memory init ... and the controller parts are the same between rk3288 and rk3188
<naobsd>
rkflashtool cannot write loader area(idb) on eMMC
<akaizen>
naobsd: hmm well I'm currently running ubuntu on the device
<akaizen>
I should be able to directly write to /dev/mmcblk0
<naobsd>
ah, yes
<akaizen>
yay :)
<sjoerd>
akaizen: and yes that change should work
<akaizen>
double yay
<akaizen>
i r now embedded ngineer
<sjoerd>
akaizen: note that if you get that wrong (i'm not guaranteeing anything) you'll need to dig up an sd card or force it to maskrom mode to recover :)
<akaizen>
T_T
<akaizen>
I'm really not sure how changing the node name in the DTS file will make it look for uboot on the emmc vs the sdcard
<akaizen>
well lets just apply the javascript dev appraoch to hardware
<akaizen>
fire and forget
<akaizen>
I'm no stranger to MASK ROM mode .. I bridge pin 8+9 on RK3188 so many times lol
<sjoerd>
akaizen: changing that node name will cause the emmc node to have u-boot,dm-pre-reloc
<sjoerd>
akaizen: which means it gets to be part of the mini dtb in the spl
<sjoerd>
the spl just expects there is one available mmc device and loads from that
<akaizen>
where is emmc and sdmmc specified (addresses and what not?)
<akaizen>
or does uboot / spl detect that?
<sjoerd>
in the include files
<akaizen>
ah :)
<akaizen>
now it makes sense
<sjoerd>
see rk3288.dtis and rk3288-firefly.dtsi
<akaizen>
I hope one day we can build a generic kernel which will just auto detect and auto configure everything y probing
<akaizen>
by*
<sjoerd>
you can't autodetect that
<sjoerd>
but you can build general kerels which will work fine as long as you hand it the right dtb
<akaizen>
sjoerd: if autodetect fails : brute force addresses ;)
<sjoerd>
not possible ;)
<akaizen>
as long as there is a huge db of components
<akaizen>
sjoerd: oh why not?
<sjoerd>
it's not that you send a message and you get an ack/nack back
<naobsd>
lautriv__: can you explain "stock firmware" more specifically? you should have partition layout in _your_ parameter which describes offset.
<naobsd>
lautriv__: if you're trying to flash one big image start with RKFW, you have to use Rockchip official flash tool such as AndroidTool.exe/upgrade_tool. rkflashtool doesn't support it.
<akaizen>
sjoerd: I will have to think more about this problem and try some things
<akaizen>
./firefly-rk3288/tools/mkimage -T rksd -d firefly-rk3288/spl/u-boot-spl-dtb.bin out —> is there a list of -T paramaters? the binary lists a few but I’d rather look at the source
<akaizen>
got it rkimage
<naobsd>
u-boot README.rockchip needs some updates...
<naobsd>
I wish I have some time today, but I have to fix some issues for my home ;)
<akaizen>
naobsd: You have a link? I can maybe submit a patch.. I'm creating a readme for myself right now
<naobsd>
link?
<akaizen>
naobsd: currently using http://git.denx.de/?p=u-boot/u-boot-rockchip.git;a=blob;f=doc/README.rockchip;h=87ce9d2e9f3aa59f261209908c8ec29d2a7370dd;hb=fb199e88b7b0dca58559c02090ddf3013a9f6be2
<akaizen>
link to the uboot README.rockchip you would like to update
<naobsd>
that one, of course
<akaizen>
Right now theres a few repos so I'm not sure which you are referring to
<naobsd>
git.denx.de is the only one u-boot repo
<naobsd>
well
<akaizen>
so linux-rockchip is unmaintained or a mirror?
<akaizen>
on github
<naobsd>
generally target is upstream,
<naobsd>
ah
<naobsd>
are you talking about linux-rockchip/u-boot-rockchip?
<akaizen>
do these offsets seem right? According to wiki they are the same for SDcard and eMMC but sjoerd mentioned SPL at 32k? sudo dd if=out of=/dev/mmcblk0 seek=64 && sudo dd if=firefly/u-boot-dtb.img of=/dev/mmcblk seek=256
<akaizen>
naobsd: yep, there is also the rkchrome/u-boot
<naobsd>
it's based on u-boot for Rockchip Android SDK. it's not origin/upstream at all.
<naobsd>
rkchrome is not upstream too
<naobsd>
no relation
<akaizen>
ah ok so those are considered deprecreated?
<naobsd>
no
<akaizen>
now that upstream supports it?
<naobsd>
they are just different, independent
<naobsd>
no relation
<akaizen>
ok
<akaizen>
from my understanding they are based on rock-chip code, while mainline is fully opensource project?
<akaizen>
is that where the independence comes form?
<naobsd>
u-boot fork from Rockchip is came from Rockchip. u-boot at denx.de is the u-boot, not based on Rockchip code.
<akaizen>
ok cool :)
<naobsd>
and, u-boot-rockchip (sjg/sjoerd work) is not "linux-rockchip community project" i.e. github/linux-rockchip/u-boot-rockchip has no relation
<naobsd>
(as I said, there is no "linux-rockchip community project")
<naobsd>
I should rename github repo
<naobsd>
ah, it should have same ancestor commit, it may be ok to add upstream u-boot-rockchip branch
<naobsd>
anyway I should add some explanation...
<akaizen>
that would be helpful :)
<akaizen>
I should document/update the wiki
<naobsd>
probably I have to refresh Rockchip SDK based repos (linux-rockchip/u-boot-rockchip) near future, it may be better to rename them as like as rk_kernel/rk_u-boot