From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1UPBgI-0004ni-Vs for mharc-grub-devel@gnu.org; Mon, 08 Apr 2013 09:00:19 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPBgB-0004lB-23 for grub-devel@gnu.org; Mon, 08 Apr 2013 09:00:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPBg6-0008He-MO for grub-devel@gnu.org; Mon, 08 Apr 2013 09:00:11 -0400 Received: from mail-ee0-f41.google.com ([74.125.83.41]:33448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPBg6-0008FJ-EC for grub-devel@gnu.org; Mon, 08 Apr 2013 09:00:06 -0400 Received: by mail-ee0-f41.google.com with SMTP id c1so2388755eek.28 for ; Mon, 08 Apr 2013 06:00:05 -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=VuX7rq//XHGqU3Rb/o8P5fBTUeXSEEx1KumxGULr+Og=; b=jibNtpbER4+26JSCGLWTz7ld89dbsmVINvsaVHaIRVlkpIqt+8EwE2bzbHV2PF94SU cCuEK0/CUQ+4HlaqqlP2im3GuF+jc4uBfdX7QXqkCVCcLdv2b2CEg/u8gWvsocNMN9R5 xZOd6Ec6B5Il5W7W7Fv0an8zAIUKCsc5PNv1EUZVDqEng6MpG4ltwHVBcUnce7EXd9Mn Y/94joKLg6u3CWTceaZFbqoUDfiOIsfLAMUmM93UO0+erVYdHA7QVWiVL3Y4K4V9RQM7 G7125zjY2wmf8DVsUz70XAKQRIuyscO42lbAJqh1zRsgfWlIZhtHZceAr90sTMVMRQt4 1LCQ== X-Received: by 10.15.43.132 with SMTP id x4mr48887303eev.31.1365426005440; Mon, 08 Apr 2013 06:00:05 -0700 (PDT) Received: from debian.x201.phnet (13-234.197-178.cust.bluewin.ch. [178.197.234.13]) by mx.google.com with ESMTPS id q5sm31901999eeo.17.2013.04.08.06.00.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Apr 2013 06:00:04 -0700 (PDT) Message-ID: <5162BF4F.3090307@gmail.com> Date: Mon, 08 Apr 2013 14:59:59 +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: Raspberry pi support References: <5161AAE3.6050403@gmail.com> <20130408114445.GS23069@rocoto.smurfnet.nu> In-Reply-To: <20130408114445.GS23069@rocoto.smurfnet.nu> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig430BB504A8A97D36BE3B226B" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.125.83.41 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: Mon, 08 Apr 2013 13:00:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig430BB504A8A97D36BE3B226B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08.04.2013 13:44, Leif Lindholm wrote: > On Sun, Apr 07, 2013 at 07:20:35PM +0200, Vladimir '??-coder/phcoder' S= erbinenko wrote: >> Based on Leif Lindholm's patches I could go to GRUB console on raspber= ry pi. >> The biggest problem is that cache flushing is simply skipped. Another >> problem is that due to different linux image format linux loader doesn= 't >> work. >=20 > Is this because you're feeding it a uImage? > It is entirely possible to runtime detect the U-Boot signature, and sim= ply > skip the header. >=20 The kernel shipped with raspbian aren't uImages. they are with some kind of raspberry stuff in it. They have to be loaded at 0 with entry point at 0. u-boot is available for raspberry pi but isn't used by default. >> I didn't test grub-install but fed GRUB to uboot using kermit. >> Is there any advantage in building armv6 binary by default unless user= >> overrides through TARGET_CFLAGS? >=20 > I think it would get messy: the barrier operations supported by ARMv6 a= re > deprecated in ARMv7. >=20 The questions basically would be how we switch between armv6 and armv7. I see as possibilities: defining target_cpu of armv6 and armv7, so it will give 4 ports armv[67]-(uboot|efi). Another possibility is to decide on runtime but it's probably more difficult. > I would suggest an alternative approach, which is to build all of the > assembly in "arm" state, and to keep the generic functionality to an > ARMv6 subset. >=20 Do we lose anything by not supporting thumb2 for assembly? What armv7 functionality is useful? >> =3D=3D=3D modified file 'conf/Makefile.common' >> --- conf/Makefile.common 2013-04-07 00:41:07 +0000 >> +++ conf/Makefile.common 2013-04-07 16:08:07 +0000 >> @@ -40,8 +40,7 @@ >> if COND_arm >> # Image entry point always in ARM (A32) state - ensure proper functio= nality if >> # the rest is built for the Thumb (T32) state. >> - CFLAGS_PLATFORM +=3D -mthumb-interwork -mno-unaligned-access -mlong= -calls >> - CCASFLAGS_PLATFORM =3D -Wa,-mimplicit-it=3Dthumb >> + CFLAGS_PLATFORM +=3D -mthumb-interwork -march=3Darmv6 -mlong-calls >> LDFLAGS_PLATFORM =3D -Wl,--wrap=3D__clear_cache >> endif > =20 > -mno-unaligned-access is required to function on platforms that do not > have caches/MMU enabled at this point. They do exist, so please leave i= t in. My compiler simply doesn't know this option. I suppose it always assumes that no unaligned access is available. Availability of this option must be detected on configure time. >=20 > And for reasons stated above, -march=3D should be set to whatever your > target architecture is. Extracted by configure, I suppose? Hence --target-cpu=3Darmv[67] proposal.g --------------enig430BB504A8A97D36BE3B226B 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/ iF4EAREKAAYFAlFiv08ACgkQNak7dOguQgnVzAD8CsJU/wE4ZSGalViIibExO3fn z7yxEzBXs0OGTtuq6q8A/A5HwpX71qbUoVjQmlkgBUQA6mXoycYH+MAaBhL4tXu3 =QMeN -----END PGP SIGNATURE----- --------------enig430BB504A8A97D36BE3B226B--