<willmore>
The sunxi wiki doesn't make any mention of it.
<KotCzarny>
could be fel button
<KotCzarny>
or some generic gpio button that orange software reacts to
<willmore>
There's a FEL button next to it already. From reading the Orange Pi web site it looks like it triggers FEL to do a boot from USB?
<willmore>
Is that a thing?
<willmore>
Is there a boot order selection pin on the H3 that it could be effecting?
<willmore>
Steven says it's for writing the eMMC from USB.
<BenG83>
so it toggles u-boot UMS mode?
<willmore>
BenG83, that would make sense. So, it won't help you if the eMMC is totally dead, but if the uboot image is good, it can tell uboot to load from USB?
<BenG83>
something like that
<willmore>
Oh, no.
<willmore>
I see, it makes the board look like a storage device. That makes sense.
<BenG83>
it tells u-boot to expose the eMMC as UMS
<BenG83>
we use the same on the Pinebook prototypes atm
<willmore>
So, you don't put an image on a USB stick and plug it into the board, you hook the board to a PC and this makes it look like a flash drive.
<BenG83>
load u-boot with ums via FEL
<willmore>
BenG83, thanks!
<BenG83>
then write the eMMC via mass storage
<BenG83>
it´s just a guess willmore ;)
<KotCzarny>
beng83: it's from generic allwinner uboot or custom added?
<BenG83>
ayufan made a u-boot for the Pinebook with UMS
<BenG83>
not sure if that feature is in the BSP u-boot
<BenG83>
it´s probably just looking for the GPIO and then starting UMS mode?
chlorine has quit [Remote host closed the connection]
<willmore>
Seems likely.
<KotCzarny>
would be nice to have such thing on nand boards
<KotCzarny>
as emmc isnt hard to access from mainline
<willmore>
Sounds like a feature that the SPI booting version of uboot should have enabled.
lkcl has joined #linux-sunxi
ikmaak has quit [Ping timeout: 258 seconds]
ruben-ikmaak has joined #linux-sunxi
chlorine has joined #linux-sunxi
ruben-ikmaak is now known as ikmaak
msevwork has quit [Quit: Leaving]
raknaz[m] has quit [Ping timeout: 252 seconds]
wzyy2 has quit [Ping timeout: 268 seconds]
raknaz[m] has joined #linux-sunxi
<tkaiser>
willmore: If it doesn't have to fit into small SPI flash I prefer doing the same thing with USB mass storage gadget mode enabled in kernel (since magnitudes faster): https://github.com/zador-blood-stained/fel-mass-storage (currently only H3 supported though)
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #linux-sunxi
<ElBarto>
I don't know if the doc is wrong or if it's the u-boot code but it seems that the dram clock is set to the ddr clock (div = 1)
<willmore>
tkaiser, good point. For a 2MB flash, we're going to have to reply on uboot, but for a 16MB flash, the kernel would work better.
<willmore>
On the plus side, the host PC won't see much difference--other than performance.
techping has joined #linux-sunxi
<willmore>
Then again, we don't have a dedicated USB mass storeage button. Can you ask Steven for that? ;)
<KotCzarny>
willmore: start producing buttons?
<willmore>
Actually, a two pin header woudl be enough.
<KotCzarny>
gpio connectablle
<KotCzarny>
with big red 'EMERGENCY' painted on top
<willmore>
We wouldn't want to use the normal GPIO as who knows what the user will hang off of there. Don't want boards acting funny and then have it traced down to uboot being clever.
<willmore>
How about a two pin header that uses red plastic instead of black?
<MoeIcenowy>
I think USB storage mode will only be highly needed on a board with both SPI flash and eMMC
<willmore>
You supply the jumper.
<KotCzarny>
last time i asked here, for shorting gpio you should add tiny resistor
<MoeIcenowy>
P.S. In fact I want to send an installer to the board via FEL, then do the installation via HDMI/ttyS0/USB Serial Gadget
<willmore>
KotCzarny, there should be a resistor in the circuit, yes.
mkesper has joined #linux-sunxi
<willmore>
MoeIcenowy, good point. Mostly because if the eMMC gets messed up, the board is toast.
<willmore>
I want to net boot.
<mkesper>
Are hardkernel boards somehow supported? I've got a C1.
<tkaiser>
willmore: Don't understand this. All that's necessary is to enter FEL mode what happens then depends on the other side of the USB cables (see MoeIcenowy's answer). And apritzel has an example to turn a random GPIO/button into FEL button (power button on OPi PC2)
<KotCzarny>
mkesper: different soc?
<ssvb>
willmore: in fact SD card has higher boot priority than eMMC after all
<ssvb>
willmore: so if your eMMC is messed up, you can still recover the board
<mkesper>
KotCzarny: oops, you're right!
wzyy2 has joined #linux-sunxi
<ssvb>
a bit of confusion about the boot priority originated from Jide Remix Mini box, which has the secure eFUSE bit set and uses https://linux-sunxi.org/TOC0 format for the bootloader instead of old eGON.BT0
<ssvb>
so when we tried to boot eGON.BT0 bootloaders from the SD card, it ignored them and booted from eMMC
<ssvb>
having a hardware FEL button is still a very good idea because we don't need a special SD card for entering into the FEL mode in the case if eMMC is fubared
<willmore>
tkaiser, if we had a FEL button, then yes, MoeIcenowy's method would work. But, if we have SPI or eMMC with uboot on it and no FEL?
<willmore>
And, yes, SD card is always another way.
<willmore>
So, the arguement always boils down to 'put a FEL button on the board'.
<tkaiser>
willmore: As ssvb said, we can always use a special SD card image entering FEL mode (a necessity on boards like NanoPi Air or OPi PC+ to flash eMMC directly)
<willmore>
tkaiser, agreed.
<MoeIcenowy>
doesn't opis with eMMC have FEL button?
<ssvb>
willmore: if there is still a somewhat valid bootloader on the board, then it can check some GPIO button and enter FEL mode if it is pressed (a "software" FEL button)
<tkaiser>
willmore: But it's inconvenient and people forget about it and then complain that flashing doesn't work.
<ssvb>
willmore: apritzel suggested this idea a long time ago
<willmore>
ssvb, that's what the USB button would do, but more specifically it would go into mass storage mode and not FEL mode.
<willmore>
tkaiser, what's inconvenient?
<ssvb>
well, if the mass storage mode is preferable, then go for it
FergusL has quit [Ping timeout: 240 seconds]
<willmore>
ssvb, it's not necessarily so. It just came up in conversation that it was possible.
<tkaiser>
willmore: Having to flash the small 'enter FEL mode' SD card image. Approx 100 percent of Armbian users forget this with NanoPi Air ;) )
<willmore>
tkaiser, okay, agreed.
<KotCzarny>
i think vendors should print linux-sunxi.org url on boxes/boards
<willmore>
That little board has an eMMC and no FEL button, so you're in a bit of a bind.
<willmore>
KotCzarny, LOL. :)
<ssvb>
willmore: a software FEL button can solve this problem
<KotCzarny>
do we have a 'new user' page?
<KotCzarny>
i mean info/faq for new users
<ssvb>
one downside is that if the bootloader is completely broken, then the users will be very scared when this button does not work anymore
<ssvb>
they will think that the hardware is toasted
<KotCzarny>
ssvb, yay, cheap boards for sale!
<willmore>
ssvb, true, but that leads us back to the 'what GPIO do you use' and does that interfere with the users use of the GPIO headers.
<ssvb>
AFAIK the built-in buttons on the Orange Pi boards are GPIO buttons
<KotCzarny>
willmore, if you print manual for your product it would alll be there
<willmore>
KotCzarny, what the vendors should do is charge $1 more per board and send that money over to linux-sunxi and armbian. :)
<ssvb>
unless you desolder it, we know exactly which GPIO is that
<ssvb>
of course if you have the right bootloader flashed there in the first place
<willmore>
ssvb, I'm thinking of existing FEL button less boards. Which GPIO do you pick to make into the software FEL button?
<KotCzarny>
any availablle i guess
<willmore>
That's the trick. That depends on what the user does with it.
<KotCzarny>
and keep in mind when booted to os it can act as a regular gpio button
wzyy2 has joined #linux-sunxi
<ssvb>
I'm afraid that hooking home made GPIO buttons is a lot more challenging task for the inexperienced users than preparing a FEL sdcard
<KotCzarny>
so maybe one with irq
<willmore>
ssvb, I can see that.
<ssvb>
unless somebody is a hardware enthusiast and has no clue about software
<willmore>
So, we're back to 'every board should have a FEL button' or at least a header/solder pads, etc.
<willmore>
What about someone who buys a board and buys some pre made device that plugs into the GPIO?
<willmore>
Lots of people like that in the Rpi world.
<KotCzarny>
willmore, such things should be configurable per board/build
<KotCzarny>
it wont be enabled by defauallt in generic uboot
<KotCzarny>
in short, if you buy vendor board/product, it's os can have such feature, but dont expect it enablled in mainline
<KotCzarny>
s/it's/its/
<MoeIcenowy>
sent out some patches for H3 OTG
Mr__Anderson has joined #linux-sunxi
<MoeIcenowy>
seems that megous now do not push his patches to mainline at all...
<wens>
some people are happy just getting there systems to work, nothing wrong with that
<MoeIcenowy>
I reworked his H3 THS driver and sent it to ML
Ntemis has joined #linux-sunxi
<MoeIcenowy>
for H3 OTG I chose a better solution said by Hans de Goede so I didn't used his code
<wens>
MoeIcenowy: i just looked at your OTG patches and what concerns me is VBUS potentially being always on
<MoeIcenowy>
?
<wens>
see my reply on the mailing list
<wens>
MoeIcenowy: oh, and r40 docs are out, in case you didn't read the back log
<MoeIcenowy>
of course I got it
<MoeIcenowy>
not by back log
<MoeIcenowy>
but by github notice
tkaiser has left #linux-sunxi [#linux-sunxi]
tkaiser has joined #linux-sunxi
paulk-blaze has quit [Ping timeout: 268 seconds]
Wizzup has quit [Quit: leaving]
fkluknav has quit [Remote host closed the connection]
Wizzup has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
fkluknav has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
lemonzest has quit [Ping timeout: 264 seconds]
techping has quit [Ping timeout: 252 seconds]
sgteem has quit [Ping timeout: 260 seconds]
sgteem has joined #linux-sunxi
lemonzest has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
r1mikey has joined #linux-sunxi
chlorine_ has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
chlorine has joined #linux-sunxi
fkluknav has quit [Ping timeout: 252 seconds]
paulk-collins has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
Andy-D has joined #linux-sunxi
f0xx has quit [Ping timeout: 260 seconds]
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
fkluknav has joined #linux-sunxi
r1mikey has joined #linux-sunxi
fkluknav has quit [Ping timeout: 260 seconds]
raknaz[m] has quit [Ping timeout: 252 seconds]
leviathancn has quit [Remote host closed the connection]
iamfrankenstein has joined #linux-sunxi
<MoeIcenowy>
wens: for R_CCU what should I do?
<MoeIcenowy>
just push the current one for H3/A64 or wait for a more full one?
<Putti>
MoeIcenowy, can you link to the OTG patch?
* Putti
is interested
<MoeIcenowy>
just find it in the mailing archive of linux-arm-kernel.
<MoeIcenowy>
which version do you want? mine or megous'
<MoeIcenowy>
?
<Putti>
ah, ok, I wasn't sure which mailing list you were talking about, thanks
<MoeIcenowy>
mine does PHY auto re-routing (as their're two controllers for this USB port), but megous' seems to use only MUSB
fkluknav has joined #linux-sunxi
raknaz[m] has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
rookieone has quit [Ping timeout: 264 seconds]
<Putti>
MoeIcenowy, I was talking about your patch – found it.
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
chlorine has quit [Ping timeout: 268 seconds]
ibu[m] has quit [Read error: Connection reset by peer]
raknaz[m] has quit [Read error: Connection reset by peer]
rookieone has joined #linux-sunxi
Andy-D has quit [Ping timeout: 260 seconds]
<MoeIcenowy>
P.S. when will 4.11's merging window close?
r1mikey has joined #linux-sunxi
<mripard>
MoeIcenowy: next monday
<mripard>
MoeIcenowy: and can you *please* put cover letters for your series
<MoeIcenowy>
ok ;-)
<MoeIcenowy>
but is there any standard whether a patchset should have cover letter?
ibu[m] has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
r1mikey has joined #linux-sunxi
chlorine has joined #linux-sunxi
yann has quit [Ping timeout: 240 seconds]
fkluknav has quit [Remote host closed the connection]
chlorine has quit [Ping timeout: 240 seconds]
f0xx has joined #linux-sunxi
<mripard>
if there's more than one patch, have one
<MoeIcenowy>
In fact usually I cannot think want to write in cover letter ;-)
r1mikey has quit [Read error: Connection reset by peer]
r1mikey has joined #linux-sunxi
<KotCzarny>
moeicenowy: think of desscribing what are you sending, then write it there
<willmore>
"The following set of patches implements/fixes/enhances *blah* function to the *foo* subsystem."
r1mikey has quit [Remote host closed the connection]
r1mikey has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
r1mikey has joined #linux-sunxi
Mikey__ is now known as MikeyG
wzyy2 has quit [Ping timeout: 264 seconds]
r1mikey_ has joined #linux-sunxi
<mripard>
"this is needed for that, I chose that kind of implementation, the shortcomings are those, etc"
r1mikey_ has quit [Client Quit]
f0xx has quit [Ping timeout: 260 seconds]
f0xx has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
r1mikey has quit [Ping timeout: 264 seconds]
f0xx has quit [Ping timeout: 260 seconds]
<montjoie>
wens: for testing dwmac-sun8i on a83t, which one of your branch is the best ? still sun8i-a83t-mmc ?
BenG83 has quit [Quit: Leaving]
Andy-D has joined #linux-sunxi
raknaz[m] has joined #linux-sunxi
yann has joined #linux-sunxi
massi_ has quit [Remote host closed the connection]
massi has quit [Remote host closed the connection]
<jemk>
/tb
gzamboni has joined #linux-sunxi
leviathan has joined #linux-sunxi
lkcl has quit [Ping timeout: 260 seconds]
|Jeroen| has joined #linux-sunxi
chlorine has joined #linux-sunxi
jernej has joined #linux-sunxi
enrico__ has quit [Quit: Bye]
netlynx has quit [Quit: Ex-Chat]
f0xx has joined #linux-sunxi
florianH has quit [Quit: Connection closed for inactivity]
mzki has quit [Quit: Lost terminal]
f0xx has quit [Ping timeout: 240 seconds]
apritzel has joined #linux-sunxi
<apritzel>
ssvb: have you tried to read-modify-write SCR in your TOC0 SD boot program?
<ssvb>
apritzel: yes, I tried to read it and it was zero
<ssvb>
then I was lazy to add the code to read-modify-write it
<ssvb>
it is a very preliminary hack and I'll still revisit it to find out what's wrong when booting from the SD card
<ssvb>
btw, can you check if TOC0 binaries can successfully boot from SPI? there is no reason why they should not, but verifying everything is never a bad idea
dave0x6d has quit [Quit: Connection closed for inactivity]
BenG83 has joined #linux-sunxi
phipli has quit [Ping timeout: 264 seconds]
BenG83_PB has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
BenG83_PB has quit [Read error: Connection reset by peer]
<apritzel>
ssvb: thanks for the smc patches for sunxi-tools, they look good on a first glance
<apritzel>
ssvb: will check them later
matthias_bgg has quit [Quit: Leaving]
tkaiser has quit [Ping timeout: 260 seconds]
apritzel has quit [Ping timeout: 260 seconds]
ericxdu has quit [Ping timeout: 260 seconds]
chlorine has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
lurchi__ is now known as lurchi_
my123_ has joined #linux-sunxi
my123_ has joined #linux-sunxi
my123_ has quit [Changing host]
my123 has quit [Ping timeout: 255 seconds]
lurchi_ is now known as lurchi__
reinforce has quit [Quit: Leaving.]
my123_ is now known as my123
mripard has quit [Ping timeout: 240 seconds]
mripard has joined #linux-sunxi
<plaes>
mripard: about a20/a10 ccu?
<plaes>
how should I name the files?
<plaes>
but I assume, they will be really similar
<rah>
I was afraid I may have killed my tablet a few days ago with bad PMU settings but it has booted again today so I am happy :-)
<mripard>
plaes: I'd call it sun4i
BenG83_PB has joined #linux-sunxi
scream has joined #linux-sunxi
phipli has joined #linux-sunxi
tkaiser has joined #linux-sunxi
lkcl has joined #linux-sunxi
tkaiser has quit [Ping timeout: 268 seconds]
BenG83 has quit [Quit: Leaving]
iamfrankenstein has quit [Quit: iamfrankenstein]
paulk-collins has quit [Remote host closed the connection]
|Jeroen| has quit [Quit: dada]
Putti has quit [Ping timeout: 240 seconds]
tithrion has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
Putti has joined #linux-sunxi
scream has quit [Remote host closed the connection]
bonbons has joined #linux-sunxi
<jemk>
ssvb: i think i found where the boot source is stored
<jemk>
ssvb: looks like the toc0 header is at 0x0/0x10000, and the boot source is stored in 0x20/0x10020
<jemk>
but we overwrite it with the code due to the run address 0x0
<jemk>
aw uses 0x480 as run address
<ssvb>
jemk: I'm not sure about this, I already tried 0x10100 as the start address
<ssvb>
let me check it again
<jemk>
i didn't try yet, but thats how the code looks like
ericxdu has joined #linux-sunxi
<ssvb>
I did it a bit wrong before, I just switched to FEL mode and then did a hexdump
<ssvb>
but of course this data could have been overwritten by the FEL stack later
<jemk>
and there is a check of toc0_length <= 0x20000 right next to the bootsource-write, so thats probably the new size limit
leviathan has quit [Ping timeout: 240 seconds]
<jemk>
hm, there isn't that much sram on h3 (if we trust the manual), so that must be wrong somehow
mzki has joined #linux-sunxi
<ssvb>
jemk: you are right, the boot source is indeed written at the offset 0x20
<apritzel>
ssvb, jemk: \o/
<apritzel>
though that sounds nasty to integrate
<ssvb>
and it was FEL corrupting the data, because I explicitly initialized it to all 0xFF
<willmore>
Not trying to start another mali discussion, but the CHIP people have a mali on a mainline-ish kernel, don't they?
<jemk>
but it means we have to keep the toc0 header alive
<ssvb>
and sunxi-fel showed this particular part replaces with zeros, while some parts of the TOC0 headers were kept intact
Mr__Anderson has quit [Remote host closed the connection]
<ssvb>
yes, we need to keep at least some part of the header
<ssvb>
it is also possible to ensure backwards compatibility by adding a small stub which would memmove the eGON.BT0 data to the start of SRAM A1 and copy the boot source byte to the eGON.BT0 header
<ssvb>
this will make boot time a bit worse
<apritzel>
ssvb: but only for TOC0, right? So probably acceptable.
<ssvb>
apritzel: the whole SPL
<apritzel>
yes
<ssvb>
right
<apritzel>
but not for eGON boots
<apritzel>
so most people would not be affected
<apritzel>
only us freaks ;-)
<apritzel>
could we somehow cheat and not copy the whole SPL?
<ssvb>
we will probably not save or lose much time anyway
<ssvb>
yes, we can cheat a bit
<jemk>
sbrom does a full copy too, even if run_address==source_address
<ssvb>
but we will probably not save or lose much time anyway
<ssvb>
just peanuts
<apritzel>
yeah, let's bikeshed about a few milliseconds ...
<jemk>
0.5s normal vs 1.13s secure, so some more wont change much...
<ssvb>
I can try to hack a converter tool
<ssvb>
then U-Boot can produce both eGON.BT0 and TOC0 images
<ssvb>
we will have to get rid of the hardcoded U-Boot image offset though
<apritzel>
ssvb: which one?
<apritzel>
the 0x10000 vs 0x0?
Ntemis has quit [Remote host closed the connection]
<ssvb>
I mean the assumption that the SPL part is always 0x8000 and that the main U-Boot part follows right after it
<ssvb>
TOC0 takes more space than eGON.BT0
<jemk>
btw, the run address is copied from boot0 header+0x20 by the original toc0 generator, which is reserved1[0] in our u-boot
tkaiser has joined #linux-sunxi
nove has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
IgorPec has quit [Ping timeout: 252 seconds]
jstein has quit [Remote host closed the connection]
tkaiser has quit [Ping timeout: 240 seconds]
<nove>
(yet another rant) there is a lot of activity here -> https://github.com/rosimildo/videoenc/commits/master, of course as expected of the "community", which prefers to spent there time working with the license-issues-blobs that to give support (even verbal support) than the project without the license-issues
yann-kaelig has quit [Quit: Leaving]
<nove>
there is even ported the shit /dev/cedarv to kernel 4.4, for C.H.I.P
<rah>
do any of the framebuffer entries in sun4i-a10.dtsi work? none of the sun4i-a10-*.dts device trees make use of them
lkcl has quit [Ping timeout: 260 seconds]
<apritzel>
rah: one of those nodes gets enabled by U-Boot
<rah>
apritzel: I see
<apritzel>
rah: those nodes in the .dtsi are just placeholders to reserve the clocks, so that Linux knows they are used
<rah>
apritzel: my display doesn't seem to be displaying though :-)
<rah>
it's just a uniform grey
<apritzel>
rah: does it work in U-Boot?
<rah>
apritzel: no
<apritzel>
rah: also please be aware that this is the simplefb solution, which is different from the proper DE kernel driver
<apritzel>
IIRC for the A10 you have both, so you should prefer the kernel driver
<rah>
true, but I would like to get both Linux and U-Boot working :-)
<nove>
there must be some kind allergy going around, allergy to the linux-sunxi maillist, and allergy to the irc channel, but that is what happens with license-issues, when there are assholes that can't have their mouth shut out, they are the ones avoid, as the professional people is too professional to be told that there are license-issues
<rah>
apritzel: how does U-Boot know what parameters to use for the framebuffer? none of the a10 dts files in the U-Boot source seem to make any reference to the framebuffer either
<rah>
how does U-Boot know the LCD resolution?
<apritzel>
EDID
<dan0_0>
nove: what would you prefer? There are only so many hours in the day, and you don't need to use that code
<apritzel>
or configured, depending on your output
<rah>
CONFIG_VIDEO_LCD_MODE
<rah>
ah
<nove>
and then, why should allwinner change, the community likes license-issues, the license-issues is a good tool to remove unwanted assholes from the way
<dan0_0>
?
Andy-D has quit [Ping timeout: 260 seconds]
<rah>
apritzel: thanks
<dan0_0>
Go write it yourself if you want things to be different nove, the loose collection of people putting in time on Linux Sunxi have minimal sway in what Next Thing Co does. Both of those projects you linked to are from Next Thing Co
<dan0_0>
Besides, neither of those have any significant amount of work done by Next Thing Co, there are under 20 commits in either, none of which are major commits.
<shadeslayer>
bbrezillon: that talk by Laurent Pinchart is awesome
<nove>
dan0_0: what you talking about? Where is the nexthing connection to the aboves link?, there is none.
<nove>
if only every hardware vendor was like nextthing, which made a commitment for having mainline(recent) kernel, to point the paying for the software to be written
komunista has quit [Quit: Leaving.]
honeylab has joined #linux-sunxi
tkaiser has joined #linux-sunxi
honeylab has quit [Ping timeout: 260 seconds]
honeylab has joined #linux-sunxi
<nove>
but now talking of nextthing, they privately email us in december of 2015 and offered samples their board, and ended saying that they wanted to talk, but when i answered explaining the unfavorable conditions caused by the license-issues, and asked if nextthing could help us in creating "favorable conditions", but this appeared to be something that is too much to ask, and the discussion ended with me saying to invite allwinner into the discussion (wh
<nove>
ich didn't happen)
<shadeslayer>
MoeIcenowy: should a DRM driver for the sun50i ( A64 ) also go into drivers/gpu/drm/sun4i ?