[Arm-netbook] passthrough, a20 and rk3288 cards

[Luke Kenneth Casson Leighton]

On Wed, Feb 22, 2017 at 11:00 AM, Albert ARIBAUD <albert.aribaud at free.fr> wrote:
> Bonjour,
>
> Le Wed, 22 Feb 2017 10:30:29 +0000
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> a écrit:

>>  (1) EOMA68 I2C EEPROM @ addr 0x51 reading library.  very simple: read
>> 32 bits, format similar to USB device ids, return major/minor numbers
>
> What would be the use case? Passing major/minor to Linux through the
> command line? Local use in U-Boot (which one)?

 local use in u-boot - leave it to linux kernel (which will need to do
the same thing) to read the EEPROM again.

 the reason is: you may not actually *use* u-boot (at all) if a
processor is used such as ... oo... an AMD Geode LX800 or something
which doesn't *use* u-boot but instead has a BIOS.

 the reason why u-boot has to read the I2C EEPROM independently is
primarily for video output (configuring then displaying)..

 ... or if there's a console device that would be detected via the
relevant devicetree overlay being read and loaded...

 ... or if there is a USB keyboard... again, needs configuring and detecting...

.. or if there's a special button for boot option selection which is
in a very special type of Housing for blind people (yes this idea came
up a few months ago)...

 ... all these things need to be coded into u-boot to interact with
the users enough so that they can choose the right boot option....

 ... all of which is *completely* independent of the linux kernel (or
whatever OS actually gets run).


>>  (2) devicetree overlays (which should be in u-boot mainline already:
>> if it isn't, it needs to be added)
>
> They'll be there there in 2017.03.

 _great_.  that's really good to hear.

>>  (3) microdesktop dtb overlay needs to be written (as a first example)
>
> Ok.

 it's really simple, that one.  it can get complicated later (loading
a bit-banging I2C module which then reads EDID data from the 2 GPIOs i
connected to the VGA monitor EDID lines) but for now the devicetree
overlay can be completely bare-bones, main thing it should really do
is set the VGA monitor to 640x480 default hard-coded output... errr...
that's all :)

>>  (4) fixing the silly, silly decision(s) which were made *without*
>> consulting any of the projects (of which there are several, *only one
>> of which* is the EOMA68-A20 Card) that require devicetree overlays for
>> the *video* aspect of their hardware, where it is ASSUMED in the sunxi
>> mainline u-boot that the video WILL be initialised EXCLUSIVELY by
>> u-boot and is to be left AS-IS by the linux kernel (as a
>> simpleframebuffer).  there IS no support for changing, setting,
>> altering, or interacting with the video hardware IN ANY WAY other than
>> that which was initialised BY u-boot at boot time.
>
> Seems to me less of a U-Boot issue, and more of a Linux issue, unless
> U-Boot takes active steps to lock video setup registers. What exactly
> prevents Linux from setting up video again after U-Boot has chained to
> it?

 good question.  huh.  yeah - good point.  last time i checked nothing
_had_ been done, so i assumed nothing _could_ be done.

l.