From nobody Mon Jul 17 17:20:50 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4R4TPq0kxpz4nL3Y for ; Mon, 17 Jul 2023 17:21:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R4TPp52H5z4Tql for ; Mon, 17 Jul 2023 17:21:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-51e344efd75so9861991a12.1 for ; Mon, 17 Jul 2023 10:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1689614461; x=1692206461; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QJxO6iRrhA7GMFdBvUqTglSQ0fu923OCMz++JsfJqto=; b=rvhJayIbVFGW3sIws2Hkkdczp9sELuKt4thHC0SZ70yxn6Pukw/Pe0fe6ufAehMuNq 2LiqsP+d3omQ21B7ClXWUWGZYYjcd3wGzpP23YBU7TYklr83Xc/uAfjpiO7jxQFeo7nB Lg8KErF07bvx+3SWfSPj8pnoJYiZdl6Z7lXPmj2pgmEKZapohvPS6wmphdibTEIf12FO w3O6IUoaek5hYkVxKmaMnQf9dSq90c+3CGAonydX+El+kICvVaA2sOJFawrE+0Zl4FV5 5QCb2TWLiijU3187aP3Yr2KTdFzGqCIk+WvmM2X7NXr+sgJOFFtnrMxXAJZ22Vuvha6B WEIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689614461; x=1692206461; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QJxO6iRrhA7GMFdBvUqTglSQ0fu923OCMz++JsfJqto=; b=O/ov4x8NoUD9ZRC9r8DJdESALINELz/de9ArFSLlSqQ1AHVaaRbC9qoDTJKJwslVqZ dNt2S2Um72fwSivTzZCf82A75dqV7KsMLz4cB4H6pInXCvCkkH9osVKOL+2RyENN9F6I sWjJpcOv6wloS+G8IYa+8/oPuFK+8lpZ/Ps0wqW/CD5ehc2wqpKAed5GTo6ohrw6MGvz LszQKD1d79Py5MkDw7escNULD0xQ9gwvS1Q8CHOta4+o5cm11cI4NydtuFxGJJXTlfTB jO+Gfs1/dwKR2aUOtxhbPtXB1UOP2ALYx9KfYzj0bFC8Wv5GyWEnDMk1EXh/y8p2n0Fl OYVA== X-Gm-Message-State: ABy/qLZdQl+ninfJruLgWUQOZBtrqkrj4app8ZPwqewVs7g1+fAMa4G8 6UpuS8SPebQq+OqXAgy1ykqKsBglwoMYgMuMRJRfTA== X-Google-Smtp-Source: APBJJlESgGnnCbvwjU6sSGQMOF4t4Myb8R+JhOFT5YhDRwHHY2HNvfkefsTAv3036R1reSWCTPrHkvGSR+kv/L+992E= X-Received: by 2002:aa7:d852:0:b0:521:6275:c9af with SMTP id f18-20020aa7d852000000b005216275c9afmr11584237eds.7.1689614460825; Mon, 17 Jul 2023 10:21:00 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 17 Jul 2023 11:20:50 -0600 Message-ID: Subject: Re: Supermicro R12SPD Ampere Altra - No valid device tree blob found To: Mark Millard Cc: John , FreeBSD ARM List Content-Type: multipart/alternative; boundary="000000000000bec7370600b2055f" X-Rspamd-Queue-Id: 4R4TPp52H5z4Tql X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000bec7370600b2055f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 17, 2023 at 11:15=E2=80=AFAM Mark Millard w= rote: > On Jul 17, 2023, at 09:37, John wrote: > > > Hi Folks, > > > > I have a new Supermicro system: > > > > Supermicro R12SPD BIOS Date:04/26/2023 Rev:1.1a > > CPU : Ampere(R) Altra(R) Max Processor > > > > Booting from the latest media (spot checking older > > media makes no difference): > > > > Boot Media: > FreeBSD-14.0-CURRENT-arm64-aarch64-20230713-510fd8313800-264135-disc1.iso > > > > Fails here: > > > > Loading kernel... > > /boot/kernel/kernel text=3D0x2a8 text=3D0x8ff810 text=3D0x29b324 data= =3D0x153cc8 > data=3D0x0+0x2c3000 0x8+0x155628+0x8+0x17e504| > > Loading configured modules... > > can't find '/etc/hostid' > > can't find '/boot/entropy' > > No valid device tree blob found! > > WARNING! Trying to fire up the kernel, but no device tree blob found! > > EFI framebuffer information: > > addr, size 0x10000000, 0x300000 > > dimensions 1024 x 768 > > stride 1024 > > masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 > > > > > > If I break into the loader, the fdt command shows the > > same error message. > > > > OK fdt ls > > No device tree blob found! > > > > OK > > > > A verbose boot shows no additional information. > > > > I've poked around in the source and don't see an obvious > > fix for this. Web searches have also not provided any > > obvious solutions. > > > > Any ideas? Thoughts? > > UEFI/ACPI booting does not have a "device tree blob" to find but > FreeBSD's UEFI laoder still puts out the "No valid device tree > blob found!". I see this on all the UEFI/ACPI booting systems that > I have access to --and they all boot fine, aarch64 system and the > amd64 system. > > I expect that your boot context is UEFI/ACPI and that the message > has mislead you about what to look for relative to booting. > > But I could be wrong and the system could be trying to boot via > fdt. That is one of the problems with the way this messaging is > handled. > > On the HoneyComb (16 Cortex-A72's), for example, there > is the FreeBSD loader's configuration command: > > OK configuration > NumberOfTableEntries=3D12 > 76b6bdfa-2acd-4462-9e3f-cb58c969d937 at 0xfad05b18 > fc1bcdb0-7d31-49aa-936a-a4600d9dd083 at 0xfaabfd98 > DXE Table at 0xfacea6b0 > HOB List Table at 0xfaabd018 > MemoryTypeInformation at 0xfacea338 > Debug Image Info Table at 0xfad038d8 > a4ee0728-e5d7-4ac5-b21e-658ed857e834 at 0xfaccea98 > ACPI 2.0 Table at 0xef890018 > SMBIOS3 Table at 0xfacb0000 > dcfa911d-26eb-469f-a220-38b7dc461220 at 0xee5cb018 > HII database at 0xee550018 > HII config routing at 0xee530018 > > For this context, it indicates a UEFI/ACPI boot: note the > "ACPI 2.0 Table at". FDT booting would refer to such instead. > > So you likely can check if you are UEFI/ACPI booting vs. > FDT booting. > > It is technically possible to have an environment that could > list both. I've no experience with booting such a system or > other knowledge of how FreeBSD handles such. > It's supposed to use FDT if it is present, and ACPI if not. If you have both (which kboot does for $REASONS), then you'll need to set kern.cfg.order=3D"acpi,fdt" in /boot/loader.conf which I do for kboot booted mount jade systems. Warner --000000000000bec7370600b2055f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 17, 2023 at 11:15=E2=80= =AFAM Mark Millard <marklmi@yahoo.c= om> wrote: