From owner-freebsd-arm@freebsd.org Wed Nov 23 15:49:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62AF8C515BC for ; Wed, 23 Nov 2016 15:49:09 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 009AA269 for ; Wed, 23 Nov 2016 15:49:08 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 5f42bd0d-b194-11e6-b17f-19517aec265d X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 5f42bd0d-b194-11e6-b17f-19517aec265d; Wed, 23 Nov 2016 15:49:10 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uANFmvsT003902; Wed, 23 Nov 2016 08:48:57 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1479916137.1889.28.camel@freebsd.org> Subject: Re: How do U-boot and SPL compare to an IML and an IPL on a mainframe? From: Ian Lepore To: John.Kitz@xs4all.nl, "'freebsd-arm'" Date: Wed, 23 Nov 2016 08:48:57 -0700 In-Reply-To: <000501d24576$ac4339b0$04c9ad10$@Kitz@xs4all.nl> References: <000501d24576$ac4339b0$04c9ad10$@Kitz@xs4all.nl> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 15:49:09 -0000 On Wed, 2016-11-23 at 11:45 +0100, John W. Kitz wrote: > Hi, > > While I'm waiting for the delivery of my first ARM based board, I was > wondering if someone would be kind enough to provide a brief > explanation (or > a link to one) of how U-boot and SPL (and related software) in de > UNIX > world, required in the process of starting up some systems, compare > to an > Initial Microcode Load (IML) and an Initial Program Load (IPL) in the > world > of mainframes. > > In others words am I correct in assuming that U-boot more or less > does what > an IML does and that SPL more or less does what an IPL does? > > Thanks and regards, Jk. Heh.  IPL.  That brings back memories.  Old old memories. Typically a modern arm SOC has a little bit of ROM code, just enough to read a small initial bootcode from a few selected devices (sdcard, eeprom, spi flash, etc).  Very often that small initial bootcode is loaded into some on-chip SRAM and that's what limits the size of the initial bootcode.  In the u-boot world, that small bootcode is SPL.  Another thing that's often true is that the arm core is running on some slow clock at this point, usually 32KHz, sometimes 24MHz. On many systems, the SPL code is responsible for configuring clocks and DRAM.  The SPL code also has larger and more-complete device drivers so that it can load the next stage from a wider variety of devices.  The next stage gets loaded into DRAM and typically runs with the cpu at or near full speed, caches enabled, etc. The next stage in some systems is the kernel.  That's especially true on things like phones where the boot process has to be so fast you don't even notice it.  On more general-purpose systems the next stage is u-boot, which does further system configuration and then continues by loading the next stage loader (which in freebsd is ubldr, a u-boot aware form of loader(8)). All in all, rather than IML (which has no analog on small arm chips) and IPL, a better analogy for the role of u-boot is that of a PC BIOS.  It's responsible for basic system hardware bringup and getting the next stage of bootloader running.  Like a pc bios, u-boot is still around while that next stage loader is running, and it can provide basic services for that loader such as a low-level device IO API.  Unlike a pc bios, however, there comes a time when u-boot is just gone; it doesn't hang around providing services forever. -- Ian