[Arm-netbook] 480 × 272 5" LCD lash up ready for testing

[luke.leighton]

On Sat, Sep 14, 2013 at 2:18 AM, joem <joem at martindale-electric.co.uk> wrote:
>
>> I tried got to a lot of things last night, and plenty milage with
>> cubieboard2 which is so much further ahead. I got to the differences in
>> boot.cmd, boot.scr, script.bin that I can fix from a stock sunxi dd uSD
>> image. I guess the next step is the kernel and then locating the board
>> specific packages and see what else needs doing to convert an existing
>> uSD cubie2 images that can be worked on by a single script to convert it
>> to boot on eoma.
>
>  you should be able to drop in a different script.fex (the
> eoma68-a20.fex one) and... err... that's about it.  you've already got
> u-boot up so it should be utterly trivial.
>
>> Then I can try the dozen or so images out there
>> for cubie2 out on eoma and eliminate duplication. :)
>
>  awesome.
> --
>
> The mistake was forgetting to create a fresh boot.scr
> after editing boot.cmd.

 ok that's good lesson.

> Results so far:

 ok - general overview, there's lots of confusion below.  there's no
such thing as an "eoma kernel" (it's a group of standards, not a
kernel).  this would be a bit like someone reporting to you, when
they're asking for your help in working out which way round an LED
should be connected, they say "the light's not working".  "light" is a
general class of thing wot generates light: by saying "light" instead
of "LED" you now don't know if they really *mean* "lightbulb" or if
they mean "LED", let alone which pin they're connecting!

 so we're going to *assume* [which is generally bad] that when you say
"eoma kernel" you *actually* mean "the specific kernel i advised you
to compile up i.e. the one that's tagged lkcl-a20-3.3-dev in the
git.rhombus-tech.net/linux.git repository".

 in future can we please therefore *specifically* use the tag that is
*specifically* unique so that there is no confusion?

> 1. EOMA Linux kernel boots the cubie A20 SD card image
>     The cubie

 again - cubie could refer to cubie 1, cubie2, it could refer to the
board itself, or to the kernel, or to something else.  please be
*really* specific.

 in hardware this is a bit like someone saying "yes i connected the
LCD". errr.... which LCD panel?  and we need to know (just as we
recently worked out was wrong with the flying squirrel LCD/LVDS
connections) which wires are *specifically* connected to which.


> boots to a command line shell on the HDMI,

 ok so we're going to assume that you're referring to the cubieboard2
image with a sunxi-3.4-dev kernel that you've picked up.

>     but eoma     kernel

 ... you mean the one tagged lkcl-a20-3.3-dev

> doesn't work the HDMI.

 ah.  i think i know why.  you remember i've mentioned i believe it's
now *seven* times that you need to obtain the file partition2.tgz
which is linked from here: http://rhombus-tech.net/allwinner_a10/boot/

> Instead get root
>     access through the UART only. Something need fixing in eoma kernel
>     to get it booting with hdmi working/

 if it's what i think it is, absolutely NOTHING needs fixing.  take a
look at the .config files for each of the 2 kernels (you've made one
from eoma68-a20-config, you'll need to track down the other one).

 search for  ... hmmm... let's actually have a look at it.... tum te
tum.... http://rhombus-tech.net/allwinner/a20/boot/eoma68-a20-config

 ok, what we got...

#
# Frame buffer hardware drivers
#
CONFIG_LYCHEE_FB_SUN7I=y
CONFIG_LYCHEE_LCD_SUN7I=y
CONFIG_LYCHEE_HDMI_SUN7I=y

ok, so yeah - HDMI is built-in.  what else might be the case...

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE is not set

ah ha!  so if you're expecting a console to come up on the HDMI output
then... duh, it ain't gonna happen.

on the other hand, if you were to do "echo faskjhfskjdkdshf >
/dev/fb2" you *might* see something come up.  or, alternatively, do
what i do, which is to log in and run "startx".  assuming that
x-windows has been installed, you *should* get something up on-screen.

> 2. EOMA Linux kernel can't boot with the EOMA lib.

 we're translating this to mean "the kernel version which is currently
tagged as lkcl-a20-3.3-dev kernel can't boot with {UNIDENTIFIED
UNAMBIGUOUS WORDS WHICH HAVE NO MEANING}".

 actually, that's not quite true: EOMA lib will *at some point* refer
to the linux kernel library subdirectories which will help identify
(at runtime) one board from another, but you don't need to know about
that right now.

 so, you'll need to be much more specific about what you're referring
to, here, joe.  it's as if you said "the LCD doesn't work with the
screwdriver".  what the _heck_ would you be doing using a screwdriver
to get a sophisticated piece of electronics to work?? :)


> 3. Cubie image has sata working on a cubieboard, but eoma kernel
>    does not allow sata to work with cubie's lib

 that's probably because the options haven't been enabled in the
kernel config, or you haven't loaded the modules.  let's have a
look...

# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
# CONFIG_SATA_AHCI_PLATFORM is not set
CONFIG_SW_SATA_AHCI_PLATFORM=m
CONFIG_ATA_SFF=y

ok, so the modules are built.  you should have copied them over to the
/lib/modules/3.3.0+ subdirectory (on the micro-sd card).  and then you
should have done "modprobe sw_ahci_platform".  at that point and ONLY
at that point should the SATA bus come up.

you can add that module to /etc/modules and it will load automatically
on every boot, if you wish.


> 4. Lots of other images to try out time permitting now that
>    I know what combinations work get a command line.
>
> 5. Found the relevant LCD set up information fex file - draw a circuit
>     soon to how to set up.

 magic.

> Its strange that EOMA kernel is the only kernel that works
> with cubieboard root fs. If the CPU is the same and all of the
> hardware details are in adjustable .fex files,
> surely that should happen to a linux kernel?!

 it's more complex than you're imagining it to be, but this is
actually standard linux kernel stuff that's *not* unique to this
board.  you're in at the deep end somewhat because you're also testing
hardware.

 it would help enormously if you had a working board (known-good).

l.