<naobsd>
sjoerd: ah, rockchip changes will be merged into someone's arm tree
<naobsd>
probably arm-soc tree
GriefNorth has joined #linux-rockchip
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 245 seconds]
GTRsdk has quit [Ping timeout: 252 seconds]
GTRsdk has joined #linux-rockchip
levd1 has joined #linux-rockchip
SamuelMoraesF has quit [Ping timeout: 252 seconds]
SamuelMoraesF has joined #linux-rockchip
levd has quit [Ping timeout: 245 seconds]
<sjoerd>
naobsd: yeah
<sjoerd>
naobsd: but as a maintainer tree you can easily ask it to be merged into next directly for earlier testing
<sjoerd>
We're should have rockchip boards in e.g. kernelci soon so having it in next early will mean it gets tested eearlier :)
<sjoerd>
*We should
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 245 seconds]
<rperier>
sjoerd: +1
<rperier>
sjoerd: personally I always work with next, and sometimes I backport some patches. But yeah, we should
levd1 has joined #linux-rockchip
<rperier>
well, I think that having a rockchip tree based on the torvald tree (the last rc most of the time) is not so bad, because we have a stable kernel to work... However, I completly agree that for continuous integration we should also work with next
levd has quit [Ping timeout: 265 seconds]
ganbold has quit [Ping timeout: 255 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 255 seconds]
<sjoerd>
rperier: oh no having a linux-rockchip is great ofcourse :)
<sjoerd>
but having it pulled into linux-next would help as you say
<rperier>
yes
<sjoerd>
seperately i'm sure tyler-baker would be more then ahppy to add the linux-rockchip tree to kernelci as well once rockchip boards become avaialble in it
<tony_>
I really want to if i can set resolution by cmdline ?
<tony_>
naobsd, do you know how to do it ?
GTRsdk has quit [Ping timeout: 255 seconds]
GTRsdk has joined #linux-rockchip
ganbold has joined #linux-rockchip
ganbold has quit [Client Quit]
ganbold has joined #linux-rockchip
ganbold has quit [Remote host closed the connection]
ganbold has joined #linux-rockchip
Shinde has quit [Ping timeout: 250 seconds]
levd1 has joined #linux-rockchip
GTRsdk has quit [Ping timeout: 260 seconds]
Shinde has joined #linux-rockchip
levd has quit [Ping timeout: 244 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 240 seconds]
<naobsd>
tony_: just edit lcd_XXX.c
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 244 seconds]
cristian_c has joined #linux-rockchip
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 250 seconds]
nighty^ has joined #linux-rockchip
visitor-14524 has joined #linux-rockchip
<cristian_c>
tony_: hello
<tony_>
cristian_c, hello.
<cristian_c>
tony_: I've tried to launch your executable
<tony_>
cristian_c, then...
<cristian_c>
I get: no such tool
<cristian_c>
toolbox.bin
<tony_>
cristian_c, ?
<tony_>
cristian_c, full path.
<tony_>
cristian_c, I think this is basic knowlege about linux. ;P
<cristian_c>
tony_: I've always launched executables from their diectory
<cristian_c>
./toolbox.bin
<tony_>
Toolbox!
<cristian_c>
mmmmm
<tony_>
cristian_c, it give me this information.
<tony_>
cristian_c, # toolbox
<tony_>
Toolbox!
<tony_>
#
<tony_>
cristian_c, can you see this ?
<cristian_c>
tony_: where have I to place the executable?
<cristian_c>
what directory?
<cristian_c>
:)
<tony_>
cristian_c, why you add ".bin" at the end.
<cristian_c>
ok
<tony_>
cristian_c, try "ls -l"
<tony_>
cristian_c, let me see what in your directory.
<visitor-14524>
Or, maybe, "pwd" first?
<cristian_c>
tony_: I've placed your file into my home
<cristian_c>
tony_: what directory should I place your file in? :)
<tony_>
cristian_c, normally, no matter.
<cristian_c>
ok
<cristian_c>
tony_: have I to add my home to the PATH?
<cristian_c>
if I must run: toolbox
<cristian_c>
or full path
<tony_>
cristian_c, no, I just want to know if the toolbox have executable permmision.
<cristian_c>
without .bin extension
<tony_>
cristian_c, try to "ls -l toolbox" at first.
<tony_>
cristian_c, okay ?
<cristian_c>
tony_: ok, but I've changed the permissions, I've added execution permission to owner
<cristian_c>
that is my user
<tony_>
cristian_c, I want to see it by my eyes. ;P
<cristian_c>
ok, I'll save the results
<visitor-14524>
And what happens if you intentionally mistype "toolbox", does it still say "no such tool" or something different?
<mmind00>
sjoerd: till now my thoughts always were that we have so little changes normally that must go through arm-soc and not some other maintainer-tree, that it didn't see the need for a linux-next inclusion ... especially as I'm normally doing multiple pull-requests to armsoc so the time stuff spends in my tree alone is quite small
<rperier>
sjoerd: if you want some tests on u-boot feel free to ask, I don't think that I will time to develop on u-boot (I prefer hack on the kernel and yocto), but I can do some tests :)
<mmind00>
sjoerd: of course that is open to re-evaluation when the flood of changes starts :-)
levd has quit [Remote host closed the connection]
<sjoerd>
mmind00: I'm just a big fan over very very short test cycles
<sjoerd>
and getting merged in linux-next is a simple question of asking not an ongoing effort so it's almost a waste not to do so :)
<tony_>
cristian_c, I also want to know visitor-14524's question. ;)
<cristian_c>
visitor-14524: I'll try that, too
<cristian_c>
if it was in the path
<cristian_c>
but it isn't
<mmind00>
sjoerd: ok so you are in favor, rperier too ... I guess it also doesn't hurt ;-)
<tony_>
cristian_c, if you use the "./toolbox" in the place which in. it don't need in the PATH.
<tony_>
cristian_c, don't care the PATH at first.
<rperier>
mmind00: an excellent example might be some regressions sometimes... some of these only appear with next... :)
<cristian_c>
tony_: ah, ok
<cristian_c>
without the .bin extension
<cristian_c>
thanks
<tony_>
cristian_c, everything works fine now ?
<cristian_c>
tony_: I've to reboot to try it
<mmind00>
rperier: I know the value of linux-next :-P ... it's just most stuff goes through other trees, leaving only dts changes (and a bit of suspend voodoo) going through my tree and then arm-soc ;-)
<tony_>
cristian_c, I'm wonder your occupation ？
<rperier>
I know that you know, I was just sharing my point of view ;)
<visitor-14524>
Just a question myself, anyone familiar with "rkflashtool b <flag>" and having a list with what the flags mean, or are they device/bootloader specific?
<tony_>
cristian_c, harker ?
<sjoerd>
rperier: feel free to test the u-boot branch i mentioned btw, I'd really like to see rockchip sutff moving to a non-crazy vnedor u-boot ;)
<cristian_c>
tony_: no
<sjoerd>
rperier: I might be tempted to hack on rk31 for a bit as i have a person project with, but that will be a bit more longterm
* sjoerd
not so sure if he wants to get into ram initialization for those, though using he propreitary first stage loader may work
<mmind00>
sjoerd: from what I've seen, ram init also is the only big chunk missing for rk30/rk31 uboot?
<sjoerd>
mmind00: the other bits are pinctrl and clocking stuff but that's not so scary
<mmind00>
sjoerd: I guess I'll try to see if anybody at Rockchip might be helpful here ... seeing that the rk32 ram init is out in the open already
<sjoerd>
mmind00: :)
<mmind00>
sjoerd: regarding linux-next, I guess it's just mailing Stephen Rothwell, right? [didn't find any "howto" so far]
<sjoerd>
mmind00: as far as i know yes
<mmind00>
sjoerd: ok, so to make rperier and you happy ;-)
<sjoerd>
\o/
<rperier>
:D
<sjoerd>
mmind00: i didn't check whether ram init is documented for rk31xx and rk30xx tbh
<sjoerd>
the key is not only how to init it but also the timings ofcourse
<mmind00>
sjoerd: it looks like Simon adapted that from the coreboot implementation
<rperier>
I think that the proprietary first stage bootloader as a first step is enough... I mean... perhaps that it would be better to focus on u-boot for rk31 and once you have something working, switch to the SPL... no ?
<sjoerd>
mmind00: yeah
<rperier>
in my humble opinion
<sjoerd>
rperier: that's my thinkign as well
<sjoerd>
And i do care much more about the u-boot stage then about hte SPL stage
<sjoerd>
but having both is always nice
<rperier>
in the longterm, have everything opened would be great, of course
<rperier>
I agree
<naobsd>
I guess DDR driver in RK 3.0 kernel for rk30/31 might be helpful for DDR init
<sjoerd>
naobsd: typically the kernel doesn't touch those parts at all
<sjoerd>
as it will assume it gets started with working ram :)
<sjoerd>
that that won't work with the upstream spl ofcourse as it can't talk that protocol
<naobsd>
well
<naobsd>
just after entering mask rom mode, you can talk with "rkflashtool l"
<naobsd>
I think RK DDR init blob returns mask rom code after DDR is initialized, so you can talk with "rkflashtool L"
GTRsdk has joined #linux-rockchip
<naobsd>
but probably simon's SPL doesn't return mask rom, you cannot talk at all
<sjoerd>
naobsd: indeed, simons SPL code just wants to load the next stage directly
<naobsd>
same for SPL on flash storage, SPL works as DDR init and not returned
<naobsd>
I guess if it returns(how? no idea for now), next stage will be loaded into DRAM by mask rom
<sjoerd>
hah, i should have read sjg's readme better but he actually has instructions for using it thoruhg maskrom mode
<sjoerd>
from his readme `` However it does not seem to be possible to
<sjoerd>
use the existing boot ROM code from SPL''
<naobsd>
return address might be stored when SPL is called
<naobsd>
I'm not sure for now
<sjoerd>
Nod
<sjoerd>
would be nice if that was documented
<naobsd>
"objdump -d" :)
<sjoerd>
one open thing for my u-boot branch is figuring out where it got loaded from (SD, EMMC, whatever) so it can load the next stage from the right device rather then always SD atm
<visitor-14524>
And here I thought doc files usually end with .c .... :)
<naobsd>
d is document :)
<sjoerd>
visitor-14524: If they'd have the c code for those bits that would be lovely
<visitor-14524>
I _think_ there are decompilers for Asm-to-C, at least some resources hint to that... Question is, how good are they...
<naobsd>
I really feel happy even if we still miss many things about low layer... here is the people who can discuss about it :)
<naobsd>
and I really feel unhappy I cannot get spare time lately :(
<sjoerd>
visitor-14524: some are pretty good, it's moare a matter of how much time people want to poor into it
<naobsd>
(return to home... bye)
BorgCuba has joined #linux-rockchip
naobsd has quit [Quit: naobsd]
<BorgCuba>
Hi, whats the state of the rk3188 mainline kernel? Has anyone tested this recently?
<karlp>
nah, no-one, not ever....
<BorgCuba>
I tried maybe 3-4 months ago and I remember the dwc2 driver had problems
<BorgCuba>
The phy driver was working but there was something wrong with the fifo buffer allocations
<BorgCuba>
karlp, dont you maintain the libopencm3-examples git?
<karlp>
not by myself, but yes, I'm one of the committers there
pietrushnic has quit [Ping timeout: 250 seconds]
<karlp>
BorgCuba: I wasonly laughing at the "recently" bit of your comment, rk3188 is one of the better devices in mainline, not as good as 3288, but better than 3066 but the other people here can probably help more
<BorgCuba>
I see, I would give it another try on my radxa board. Do you have wiki or something where you list which features/drivers are working on a certain device/soc?
pietrushnic has joined #linux-rockchip
<karlp>
you can make or maintain pages on linux-rockchip.info but no-one's maintaining any central list currently to my knowledge,
<karlp>
radxa has their own wiki, they talk explicitly about mainline there don't they?
<BorgCuba>
yes, but I think the radxa page is outdated or at least not updated
tizbac has quit [Ping timeout: 246 seconds]
<c0d3z3r0>
hi guys, maybe someone could help me with git? :) I have a branch A at next-20150820 and a branch B at next-20150817. Merging A into B works just fine… fast-forward. Back to the start: A at 20150820 and B at ..17; I do one little commit on B and then merge A into B which should work without problems, shouldn't it? I get many merge conflicts… any ideas why?
<c0d3z3r0>
I never had that problem before :(
<visitor-14524>
Wonder how long A and B were apart? Merge tries to find the common root first to base the changes in both branches on.
<visitor-14524>
But, oh, right, fast-forward should answer my thought at least partly..
<c0d3z3r0>
B was branched off from A at ..17; then I pulled on A and fast-forwarded it to ..20
<visitor-14524>
And that single commit on B lads you in merge conflict hell...? Okay. Strange.
<c0d3z3r0>
yep
<c0d3z3r0>
fun fact: I did that many times before what worked fine
<visitor-14524>
Maybe try the other way round...? Stash the change, do the fast-forward, then pull the change from the stash? Effectively a rebase of the to-be-commited change...
<mmind00>
c0d3z3r0: linux-branches are recreated every time, so they are not really mergeable
<c0d3z3r0>
mmind00: the complete history gets rewritten every time?
<mmind00>
c0d3z3r0: linux-next master is (re-)created from the sourced trees
<c0d3z3r0>
mmind00: aha, that explains why I get such problems… so I have to use linus' branch and need to apply the patches I want to test on next each time again?
<c0d3z3r0>
(after a fetch)
<mmind00>
c0d3z3r0: I guess that all depends on what you're doing ... aka applying patches on top of a linux-next release works too for testing ... you just cannot jump between next releases that easily
<mmind00>
c0d3z3r0: as you can see in my github repo, I use a different approach, for pending patches I need for a longer timespan
<c0d3z3r0>
mmind00: ok, thanks :)
<visitor-14524>
Hmmmh, strange. rkflashkit seems to flash an image just fine, but with rkflashtool it's more often than not trashed... As in, reading it out again and comparing yields differences.
sunilmohan_w has quit [Ping timeout: 265 seconds]
<sjoerd>
hmm looks like the loader gets probed from at least 6 different locations fun
sunilmohan_w has joined #linux-rockchip
<sjoerd>
mmind00: your clocking patches work nicely to sort out the issue with rates being wrong at first on spidf, thanks :)
<mmind00>
sjoerd: yay
<mmind00>
sjoerd: so I'll bring them on its way too
<mmind00>
s/its/their/
<sjoerd>
cool
<sjoerd>
need to get analog output working on my orkc2 first now and then i'll look at fixing the varous review comments and sending v4 for the spdif bits
<sjoerd>
and maybe if i have time do a first itegration of the dts for rock2
cristian_c has quit [Quit: Bye]
ssvb has quit [Ping timeout: 244 seconds]
JohnDoe_71Rus has joined #linux-rockchip
GriefNorth has quit [Quit: Konversation terminated!]
pjr has quit [*.net *.split]
ssvb has joined #linux-rockchip
pjr has joined #linux-rockchip
irsol has quit [Ping timeout: 256 seconds]
GriefNorth has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
irsol has joined #linux-rockchip
<c0d3z3r0>
rperier: your / mmind00's patch solves the problem of being stuck at …PMU..
tony_ has quit [Quit: Leaving]
<rperier>
c0d3z3r0: there is a part from me (pclk_peri) and a part from Heiko (clk_protect calls order)
<rperier>
okay good
<rperier>
I will send it to the ML soon
<rperier>
does someone know a good free/libre email hosting service ?
<rperier>
I want to leave gmail (aka "big brother is watching you")
<visitor-14524>
Now the list of possible choices got very, very short....
<c0d3z3r0>
rperier: I'm using zoho.com with my own domain, but going to switch completely to my own mailserver soon
<rperier>
I found stuffs like mailoo.org or openmailbox... but without "two-factor authentication"... I don't like that...
<c0d3z3r0>
the problem with mails is that not only ones own hoster must be "secure" but also the hoster of the recipient.. which isn't the case in maybe 90%
<visitor-14524>
As well as any mail transport agent on the path between those two.
<c0d3z3r0>
yeah right
<c0d3z3r0>
the only solution at the moment is pgp/gpg but most people are claiming that it's "soooo complicated" blah blah
<visitor-14524>
I know. Believe me, I know...
<c0d3z3r0>
I've given up discussing that… same problem like whatsapp vs threema/myenigma/signal and so on
<c0d3z3r0>
"none of my friends are using it blah blah" … really bad arguement
<rperier>
no I was most talking about the security of the account by itself, two-factor auth reduces the risk to being hacked
<rperier>
(+ protocols used to be authenticated... of course)
<visitor-14524>
But your other grief was with Big Brother Google excessively sifting through your mail for anything that might be of value?
<karlp>
mailpile is a good option that's coming along nicely, but it won't meet everyone's needs.
<karlp>
(yet)
<visitor-14524>
leaving for home... CU
visitor-14524 has quit [Quit: Connection reset by beer]
premoboss has joined #linux-rockchip
GTRsdk has quit [Ping timeout: 244 seconds]
GTRsdk has joined #linux-rockchip
nashpa has quit [Ping timeout: 244 seconds]
nashpa has joined #linux-rockchip
tizbac has joined #linux-rockchip
gb_master has joined #linux-rockchip
GTRsdk has quit [Ping timeout: 244 seconds]
pizthewiz has joined #linux-rockchip
maz_ has joined #linux-rockchip
ssvb has quit [Ping timeout: 246 seconds]
jas-hacks has joined #linux-rockchip
maz_ has quit [Ping timeout: 246 seconds]
ssvb has joined #linux-rockchip
maz_ has joined #linux-rockchip
premoboss has quit [Ping timeout: 264 seconds]
jas-hacks has quit [Quit: Leaving.]
<maz_>
anyway could point me to a u-boot tree containing the patches that are aimed to mainline (probably Simon Glass's patches)?
<maz_>
mmind00: cool, thanks.just got my speedy, so eager to start hacking while on the plane... ;-)
<sjoerd>
you'll probably need some of the crazy tricks we've done on the nvidia chromebooks if you want to chainload u-boot btw
<sjoerd>
(rather then having it in spi)
<mmind00>
maz_: the coreboot on the device also loads custom kernels alright on its own
<maz_>
sjoerd: yeah, I expect this to be slightly convoluted - you probably need to masquerade u-boot as a kernel for the firmware to be happy
<maz_>
mmind00: it does indeed, but I need to enable PSCI and boot to HYP, hence the need for u-boot.
<sjoerd>
maz_: the real convoluted thing is that you can't load u-boot at rnadom offsets
<sjoerd>
maz_: So you have to stick u-boot n the FIT image at a known offset (iotw pad the fit image), work out where coreboot loads the FIT image in memory so you can configure u-boot with that address
<sjoerd>
maz_: oh and also ensure you align it at a nice offset otherwise things will explode as well
<maz_>
sjoerd: fancy.
<sjoerd>
maz_: also see the patch from tomeu on the u-boot list to turn on the extended addressing bit of the mmu otherwise it'll hang when turning the mmu on
<sjoerd>
somewhere on my way too long todo list is adding some scripts to do all that..
<sjoerd>
but yeah it took us some time to wokr out how to get this going :p
<maz_>
sjoerd: I may have to prototype on something more hackable than the chromebook! ;-)
<mmind00>
maz_: as the edp driver is still in the works
<sjoerd>
maz_: that's if you want to chainload u-boot on eMMC from coreboot
<sjoerd>
maz_: you can also use the legacy payload option of coreboot in principle (never loked at that) or flash u-boot into the SPI flash which is what sjg tends to do but that's abit more scary
<maz_>
mmind00: my plan is load u-boot from the sdcard, really. I don't plan to change anything on the device itself.
<mmind00>
sjoerd: especially taking apart a Chromebook on a plane might raise some eyebrows
<maz_>
mmind00: yeah, I'll wait until I'm home! ;-)
GTRsdk has joined #linux-rockchip
<sjoerd>
maz_: right taht's why we went that route as well
<mmind00>
maz_: yep, that's what I'm doing as well ... loading kernel + os from an sd card
<mmind00>
maz_: they have this nice dual-boot "prompt" in dev-mode, so you can decide what to load
<maz_>
mmind00: so far, it works pretty well - I've reused the Debian install that used to run on my Samsung chromebook, and slapped it on speedy. quite an improvement!
<sjoerd>
mmind00: we're driving our nyan in our lava lab so we needed some fanicer stuff :p
<mmind00>
sjoerd: haha, yeah my pinky also gets its kernel via tftp ... just the real consumer-chromebooks I have I'd like to keep in a general working condition
<sjoerd>
mmind00: maybe it's more fancy with newer coreboots, but iirc on the nyans you couldn't really dynamically drive where to tftp from, what kernel arguments etc
<maz_>
mmind00: I'm not fond of the whole GPU thing - having simple 2D graphics is just fine for what I do (which is basically writing code or email).
<maz_>
sjoerd: when you say "also see the patch from tomeu on the u-boot list to turn on the extended addressing bit of the mmu ...", do actually mean turning it *off*?