[Arm-netbook] passthrough, a20 and rk3288 cards

Albert ARIBAUD albert.aribaud at free.fr
Wed Feb 22 11:00:19 GMT 2017


Bonjour,

Le Wed, 22 Feb 2017 10:30:29 +0000
Luke Kenneth Casson Leighton <lkcl at lkcl.net> a écrit:

> ---
> crowd-funded eco-conscious hardware:
> https://www.crowdsupply.com/eoma68
> 
> 
> On Wed, Feb 22, 2017 at 9:55 AM, Albert ARIBAUD
> <albert.aribaud at free.fr> wrote:
> 
> >>  u-boot development, kernel development, os preparation, packaging,
> >> upstreaming - anything like that.  
> >
> > I can do U-Boot development/mainlineing, but before I commit
> > myself, I'd need to know what the time frame and deadlines would
> > be.  
> 
>  as a software libre project i'm not comfortable with specifying
> deadlines to people: that's not fair so i'm not going to do that.
> also, timeframe: i have a working version of u-boot (non mainline), it
> works, it ain't broke, i ain't gonna try to "fix" it.
> 
>  there are however some very specific things that need to be done for
> mainline u-boot:
> 
>  (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)?

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

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

Ok.

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

> this last one will take time as it will involve talking to a lot of
> people.  that's fine: we have the sunxi 3.4 kernel in the meantime.
> 
> l.

Amicalement,
-- 
Albert.



More information about the arm-netbook mailing list