From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 2 Dec 2014 09:21:47 -0600 Message-ID: From: Steven Stallion To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] Porting plan9 Topicbox-Message-UUID: 3201f1bc-ead9-11e9-9d60-3106f5b1d025 On Tue, Dec 2, 2014 at 8:10 AM, erik quanstrom wrote: >> One of the functions u-boot performs is configuring the various subsystems >> in the SoC (individual clocks and power settings for subcomponents, gpio >> pin functions, ...) -- things a BIOS would do in a more old-timey computer. >> In my experience these are typically undocumented (or worse, incorrectly >> documented), so doing this initialisation in Plan 9 would require reverse >> engineering of u-boot to figure out what to do. It's easier just to be >> lazy and let u-boot do it. > > that's interesting. with the marvell chip and board i had, there was almost no > setup code required. and what setup code there was, the hardware guy had got > wrong. That project was a little different. Off the shelf SoC's (particularly those targeted for mobile) usually have firmware blobs that have to be loaded at specific addresses, (undocumented) clock trees, signed stage 1 loaders, and other bits. Many times, using u-boot is your only choice. You can pick apart the source if you like, but honestly why do the work? I'm more interested in porting the kernel than writing a bootloader. Frankly, purity in a software system only exists if you've also designed the hardware. Steve