On Wed, Feb 22, 2017 at 11:00 AM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Bonjour,
Le Wed, 22 Feb 2017 10:30:29 +0000 Luke Kenneth Casson Leighton lkcl@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.