Re: LG Nexus 5

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

On 23/11/2022 11:15, Shao Miller wrote:
> Good day, folks.

Hi,


> After much whittling away of the "fun" that led up to being able to get 
> a PID 1 going, attached is a patch.  This patch is _not_ intended as a 
> worthy submission to the code-base.  It's merely evidence that the LG 
> Nexus 5 is approachable.

Congrats!


> Known issues:
>
> 1. The hack to simplefb to support 24-bit color isn't quite right.  It 
> appears to result in green text (unless that's always true?) and there 
> is some kind of glitch in which text from the bottom might become 
> interleaved with text near the top, or even interleaved with such text 
> from a previous boot of the device.  (When I used some framebuffer code 
> from 'tinyfont' and it used 24 bits per pixel, it was fine.)


This is standard kernel colour.


$ grep WS_KERNEL_FG sys/arch/evbarm/conf/GENERIC
options         WS_KERNEL_FG=WSCOL_GREEN
$

> 2. The macro-names for the CPU probably warrant criticism.

Just a CPU_ID_KRAIT_P ?


> 3. The macros for the CPU probably aren't the right combination of 
> specificity.

Having specific core ID macros and family macros available is common.

> 4. The injection of the CPU into "someone else's" section isn't right 
> and there should probably be a new section, instead

Yeah, please do a CPU detection outside of CPU_CORTEX (Arm CPUs)

.
> 5. I haven't yet figured out how to provide a /dev/console.  Any 
> suggestions would be most welcome >
> 6. The "platform" naming isn't quite right, but having not developed for 
> NetBSD before, I'm uncertain as to the conventions.  SoC?  Precise 
> phone-model?  Less-precise phone-model?  Whimsical choice?

SoC or SoC-family.


> 7. The "NEXUSTROUBLEXXX" lines are merely descriptive.  The use of an 
> 'if' to block out a "problematic" line warrants further pursuit of 
> understanding before even deciding upon a correct strategy, whether 
> #ifdef or something else.

Do the Krait CPUs have non-architecture described caches?

> 8. The organization of the configuration-files probably isn't right.  If 
> the device was fully supported, I suppose it'd probably get added into 
> evbarm GENERIC, at such a time... or elsewhere.

evbarm/conf/GENERIC would be the goal, yes.

> 9. Thanks to Nick Hudson for direction towards callout(9).  I'm not sure 
> that xxx_platform_device_register is where it belongs; probably not.

seems best from a quick glance.

> 10. Magical numbers everywhere, including an arbitrary choice for the 
> framebuffer VA space.

#define the magic numbers please :) (and lower case hex digits)

> 11. The last time I checked, some of the low RAM is forfeited; likely 
> due to the FDT not covering enough detail.


or firmware taking some?

Nick