nighty- has quit [Quit: Disappears in a puff of smoke]
LargePrime has joined #linux-rockchip
vstehle has quit [Ping timeout: 240 seconds]
nighty- has joined #linux-rockchip
lurchi_ is now known as lurchi__
hgs has left #linux-rockchip [#linux-rockchip]
<vagrantc>
hrm. tried ayufan's rock64 u-boot patches ... but aarch64-linux-gnu-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region `.sram'
<vagrantc>
aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 184 bytes
<vagrantc>
would really need to trim that down to handle inevitable growth
vagrantc has quit [Quit: leaving]
cnxsoft has joined #linux-rockchip
agusan has quit [Ping timeout: 240 seconds]
LargePrime has quit [Remote host closed the connection]
<mfny>
anyone here ?
<stdint>
Why not just said your problem not ask
<stdint>
it is the basic rule of a irc channel
<mfny>
i dont have a particular problem, im just looking for advise
<adj_>
mfny, remove the sugar from your diet
fysa has quit [Remote host closed the connection]
nots has quit [Quit: Page closed]
fysa has joined #linux-rockchip
<mfny>
there are alot of rockchip SBCs out there im trying to figure out which are the good vendors and which are the not so good
<mfny>
for eample t-firefly, librecomputer,96boards ... and so on
<stdint>
next time, just leave you message, there are people from different timezone
<mfny>
in particular im looking at RK3399 boards
<buZz>
i dont think 3399 is that well supported yet
<mfny>
yea its a bit early days but still, so many vendors are making boards its hard to choose
<adj_>
mfny, maybe more important than the vendor is how well supported is in mainline linux
<adj_>
I mean the kernel
<mfny>
well true, but a good vendor will work around any issues like that id think by rolling their own
<mfny>
also alot of these places are shall we say not great with documenation
<lvrp16>
mfny: the roc-rk3399-pc is a collaboration between firefly and librecomputer so it is one in the same. the firefly guys built the first RK3399 development platform on the market two years ago so they are the most experienced in terms of the rockchip bsp.
<Pix>
yeah can't wait for july to order one :)
<Pix>
a ddr4 design too
<buZz>
:) i hope for a nice 3399 with proper mainline support, gbit, M2 NVMe slot, and a bunch of gpio :)
matthias_bgg has joined #linux-rockchip
BenG83 has quit [Ping timeout: 260 seconds]
<lvrp16>
buZz: there's a mezz for renegade elite with m.2 m-key pci-e x4 with wifi and PoE
<buZz>
one of the searx hits on 'mezz for renegade elite' is List of ethnic slurs - Wikipedia
<buZz>
in other words, what?
<lvrp16>
mezz = mezzanine
<buZz>
ah, thats a 96boards form factor?
<buZz>
whats 'renegade elite' then?
<lvrp16>
no
<lvrp16>
HAT/mezzanine board
<lvrp16>
whatever you want to call those things
<buZz>
a SBC?
<buZz>
ah 'renegade elite' is some libre.computer thing?
<Pix>
it's the upcoming 3399 board
<buZz>
ah, well cute
<buZz>
i dno why libre.computer doesnt just follow 96boards standards though
<Pix>
maybe they don't have manpower to change an existing board layout they did a while ago
<buZz>
but they only started producing 2 years ago or something
<buZz>
way after 96boards established
<Pix>
ah!
<lvrp16>
96boards spec is a little restrictive
<lvrp16>
also the requirements are a little weird
<buZz>
still , standard port placing and formfactor is -extremely- welcome in ARM SBC land
<lvrp16>
libre computer boards are all standardized, to their own spec ;)
<buZz>
yeah thats sad :)
<lvrp16>
96boards ports aren't standard either
<lvrp16>
look at hikey 970
<lvrp16>
hikey and hikey 960 had different ports
<lvrp16>
the pcie ports go all over the place
<buZz>
indeed
<buZz>
i ment external connectors
<lvrp16>
so 96boards is both restrictive and non-standardized
<wens>
IIRC the standard only says the ports should be on which side, and what connectors are mandated. Nothing about layout
<lvrp16>
M.2 is a very important connector...
<buZz>
lvrp16: its standardized to certain parameters
<buZz>
it does allow usage of cases on >1 board :P
<buZz>
from >1 manufacture
<buZz>
+r
<lvrp16>
on Mediatek X20, the PCIE goes one way, on HiKey 960 they go another way, on HiKey 970 it's in a completely different position altogether XD
<lvrp16>
*facepalm*
yann has joined #linux-rockchip
<buZz>
tbh , PCIe on ARM is mostly just a fascination atm :P
<buZz>
most implementations cant be used with stuff like a GPU
<lvrp16>
some boards have MicroUSB, some have Type C
<lvrp16>
some boards have HDMI upside down
<buZz>
on the same position though
<buZz>
upside down is hella annoying yeah
<lvrp16>
yeah except you can't have the same case...so all points
<buZz>
lvrp16: i get you're now defending your employer? :D
<lvrp16>
no, i love linaro and the goal
<buZz>
or i dont understand why you'd attack this so much :P
<lvrp16>
the execution was terrible
<buZz>
what would be better then? keep making 'raspi compatible boards' , even though none really are? :P
<lvrp16>
linaro did great things for arm, arm wouldn't be where it is now without linaro
<buZz>
we wouldnt even be considering using PCIe on ARM without them ;)
<lvrp16>
dude, i'm just giving flak where flak is deserved, compliments where it is deserved
<lvrp16>
i'm not bias towards any organization be it rpi, 96boards, or libre computers. but to put out a spec and not enforce it is self-defeating.
<lvrp16>
i know linaro's not in a place where it can force silicon vendors to do things a certain way so it's not completely their fault
<lvrp16>
so i stand by my original point: 96boards spec is a little restrictive
<buZz>
how would you want them to enforce it? :P
<buZz>
call the SBCpolice?
<lvrp16>
haha thats the tricky part
<lvrp16>
if they spec'ed something slightly bigger that provides more flexibility and forward thinking
BenG83 has joined #linux-rockchip
<lvrp16>
i think both ngff and type c were announced then
<lvrp16>
rock960 is a 10/12 layer board?
<lvrp16>
thank god hikey 960 had pop dram
<lvrp16>
otherwise that thing would never fit
<lvrp16>
and no ethernet port???
<buZz>
horrible :D
<buZz>
i wish ppl would just stop buying android phones
<buZz>
then maybe we could get some better socs targetted for actual computers
<Pix>
:)
<buZz>
Pix: right? what serious arm socs do you know
<buZz>
cavium, amd (although i think they stopped making them?), .. nothing else? :)
aalm has joined #linux-rockchip
<lvrp16>
Kirin 960 could have done some real damage to Intel and AMD's bottom line but Huawei doesn't sell chips
<lvrp16>
and HiKey 960 doesn't have ethernet
<lvrp16>
It could have easily been a high density replacement for four core Intel and AMD chips used by datacenters for web frontends where the systems are interrupt limited
<Pix>
buZz, broadcom ? :)
<Pix>
i'm reading their roadmap
<buZz>
Pix: made me lol irl
<gab>
Pix: meh :p
<buZz>
this whole raspberry pi thing to begin with is starting to feel a whole lot like 'we accidentally produced xxxxx of this shitchip, plz buy nao'
<beeble>
apm/ampere
<wens>
:p
<gab>
yeah
<gab>
if they really cared about open stuff, rpi would be less ridiculously underpowered
<gab>
doesn't even come close to what they put in their mid-range closed chips
stdint has quit [Ping timeout: 240 seconds]
<buZz>
gab: or less IO impared
stdint has joined #linux-rockchip
BenG83 has quit [Quit: Leaving]
LargePrime has joined #linux-rockchip
<mfny>
morning all
<mfny>
lvrp16: ah so t-firefly would theoretically be the best/most mature vendor for something rk3399 ?
<lvrp16>
between hardkernel, pine, and friendlyarm: yes
<lvrp16>
they specialize in rockchip solutions
<mfny>
lvrp16: right, well that helps narrow things down a bit thanks
<lvrp16>
mfny: my rule of thumb, go with pine if you are targeting third world market where pennies matter, friendlyarm is middle of the road, hardkernel and firefly as highly reliable solutions
<lvrp16>
you basically pay for the number 9's in reliability
<lvrp16>
most rk3399 are 1.8ghz, theobroma sources 2.0ghz chips
<mfny>
this is for hobbist use only and i have a budget of about $150 ish at most
<mfny>
t-firefly have 2 boards .. the AIO-3399J and the Firefly-RK3399
<mfny>
which one would be most suitable ? the AIO seems to have alot more IO for the money ..
<lvrp16>
what's your application?
<lvrp16>
for hobbyist, rk3399 is better. If you are developing a solution using their som for a product, aio-3399j is better
xerpi has quit [Quit: Leaving]
<mfny>
oh wait the AIO has no GPIO
<mfny>
so that makes the Firefly-RK3399 the only choice i guess
<mfny>
lvrp16: no particular application as yet, more a general tinkerer
<lvrp16>
mfny: the difference between firefly rk3399 and all the other boards being released is that it uses ddr3 which already has all the initialization code upstream
<lvrp16>
lpddr4 is only tuned on the rockchip sdk afaik
<mfny>
lvrp16: ah so the firefly has slower ram but as a result has better linux support ?
<lvrp16>
firefly rk3399 is a 2 year old model when only ddr3 support was available
<lvrp16>
bandwidth wise, it should be better than lpddr4 until lpddr4 gets tuned to its max performance
<mfny>
ah
<mfny>
well i value maturity in products so guess that means the firefly should go to the top of the list
matthias_bgg has quit [Read error: Connection reset by peer]
matthias_bgg has joined #linux-rockchip
afaerber has quit [Quit: Leaving]
<ramcq>
buZz: one of the founders of RPI worked on the team at Broadcom who made the VideoCore chip, so it's unsurprising that he chose his own chip, and was able to secure a good price from Broadcom. :)
<gab>
that's not the point
<gab>
when you know bcm's lineup when it comes to proprietary/operator STBs, it appears clearly that the rpi's bcm SoCs are stripped down low-cost versions
<ramcq>
afaict the respins are intentional, to retain ecosystem compatibility
<ramcq>
an average RPI program uses a python module to access GPIOs, has the display controller draw some stuff on a plane above the X server, and writes into the config.txt file which is read by the firmware
<ramcq>
so like... the faster chips had to be very compatible with the original in order to not break the platform
<ramcq>
and - well - it works. 5m backwards/forwards compatible boards.
afaerber has joined #linux-rockchip
lurchi_ is now known as lurchi__
<mbakke>
I wonder if we still need to build icedtea with gcc-4 after the recent Java changes.
<adj_>
lvrp16, mfny the theobroma Q7 SOM also has ddr3
aalm has quit [Ping timeout: 265 seconds]
<mfny>
theobroma dont list prices on site so im gonna guess they are very expnesive
<beeble>
mfny: the kit is above your price target
<adj_>
probably, it's more a development platform for companies
<adj_>
I would guess that the Q7 module is not very expensive in volume, the development board not
cnxsoft has quit [Quit: cnxsoft]
<mfny>
speeaking of price target i may have to lower that.. so may take the 3399 out of the running... would firefly still be a god choice for lower rockchip device ?
<adj_>
mfny, if you want to lower it a lot more you have rock64 but based on rk3328
<mfny>
what about the firefly ROC-RK3328
<mfny>
?
<adj_>
I don't know anyone using it
<mfny>
hm EMMC is a standard connector right. i should be able to buy any EMMC and plug it in to the ROC-RK3328 ?
<asciilifeform>
mfny: i run a small cluster of rk3328-roc-cc boxes ( details re os etc in http://www.loper-os.org/?p=2295 ) , they work .
<asciilifeform>
never tried the emmc though.
<asciilifeform>
( i have'em booting from sd and then immediately mounting / from usb3 drive )
<mfny>
hm is there a RK3328 with built in EMMC, WIFI for a good price out there ?
<asciilifeform>
no idea ( rk3328-roc-cc does not have soldered-on emmc, it has a socket for it, you can buy different sizes iirc )
<asciilifeform>
it does have wifi, though i have not used it
xerpi has joined #linux-rockchip
xerpi has quit [Remote host closed the connection]
<mfny>
there is no wifi on the ROC ?
xerpi has joined #linux-rockchip
<asciilifeform>
there is. haven't had occasion to try it though.
<mfny>
all the specs im reading say there is no wifi at all just gb ethernet ?
<asciilifeform>
hm possibly the schematics threw me off , they mention wifi but seems to be unpopulated (?)
<mfny>
cant seem to find a RK3328 board with onboard wifi at all ...
<asciilifeform>
why does it absolutely have to be soldered down ? wifi usb dongle is quite compact
<mfny>
well i want to avoid the minefield of compatibility
<asciilifeform>
seems easier to do when you can plug in one of a million different chips, rather than where you're stuck with the board vendor's favourite
<asciilifeform>
buy e.g. atheros, and you're golden
<mfny>
yea i just dislike playing vendor/chipset roulette realy with wifi stuff
unics has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
vagrantc has joined #linux-rockchip
Easyfab has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 240 seconds]
tllim has joined #linux-rockchip
unics has left #linux-rockchip ["Leaving"]
yann has quit [Ping timeout: 268 seconds]
aalm has joined #linux-rockchip
Omegamoon has left #linux-rockchip [#linux-rockchip]
oleavr has joined #linux-rockchip
yann has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
xerpi has quit [Quit: Leaving]
LargePrime has quit [Ping timeout: 256 seconds]
anarsoul|2 has joined #linux-rockchip
LargePrime has joined #linux-rockchip
LargePrime has quit [Ping timeout: 248 seconds]
LargePrime has joined #linux-rockchip
hanetzer has quit [Remote host closed the connection]
<ezequielg>
mmind00: hm, why are rk3399.dtsi iommu nodes marked as disabled? i thought only controllers that could be present or not on a board should be disabled?
nots has joined #linux-rockchip
afaerber has quit [Quit: Leaving]
<mmind00>
ezequielg: good question ... same is true for vops ... but then again, if your board doesn't have any graphics usage you might not want the probe overhead
<mmind00>
ezequielg: so I guess history has it that we just enabled iommus with their respective users
<ezequielg>
mmind00: ok, i'll enable with vpu then.