From nobody Mon Jul 17 20:39:33 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 4R4YqB0bqWz4mtn5 for ; Mon, 17 Jul 2023 20:39:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4R4Yq94Wfcz4Gtv for ; Mon, 17 Jul 2023 20:39:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1689626387; bh=j8HqDBm4Fva78ZC1bmum+5vGH2XfGl1iCprtSflypuw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=HQuyPbKZrrPuk5vGfA364pQzbyn1DVQ3Lgi3m2q4zIluysMb/d6Z/tULPe0zkzCGVxW/56X+7B2aUk5C3EKBJrtxVCxfwL+aQpmiOPxdICkIXVieDNA5cZtzR8KiYuZCg93WAJesgp1lEShtOX/YDtRaI7wr45NiBxvJoxbfBTHbAL3s8/WZSnAM6bauHfgqLROL11h9j6IKJz4UsO8CZguPbGy1l7R0alb8NwA/VtInjJQIy7j9f8C+EvI2DC8lG35Bl47x0sdP7jziHKuwFgsAgJJBSVP0seYQHGJqeq4/7v0VAo/VZkp8ugTaNSiASn4127ROv2lpgv2jOxh7fA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1689626387; bh=T8keJWswkczyfyYbyCi3HO6AzTP9WFF6J1CIiaEvsD3=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bToDA9dEPkm02rOQAzOuewea+cqBhMgSbq03fNG4tpej05OcaVT2aendlvthEgbfw+FKhTvKz8ynFxJk5Y+JnpEc5hwPwt8VklUGC9TfiVW54eF1eIGmXnJH48zLk0UoO0nryoPMDk+APWts2q3yMl9k6uTUwN7rnJysEXCzlBX+1muYaT8bAATbFu+Fs43KsasayRc+KmqT13XEClwYbOPq/W+bELzrW+MF9QXbhu3HBDeQO7ptyYEIKNMe9CuMUfvzluVu1k4DqZb/1x/j6wyPfzPv5tWGLbRyyqp231t8Ra/VZ3N7VSLC0OJuHVH7xJ1YWLXSXMl2o1i8/QkKsg== X-YMail-OSG: 3IFfTCgVM1lWU_CYmRCQqv6yVkVjcIzg8Vlht0W9Fc062GehTfqMKyGPglYQdpm R3wZirczd0XlBAt1J6FAHtBn9VJIgvUaYfWsrn_T2RxVpvDuofPjgHrsom3dKtnB_TCHuX8HZLsM lEfT5WO2U0jBJFhB_yWgKvKqg7eX5iBli3fxwLDXb1R7_A67SKTinOFnP4AGiFqpZLHZQjsEFeEu BQmh2Fe7RjssR_AoQADZPlDq.yXfCkk2yJmU3XioSct7QEBVHXtjRfN9koHcwOh_tBFmcsZjmYgd DNtMqvw8UDWLXuC7So7i_lbFidcdtAtE5Fcp9cCVSlWj2bZPIQUcGoKdS7zh2s7Cp0tkg9GV0i.I rbb5Xjm5rBtI9ROWi3aZIHp1DKA0zJvrLR9k8N9SnFFvxmESwPb_NZOovB9FpBNrpNst395mlBAY e8kZBLJnWESCI9JNu10EX_V7ti7ax2D.pKAckD1tvJ7IfLg_lPeAOst3qJ3s4iLX_YS0oS4_lpLa 3kOx7t9aXg7UIqRXgtBHo2RYexpd4alvh2nDnHnY2u1NnOgqSdMJTtXWygtixVI6HWUbEdvB4STQ .bajAALPmPbq4Il5fEjmFbAHvW8vs_eQ2B_7HhJZDf4C0PTY0LJ0qdsk7rtmkFqpr1nMwAb.NY1S nH4iDE.OZybr8l5_8NrgZVI4Z6m2WqxW62Ficfm3YuUeDd4ImgChSld_0QxU4gi_geo4qQ5yGNV4 dE0Ot5_x6__Nktw1bBugcY39Qihb4DjAxiOmoC1y6.O3rH48x.O4b1j0NuXXBTC._a9B2pQ2ZIVd IAJ7TRu8lU5yP2MuWdOsn0ofIhgxvdG7VBNsv.0..Z2Il2G9SFS1BNSb05RFeQnzrdca9ZPtmmhS _WKjlG1.Lx19hAKUxaHN.HJ5tE0nI56Ja1mbT0bOpRhfeEq.PjyBc6dAGwpa_QZzUCsioKWYMFuo DuDi3ncnVhjIiW6wk_d1hwhMzvNYrW8Teomrpb22SUMoJMcgbOR0CQVMmnawryYIIcIl.kRXzO7f RDKPN8FIUap9Qj7QLOVMK65ddi6EWC0TFz_rijdKgSLjThzeOEHl.0wGDlcZVVzPrVXZtg5aErC1 rK4mRU39xU7lJrPXBNxuOu.3kTyHSdWk2BBTUuIAEqaVTKPwwhrd5FecNCtekeizamCTuQcTXCJX EF1pXKuBtaPXKhpRw5ZLZhoXxUhx.H7lBbopy_nTNlmq4VbdiSwPeWqA3AV7rYYOAyoe382QtiH9 Lvy4dVsk1yorsdtJWKAX6DIVC8XgSX4Pr8KE02MCd0ZXmfkH4p90kyA3QgycWfHBin_lctDyDmhP IK8JpLEgeI3miMWi8vdLTW8JUiqzbbvLPeSCjjXD8aon.h9TgPwbxJBEbEvtNvlVbeJUBeJAqsV1 6r6NgSCBAupN055giScIerlq_3VGCgWTbt.4tHXtN08GKmwmSmFRZPyKKsBQSdGgbhoNsXtEDI8V MgEEiDwpxLYgM4FTjRi_GE7vmdaIvk1uqMSwLfH9dlUH2GEeDOZTdnim0.d.wcb0leMrjLmLKTbk e18GNx9hp2deOvo4brNkDtFuuKjGEj_QNqgEWRtusBJ.v7vYBcN4XjWkTllTUWi1KVesEp.vgIMh jd_l4Ef2fVcBmva0LC4F.uAIFHHMO_gAJGSxK6l8NoEp1zT4FcDqMe8Pt19n3N4oTUFFDX61LJ9a nqEYVQ8AVPvT_TUTNlDjxdOUNFsA_45TQwe0jkHhxkIkgm0b5eo8uFXMGQ.c6zd_hsac6u0LSc0h 2JWWqFRm5MlNLMBTYaG.K4IM6NMUulfqepPhD_z0mWZvDqU_9CK_tt0S0IgEUr4oLbHcNvriMCww by70Ka7P_0nCF6awFbjC..yG8vx45vg8QO86KQjgssAVmUQguCH78T_o2sSLlsshKiziUaVL23ed 2cQ.fuoDps2OKZWI2Bj0ZR1HBRlvXfcX0RgcuF6FiWNJeOdWGSEKpR1M0INVy.br9Rm5t0HqWTAH gftqZUWZo01rgz5vw57vlvr2I7K8vRsR4xLpttAGKySBTsUZqr4QakH1_rvRcdWEkU2ydMTn_5TH p0fVgK9mUgwEb6.nH063kNgVed5PJatjuurdxLCMmnDyPdcMorv9O..jCtnI86VLZhwMtx5t_zBp oIuBkLBDKkn0neBVry1cdMd63CaOOm46MDK08pDItX9dWHeiGERkfDokQgH_2Ngj_dNCbAo0Kdrf 74ytqXh52TPLmyM4P.QtEypmKOr4QJw1ytSHSpsG_VriS5M0yrAgbFI4dh0uGOltmrk9XrdQmc3l mLe.bCQ-- X-Sonic-MF: X-Sonic-ID: e5cc5673-b9f8-4a4a-bc0d-11e506f858f6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Mon, 17 Jul 2023 20:39:47 +0000 Received: by hermes--production-gq1-767c8cd9fb-gbtfg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5f329f11cd2261de4d26bd7de4f29491; Mon, 17 Jul 2023 20:39:44 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: Supermicro R12SPD Ampere Altra - No valid device tree blob found From: Mark Millard In-Reply-To: Date: Mon, 17 Jul 2023 13:39:33 -0700 Cc: Warner Losh , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: To: John X-Mailer: Apple Mail (2.3731.600.7) X-Rspamd-Queue-Id: 4R4Yq94Wfcz4Gtv X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jul 17, 2023, at 12:34, John wrote: > ----- Warner Losh's Original Message ----- >> On Mon, Jul 17, 2023 at 11:15=E2=80=AFAM Mark Millard = wrote: >>=20 >>> On Jul 17, 2023, at 09:37, John wrote: >>>=20 >>>> Hi Folks, >>>>=20 >>>> I have a new Supermicro system: >>>>=20 >>>> Supermicro R12SPD BIOS Date:04/26/2023 Rev:1.1a >>>> CPU : Ampere(R) Altra(R) Max Processor >>>>=20 >>>> Booting from the latest media (spot checking older >>>> media makes no difference): >>>>=20 >>>> Boot Media: >>> = FreeBSD-14.0-CURRENT-arm64-aarch64-20230713-510fd8313800-264135-disc1.iso >>>>=20 >>>> Fails here: >>>>=20 >>>> 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 >>>>=20 >>>>=20 >>>> If I break into the loader, the fdt command shows the >>>> same error message. >>>>=20 >>>> OK fdt ls >>>> No device tree blob found! >>>>=20 >>>> OK >>>>=20 >>>> A verbose boot shows no additional information. >>>>=20 >>>> 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. >>>>=20 >>>> Any ideas? Thoughts? >>>=20 >>> 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. >>>=20 >>> I expect that your boot context is UEFI/ACPI and that the message >>> has mislead you about what to look for relative to booting. >>>=20 >>> 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. >>>=20 >>> On the HoneyComb (16 Cortex-A72's), for example, there >>> is the FreeBSD loader's configuration command: >>>=20 >>> 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 >>>=20 >>> For this context, it indicates a UEFI/ACPI boot: note the >>> "ACPI 2.0 Table at". FDT booting would refer to such instead. >>>=20 >>> So you likely can check if you are UEFI/ACPI booting vs. >>> FDT booting. >>>=20 >>> 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. >>>=20 >>=20 >> 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. >>=20 >> Warner >=20 > OK set boot_verbose > OK set kern.cfg.order=3D"acpi,fdt" > OK configuration > NumberOfTableEntries=3D12 > 76b6bdfa-2acd-4462-9e3f-cb58c969d937 at 0xffe88718 > DXE Table at 0xffe84188 > HOB List Table at 0xffc40018 > MemoryTypeInformation at 0xffe865b8 > Debug Image Info Table at 0xffe87380 > 00781ca1-5de3-405f-abb8-379c3c076984 at 0xffd0db98 > ACPI 2.0 Table at 0xffc80000 > a4ee0728-e5d7-4ac5-b21e-658ed857e834 at 0xffd07d18 > SMBIOS3 Table at 0xf8b1ff98 > dcfa911d-26eb-469f-a220-38b7dc461220 at 0xf0c78018 > b122a263-3661-4f68-9929-78f8b0d62180 at 0xfa76bd98 > d742672e-1918-4a66-a1aa-fda807542d81 at 0xf0be0018 So no FDT, just "ACPI 2.0 Table at". That likely implies that set kern.cfg.order=3D"acpi,fdt" makes no difference for the actual context: Always UEFI/ACPI. > OK lsdev =20 > disk devices: > disk0: 1792780 X 512 blocks (removable) > disk0: ISO9660 > disk1: 7501476528 X 512 blocks > disk2: 7501476528 X 512 blocks > disk3: 7501476528 X 512 blocks > disk4: 7501476528 X 512 blocks > http: (unknown) > net devices: > net0: > net1: > net2: > OK boot > 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' Does the media that has the /boot/kernel/kernel that is used above also have a world? I actually have a context in which the used /boot/kernel/ is on separate media than used for the world. (The FreeBSD kernel was the earliest stage that could actually deal with the USB3 port that I wanted to use for the world.) I had to also deal with having/managing /etc/hostid and /boot/entropy on the media used for the /boot/kernel/ . /boot/loader.conf too. Keeping loadable modules uniformly matching the used kernel was also part of managing this odd context. For this context the /boot/loader.conf for the media for the used /boot/kernel/ has: vfs.root.mountfrom=3D"ufs:/dev/gpt/Rock64root" kern.cam.boot_delay=3D10000 vfs.root_mount_always_wait=3D1 The vfs.root.mountfrom redirects the world's root to load=20 from the USB3 drive's partition holding the world. I'm not claiming such notes are your overall solution. But those "can't find" messages may be a clue if they are unexepected. > 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 Serial console possible? Only a video console? There likely are various ways that a video console fails to work, making it not obvious that the boot has actually progressed. Serial console's might have similar issues. Is there some independent evidence that the boot has actually failed vs. its status just not being presented via some form of console? > Any suggestions to track this down? Things must be going > bad pretty quickly. >=20 > Thank, > John >=20 >=20 > It still fails to boot, no output.=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com