From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1WWE62-0004pc-61 for mharc-grub-devel@gnu.org; Fri, 04 Apr 2014 20:04:30 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33610) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWE5w-0004mq-RG for grub-devel@gnu.org; Fri, 04 Apr 2014 20:04:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WWE5v-0007h7-Kx for grub-devel@gnu.org; Fri, 04 Apr 2014 20:04:24 -0400 Received: from mail-yk0-x233.google.com ([2607:f8b0:4002:c07::233]:54494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWE5v-0007gv-F2 for grub-devel@gnu.org; Fri, 04 Apr 2014 20:04:23 -0400 Received: by mail-yk0-f179.google.com with SMTP id 9so3555479ykp.24 for ; Fri, 04 Apr 2014 17:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HgFs50roe9flkSOaKCvGC4NvwjEs7pU1US1fTq2GC04=; b=fVNlOVV6yH3yH6JNR44jDW1UrtRjvTRRkWmgMUVYJkPg2sU+ubrRLswynZ9QrXYwp6 sBidBHS9htkHMjeTjJf28s6o9NV6MdeBdJpLrBTO3b1Qk92Vb1T4QVykp7l8nNsZzH8D N5FPRbQOuXgqlK1M/XiaxpcxV+e2SFOHnvmhXW3ajsuMFyfvx3zZUMPyDDp8rBsHZuSE nzl1P/F3qSpc/eZAGdTkTBSXaST9TVtkDJSAXCf0o6+XYZPSVSXb3PbuUckOepMDWdOu YmjSzoTuFIQOGb8XLSz4ldXARxwFhYlekXChrI2YMfYh7Ag8UKI5G9PMEeqJRthLO1EI nvBA== MIME-Version: 1.0 X-Received: by 10.236.134.71 with SMTP id r47mr20721631yhi.83.1396656262463; Fri, 04 Apr 2014 17:04:22 -0700 (PDT) Received: by 10.170.65.84 with HTTP; Fri, 4 Apr 2014 17:04:22 -0700 (PDT) Received: by 10.170.65.84 with HTTP; Fri, 4 Apr 2014 17:04:22 -0700 (PDT) In-Reply-To: References: <20140403230329.06d61900@opensuse.site> <20140403192657.GM29218@ram.oc3035372033.ibm.com> <20140403235446.2c69a649@opensuse.site> <20140403203222.GO29218@ram.oc3035372033.ibm.com> <20140404062851.1228cd3b@opensuse.site> <20140404174735.GB16534@ram.oc3035372033.ibm.com> <20140404221744.1ac39311@opensuse.site> <1396635898.2170.12.camel@petersburg.suse.cz> <20140404231223.371fd610@opensuse.site> <1396643353.14361.4.camel@petersburg.suse.cz> <20140404221903.GQ29218@ram.oc3035372033.ibm.com> Date: Sat, 5 Apr 2014 02:04:22 +0200 Message-ID: Subject: Fwd: Re: [RFC PATCH 21/23] powerpc64 is not necessarily BigEndian anymore! :) From: "Vladimir 'phcoder' Serbinenko" To: The development of GRUB 2 Content-Type: multipart/alternative; boundary=bcaec5468c5165c50404f6406081 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4002:c07::233 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: Sat, 05 Apr 2014 00:04:26 -0000 --bcaec5468c5165c50404f6406081 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ---------- Forwarded message ---------- From: "Vladimir 'phcoder' Serbinenko" Date: 5 Apr 2014 01:45 Subject: Re: [RFC PATCH 21/23] powerpc64 is not necessarily BigEndian anymore! :) To: "Ram Pai" Cc: On 5 Apr 2014 00:19, "Ram Pai" wrote: > > On Fri, Apr 04, 2014 at 10:29:13PM +0200, Dinar Valeev wrote: > > On Fri, 2014-04-04 at 23:12 +0400, Andrey Borzenkov wrote: > > > =D0=92 Fri, 04 Apr 2014 20:24:58 +0200 > > > Dinar Valeev =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > > > > > > > > > Right, my mistake. I recall a message message with 64bit LE patches. But > > > > seems that came from somewhere else. > > > > > > > > Long story short. With 32Bit BE stage one I had several issues like > > > > accessing btrfs and booting from media. I gave up on my hack, and now > > > > use proposed patches (64Bit LE). > > > > > > > > > > Well, then this is the real bug that has to be fixed. btrfs driver is > > > supposed to be endian-clean. > > > > > > Did you try to disable SUSE btrfs patch to verify? There is at least one > > > suspicious place > > > > > > + tree =3D grub_le_to_cpu64(data->sblock.root_tree); > > > + err =3D get_fs_root(data, tree, grub_cpu_to_le64(GRUB_BTRFS_FS_TREE_OBJECTID), > > > + 0, &fs_root); > > > > > > get_fs_root expects "tree" in on-disk format, not in CPU format. > > > > > > +get_fs_root(struct grub_btrfs_data *data, grub_uint64_t tree, > > > + grub_uint64_t objectid, grub_uint64_t offset, > > > + grub_uint64_t *fs_root) > > > ... > > > > > > + err =3D lower_bound(data, &key_in, &key_out, tree, > > > + &elemaddr, &elemsize, &desc, 0); > > > > > > and lower_bound converts fourth argument again > > > > > > lower_bound (struct grub_btrfs_data *data, > > > const struct grub_btrfs_key *key_in, > > > struct grub_btrfs_key *key_out, > > > grub_uint64_t root > > > ... > > > grub_disk_addr_t addr =3D grub_le_to_cpu64 (root); > > Huh... I can give it a try, if time permits. > > If this works; assuming all the libgcc calls have been replaced > appropriately with native code, there is no strong reason; that I > can think off, to do 64bit LE grub. May the best solution win. > > However in the long run, it does constrain grub bootloader from using > any libgcc calls, thus impeding easy extensibility in the future for > this architecture. > There are other reasons to replace libgcc as well. Main one is that libgcc may be compiled with options that use instructions unavailable at runtime. It already happened with libgcc using fpu for divisions. Adding libgcc functions as needed is already needed so maintaining increase ia small. > RP > --bcaec5468c5165c50404f6406081 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
---------- Forwarded message ----------
From:= "Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com>
Date: 5 Apr 2014 01:45
Sub= ject: Re: [RFC PATCH 21/23] powerpc64 is not necessarily BigEndian anymore!= :)
To: "Ram Pai" <linuxram= @us.ibm.com>
Cc:


On 5 Apr 2014 00:19, "Ram Pai" <linuxram@us.ibm.com> wrote:
>
> On Fri, Apr 04, 2014 at 10:29:13PM +0200, Dinar Valeev wrote:
> > On Fri, 2014-04-04 at 23:12 +0400, Andrey Borzenkov wrote:
> > > =D0=92 Fri, 04 Apr 2014 20:24:58 +0200
> > > Dinar Valeev <dvaleev@suse.de> =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> > >
> > > >
> > > > Right, my mistake. I recall a message message with 64bi= t LE patches. But
> > > > seems that came from somewhere else.
> > > >
> > > > Long story short. With 32Bit BE stage one I had several= issues like
> > > > accessing btrfs and booting from media. I gave up on my= hack, and now
> > > > use proposed patches (64Bit LE).
> > > >
> > >
> > > Well, then this is the real bug that has to be fixed. btrfs = driver is
> > > supposed to be endian-clean.
> > >
> > > Did you try to disable SUSE btrfs patch to verify? There is = at least one
> > > suspicious place
> > >
> > > + =C2=A0tree =3D grub_le_to_cpu64(data->sblock.root_tree)= ;
> > > + =C2=A0err =3D get_fs_root(data, tree, grub_cpu_to_le64(GRU= B_BTRFS_FS_TREE_OBJECTID),
> > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A00, &fs_root);
> > >
> > > get_fs_root expects "tree" in on-disk format, not = in CPU format.
> > >
> > > +get_fs_root(struct grub_btrfs_data *data, grub_uint64_t tre= e,
> > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0grub_uint64_t obj= ectid, grub_uint64_t offset,
> > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0grub_uint64_t *fs= _root)
> > > ...
> > >
> > > + =C2=A0err =3D lower_bound(data, &key_in, &key_out,= tree,
> > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0&elemaddr, &elemsize, &desc, 0);
> > >
> > > and lower_bound converts fourth argument again
> > >
> > > lower_bound (struct grub_btrfs_data *data,
> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0const struct= grub_btrfs_key *key_in,
> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct grub_= btrfs_key *key_out,
> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0grub_uint64_= t root
> > > ...
> > > =C2=A0 grub_disk_addr_t addr =3D grub_le_to_cpu64 (root); > > Huh... I can give it a try, if time permits.
>
> If this works; assuming all the libgcc calls have been replaced
> appropriately with native code, there is no strong reason; that I
> can think off, to do 64bit LE grub. =C2=A0May the best solution win. >
> However in the long run, it does constrain grub bootloader from using<= br> > any libgcc calls, thus impeding easy extensibility in the future for > this architecture.
>
There are other reasons to replace libgcc as well. Main one is that libgcc = may be compiled with options that use instructions unavailable at runtime. = It already happened with libgcc using fpu for divisions. Adding libgcc func= tions as needed is already needed so maintaining increase ia small.
> RP
>

--bcaec5468c5165c50404f6406081--