Is the MIPS kernel buildable from HEAD?

[M. Warner Losh]

In message: <32AB5C9615CC494997D9ABB1DB12783C024C875653 at SJ-EXCH-1.adaranet.com>
            Patrick Mahan <PMahan at adaranet.com> writes:
: 
: 
: > -----Original Message-----
: > From: M. Warner Losh [mailto:imp at bsdimp.com]
: > Sent: Wednesday, August 25, 2010 10:29 PM
: > To: c.jayachandran at gmail.com
: > Cc: Patrick Mahan; freebsd-mips at FreeBSD.org
: > Subject: Re: Is the MIPS kernel buildable from HEAD?
: >
: > In message: <AANLkTi=FZrdjE0KoUHvOiB9hyz5ZDWepS9743ghAw9SU at mail.gmail.com>
: >             "Jayachandran C." <c.jayachandran at gmail.com> writes:
: > : On Thu, Aug 26, 2010 at 2:43 AM, M. Warner Losh <imp at bsdimp.com> wrote:
: > : > In message: <32AB5C9615CC494997D9ABB1DB12783C024C875590 at SJ-EXCH-
: > 1.adaranet.com>
: > : >            Patrick Mahan <PMahan at adaranet.com> writes:
: > : > : Is it possible to build the MIPS kernel from HEAD?  Or is the
: > : > : current development still external to the HEAD branch?
: > : >
: > : > Yes.  The tip of head is where the mips action is these days.  There
: > : > is no external development branch.
: > : >
: > : > There is one issue, however.  If you are building for one of the
: > : > 64-bit processors a 64-bit kernel, then the required userland won't
: > : > build.  There's still issues that need to be sorted out...
: > :
: > : The 64-bit userland builds for me with  -DWITHOUT_CDDL -DWITHOUT_USB
: > : -DWITHOUT_BLUETOOTH  -DWITHOUT_RESCUE - are you referring to these, or
: > : are there other issues?
: >
: > I can do a buildworld now without any of these flags.  I don't know
: > what the bluetooth issue is/was, but it doesn't kill the build.  I
: > fixed the CDDL issue, and papered over the uath and rescue issues in
: > the build system.
: >
: > I can now build a n64 world in -current.  I haven't had a chance to
: > run it yet, but hope to soon.  My CN38xx board doesn't like the 32-bit
: > kernel anymore...  It also doesn't like the 64-bit kernel, but I think
: > that's a uboot issue.  It seems older ldscripts didn't tickle the bugs
: > the current one does (on the other hand, the old ldscripts only worked
: > on the CN38xx board).  On the other hand, SDK 1.9.0's uboot on another
: > board works fine with the 64-bit kernel.
: >
: 
: Warner,
: 
: We build o32 with our modified FreeBSD 8.0 that boots under the SDK 1.8.1
: on a CN58XX.  However, I was looking at the ldscript that we use versus
: the one in use for you.  We are using what is basically sys/conf/ldscript.mips.

That's good to know...

: Also, I think our problem is with the a3 register passed in as part of
: platform_start() in cavium/octeon_machdep.c.  We have the following in
: mips/lowcore.S -
: 
: #if defined(TARGET_OCTEON)
:         la      a0, app_descriptor_addr
:         sw      a3, 0(a0)               /* Store app descriptor ptr */
: #endif
: 
: So we are storing the value of a3 into a global that we later use in
: octeon32/Octeon_machdep.c -

Yea.  The old code did that.  We removed it because we were passing a3
into the platform_start routine directly.  I had to fix some of locore
to not clobber the a3 register, however, to make it useful...  A quick
look at locore.S shows 

: static void
: mips_boot_params_init(void)
: {
:         int descriptor_not_parsed = 1;
: 
:         if ((app_descriptor_addr == 0) || (app_descriptor_addr >= 0xAfffffff)) {
:                 printf("address of app_descriptor is %x\n",
:                     app_descriptor_addr);
:         } else {
: 
:                 app_desc_ptr = (octeon_boot_descriptor_t *) app_descriptor_addr;
:                 octeon_bd_ver = app_desc_ptr->desc_version;
:                 ...
: 
: 
: I am need to investigate, but I think we found that a3 was getting clobbered on
: the inbound call to platform_start().

You might try not using the app_desc_ptr at all.  It used to be
possible to boot things w/o it before Juli's changes.  I haven't tried
since then.

Also, there was a bug with the bzero in locore where it would round to
the next page bogusly.  As a result, it overwrote part of the
app_descriptor leading to much confusion inside the kernel...

You might also try poking some kind of character into the LEDs at
different points to see how far you get.  When I've seen uboot bugs,
they have kept me from even getting to the first line of locore.S.

Warner