From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 14:21:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3154435; Mon, 17 Mar 2014 14:21:30 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F398AA5C; Mon, 17 Mar 2014 14:21:29 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id c6so3385258lan.38 for ; Mon, 17 Mar 2014 07:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+ontWEXjaCzV9ase3aN1ZAxi9BBHPDMrK+fi7kFVDmY=; b=tBIMf0mv/mhk964pDsPkwpJwp3CoZwYdgA/bINqMTVqHQdYoDtYyY+otpftLNlx9hC LE63Yu3xfq5I9/Txu7rydGHZ6Ybbv+MZOOoh+qFSBKqsKotuoYvyFHpi4dAb7eslKYOU Z3mRkquWZVDBNu/N2KmZQrn3++wcUhSIPCl9AT0iMpI8z5XKWx0tcuiNW1TTMVySnn/e qIOevDHkRiseBMqkF1RJf1eOq7KCaneJt0Avwpi3D6UhJSIoGhZvYEHkAKEg/zhj2I5V yPuWqPMvKdA02fA4nwPHO356fjcE13XiYLlmXsxFBmpApqV3rtPuhpBUxm9d2PqsJNty 50yQ== MIME-Version: 1.0 X-Received: by 10.112.94.229 with SMTP id df5mr1672473lbb.36.1395066088095; Mon, 17 Mar 2014 07:21:28 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.142.10 with HTTP; Mon, 17 Mar 2014 07:21:28 -0700 (PDT) In-Reply-To: <1395064661.1149.565.camel@revolution.hippie.lan> References: <1395064661.1149.565.camel@revolution.hippie.lan> Date: Mon, 17 Mar 2014 10:21:28 -0400 X-Google-Sender-Auth: BHDbd8w1qyu3QxG5f9fGzDnd8R0 Message-ID: Subject: Re: Booting FreeBSD from eMMC on BeagleBone Black From: Patrick Kelsey To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 14:21:31 -0000 On Mon, Mar 17, 2014 at 9:57 AM, Ian Lepore wrote: > On Sun, 2014-03-16 at 22:16 -0400, Patrick Kelsey wrote: > > On Sun, Mar 16, 2014 at 9:33 PM, Rui Paulo wrote: > > > > > On 16 Mar 2014, at 14:59, Patrick Kelsey wrote: > > > > > > > - Improved disk probing support that will now by default find and > use the > > > > first suitable partition among the available storage devices. > > > > > > I think this introduced a bug where, if you have a non-responsive boot > > > device, ubldr will stop and won't try network booting: > > > > > > ## Starting application at 0x01000054 ... > > > Consoles: U-Boot console > > > Compatible API signature found @1d800a8 > > > Number of U-Boot devices: 2 > > > > > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > > > (rpaulo@zedfs.local, Fri Mar 14 22:35:47 PDT 2014) > > > DRAM: 256MB > > > Unknown device type '' <------------ this is new > > > Found U-Boot device: disk > > > Probing all storage devices... > > > Checking unit=0 slice=0 partition=-1...disk0: read failed, error=1 > > > > > > Checking unit=1 slice=0 partition=-1... > > > Checking unit=2 slice=0 partition=-1... > > > Checking unit=3 slice=0 partition=-1... > > > Checking unit=4 slice=0 partition=-1... > > > Checking unit=5 slice=0 partition=-1... > > > > > > can't load 'kernel' > > > > > > Type '?' for a list of commands, 'help' for more detailed help. > > > loader> > > > > > > It stops here and doesn't try net0 booting. > > > > > > > > I think the problem is that some of the conditionals in > > sys/boot/uboot/common/main.c:main() are broken. I believe I sowed the > seed > > for this in the original patch I sent to Ian, which appears to have had > an > > out-of-order set of tests in the disk conditional, which in hindsight > > turned out to work due to a friendly coincidence (namely disk appearing > > before net in the devsw). That bad-pattern conditional seems to have > > gotten munged a bit further and propagated in some of the refactoring Ian > > did when integrating my patch. > > > > I believe sys/boot/uboot/common/main.c, starting around line 442, should > > look like this: > > > > if (strcmp(devsw[i]->dv_name, "disk") == 0 && > > (load_type == -1 || (load_type & DEV_TYP_STOR))) { > > if (probe_disks(i, load_type, load_unit, > load_slice, > > load_partition) == 0) > > break; > > } > > > > if (strcmp(devsw[i]->dv_name, "net") == 0 && > > (load_type == -1 || (load_type & DEV_TYP_NET))) > > break; > > > > > > Can you give that a try? > > > > -Patrick > > This was my bad. I think I was so enmeshed in whether the strange > original strncmp() calls were really just a silly form of strcmp() (they > were) that I didn't even notice I screwed up the overall logic. > > Rather than putting the strcmp() first as shown above, I just adjusted > the parens in the network if() to be what I should have done originally. > > I don't believe that approach will fix it. It's not just the parens in the "net" conditional that are the issue - I had the order of the tests in the "disk" conditional backwards to begin with. To get the desired behavior (proper fallback to net), the test of devsw[]->dv_name needs to be first so that a load_type of -1 cannot short circuit it in a loop iteration that is for another type. Otherwise, when load_type is -1, coming out of an unsuccessful probe_disks() will result in an exit from the loop via the "net" conditional, and you will wind up out of the loop, but without currdev set up properly for the net device (it will still be set up for "disk", and with a possibly non-zero unit number). Putting the test of devsw[]->dv_name first ensures that the loop won't be exited on behalf of a given type without currdev being set up for that type. -Patrick