ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at http://linux-rockchip.info | Logs at http://irclog.whitequark.org/linux-rockchip | ML at http://groups.google.com/group/linux-rockchip
cnxsoft has joined #linux-rockchip
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-rockchip
naobsd has joined #linux-rockchip
naobsd has quit [Read error: Connection reset by peer]
naobsd has joined #linux-rockchip
GriefNorth has joined #linux-rockchip
naobsd has quit [Ping timeout: 252 seconds]
naobsd has joined #linux-rockchip
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-rockchip
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-rockchip
<sjoerd> mmind00: rk3288
<sjoerd> got the thing to load one of the binaries now from the radxa repo over maskrom
<sjoerd> now trying to put on custom u-boot to the emmc which is being specail
markm_ has quit [Ping timeout: 265 seconds]
markm_ has joined #linux-rockchip
markm_ has quit [Ping timeout: 260 seconds]
<naobsd> ah, sorry & thanks for emac issue, I couldn't get free time at all :(
<sjoerd> naobsd: i'm having some oddities with mask rom mode, is there any way i can make it write something on "flash" (which is emmc on this board) at an offset of 32k ?
premoboss has quit [Ping timeout: 265 seconds]
<naobsd> sjoerd: RK tools such as upgrade_tool/AndroidTool.exe can do it
dlezcano has quit [Read error: Connection timed out]
<naobsd> sjoerd: but you need to prepare RKLoader.bin form binary for such tools
<naobsd> or if you can run Linux on target board, you can write data to emmc via Linux environment
dlezcano has joined #linux-rockchip
<sjoerd> Right, i'm just looking at a way to put a proper u-boot on a board without jumping through hoops
<naobsd> btw upstream u-boot supports writting data to (e)mmc?
<sjoerd> naobsd: i've gone to maskrom mode and loaded rk32xxminiloaderall.bin but that doesn't seem to do the trick
<naobsd> fastboot on u-boot may be helpful if it works
<naobsd> well
<sjoerd> naobsd: upstream u-boot also has some other flashing capabilities
<naobsd> download miniloader.bin from mask rom mode, then flash your_own_loader.bin
<naobsd> is not working?
<sjoerd> doesn't seem so
<sjoerd> I did some tricks to put some known data on the eMMC at the offset i care about (iotw 32k where i want to put the SPL) but rkflashtool r doesn't seem to be able to read that
<naobsd> well
<naobsd> rkflashtool doesn't support loader area
<naobsd> I said use RK tools such as upgrade_tool for flashing loader
<sjoerd> Right that wasn't entirely clear to me
<sjoerd> ooi do you know what would be needed to flash to loader area ?
<naobsd> rkflashtool can do "download loader code to SRAM/DRAM" but cannot do "flash it to NAND/eMMC/etc"
<naobsd> well
<sjoerd> rkflashtool w doesn't put stuff on flash ?
<naobsd> "rkflashtool w" can flash images to logical area/partition
<naobsd> loader is not in logical area/partition
<naobsd> loader flashing protocol should be almost known, but it needs ECC calculation.
<sjoerd> right but w <offset> <size> is a bit more flexible it seems
<naobsd> in addition to dada part, oob part need to be sent
<naobsd> well
<sjoerd> I see
<naobsd> no
premoboss has joined #linux-rockchip
<naobsd> [ loader area | logical partitions ]
<naobsd> "rkflashtool w" is for logical area
<naobsd> on eMMC, loader area is 0-2047th sector, logical area is 2048-th sector
<sjoerd> Right
<naobsd> rkflashtool r|w 0 read/write sector 2048th on eMMC
<sjoerd> I see
<naobsd> rkflashtool r|w doesn't support loader area clearly
<sjoerd> interestingly it looks like rkflashtool i does get my bits
<naobsd> USB protocol is different
<naobsd> "rkflashtool i" is for loader area
<naobsd> ah sorry, loader area should be started from 64- sector on eMMC
<naobsd> loader area a.k.a. IDB
<naobsd> for writing loader, we need ecc code
<naobsd> probably.
<naobsd> (for eMMC it may not be required)
<sjoerd> Looking at what rkflashtool i retrieves the ecc on eMMC is just all 0xff
<naobsd> I guess, for eMMC, ecc things should be done in chip
<sjoerd> yeah
<sjoerd> I'll havea go at implement rkflashtool j
<naobsd> then we can send random oob data
<sjoerd> for emmc iotw just fill the ecc chunk with 0xff
<sjoerd> ack
<philhug> just a quick question: rkflashtool is still the most commonly used tool right? I just packaged it for Debian and would upload it soonish..
<philhug> e.g. there is also rkflashkit
<naobsd> philhug: unfortunately there are several rkflashtool forks but I hope ours are best ;) https://github.com/linux-rockchip/rkflashtool
<naobsd> I have no idea about rkflashkit
<philhug> yes, that's the one I took :)
<sjoerd> philhug: \o/
<sjoerd> philhug: Looking forward to having that in debian ;)
<sjoerd> philhug: are you loking at also enabling u-boot/kernel in debian (it's somewhere on my backlog but...)
<philhug> sure, I can do that as soon as everything needed is upstream.
<sjoerd> should be for rk3288
<sjoerd> what boards are you interested in ?
<naobsd> (rkflashtool needs some refactoring, but I have no time...)
<naobsd> (now trying my terrible node.js based RK compatible OTA server...)
<naobsd> I hope it's better than tomcat-based RK original OTA server ;)
<naobsd> RK OTA download client must be XXXX
<philhug> sjoerd: I'm insterested in rk3288/chromebook
<naobsd> oh, chromebook loader shouldn't support rock usb protocol...
<naobsd> well
<philhug> and I have an old tv stick with rk3066
<philhug> which is why I packaged it quickly
<naobsd> rkflashtool should work _on_ rk3288/chromebook too ;)
<philhug> naobsd: really?
<naobsd> ah sorry
<naobsd> linux on chromebook
<naobsd> libusb is required, I'm not sure chromeos has it
<philhug> ah you mean on chromeos?
<naobsd> it should work on linux on chromebook, it may work on chromeos on chromebook
<naobsd> I don't have any chromebook
<naobsd> permission might not be given
<naobsd> anyway rkflashtool should be portable
<naobsd> it should work on Android too ;)
<philhug> yes, it seems very easy to port. but I only need it on Linux atm :)
<mmind00> naobsd philhug: the regular protocol spoken by rkflashtool (aka r and w options) is specific to the rockchip uboot ... I don't think coreboot (used on Chromebooks) speaks that protocol
<naobsd> it will not be implemented to upstream u-boot too... at least I have no interest...
<sjoerd> the protocol is too vendor specific to make sense for upstream
<naobsd> but I will maintain rkflashtool as much as possible :)
<philhug> yes sure it depends on the proprietary loader
<sjoerd> Upstream would use either fastboot or dfu which is more sensible there :)
<philhug> it could make sense though to have a tool that speaks the mask rom protocol.
<sjoerd> that's what rkflashtool does ;)
<sjoerd> philhug: i'm current using maskrom mode via rkflashtool... I'm pretty sure
<philhug> rkflashtool can only flash within rock/bootloader mode...
<naobsd> no, rkflashtool l/L are for mask rom mode
<naobsd> I added it ;)
<philhug> ah ok :)
<sjoerd> philhug: don't assume the radxa site is fully up to date :)
<naobsd> and sorry for not updating wikis
<philhug> #802463
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
<naobsd> thanks... probably I have to care version number more
<naobsd> personally I think everything is w.i.p. ;)
<sjoerd> naobsd: \o/ \o/
<sjoerd> Just flashed upstrema u-boot onto the eMMC using maskrom mode ;)
<philhug> yeah it would be nice to have a *released* tarball
<sjoerd> naobsd: the ecc stuff for emmc is just ignored it seems (either that or it is happy with 0xff)
fireglow has joined #linux-rockchip
<naobsd> sjoerd: do you know protocol to write loader(IDB) area? I should have USB snoop log on somewhere on my machine...
<naobsd> or you can see receiver side implementation in RK u-boot
<sjoerd> naobsd: it's the same as the normal one, yuou just write 512 bytes + ecc chunks rather then 512
bludot has quit [Quit: Connection closed for inactivity]
<sjoerd> naobsd: I just got it working, will send you a patch to make rkflashtool j do the thing
<sjoerd> will probably not work for nand though unless you know the ecc algorithm used on it
<naobsd> very nice :) thanks
<sjoerd> naobsd: thank you for your help :)
<sjoerd> ofcourse next step would be to be able to load upstream u-boot via l/L but yeah
<naobsd> proper erase command should be implemented in future
<naobsd> current one is just writing 0x00 for logical area
<naobsd> when RK u-boot source was not available, I have a lot of motivations to implement rockusb protocol, but ... ;)
<naobsd> well, return to home
<naobsd> later
naobsd has quit [Quit: naobsd]
<philhug> what do you think would be the best option to support Debian on the arm chromebooks?
<philhug> chainload u-boot, which then loads kernel/initrd
ssvb has quit [Ping timeout: 240 seconds]
<philhug> or package debian kernel as chromebook kernel image
<sjoerd> It depends
<sjoerd> Personally i feel that the former would be better but that will need some extra u-boot fun
dlezcano has quit [Read error: Connection timed out]
dlezcano has joined #linux-rockchip
<philhug> sjoerd: well that's the way the allwinner images work on debian, so if u-boot can access the block devices we're good.
naobsd has joined #linux-rockchip
<naobsd> I forgot to say one thing... just my guessing... there is very small possibility, writing loader w/o ecc calc may work with NAND too
<naobsd> it's just my guessing, it might be required when RK SoC was very poor (pre-android devices) and everything needed to be done on PC side...
<naobsd> current RK proprietary loaders should know everything about NAND, there is no reason to give oob/ecc data from PC
<naobsd> only protocol need to be compatible
<naobsd> so it's worth to try sjoerd's new code with NAND
naobsd has quit [Quit: naobsd]
naobsd has joined #linux-rockchip
<naobsd> I should check RK u-boot implementation... oops, my todo list is too loooooooong...
naobsd has quit [Client Quit]
<philhug> rkflashtool is in NEW now: https://ftp-master.debian.org/new.html
<philhug> just a matter of days, weeks, months :)
markm has joined #linux-rockchip
<mmind00> philhug: I guess bootloader is a matter of taste ... so far I didn't find coreboot lacking anything ... including dualbooting either chromeos from emmc or debian from sd-card
<sjoerd> does an initramfs work now in the fit images ?
<mmind00> hmm, ok that might be one issue, when trying to boot a real generic kernel
<sjoerd> I like the u-boot approach as that makes the distro integration a bit simpler and more generic
<sjoerd> though i'm slightly biased :)
<philhug> just wanted to ask the same. I need dtb appended and initrd support
<sjoerd> the coreboot/verified boot stuff from chromeos is quite cool
<philhug> s/initrd/initramfs
<mmind00> philhug: coreboot/fit does have a separate section for the dtb(s) ... one fit image can boot multiple different machines
<sjoerd> nod
<sjoerd> and the fit image can in principle include the initrd as well
<sjoerd> but i had issues with that on some samsung chromebooks way back
<mmind00> when Kevin was integrating his Chromebook into the board-farm, the initramfs question also came up
<philhug> mmind00: well, the Debian kernels use appended dtb's, so I don't have a choice there.
<philhug> I'm more worried about initramfs
<sjoerd> philhug: debian kernels don't use appended dtbs...
<philhug> sjoerd: the armmp does
<sjoerd> that only means that it's supoprted though
<philhug> sjoerd: I'll try. but do you have an idea about initramfs?
<sjoerd> you'd have to try, the samsung chromebooks didn't even use coreboot (their flash has u-boot) so it's likely it would work for corebook just fine
premoboss has quit [Ping timeout: 272 seconds]
ssvb has joined #linux-rockchip
<rperier> hi all
bludot has joined #linux-rockchip
premoboss has joined #linux-rockchip
dlezcano has quit [Read error: Connection timed out]
cnxsoft has quit [Quit: cnxsoft]
cristian_c has joined #linux-rockchip
naobsd has joined #linux-rockchip
GriefNorth has quit [Ping timeout: 260 seconds]
<ganbold> naobsd: ping
<naobsd> ganbold: hi
<ganbold> naobsd: hi
<ganbold> naobsd: trying to flash kernel to RR board
<ganbold> rkflashtool: info: Error: Partition 'kernel' not found.
<ganbold> strange
<ganbold> parameters has
<ganbold> CMDLINE:console=ttyFIQ0,115200 console=tty0 root=/dev/block/mtd/by-name/linuxroot rw rootfstype=ext4 init=/sbin/init mac_addr=de:ad:de:ad:be:ef initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:0x00008000@0x00002000(boot),-@0x0000A000(linuxroot)
<naobsd> no kernel partition in it
<ganbold> looks like it so
<ganbold> which one to flash
<ganbold> boot ?
<naobsd> using boot is one of the solution. you need to make boot.img with mkbootimg.
<naobsd> or you can add kernel partition
<ganbold> ok, how to add it
<naobsd> mtdparts=... is the partition definition
<naobsd> size@offset(name)
<naobsd> well
<naobsd> if you don't need linuxroot, just rename it to kernel ;)
<ganbold> ok, so change parameters and flash back?
<naobsd> yes
<naobsd> rkflashtool p > parameter; vi parameter; rkflashtool P < parameter
<ganbold> let me try
<ganbold> now it becomes like this
<ganbold> CMDLINE:console=ttyFIQ0,115200 console=tty0 root=/dev/block/mtd/by-name/kernel rw rootfstype=ext4 init=/sbin/init mac_addr=de:ad:de:ad:be:ef initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:0x00008000@0x00002000(boot),-@0x0000A000(kernel)
<ganbold> root@beastie:/home/tsgan/rkutils/rkflashtool # ./rkflashtool w kernel < ../kernel.img
<ganbold> rkflashtool: info: rkflashtool v5.2
<ganbold> rkflashtool: info: Detected RK3188...
<ganbold> rkflashtool: info: interface claimed
<ganbold> rkflashtool: info: working with partition: kernel
<ganbold> rkflashtool: info: found offset: 0x0000a000
<ganbold> rkflashtool: info: partition extends up to the end of NAND (size: 0x00846000).
<ganbold> rkflashtool: info: writing flash memory at offset 0x0000cbc0... Done!
<ganbold> rkflashtool: info: premature end-of-file reached.
<philhug> sjoerd: is this the way to go for initramfs? http://www.coreboot.org/Initramfs
<philhug> ah nope, thre seems to be initramfs support in fit
<ganbold> naobsd: flashed android and then changed parameter and flashed kernel. Even after flashing kernel it still boots to android
<sjoerd> philhug: You should put it in the fit image indeed
<sjoerd> philhug: chromeos has a coreboot payload (called depthcharge) that does their verified boot stuff
<philhug> found the source. unfortunately, 16MB is too small
<ganbold> naobsd: ok, got it working :)
dlezcano has joined #linux-rockchip
<philhug> sjoerd: initrd+kernel ends up being around 20MB, depthcharge didn't like my resized KERN-A partition
<sjoerd> Guess u-boot it is
<sjoerd> but that'll need some work for sure
<philhug> or do you have an idea why it should have a problem with a larger partition? hardcoded sizes?
<sjoerd> philhug: check if the flags and the gpt id are still correct
dlezcano has quit [Read error: Connection timed out]
<philhug> sjoerd: now I need to upgrade depthcharge. factory version doesn't have ramdisk support.
<sjoerd> philhug: Thats one of the reasons my personal preferncde would be u-boot support, then you don't have the change depthcharge and all that
<sjoerd> (he says with no time available to help out thre)
<philhug> I think ramdisk support is in the official image, but as I replaced the signing keys it reverted to readonly version
<philhug> np, will find a way..
VargaD has quit [Ping timeout: 268 seconds]
VargaD has joined #linux-rockchip
GriefNorth has joined #linux-rockchip
ssvb has quit [Ping timeout: 240 seconds]
dlezcano has joined #linux-rockchip
ssvb has joined #linux-rockchip
dlezcano has quit [Read error: Connection timed out]
dlezcano has joined #linux-rockchip
akaizen has quit [Remote host closed the connection]
Sadneophyte has joined #linux-rockchip
<c0d3z3r0> mmin00: rk3188 is still crashing with your patch http://pastebin.com/jPgM85nn :(
ssvb has quit [Ping timeout: 246 seconds]
<c0d3z3r0> i should write names correct…
<c0d3z3r0> mmind00: rk3188 is still crashing with your patch http://pastebin.com/jPgM85nn 
Sadneophyte has quit [Ping timeout: 265 seconds]
<cristian_c> lol
ssvb has joined #linux-rockchip
<mmind00> c0d3z3r0: I would've thought so, as it was only something I identified as potential problem by looking at the code :-) ... my change probably doesn't solve it wholly
<c0d3z3r0> mmind00: ok, thank you anyway :)
dlezcano has quit [Read error: Connection timed out]
GriefNorth has quit [Ping timeout: 272 seconds]
dlezcano has joined #linux-rockchip
mrueg has quit [Remote host closed the connection]
mrueg has joined #linux-rockchip
Sadneophyte has joined #linux-rockchip
johnnyr has joined #linux-rockchip
dlezcano has quit [Ping timeout: 252 seconds]
Sadneophyte has quit [Read error: Connection reset by peer]
bludot has quit [Quit: Connection closed for inactivity]
cristian_c has quit [Quit: Bye]
bludot has joined #linux-rockchip
Sadneophyte has joined #linux-rockchip
akaizen has joined #linux-rockchip
Sadneophyte has quit [Read error: Connection reset by peer]
naobsd has quit [Remote host closed the connection]
akaizen has quit [Remote host closed the connection]
Sadneophyte has joined #linux-rockchip