From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 648 invoked from network); 8 Apr 2021 14:28:10 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 8 Apr 2021 14:28:10 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 1ess; Thu Apr 8 10:21:36 -0400 2021 Message-ID: Date: Thu, 08 Apr 2021 16:21:24 +0200 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: enhancement SSL over ACPI service information element event controller Subject: Re: [9front] PXE booting Rpi Reply-To: 9front@9front.org Precedence: bulk you have to distinguish the bcm and bcm64 kernels. in bcm64, a arm64 kernel, device tree is passed in R0. the devicetree support was implemented for raspberry pi 4 as the newer firmware didnt provide atags. and we also need devicetree now as they move the pci windows around in physical memory depending on the model (cm4, pi400). in the 32 bit bcm kernel, the ATAGS where always located at a fixed memory location 0x100. devicetree was not used. it is possible that this assumption doesnt hold anymore and now atags are at a variable address passed in R2 as you say? note, i didnt come up with this logic. and didnt pay too much attention on the 32 bit bcm kernels and their newer firmware incarnations. it might be confusinbg as bcm/bootargs.c is shared between the bcm and bcm64 kernels. -- cinap