02:55 <levd> In order to bring rockusb to rk3399, I test the firefly-rk3288 board which rockusb is claimed to support. But I had a problem. The TF card is stuck at SPL after showing: "U-Boot SPL 2019.10 (Oct 15 2019 - 02:43:47 +0000)".

02:56 <levd> I'm using Gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3) in Ubuntu 18.04. Build with the following commands according to the U-Boot doc/README.rockchip:

02:56 <levd> export CROSS_COMPILE=arm-linux-gnueabi-

02:56 <levd> make firefly-rk3288_defconfig

02:56 <levd> make -j8

02:56 <levd> tools/mkimage -n rk3288 -T rksd -d spl/u-boot-spl-dtb.bin out

02:57 <levd> And flashed with "sudo dd if=out of=/dev/sdc seek=64 && sudo dd if=u-boot-dtb.img of=/dev/sdc seek=16384".

02:57 <levd> kevery: this is likely a regression?

03:00 <levd> I've had the emmc erased. Without the TF card, the board enters into MaskRom mode.

03:04 <kevery> Maybe because of the pinctrl driver, you can enable the DEBUG for SPL to get more detail

03:04 <levd> i also tried the toolchain of gcc-linaro-6.3.1-2017.05-x86_64_arm-linux-gnueabihf, with the same result.

03:10 <kevery> I didn't try with sdcard recently, I only try with EMMC and it works OK.

03:11 <kevery> This issue should be nothing to do with toolchain.

03:19 <levd> kevery: would you plz post your commands with EMMC?

03:20 <levd> I turn on DEBUG in pinctrl-rockchip-core.c, which results that the size of spl/u-boot-spl-dtb.bin is increased to 32864 bytes, not bootable :(

03:20 <levd> the 32K bytes limit of spl

03:28 <kevery> The build command for emmc is no difference with sdcard, they share the same firmware.

03:35 <levd> But it's confusing in doc/README.rockchip.

03:36 <levd> In the chapter "Booting from an SD card on RK3288 with TPL", there're actually no commands for generating the idbloader.img for rk3288.

03:40 <levd> The emmc flashing instructions in that doc are using `rkflashtool l`, which is stuck after showing the "U-BOOT SPL...".

04:25 <anarsoul> what's the status for rk3399 hdmi support in u-boot?

04:25 <anarsoul> I see that driver is there but it doesn't work for me on rockpro64

04:25 <anarsoul> looks like it's not even probed

06:15 <EmilKarlson> do you have that blob, which I believe that it required

06:15 <EmilKarlson> I have no idea, if that would help, but I believe it's not optional for hdmi

07:20 <levd> kevery: after git bisect, i found that after this commit "[d18ca747b6264289579fbeb778f299eb03e479ed] rockchip: rk3288: enable TPL configs to chip level", the firefly-rk3399 no longer boots. Before that commit, it is okay with tf card booting.

07:20 <levd> oh no, typo, s/firefly-rk3399/firefly-rk3288

07:23 <levd> my test commands: make clean && make firefly-rk3288_defconfig && make CC="ccache ${CROSS_COMPILE}gcc" -j8 && tools/mkimage -n rk3288 -T rksd -d spl/u-boot-spl-dtb.bin out && cat u-boot-dtb.bin >>out && sudo dd if=out of=/dev/sdc seek=64 && sudo dd if=u-boot-dtb.img of=/dev/sdc seek=16384

07:24 <levd> previously i left out an import step of "cat u-boot-dtb.bin >>out"

07:24 <kevery> levd: This patch is to make TPL available for all rk3288 board, suppose to not affect those board not enabled.

07:25 <kevery> I would prefer to enable TPL for all the boards so that we don't limit by the size of IRAM, and easier to debug.

07:43 <levd> kevery: i tried to turn on TPL like tinker board, with patch at http://ix.io/1YHT , but got result of not being able to reading mmc device:

07:43 <levd> U-Boot SPL 2019.10-dirty (Oct 15 2019 - 15:37:16 +0800)\n Trying to boot from MMC2\n mmc_load_image_raw_sector: mmc block read error\n Trying to boot from MMC1\n mmc_load_image_raw_sector: mmc block read error\n SPL: failed to boot from all boot devices\n ### ERROR ### Please RESET the board ###

08:14 <levd> rockusb & ums work like a charm in U-Boot v2019.04 on firefly-rk3288 board. What's lacking to support rockusb in rk3399? Any thoughts? kevery mmind00

08:16 <kevery> The rockusb driver on mainline and rockchip branch are different, so I'm not sure how many people are using mainline rockusb function.

08:21 <kevery> With below update, the firefly-rk3288 boots from emmc:

08:21 <kevery> https://paste.ubuntu.com/p/5J4s3wTVRB/

08:21 <kevery> If you are using SD card, then need to care about: IOMUX and power supply.

08:25 <levd> tks, i'll take a look.

08:44 <levd> strange, it hangs at "U-Boot SPL 2019.10-00014-g9d89161bba73-dirty (Oct 15 2019 - 16:40:13 +0800)\n Trying to boot from MMC2". I'm using the latest commit 9d89161bba733b2de65e49e17223af5bd4417bb0 in rockchip repository, applied with your patch, without any more modification.

08:46 <levd> compiled with: make firefly-rk3288_defconfig && make CC="ccache ${CROSS_COMPILE}gcc" -j8 all && ./tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin out && cat ./spl/u-boot-spl-dtb.bin >> out

08:46 <levd> flashed with: rkdeveloptool db rk3288_loader_v1.06.236.bin && rkdeveloptool wl 0x40 out && rkdeveloptool wl 0x4000 u-boot-dtb.img && rkdeveloptool rd

08:50 <levd> Now I see, idbloader.img is generated automatically if TPL and SPL is both y, which equals to the `out` above.

09:59 <paulk-leonov> hey there

09:59 <paulk-leonov> just built ATF for rk3399

10:00 <paulk-leonov> resulting binary is 4.3 GiB

10:00 <paulk-leonov> is it just me?

10:00 <paulk-leonov> or there's something seriously wrong happening here?

10:00 <paulk-leonov> the .elf is a few hundred KiBs

10:16 <paulk-leonov> nevermind, it's at https://github.com/ARM-software/arm-trusted-firmware/commit/33218d2a8143ef54684db529f1a8a5182e5a52f7

10:16 <paulk-leonov> my fault for not using master :p

18:57 <hanetzer> paulk-leonov: huh. so there were like huge empty spaces in the .bin file

19:39 <mmind00> hanetzer: yep which was caused by the sram code being in that bin file as well ... aka ddr-based atf at (then) 0x10000 + sram-atf-code at 0xff7c0000 (or somewhere in that area) ... so you end up with around 4GB of sparsely filled file

19:40 <mmind00> hanetzer: hence the move to not use that .bin anymore and only use the .elf that isn't affected by this

19:43 <anarsoul> mmind00: ping

19:43 <mmind00> anarsoul: hey

19:43 <anarsoul> mmind00: do you know what's the status for HDMI support for rk3399 in u-boot?

19:44 <anarsoul> driver seems to be there but device(s) is not even probed

19:44 <mmind00> anarsoul: no clue ... my u-boot needs generally end with it booting my tftp kernel ... but kevery may know [one woken up again ;-) ]

19:45 <mmind00> anarsoul: is it enabled in the dts used in your uboot?

19:45 <anarsoul> yes

19:46 <mmind00> anarsoul: Does "dm tree" list the device then?

19:46 <anarsoul> yes, but it's not probed

19:47 <anarsoul> both vops are here as well as rk3399-hdmi

19:51 <mmind00> anarsoul: from what I gathered from past hurdles, uboot seems to do some lazy probing ... like sdmmc causes clk-controller to probe, etc ... so I guess graphics might do this similarly

19:52 <anarsoul> maybe

19:52 <anarsoul> guess I'll have to debug it

23:39 <fALSO> sigmaris, i've been using your kernel branch ;-)

23:39 <fALSO> just updated to rc3, and works ok. I just gonna try to see if reboot already works ;-)

23:40 <fALSO> sigmaris, noticed hantro_vpu on dmesg, you have any idea on how to use it?

23:40 <fALSO> sigmaris, ffmpeg?

23:40 <fALSO> damn... idle 4 days :-(