<nomis>
I am actually using the 5.4-kernel from the yocto-version of meta-rockchip. But since I did not yet find a sample machine configuration file for a rk3328 I might have dragged something wrong in from https://www.yoctoproject.org/pipermail/yocto/2019-April/044957.html
<robmur01>
not that I have the slightest idea what a yocto is ;)
<nomis>
robmur01: the "rockchip"-part was missing in my machine-config file. Ok, that should help. Thanks.
<robmur01>
(indeed last time I looked it only defined itself by what it *isn't*...)
<nomis>
robmur01: heh, not that I am a yocto expert, but I'd describe it as a "distribution builder"...
<nomis>
Esmil: the kernel builds now, thanks for spotting that.
maze-BUG has quit [Remote host closed the connection]
maze-BUG has joined #linux-rockchip
maze-BUG1 has joined #linux-rockchip
maze-BUG has quit [Ping timeout: 265 seconds]
maze-BUG1 is now known as maze-BUG
mrjay has joined #linux-rockchip
<mrjay>
rockchip-dp ff970000.edp: no DP phy configured
<mrjay>
anyone getting this on linux-next with pinebook pro?
<mrjay>
i have no display on pbp
kaspter has quit [Quit: kaspter]
kaspter has joined #linux-rockchip
mrjay has quit [Ping timeout: 240 seconds]
robmur01_ has joined #linux-rockchip
robmur01_1 has joined #linux-rockchip
<nomis>
ok. adding that "rockchip"-Directory seems to have messed with the image generation recipe.
<nomis>
in rockchip-gpt-img.bbclass a mcopy fails due to "Bad target ::rockchip/rk3328-evb.dtb"
robmur01 has quit [Ping timeout: 260 seconds]
robmur01_1 is now known as robmur01
robmur01_ has quit [Ping timeout: 256 seconds]
<nomis>
(more specifically: "::rockchip/rk3328-evb.dtb: no match for target")
<JPEW>
nomis: Use wic, it's much better than rockchip-gpt-img.bbclass
<JPEW>
nomis: Also, fitImages make it a little easier to get the correct DTB :)
<nomis>
JPEW: ok, will figure out how to use wic...
<nomis>
JPEW: what is "fitImages"?
<JPEW>
I probably won't do the description justice, but is's a container format that packages kernel, DTB, initrd into a single file
chiastre has quit [Ping timeout: 240 seconds]
<nomis>
hrm. It would be really helpful to me to have a machine-config example file that uses all of the modern stuff... :)
<nomis>
(for rk3328)
<JPEW>
nomis: I think you're best bet would be to start with the rock-pi-4 (rk3399)
<JPEW>
I just wrote that one a few months ago
<nomis>
JPEW: thanks, will stare at it. :)
<nomis>
JPEW: what are these "ATF_"-Variables in rk3399.inc ?
<JPEW>
Those instruct it how to build the Arm-Trusted-Firmware
chiastre has joined #linux-rockchip
<nomis>
ah, that is for the "small" cores of the 3399 that the 3328 does not have, right?
<JPEW>
No, ATF is a security layer that runs above the kernel on aarch64.... controls access to keys and such
<JPEW>
I don't know a whole lot about what it does specifically, but it's required to boot
<nomis>
ah ok.
<nomis>
thank you.
<JPEW>
The rk3328 does have ATF, but it looks like all you'll need to do is set ATF_PLATFORM ?= "rk3328"
<mps>
hmm, mrjay is left, but I also have this 'rockchip-dp ff970000.edp: no DP phy configured'
<mps>
but my display works although with some quirks
<robmur01>
nomis, JPEW: the short short version from a kernel perspective is that ATF is what does all the low-level stuff in booting secondary CPUs, system suspend/shutdown, etc.
vagrantc has joined #linux-rockchip
<nomis>
robmur01: ah, thank you.
camus1 has joined #linux-rockchip
kaspter has quit [Ping timeout: 258 seconds]
camus1 is now known as kaspter
vicencb has joined #linux-rockchip
klokken has joined #linux-rockchip
<nomis>
ok, at least it seems that some code gets executed now. However, it is not working good.
<nomis>
I get a "col error" and a "data training error". But then booting stops. I don't see any U-Boot message or any USB-Maskrom/Loader-functionality
<nomis>
the last lines are:
<nomis>
DDR3, 333MHz
<nomis>
BW=16 Col=12 Bk=8 CS0 Row=16 CS=1 Die BW=8 Size=4096MB
<robmur01>
looks like the initial loader doesn't like your RAM - is your u-boot build using a miniloader binary or SPL?
<nomis>
robmur01: I am unsure. Do I control this from the machine-config? via which variables?
vicencb has quit [Quit: Leaving.]
<robmur01>
assuming there's some sort of u-boot package, I'd look at which artefacts that picks from a successful build
<robmur01>
that said, if the initial loader output doesn't say something like "U-Boot SPL" (or TPL) then it's a fair bet you're using the miniloader
<nomis>
robmur01: do you have any insights what considerations are important for the two approaches (miniloader vs. SPL) ?
<nomis>
I read the boot process page in the rochchip wiki, but that was just not very clear to me.
<nomis>
miniloader somehow involves the trust partition, but beyond that...
<vagrantc>
on supported platforms, you can use mainline u-boot and ATF/arm-trusted-firmware/trusted-firmware-a without using the binaries from rockchip
<nomis>
vagrantc: thata sounds preferrable to me. Is that the "SPL" approach?
<vagrantc>
TPL+SPL these days, but yeah
<vagrantc>
TPL loads SPL which loads u-boot/ATF
<vagrantc>
ish
<robmur01>
the main thing is that u-boot's DDR code doesn't necessarily support all DRAM configurations that the latest miniloader does, but I think for RK3328 it's fairly mature these days, and certainly works OK for my DDR3 box
<nomis>
this is the output from "my" loader: BW=16 Col=12 Bk=8 CS0 Row=16 CS=1 Die BW=8 Size=4096MB
<robmur01>
at worst you could extract the miniloader from your box's original Android firmware and bodge that in to the current flow
<nomis>
and this is from a working loader I've uploaded via USB: th=32 Col=11 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=4096MB
<nomis>
the "Die Bus-Width" seems different. That feels wrong.
<robmur01>
or try switching the flow (i.e. have the build use the idbloader.img + u-boot.itb artefacts instead)
<nomis>
(not sure if "BW=16" and "th=32" refer to the same underlying value)
<robmur01>
there's a slight technical difference between the order and way in which the various images are loaded between the two flows, but you don't really need to care about it. Only that with the SPL flow there's no separate trust.img to flash.
<robmur01>
yeah, could be that your build has some old binary that doesn't know how to read those particular chips correctly
<nomis>
robmur01: are you familiar with yocto? Where would I find the reference to the binary that is actually embedded into the final image?
<robmur01>
sorry, my knowledge stops at ATF/u-boot/kernel's own build process and how to flash stuff manually :)
<robmur01>
and these days I trust it all enough to use the "build natively and install with dd, over ssh" approach
<nomis>
oh nice. :)
<robmur01>
I have RK3288, RK3328 and RK3399 boxes/boards here all running full-mainline firmware stacks now :D
<nomis>
robmur01: do you mind if I bother you with more questions in the next few days?
<nomis>
(I'll try to be smart about my questions :)
vicencb has joined #linux-rockchip
<robmur01>
can't guarantee I'll be helpful, but I can always *try* - people often mistake my "look at stuff I've never seen before and infer a guess" approach for actual understanding ;)
<nomis>
heh, ok.
<nomis>
right now I am fighting at two sides: on one side there is the rockchip boot process with tons of obscure (to me) terminology and on the other hand there is yocto with a quite involved and also partially obscure (to me) build process.
field^Zzz2 has joined #linux-rockchip
<nomis>
anyway. Thanks all for all your help, I guess I'll pop up again tomorrow :)
<robmur01>
yeah, the legacy BSP/Android boot process is a bit of a nightmare - I was there 3-4 years ago with my first RK3288...
<JPEW>
nomis: Can you shared your machine conf?
<JPEW>
I can provide a little help with the Yocto side of things
<nomis>
this is my own layer where I've tried to collect the stuff that bitbake complained about being missing when I tried to compile it.
<nomis>
(esp. the stuff in include)
<nomis>
I tried roughly to follow your rk3399 example.
<nomis>
my external yocto-layers are all on dunfell.
<JPEW>
nomis, robmur01: OK. The rk3399 builds idbloader.img from u-boot as the SPL, which then needs to be copied to the "loader1" partition on the disk
<nomis>
idbloader is the non-proprietary stuff, correct?
<JPEW>
It pulls the ATF into the u-boot build by passing the BL31=... argument when invoking `make`
<JPEW>
Correct... I don't know for 100% sure, but I didn't think there were any proprietary parts
<nomis>
I have ATF_PLATFORM ?= "rk3328", ATF_TARGET ?= "bl31" and ATF_SUFFIX ?= "elf"
<nomis>
where the PLATFORM originated by search&replace from your 3399 :)
<JPEW>
Make sure you get the changes in u-boot%.bbappend to tell u-boot to pull in ATF
<JPEW>
duplicate the two rk3399 lines and replace with rk3328
<JPEW>
nomis: Also, if you want panfrost graphics support, do the same thing for the line in mesa_%.bbappend :)
<nomis>
ah! good point.
<nomis>
graphics is not high priority at the moment. But yeah.
<JPEW>
Oh, and also change DEFAULTTUNE ?= "cortexa53-crypto" and the matching require line below it, since it's not big.LITTLE
<JPEW>
And SOC_FAMILY :)
<nomis>
JPEW: do I have to adjust the name "do_compile_append_rock2-square" to my machine name?
<JPEW>
No, that one applies to the rock2-square machine, not yours (or the rk3399)
<nomis>
ok.
<nomis>
JPEW: I have SOC_FAMILY = "rk3328" and DEFAULTTUNE ?= "cortexa53-crypto" - are you saying this is wrong?
<JPEW>
That looks correct
<nomis>
I think I got the tune-cortexa53.inc-file from some patch on a mailinglist. That might have all sorts of crimes in it though.
adjtm has quit [Remote host closed the connection]
<JPEW>
Should be in oe-core (poky) already
adjtm has joined #linux-rockchip
<JPEW>
It was added in 2019
<nomis>
ah! there!
<nomis>
yeah, I might have added these files before switching to dunfell.
<JPEW>
Ah
<JPEW>
You should make your changes in meta-rockchip then upstream them ;)
<nomis>
will do so gladly if that stuff works.
tuxd3v has joined #linux-rockchip
<nomis>
Building U-Boot fails. Apparently it is missing a "bl31.elf" file:
<nomis>
FileNotFoundError: [Errno 2] No such file or directory: '/home/simon/yocto-becker/BSP/build/tmp/deploy/images/becker-cc41/bl31.elf'
<tuxd3v>
vagrantc, I don't thibk my partition scheme is wrong..
<nomis>
(I suspect that this is the same as earlier, I just missed the "U-Boot" message because maybe the serial port was not set up fast enough after a power cycle
tuxd3v has quit [Remote host closed the connection]
<JPEW>
nomis: I'm not sure how that all works, but do you need a different defconfig for u-boot?
<nomis>
JPEW: maybe. I don't have an original rk3328-evb here.
<nomis>
it also is possible that tty2 is wrong for the console and some output gets written into a nirvana.
<nomis>
robmur01: it might be helpful for me if you could provide me with a dump of the boot/u-boot partitions of your rk3328-box. I then could try if this works for me and then try to understand how to reproduce your build process in yocto.
<nomis>
the hardware I am working on is an enybox "a5x" tv box btw.
<robmur01>
FWIW my u-boot is just straight mainline, so I'd fully expect it to do exactly the same thing
<robmur01>
it does look a lot like the u-boot DDR code can't cope with whatever chips you have, thus things just die when it tries to transfer to SPL and DRAM just isn't there
<nomis>
originally there was an 2017-uboot on the device which seemed to be able to cope. Unless a miniloader-based approach would shift the ddr-init stuff towards the miniloader.
tuxd3v has joined #linux-rockchip
<tuxd3v>
vagrantc, yeah it sounds right but still on TPL
<robmur01>
nomis: you can still use mainline u-boot.img with the miniloader, to have sane booting instead of the partitions.txt Android crap
<robmur01>
what I'm not sure about is how to package ATF to work with that flow
<robmur01>
easiest is to use ATF binaries from rkbin, but beware that they tend to include OP-TEE as a secure-world payload, which might still require DT hacks to work around the secure memory reservation
<nomis>
robmur01: I actually would prefer to have this as easy as possible, which to me at the moment sounds like "avoid proprietary stuff".
<damex>
robmur01: can't you just build atf from official sources?
<nomis>
the whole miniloader/trust/tee/whatever stuff feels quite overcomplicated.
<robmur01>
damex: sure you can build it, but I suspect it needs to be wrapped in a special image header for the miniloader to recognise it
<nomis>
robmur01: wait, isn't miniloader what should be replaced by the uboot-tpl/bl31.elf?
<nomis>
or do you refer to the rom-bootloader as "miniloader"?
<robmur01>
TPL replaces the miniloader, but unfortunately if the TPL can't cope with your RAM you're backed into a corner :(
<robmur01>
bl31.elf is the mainline counterpart of the "rktrust" binary
<nomis>
(what does "TPL" stand for btw.?)
<robmur01>
I think it's "trusted program loader"
<nomis>
ah, ok.
<nomis>
I was thinking "tertiary program loader" and was confused about the order of things. :)
<robmur01>
(originally there was the "secure program loader" that did all the DDR init and secure stuff, before handing off to the non-secure main stage, but than it started getting too big so they had to invent a new even earlier stage for DDR init, and bump the SPL into running from DRAM)