<hexdump01>
jenneron[m]: yes i have a acer tab 10 = scarlet and did try to get it working recently to some degree, the others i know are asus c101p = bob and samsung chromebook plus xe513c24 = kevin
hexdump01 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #linux-cros-arm
<jenneron[m]>
hexdump01: please send me an output of `cat /proc/device-tree/compatible` from that acer tablet
<hexdump0815>
the asus ct100 seems to be quite rare and the aopen and ctl one from your list i have never heared of - i guess they are us only ... in general back then many of the chromebooks seem to not have reached europe, at max uk maybe
<hexdump0815>
will send you the ooutput in the next days
<hexdump0815>
but in general the scarlet mainline dts is working quite well, so you should be able to get all info from there
<hexdump0815>
to me it looks like rk3399 and rk3288 are a bit similar from the way they were merketed: there are a few major branded ones like speedy and minnie and a lot of white label ones like medion and many more all running as jaq or mighty - i guess all the other rk3399 are maybe only one model from compatible perspective
<jenneron[m]>
hexdump0815: as i've already mentioned, we don't have an infrastructure for shared ports so far, so i have to use one dtb per device port, but with scarlet dts:es it is not clear which dts corresponds to which codename
<jenneron[m]>
hexdump0815: we have 3 codenames and 3 dts:es, so i guess that one dts is one codename
<jenneron[m]>
one of those codenames (druwl) is for 2 tablets, so we have 4 tablets
<hexdump0815>
maybe there are even multiple - also with kukui for instance you sometimes have a few revisions per device with slightly different hardware it seems from the dtbs - and i think some users already had different revs when using my images, so it looks the revs really exist
<jenneron[m]>
well, for now pmbootstrap asks to select a revision
<hexdump0815>
then i guess drowl is the white label one for ctl, aopen and all others we do not know yet maybe
<hexdump0815>
the way i handle it for my images so far is to provide all systems with a dts in mainline and wait for people to complain if something does not work - so for pmosyou might create dummy systems for all available dts and just mark the ones not yet tested as so ... what usually comes up is sound, display, touchscreen or touchpad not working everything else is usually the same for one family
<hexdump0815>
i recently even noticed that there are dts on the mediatek list for kukui systems which were never mainlined but seem to exist in the real world - most probably just forgotten :)
<hexdump0815>
forgotten to pickup from the list i mean
<alpernebbi>
the general form is google,<codename>(-rev<X>)(-sku<Y>)
<alpernebbi>
but weirdly some boards can have the baseboard as the codename in compatible
<alpernebbi>
if depthcharge can't find the full "google,<codename>-revX-skuY" form, it falls back to "google,<codename>-skuY" then finally to "google,<codename>"
<alpernebbi>
so for example dumo is "google,scarlet-sku0", druwl is "google,scarlet-sku2" or "google,scarlet-sku3" depending on idk
<alpernebbi>
but all will accept "google,scarlet" if there's nothing more specific