Re: [RFC PATCH 21/23] powerpc64 is not necessarily BigEndian anymore! :)

[Ram Pai]

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:
> > В Fri, 04 Apr 2014 20:24:58 +0200
> > Dinar Valeev <address@hidden> пишет:
> > 
> > > 
> > > 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 = grub_le_to_cpu64(data->sblock.root_tree);
> > +  err = 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 = 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 = 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.

RP