ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | http://irclog.whitequark.org/linux-rockchip
leowt has quit [Quit: leowt]
Astralix has joined #linux-rockchip
Astralix|afk has quit [Ping timeout: 248 seconds]
<Astralix> ping
<naobsd> hi
mmind00 has joined #linux-rockchip
<Astralix> hi all
<Astralix> looks like west is waking up+
<Astralix> Does anyon of you know how to pack a bootimg?
<naobsd> rkcrc for ramdisk only boot.img and mkbootimg for kernel+ramdisk boot.img (same for recovery.img)
<Astralix> I need to have a bootimg without kernel and my mkbootimg fails on not having kernel
<naobsd> you can use both type regardless of the type used in stock rom
<mmind00> for the android type you could also use abootimg which is in most linux distributions
<Astralix> ??
<Astralix> I'll go for android
<Astralix> so just need an boot.img without kernel as RK Bootloader prefers boot.img kernel before kernel.img
<mmind00> hmm, no then :-)
<mmind00> the android boot img is used for the recovery stuff
<naobsd> is there abootimg which supports rockchip's id generation?
<Astralix> don't know
<Astralix> I am normally only doing kernel
<mmind00> no, abootimg is only for the android type images
<naobsd> I'm speaking android type image
<Astralix> ok, the kernel supports make boot.img
<naobsd> mkbootimg for rockchip is bit different than standard one
<Astralix> but requires to be linked inside android build system
<naobsd> mkbootimg is a part of android build system
<Astralix> yes, but it forces to have kernel inside. That is pretty painful if you recompile kernel every minute and have to pack bootimg all the time
<Astralix> And I do not have sources for this android that I use
<naobsd> if you modify kernel so often, but not ramdisk, then ramdisk only boot.img is better
<Astralix> I dismounted update.img and separated images
<Astralix> Yea, aou got it
<Astralix> you got it
<Astralix> I like to have a simple ramdisk only bootimage for RK31xx
<naobsd> what's "android build system"? script for unpack & repack update.img
<naobsd> ?
<Astralix> ?
<naobsd> ah
<naobsd> you think you need "android build system" to use mkbootimg, right?
<Astralix> nope
<naobsd> sorry, I couldn't understand "but requires to be linked inside android build system"
<Astralix> I think I need android build system to use the kernels Makefile option "make boot.img"
<Astralix> Modern Android likes to have the kernel inside
<Astralix> kernel is build and put into required images with "make lunch"
<Astralix> Before Android 4.2.x the kernel could stay outside.
<naobsd> mkbootimg just requires binary(compiled) kernel and ramdisk binary, you can use mkbootimg out of build system. no need to recompile everything
<Astralix> Yes I know
<Astralix> but mkbootimg insists on having kernel
<naobsd> yes
<naobsd> and not good for your work, I see.
<Astralix> I don't want to, as the rockchip bootloader then boots this kernel
<Astralix> so I'd prefer the old way ramdisk -> boot.img, kernel -> kernel.img
<Astralix> So could it be, that you just cpio the ramdisk and put rkcrc around it to have boot.img?
<naobsd> anyway, please use rkcrc in rkutils
<Astralix> sure
<Astralix> I have all these tools and I even have android build system.
<Astralix> But for kernel tests I need to have an Android that I know of it is working.
<Astralix> Bad idea to test something in an untested surrounding. So I use original manufacturers android and just exchange the kernel
<naobsd> rkcrc -k cpio+gz(format depend on kernel config) boot.img
<naobsd> should work
<naobsd> you can try rkunpack stock-boot.img, rkcrc -k stock-boot.img.raw new-boot.img
<naobsd> stock-boot.img and new-boot.img must be 100% same
<naobsd> I want more spare time to update rkutils...
<Astralix> ehat is the input of rkcrc?
<Astralix> I have ramdisk.gz
<naobsd> (but probably no one want decrpy function for rk2918 cramfs system.img anymore lol)
<naobsd> normal cpio+gz for input
<naobsd> 8 bytes header(KRNL + payload size) + payload + 4 bytes crc
<naobsd> for kernel.img, payload is zImage
<Astralix> yes, I miss the cpio part
<Astralix> the rkcrc I understood
<Astralix> ok, think I got it
<Astralix> just testing
<Astralix> then you could add this to your tools wiki
<naobsd> good documentation is missing for very long time.. ;)
<naobsd> I can't count how many times I told how to use :)
<naobsd> basically format/protocol is not changed from rk2808 :)
<Astralix> no, that was not the problem. I know all these tools, but all of them are only a half of the solution. And they all miss documentation
<Astralix> I was missing the first link, coming from ramdisk/ directory to cpio+gz
<Astralix> But actually no luck:
<Astralix> Boot ver: 2013-05-18#1.20
<Astralix> Begin recover...
<Astralix> GetRemapTbl flag = 1
<Astralix> Load failed!
<Astralix> E:CRC failed!
<Astralix> start_linux=====54563
<Astralix> UsbBoot,3641728
<Astralix> UsbHook,4294635
<Astralix> powerOn,4294659
<Astralix> 4444134 UsbConnected
<Astralix> 4524492 UsbConnected
<naobsd> hmm
<Astralix> Ah, boot.img has wrong header!
<Astralix> It's showing KRNL
<Astralix> without kernel, the bootimg must show ANDROID
<naobsd> no
<Astralix> yes
<naobsd> ANDROID! is for kernel+ramdisk image by mkbootimg
<Astralix> I can check...
<naobsd> sorry, away for a while
<Astralix> ok, you're right
<naobsd> back
<naobsd> Astralix: booted now?
<Astralix> kernel.img is too large
<Astralix> was the reason for the CRC error
<naobsd> I see
<Astralix> unfortunately I cannot use my specialized toolchains on rockchip
<Astralix> works only on single-cores
<naobsd> what is specialized toolchains?
<Astralix> I have some gcc optimized for cortexA series including NEON/SIMD and such
<Astralix> Includes gold linker
<naobsd> probably I only tried same gcc version used for stock kernel... gcc 4.4.3
<naobsd> gcc 4.4.3 from aosp android prebuilt
<Astralix> I tested almost all of them from 4.5.x to 4.9.x
<Astralix> only 4.4.3 to 4.6.2 work on rockchip
<naobsd> I'm not sure NEON can be used in kernel space
<Astralix> ok, all work on 2918 but as soon as you get multicore, only the old ones work
<naobsd> you may try newer gcc for userland :)
<Astralix> I have arounf 20 different gcc installed and made a script that selects them
<Astralix> so depending on what project I work, I can quickly select
<Astralix> I will test, what fails on newer gcc and SMP support on RockChips , the I will post a fix to the gcc guys or to you for mainline RK support
<Astralix> But using specialized toolchains on kernel gives some % size improvement and lots of speed improvement
<naobsd> http://lists.linaro.org/pipermail/linaro-kernel/2013-May/004359.html I guess NEON in kernel is not supported yet
<naobsd> probably newer gcc generates more optimized non-NEON code
<Astralix> The problem will be, that rockchips code is not compatible to the combination of VFP and SMP.
<Astralix> If you check broadcom chips, it works pretty fine and fast with gcc 4.9.x
<Astralix> but rockchip compiled with the same toolchain crashes right in the first seconds
<naobsd> sometimes source code need to be modified to use newer gcc
<Astralix> yes
<Astralix> I know
<naobsd> probably you can use newer toolchain with linux-next kernel which has rockchip support in future :)
<Astralix> If we could do that, I will be happy to support if I can
<naobsd> I'm not linux guy but probably mainlining effort will be hard...
<Astralix> yes, the code, as it is today, will be rejected in every singe line
<mmind00> correct :-)
<mmind00> and it will be a long time until you get to see anything on a display
<naobsd> I like serial console!
<mmind00> currently it can boot a debian off the sd card just fine, but you of course only get serial output
<Astralix> hmm... nope
<naobsd> very nice ;)
<naobsd> I forgot to ask, USB is also DW?
<Astralix> we have picuntu running with graphics
<mmind00> Astralix: the mainline code
<Astralix> ah, yes
<mmind00> naobsd: the otg is a synopsis dwc2 (drivers/staging/dwc2)
<mmind00> from what I've seen it is currently limited to host support
<Astralix> For the synopsis there is chaos in the mainline kernel
<naobsd> hehe
<mmind00> the s3c-hsotg does implement the gadget part of a dwc2 and should be incorporated into the real dwc2 at some point, as I've read
<Astralix> there are about 7 different drivers on different SOCs that are all synopsis
<Astralix> take the implementation from pengutronix, from their i.MX support.
<Astralix> I guess they started to mainline their implementation and try to replace all the others.
<mmind00> nope ... i.e. the real dwc2 driver is the way to go, the usb guys won't accept a driver reimplementing the same functionality
<Astralix> But I can ask Robert on that topic
<mmind00> interestingly it's even a synopsis guys that is working on the dwc2 driver
<Astralix> who's the maintainer of the dwc2?
<mmind00> a Paul Zimmerman ... with a synopsys.com mail address
<Astralix> ok, then this crappy Ip might get enough software workarounds to work some day
<mmind00> :-)
<naobsd> Astralix: https://github.com/crewrktablets/rkflashtools/commits/master both "Astralix" and "Ulrich Prinz" are you?
<Astralix> yes
<naobsd> oh, I see :)
<naobsd> then you snooped rockchip USB protocol, right?
<Astralix> I work with heavy wheapons
<Astralix> I know how to use usb sniffers as well as IDA pro advanced
<naobsd> well, do you have hardware analyzer?
<naobsd> wow, very nice :)
<Astralix> nope, not needed if you use Unix as host and Windows as guest
<naobsd> it was f***in thing when I snooped with tools for windows
<naobsd> yes I know
<Astralix> But i do sometimes not release information, as I have some contacts in RK that sometimes anwer my emails.
<naobsd> it's useful todays PC spec
<naobsd> oops
<Astralix> And I didn't want to offend them too much, before giving them a chance to answer my emails
<naobsd> I'm weak, but I have no relation to RK, so I'm free :)
<naobsd> I can understand it
<Astralix> They learned that they have two chances to answer, otherwize I put my resuilts online
<naobsd> my question is, is there any problem to add "push image to ram, then boot it" function to rkflashtool
<Astralix> Nex to come is a fully disassembled bootloader
<Astralix> I have both of them on my drive. The mask rom loader from the 3066 and the bootloader from NAND
<naobsd> I can't find answer to extra 2 bytes to flash bootloader via USB yet
<naobsd> I wonder why you didn't know how to make ramdisk-only boot.img :)
<Astralix> what I would like to see first is, how to format flash so defects are blacklisted and how to check flash how worn out it already is
<Astralix> You know, the boot image things are file systems and OMA, Jochen and Lars took care of it
<Astralix> Therefore I can probe out your touchscreen chip and it's I2C protoocol
<Astralix> If you have family and work you only have 3 to 4 nights of a week to work on that
<naobsd> I didn't know inside in your team
<Astralix> so I totally conectrate on kernel and lowlevel interfaces and MALI nad toolchain
<naobsd> I have a family and sometimes I only have less than 1 night of a month ;)
<Astralix> if I need a filesystem, image, android or so, I just request it and the guys look for it
<Astralix> if you have to do it all youself you'll make no step forward.
<naobsd> I was almost alone so my progress was terribly slow!
<Astralix> I started that way
<Astralix> fortunately that time there was only kernel.img carrying a kernel. So just flashing that one was enough
<naobsd> Astralix: is it possible to add "load kernel.img to RAM, run it" function to rkflashtool?
<naobsd> I think RKAndroidTool has that function
<Astralix> yes, should be possible
<Astralix> ah...
<naobsd> it should be useful for kernel development
<Astralix> yes
<Astralix> guess so
<Astralix> like loading it from nfs/tftp
<naobsd> but currently I don't have enough time to snooping/writing code ;)
<Astralix> put a todo into my rkflashtool github
<naobsd> away for a while...
<naobsd> oh
<Astralix> ?
<naobsd> at that time I didn't think linux developer has interest to this kind of crap ;)
<Astralix> lol
<naobsd> my original rkflash(still in my rkutils repo) was written for *BSD
<naobsd> so no one can't use it until rkflashtool is available
leowt has joined #linux-rockchip
<leowt> hello!
<naobsd> now I can see nice developers, it must be happy :)
<naobsd> RK3066/RK3188 is not crap, it's nice too :)
<Astralix> the chips aren't crap, the code is
<naobsd> and final product made by small factory in china ;)
<mmind00> :-)
<leowt> naobsd: assembled
<leowt> =P
<Astralix> this isn't real crap... it is sometimes so and sometimes so...
<leowt> the thing is is that is no integration in those kinds of chinese products
<naobsd> assembled
<leowt> the "SoC vendor --> pcba" flow is very strange to us westerners
<leowt> i mean, those kinds of crappy chinese products you talk about
<leowt> nothing is developed by the same company
<naobsd> I think factory guys must have better soldering skill than me
<leowt> thats why you end up with a: fragile and crappy chassis, bad solder hw, hw bugs, no attention to sw
<naobsd> (but sometimes I can see terrible soldered connectors in crap)
<leowt> the thing is that the flow is like this:
<leowt> Soc Vendor - PCBA - Assembler - distributor
<leowt> so, where is the development company?
<leowt> nonexistent
<leowt> =P
<naobsd> I like stick style device, it has less crapinness
<naobsd> fewer parts, fewer faults ;)
<leowt> some rk scondary developers are PCBA, just because they want to get their hands on the newer chips asap so they can develop mid, and tv stick boards so they can sell to all (startup, home, small) factories
<leowt> so there is no produt thinkering here
<leowt> just sticking boards in chassis and boxes and shipping
<leowt> thats why you end up with such a crappy product
<leowt> and thats why rk doesnt care about us
<leowt> they sell much more that way
<leowt> but the real thing here
<leowt> is the price comparing to freescale, texas, etc
<leowt> for example 15 to 35 difference for a a9 quadcore
<leowt> thats why i believe that it is worth doing what is supposed to be the rk job, i mean, maintaning the lower stuff
<leowt> so 20$ difference, if i had a company, i would use allwinner/rockchip and for example contract all you guys for a dream job and still have a cheapier product with quality
<leowt> haha
<naobsd> I heard rockchip is going to be (relatively) open
<leowt> that is myth
<leowt> xD
<leowt> is from a video
<leowt> of charbax interviewing the CEO i think
<leowt> just a sec
<naobsd> https://github.com/HermanChen/ he should be rockchip guy
<naobsd> he already gives some amount of help to XBMC community
<naobsd> of course "everything" is not open yet, but
<leowt> i will be happy with kernel sources
<leowt> xD
<leowt> for my rk8168
<leowt> *would
<leowt> 19:20
<Astralix> herman is rockchip, yes
<Astralix> he supports as much as he is allowed
<leowt> in the video the guy says they have around 300 android engineers
<leowt> lol
<Astralix> no wonder that they produce only crap
<Astralix> far too many people on that project
<leowt> that must have been a misunderstanding
<leowt> aww if google had 300 android devs full time...
<leowt> xD
<leowt> well, going out for a bike ride
<leowt> cya
mmind00 has quit [Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/]
<naobsd> my weekend is end
<naobsd> I may not join here in weekdays
<naobsd> well
<naobsd> I can not join discussion here in weekdays because of timezone
<naobsd> probably.
leowt_ has joined #linux-rockchip
leowt_ has quit [Client Quit]
leowt has quit [Ping timeout: 276 seconds]
mmind00 has joined #linux-rockchip
<Astralix> someone in here still?
mmind00 has quit [Read error: No route to host]
mmind00 has joined #linux-rockchip
mmind00 has quit [Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/]