[Gta04-owner] QtMoko v44

[Martin Jansa]

On Mon, Apr 23, 2012 at 09:40:02PM +0200, Martin Jansa wrote:
> On Mon, Apr 23, 2012 at 09:10:39PM +0000, Radek Polak wrote:
> > On Sunday 22 April 2012 19:30:02 Martin Jansa wrote:
> > 
> > > There is small issue with ext4, README at
> > > http://sourceforge.net/projects/qtmoko/files/GTA04/
> > > suggests to use ext4 for rootfs, but if you create ext4 partition with
> > > e.g. extents, then booting will fail like this:
> > > EXT3-fs (mmcblk0p2): error: couldn't mount because of unsupported
> > > optional features (240)
> > 
> > Do you have ext4 compiled in your kernel? You must select Y there.
> 
> Yes.. this was because of rootfstype which forced ext3 fs driver to be
> used instead of trying all available fs drivers (e.g. ext2, ext3, ext4.. etc)
>  
> > > because boot.scr as well as default CMDLINE in kernel is passing
> > > "rootfstype=ext3", I've changed defconfig in SHR and will send patch for
> > > boot.scr.
> > 
> > When using gta04-init as initramfs the rootfs and rootfstypes are ignored. 
> > Instead we mount root either according to bootdev file or if the file does not 
> > exist by clicking on icon.
> 
> Right.. but without gta04-init in SHR kernel it was trying to mount real
> rootfs (with qtmoko) just after flashing SHR kernel instead of qtmoko
> kernel.
> 
> gta04-init mounts it correctly, because is's trying fs in order ext4,
> ext3, btrfs.. so my boot.txt patch just makes u-boot doing the same.
> 
> > > so now we have rootfstype=ext4,ubifs,jffs2,btrfs in defconfig
> > > http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=c09e13fa3b
> > > ec89fb51d3f8d5f6d7d8d6f5dbfcde and
> > > setenv mmcrootfstype 'ext4,ext3,btrfs rootwait'
> > > in boot.scr
> > > 
> > > And also uImage should be included in qtmoko-fat-v44.tar.gz because
> > > extload cannot read ext4 partition with rootfs.
> > 
> > Good point, i have updated it and it has uImage now.
> > 
> > > I've added gta04-init to SHR kernel to resolve it
> > > http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=fac33bd0c4
> > > ca2729aae23bcd106793489da26835 but it needs a bit more work, as now it
> > > shows fb ui from initramfs and doesn't switch to xserver.
> > 
> > Nice, btw is there already SHR tarball which i could try?
> 
> Yes, 
> http://build.shr-project.org/shr-core-staging/051/images/
> has right uImage and today new images should be there, but yesterday I
> got some issues with systemd on om-gta04, it seems like vfat partition
> gets broken very soon and systemd switches to emergency mode when it
> cannot mount it (or something like that).

With modified 1.sh for gta04-init it seems to boot more reliable. 
I think that switch to emergency mode was because one of systemd 
units is remounting rootfs.

remount-rootfs.service:
ExecStart=/bin/mount / -o remount

and this is failing when / is just something like chrooted dir
/real-root/distros/SHR

But the same happens with 1.sh too (just not fatal for systemd), 
I'll try to debug what's wrong with systemd when started by run_init().

Cheers,

1.sh:
/fat/gta04-init/busybox echo "booting SHR image"

/fat/gta04-init/busybox echo "mounting rootfs"
/fat/gta04-init/busybox mount -t ext4 /dev/mmcblk0p2 /real-root

/fat/gta04-init/busybox echo "mounting sysfs"
/fat/gta04-init/busybox mount -t sysfs none /real-root/distros/SHR/sys

/fat/gta04-init/busybox echo "mounting proc"
/fat/gta04-init/busybox mount -t proc none /real-root/distros/SHR/proc

/fat/gta04-init/busybox echo "mounting dev"
/fat/gta04-init/busybox mount -t devtmpfs none /real-root/distros/SHR/dev

exec /fat/gta04-init/busybox chroot /real-root/distros/SHR /sbin/init

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20120424/ebb50e8c/attachment.bin>