ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at | Logs at | ML at
<naobsd> getting TV from my family is most difficult task ;)
<jmcneill> i think you are right wrt voltages
<jmcneill> top is cold boot, bottom is after resetting from android
<jmcneill> let me try rebooting with 1.6GHz and these voltages
<jmcneill> boots but not really stable
BorgCuba has quit [Remote host closed the connection]
<jmcneill> 1.4 is ok
<naobsd> you may need VDD_ARM 1.35V for 1.6GHz
<naobsd> sorry, I'll out really soon, later!
<naobsd> I guess ldo2 is for hdmi
naobsd has quit [Quit: Page closed]
<jmcneill> thanks
<jmcneill> where did you see ldo2 for hdmi?
field^Mop has joined #linux-rockchip
<jmcneill> ldo2 did the trick btw, thanks!
<jmcneill> act8846pm0: LDO2: [1.200V] [OFF]
<jmcneill> ...
<jmcneill> ithdmi0 at iic2 addr 0x4cact8846pm0: LDO2: [1.200V] [ON]
<jmcneill> : id 54 49 12 16
<jmcneill> ithdmi_hpd: sysstat 0x0c
field^Mop has quit [Ping timeout: 255 seconds]
<jmcneill> yay i can read edid
cnxsoft has joined #linux-rockchip
<ganbold_> nice
Astralix has joined #linux-rockchip
Astralix1 has quit [Ping timeout: 250 seconds]
cnxsoft has quit [Ping timeout: 245 seconds]
cnxsoft1 has joined #linux-rockchip
Avagetto has quit [Ping timeout: 264 seconds]
RayFlower has quit [Ping timeout: 250 seconds]
Avagetto has joined #linux-rockchip
RayFlower has joined #linux-rockchip
naobsd has joined #linux-rockchip
<akaizen_> @jmcneill Is that EDID from Firefly? If so, did you read it under Android/
<naobsd> akaizen_: jmcneill is working for NetBSD
<akaizen_> Oh awesome! Would FreeBSD port to Firefly as well?
<naobsd> I'm not talking about firefly
<ganbold_> jmcneill is working on rk3188
<akaizen_> ahh ok
akaizen_ is now known as akaizen
<ganbold_> I have firefly, but I've got printing some chars in initarm()
<akaizen> have you gotten jtag access?
<ganbold_> I didn't try
<akaizen> Sorry, but I'm very curious about *BSD on Firefly so I'm going to probably ask alot of questions :D
<ganbold_> I have chars printed using early printf in initarm() of machdep.c
<akaizen> Is there a porting guide?
<ganbold_> just before setttb()
<akaizen> Ah ok
<akaizen> Also, whats the state of embedded graphics? I'm really interested in writing a nice GUI that bypasses X
<akaizen> Or at least taking advantage of Open GL ES 2.x, 3.x and doing hardware accelerated rendering to framebuffer @ 4K + 60 fps
pacopad has joined #linux-rockchip
<akaizen> I found a C OpenVG library so that should handle images and texts
<ganbold_> I think jmcneill has more knowledge in that area, but I don't think either freebsd or netbsd does have mali driver
<ganbold_> I should have andy's eurobsdcon talk, let me look for
<akaizen> Do you think lima would work?
<akaizen> I'm not too sure of the current differences between the *BSD and Linux kernel other then old history
<akaizen> I also saw the Darwin on ARM project ;)
<akaizen> Porting OS X to Firefly would be crazy awesome haha
<naobsd> porting work is
<naobsd> well
<naobsd> if you can make it work, it will work
<naobsd> answering something not yet working is very difficult
<naobsd> jmcneill: about power for hdmi units, I saw schematics for RR(Pro). I guess ldo2 is used for hdmi on reference board
<ganbold_> if anyone would like to see andy's pdf let me know
GriefNorth has joined #linux-rockchip
<akaizen> @ganbold_ I would. Can you upload to github or dropbox or something?
<akaizen> Is this it: A Reimplementation of NetBSD Based on a Microkernel presented by Andy Tanenbaum
<akaizen> Porting NetBSD to the LatticeMico32 open source CPU -
<akaizen> Porting the drm/kms graphic drivers to DragonFly -
<akaizen> I guess those might be helpful too :)
cnxsoft1 has quit [Ping timeout: 256 seconds]
<naobsd> mmind00_: "rockchip,pins = ..." lines are not required if I just want to change its function to gpio?
<naobsd> ah
<naobsd> mmind00_: for gpio7/8 on rk3288, "rockchip,pins = ..." lines are not required if I just want to change its function to gpio?
<naobsd> mmind00_: or all RK_GPIO/RK_FUNC_ prefixes should be removed from .dts/.dtsi?
<naobsd> there is no RK_GPIO prefix in rk3288.dtsi
<naobsd> about RK_FUNC_, some has it, some doesn't have it
Avagetto has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-rockchip
pacopad has quit [Read error: Connection reset by peer]
<mmind00_> naobsd: I only meant to not introduce new "#define RK_GPIO7 7" mappings, as they are unnecessary ... the regular 7 in the "rochchip,pins" line already provides enough information
<mmind00_> naobsd: I specifically did not mean to change existing entries ... as the already existing RK_GPIO0 etc constants are already part of the API and thus cannot go away anyway
akaizen has quit [Read error: Connection reset by peer]
<naobsd> mmind00_: for rk3288-firefly.dst, which one should I use, regular X or RK_GPIOX for gpio[0-6]?
<naobsd> mmind00_: and for 3rd argument, which is better, RK_FUNC_GPIO and 0
<mmind00_> naobsd: just "X" to keep it consistent ... and for the function I'd suggest RK_FUNC_GPIO ... but just numbers for other pin functions
<mmind00_> naobsd: i.e. function 0 (GPIO) is special enough that we can mark it as such for readability
<naobsd> mmind00_: I see
<mmind00_> naobsd: the other pin functions do not provide additional value in their RK_FUNC_1 -> 1 mapping
<naobsd> yeah
<naobsd> if it's like RK_FUNC_MMC, it will have additional value, but it will not be necessary
<mmind00_> naobsd: also, if you look into the firefly "upstream"-dts you can see that they use the vccio_sd as supply for the sdmmc. Still the wrong regulator as it is vqmmc but it seems it is really the 2nd source for the sdmmc
<naobsd> mmind00_: sdmmc0 supply is vcc_sd in rk 3.10 kernel
<naobsd> mmind00_: I'll try vccio_sd off and see what happen
<naobsd> mmind00_: ah, sorry, I looked wrong branch :(
akaizen has joined #linux-rockchip
<naobsd> I'll ask firefly team
<naobsd> I cannot find source of vccio_wl, so I guessed vccio_sd and vccio_wl are same
<naobsd> I'll ask about it too
<jmcneill> naaobsd, i read the edid with netbsd via ddc using it66212, cold boot
<jmcneill> no help from android
<naobsd> jmcneill: yeah I read log, congrat :)
jas-hacks has joined #linux-rockchip
<jmcneill> think i will take a break from that and do cpu freq
<Astralix> jas-hacks: thanks again for your help, it was what I assuemd, there where desrtoyed file permissions.
<Astralix> As the download of the new ZIP always fails, I cloned from the nl mirror and after setting right JAVA version, it now compiles
<jas-hacks> Astralix: np, interested to know if you build will boots once it compiles
<Astralix> I wonder why they insist on having ORACLE JAVA... We are using OpenJDK for along time now successfully... However, I uese ORACL 1.6.0_45 now for the first test
<Astralix> BTW, is there a know to work installation of XBMC for radxa rock?
<Astralix> jas-hacks, as you tried the compile, did you use the compilers they tell about from the wiki? or do you use the standard ubuntu versions?
<jas-hacks> Astralix: its hardcode in the make files to use the prebuilt one in the android tree
<Astralix> Yes for Android, but no for kernel
<Astralix> For uboot and kernel the installed arm-* toolchains are used
<Astralix> And we had many problems in the past with kernels working on onw version but not working on another version
<Astralix> However, current 3188 kernel run fine and fast with 4.9.2hf and uboot runs fine with 4.9.2 (non-hf!)
<Astralix> But wiki downgrades to 4.8.x
<jas-hacks> From what I remember I tried with 4.8.x
<jas-hacks> although changed uboot to compile with 4.9.2
<Astralix> Yes, all kernels 3.0.36 and above should run fine with 4.9.2hf. but uboot does not support VFP so you cannot compile it with hf compiler.
<jas-hacks> Noticed that i2c5 is disabled for firefly in Android, I don't think they use EDID for hdmi
<naobsd> Astralix: see Makefile under kernel and u-boot, it uses Android prebuilt gcc 4.6/4.7
<naobsd> for jdk use oracle jdk6
<Astralix> for the first test I use jdk6
<naobsd> you can use another toolchain, but don't blame radxa/firefly when you get problem
<naobsd> blame rockchip ;)
<Astralix> i did not blame anyone
<Astralix> I hate that they always modify Makefiles
<Astralix> If you do export CROSS_COMPILE=xyz you expect that xyz is used and not that the Makefile resets it to something else
<Astralix> But RK always does this
<naobsd> no
<naobsd> again, see Makefile under kernel and u-boot
<naobsd> and don't blame rockchip ;)
<naobsd> there are CROSS_COMPILE ?=, not CROSS_COMPILE =
<naobsd> you can use another toolchain.
<Astralix> Then do not tell that the toolchain is used, it is only used "by default"
<naobsd> that toolchain should be used
<Astralix> ifneq ($(wildcard ../toolchain/arm-eabi-4.7),)
<Astralix> CROSS_COMPILE ?= $(shell pwd)/../toolchain/arm-eabi-4.7/bin/arm-eabi-
<Astralix> and following lines
<naobsd> it's default, tested
<Astralix> Sure, and I am using this for the first test now
<Astralix> First test == everything default
<Astralix> following every line of the wiki
<naobsd> it's good for first trial
<naobsd> btw only ../prebuilts/... config is applied with android sdk
<naobsd> ../toolchain/... is not available in current android sdk
<Astralix> Does it destroy anything, if you, instead of directly invoking "make -jx" first do "source build/" and then "lunch 6"?
<Astralix> cause this would be the normal way of building Android
<naobsd> it's not normal Android SDK, it's Rockchip's Android SDK. please follow Rockchip's procedure at first
<naobsd> I sometimes do differently after I understand some things
<Astralix> I just ask, if someone has tried that
<Astralix> would be cool, if the sdk will work for 3188 too
<naobsd> I have to leave now, good night
<Astralix> we ported 4.4.4 to rk and are curious if the changes we made are matching somehow the ones RK did
<Astralix> good night naobsd
<Astralix> Ok, the first trial failed as the build did not create a system.img
<Astralix> Running make without -j option to lokate the error reason
<Astralix> *locate
<Astralix> A question... if the firefly SDK is 4.4.4, why are the strings and references set to 4.4.2?
<Astralix> jas-hacks, you told me that it compiled, but didn't start on the machine. here it doesn't compile
<jas-hacks> Astralix: looks like a JDK problem
<Astralix> yes, just rtying to find out which problem
<jas-hacks> Astralix: java version "1.6.0_45"
<Astralix> $ javac -version
<Astralix> javac 1.6.0_45
<Astralix> Ok, there are more variables out there... If you have multiple JDKs installed, you need to reset ...
<Astralix> export JAVA_HOME="/usr/lib/jvm/jdk1.6.0_45/bin"
<Astralix> export ANDROID_JAVA_TOOLCHAIN="/usr/lib/jvm/jdk1.6.0_45/bin"
<Astralix> export PATH="/usr/lib/jvm/jdk1.6.0_45/bin:$PATH"
<jas-hacks> my default JDK 1.6 so no environment vars
<jas-hacks> sudo update-alternatives --config java
cnxsoft has quit [Remote host closed the connection]
<Astralix> jas-hacks, if you do the update-alternatives, it resets the JDK/JRE used by ubuntu
<Astralix> But I like to keep ubuntus defaults to open JDK, while for compilign Android L I use openjdk 7 and for other KK I use open JDK 6 or ORACLE JDK 1.6
<Astralix> With the above exports set, it works, I just ran out of disk space...
<rperier> uboot works so fine on the rock now, cool
<rperier> (it changes compared to the old limited proprietary bootloader)
<rperier> :)
<rperier> did you already play with CONFIG_UART_NUM ? in config
<rperier> typically, I would like to ask uboot to initialize uart0 or uart1 in order to use earlyprintk from the kernel later
<Astralix> rperier, I didn't use uboot on rock for now. Which git are you using?
<Astralix> have to leave for lunch...
<rperier> Astralix: the one from radxa, but you can probably use naobsd's repository too. I just did read this article
<rperier> ok, have a good lunch
BorgCuba has joined #linux-rockchip
<BorgCuba> rperier, have you tried the rk32 usbphy on rk30/31?
<rperier> no yet, but it is in my todo list, don't worry (I tried to find a way to get logs on uart0 or uart1 first)
jas-hacks has left #linux-rockchip [#linux-rockchip]
<BorgCuba> rperier, you have uart problems?
<rperier> yes only on my rock pro, uart2 is not stable
<rperier> others work fine
<BorgCuba> thats the default debug uart? I have the same problem on the rk3188 and rk3188t devices I own
<rperier> switch from uart2 to uart0 from uboot works just fine
<rperier> I did not think that it was so easy :)
<rperier> I just need to find how to boot kernel from nand now :D
<BorgCuba> cool, I dont have this as an option. I am trying to get g_ether or g_serial to work
ganbold_ has quit [Ping timeout: 255 seconds]
eebrah has quit [Remote host closed the connection]
eebrah_ has joined #linux-rockchip
eebrah_ has quit [Client Quit]
BorgCuba has quit [Quit: leaving]
FreezingCold has quit [Ping timeout: 256 seconds]
faddat has joined #linux-rockchip
mcan has joined #linux-rockchip
mcan has quit [Changing host]
FreezingCold has joined #linux-rockchip
<Astralix> naobsd? May I request you help?
<Astralix> The linux upgrade_tool does not support the new images of rk3288 like resource, backup and others.
<Astralix> Do you know of a new version of this tool?
curlymo has joined #linux-rockchip
<curlymo> does anyone know how to prepare a standalone SD card boot? I want to write uboot + kernel + OS image to my SD card w/o touching NAND so it boots just with the SD card.
jmcneill has quit [Quit: Leaving]
jas-hacks has joined #linux-rockchip
<jas-hacks> Astralix: you can use 'rkflashkit'
<Astralix> Hmm... Sure, just wonder if there isn't a command line tool available
<jas-hacks> update_tool will also work
<jas-hacks> Linux_Upgrade_Tool_v1.2.tar.gz
<Astralix> hpe do your flash resource.img with that. It doesn't have any parameter for it
<Astralix> let me check...
<jas-hacks> I use 'rkflashkit'
<Astralix> You can use upgrade_tool only with older kernels and setups that do not put part of kernel related things (dtb and boot images) to resource.img
JohnDoe_71Rus has joined #linux-rockchip
<jas-hacks> Astralix: you can use rkflashkit from the command line
<Astralix> Hmm... I just discovered that
<Astralix> From the menu it is a little horror to use it
<Astralix> But the command line is nice to user
<Astralix> -r
<jas-hacks> mmind00_: do you know if there a way to associate a vop to hdmi and it does it auto assign?
JohnDoe_71Rus has quit [Quit: KVIrc 4.2.0 Equilibrium]
curlymo has quit [Quit: HydraIRC -> <- Would you like to know more?]
GriefNorth has quit [Ping timeout: 244 seconds]
<mmind00_> jas-hacks: interesting question ... but I haven't looked into the drm parts to deeply yet so am not sure
jas-hacks has left #linux-rockchip [#linux-rockchip]
akaizen has quit [Read error: Connection reset by peer]
akaizen has joined #linux-rockchip
field^Mop has joined #linux-rockchip
jmcneill has joined #linux-rockchip
<jmcneill> naobsd:
<jmcneill> clotho# sysctl machdep.cpu
<jmcneill> = 1608
<jmcneill> machdep.cpu.frequency.current = 1608
<jmcneill> machdep.cpu.frequency.available = 1608 1416 1200 1008 816 600
<bbelos> CONFIG_LCDC1_IO_18V anyone know how i tell if i need 1.8V or the default 3.3?
markm_ has joined #linux-rockchip
ssvb has quit [Read error: Connection reset by peer]
ssvb has joined #linux-rockchip
<naobsd> Astralix: you can flash resource.img etc with upgrade_tool
<naobsd> e.g. upgrade_tool di resource resource.img
<naobsd> and upgrade_tool is not packing tool, it doesn't make resource.img from xxx.dtb etc
<Astralix> Oh! Didn't know that... Just knew about the -r -s -k and so on
<naobsd> there is another packing tool for it in android sdk
<Astralix> yes, I could probably build an upgrade.img from the various images, but I'd prefer to flash them part by part
<naobsd> I'm not speaking about update.img
<Astralix> you said packing tool
<naobsd> <Astralix> You can use upgrade_tool only with older kernels and setups that do not put part of kernel related things (dtb and boot images) to resource.img
<naobsd> packing tool for resource.img is different to packing tool for update.img
<Astralix> Yes, may be, I was just searching for a linux command line flash tool to send the images to memory
<naobsd> "You can use upgrade_tool only with older kernels" is wrong, it can be used for newer(mainline) kernel too
<jmcneill> sup naobsd
<naobsd> jmcneill: lately I only can say "awesome" ;)
<naobsd> jmcneill: 1.6GHz now stable?
<jmcneill> good!
<Astralix> Yes, sure, I was wrong in that, cause you told me that upgrade_tool resource resource.img works
<jmcneill> seems ok
<naobsd> Astralix: and I guess no one use resource.img to give dtb to mainline kernel
<jmcneill> impressed by the performance
<naobsd> jmcneill: enough, very nice! :)
<jmcneill> $ openssl speed md5 2>&1 | grep ^md5
<jmcneill> md5 4241.43k 15706.98k 51198.47k 117388.16k 189134.50k
<jmcneill> this is the x7
<Astralix> I disassembled a resource image from a stick and in that I found ddtb
<Astralix> dtb
<jmcneill> atropos$ openssl speed md5 2>&1 | grep ^md5
<jmcneill> md5 1737.98k 6576.34k 21582.93k 50503.61k 83528.46k
<naobsd> jmcneill: I didn't check latest code yet, cpufreq code change voltage?
<jmcneill> this is my a20
<naobsd> Astralix: I know it
<jmcneill> it changes voltage now yes
<jmcneill> and instead of setting it on kernel cmdline, you can set it with sysctl
<Astralix> And I flashed a self made kernel to a device without changing resource and it worked fine
<naobsd> Astralix: what I said is (I guess) mainline Linux developer doesn't use that RK method to give dtb
<jmcneill> (supports interface compatible with estd)
<Astralix> I am not at mainline
<Astralix> I am an plain bare naked rockchip sdk
<Astralix> an = at
<naobsd> Astralix: it should work of course
<Astralix> Don't mess this up please... I am at plain naked sdk
<naobsd> Astralix: if you don't change anything include hardware components, same dtb should work, very normal
<Astralix> And I want to flash only this plain naked compile results of the sdk
<Astralix> I didn't change any dtb in my current test, but I wanted to flash the resulting resource.img
<Astralix> And I assumed that it is not supported by upgrade_tool
<Astralix> DownloadImage:DI <-p|-b|-k|-s|-r|-m image> [parameter file]
<naobsd> Astralix: I see, then now you can update resource.img
<Astralix> is what upgrade_tool -h tells you
<naobsd> Astralix: btw you can use rkflashtool too
<Astralix> There is no help or explanation that this tool accepts a fourth optional parameter to this DI command
<naobsd> there is no enough explanation for anything from RK ;)
<Astralix> Yes
<naobsd> some command listed in -h didn't work in some version...
<jmcneill> naobsd: who can i trick into writing a vmac driver
<Astralix> Oh, all commands work! But they do not work in any state of the system
<Astralix> Some only in MASK ROM some in Loader some only after erased all of flash and so on
<naobsd> jmcneill: it's attractive
<Astralix> Most easy way is to roll the dices and if you get a 7, the command works as expected
<Astralix> However, I try that now and see if the firefly gets Android 4.4.4 started as expected
<jmcneill> i will offer hdmi, fb, and audio -- never written a network driver before
<jmcneill> not to say i can't just haven't done it yet
<naobsd> jmcneill: fixing vmac (arc emac) driver in linux mainline is in my todo ;)
<jmcneill> oh is it based on another design?
<Astralix> is the vmac again broken? Or is it the rk3288 you are talking about?
<naobsd> Astralix: which branch are you using? master? pad? I guess master is not updated to 4.4.4 yet
<Astralix> pad
<naobsd> Astralix: I'm sure RK has 4.4.4 source tree, what I'm not sure is firefly updated their tree or not
<Astralix> As I said, I am exactly following the wiki
<Astralix> However, I am missing the parameter file
<naobsd> Astralix: I see, then it should be 4.4.4
<naobsd> Astralix: sorry, there are 2 version on wiki, probably I missed that you said you're trying pad branch
<naobsd> jmcneill: Rockchip vmac is Arc's(now designware's) emac(vmac?)
<Astralix> Yes, and there are probably at least two wikis...
<naobsd> jmcneill: it's different to dwc gmac
<Astralix> however I followed the strings for pad version of the release board
<Astralix> I still wonder that the build process does not create a working parameter file... I guess it is still needed
<jmcneill> not seeing anything i can salvage, nuts
aboahmidd has joined #linux-rockchip
<naobsd> Astralix: what I said is both master and pad branch are explained
<naobsd> Astralix: pad is not only one
<Astralix> yes, I am following that page and use the pad version for release board.
<Astralix> What the page doesn't explain is the creation of parameter file.
<naobsd> Astralix: master branch can be used for release(production ver.) board too
<naobsd> Astralix: pad is not only one for release board
<Astralix> may be
aboahmidd has quit [Client Quit]
<Astralix> didn't test that as in the other wikis anf forum they explicetly tell you to just use pad version as the former master branch is obsolete
<Astralix> And I followed the advice of a wise guy who told me to follow the wiki exactly with out doing everything a bit different anytime
<Astralix> I guess it was you :)
<naobsd> Astralix: sorry, please tell me which forum/wiki explicetly tell master is obsolete
<naobsd> Astralix: yes, wiki I pointed doesn't say don't use master
<Astralix> "We announce...", "From now on...", "new version..."
<Astralix> That sound like 4.4.2 is obsolete
<naobsd> Astralix: git remote add bitbucket
<naobsd> Astralix: From now on, _you can pull from bitbucket_:
<naobsd> Astralix: git pull bitbucket pad:pad
<naobsd> I cannot see any text which says "master is obsolete"
<Astralix> however, the pad version seems to be a new MID SDK for tablets and the master sounds like a BOX SDK for sticks and TV settop boxes but if you read that it is still 4.4.2
<naobsd> it just say "you can run git pull bitbucket after you run git remote add bitbucket"
<Astralix> I added the remote and I pulled and I am at the latest version yesterday eveneing
<naobsd> Astralix: so what?
<naobsd> Astralix: there are 2 version
<naobsd> Astralix: both are still alive
<Astralix> nabosd, it is difficult for me to follow your ideas
<naobsd> Astralix: firefly may obsolete master, but no one said it yet
<Astralix> You now spent 90% of my time to disassemble my words, but you did not give me a single hint where this parameter file went...
<naobsd> Astralix: why? there are 2 version, both are described on wiki
<naobsd> Astralix: ah sorry
<Astralix> I do not have a parameter in that firefly that matches any need for Android, just for Linux and in the SDK there is noe parameter file.
<Astralix> And it is absolutely no discussion if there are 1, 2 of ten versions in the wiki of forum.
<Astralix> I loaded latest and greatest bit for pad. nothing more and nothing less
<Astralix> I just want to flash pad version as described in the wiki
<Astralix> But the wiki misses the point that you have had linux on your firefly and you have no parameter file
<Astralix> so if you read-out parameter from the board, you cannot use it for Android