nighty^ has quit [Quit: Disappears in a puff of smoke]
pizthewiz has quit [Quit:
tlwoerner has quit [Quit: Leaving]
cnxsoft1 has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 256 seconds]
naobsd has joined #linux-rockchip
<naobsd>
mrutland: you can specify partition name instead of offset address for rkflashtool
<naobsd>
in this case address is taken from parameter on device
akaizen has joined #linux-rockchip
tony__ has joined #linux-rockchip
akaizen has quit [Remote host closed the connection]
tonokip2 has quit [Ping timeout: 246 seconds]
akaizen_ has joined #linux-rockchip
ssvb has quit [Ping timeout: 250 seconds]
visitor-14524 has joined #linux-rockchip
<visitor-14524>
A question for starters... Until now, the system either panic()ed or got stuck while booting a self-baked recovery image (new kernel), now, especially with including a "known good" recovery ramdisk it goes into a bootloop...
<visitor-14524>
Would that mean that it actually got past lowlevel kernel bootup and /init decided for a reboot just because things are still too wonky to work with?
<visitor-14524>
For the sake of brevity, just assume that I don't have any means to access the lowlevel kernel log short of disassembling the device to see if it has some serial pins on board. Because that's pretty much the case :(
<mmind00>
naobsd: oh interesting ... didn't know that rkflashtool aquired that capability ... I probably should upgrade mine then ;-)
<amstan>
visitor-14524: what device?
<visitor-14524>
Pretty much sure the name "Odys Noon Pro" doesn't tell you anything. It seems to have become a non-entity of sorts. From what I've seen it's RK3188 based and the GPIO pinout is a close match (but not 100%) to the rk3188-sdk board, judging from the GPIO pinout dump.
<visitor-14524>
Uses proprietary bootloader, Version V1.03, and partition map seems pretty vanilla to me as rockchip-devices go. Boot, kernel, recovery, misc, kpanic, parameter file - everything there.
<visitor-14524>
So far, when the new kernel in the recovery image threw a panic(), the system rebooted the stock "live" bootimage. Now it went into a bootloop with the borked recovery image. Pretty sure that's got to mean something...
<rperier>
mmind00, amstan: exactly, I work on "meta-rockchip". A bsp meta-layer (aka a module) for yocto (aka this is to support rockchip socs in yocto)
<rperier>
amstan: why ?
<amstan>
i want to see what advantages yocto has for an embedded project as compared to something like arch
<rperier>
with yocto/oe your build your distro from scratch, so you are able to choices tunes, cflags for your target, choice your kernel... build your own rootfs... when your target is supposed to be used for a specific purpose it makes sense, because you won't deliver a general desktop distro to a client :)
<rperier>
/choise/choose/
<rperier>
it include a build system for that, a package manager which you can install on your target... mirroring system and a lot of nice dev tools
<rperier>
even if arch linux for arm is very nice (I love arch, I use it myself on all my desktop/laptops), that's completly different, that's not really the same goal
<amstan>
are there any update mechanisms?
<rperier>
amstan: have a look at the yocto documentation for more details, it is very well explained
<rperier>
amstan: yes, of course
<amstan>
anything like an A/B system where it can gracefully fail an update?
<rperier>
well, yocto/oe itself is the set of packages/tools to build your distro/firmware including , the reference embedded distro is "poky"
<rperier>
(or oe-core in openembedded)
<rperier>
poky itself is released each 7-8 months with new packages
<rperier>
on the target side, as you have a package manager (apt, ipkg, etc...) you can update everything easily (including dependencies)
<amstan>
on chromeos there's 2 rootfs partitions and 2 kernels
<amstan>
whenever there's an update, it always does the other rootfs than the active one
<amstan>
then just reboots to switch
<amstan>
once the new image can ping google.com it marks that partition as the active one, if it can't ping google it reverts back to the old version
<rperier>
as you build your embedded distro... you can use the method you want to handle updates on the target :)
<rperier>
a nice feature is that you can even build "flashable" image
<rperier>
including partitions... bootloaders... etc
<rperier>
amstan: if you have a custom tool to support updates over the air, you can still include it in yocto by writing recipes (like a PKGBUILD)
<amstan>
nope, i would have to write such a thing
<rperier>
it was just an example :)
<amstan>
rperier: i guess i should just try it
<rperier>
yes
<amstan>
rperier: so what brings you to yocto?
<amstan>
why are you contributing to it with rockchip patches? do you have a use for it in mind?
<rperier>
this is my cross-compilation environment and my embedded distro on *all* my rockchip-based devices. It is open-sources, free, powerful you can control everything you want in the target distribution... usually when you work on embedded systems this is what you want to do
<rperier>
amstan: I am contributing to the bsp meta-layer for rockchip, aka the module which adds support for rockchip-based devices
<rperier>
yocto itself, i.e the development tools with the reference embedded distro (poky) is there https://git.yoctoproject.org/cgit/cgit.cgi/poky/ . I did not contribute yet to the core, but I think that one day I will
<amstan>
it seems that for using yocto you need a very specific application in mind(as a reason for the "you can control everything you want"), i'm just curious why you picked yocto before you made the first patch to it
<amstan>
are you working at a place which build embedded devices or something?
<rperier>
I am working for a company specialized in embedded linux development and embedded open source technologies (my company is called "open wide"), we use buildroot and yocto everyday. when I got my first rockchip board, I found that there was no rockchip support in yocto, so I decided to contribute at this time. I was a great opportunity for me to improve my skills on this subject, that's all
<rperier>
but, everything I do on the kernel and yocto is done in my free time
<rperier>
that's not for my company
<amstan>
rperier: cool
<rperier>
meta-rockchip is still a bit buggy sometimes, so feel free to ask if you have any questions or propose improvements or feedbacks. suggestions are always welcome :)
<rperier>
did I answer to all your questions ?
<amstan>
rperier: yes, thank you very much for your time
<rperier>
you're welcome
<rperier>
in fact you reminded me that I need to push some changes to support speedy in meta-rockchip
<rperier>
(the "machine configuration")
markm has quit [Ping timeout: 255 seconds]
naobsd has quit [Quit: naobsd]
markm has joined #linux-rockchip
nighty^ has joined #linux-rockchip
apritzel has joined #linux-rockchip
naobsd has joined #linux-rockchip
cristian_c has joined #linux-rockchip
<cristian_c>
tony__: I've got the requested output
<karlp>
rperier: you left out that you can configure yocto to be much much smaller than arch (I presume, I know very little about arch linux)
<cristian_c>
tony__: sorry, ls -l toolbox.bin finds the file
<cristian_c>
there is not toolbox in my home. There is toolbox.bin in my home
<tony__>
cristian_c, and how so ? I give you a toolbox without ".bin"
<cristian_c>
ok
<rperier>
karlp: I have a rootfs ... its size is... 35mb here
<tony__>
cristian_c, just try "ls -l"
<tony__>
cristian_c, show me.
<rperier>
my initramfs for developing (include busybox and kxec) is something like... 3MB
<cristian_c>
tony__: you gave me toolbox.bin
<cristian_c>
but i can retrieve the log
<rperier>
karlp: so yes
<rperier>
but it really depends what you plan to do with it
<tony__>
cristian_c, from your log.
<tony__>
cristian_c, the problem is that the toolbox.bin has no permission to run.
<rperier>
I mean, arch or debian or whatever you want was originally designed to be a desktop distribution... not an embedded one, even if these exist for arm you don't control the packaging or the features into your applications, or cflags or tunes
<cristian_c>
tony__: ok, file owner can execute the file, btw
<tony__>
cristian_c, ok, try run it.
<tony__>
cristian_c, give me the log for running.
<cristian_c>
owner = rwx , group = r, other = r
markm has quit [Ping timeout: 256 seconds]
<cristian_c>
<cristian_c> tony_: I've tried to launch your executable
<cristian_c>
08:39 <tony_> cristian_c, then...
<cristian_c>
<cristian_c> I get: no such tool
<cristian_c>
tony__: but I can launch toolbox.bin again and save the result
<tony__>
cristian_c, ok, pls give me a whole log.
<tony__>
cristian_c, not just one line.
<karlp>
rperier: my rootfs today is 6.4meg :)
<cristian_c>
the full output, ok
<cristian_c>
tony__: have you solved your resolution issue?
<tony__>
cristian_c, and also try "file toolbox" to see the file detail information.
<cristian_c>
tony__: ok
<tony__>
cristian_c, I'm doing it. I will try to other way to do that. maybe "fbset" can not work in the long time. ;O
<tony__>
cristian_c, I tried the Ubuntu on rk3188 / Android 4.4 on rk3188 /Android 4.2 on rk3188.
<cristian_c>
tony__: I've enabled bluetooth
<tony__>
cristian_c, all of them can not work fine.
<cristian_c>
uhm
<cristian_c>
tony__: I've used again brcm_patchram_plus
<tony__>
cristian_c, \ - /
<rperier>
karlp: this is because I used the default busybox config and some optional stuff, but if you want I can really make it small... :)
<tony__>
cristian_c, now just talk about toolbox. ;P
<cristian_c>
it works also with rk903
<cristian_c>
tony__: ok
<rperier>
karlp: the size by itself is not really objective, what does matter is what do you have in there, what is its size, what is it designed for etc..
cristian_c has quit [Quit: Bye]
<karlp>
rperier: yeah, I know, I was just saying that more for amstan that one of the benefits of the yocto path is being able to make very small things.
<rperier>
;)
<karlp>
I'm kinda cheatin anyway saying i have a 6meg rootfs, I'm on openwrt, not yocto :)
<karlp>
almost a meg of it is javascript even. hooray for web development
<rperier>
karlp: openwrt is really nice and powerful ?
<rperier>
I just know it by its name
ssvb has joined #linux-rockchip
<karlp>
got pluses and minuses.
cristian_c has quit [Quit: Bye]
cristian_c has joined #linux-rockchip
<cristian_c>
tony__: I've renamed toolbox.bin into toolbox
<cristian_c>
now, I get: Toolbox!
<tony__>
cristian_c, ok, it works fine nowl.
<cristian_c>
tony__: what does it make this modified tool?
<tony__>
"toolbox getevent "
<cristian_c>
ok, a collection of commands
naobsd has quit [Quit: naobsd]
tony__ has quit [Remote host closed the connection]
rk3288_git has quit [Ping timeout: 246 seconds]
ssvb has quit [Ping timeout: 255 seconds]
<rperier>
karlp: my problem is that in order to have a fast boot with recent distro technologies, I use systemd... my minimal rootfs contains busybox (few MB), dropbear and systemd... I think that systemd and all its dependencies take a lot of space
cristian_c has quit [Quit: Bye]
RayFlower has joined #linux-rockchip
<rperier>
I understand how to do a simple AXI4 read request in C, but how are you supposed to do an AXI4 burst read?
<visitor-14524>
So far I'm not giving up... Wrote a script that takes an uncompressed kernel image, a system.map and the base address and disassembles the kernel and adds a number of annotations. Let's see what I can glean from the stock kernel...
<rperier>
se
<rperier>
apparently it is only possible via dma... (axi dma)
<bashintosh>
Who's a guru about RK3188/3288 internals with relation to clock generators? I am looking for the relationship between a DTS parameter such as DCLK (a.k.a. clock-frequency @https://www.kernel.org/doc/Documentation/devicetree/bindings/video/display-timing.txt) and the kernel driver which drives such clock - I have landed in <kernel-source>/drivers/clk/rockchip/ but I am not sure about how lcd clocks are
<bashintosh>
driven from here
<sjoerd>
bashintosh: the drivers in there turn those clocks on and off on request of other drivers
<bashintosh>
sjoerd: nice one - do these drivers (drivers/clk/rockchip/) also modify the clock frequency(s) according to what the 'calling' driver tells them do to?
<sjoerd>
yes
<sjoerd>
(if possible etc)
<bashintosh>
sjoerd: I think the (if possible etc) clause might have gave me a good clue about why a given (legal) LCD DCLK value (DTS) is 'ignored' and a different clock freq. is generated
<bashintosh>
thank you much
ssvb has joined #linux-rockchip
<sjoerd>
bashintosh: it can also be that the tree is incorrect in its flags (e.g. it may not know that if you set that clk tree endpoint it can modify tis parent)
neyder_ has joined #linux-rockchip
visitor-14524 has quit [Quit: Page closed]
VargaD has quit [Ping timeout: 256 seconds]
markm has quit [Ping timeout: 264 seconds]
<bashintosh>
sjoerd: when you say tree flags, you mean LCD related? i.e. hfront-porch,vsync-len etc.? My understanding is that the DCLK is directly affected by the rest of the LCD timings - I am having a hard time understanding 'where' such logic happens, in the kernel. Probably need to read a lot more code
<amstan>
karlp: put the javascript and web ui on another host
<amstan>
only have the api endpoints on the router, lol
<amstan>
*insanity wolf*
<karlp>
doesn't matter, it all fits :)
<karlp>
empty flash is wasted flash!
wb|biketron has quit [Ping timeout: 244 seconds]
wb|biketron has joined #linux-rockchip
akaizen_ has quit [Remote host closed the connection]
rory0962 has joined #linux-rockchip
dack has joined #linux-rockchip
cristian_c has joined #linux-rockchip
dack has quit [Remote host closed the connection]
dack has joined #linux-rockchip
<rory0962>
what's the preferred way to compile a device tree? i'm getting syntax errors using dtc alone, since it's #include instead of /include/. guessing i need a c preprocessor?
<rory0962>
(http://she-devel.com/makedts is telling me i'm missing 'arm-none-linux-gnueabi-gcc' - any idea where to get that? i've tried 3 different apt-get repos so far)
<rory0962>
hmm, even switching that script to arm-linux-gnueabi-gcc doesn't work; i guess it's not available in the (cros_sdk) chroot? should i try compiling in a normal, non-chroot terminal?
<amstan>
rory0962: i assume you're using the chromebook chroot?
<amstan>
rory0962: why are you compiling dts files from scratch?
<rory0962>
amstan: trying to port chromeos to a new device (cx-929 stick)
<rory0962>
and yep, chromeos chroot
<amstan>
rory0962: you can go the short hacky way or the long way
akaizen has joined #linux-rockchip
<rory0962>
alright it seems to be working now outside the chroot, now just getting duplicate label errors because rk3288-veyron.dtsi uses rk808 as the pmic and i just pasted in some act8846 stuff. hmm...
<amstan>
short hacky way involves picking a chromebook close to what you want, perhaps veyron_jerry and compiling the whole image for it
<rory0962>
short way? i'm intrigued
<amstan>
then including the dts new dts file in the kernel(add it to the makefile)
<amstan>
long way is making a new chromebook variant
<amstan>
which is what you want probably at the end
<rory0962>
hmm okay, guess rk3288-evb's the best i've got (since it's act8846)
<amstan>
there's no rk3288 evb variant
<rory0962>
but yeah, appending the dts was the plan here
<amstan>
dianders: are our overlays public? can someone compile veyron_jerry with just the public stuff?
<rory0962>
wait, is adding it to the makefile a different strategy from appending it to the zImage?
<dianders>
I don't think anyone has made them public, but I think you can just build "veyron" and get most of the stuff.
<dianders>
...but I think they're not public just because nobody has done it yet. It's possible there's a thing or two in there that needs to not be public, but not 100% sure...
<rory0962>
so can i just not worry about the rk808 vs act8846 right now? try a flash with just a veyron build and see what happens?
<amstan>
it will probably not work if you're using the wrong pmic, it'll complain about power rails not going up properly
<rory0962>
so what's my best bet for that? keep trying to compile a dts that #includes rk3288-veyron.dtsi?
<rory0962>
(or can i not include that at all, since it has rk808 already in it?)
<amstan>
so.. you need to start by compiling an image with the proper chromeos tools, so start following the developer guide and try to compile veyron
<rory0962>
yep, i've got a veyron zImage so far
<amstan>
once you get that working, you'll notice emerge-veyron linux-3.14, which compiles and packages the kernel
<amstan>
that will call the dts compilng for you, no need to do it manually
<rory0962>
does emerge-veyron let me specify my own dts?
<amstan>
rory0962: no, it'll grab all veyron dts files(not sure where it gets that list from)
<rory0962>
so all veyron- prefixed files? or just -veyron.dts files?
<amstan>
check the src/third_party/chromiumos-overlay/eclass/cros-kernel2.eclass file
<rory0962>
ah ok, looks like it's a chromiumos-rockchip dir somewhere
dack has quit [Read error: Connection reset by peer]
GriefNorth has quit [Ping timeout: 246 seconds]
<rory0962>
oh wait no nvm, it's just the boot_dir and boot/dts if there's none there
nighty^ has quit [Quit: Disappears in a puff of smoke]
irsol has quit [Remote host closed the connection]
gb_master has quit [Remote host closed the connection]
irsol has joined #linux-rockchip
markm has quit [Ping timeout: 244 seconds]
markm has joined #linux-rockchip
naobsd has quit [Quit: naobsd]
pizthewiz has quit [Quit:
neyder_ has quit [Ping timeout: 246 seconds]
cristian_c has quit [Quit: Bye]
pizthewiz has joined #linux-rockchip
<rory0962>
alright i'm having trouble with chromiumos' ./build_packages, getting "build_packages:262:main(), called: die_err_trap"
<rory0962>
my emerge http://pastebin.com/HgM6gkXW is showing "CROS_WORKON_SRCDIR=("/mnt/host/source/src/third_party/kernel/v3.14")" even though i've already cros_work stopped that