FORUMS

OnePlus 2 Forums: Discuss Everything About The OP2!

Now that the OnePlus 2 has been officially unveiled and that we have had close-up … more

Intel & Micron Announce “Revolutionary” Storage Tech

Intel & Micron have announced 3D Xpoint technology—”the … more

Google Now Interfaces With Third-Party Messaging Apps

Google has announced that Ok Google voice commands can now be used to send … more

Make Your Lockscreen More Productive With Widgets

Are you running Android Lollipop? Do you miss the ability to add widgets to your lock … more

Ext4 fs?

450 posts
Thanks Meter: 139
 
By rcgabriel, Senior Member on 30th December 2010, 03:41 PM
Post Reply Subscribe to Thread Email Thread
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
 
Donate to Me
More
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
 
Donate to Me
More
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
 
More
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
 
More
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
 
More
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: 37
 
More
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
 
Donate to Me
More
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
 
More
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
 
More
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.
6th January 2011, 11:16 PM |#11  
OP Senior Member
Thanks Meter: 139
 
More
Ba...ZING! Finally got ext4 driver working properly. Figured out what was causing the bootloops before, I think - or at least localized the issue.

Running an e2fsck and disabling inandop.sh seems to have done the trick. I think one of the checks in inandop.sh was triggering a reboot. My init.rd now successfully mounts /data as an ext4 partition, mount reports the partition as ext4.

What I need to do now is try to clean up inandop.sh so it properly uses the right binaries to set up the partition as a true ext4. Currently just mounting an ext3 partition with the ext4 driver.

So far no significant performance boost in Quadrant, it's within 50 points of where it was before. But I'm not done yet.

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

Advanced Search
Display Modes