Re: LG Nexus 5

[Shao Miller <netbsd%sha0.net@localhost>]

Good day, folks.

Some progress: I've been able to start /sbin/init (in a RAM disk) on the 
LG Nexus 5.

Some findings to share:

1. The "simple framebuffer" doesn't support the r8g8b8 mode that the 
device's framebuffer uses.  I used the framebuffer code from "tinyfont" 
to scrape by.

2. "Simple framebuffer" can be hacked to accept 24-bit color with the 
result being "all bits on" is "green."

3. I was unable to identify a "framebuffer commit hook" or "framebuffer 
refresh hook" in "simple framebuffer."  This device needs a poke at an 
address outside of the framebuffer memory in order to draw the screen.  
Such a poke needs to have a maximum rate, also, otherwise one will have 
a scrambled display.

3. I could be mistaken, but there appears to be an assumption somewhere 
about device-memory being at > 2 GiB ("high").  What I found was that if 
the framebuffer was identity-mapped to its < 2 GiB address, it would 
work until some random point after interrupts and the clock are enabled, 
then any attempt to touch that "low" memory would hang the device.  When 
I mapped its low PA to a high VA, all was well.  Perhaps this has 
something to do with the user-land and kernel-land split.

4. The "simple framebuffer" appears to use the PA, so it runs afoul of 
the previous point.  I might try to hack it to use the VA, instead.

5. In the arch/arm/arm32/arm32_kvminit.c file's arm32_kernel_vm_init 
function, there is an ARM_MMU_EXTENDED #ifdef section which "[disables] 
lookups via TTBR0 until there is an activated pmap."  Removing the call 
to the armreg_ttbcr_write function appears to permit the device to 
proceed beyond the nearby and subsequent call to cpu_tlb_flushID.  (An 
earlier call to cpu_tlb_flushID prior to this "disabling" of TTBR0 
succeeds.)

6. I did not have MULTIPROCESSOR for this build, but I might try it 
later.

7. The GIC appears to be at least compatible enough with 
arch/arm/cortex/gic.c to get as far as the progress noted at the top.

8. The CPU ID needed to be injected into at least a couple of places, as 
would be expected.

9. The FDT at 
external/gpl2/dts/dist/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts 
seemed to permit the clock and timer to be matched and attached.

10. The /sbin/init program's output didn't appear to goto the 
framebuffer, but there was other evidence that it ran successfully.  
Perhaps some "boot argument" is needed, in order to direct /sbin/init's 
output to the same destination(s) as kernel-land printf.  Hints welcome 
(please).

If there's an existing trick to persuade "simple framebuffer" to use VAs 
instead of PAs, that'd be neat.

- Shao Miller