afaerber has quit [Remote host closed the connection]
LongWork has quit [Ping timeout: 248 seconds]
LongWork has joined #linux-rockchip
vagrantc has joined #linux-rockchip
nasuga has quit [Ping timeout: 240 seconds]
aalm has quit [Quit: xyz 1.9]
BenG83 has joined #linux-rockchip
kloczek has joined #linux-rockchip
nasuga has joined #linux-rockchip
LargePrime has quit [Remote host closed the connection]
<topi`>
anyone got the Firefly-RK3399?
<topi`>
is it worth acquiring? I mean, can I run mainline on it and does it support most of the HW interfaces (we can forget 3D)
<topi`>
the rk3399 looks a really solid chip from Rockchip
<Ke>
what is your purpose
<Ke>
I think someone just testified that linux-4.14-rc1 had broken frequency scaling and you are stuck with 200MHz on the a72 cores
<topi`>
build a server afarm
<topi`>
:)
<topi`>
I'm thinking of designing a mainboard that can accommodate 4x Firefly-RK3399 Core SOMs each with their own ethernet. Shared power lines.
<topi`>
(reset lines not shared ;)
<vagrantc>
well, 4.14-rc1 *does* do frequency scaling on the a53 cores, which is better than before
<vagrantc>
topi`: mainline support is coming along for the firefly-rk3399, but still in development
<topi`>
vagrantc: it's not the first time there has been regressions with DFVS stuff :)
phinxy has joined #linux-rockchip
phinxy has quit [Changing host]
phinxy has joined #linux-rockchip
<Ke>
my grievance is that the board is very brickable contrary to firefly's docs, the hw disable for the emmc is absurdly bad, but that would not be your problem
<topi`>
how can you brick it? I thought you could always boot the RK3399 in maskrom mode?
<vagrantc>
if it allowed reading from the microSD before the eMMC ... that would be a good start
<Ke>
that's the hw disable for emmc
<topi`>
ah... I see a potential problem there :)
<vagrantc>
if it works well enough that it doesn't enter maskrom mode
<Ke>
anyway, you can zero the emmc and always boot from the SD
<topi`>
this is something I tried to do with the batch of Hummingboards we have
<vagrantc>
had the same issue with the firefly-rk3288 a while back, too
<topi`>
I could not disable the eMMC so it would always boot from the invalid bootloader.
<vagrantc>
Ke: if you trust that you have a working microSD ...
<Ke>
also you can always backup boot, if you get a spi flash
<vagrantc>
there's a bit of a leap of faith there...
<Ke>
vagrantc: I don't get what you mean?
<topi`>
too many microSDs are crappy
<topi`>
I think SPI flash would be the most reliable way to boot
<vagrantc>
Ke: if you disable the eMMC, you have no way of testing that it will boot until you've already disabled eMMC
<topi`>
and there is usually enough flash to hold the entire UBOOT
<vagrantc>
Ke: so it's a leap of faith to wipe the eMMC
<topi`>
let's see, what other options do I have? RK3399 is one of the very few easily available chips that has decently fast cores *and* working PCIe
<topi`>
the Qualcomm stuff I skip, overpriced and probably difficult to get TRMs
<beeble>
topi`: i could recommend you a rk3399 som that has a emmc disable pin on it's edge connector
<beeble>
but also spi nor
<beeble>
if you are looking for that
<topi`>
I would skip the eMMC and mount all filesystems using network block devices (nbd)
<beeble>
however you like it, you can disable the boot source :)
<topi`>
but at some point probably the most expensive part will be providing enough network bandwidth for such a cluster
<topi`>
I have all these crazy ideas in my head
<topi`>
but I've always wanted to start my own business, the crazier the idea the better
<vagrantc>
speaking of working pcie, i don't see anything on the pci bus ... but that might just be a misconfiguration on my part
<beeble>
pcie is working with mainline
<beeble>
i can verify that
<vagrantc>
built as a module or built-in?
<beeble>
built-in
* vagrantc
always builds modular configs, so that it can be pushed to debian
<Ke>
topi`: also rk3288 had broken virtualization, not sure if that is some rockchip thing
<topi`>
Ke: it's difficult to get it right ;) do you mean it could not enter hypervisor mode at all?
<Ke>
open source boot on rk3399 was reported to be limited to 2G of RAM also or something
<Ke>
or perhaps just u-boot boot
<topi`>
oh, that's a terrible limit. 4G should be the standard ram these days
<vagrantc>
beeble: which kernel configuration options does it use?
<Ke>
topi`: I wouldn't worry about that raminit, unless you are really in hurry
<topi`>
compile any modern C++ project these days, and you'll see why 2G is not enough
<beeble>
vagrantc: but i run into some gen2 5gb issue. but have to look into that and hadn't time yet
<Ke>
I think actually there is opensource raminit for rk3399, as there is libre boot for chromebook kevin
<vagrantc>
i've got 4gb of ram working on the firefly-rk3399 using mainline u-boot 2017.09
<beeble>
vagrantc: CONFIG_PCIE_ROCKCHIP
<Ke>
vagrantc: direct u-boot without the mini-bootloader thing=?
<beeble>
Ke: miniloader is closed source. but uboot ram init does not really have any limit except that it was done for the hardware available at the moment
<beeble>
Ke: 4GB boards are in the pipeline, so support will pop up soon latest
<Ke>
anyway, afaik chromebooks have open source raminit
<Ke>
so there is code
<beeble>
it is really no issue. uboot has eveything and its a designware controller
<beeble>
just have to do it :)
<beeble>
there was just no pressure to do it for more then 2gb at the moment
<Ke>
I'd mostly love some knowledge on what format the soc botos etc
<Ke>
there seem to be only commands in example scripts, some of which are open source
<beeble>
mkimage supports boot image creation for rk3399
<beeble>
included in uboot
* vagrantc
really needs to test the u-boot SPL for firefly-rk3399
<Ke>
that is for the very first bootloader, right?
<vagrantc>
it's what initializes the ram if you don't use miniloader ... i think
* vagrantc
still doesn't understand what arm-trusted-firmware actually does
<beeble>
spl does dram init and loads uboot proper
<beeble>
(it does more hardware initalization actually but thats not that important)
<beeble>
it also loads the atf
<beeble>
and the cortex m0 firmware
<Ke>
beeble: is it just me, or did the bootup complexity go one rocket science up from arm32?
<beeble>
Ke: so just look at uboot. rk3399 is blob free except mali
<Ke>
yes, yes
<beeble>
it got a bit more complex due the execution levels
<Ke>
they do still refer to blobs in docs though, I guess it's moderately reasonablo workaround to help paople...