<naobsd>
well, if you want to know _only_ about how to change size of partition, I already explained (try 0x10000 (32MiB) for boot partition), now I'm talking about different topic
<naobsd>
then
wadim_ has joined #linux-rockchip
<naobsd>
dowu: if you want to prepare _Ubuntu_ kernel image, I think it's better to use ramdisk from Ubuntu
<naobsd>
anyway, now I understood what you are using
<dowu>
naobsd: The year 2002, I built an embedded system with Intel CPU board. and I built the ramdisk file with my proper decision.
<dowu>
But with ARM, I am still a novice...
<naobsd>
dowu: I just said you may be able to use another ramdisk
<naobsd>
dowu: you want to prepare kernel image compiled from Ubuntu kernel package, right?
<dowu>
naobsd: Also I would be graceful if you let me know how to build the proper ramdisk file.
<naobsd>
"12:14dowuI have worked on rk3188 to port latest Ubuntu linux kernel for 3 months."
<naobsd>
dowu: "proper" need to be defined... _on Ubuntu_, "mkinitramfs" is the proper tool
<naobsd>
kernel on www.kernel.org is vanilla kernel, not _Ubuntu_ kernel
<naobsd>
why do you use 4.6.4? stable is 4.7.x, and there is 4.8-rcX too
<dowu>
I see. then I will try again with Ubuntu...
<dowu>
I did not have any meaning on the kernel version. But I need new device drivers. that's why I preferred new kernel version...
<naobsd>
I'm not sure you should try Ubuntu kernel
<naobsd>
you may use latest kernel source from kernel.org
<naobsd>
well
<dowu>
naobsd: You made me clear on this. I will try with your advices and latest Ubuntu package
<naobsd>
dowu: which RK3188 board are you using? Radxa Rock?
<dowu>
With Radxa routines, I ported the embedded system with old linux kernel which do not have proper device drivers to me.
<dowu>
So I am trying with a new version of Linux.
<naobsd>
I see
<naobsd>
I think it's good to use kernel from kernel.org
<dowu>
Than you a lot for your greates info.
<naobsd>
well
<dowu>
Thank you... typo.
<naobsd>
you should change size of boot partition
<dowu>
Yes I will.
<stdint>
sadness, the new u-boot for RK3188 is not ready
<naobsd>
15:18naobsdyou can change 0x00008000@0x00002000(boot) to (e.g.) 0x00010000@0x00002000(boot) 15:18naobsdthen you have to change linuxroot from -@0x0000A000(linuxroot) to -@0x00012000(linuxroot)
<naobsd>
oops
<dowu>
Yepp.
<naobsd>
if u-boot mainline for RK3188 is available, boot sequence/configuration will be changed completely
<naobsd>
dowu: you should be able to use SD card or USB storage on mainline Linux
<naobsd>
dowu: or eMMC if your board has eMMC
<naobsd>
dowu: do you know you can put bootloader etc on SD card instead of NAND?
<dowu>
eMMC then I will choose.
<dowu>
I have routines "flashing on SDCARD" br br br...
<naobsd>
well
<naobsd>
dowu: does your board have eMMC?
<dowu>
I am not pretty sure but I think so.
<naobsd>
dowu: if your board have eMMC, you can use it from mainline Linux. but mainline Linux doesn't understand Rockchip partitioning scheme(mtdparts= in CMDLINE)
<naobsd>
dowu: can you hear about detail of your board?
<dowu>
Then I understand why I could not boot when I ported with 4.6.4 modulaized yesterday.
<dowu>
I will show our talk to my hardware engineer
<naobsd>
oops
<naobsd>
s/can you hear/can I hear/
<naobsd>
anyway, I see ;)
<dowu>
Anyway, I think you in USA right?
<naobsd>
no I'm in Japan
<dowu>
Oh. I am in Korea.
<dowu>
same time line.
<naobsd>
:)
<naobsd>
RK3188 supports boot from eMMC, SD card (in addition to NAND)
<naobsd>
mainline Linux for RK3188 supports eMMC, SD, but doesn't support NAND
<dowu>
With Intel cpu board, embedding was very routine following way. but with RK3188 I am still hanging ....
dlezcano has quit [Remote host closed the connection]
dlezcano has joined #linux-rockchip
<dowu>
Anyway I will chang the boot size and even u-boot.... sad....
<naobsd>
well, mainline u-boot doesn't use Rockchip scheme
<naobsd>
such as "parameter"
<naobsd>
any tools such as rkflashtool etc(it's for Rockchip proprietary protocol) cannot be used with mainline u-boot
dlezcano has quit [Remote host closed the connection]
<naobsd>
newer Rockchip SoCs support only mainline u-boot/linux, I think everything for RK proprietary protocol will be obsoleted...
<naobsd>
(except things for mask rom mode)
<dowu>
What do you mean newer Rockchip SoCs?
<naobsd>
e.g. RK3399
<naobsd>
well, I'm not RK person, "newer Rockchip SoCs support only mainline u-boot/linux" might be incorrect, sorry
<naobsd>
but it looks like RK focuses mainline(oss) things for newer SoCs
<naobsd>
since rk3288
<dowu>
I see
dlezcano has joined #linux-rockchip
<stdint>
naobsd, no, the RK protocol would be still used to flash bootloader in maskrom
milosladni has joined #linux-rockchip
milosladni has quit [Client Quit]
<naobsd>
stdint: yes, I said "(except things for mask rom mode)" :)
<stdint>
I don't notice that sorry
<naobsd>
I think, uploading loader with fastboot support, then use fastboot, will be handy
<naobsd>
(or uploading u-boot, then do something on u-boot console)
<stdint>
I agree with you, but the maskrom is hard code in chip
<stdint>
and PM doesn't think we should use the fastboot
<stdint>
you may send him a mail to give your suggestion
paulk-collins has joined #linux-rockchip
<naobsd>
well, no
<naobsd>
"uploading loader with fastboot support" this is not mask rom code
<naobsd>
u-boot with fastboot support is enough
<stdint>
well actually, the fastboot is not need
<stdint>
you could mount the all the partition through otg
<stdint>
you could updata any files you want
<naobsd>
ah, loader with usb mass storage mode support? it might be another answer
<naobsd>
but with fastboot, it can run new kernel without flashing
<naobsd>
it can erase partition with single command (not writing lots of 0x00)
<naobsd>
maybe something else
<naobsd>
I'm not sure what is the best ;)
<naobsd>
what I said was rockusb protocol is needed only for mask rom mode in future ;)
<naobsd>
more common protocol such as fastboot, ums, etc will be used after running loader
<paulk-collins>
libv, interesting that there is no linux-mediatek community yet ;)
<libv>
why should there be?
<libv>
how many mtk chipsets are hackable? how many have u-boot and kernel available?
premoboss has quit [Ping timeout: 265 seconds]
<libv>
paulk-collins: only -sunxi is the really popular one, with rockchip a distant second (sadly)
<paulk-collins>
libv, there is an upcoming Chromebook coming with mt8173
<paulk-collins>
libv, with coreboot support
<libv>
ah, pvr rogue based
<paulk-collins>
libv, nearly no blobs
<paulk-collins>
yeah :(
<paulk-collins>
libv, mediatek is contributing a lot to mainline kernel thanks to ChromiumOS
<libv>
my currnet customer is going to be finding out how great PVR is :)
<paulk-collins>
hehe
<paulk-collins>
libv, note that there are also rk3399 Chromebooks coming later
<libv>
they want a proprietary hypervisor, a proprietary client for the cluster, and linux for infotainment
<paulk-collins>
libv, and rk3288 is also moving forward, rockchip is mainlining a VPU driver
<libv>
on the rogue....
<paulk-collins>
libv, good luck with that :)
<libv>
i know, they talked to the cedrus guys, and nove and i talk
<paulk-collins>
nice
<paulk-collins>
cedrus also leaped forward
<paulk-collins>
thanks to free-electrons
<libv>
my customer ran out of money though
<libv>
which gives me a reason to stop working for them (which makes me surprisingly happy)
<paulk-collins>
that won't make things easy I guess
<paulk-collins>
okay
<libv>
and afterwards they came up with the nonsense i just stated :)
<libv>
which made me very very happy :)
<libv>
i had good revenue out them for 1.5ys so i am ok financially
<paulk-collins>
alright!
<libv>
and i have a child coming in december, and stuff to organize :)
<libv>
as for mtk, i saw the cnx thing
<libv>
and then read pvr
<paulk-collins>
oh that's great :)
<paulk-collins>
cheers!
<libv>
and then thought "nope, not gettnig that"
<paulk-collins>
okay well, I hope it'll be good enough without 3D
<libv>
i am now poking at amlogic s805/905 (odroid) and just got a s912 box which is at home waiting for me to open it up
<libv>
they love their pre-uboot boot blobs :(
<stdint>
naobsd, then I would suggest you to use the tftp
<naobsd>
stdint: I said "(or uploading u-boot, then do something on u-boot console)" too :)
<stdint>
paulk-collins, I am doing the VPU driver
<paulk-collins>
libv, oh I'm quite interested to learn about those platforms
<paulk-collins>
libv, so pre-u-boot blobs huh?
<libv>
yup
<stdint>
naobsd, well my English is too good enough
<libv>
managable for s805 (not aarch64)
<libv>
but not so for s905 anymore
<libv>
trustedcore signed crap
<libv>
which even has the CPU DVFS tables
<libv>
not sure whether you followed that story
<naobsd>
anyway, standard things should be better than rockusb :)
<paulk-collins>
stdint, that's great!
<paulk-collins>
stdint, are you at rockchip?
<paulk-collins>
libv, oh damn :(
<stdint>
paulk-collins, yes
<paulk-collins>
stdint, excellent
<paulk-collins>
stdint, as far as I saw, rk3288 vpu doesn't require a loaded firmware, right?
<paulk-collins>
stdint, but rk3399 does
<stdint>
yes
<stdint>
but I am not sure about the rk3399
<libv>
wasn't rk3339 also aarch64?
<libv>
it could be that this trustedcore bs is the norm for aarch64 (i have been too busy trying to beat some sense in my customer to play with much aarch64 hw to be able to make a sound judgement there)
<paulk-collins>
yes it is
<paulk-collins>
libv, but I don't think it has any pre-loader blobs
<paulk-collins>
on Chromebooks, they use Coreboot directly
<libv>
but coreboot is not too unhappy to use blobs these days
<paulk-collins>
libv, when they can't avoid them, indeed
<libv>
(where was the FSF when that happened, i was there to try to push ron to have his code at least external of the coreboot repo)
<paulk-collins>
libv, otherwise, chromiumos people are doing their best to avoid it
<paulk-collins>
libv, Intel x86 is a dead-end for now though
<paulk-collins>
and sadly, it seems that the "firmware is part of hardware design" reasoning is getting more and more common
<paulk-collins>
manufacturers don't want to open their hardware design, so they don't open the firmware
<paulk-collins>
in the case of Intel, it covers all silicon init :(
<libv>
i am having a shitthrowing contest with ATIs bridgman on phoronix right now
<libv>
he basically is confirming that he had a different plan all along
<libv>
atombios for ati graphics really was just the start
<libv>
and the dependence on further firmware has only increased since then
<paulk-collins>
yeah, I saw that :(
<libv>
and i pretty much got my career ruined (once again) trying to get a solid free display driver out
<paulk-collins>
ohh 20 pages of it now!
<paulk-collins>
yeah :(
<paulk-collins>
that sucks
<libv>
half of it is me and bridgman battling, the other half is random phoronix noise
<libv>
and then the libreboot talk at fosdem was all FSF style whining about blobs for graphics
<libv>
where were they when that battle was being fought?
<paulk-collins>
well, we're catching up late
<paulk-collins>
Libreboot is quite recent
<paulk-collins>
compared to the events you're mentioning
<libv>
the FSF is never on the ball.
<paulk-collins>
yeah, that's right
<libv>
and i am not slating you and your work on libreboot
<libv>
i just think the whole thing is pretty late, and comes over as mostly whining, sadly
<paulk-collins>
it feels like the FSF is not that invested in the low-level aspect of things, sadly
<paulk-collins>
libv, I understand that it comes across like that
<paulk-collins>
libv, really, I think it's just a bunch of motivated people that are late to the party
<paulk-collins>
(Libreboot)
<paulk-collins>
and are now facing a shitty situation
<paulk-collins>
but heh, at least we can hope that it'll end up actually improving things
<paulk-collins>
it may be too late for the battles we lost already, but there are other ones to come
* paulk-collins
trying to be optimistic
<libv>
wait and see, but with intel/amd where they are today, and where aarch64 is headding, things have not been improving
<paulk-collins>
I'm not sure aarch64 is all that bad
<libv>
intel just cut a lot of its workforce as well, amd is run by ati and as a result, almost dead
<libv>
i just noticed a big, signed, blob for amlogic so far
<paulk-collins>
anyway, we'll know more with that mediatek chromebook in hands
<paulk-collins>
but I see potential there
<libv>
and it seems a relatively standard aarch64 thing to do
<paulk-collins>
okay
<libv>
i wonder what olimex's a64 board will be like software wise
<paulk-collins>
yeah, indeed
<libv>
never played with pine64 though
<paulk-collins>
I'm still internally debating whether to apply for a few month's internship there next summer
<paulk-collins>
maybe I could have a close look at it then
<libv>
on the other hand, that's the status on most sunxi hw
<paulk-collins>
well, we're doing good with DRAM init nowadays
<libv>
really? again, i am a bit out of touch
<paulk-collins>
I think A33 is done
<paulk-collins>
I know H3 is
<paulk-collins>
A31 received little interest
<paulk-collins>
so I'm unsure about H8 and A80
<paulk-collins>
but the rest should be good
<paulk-collins>
U-Boot is working real great, too
<libv>
ok, so olimex should be doing good
<paulk-collins>
I hope so
<libv>
rk3399 should be better than amlogic s912 for me though, when it finally does hit
<paulk-collins>
yeah
<libv>
i got the odroids for the mali-450
<paulk-collins>
ah right, makes sense
<libv>
and the s912 device for the mali-t8xx on it
<paulk-collins>
note that there is another rockchip already shipping
<paulk-collins>
geekbox thing
<libv>
the 3288 i have, both the firefly and the asus chromebook
<libv>
but that's t7xx
<paulk-collins>
rk3368
<paulk-collins>
mhh that's powervr :(
<paulk-collins>
libv, note that I have a bunch of rk3288 cros devices now
<paulk-collins>
even an HDMI dongle I got for $50 in the US
<paulk-collins>
when attending the Coreboot conference in SF
<libv>
i just spent the morning explaining to my customer just how they shot themselves in the foot with the renesas they are going to wo work with
<paulk-collins>
well, better tell them now :)
<libv>
apple has a really all encompassing license with powervr
<libv>
they design their own powervr cores these days
<paulk-collins>
really?
<paulk-collins>
damn
<libv>
i already expected that apple rewrote most of the imagination drivers/microcode themselves
<libv>
but this truly means that only apple has a solid powervr implementation
<libv>
and that what other costumers get is pretty second rate
<paulk-collins>
I guess yeah
<paulk-collins>
that's leverage for a free driver right there
<paulk-collins>
but who's gonna hear that argument…
<libv>
and then i explained them here that the powervr 7 is the first where imagination claims hardware virtualization (in as far as that can be true in the pvr microcode driven world)
<libv>
and guess which is the only company currently shipping the 7 :)
<libv>
3 more weeks, and then holidays, and good riddance too :)
<paulk-collins>
I see
<paulk-collins>
good luck with it then
<libv>
some source in img told me that it was pretty close for sgx a few times
<libv>
(pvr 5xx)
<paulk-collins>
I mean come-on, the code leaked
<libv>
but that for some reason it was blocked each time
<paulk-collins>
what argument can they possibly have left
<paulk-collins>
maybe I should have paid more attention to the MIPS boards
<paulk-collins>
and get discussions going with the PR guy
<paulk-collins>
not sure he can do a lot though
Haris has joined #linux-rockchip
Haris is now known as Guest89380
<Guest89380>
HI is there anyone here that can assist me with unbricking an RKM MK902, I have the circuit board open and ned some advice
<Guest89380>
anyone?
Guest89380 is now known as Haris12345
<Haris12345>
Is there a channel that would be more suited to help with unbricking rockchip devices?
<Haris12345>
anybody here?
aalm has quit [Quit: aalm]
nighty has quit [Quit: Disappears in a puff of smoke]
<Haris12345>
anyone know of a channel that would help unbricking an RKM MK902 ?
linux_ has joined #linux-rockchip
<libv>
paulk-collins: nah, these were always high level decisions which also hurt alexandru voicas goals
<paulk-collins>
yeah
nighty has joined #linux-rockchip
Haris12345 has left #linux-rockchip [#linux-rockchip]
premoboss has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
wens has quit [Quit: Changing server]
wens has joined #linux-rockchip
wens has quit [Client Quit]
wens has joined #linux-rockchip
linux_ has quit [Ping timeout: 264 seconds]
fireglow has quit [Ping timeout: 258 seconds]
vagrantc has joined #linux-rockchip
premoboss has quit [Ping timeout: 244 seconds]
premoboss has joined #linux-rockchip
fireglow has joined #linux-rockchip
wadim_ has quit [Remote host closed the connection]
arnd_ has joined #linux-rockchip
steev_ has joined #linux-rockchip
sjg1__ has joined #linux-rockchip
anatoly_ has joined #linux-rockchip
anatoly has quit [Ping timeout: 260 seconds]
steev has quit [Ping timeout: 260 seconds]
arnd has quit [Ping timeout: 260 seconds]
cyrozap has quit [Ping timeout: 260 seconds]
sjg1_ has quit [Ping timeout: 260 seconds]
dlezcano has quit [Ping timeout: 260 seconds]
mrutland has quit [Ping timeout: 260 seconds]
ayaka has quit [Ping timeout: 260 seconds]
fungi has quit [Ping timeout: 260 seconds]
ayaka has joined #linux-rockchip
sjg1__ is now known as sjg1_
fungi has joined #linux-rockchip
cyrozap has joined #linux-rockchip
arnd_ is now known as arnd
mrutland has joined #linux-rockchip
dlezcano has joined #linux-rockchip
steev_ is now known as steev
JohnDoe_71Rus has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
dlezcano has quit [Remote host closed the connection]
JohnDoe6 has joined #linux-rockchip
JohnDoe_71Rus has quit [Ping timeout: 250 seconds]
dlezcano has joined #linux-rockchip
dlezcano has quit [Remote host closed the connection]