Toiling away on booting the new blades

[Andrew Duane]

This is actually something I wanted to understand better. I'm spending a lot of time in octeon_machdep.c, and the file seems to be a combination of Cavium SDK code (or at least SDK-derived code) and some stuff FreeBSD did itself. I'm trying to understand which is which, and what I should try hard to keep intact for future SDK drops. The file does seem to have a split in the middle, with a separate block comment about provenance, and the structure definitions are a bit muddled.

The cvmx_bootinfo_t structure is from Cavium? It has a lot of baggage that we really don't use. About 3/4 of it is completely unused (some is used in the Linux application stuff, but not in the kernel), and some of the rest is easily derived from querying the hardware. That's what we do in JUNOS. Things like core count, clock speed, etc. are just register reads on the chip. Even memory size (that dreaded phy_mem_desc_addr) is really much more easily described. The u-boot provided with the SDK allows the user to carve up memory into different spaces for various things, but that's really not used. You just need the "top of memory" which bootinfo provides, then use the simulator path in octeon_memory_init (which I assume is FreeBSD code?) to assign phys_avail[1], and away you go.

But, if the structure is from the SDK, I will leave it be. In fact, I still have to synthesize a structure so things like the enet driver (mac_addr) and CF driver (compact_flash_common_base_addr) will work. I would just like to know what code in there is fair game. I've spent a lot of time working on Octeon startup code, but we dumped pretty much all of the SDK in this area and rolled our own.

--
Andrew Duane             Juniper Networks
978-589-0551              10 Technology Park Dr
aduane at juniper.net      Westford, MA  01886-3418

________________________________________
From: Warner Losh [imp at bsdimp.com]
Sent: Sunday, April 03, 2011 9:45 PM
To: Juli Mallett
Cc: Andrew Duane; mips at freebsd.org
Subject: Re: Toiling away on booting the new blades

On Apr 3, 2011, at 5:19 PM, Juli Mallett wrote:

> On Sun, Apr 3, 2011 at 15:07, Warner Losh <imp at bsdimp.com> wrote:
>> On Apr 3, 2011, at 3:29 PM, Andrew Duane wrote:
>>> Since the MIPS bootinfo structure is already part of FreeBSD, is this code in the startup path something you'd be interested in taking in?
>>
>> I think I'd be interested.  I think this is a decent path to explore, but would need to see code before committing :)
>
> Indeed, I think it's worth committing probably, or perhaps committing
> a modified version that does the same thing.  It's easy to imagine
> that some people will eventually want to just use loader with U-Boot
> on Octeon so that they can have hints, good UFS support, module
> loading, etc.
>
> Also, Warner, if you touch octeon_machdep.c, could you please move the
> app boot descriptor thing to a separate header file with the Cavium
> license?  I believe I've touched all of the actual *source code*
> there, but right now we're possibly violating the license (depending
> on how big you believe a page is) which requires the license to be at
> the top of the file.  So I think moving the license and struct to a
> separate header would be sufficient (using the structure from the
> current SDK would probably be even better?)

I'll look into it.  I inherited the code from the Cavium folks, so if there's a license violation, they did it to themselves :)

Structurally, I think it would be better.  I've wanted to have more modularity in how we hook up the bootloader-> kernel handoff for embedded systems for a while, and this will help that goal.

Warner