From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1UPcK3-0005rj-B3 for mharc-grub-devel@gnu.org; Tue, 09 Apr 2013 13:27:07 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39952) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPcJy-0005e7-AX for grub-devel@gnu.org; Tue, 09 Apr 2013 13:27:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPcJw-0000Qy-KX for grub-devel@gnu.org; Tue, 09 Apr 2013 13:27:02 -0400 Received: from mail-ee0-f49.google.com ([74.125.83.49]:49101) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPcJw-0000PY-EP for grub-devel@gnu.org; Tue, 09 Apr 2013 13:27:00 -0400 Received: by mail-ee0-f49.google.com with SMTP id l10so1771644eei.36 for ; Tue, 09 Apr 2013 10:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type; bh=ZtBHWs7OgGkFkf4yKOX1MtxtI28UgwYxm7VKsLx62+E=; b=JSPvrUkjRdpCXE1NWuPqsPrmSfvVlEXcog/DaHg5VyYpHlYKEcPkWhTjhbpbhHQhM5 NrJAd84w6sv9x/YXNrwq8zf/UYZuiJ/P91t0i3pMNCOP0Kts+wIeivmnxN3g2KttG4Sn jbyZg9b6MT+BHQHuPP65i+NN43+yROwCUNIAXlJA2WDB8lNDwjP4WItfg054FdijmiQv BUEPetBczWB4u1/CM6R7Q/RDS7+FKF8BARxEoAcjVqU4zOUnBaB2mJUv3PYj0TC1BevF 2ZuGtIuX9cVDhzWjkd8Whqv/5aPDVFwyDf/LNF69trP0yVdU+PdlJsiwkJB0qcfZ9tPh kJNA== X-Received: by 10.15.35.193 with SMTP id g41mr16929713eev.45.1365528419608; Tue, 09 Apr 2013 10:26:59 -0700 (PDT) Received: from debian.x201.phnet (245-188.1-85.cust.bluewin.ch. [85.1.188.245]) by mx.google.com with ESMTPS id v6sm1057741eel.10.2013.04.09.10.26.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 10:26:58 -0700 (PDT) Message-ID: <51644F61.6040804@gmail.com> Date: Tue, 09 Apr 2013 19:26:57 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Leif Lindholm Subject: Re: [PATCH 4/7] Support for ARM/U-Boot platforms References: <5158EDA7.2040906@gmail.com> <20130403163238.GL23069@rocoto.smurfnet.nu> <5162A054.5090502@gmail.com> <20130409102613.GU23069@rocoto.smurfnet.nu> In-Reply-To: <20130409102613.GU23069@rocoto.smurfnet.nu> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig87FF358826336A0F3B2B13B7" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.125.83.49 Cc: The development of GNU GRUB X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 17:27:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig87FF358826336A0F3B2B13B7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >> Trouble is that grub-install now rightfully warns about the lack of >> platform-specific install. >> What do we have to do to register the image at u-boot? >> Put it in specific location? >=20 > EFI provides three very nice things: > - Standardised partition and filesystem type for bootloaders. > - Standardised runtime services for updating selected boot image. > - Standardised "removable media" bootloader path. >=20 > U-Boot has neither, and different platforms use different mechanisms to= > affect boot images - some "prime" the enviroment with a uEnv.txt, some > search around a predefined set of filesystems for boot scripts, some > require you to manually "setenv" from within U-Boot. Is environment stored in flash? >=20 > Debian use a special package called flash-kernel to abstract these thin= gs > away. >=20 Can we use it? > So in short, I think the only sane thing grub-install can do for arm-ub= oot, > is what I already have it do - generate an image with the required modu= les > embedded. If that's the only thing we do, then the warning should be kept. > Now, maybe it shouldn't be grub/arm-uboot/core.img, but that was > what I ended up using. >=20 I'd prefer to keep this file and make a copy if necessarry. >> Also you spoke about relocatable image but AFAICT header always >> specifies load address. Do you have a way around it? >=20 > Well, it's not so much a way around it as somthing that almost ampounts= > to a new port (certainly a new image type). > The proper fix would be to generate it as an ELF image _instead_, and u= se > U-Boot's ELF loader support to load it properly. >=20 It's not really a new port. We already have ports using several image formats, e.g. i386-pc, sparc64-ieee1275, mips-loongson. Doesn't U-boot terminate services if it loads an ELF? How good is its ELF support? Does it handle relocations correctly? If it doesn't we can use -fPIC for kernel. --------------enig87FF358826336A0F3B2B13B7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAlFkT2EACgkQNak7dOguQgn8hgD/TRZ6cRZ643XfOlzhSgN05Qng LyWaSSqBjSNKc2slPncA/3mZpYKE45PDXnc4ee60E0TX726U8/9UlvYlELwRoZeR =Hyra -----END PGP SIGNATURE----- --------------enig87FF358826336A0F3B2B13B7--