lurchi_ has quit [Read error: Connection reset by peer]
lurchi__ has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
anarsoul has quit [Ping timeout: 240 seconds]
nasugagusan has quit [Quit: WeeChat 1.9.1]
cnxsoft has quit [Ping timeout: 240 seconds]
cnxsoft has joined #linux-rockchip
wzyy2 has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-rockchip
JohnDoe_71Rus has quit [Client Quit]
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 has joined #linux-rockchip
cnxsoft1 is now known as cnxsoft
_whitelogger has joined #linux-rockchip
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 248 seconds]
vstehle has joined #linux-rockchip
wzyy2 has joined #linux-rockchip
<eballetbo>
Esmil : many thanks, with your defconfig works :)
<Esmil>
eballetbo: Nice!
<Esmil>
It would be interresting to know what config option breaks it though
<eballetbo>
yep, I'll investigate a bit and also rebase the patches on top of mainline
<mmind00>
eballetbo: good thing would probably also be letting Sean Paul know that your on it to prevent duplicate work ... see the similar discussion in #chromium-os yesterday between thierryE and seanpaul
wzyy2 has quit [Remote host closed the connection]
wzyy2 has joined #linux-rockchip
<eballetbo>
mmind00: thierryE and me are in contact :)
<eballetbo>
I mean that we're working together
<mmind00>
eballetbo: ah, great
<mmind00>
eballetbo: are you also in contact with seanpaul? "<seanpaul> thierryE: ah, good clue about where i left off :)", not that you two work on this separately
<mmind00>
because that somehow sounds like he wants to look at this as well
<eballetbo>
yes, we're also in contact with seanpaul
<thierryE>
mmind00: yes
<thierryE>
mmind00: please to meet you btw :)
<mmind00>
thierryE: Hi :-)
<mmind00>
and great to hear that everybody is on the same page ... seeing these separate discussions on separate channels made me worry a bit ;-)
matthias_bgg has joined #linux-rockchip
kloczek has quit [Remote host closed the connection]
<mmind00>
phh: interesting question ... often times a "ping"-mail is enough to get maintainers into action ... but that differs by maintainer
<phh>
ok thanks. and what about timeframe? it's not too late for 4.15?
matthias_bgg has quit [Ping timeout: 240 seconds]
afaerber has joined #linux-rockchip
Aussie_matt has joined #linux-rockchip
wzyy2 has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 240 seconds]
matthias_bgg has joined #linux-rockchip
nighty- has quit [Quit: Disappears in a puff of smoke]
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-rockchip
lurchi_ is now known as lurchi__
lurchi__ has quit [Read error: Connection reset by peer]
lurchi__ has joined #linux-rockchip
nighty- has joined #linux-rockchip
<mmind00>
phh: I do think it will be to late for 4.15
lurchi__ has quit [Ping timeout: 264 seconds]
matthias_bgg has quit [Ping timeout: 248 seconds]
vagrantc has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
nasugagusan has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
vagrantc has joined #linux-rockchip
nighty-- has joined #linux-rockchip
Aussie_matt has quit [Remote host closed the connection]
matthias_bgg has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
nighty-- has quit [Ping timeout: 240 seconds]
kloczek has joined #linux-rockchip
<vagrantc>
anyone successfully get u-boot SPL working with firefly-rk3399 ?
<vagrantc>
all i get is: U-Boot SPL board init"Synchronous Abort" handler, esr 0xffff0000
<vagrantc>
i've created a fit image with ATF in all the right places... i think. dumped the u-boot-spl rksd image onto sector 64, and dumped the u-boot.itb fit image onto 16384 ...
* vagrantc
waits to hear about other better, nicer rk3399 boards
<xevious>
I just built a new base image for RK3328 using the latest version of rk_rootfs_build to try out the armsoc driver. When I try to start X, I'm getting this error: Driver failed PrepareAccess on a pinned pixmap.
<xevious>
Has anyone come across that error? Is there a known solution?
* vagrantc
wonders if the eMMC is fried on this thing
wzyy2 has quit [Ping timeout: 240 seconds]
wzyy2 has joined #linux-rockchip
<xevious>
This error appears above the one I just mentioned: ARMSOCPrepareAccess: Failed to map buffer
wzyy2 has quit [Ping timeout: 248 seconds]
wzyy2 has joined #linux-rockchip
<wzyy2>
- -I test it in rk3036 and it work well, but i don't have try rk3328..
<xevious>
I'm building a new image with the latest upstream u-boot, kernel, and rk_rootfs_build.
<mmind00>
vagrantc: my rk3399 firefly does boot via spl (not having the correct rank handling for ddr-init does shorten the ram in half) ... but haven't thouched that for quite some time
<mmind00>
vagrantc: other than that, I rebuild the whole boot chain for the Theobroma Systems-Puma board 2 weeks ago ... https://git.theobroma-systems.com/ ... while their u-boot is not 100% mainline, it is very close to it, so I suspect mainline uboot should work just as well
<mmind00>
vagrantc: especially as one of the Theobroma people now does the main maintaining of Rockchip uboot support
<beeble>
i think rockchip next branch is even further then the repo you linked
<beeble>
ok, it's some mix
cyteen has quit [Ping timeout: 268 seconds]
indy has quit [Ping timeout: 252 seconds]
<topi`>
can anyone point me to some kind of instructions on how to boot a 4.x kernel on the rk3368 (geekbox)?
<topi`>
I know it has some odd bootloader, because it loads up an android kernel image (blob starts with ANDROID!) but I can't see where the kernel params go
indy has joined #linux-rockchip
cyteen has joined #linux-rockchip
afaerber has joined #linux-rockchip
<vagrantc>
mmind00, beeble: I never seem to manage to get past all the synchronous abort messages ... but just using upstream u-boot master for the most part
<vagrantc>
also, not sure what ATF binaries to use
* vagrantc
struggles to find the repository ARM-software uses to track issues in arm-trusted-firmware
<beeble>
if so i would guess your atf is the fault. spl loads atf and executes it
<vagrantc>
that's all i see on power-on
<vagrantc>
ok, that's something to start with
<vagrantc>
most u-boot spl report the version number of the build ... wonder why this doesn't
<vagrantc>
useful to know if it's not booting what i think it's booting
<beeble>
let me check later
<beeble>
have to catch the train
jelly-home has joined #linux-rockchip
<vagrantc>
hmmm... my u-boot-tools is the ancient 2017.09 ... wonder if that matters
* vagrantc
wonders how it's getting m0
<beeble>
so spl init comes first. version string follows later with another u-boot spl string
<beeble>
inbetween it initalizes the dram
<vagrantc>
i've tried with a self-built ATF and the atf provided https://github.com/rockchip-linux/rkbin and i've also tried building arm-trusted-firmware from upstream
<beeble>
so it aborts before loading the atf i guess
<beeble>
spl output. atf is build verbose so a bit more output
<vagrantc>
i tried using the debug and non-debug atf variants
<vagrantc>
i've got a build of atf packaged for debian, but i've never seen it work, so obviously not worth uploading (and possibly has other blockers)
<beeble>
i think you shoulf see the booting from <device> first. as it contains the itb with the atf
<vagrantc>
it's loaded on microSD
<vagrantc>
seems to get the abort errors before it even gets that far
<beeble>
what dts are you using?
<vagrantc>
rk3399-firefly.dts from u-boot
<vagrantc>
oh, maybe i should actually use the u-boot.dtb instead
<beeble>
so things that i can think of that can go wrong. you are missing some .config options enabling devicetree in spl. the firefly dts is missing some important dm-pre-alloc entries
<beeble>
so your memory init fails. but thats just a guess
<beeble>
and you may try to do a make clean before rebuilding spl. u-boot make infrastructure is sometimes buggy
<vagrantc>
i always build from a clean source tree
<vagrantc>
in fact, a clean build environment
<vagrantc>
e.g. minimal chroot, add build dependencies, build
<vagrantc>
beeble: you use a patched arm-trusted-firmware for the puma_rk3399 ?
<beeble>
yes
<vagrantc>
in theory that could work with this as well?
<vagrantc>
e.g. use the puma_rk3399's .its file to generate the image using your patched atf ?
<beeble>
i think there is nothing board specific in the patches
muvlon has joined #linux-rockchip
<vagrantc>
i'm not trusting that the script i'm using is actually doing the right thing; it'd be nice to reduce variables
<vagrantc>
the .its generation script, that is
jelly-home is now known as jelly
<beeble>
but you have to get the cortexm0 firmware too. but you will get a error if its missing anyway
* vagrantc
would love to see a different error at this point
<beeble>
build error :)
<vagrantc>
upstream atf builds a rk3399m0.bin ... is that the firmware you're talking about
<beeble>
see iur board readme
<beeble>
our
<vagrantc>
right
<beeble>
and i have to check upstream atf and do a sync
<beeble>
so it's a bit behind and some things may have changed
<beeble>
but nothing that keeps it from working with current uboot
<vagrantc>
ok, i'll try building with your atf/m0 and see how that goes...