From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1UPX9E-0006Yk-Tx for mharc-grub-devel@gnu.org; Tue, 09 Apr 2013 07:55:36 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPX9C-0006VM-4s for grub-devel@gnu.org; Tue, 09 Apr 2013 07:55:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPX9A-0002CB-Kb for grub-devel@gnu.org; Tue, 09 Apr 2013 07:55:34 -0400 Received: from mail-ee0-f48.google.com ([74.125.83.48]:39954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPX9A-0002C2-Af for grub-devel@gnu.org; Tue, 09 Apr 2013 07:55:32 -0400 Received: by mail-ee0-f48.google.com with SMTP id b15so2775779eek.7 for ; Tue, 09 Apr 2013 04:55:31 -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:subject :references:in-reply-to:x-enigmail-version:content-type; bh=kM8oEVZBDTrDl7t783fwOdDxtwgeX8LcsCc14NWMIBA=; b=lYEFv9xOsThrN8tO7F2+VLVVk1zojxXTwxCt+QDlvsTyb08pc9FsigvERM2663Q5// ryuSNInWOJwDefrGlGQHw4bhBa7Bp4CblyWMAvEd9vPi/8wLNmvbKWKHFPEjOhAkBlXq EGeTxa87i2/pU7S5wKlBeSP3qQTlY3f8qDtCEZaoGiox3PPv5Yn7aLtuJwtiaUubpGzt cP22zHiBBZcDVez+OVn4gIrF3QOWlqUlrYF0Q6qUTUwlwu0//hMp18ingzBlUx+zErjK hs5soQIi9noCwcUQCUhR5ykGv+vFTOh+0OJuE0ucCVt8LWym6kVzXA9PVbL8+Gk+CajB TigQ== X-Received: by 10.14.4.69 with SMTP id 45mr59754980eei.0.1365508531495; Tue, 09 Apr 2013 04:55:31 -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 bk42sm19327418eeb.3.2013.04.09.04.55.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 04:55:30 -0700 (PDT) Message-ID: <516401B1.4080404@gmail.com> Date: Tue, 09 Apr 2013 13:55:29 +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 , The development of GRUB 2 Subject: Re: [PATCH 4/7] Support for ARM/U-Boot platforms References: <51635D98.7020901@gmail.com> <20130409113927.GX23069@rocoto.smurfnet.nu> In-Reply-To: <20130409113927.GX23069@rocoto.smurfnet.nu> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig1B559EB9AEE5F380EAFB1A9C" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.125.83.48 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 11:55:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1B559EB9AEE5F380EAFB1A9C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09.04.2013 13:39, Leif Lindholm wrote: > On Tue, Apr 09, 2013 at 02:15:20AM +0200, Vladimir '??-coder/phcoder' S= erbinenko wrote: >>> =3D=3D=3D added directory 'grub-core/kern/arm/uboot' >>> =3D=3D=3D added file 'grub-core/kern/arm/uboot/startup.S' >>> --- grub-core/kern/arm/uboot/startup.S 1970-01-01 00:00:00 +0000 >>> +++ grub-core/kern/arm/uboot/startup.S 2013-03-24 13:03:31 +0000 > [...] >>> + @ Set up a new stack, beyond the end of copied modules. >>> + ldr r3, =3DGRUB_KERNEL_MACHINE_STACK_SIZE >>> + add r3, r1, r3 @ Place stack beyond end of modules >>> + and sp, r3, #~0x7 @ Ensure 8-byte alignment >>> + >>> + @ Since we _are_ the C run-time, we need to manually zero the BSS >>> + @ region before continuing >>> + bl uboot_get_real_bss_start @ zero from here >> >> This start is wrong. Even if modules start later due to alignment, BSS= >> starts at __bss_start. Additional problem is that both __bss_start and= >> _end may be unaligned unless special care is taken (like putting a dum= my >> uint32_t at the beginning of BSS by putting it at the end of startup.S= >> or using ld options) > =20 > My main concern here is getting the module start address right. > But see below. >=20 >>> + ldr r1, =3DEXT_C(_end) @ to here >>> + mov r2, #0 >>> +1: str r2, [r0], #4 >>> + cmp r0, r1 >>> + bne 1b >>> + >>> + @ Global variables now accessible - store kernel parameters in memo= ry >>> + ldr r12, =3DEXT_C(uboot_machine_type) >>> + str r4, [r12] >>> + ldr r12, =3DEXT_C(uboot_boot_data) >>> + str r5, [r12] >>> +=09 >> >> Instead of temporary stashing the values to registers you can just ini= t >> those values in C code to e.g. 0x55aa55aa so they'll be in .data and s= o >> accessible from the very beginning. >=20 > Neat :) > I'll do that. > =20 >>> + b EXT_C(grub_main) >>> + >>> + /* >>> + * __bss_start does not actually point to the start of the runtime >>> + * BSS, but rather to the next byte following the preceding data. >>> + */ >> >> Only modules are aligned. BSS itself is still at _bss. > =20 > My issue with this statement is that this definition of BSS can > include padding before the first symbol inside the BSS. > I accept that it can also contain less-aligned symbols, which is a > problem that I need to handle in the code above. >=20 Actually since BSS surely contains at least one uint32_t its start and has to be aligned to 32-bit. So we can just align_up __bss_start to 4 and _end align_down to 4. This would work correctly enough even with the presence of the bug you rerported to GCC folks. >>> +FUNCTION (uboot_get_real_bss_start) >>> + ldr r0, =3DEXT_C(__bss_start) @ src >>> + tst r0, #(GRUB_KERNEL_MACHINE_MOD_ALIGN - 1) >>> + beq 1f >>> + mvn r1, #(GRUB_KERNEL_MACHINE_MOD_ALIGN - 1) >>> + and r0, r0, r1 >>> + add r0, r0, #(GRUB_KERNEL_MACHINE_MOD_ALIGN) >> >> Can be trivially simplified to: >> mvn r1, #(GRUB_KERNEL_MACHINE_MOD_ALIGN - 1) >> add r0, r0, r1 >> and r0, r0, r1 >=20 > Yes, I may have been a bit silly when writing the above (and now), but > I don't follow (0xfffffff8 + __bss_start) & 0xfffffff8 ? > Do you mean: > mvn r1, #(GRUB_KERNEL_MACHINE_MOD_ALIGN) > add r0, r0, #(GRUB_KERNEL_MACHINE_MOD_ALIGN - 1) > and r0, r0, r1 >=20 Yes, sorry, I proposed it without testing and I'm a beginner in ARM asm. >> which can be then inlined. Also it's more reliable to save grub_modbas= e >> as soon as we computed it in asm part (and use 0x55aa55aa trick to mak= e >> it accessible early) > =20 > OK, that makes sense. And having done that, it can be inlined, since I = no > longer need it from within uboot/init.c. >=20 > / > Leif >=20 --------------enig1B559EB9AEE5F380EAFB1A9C 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/ iF4EAREKAAYFAlFkAbEACgkQNak7dOguQgmIkgD6A4fJPc6VR7e40b8sJhusWS0G 3LFieiPWLBccV/G3XXYA/3GPkoEYoUfXXMhbE0I6TJ+wa/kNzCuO4PxaPPK3NXBy =JsYz -----END PGP SIGNATURE----- --------------enig1B559EB9AEE5F380EAFB1A9C--