From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <9front-bounces@9front.inri.net>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4
Received: from 9front.inri.net (9front.inri.net [168.235.81.73])
	by inbox.vuxu.org (Postfix) with ESMTP id F1859249F7
	for <ml@inbox.vuxu.org>; Mon, 12 Feb 2024 14:53:30 +0100 (CET)
Received: from ftrv.se ([45.76.35.157]) by 9front; Mon Feb 12 08:52:09 -0500 2024
Message-ID: <C8CFD652C333F402D0024F36F83A9223@ftrv.se>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftrv.se; s=mail2;
	t=1707745926; bh=XJC3R258246ic//M/PdWG4/M4S4mH4elm97DHuSDucU=;
	h=To:Subject:Date:From:In-Reply-To;
	b=KX1ENUoTxudPnlvY0aIkjvKH9K8hvqCT2fqRiR30ZP5FWfKeIqYcuSs3hQ7V+LA6C
	 6+4c9PsPhHR11rnPESNsXGdNynJAPVa5QZ8B/6DPSuU5PEFx6kUB4X/EZT75+9Zspz
	 9JCjuD+CQUksCGF1RjyHM1U5CETajnYcsfy7pB14TDBLccOw2bivnXSR0Ux+nL9G6w
	 /CwsOt4NxRglSSvFA+/qSx4mB7ggTHeGBJI4perG12bgk0izLKQs06JBpbTwuzfXQu
	 uDiNmosYAmIpRySnbXlg37YBsPsfYsowyDRFY0XZxkH8O/XFrzJrkaZ4d8UqofZvnZ
	 3zmPZh5/S/87A==
To: 9front@9front.org
Date: Mon, 12 Feb 2024 14:52:05 +0100
From: =?utf-8?q?Sigrid_Solveig_Hafl=C3=ADnud=C3=B3ttir?= <sigrid@ftrv.se>
In-Reply-To: <1ef18420c4f54c9155a18c7d6dd16ca5@posteo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: map/reduce plugin 
Subject: Re: [9front] Reform MNT Boot Process
Reply-To: 9front@9front.org
Precedence: bulk

Quoth alex-ml@posteo.de:
> My guess would be that flash.bin (built via the mkfile) is loading the 
> kernel with the information from boot.scr (also built via mkfile). Is 
> that right? In this case, the boot process would be a bit easier than 
> described above (at least with fewer steps).

Yes.  flash.bin is U-Boot built for Reform.  It is in turn the one
loading the kernel by following the instructions in boot.txt (which
gets "compiled" into boot.scr).

> In /sys/src/cmd/aux/txt2uimage.c/, which is used in the recipe for 
> boot.scr, there are some numbers that I would like to understand where 
> they come from. Is there some documentation explaining how an uimage and 
> / or header has to look like? Unfortunately I wasn't able to find this 
> information on https://docs.u-boot.org/.
> 
> And the same question for /sys/src/boot/reform/boot.txt/, where some 
> addresses are given. How do I obtain this information?

"uImage" is a wrapper for whichever files you intend to use with
U-Boot.  In this specific case it tells U-Boot it's a "script" file
with a specific load address (where to put the "raw" unwrapped data)
and an entry point (where to start execution from).  I am not sure
where to find any documentation for this besides looking at U-Boot
sources (include/image.h describes a lot of it).

>
> I am very sorry for my beginner questions and I would really appreciate 
> any explanations/hints to help me understand what happens during the 
> boot process.

Don't think it's beginner questions but even if those were, no harm in
asking.