Get Your XDA 2015 Custom Avatar and Signature Images Here

As stated in our motto, XDA Developer is for developers, by developers. The … more

Pin Your Photos on Android Lollipop with Photo Pinner

In the last few weeks,we have been talking quite a bit about Android 5.0 Lollipop. This … more

Samsung Galaxy Note Edge Hands On – XDA TV

Perhaps one of the more peculiar announcements this year was the curved edge-screened … more

Nova Launcher Update Brings Lollipop Functionality and Feel

One of the most popular third party launcher on Android, Nova Launcher, has just … more
Post Reply

Ext4 fs?

OP rcgabriel

30th December 2010, 03:41 PM   |  #1  
OP Senior Member
Thanks Meter: 139
 
450 posts
Join Date:Joined: May 2010
Just a quick thought - I was trying to figure out if I might get somewhat better filesystem performance out of ext4 rather than ext3 for the user data partition. As a first pass, I compiled a kernel with ext4 enabled, and tried to change my boot partition init.rc to mount /data as an ext4 partition rather than an ext3 - my understanding is they should be mount-compatible even without repartitioning.

The result of this was a bootloop. Had to reflash back to a working boot.img. Didn't do anything bad to my /data partition though.

Any ideas why this might be happening? Is there a way to grab dmesg from a boot looping kernel on Android?
30th December 2010, 07:40 PM   |  #2  
Junior Member
Thanks Meter: 20
 
19 posts
Join Date:Joined: Nov 2010
Donate to Me
I've found the following procedures to be helpful in debugging custom kernels.

First, remove the fbcon.c patch in the kernel source (you can just edit the one line that gets modified and uncomment it):


Code:
nano drivers/video/console/fbcon.c
Search for "navy", then uncomment the line:

Code:
update_screen(vc);
Rebuild your kernel. Now you'll have the ability to get a framebuffer console, if your kernel command line arguments are correct. You have to supply custom kernel command line arguments when using mk-boot-img. I use the following when using mk-boot-image:

Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "mem=448M@0M nvmem=64M@448M vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:16384K@12032K(misc),16384K@62208K(recovery),16384K@79104K(boot),273536K@96000K(system),153728K@370048K(cache),4096K@7424K(bootbmp),32768K@28928K(logodata)" -o boot.img
The important part there is changing the console parameter from the default ttyS0 to tty0.

I make separate boot images when debugging - one that executes a shell in the initial ramdisk, and one that doesn't. To get a shell in the initrd, which you'll want to do in this case to figure out your mount issue, is change the above mkbootimg --cmdline parameter:

Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "break=top mem=448M@0M nvmem=64M@448M vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:16384K@12032K(misc),16384K@62208K(recovery),16384K@79104K(boot),273536K@96000K(system),153728K@370048K(cache),4096K@7424K(bootbmp),32768K@28928K(logodata)" -o boot.img
Notice the "break=top". This will give you a command shell before anything in initrc has been executed. You could also use "break=bottom" or "break=init" to get you to different spots in initrc.

Hope that helps! Happy hacking!
The Following 2 Users Say Thank You to jersacct For This Useful Post: [ View ]
30th December 2010, 07:42 PM   |  #3  
Junior Member
Thanks Meter: 20
 
19 posts
Join Date:Joined: Nov 2010
Donate to Me
Oh, and I forgot to mention that a usb keyboard is very handy after you get a shell
5th January 2011, 01:14 PM   |  #4  
OP Senior Member
Thanks Meter: 139
 
450 posts
Join Date:Joined: May 2010
Quote:
Originally Posted by jersacct

I've found the following procedures to be helpful in debugging custom kernels.

First, remove the fbcon.c patch in the kernel source (you can just edit the one line that gets modified and uncomment it):


Code:
nano drivers/video/console/fbcon.c
Search for "navy", then uncomment the line:

Code:
update_screen(vc);
Rebuild your kernel. Now you'll have the ability to get a framebuffer console, if your kernel command line arguments are correct. You have to supply custom kernel command line arguments when using mk-boot-img. I use the following when using mk-boot-image:

Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "mem=448M@0M nvmem=64M@448M vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:16384K@12032K(misc),16384K@62208K(recovery),16384K@79104K(boot),273536K@96000K(system),153728K@370048K(cache),4096K@7424K(bootbmp),32768K@28928K(logodata)" -o boot.img
The important part there is changing the console parameter from the default ttyS0 to tty0.

I make separate boot images when debugging - one that executes a shell in the initial ramdisk, and one that doesn't. To get a shell in the initrd, which you'll want to do in this case to figure out your mount issue, is change the above mkbootimg --cmdline parameter:

Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "break=top mem=448M@0M nvmem=64M@448M vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:16384K@12032K(misc),16384K@62208K(recovery),16384K@79104K(boot),273536K@96000K(system),153728K@370048K(cache),4096K@7424K(bootbmp),32768K@28928K(logodata)" -o boot.img
Notice the "break=top". This will give you a command shell before anything in initrc has been executed. You could also use "break=bottom" or "break=init" to get you to different spots in initrc.

Hope that helps! Happy hacking!

Hey jersacct, so I've tried this (recompiled with your suggested patch, then made new boot image with the last set of params you mentioned) and I absolutely see the framebuffer scrolling by rapidly right after the Viewsonic Birds display. However, I never get the break into console - the FB scrolls by very quickly, then I get the GTabDevs boot image for about 2 seconds, then I boot loop again.

Any ideas? I have tried both the break=top and break=init variants of that mkbootimg command line with no success.

EDIT: I tried with a known-good ramdisk image too. The boot.img boots fine, but again I never get dropped to console.
Last edited by rcgabriel; 5th January 2011 at 01:39 PM.
5th January 2011, 01:54 PM   |  #5  
OP Senior Member
Thanks Meter: 139
 
450 posts
Join Date:Joined: May 2010
Hmm, I suspected the issue might be that the default config has a pesky setting called CONFIG_CMDLINE="" that could be force-overriding any command line passed to the kernel from the boot image. Tried again with that line commented out, and still didn't have any luck getting the break= command to do anything.

I could probably try forcing the command line from CONFIG_CMDLINE but not sure why that would be different from passing it in mkbootimg...

EDIT: nope, I tried that too. Doesn't make a difference. So I assume it's receiving the CMDLINE just fine. For some reason break=top isn't giving me a console. I also tried it with my USB keyboard already plugged in to see if that was making a difference with the input devices, and still no console.
Last edited by rcgabriel; 5th January 2011 at 03:35 PM.
5th January 2011, 06:18 PM   |  #6  
OP Senior Member
Thanks Meter: 139
 
450 posts
Join Date:Joined: May 2010
Still no luck on the debug console. At my wit's end on that. All I can say is that on a regular boot with ext3 mounting my /data partition I see that the partition is dirty and the first mount attempt fails. Second attempt seems to succeed. Says I need to fsck my data partition - which I'd do, but our busybox doesn't seem to support fsck.

Anybody know where I can find a busybox binary that properly supports fsck for ext2/3 and also has mkfs.ext4? I know the Archos guys seem to have one and that's an ARM v9 device so it should work, but I'm having trouble finding it (I even downloaded the "SDE" firmware from the Archos site).

I think the reason the ext4 driver is probably just that it's dirty, though I can't confirm that without the damned debug console.

If I can get an up-to-date busybox on here, I suspect this will just start working magically, without further ado. Ideas are appreciated, either on busybox binaries or on getting the initramdisk console stuff that jersacct posted to work.
6th January 2011, 02:11 AM   |  #7  
Senior Member
Thanks Meter: 26
 
225 posts
Join Date:Joined: Dec 2010
These guys can help you:
http://forum.xda-developers.com/showthread.php?t=895599

And it makes a HUUUUGE difference...
6th January 2011, 04:08 AM   |  #8  
Junior Member
Thanks Meter: 20
 
19 posts
Join Date:Joined: Nov 2010
Donate to Me
Quote:
Originally Posted by rcgabriel

Still no luck on the debug console. At my wit's end on that. All I can say is that on a regular boot with ext3 mounting my /data partition I see that the partition is dirty and the first mount attempt fails. Second attempt seems to succeed. Says I need to fsck my data partition - which I'd do, but our busybox doesn't seem to support fsck.

Anybody know where I can find a busybox binary that properly supports fsck for ext2/3 and also has mkfs.ext4? I know the Archos guys seem to have one and that's an ARM v9 device so it should work, but I'm having trouble finding it (I even downloaded the "SDE" firmware from the Archos site).

I think the reason the ext4 driver is probably just that it's dirty, though I can't confirm that without the damned debug console.

If I can get an up-to-date busybox on here, I suspect this will just start working magically, without further ado. Ideas are appreciated, either on busybox binaries or on getting the initramdisk console stuff that jersacct posted to work.

You know, I didn't think to mention that I was using the Karmic ramdisk image - I bet our stock ramdisk image doesn't have breakpoints setup in initrc. You can grab a copy of a stock initrd image here:
http://www.retardedrobot.com/karmic-initrd-orig.gz

Then just use it instead of the stock ramdisk image when using mkbootimg. Please note, I hardcoded mine to get root to work off the SD card. I think this is an unmodified initrd, so it may work straight out of the box (and boot android if allowed). You might have problems with it though, and may need to unpack it, edit some scripts (for mounting root, etc) and repackage it.

Hope that helps.
6th January 2011, 04:50 AM   |  #9  
OP Senior Member
Thanks Meter: 139
 
450 posts
Join Date:Joined: May 2010
Quote:
Originally Posted by stanglx

These guys can help you:
http://forum.xda-developers.com/showthread.php?t=895599

And it makes a HUUUUGE difference...

Yeah, I've seen the thread before.

I think I was just exhausted and bleary eyed earlier and completely frustrated.

Now that I'm a little more clear-headed, things are much easier.

I've snagged the busybox build out of the Archos initramfs. It indeed does all the ext4 stuff.
6th January 2011, 04:51 AM   |  #10  
OP Senior Member
Thanks Meter: 139
 
450 posts
Join Date:Joined: May 2010
Quote:
Originally Posted by jersacct

You know, I didn't think to mention that I was using the Karmic ramdisk image - I bet our stock ramdisk image doesn't have breakpoints setup in initrc. You can grab a copy of a stock initrd image here:
http://www.retardedrobot.com/karmic-initrd-orig.gz

Then just use it instead of the stock ramdisk image when using mkbootimg. Please note, I hardcoded mine to get root to work off the SD card. I think this is an unmodified initrd, so it may work straight out of the box (and boot android if allowed). You might have problems with it though, and may need to unpack it, edit some scripts (for mounting root, etc) and repackage it.

Hope that helps.

Ahh, this explains why it doesn't work. Thanks so much, I'll take a crack, but hopefully I can clean up my /data partition into a proper ext4 partition with busybox and get it mounting now. I'll see tomorrow, too tired tonight.

Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes