[Arm-netbook] passthrough, a20 and rk3288 cards

[Albert ARIBAUD]

Hi Luke,

Le Wed, 22 Feb 2017 14:07:36 +0000
Luke Kenneth Casson Leighton <lkcl at lkcl.net> a écrit:

> 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).

Ok. Inside U-Boot this could be either compiled or scripted; will have
to see what the exact use cases are.

> >>  (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 :)

Let's start simple. :)

> >>  (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.

I'll try and have a look.

> l.

So, back to the initial question: I'm ok with doing U-Boot related
stuff, at least, on a pre-prod card. How do we proceed?

Amicalement,
-- 
Albert.