<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"
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 http://radxa.com/Rock/U-Boot
<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>
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?
<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
<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