ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at | Logs at | ML at
<naobsd> arokux: all I know is I cannot do anything except "fastboot devices" with current rk3188/rk3288 u-boot
<naobsd> and I have working example (ASUS MeMO Pad 8), I don' know the reason about not working
Soopaman has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
<naobsd> it seems firefly was sold out on taobao/aliexpress
RayFlower has joined #linux-rockchip
<naobsd> I guess only few sample boards were available
<naobsd> it might be a reason that they didn't reply about sample boards for developers (it's just my guessing)
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
Soopaman has quit [Quit: Leaving.]
ganbold__ has quit [Ping timeout: 255 seconds]
ganbold_ has joined #linux-rockchip
FreezingAlt has joined #linux-rockchip
FreezingCold has quit [Ping timeout: 255 seconds]
JeffyChen has joined #linux-rockchip
<JeffyChen> naobsd : about fastboot, you can try "fastboot -i 0x2207 getvar unlocked", 0x2207 is rockchip's vendor id
<naobsd> JeffyChen: I modified vendor id in source, I can see device by "fastboot devices"
<naobsd> JeffyChen: did you confirm your command works?
<naobsd> I changed id only fastboot code, i.e. vendor id is changed when switching rockusb to fastboot. it might be wrong
<JeffyChen> fastboot devices will list all devices it found, but other cmd need to specify the vendor id(if it not in the build-in vid list)
<naobsd> well, I know built-in vid list, I changed vid to google(18d1)
<JeffyChen> you change the vendor id in uboot's source code?
<naobsd> anyway, I understood you confirmed your command works, then I have to try same way
<naobsd> I changed u-boot source, not fastboot source
<JeffyChen> i haven't try it this way, but i think this should work too...
<JeffyChen> i used to modify fastboot's source code, add 2207 to built-in list, and it works well for me(in linux)
<JeffyChen> and i also tried to specify vid by "-i" in windows, and it worked too
<naobsd> JeffyChen: which uboot binary/source tree you tried?
<naobsd> thanks
<naobsd> currently I'm trying u-boot in Android SDK for rk3288, little difference
<naobsd> oops, CONFIG_PREBOOT "setenv bootdelay 3" didn't work... how did I enter fastboot last night? ;)
<naobsd> ^on u-boot for rk3188
<JeffyChen> this uboot is for 3288 by default, change CONFIG_RKCHIPTYPE to "CONFIG_RK3188" in for 3188
<JeffyChen> to enter fastboot, you can try "adb reboot fastboot" if your kernel supported
<JeffyChen> or board/rockchip/rk30xx/rk30xx.c:287: checkKey(&boot_rockusb, &boot_recovery, &boot_fastboot); force set boot_fastboot to true
<naobsd> ah, sorry, I know well about it
<naobsd> just joking
<naobsd> ah, I didn't know rkchrome's u-boot supports RK3188
<naobsd> my u-boot for rk3188 is based on this
<naobsd> older than u-boot for rk3288
<naobsd> I remembered that I added special command to set ISetLoaderFlag(SYS_LOADER_REBOOT_FLAG|XXX) both u-boot and rkflashtool
<naobsd> ^last night
<JeffyChen> the uboot in rkchrome is the same uboot for android...just different version
<naobsd> JeffyChen: last commit log in u-boot in SDK is "update uboot 20140821", I guessed it's latest on public
<naobsd> JeffyChen: are you Rockchip person?
<JeffyChen> yes...
<JeffyChen> my poor chinese english, haha
<naobsd> JeffyChen: I see, I never met the person who knows more about u-boot like you :) thank you for your help
<naobsd> JeffyChen: no problem, my japanese english is also poor :)
<JeffyChen> you're welcome, and i was in rk's u-boot team last year..
<naobsd> JeffyChen: great :)
<naobsd> this is the repo I'm maintaining
<naobsd> forked from rkchrome/uboot but it's replaced by u-boot from SDK on u-boot-rk3288 branch and u-boot from Radxa on u-boot-rk3188 branch
<naobsd> I should try rkchrome/uboot for rk3188 because u-boot-rk3188 branch is based on old u-boot
<naobsd> let's try fastboot for now...
<JeffyChen> sure
<naobsd> ah
<naobsd> it just work ;)
<naobsd> I got very strange error that USB handshake was not done correctly
<naobsd> but I think I changed vendor id only in fastboot code
<naobsd> for host(PC) side, vendor id was changed on same device w/o disconnect
<naobsd> I thought ASUS Memo Pad 8 uses vid in the list so I tried to do same...
<naobsd> if I changed whole vid, it may work, but all rockusb tools will not work unless vid is 0x2207 ;)
<naobsd> it's better to use "-i 0x2207"
<JeffyChen> yes, it's the official way
<naobsd> oops, this old u-boot doesn't update unlock state by "oem unlock" ;)
<naobsd> let implement it...
<naobsd> I want to do fastboot boot boot.img (boot new kernel w/o flashing)
<JeffyChen> oh, about unlock, i remember should run fastboot oem unlock_accept after fastboot oem unlock in 5 secs
<naobsd> oh
<naobsd> reading code again...
<naobsd> ah, I see... it also erase userdata
<naobsd> standard "unlock" behavior I guess
<naobsd> hmm
<JeffyChen> yes
<naobsd> I could do "fastboot boot zImage" not "fastboot boot boot.img"
<naobsd> and I noticed there is no way to pass parameter via fastboot
<naobsd> hmmmmmmm....
<naobsd> I have to check newer u-boot for rk3288
<naobsd> (what I want is "boot from USB" w/o flashing)
<naobsd> ah, let's try rkchome/uboot with rk3188
<JeffyChen> i don't think rkchrome/uboot can get paramter though usb..
<JeffyChen> maybe you can try force command line in kernel
<naobsd> include/configs/rk32xx.h:207:3: error: #error : PLS config chip for rk plat!
<naobsd> if my memory is correct, rk3188 support was dropped at some point
<JeffyChen>'re right
<naobsd> of course it's possible to resurrect it on latest u-boot(for rk3288) with some amount of effort
<naobsd> but I think "effort" should be done for porting upstream u-boot
<naobsd> anyway
<naobsd> fastboot is surely working, thanks :)
<JeffyChen> you're welcome
<naobsd> I'm not sure it's better to use "loader key" as "fastboot key"
<naobsd> if fastboot is default, we can go rockusb by fastboot reboot-bootloader
<naobsd> but I prefer rockusb
<naobsd> more useful than fastboot
<naobsd> so let's implement non-standard reset flag for rockusb reset command ;)
<naobsd> which does ISetLoaderFlag(SYS_LOADER_REBOOT_FLAG|XXX)
<JeffyChen> yes, most of us use rockusb more than fastboot
<JeffyChen> right
<naobsd> JeffyChen: btw, do you know why read/write/exec RAM commands were not implemented in u-boot rk3288?
<naobsd> everyone flashes kernel everytime while developing?
<JeffyChen> yes
<JeffyChen> i don't quite understand read/write/exec RAM cmds
<JeffyChen> is that cmd_mem.c ?
<naobsd> ah, rockusb protocol
<naobsd> well
GriefNorth has joined #linux-rockchip
<naobsd> old u-boot for rk3188 and Rockchip proprietary loader for rk3188 has some support
<JeffyChen> i see
FreezingAlt is now known as FreezingCold
<JeffyChen> this just because our uboot team only
<JeffyChen> have one person now
<naobsd> hmm, I see
<JeffyChen> he is quite busy..
<naobsd> I see...
mlilenium_ has joined #linux-rockchip
mlilenium_ has left #linux-rockchip [#linux-rockchip]
Avasz has joined #linux-rockchip
<naobsd> reboot to fastboot is also added to u-boot-rk3288
<naobsd> but fastboot boot zImage doesn't work :(
<naobsd> failed to find part:04ff0000
<naobsd> failed to prepare_fdt from 04ff0000!
<naobsd> failed to find part:resource
<naobsd> failed to prepare_fdt!
<naobsd> Unable to boot:04ff0000
<naobsd> I guess resource partition is needed
<naobsd> ah
<naobsd> dtb can be included in ANDROID! image
<JeffyChen> yes, in the second data area
Avasz has quit [Ping timeout: 260 seconds]
<naobsd> hmm, I think I properly set --second resource.img
<naobsd> but got error...I think I missed something
<naobsd> anyway
<naobsd> if I flashed loader, parameter, resource,
<naobsd> I can boot boot.img by "fastboot boot boot.img"
<naobsd> on my rk3288 box.
<naobsd> very nice
<naobsd> JeffyChen: thank you for your information :)
<JeffyChen> you're welcome
<JeffyChen> i saw this command in mkbootimg --kernel $OUT/kernel --ramdisk $OUT/ramdisk.img --second kernel/resource.img --output $OUT/boot.img
<naobsd> yes, very recent rk3288 android sdk does it too
<naobsd> but I did it by my hand, I'll retry later
<naobsd> it's lunch time for now
<JeffyChen> yes
<naobsd> (not android building)
benja` is now known as benja
<naobsd> hmm
<naobsd> if u-boot is booted from eMMC, rockusb works (of course)
<naobsd> but if u-boot is loaded/run from USB on mask rom mode, rockusb doesn't work :(
<naobsd> USB is used by mask rom and may not be reset properly by u-boot
<naobsd> if usbplug loader is loaded/run from USB on mask rom mode, rockusb works fine (of course)
cyrozap has quit [Ping timeout: 272 seconds]
cyrozap has joined #linux-rockchip
benja is now known as benja`
FreezingCold has quit [Ping timeout: 240 seconds]
FreezingCold has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
rperier has quit [Remote host closed the connection]
rperier has joined #linux-rockchip
rperier has quit [Changing host]
rperier has joined #linux-rockchip
ganbold_ has quit [Ping timeout: 255 seconds]
cyrozap has quit [Ping timeout: 245 seconds]
cyrozap has joined #linux-rockchip
ganbold_ has joined #linux-rockchip
Avasz has joined #linux-rockchip
Avasz has joined #linux-rockchip
<hramrach_> naobsd: normal u-boot supports loading kernel arguments from environment
<hramrach_> not sure about the rk one
<naobsd> here is #linux-rockchip
<hramrach_> I know. bootenv should be the same unless rk butchered u-boot too much
<hramrach_> *bootargs
<naobsd> when I said I don't know about it?
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
<JeffyChen> rk's uboot only parse bootargs from "parameter", official android should be from !ANDROID bootable image. not in u-boot's legacy way
RayFlower has joined #linux-rockchip
<hramrach_> I would say anything with android in it is legacy but whatever
<hramrach_> so on rk u-boot bootargs don't work?
<JeffyChen> it will load bootargs from parameter partition, and set into environment(override the origin "bootargs" env)
<JeffyChen> just before jump to linux
<hramrach_> so the order would be environment, parameter partition, android image?
<JeffyChen> no, the origin bootargs env would be replaced by the one got from parameter, and rk's uboot just ignore the bootargs stored in android image
<JeffyChen> the same as the old non-uboot rk loader
<hramrach_> ok, thanks
<JeffyChen> you're welcome
Avasz has quit [Ping timeout: 260 seconds]
cyrozap has quit [Ping timeout: 240 seconds]
Avasz has joined #linux-rockchip
Avasz has quit [Changing host]
Avasz has joined #linux-rockchip
<rperier> hi all
<hramrach_> hello
Avasz has quit [Ping timeout: 260 seconds]
<hramrach_> is there some chance to get a device working without the sources for the original rom?
<hramrach_> I have used gpio_dump to get as much information as possible but I do not have dram settings
<hramrach_> and I do not know how to convert what gpio_dump produces into useful configuration
<hramrach_> which I could posibly use with the loader already on the device which sets up ram in some way or another
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<naobsd> hm
<naobsd> fastboot boot does do_booti(), then do_go()
Avasz has joined #linux-rockchip
cristian_c has joined #linux-rockchip
<cristian_c> Hi
<cristian_c> naobsd, I've launched fbset
<cristian_c> lcd displays looses the video signal
<cristian_c> so, the display led changes color
<naobsd> I guess load_fdt() doesn't read fastboot image on ram
<naobsd> but fixing it shouldn't so difficult
<naobsd> how to handle bootargs is also not difficult
<naobsd> cristian_c: well?
arokux2 has joined #linux-rockchip
<cristian_c> naobsd, :D
<cristian_c> naobsd, anyway, fbset is accepted from cwm
<cristian_c> also if result is bad
<cristian_c> :(
<cristian_c> this is an improvement
<cristian_c> naobsd, I try to read the dmesg
<cristian_c> to be sure
<hramrach_> it might be power saving
<naobsd> cristian_c: I don't know how you launched
<cristian_c> naobsd, fbset -xres value1 -yres valu2
<cristian_c> *value2
<hramrach_> maybe try a preset mode
<cristian_c> hramrach_, my resolution is not present in /sys/devices/virtual/display/display0.HDMI/modes
<hramrach_> what did fbset -s show after boot?
<cristian_c> and value in /sys/devices/virtual/display/display0.HDMI/mode is wrong
<cristian_c> 1920x1080
<cristian_c> hramrach_, in cwm recovery?
<naobsd> cristian_c: I thought fbset doesn't change HDMI signal
<cristian_c> hramrach_, I've created a fbset copy in cwm recovery
<hramrach_> yes, whereever
<hramrach_> so it should support -s
<naobsd> cristian_c: and if your monitor doesn't accept 1080p, what you need is to change HDMI mode, not framebuffer size
<hramrach_> also you can upload /etc/fb.modes into recovery to try preset modes from there
<hramrach_> well, correctly implemented framebuffer changes screen mode when framebuffer resolution changes
<hramrach_> if rk's does is another question
<cristian_c> so, I can use fbset only after copied it, copied arm-linux-gnueabihf directory,, created bin and lib directory, moved the files into bin and lib, created a symbolic link to /dev/graphics/fb0 in /dev
<hramrach_> and you can copy /etc/fb.modes too
<hramrach_> and then use like bfset 1600x1200-60
<cristian_c> naobsd, you have suggested me to change the framebuffer instead of hdmi mode
<cristian_c> I've already tried to change hdmi mode
<cristian_c> hramrach_, I take a look
<hramrach_> fbset -s should show current mode
<cristian_c> hramrach_, so, should I change the recovery.img creating fb.modes in /etc and repacking and reflashing recovery.img?
<cristian_c> and then launching fbset -s
<cristian_c> but fbset is not contained in cwm recovery by default
<hramrach_> fbset -s is independent of fb.modes
<naobsd> cristian_c: try "fbset -a -nonstd 4 -g 1280 720 1280 720 16 -rgba 5/11,6/5,5/0,0/0"
<cristian_c> ok
<hramrach_> you can upload random files over adb while cwm is running
<cristian_c> yeah, I know
<cristian_c> I've uploaded files with adb push
<hramrach_> fb.modes is just helper file that is included with fbset and lists standard modes so that you do not have type all the parameters
<cristian_c> hramrach_, I've pushed only fbset executable to cwm
<cristian_c> :)
<cristian_c> now, I try the command
<naobsd> cristian_c: btw, which TV are you using? is there HDMI switch or something? did you power-on TV and select input before power-on your board?
<cristian_c> naobsd, lcd display with 1440x900 resolution
<naobsd> cristian_c: I remembered that if my TV is power-off while booting my board, I cannot get TV output
<cristian_c> as written in the package and in the display manual
<cristian_c> naobsd, I'm using vga connection
<cristian_c> ok
<cristian_c> naobsd, in android resolution is correctly displayed, in cwm recovery no
<cristian_c> it's strange
<cristian_c> but I changed the resolution when I purchased the tv dongle
<cristian_c> from rockchip hdmi settings
<naobsd> well, after above fbset command? is it first time "correctly displayed" after fbset?
<cristian_c> no, I was doing a comparison between display size in android and cwm
<cristian_c> sorry :)
<naobsd> ah
<naobsd> cwm doesn't use android setting
<cristian_c> now, I try (I must type again all the above commands to use fbset)
<cristian_c> naobsd, I know
<naobsd> which HDMI setting is working on android? probably you have to choose 1080/720/480 i/p 50/60hz and no 1440x900
<naobsd> think android setting doesn't change framebuffer size, only HDMI signal is changed
<naobsd> ^I
<cristian_c> ok
<cristian_c> I take a look at the system partition
<naobsd> well, system partition should have no relation...
<cristian_c> naobsd, the fbset -a -nonstd 4 -g 1280 720 1280 720 16 -rgba 5/11,6/5,5/0,0/0 returns the same result as in the previous fbset command
<naobsd> lost signal?
<naobsd> can you see any output on lcd before fbset run? (what is initial state when booting cwm?)
<cristian_c> yeah, I see the cwm recovery screen
<cristian_c> with wrong resolution
<naobsd> how wrong?
<cristian_c> now, I've rebooted to android to check the hdmi resolution in settings :)
<cristian_c> naobsd, too big
<naobsd> I see
<naobsd> well, large text/icon?
<cristian_c> sorry, the image goes out off the screen
<cristian_c> yeah, text out the screen
<naobsd> ah
<naobsd> well
<naobsd> do you know about this?
<cristian_c> ok, hdmi mode in android: 1280x720p-60
<naobsd> and probably there is a setting on Android like scaling/zooming
<cristian_c> naobsd, now, I read
<cristian_c> I remeber I changed the hdmi mode the first time
<cristian_c> for the same reason
<naobsd> it's different thing than HDMI mode and framebuffer size
<cristian_c> naobsd, I've already checked it
<cristian_c> in cwm recovery: 95 and 95
<naobsd> rockchip kernel might have similar setting in both HDMI and framebuffer
<naobsd> well
<naobsd> ah,
<naobsd> recent kernel may kill these setting (under /sys) and may scale GL surface for it
<cristian_c> ok
<naobsd> ^on android
<naobsd> please check scaling setting on android. if you're using 100%, your lcd doesn't do overscan
<naobsd> please change scale value under HDMI or fb (unser /sys) to different one, if screen have no change, it's killed
<naobsd> ^change scale on cwm
<naobsd> it seems what you need is scaling(shrinking) function on cwm
<naobsd> later cwm has a function to scale output on GL surface (which can be used on any device)
<naobsd> but my cwm is old
<naobsd> I'm not sure why fbset kills output signal
<naobsd> maybe 1280x720 doesn't match edid info, fbset is failed, then lcdc is stopped (if it's correct, there is some info on dmesg)
<cristian_c> also if I change files in /sys/devices/virtual/display/display0.HDMI/
<cristian_c> scale file included
<cristian_c> I cannot apply the changes
<cristian_c> I can try to read the dmesg
<naobsd> echo scale=100 > scale , or echo 100 > scale ?
<cristian_c> the file was changed
<cristian_c> but then is needed to apply the changes
<naobsd> it's applied immediately if it's not killed in kernel
<cristian_c> uhm, strange
<cristian_c> I try
<naobsd> killed=just ignored
<naobsd> "file was changed but no effect" is not strange
<naobsd> please find fb0/scale under /sys
<naobsd> (but it may be killed too)
<cristian_c> ~ # cat /sys/devices/virtual/display/display0.HDMI/scale
<cristian_c> xscale=95 yscale=95
<cristian_c> I try to change the value
<cristian_c> ah, ok
<cristian_c> block class devices firmware kernel power
<cristian_c> bus dev dvfs fs module sd-sdio
<cristian_c> /sys # ls
<naobsd> find /sys -name fb0
<cristian_c> naobsd, I try with 80 value for scale
<cristian_c> ok
<naobsd> 80 worked?
<cristian_c> /sys/devices/platform/rk-fb/graphics/fb0
<cristian_c> /sys/class/graphics/fb0
<cristian_c> naobsd, I must try
<naobsd> if there is fb0/scale, please try it too
<naobsd> but if you're using very recent kernel, it will not work
<cristian_c> naobsd, scale is present in both the directory
<naobsd> actually it may work when changing framebuffer size by fbset(if it doesn't kill output) but I think it's a bug ;)
<cristian_c> ~ # cat /sys/devices/platform/rk-fb/graphics/fb0/scale
<cristian_c> xscale=100 yscale=100
<cristian_c> ~ # cat /sys/class/graphics/fb0/scale
<cristian_c> xscale=100 yscale=100
<naobsd> I guess both is same
<cristian_c> ok
<naobsd> probably /sys/class/ is symlink
<cristian_c> ~ # echo 80 > /sys/devices/platform/rk-fb/graphics/fb0/scale
<cristian_c> ~ # cat /sys/devices/platform/rk-fb/graphics/fb0/scale
<cristian_c> xscale=80 yscale=80
<naobsd> output is changed? or not changed? it's important
<cristian_c> naobsd, as I expected, it has got no changes
Avasz has quit [Ping timeout: 272 seconds]
<cristian_c> nothing has been happened
<naobsd> :(
<naobsd> I think what you need is scaling, not change HDMI mode or not change fb size
<cristian_c> ok
<naobsd> well
<naobsd> can you set HDMI mode to 720p 60hz?
c0d3z3r0 has quit [Ping timeout: 240 seconds]
c0d3z3r0 has joined #linux-rockchip
<naobsd> it may not change appearance, but HDMI mode should be changed. if your lcd can show info about input signal, you can check it
<cristian_c> ~ # cat /sys/devices/virtual/display/display0.HDMI/mode
<cristian_c> 1920x1080p-60
<cristian_c> naobsd, no info about signal after scale file change
<naobsd> can you change it to 1280x720p-60?
<naobsd> scale file does nothing for HDMI signal
<naobsd> even if it's not killed
<naobsd> it just modify image on display, not signal
<naobsd> what I asked now is change HDMI mode
<cristian_c> ~ # echo "1280x720p-60" > /sys/devices/virtual/display/display0.HDMI/mode
<cristian_c> ~ #
<cristian_c> image is very little
<naobsd> it changes HDMI signal output from your box, and HDMI input on your lcd should be changed
<cristian_c> very very tiny
<naobsd> oops
Avasz has joined #linux-rockchip
<naobsd> ah
<naobsd> you changed HDMI/scale?
Avasz has quit [Changing host]
Avasz has joined #linux-rockchip
<cristian_c> naobsd, In past, I tried this echo command, with 1440x900p-75 but I got:
<naobsd> HDMI/scale may be applied while changing mode
<cristian_c> ~ # echo "1440x900p-75" > /sys/devices/virtual/display/display0.HDMI/mode
<cristian_c> sh: write error: Invalid argument
<naobsd> probably it's not in HDMI/modes
<cristian_c> naobsd, now, with 1280x720 wirks!
<cristian_c> *works
<cristian_c> *it
<naobsd> probably you only can choose 1080/720/480 on Android
<cristian_c> ok
<naobsd> well
<naobsd> what is current HDMI/scale value?
<naobsd> oh well
<cristian_c> ~ # cat /sys/devices/platform/rk-fb/graphics/fb0/scale
<cristian_c> xscale=80 yscale=80
<naobsd> you said you tried to change HDMI/mode, but actually it was "tried to set 1440x900p-75 and failed"?
<naobsd> I thought you tried 720p
<naobsd> cristian_c: what I asked is HDMI/scale, not fb0/scale
<cristian_c> ok
<naobsd> I guessed HDMI/scale, but if you get too small image, both HDMI/scale and fb0/scale may be applied
<cristian_c> naobsd, in past, not today
<cristian_c> weeks ago
<naobsd> I thought you tried 720p, but if you didn't, then both scale may not be needed, just set 720p may solve your problem
<naobsd> ok, just set 720p didn't solve problem in the past
<naobsd> then scale should be applied this time
<cristian_c> in past I tried 900p, today I've tried 720p
<naobsd> oh
<naobsd> please explain more clearly...
<naobsd> then just set 720p may be answer
<cristian_c> ok
<cristian_c> weeks ago, I tried echo "1440x900p-75" > /sys/devices/virtual/display/display0.HDMI/mode
<cristian_c> but I got invalid argument
<naobsd> please forget about 1440x900
<cristian_c> today I've tried echo "1440x900p-75" > /sys/devices/virtual/display/display0.HDMI/mode
<cristian_c> ok
<naobsd> what I asked is 720p and value of scales
<cristian_c> sorry
<cristian_c> today I've tried echo "1280x720p-60" > /sys/devices/virtual/display/display0.HDMI/mode
<naobsd> well
<naobsd> try "echo 1920x1080p-60" > /sys/devices/virtual/display/display0.HDMI/mode" now
<cristian_c> ~ # cat /sys/devices/virtual/display/display0.HDMI/scale
<cristian_c> xscale=95 yscale=95
<naobsd> if scale is working, you'll get same small image
<naobsd> 95% is not so "too small", I guess both 80% and 95% is applied
<naobsd> or
<naobsd> scaling may not be applied at all, and your lcd doesn't support both 1080p(too large) and 720p(too small)
<naobsd> you can confirm by same procedure but different(or default) scale value from reboot
<naobsd> if you use your lcd with PC, what happen if you input small resolution?
<naobsd> if you disabled scaling function on lcd(=dot-by-dot mode), 1080p must be too large, and 720p must be too small
<naobsd> but you said it's fine on Android(=720p), your lcd shouldn't be dot-by-dot mode
<hramrach_> most LCDs can only scale up
<hramrach_> so 720p should work on most 900p screens but 1080p not
<naobsd> many smaller-than-1920x1080 LCD supports 1080p input
<naobsd> of course it's not "all".
<hramrach_> TVs maybe or displays intended for TV replacement
<hramrach_> haven't seen a computer display with scale down feature
<cristian_c> naobsd, sorry for waiting
<cristian_c> naobsd, with your command image is increased in size
<cristian_c> :)
<naobsd> thank you for pointing it out
<naobsd> well, fbset works this time?
<naobsd> font and icon size is fixed and not scaled by framebuffer size, so if default is 1920x1080 and changed to 1280x720, font/icon will be relatively larger
<cristian_c> naobsd, 720p is smaller but it's better than 95 scaling
<naobsd> oh, scaling is really applied?
<cristian_c> *than 100%
<naobsd> btw framebuffer size and HDMI mode is independent
<cristian_c> not, only to ~ # cat /sys/devices/platform/rk-fb/graphics/fb0/scale
<cristian_c> xscale=80 yscale=80
<naobsd> hmm
<cristian_c> but it's really changes
<cristian_c> *changed
<naobsd> well
<naobsd> if you run fbset, scale values should be applied
<naobsd> there are many parameters, to confirm what happened, you need to change only 1 parameter at a time...
<naobsd> anyway
<naobsd> if you found answer, no need to confirm anymore
<naobsd> just use scale/mode/fbset values which is good for you :)
<cristian_c> naobsd, anyway, fbset is not present in the cwm recovery
<cristian_c> it must be pushed via adb
<hramrach_> and does it do anything?
<cristian_c> with arm,.. and ld directory and file
<hramrach_> you changed the mode by the echo command, right?
<naobsd> cristian_c: you know how to change cpio image
<cristian_c> naobsd, i've tried the answer
<cristian_c> *it needed
<cristian_c> :)
<cristian_c> fbset is unnecessary, Iit need only working with echo commands
<cristian_c> I can unpack and repack the recovery image
<cristian_c> but I don't know what files I have to change to set the recovery image
<naobsd> oh I think I misunderstood "with your command image is increased in size" I thought you used fbset
<cristian_c> I needed to change resolution to read the text of options in cwm reecovery
<cristian_c> naobsd, sorry, I've used echo commands:
<naobsd> anyway you have answer, no need to explain it again ;)
<cristian_c> echo value > /sys/devices/platform/rk-fb/graphics/fb0/scale
<cristian_c> echo "value" > /sys/devices/virtual/display/display0.HDMI/mode
<cristian_c> that's all
<cristian_c> :)
<naobsd> I see
<cristian_c> echo "value" > /sys/devices/virtual/display/display0.HDMI/scale
<naobsd> in the past echo xxx > scale applied immediately
<cristian_c> has no effects
<cristian_c> naobsd, ah, ok
<naobsd> and in the past HDMI/scale was effective
<naobsd> but old info is useless for you
<cristian_c> by default /sys/devices/virtual/display/display0.HDMI/scale is 95
<cristian_c> and by default /sys/devices/platform/rk-fb/graphics/fb0/scale is 100
<naobsd> cristian_c: it can be changed when compiling kernel, some kernel may have different value
<cristian_c> it needed change value in the second file from 100 to a lower value
<naobsd> ^it = default scale value
<cristian_c> ok
<naobsd> if you have kernel source, you can change default value
<naobsd> and I think there is some lines that tries to set scale value in /init.rc or somewhere else
<naobsd> you may edit it
<cristian_c> ok, but I've to download the kernel
<cristian_c> *kernel source
<naobsd> /init.rc in my cwm image
<cristian_c> for the cwm recovery
<naobsd> I'm not sure, I might be removed when I found it doesn't work on recent kernel at some point
<naobsd> I'm sure I added some lines for scaling in the past
<cristian_c> naobsd,
<naobsd> probably "write /path/to/scale value"
<naobsd> well, /init.recovery.XXX.rc ?
<cristian_c> there is init.recovery.rk30board.rc
<naobsd> anyway, what you need is some "write /path/to/xxx value" lines
<cristian_c> but path is wrong
<naobsd> not wrong, it was correct on some old kernel
<naobsd> anyway, you can remove useless lines and add lines you need
<cristian_c> naobsd,
<cristian_c> paste expiration is 1 hour
<naobsd> remove last line and add lines you need
<cristian_c> naobsd, I tried to correct the path in past weeks but it has no changes
<naobsd> because it doesn't applied immediately on your kernel
<cristian_c> naobsd, ah, ok, I understood
<naobsd> you need to update HDMI/mode
<naobsd> after scale
<cristian_c> ok
<cristian_c> thanks
<cristian_c> I've to add a further wirte in the rc
<cristian_c> :)
<cristian_c> *write
<cristian_c> naobsd, thank you very much
<naobsd> I think this behavior is a kind of bug ;)
<naobsd> recent RK Android should do scaling on GL layer
<naobsd> (it may be wrong but it's not important here ;)
<naobsd> hm
<naobsd> building latest Android SDK for rk3288 was done some times ago...
<naobsd> I want faster build machine
<arokux2> hi naobsd
<naobsd> arokux2: hi
<cristian_c> ok , I've done a test
<cristian_c> the /sys/devices/platform/rk-fb/graphics/fb0/scale change works only if I use a different resolution (for example 1280x720) instead
<cristian_c> *instead of default resolution (1920x1080)
<cristian_c> I've done the test to be sure :D
<naobsd> I thought it applied when fbset runs
<arokux2> what is happening in RK world if in several sentences...?
<naobsd> arokux2: RK world is too large! ;)
<arokux2> naobsd: I guess you are exploring u-boot?
<naobsd> arokux2: about mainlining?
<naobsd> arokux2: yes and no, I try to explore everything about I don't know
<cristian_c> naobsd there isn't fbset in the cwm
<cristian_c> :)
<arokux2> naobsd: what about booting u-boot from SD card and using tftp to download the kernel and than boot it. how are things looking here?
<hramrach_> should work provided you have a board with stmmac and somebody wrote stmmac glue for u-boot
<naobsd> cristian_c: cwm recovery calls some ioctls as like as fbset, but probably you're right
<cristian_c> every time I reboot cwm recovery, I've to push fbset via adb if I want to use it
<cristian_c> naobsd, ah, ok
<naobsd> arokux2: RK u-boot doesn't support ethernet (for now)
<cristian_c> I didn't know
<arokux2> hramrach_: what's on the radxa?
<hramrach_> I have no idea
<naobsd> cristian_c: I think you know how to unpack/repack recovery.img...
<naobsd> haha
<hramrach_> I did not get a radxa rock
<naobsd> everything should work if someone make it work ;)
<cristian_c> naobsd, yeah
<naobsd> cristian_c: anyway, fbset is not needed anymore
<cristian_c> exactly
<hramrach_> well, the glue for stmmac was not that big a change on AW so it's something you can presumably do with the hardware in hand and stmmac driver in mainline linux to look at
<naobsd> arokux2: boot from SD card is working
<hramrach_> does USB host work?
<hramrach_> maybe u-boot has some USB dongle support
<arokux2> hramrach_: it does.
<hramrach_> hmm, I'm wondering if I should upgrade my tablet to android 4.2. Is there some way to backup the current rom?
<arokux2> naobsd: any USB support in u-boot?
<hramrach_> and any support for reading read the areas written with l L rkflashtool command?
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<naobsd> arokux2: only rockusb and fastboot slave
<arokux2> naobsd: anybody thought about porting rk-u-boot to mainline u-boot?
<naobsd> arokux2: I "just thought"
<arokux2> :) and...?
<arokux2> is somebody doing it? will you want to mentor someone doing it...?
<naobsd> arokux2: I have no idea what/when I can do for everything
<hramrach_> you are free to start :)
<hramrach_> bah, Chinese looks really bad in my browser. and cannot read it :/
<arokux2> hramrach_: rk u-boot is full of chinese? :)
<hramrach_> no, searching for tablet firmware
<hramrach_> it probably is full of Chinese too but not looking at it
<hramrach_> I have no use for it, anyway
<naobsd> arokux2: if you want to send kernel via USB, you can use fastboot
<naobsd> arokux2: and/or my exec ram hack with rkflashtool
<naobsd> arokux2: and you may use kexec to load new kernel
<hramrach_> that's an option but exporting it through tftp and have the tablet download it is more automated
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
Avasz has quit [Ping timeout: 255 seconds]
JeffyChen has quit [Ping timeout: 246 seconds]
Guest66547 has joined #linux-rockchip
Guest66547 has quit [Remote host closed the connection]
<arokux2> naobsd: so rk-u-boot applies against the mainline u-boot?! :)
<naobsd> arokux2: sorry, I cannot understand...
<arokux2> naobsd: the RK u-boot is based on most recent u-boot, right? 2014-04
<arokux2> naobsd: rk3188 is based on 2014-01 and rk3288 on 2014-04
<naobsd> arokux2: well, version is correct, but any u-boot fork is based on u-boot...
<arokux2> naobsd: yes, but if the version were too old it would have been much more difficult to port
<naobsd> arokux2: yes
<arokux2> naobsd: the u-boot that rk was using is so new, that we could basically just submit code to mainline just after cleaning or so...
<naobsd> arokux2: I think there was no reason to use more older version when RK started to u-boot work
<naobsd> arokux2: I don't know "cleaning" is small work
<arokux2> naobsd: of course. but they could have started several years ago and do not merge upstream any more
<naobsd> anyway it should be done to support virtualization
cristian_c has quit [Quit: Sto andando via]
<arokux2> naobsd: is mask rom read only? :)
<naobsd> arokux2: mask rom is read only because it's mask rom...
<arokux2> naobsd: yes, rom - read only mem, I was just double checking
<naobsd> _mask_ rom
<naobsd> generic term
<arokux2> naobsd: ah... yes, thank.
<naobsd> btw I'm not sure it's really mask rom is in RK cpu
<naobsd> well
<naobsd> btw I'm not sure it's really mask rom which is in RK cpu
<naobsd> but as far as I know the code in RK CPU is read-only
<arokux2> I'm trying to understand what is the lowest hardware level, as I understand it is mask rom
<naobsd> it's read-only and RK tools say "mask rom mode" so I think it's mask rom
<naobsd> I cannot remember how it explained in TRM, but such a name of technology may not be important
<arokux2> naobsd: u-boot is loaded by rk....loder.bin, right?
<arokux2> loader*
<naobsd> u-boot can become a part of RKxxxLoader.bin
<naobsd> and can become secondary loader loaded from first loader in RKxxxLoader.bin
<naobsd> e.g. RK3288Loader_uboot_V2.15.02.bin <- u-boot is first loader
<naobsd> RK3188Loader_miniall.bin + uboot.img (uboot partition) <- u-boot is second loader
<naobsd> if you need NAND support, you have to use miniall first loader
<naobsd> miniall provides A
<naobsd> miniall provides API(may not be correct word)
<arokux2> naobsd: what is miniall?
<naobsd> arokux2: 1st loader which provides NAND access functions for 2nd loader
<naobsd> (I'll leave here soon for a while)
<arokux2> naobsd: so then it is RK3188Loader_miniall.bin ---> miniall --> uboot.img?
<arokux2> ohhh))
<arokux2> RK3188Loader_miniall.bin
<naobsd> RK3188Loader_miniall.bin is miniall
<arokux2> it is miniall already
<arokux2> yes, sorry
<naobsd> 1st loader is actually 2 parts, DDR init and loader
<arokux2> naobsd: x_miniall.bin is binary?
<naobsd> arokux2: yes and no, there is structure
<arokux2> naobsd: alright, thanks!
<naobsd> 2sets of "DDR init and loader"
<naobsd> one for USB boot from mask rom, another for flashing NAND/eMMC/etc
<naobsd> sorry, it's time to leave
<naobsd> later
<arokux2> ok
AstralixNB has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
nighty-_ has joined #linux-rockchip
RaYmAn has quit [Ping timeout: 245 seconds]
mac- has quit [Ping timeout: 240 seconds]
ssvb has quit [Ping timeout: 245 seconds]
mac- has joined #linux-rockchip
RaYmAn has joined #linux-rockchip
wigyori has quit [Ping timeout: 240 seconds]
wigyori has joined #linux-rockchip
ssvb has joined #linux-rockchip
arokux2 has quit [Remote host closed the connection]
AstralixNB has quit [Read error: Connection reset by peer]
GriefNorth has quit [Ping timeout: 260 seconds]
hipboi has quit [Ping timeout: 260 seconds]
AstralixNB has joined #linux-rockchip
benja` is now known as benja
benja is now known as benja`
hipboi has joined #linux-rockchip
rz2k_ has joined #linux-rockchip
<rperier> rock-chip guys seem to have problems with authorship and the "signed-off-by" label ^^
<naobsd> first impression: cubieboard!
<rperier> nice !
<arokux> naobsd: btw, the detailed description of the boot sequence is described in trm for rk30xx.. I should have read that before asking you
<AstralixNB> Connector-Chaos-Board... How will this be mounted other than free hanging in the air?
<arokux> omg..
<arokux> I hate China for that :(
<AstralixNB> You'll probably never fit a mic and headphone at the same time, connectors are not aligned properly, connector on all four sides.
<AstralixNB> Bigger micro-USB housing of the cable will cover the button below
<AstralixNB> And buttons on two sides of the board... So seen from someone who likes to cover his electronics in neat little housings this is a nightmare.
<arokux> AstralixNB: they do not think about this.. they just CLONE & SELL
<naobsd> arokux: TRM may not explain form of software such as 1st loader, 2nd loader
<arokux> naobsd: that is right.
<AstralixNB> Yes, I know
<AstralixNB> Sorry, could not resist...
<arokux> naobsd: is there rk software that understands mask boot rom USB protocol?
ganbold__ has joined #linux-rockchip
<naobsd> arokux: all RK official tool knows how to handle mask rom mode
<arokux> naobsd: has anybody tried to RE the protocol?
<arokux> naobsd: oh, so you reversed it already?!
<naobsd> personally, most difficult thing is NAND physical access. protocol is easy, but I don't know how to make data properly e.g. ECC, bad block handling, etc
ganbold_ has quit [Ping timeout: 255 seconds]
<naobsd> we still can't flash RKxxxxLoader.bin via rkflashtool
<arokux> naobsd: i.e. how to write RKxxxxLoader.bin to NAND with rkflashtool, right?
<naobsd> arokux: yes
<naobsd> arokux: more specifically, as I said there are 2sets of "DDR init and loader" in RKxxxLoader.bin
<naobsd> arokux: "my implementation" can transfer first set "for USB boot from mask rom"
<naobsd> arokux: but 2nd set "for flashing to NAND" cannot be handled
<arokux> naobsd: the 1set is for copying to RAM and booting from there, right?
<naobsd> arokux: yes
<naobsd> arokux: this might be helpful
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<naobsd> well
<AstralixNB> there are many people doing something on RK SOCs, I am not sure, what will bring the most benefit to the thing
<AstralixNB> so if someone starts (restarts) into Rk SOC devel, what will be best thing to do first?
<naobsd> probably many user want bug free RK 3.0(or fully functional) kernel
<AstralixNB> Yes, but bug free often is linked to the application itself...
<AstralixNB> Are there general bugs known that affect all / most users?
<naobsd> I can understand it and I want to fix bugs if possible, but I'm not sure using time for 3.0 is really good
<arokux> users and hackers have different interests
<naobsd> I guess many of "XXX doesn't work" is "I don't know how to do XXX properly"
<AstralixNB> Ah... in that case I am more of a user as I want to use my devices...
<naobsd> anyway, 3.0 should have a lot of bugs
<AstralixNB> Yes, but which?
<AstralixNB> I see some things, that are not implemented, but I use the 3.0.36+ for desktop linux now for about a week and it works pretty cool
<naobsd> but it will be good to use time for mainline
<AstralixNB> Surfin, compiling even OpenJDK7 and Eclipse work fine
<AstralixNB> Ya, sure, but then we're off of any GPU and VPU accelleration
<naobsd> I'm using 3.0.36+ desktop some monthes on my job
<AstralixNB> But the users want to have fast Video and 2D accel
<AstralixNB> I guess most benefit over all will be to support a kernel that makes 2D and VPU availablel, whichever name it has
<naobsd> "support feature which runs on Android but not run on Linux" is also one of important things
<naobsd> personally I have interest to run mainline Linux/u-boot
<AstralixNB> Yes... ugly decision of RK to make slim interfaces in kernel and do the rest in Android
<AstralixNB> Me too!
<arokux> and me :)
<AstralixNB> and I have at least 3 other people
gb_master has joined #linux-rockchip
<AstralixNB> ... correct 4 other people, arokux, that prefer linux desktop
FreezingCold has quit [Ping timeout: 272 seconds]
<arokux> AstralixNB: it is not decision by RK, it is by ARM
<AstralixNB> nope
<AstralixNB> arokux, I am talking of 2D and VPU not MALI
<arokux> oh, this is separate, ok.
<arokux> so MALI isn't needed to play video at all?
<AstralixNB> a small part of MALI is 2D too, but I am talking of IPP and VPU units in the chips that are bought and licensed by another company
<AstralixNB> no, MALI hasn't anything to do with video
<naobsd> RGA/IPP thing may be relatively easy (compared to video decoders/encoders)
<AstralixNB> right
<naobsd> and useful for general 2D accel
<AstralixNB> Yes
<naobsd> well, btw,
<naobsd> I'm not leader, I cannot talk things like "our big goal"
<AstralixNB> no, but pulling on the same string puts more energy into it...
<naobsd> what I can do is only "what I can do now", sometimes I try mainline thing, sometimes try u-boot, sometimes ...
<AstralixNB> me too
<AstralixNB> for me the whole thing is judt for fun and hobby. no commercial interests. And somtimes programming uboot can be sort of a holiday from programming kernel drivers :)
<naobsd> this is the reason I cannot answer question like "what should we do for future?"
<AstralixNB> Hmmm. But it doesn't make sense someone starts into something that someone else has already almost done.
<naobsd> of course I'm tying to think about it now...
<AstralixNB> Only want to avoid duplicates
<AstralixNB> sure, but that is for mainline
<naobsd> I have to write some things
<naobsd> no
<naobsd> "Please create a section for each project of the linux-rockchip community (bootloader, buildroot, etc...)"
<AstralixNB> And the phy-usb is something I started before I had to pause it cause of vacation times and job projects
<AstralixNB> according to mmind00, usb-phy is still open in mainline.
<AstralixNB> but yea, it would be cool to have this page maintained and filled with tasks
<AstralixNB> rperier, are you around?
<AstralixNB> arokux, let's copy that list and do the same job as they did :)
<arokux> :)
<arokux> wiki is very nice
<AstralixNB> I need to ask something about the emac thing, rperier
<arokux> I wrote some pages too
<naobsd> cleaning is one of todo...
<naobsd> don't believe it w/o confirmation...
FreezingCold has joined #linux-rockchip
<AstralixNB> I can help... I have login
<arokux> there is/was a problem with
<naobsd> I prefer "need understanding/confirmation before publishing", but it seems it's not common :(
<arokux> it belongs to olimex. their employees were deleting some stuff hipboi was adding about radxa. so hipboi created separate wiki for radxa
<arokux> belongs to community
<naobsd> currently I own
<rperier> AstralixNB: yes I am here
<rperier> :)
<AstralixNB> hmm... I can understand, cause olimex and rk build sort of the same thing
<arokux> AstralixNB: and radxa you mean
<arokux> naobsd: so they transferred the right to you?
<AstralixNB> rperier, I am discussing an EMAC thing and need your verification
<naobsd> hipboi owned
<arokux> naobsd: I do not think so
<AstralixNB> rperier, the EMAC should be able to handle a multi-head PHY, is this right?
<naobsd> olimex own
<naobsd> please see _info_ _org_ part carefully
<arokux> naobsd: ah, ok
<arokux> yes yes, sorry
<AstralixNB> rperier, so I can add a dual-phy to the RGMII of the RK3288 and have later eth0 and eth1 in linux?
<naobsd> generally ethX unit number is assigned to MAC, not phy
<arokux> naobsd: ok, so everything I said applies to *.info
<naobsd> arokux: I see
<AstralixNB> If there are some discrepancies according linux-rockchips.or and .info I can try to act as the counselor ...
<AstralixNB> normally yes, but adding a dual-head phy to an RGMII gives 500MBit/s worst case. Putting second GBE to USB will result in less then 200MBit/s
<AstralixNB> And technically it is possible to handle each head of a phy separately as they have their own buffers.
<arokux> naobsd: and so the wiki was split... and olimex still didn't bring anything to market. radxa being the main dev board which should have produced nice wiki if community were managed properly
<naobsd> I can prepare mediawiki on my server (if someone want)
<AstralixNB> ah, not another entry point
<naobsd> I'll prepare on my server. wiki is only one exception not hosted/managed by me(us)
<naobsd> e.g. we cannot update mediawiki
<naobsd> admin rights on wiki is too weak ;)
<AstralixNB> crewrktablets has a file-server too
<AstralixNB> we have a blog we can add subdomains
<arokux> crewrktablets o_O
<arokux> tons and tons of ROMs and similar things
<AstralixNB> hmm
<rperier> technically if you have two different connection to each phy through your mii_bus, if you register a different structure through "register_netdev" for each device, I would say yes it possible, never tried personnally.... do your EMAC support this use case ? (for irq and etc)
<rperier> did not play with rk3288 yet
<AstralixNB> rperier, I do not know. I do not have any RK3288 devkit till yet. I just know that you ported emac code for RK3188, afaik
<arokux> naobsd: is actually backed up? :)
<AstralixNB> I guess the EMAC itself just gets the normal "Have Data" IRQ from the PHY as usual. But then the EMAC has to select the PHY head that has pending data by MDIO command.
<naobsd> AstralixNB: ah, you asked about RK3288, it uses stmmac, not arc emac
<naobsd> arokux: no idea
<naobsd> (btw currently I don't have idea to leave something related to server/network resources to somebody)
<rperier> AstralixNB: it's really specific to your to the MAC on your board and to the used driver
<rperier> s/to your//
<AstralixNB> actually I am just checking schematics of a new board, featuring RK3288 and I want to make sure that it is a better idea to use a dual-head PHY instead of putting the 2nd GBE behind a slow USB2.0
<naobsd> (when someone said about "revive community", we didn't know who is owner. I had to spend some time to contanct owners. it's result of "leave things to somebody and don't care live or dead")
<hramrach_> dual phy might be interesting driver challenge
<AstralixNB> at crewrktablets we have moe than one admin for this case. So there is always someone around who can help, even the others are offline for a time
<hramrach_> but it may happen that you put it on the board and it never works or it works but your board will be the only to ever have that feature
<naobsd> I understand "I'm only one admin" is not good
<naobsd> ah
<AstralixNB> hramrach_ it is a problem many embedded SOC have. Either you buy a full features networking specialized SOC like Broadcom, Qualcomm or Marvell, but you don't get these in small values.
<naobsd> AstralixNB: please make account public on github linux-rockchip group and join google-ml to support community
<naobsd> I forgot to say it ;)
<arokux> and so a common dev board usually cannot be used as a router!
<AstralixNB> naobsd?
<AstralixNB> waht do you mean?
<hramrach_> I run router with USB Ethernet because upstrean is slow
<AstralixNB> I am public, just skip the NB at the end of my name :)
<naobsd> AstralixNB: I'm reorganizing linux-rockchip things. you are one of owner on github linux-rockchip group
<arokux> hramrach_: usb dongles suck :)
<AstralixNB> I am honoured, tnx
<hramrach_> yes, they do
<naobsd> AstralixNB: please check this page
<hramrach_> but you can connect them to *anything* and turn it into a router
<AstralixNB> hramrach_ having GBE on USB results in <200MBits/s, sharing one MAC over dual-head PHY may resuilt in <500MBit/s
<naobsd> only me, arokux, julien, and karlp is public member
<hramrach_> they do not suck so much with USB3, either
<AstralixNB> but neither RK3188 nor RK3288 have USB 3.0
<hramrach_> but rk in its wisdom decided to not include it
<naobsd> linux-rockchip on github is currently only 4 people group ;)
<AstralixNB> And they do not have PCIe or any other fast interface that can handle 1GBE of data
<arokux> hramrach_: no dev boards under $100 around with usb3 are there any?
<AstralixNB> naobsd, I am Astralix
<hramrach_> don't think so. Exynos boards around $150 (which is btw the price of an rk3288 tv box) and A80 Optimusboard in special sale for arouns $100 (600 rmb on taoboa, presumably)
<AstralixNB> NB is just for IRC as I am using two computers that are often online at the same time
<hramrach_> but although merrii announced price cut from 999 rmb to 599 rmb the price tag on taobao still says 999
<naobsd> AstralixNB: log-out github, then access , there is no "Astralix"
<naobsd> AstralixNB: because currently you're private member
<AstralixNB> ah! ok, I got your point
<AstralixNB> Modified now!
<naobsd> AstralixNB: thank
<naobsd> we are now 5people group :)
<hramrach_> I think at that price it would be quite nice but taobao is China only
<AstralixNB> hramrach_ the point was, if we could make something existing working as a soho router / server / firewall
<AstralixNB> Not to buy something else where you might have to start at the beginning again
<hramrach_> well, the optimusboard would work. iirc it has GBit stmmac and USB3
Soopaman has joined #linux-rockchip
<hramrach_> linux support is .. wip
<arokux> hramrach_: but no mainline kernel, maybe it is not that big deal.. but it nice to have mainline..
<naobsd> AstralixNB: one more thing, are you already join google-ml?!forum/linux-rockchip
<AstralixNB> If I need to have a different thing then I will buy a Marvell board. But I'd prefer to stay on the RK thing, just trying to make the best out of it.
<hramrach_> I tried to stay with AW for a while but I realized that it's nonsense
<hramrach_> If the board/SoC/vendor does not have the features look for another that does
<hramrach_> and yes, marvell would be probably good
<AstralixNB> Yes sure
<naobsd> (ml is still almost dead, but I want to use there to talk dev things like here)
<hramrach_> problem is community hardware for marvell does not exist anymore
<AstralixNB> In that case I am just supporting someone who makes a new board for the open source world. I am not asking for a commercial thing I need in the near future
<karlp> hramrach_: what features were you looking for that made you leave AW?
<hramrach_> and taking apart random NAS boxes to see if you can make them work, and then fins that in 3 months they silently start putting completely different hardware in it
<AstralixNB> naobsd, added myself seconds ago
<arokux> hramrach_: why is sunxi nonsense?
<naobsd> AstralixNB: really thanks
<AstralixNB> naobsd, welcomed
<hramrach_> sunxi community is nice but the hardware sucks
<hramrach_> I am looking for at least half-decent tablet and/or desktop replacement
<hramrach_> and so far none of SoCs cut it
<arokux> hramrach_: so you mean A80 was too late? and no sunxi quad core either?
<hramrach_> yes, a80 is late and has poor support
<AstralixNB> hramrach_ that is why I restart in this community again as well. This over-optimized android rk, mtk and others privide just sucks. So I try to support linux desktop porting to RK3xxx as much as my free time allowes me to
<hramrach_> the quadcores are reportedly useless.
<arokux> actually I cannot understand people who use arm board as desktop. it is way too slow, isn't it?!
<AstralixNB> not really
<hramrach_> I do not own the quadcore hardware but users that do as plain tablet users complain about performance
<naobsd> I don't think RK hardware/support/etc is good, I really like it
<hramrach_> but comparing dulacore a23 to rk3188 you see that there really is a performance problem
<hramrach_> and it's likely not in the number of cores
<naobsd> RK3188 is faster than my old Pen4 single core (HT) machine...
<AstralixNB> cross compiling AVR code of a larger project on notebook ubuntu: 3.6s ... lubuntu-desktop radxa rock: 36s ... notbeook windows 7: 42s
<AstralixNB> Using eclipse on rock needs 2min to start but then it is not much slower than it is on the notbook
<rperier> you can remove "on rock" because eclipse needs 2 min to start on all machines :D
<arokux> hm.. I'd prefer an i5 or i7 workhorse :)
<naobsd> lately I'm writing a code for some mips SoC, I'm testing mips binary on qemu on RR ;)
<AstralixNB> And some slowiness is caused by missing 2D acceleration support and the fact that I am using a single fast SD card as rootfs and home drive
<naobsd> arokux: I prefer too if I have it :)
<hramrach_> yes, i5 and i7 is nice as desktop but not so much for tablet
<arokux> AstralixNB: so your desktop is on an SD card, no SDD/HDD?
<naobsd> I recommend intel box for someone who want perfect(?) desktop
<AstralixNB> arokux: I do develop little devices directly connected to mains. Having a workstation that can be connected ground-free avoids exploding USB hubs and such
<AstralixNB> arokux: yes, only a Sandisk Extreme 45/30MB/s SD Card
<hramrach_> SD is quite good for small things
<hramrach_> you can get fast SD cards
<hramrach_> building a kernel on it may take a while,though
<AstralixNB> RK3188 only supports up to 45MB/s as for faster transfer you need additional things in the host controller. RK3288 should be capable of doing 100+MB/s
<hramrach_> AW can do ~ 10Mb/s
<hramrach_> any card faster than class 10 is basically useless
<AstralixNB> You can try to go 100MB/s if you solder fast DDR eMMC instead this ugly NAND
<hramrach_> yes, presumably CT has a Chinese emmc as the nand
<arokux> AstralixNB: does it come in same packages? :)
<AstralixNB> Hehe, you have to reduce the naumbers on the cards by the marketing factor...
<AstralixNB> I do have a no-name class 10 card and a samsung and some sandisks. There is a true difference in those cards. Regardless if you use them in a notebook or in the rock
<hramrach_> there is no real difference when you use them in a CB
<AstralixNB> SD comes in same package
<AstralixNB> CB?
<hramrach_> cubieboard
FreezingCold has quit [Read error: Connection reset by peer]
FreezingCold has joined #linux-rockchip
<hramrach_> it was nice cheap board and at its price at the time it was good but its time is over
<hramrach_> if you still have use for something that underpowered Olimex has Lime
<arokux> hramrach_: GSM gateway :)
<hramrach_> scanner network interface .. if it has enough ram to hold the scanned image or it can be sent over network in pieces
<arokux> cubieboard is even more powerful that is needed... but i couldn't find anything cheaper
<hramrach_> did not research saned enough
<hramrach_> as for useful SoCs for interactive use I guess it's only exynos now :/
<arokux> hramrach_: me? there is only rpi which is only slightly cheaper. it needs to have some usb ports and ethernet
<hramrach_> A80 has poor graphics
<arokux> hramrach_: rk3288?
<hramrach_> and once tablets with USB3 become common rk3288 has lost
<AstralixNB> I use the rock on a 47" Loewe flat screen at work and it is nice... You can surf and program without glasses :)
<arokux> hramrach_: do you know something cheaper that is not on this list?
<AstralixNB> hramrach_ there will always another thing that makes it better after a while
<hramrach_> you should add Olinuxino Lime
<arokux> hramrach_: true. it is not there.
<hramrach_> it's one of the best low-cost boards available.
<arokux> hramrach_: it is not cheap though - 43 EUR
<arokux> hramrach_: olimex won't show taxes on there website until you pick country
<AstralixNB> however, have to go now. see you all later these days
<arokux> see you
<hramrach_> for Europeans it's cheapest
<hramrach_> for others other boards might be more attractive
<hramrach_> but in general there is the a10 cut down version which is really cheap and the a20 version which is as good as the cheap stuff gets. Both from same vendor, same enclosure (sold from same vendor also)
<arokux> hramrach_: which one do you mean?
<hramrach_> Olinuxino Lime
Soopaman has quit [Ping timeout: 245 seconds]
<arokux> hramrach_: lime is 52 EUR (with shipping), RPi is as cheap as 34 EUR with shipping
<arokux> hramrach_: so 18 EUR difference!
<hramrach_> you can get better shipping deals from a local vendor
Soopaman has joined #linux-rockchip
<hramrach_> which is probably why your Pi turns out so cheap as well
<arokux> rpi is cheap because of amazon
AstralixNB has quit [Ping timeout: 250 seconds]
<hramrach_> ok, shopping for olimex products is not as streamlined as OneClick(tm) but it can be done at reasonable price
<hramrach_> and you get board with useful features unlike RPi
<arokux> hramrach_: oh, Olimex sells on amazaon too
<hramrach_> so there you go. They also sell in a local store in this very city
<arokux> hramrach_: where the company is located?
<hramrach_> Olimex itself is located in Bulgaria or what it's called
<arokux> hramrach_: so A10-OLINUXINO-LIME-4GB is 40 EUR on Amazon vs 34 EUR RPi. it is comparable now.
<hramrach_> I always get those countries down there confused. One has Dracula and the other has Olimex
<arokux> :)
<arokux> I thought you are from one of those
<hramrach_> would be even cheaper shipping I guess :)
<hramrach_> and since you are listing boards up to $200 there would be some arndale kits if they weren't all sold out all the time, some new Odroid XU3 and the merrii A80 optimusboard
<arokux> hramrach_: how about housing, what do you use?
<hramrach_> whatever I can get. some boards are bare since the layout is so insane you cannot build a case around it, most in that sandwich plastic housing, and the awesome Lime in its original Olimex case
<arokux> hramrach_: ... which they do not sell on amazon :(
<hramrach_> nag tsvetan
<hramrach_> or maybe it's even part of the default accessories
<arokux> hramrach_: sorry, they do. 14 EUR
<arokux> :D
cyrozap has joined #linux-rockchip
<arokux> no, it is not
<hramrach_> 14 eur is a bit expensive
<arokux> yes
<hramrach_> I think it was much cheaper when bought directly from them
<arokux> hramrach_: have you tried to print the housing? I have a 3d printer nearby i can use
<hramrach_> Amazon sucks for small stuff I guess
<hramrach_> I considered it but for the saner boards I have at least sandwich housing
<arokux> hramrach_: from them it is 22 EUR :)
<hramrach_> wihout shipping?
<arokux> hramrach_: yes and tax
<hramrach_> :s
<hramrach_> last time I looked it was cheap
<hramrach_> meh
<arokux> hramrach_: the funny thing is lime and lime-4Gb is same price on amazon
<arokux> hramrach_: with millions of rpi sold i'm asking myself if their price is justified...
<hramrach_> they were underselling them to start with but maybe they started to make money on them. You would not say no to that, would you?
<arokux> well.. i'm on consumer side this time, so the cheaper the better... for several years now RPi price wasn't beaten
<arokux> hramrach_: you were right about local resellers. A10-LIME (without NAND) + original housing + tax and shipping = 46 EUR
c0d3z3r0 has quit [Ping timeout: 260 seconds]
c0d3z3r0 has joined #linux-rockchip
FreezingCold has quit [Read error: Connection reset by peer]
<hramrach_> do you have some experience designing cases for 3D printing?
<arokux> hramrach_: no, not at all
<arokux> hramrach_: but there is thiniverse, check this out:
<hramrach_> then you will probably need lots of plastic until you get it right ;-)
<hramrach_> ok, that should do
<arokux> hramrach_: ok, the best bet would be to buy LIME-4GB on amazon and then case elsewhere. LIME-4GB on amazon is same price as without NAND
FreezingCold has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<arokux> hramrach_: ok, just to leave it correct. with NAND it is not the same price. so LIME+BOX+tax+shipping=45.15 EUR.
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
hipboi has quit [Read error: Connection timed out]
<arokux> hramrach_: what is the speed comparison NAND vs microSD?
hipboi has joined #linux-rockchip
ganbold__ has quit [Ping timeout: 255 seconds]
<arokux> hramrach_: I've realized microSD card is needed, so LIME+microSD = LIME + NAND
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
bengal has joined #linux-rockchip
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
FreezingCold has quit [Ping timeout: 255 seconds]
alze has joined #linux-rockchip
<alze> hello
alze has quit []
FreezingCold has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
arokux2 has joined #linux-rockchip
Soopaman has quit [Read error: Connection reset by peer]
Soopaman has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<hramrach_> hello
<hramrach_> arokux: well, regarding nand vs microsd the speed on cb is about the same. could be different if they used different nand in lime but the limitation might be also on the SoC
<hramrach_> nand will wear down and is irreplacable. microsd has unreliable contact so you might have system crashes/failures from the card simple being inaccessible
<hramrach_> fullsize SD might be a bit better in this regard with larger contact surface and better leverage
FreezingCold has quit [Ping timeout: 260 seconds]
FreezingCold has joined #linux-rockchip
<arokux2> hramrach_: I see
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
hipboi has quit [Read error: Connection timed out]
hipboi has joined #linux-rockchip
FreezingCold has quit [Ping timeout: 244 seconds]
FreezingCold has joined #linux-rockchip
Soopaman has quit [Quit: Leaving.]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
gb_master_ has joined #linux-rockchip
nighty-_ has quit [Quit: Disappears in a puff of smoke]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
Dandel has joined #linux-rockchip
<Dandel> i have a factory firmware image for a rockchip rk3188 based tablet, and i was wondering how to unwrap it from the single large file.
gb_master_ has quit [Quit: Leaving]
gb_master_ has joined #linux-rockchip
gb_master_ has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
gb_master_ has quit [Remote host closed the connection]
srao_ has quit [Ping timeout: 260 seconds]
srao_ has joined #linux-rockchip
bengal has quit [Quit: Leaving]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
ganbold_ has joined #linux-rockchip
arokux2 has quit [Remote host closed the connection]
arokux2 has joined #linux-rockchip
arokux2 has quit [Read error: Connection reset by peer]
arokux2 has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip