Hi Luke, Le Wed, 22 Feb 2017 14:07:36 +0000 Luke Kenneth Casson Leighton <[email protected]> a écrit:
> On Wed, Feb 22, 2017 at 11:00 AM, Albert ARIBAUD > <[email protected]> wrote: > > Bonjour, > > > > Le Wed, 22 Feb 2017 10:30:29 +0000 > > Luke Kenneth Casson Leighton <[email protected]> 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. _______________________________________________ arm-netbook mailing list [email protected] http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to [email protected]
