[TECH] Discussion about bootloader

[Guest t0mm13b]

Have been mulling over this one a lot ...

This is a technical discussion that is warranted to help some kernel devs purely for porting kernels and would like some input/feedback into this in relation to bootloaders and all sorts...

How the bootloader works is this:

Bootloader is in fact called lk (Little Kernel), some say Little-endian kernel, this is the guts and framework for running the minute the power switch is on.

It is in that lk, that determines two main outcomes:

1. If Volume+Down key is pressed, lk loads the recovery rom and initializes the stack, memory, load the recovery kernel (Clockworkmod's 2.6.32-9) and jumps into it.
   
2. No keys pressed, lk will initialize, stack, memory, irqs, and load the rom's kernel and jumps into it.
   

The intriguing thing about this lk, is since the source is there, and for the benefit of kernel devs, could be hacked to be able to capture the logging of the boot process without the need of soldering and what-nots. Even more so, there's a file (I believe that is used by the flashing tool that wbaw and co put together - converting Gen1 to Gen2), appsboot.mbn, now according to one of the comments in the above linky, that is where lk is stored. Question is, can this be modified to include a modified lk embedded in the file, okay, there may be some headers or signatures that the blade's internal boot mechanism checks for prior to loading lk.

I am thinking of a way into how to accomplish this - but need to take into account of wbaw's TPT method for conversion of Gen1 to Gen2, like overwrite the existing appsboot.mbn with a new enhanced version and dump it into the special partition where it resides in.

A big what-if scenario... follows: if lk can be made to set up a dummy console/serial port and trick the ROM (by ROM am talking about CM7, SS5 etc...) kernel into thinking that there's a serial port hooked up or a console is hooked up, and the ROM kernel can then spit out info into that dummy console/serial port, lk in turn can read from that and capture the information and dump it into the sdcard?

This would be a big life saver especially if trying to determine whereabouts the kernel has hung or boot-looped...

I am constantly frustrated at the lack of in not-having the expertise of electronics to perform any soldering to obtain the information on why the kernel is booting or not.

Please post suggestions/thoughts ideas etc...

I am quoting this from the linky above if anyone is interested

Petri Nieminen says:

August 12, 2010 at 10:21 am

Hi Chandra, use

git clone git://codeaurora.org/kernel/lk.git –no-checkout

cd lk

git checkout origin/froyo -b foo

And this is the original creator of lk and what he says

Travis Geiselbrecht says:

March 7, 2011 at 2:51 am

Hi all,

It’s quite amazing to see what folks have done with the LK kernel I hacked together a few years back for my own edification. The Android guys took it and added some bootloader stuff to it and it ended up getting pulled into this project. Neato. The original git repo is at git://git.newos.org/lk.git

It is also the basis for all of the webos bootloaders at Palm/HP now too, though that project is admittedly somewhat farther along than this one as far as features, but HP doesn’t seem to feel the need to push the code back, so it’s mostly a matter of reimplementing features needed here.

As far as licenses are concerned, I originally licensed the source under the MIT license, so you can pretty much do whatever you want with it. If you jam some GPL code into it then you’ll have to release the whole thing, etc. If you take it, hack it up, and never give back to the world, so be it.

Have fun!

Travis

Now, this is the bit that says it all

Ajay Dudani says:

March 22, 2010 at 10:20 am

>> SNIP <<

As for initializations for development board vs. commercial devices – OEMs have access to all the source code and they are free to modify it. OEMs completely control what goes on their commercial devices. So the code and assumptions in code on development boards vs. commercial devices may not always match.

Important point noted here:

appsboot.mbn is apps bootloader (Little kernel) elf file wrapped around a proprietary header that is needed by early boot chain that loads apps boot loader.

All the above quotes are from the comments section found in the above linky.

Cheers :unsure:

[Guest fonix232]

Wasn't qcsbl and oemsbl what are the primary bootloaders (flashable)? And oemsbl is what enables/disables modes (VolUp/VolDown + PowerOn)?

SBL is the secondary bootloader what handles these stuff AFAIK.

EDIT:

Some moar stuff:

<fonix232> just disassembled appsboot

<t0mm13b> and...

<fonix232> you've never seen such a complex assemtree

<t0mm13b> its probably laid out like this

<t0mm13b> signature (length unknown) + binary dump of lk

<t0mm13b> may be more I'd say

<fonix232> signature is the hdr file, nope?

<t0mm13b> hdr is wrong terminology to use

<fonix232> then what it is?

<t0mm13b> it could be a series of bytes XX XX XX XX then actual binary as if it was "cat >> appsboot.mbn"

<t0mm13b> whoops I meant "cat lk.img >> appsboot.mbn"

<t0mm13b> and some padding to make it the right size for validation of some sort

<t0mm13b> maybe it could be something like this

<t0mm13b> XX XX XX (for ZTE)

<t0mm13b> followed by validation code of some sort with the dumped lk image in there

<t0mm13b> haven't really looked into this but intend to

<fonix232> I see some sort of stuff like that

<fonix232> file (CSE_P729VV1 appsboot) begins with 0x06

<fonix232> then a double nullspace

<fonix232> 3bytes of data

<fonix232> nullspace

<fonix232> again 3bytes, nullspace

<fonix232> these all begin with 0xEA

<fonix232> then a last time, there's an EA beginning, but not 3bytes long

<t0mm13b> more likely 0xEA 0x.. 0x.. 0x.. 0xEA

<fonix232> nope

<fonix232> 0x00 0xEA 0x** 0x** 0x00 0xEA 0x** 0x** 0x00 etc

<t0mm13b> could point to a signature in the memory address somewhere - 4 bytes long

<t0mm13b> that is already initialized by oemsbl somewhere I'd guess

<t0mm13b> and asks appsboot to look in there

<fonix232> hmm

<fonix232> oemsbl has the same kind of header

<fonix232> first four bytes ending with 0x00 then four bytes ending with 0x00

<fonix232> no beginning EA though

Edited May 12, 2011 by fonix232

[Guest Grain]

if lk can be made to set up a dummy console/serial port and trick the ROM (by ROM am talking about CM7, SS5 etc...) kernel into thinking that there's a serial port hooked up or a console is hooked up, and the ROM kernel can then spit out info into that dummy console/serial port, lk in turn can read from that and capture the information and dump it into the sdcard?

How would that work without some kind of hardware virtualization? I don't know how COM ports are working on ARM hardware, but for x86 that's done by writing to some CPU IO ports. Without hardware virtualization there is no way for other software to tap into that mechanism as far as I know. Also, how would you dump something on the SD card that early (SD card hardware support, filesystem implementation, ...), without interfering with the SD card parts of the starting kernel?

[Guest t0mm13b]

How would that work without some kind of hardware virtualization? I don't know how COM ports are working on ARM hardware, but for x86 that's done by writing to some CPU IO ports. Without hardware virtualization there is no way for other software to tap into that mechanism as far as I know. Also, how would you dump something on the SD card that early (SD card hardware support, filesystem implementation, ...), without interfering with the SD card parts of the starting kernel?

Good question :unsure:

I have not fully checked out the lk source but there's rudimentary NAND filesystem write support in the sources....

In a nutshell, since lk is loaded into memory at 0x200000, the ROM kernel is loaded into 0x260000, theoretically, lk can and should be able to read the console memory which resides at 0x250000 - 0x25ffff ... and dump it elsewhere...

If you run blade buddy pro or mr. pigfish, there seems to be holes in there that is ... not contiguous memory... like blade buddy shows 02500000-025fffff is for ram_console, kernel follows immediately after that... there's gaps in there...

Also, there should be a way to be able to read that ram_console but is rarely used AFAIK...

It's a bit of a chicken and egg situation here - yes I am fully aware of that, in the sense that, in order to read the memory locations - the kernel must be booted, and likewise the kernel must be there before you can read it - heh!!! :P

Ahhh, the joys of OS development and a large factor of that is based on Chicken and Egg situation so... I'll add dots here as that is a big food for thought and possibly fry the gray noodles inside the head trying to figure that one out... :)

Edited May 12, 2011 by t0mm13b

[Guest ThrashMan]

At what point, if any, does LK hand over completely to the ROM i.e. die?

[Guest t0mm13b]

At what point, if any, does LK hand over completely to the ROM i.e. die?

It hands over the control to the ROM's kernel after setting up the memory, stack etc... see here for main.c

void kmain(void)								  

{												 

		// get us into some sort of thread context

		thread_init_early();					  


		// early arch stuff

		arch_early_init(); 


		// do any super early platform initialization

		platform_early_init();					   


		// do any super early target initialization

		target_early_init();					   


		dprintf(INFO, "welcome to lk\n\n");


		// deal with any static constructors

		dprintf(SPEW, "calling constructors\n");

		call_constructors();					


		// bring up the kernel heap

		dprintf(SPEW, "initializing heap\n");

		heap_init();						 


		// initialize the threading system

		dprintf(SPEW, "initializing threads\n");

		thread_init();						  


		// initialize the dpc system

		dprintf(SPEW, "initializing dpc\n");

		dpc_init();						 


		// initialize kernel timers

		dprintf(SPEW, "initializing timers\n");

		timer_init();						  


#if (!ENABLE_NANDWRITE)

		// create a thread to complete system initialization

		dprintf(SPEW, "creating bootstrap completion thread\n");

		thread_resume(thread_create("bootstrap2", &bootstrap2, NULL, DEFAULT_PRIORITY, DEFAULT_STACK_SIZE));


		// enable interrupts

		exit_critical_section();


		// become the idle thread

		thread_become_idle();

#else

		bootstrap_nandwrite();

#endif

}

thread_resume creates and forks off a thread to execute bootstrap2 which is where the registers/memory etc are setup and jumps to the ROM's kernel at this stage... the lk gets completely overwritten I'd be inclined to say at this stage for room for the ROM kernel in place

static int bootstrap2(void *arg)

{

		dprintf(SPEW, "top of bootstrap2()\n");


		arch_init();


		// initialize the rest of the platform

		dprintf(SPEW, "initializing platform\n");

		platform_init();


		// initialize the target

		dprintf(SPEW, "initializing target\n");

		target_init();


		dprintf(SPEW, "calling apps_init()\n");

		apps_init();


		return 0;

}

After that - away we go... ROM boots up as usual. This all happens in a blink of an eye :unsure:

Check in /proc/last_kmsg and you will see 'Welcome to lk' near the bottom of the virtual file...

Edited May 12, 2011 by t0mm13b

[Guest wbaw]

Wasn't qcsbl and oemsbl what are the primary bootloaders (flashable)? And oemsbl is what enables/disables modes (VolUp/VolDown + PowerOn)?

SBL is the secondary bootloader what handles these stuff AFAIK.

EDIT:

Some moar stuff:

qcsbl is a qualcomm signed bootbloader, i think it can't be changed. oemsbl controls tpt mode (vol+ or vol+ & menu + power on), it also seems to help with the windows flasher, its what stops the modem partitions being read by android & it's pretty early in the boot process. Mess oemsbl up & your phone is bricked, pretty much.

appsboot controls booting into fastboot mode or recovery (volup/voldown + power on). it is based on lk, but that's a bsd license, so zte's modifications are closed source & we have no idea what it'd take to compile a version that loads on the blade. I think it'd still be recoverable if you mess it up by tpt though, because oemsbl does tpt mode & it loads first.

[Guest cpg]

Wasn't qcsbl and oemsbl what are the primary bootloaders (flashable)? And oemsbl is what enables/disables modes (VolUp/VolDown + PowerOn)?

SBL is the secondary bootloader what handles these stuff AFAIK.

Some of it is, some of it comes later.

Boot procedure starts with some code in ROM, which loads QCSBL + OEMSBL. These load both AMSS (on the modem processor) and APPSBOOT (on the application processor). OEMSBL also enables some protection that makes the flash areas containing all boot loader parts inaccessible by the application processor.

TPT and download mode (the mode used by the windows flasher to start armprg.bin on the phone) are in OEMSBL, while APPSBOOT decides the Android-related modes, like recovery/fastboot/boot.

The entry point for the kernel is a bit later than the above code suggests, though. The function apps_init starts aboot.c which checks keys pressed and enters fastboot, recovery or regular boot and in the function boot_linux:

	enter_critical_section();

	platform_uninit_timer();

	arch_disable_cache(UCACHE);

	arch_disable_mmu();


	entry(0, machtype, tags);

If the code returns at this point (or if an error occurs while trying to load the kernel image), fastboot is automatically enabled.

(i just saw wbaw covered these points in what he posted while i was taking some time to write my response :unsure: )

[Guest wbaw]

So how would you rate the chances of making an open source appsboot.mbn that works on the Blade?

[Guest cpg]

So how would you rate the chances of making an open source appsboot.mbn that works on the Blade?

I guess it would be possible, though i'm not sure if it's worth the effort. It will be quite awful to debug as well.

I haven't looked at the blade kernel sources a lot, but based on some (limited) kernel development experience on another device, wouldn't it be possible to enable the frame buffer console for kernel boot messages?

[Guest fonix232]

I guess it would be possible, though i'm not sure if it's worth the effort. It will be quite awful to debug as well.

I haven't looked at the blade kernel sources a lot, but based on some (limited) kernel development experience on another device, wouldn't it be possible to enable the frame buffer console for kernel boot messages?

Problem is that what t0mm13b wants is mostly controlled by the Android kernel, and it controls USB, SD card writing, etc. Replacing the original appsboot with one what mounts SD card first and saves logs there (before even letting Android work), console framebuffer, etc, can be saved there. Also this would enable boot-time multi-boot (u-boot maybe), booting from NAND or SD (like the HD2).

Also, sent you a PM :unsure:

[Guest cpg]

Problem is that what t0mm13b wants is mostly controlled by the Android kernel, and it controls USB, SD card writing, etc. Replacing the original appsboot with one what mounts SD card first and saves logs there (before even letting Android work), console framebuffer, etc, can be saved there. Also this would enable boot-time multi-boot (u-boot maybe), booting from NAND or SD (like the HD2).

There's still the problem of running the logging code while the new kernel is initialising all the hardware, including the cpu.

That's why i thought maybe a framebuffer console might be good enough for debugging purposes. I experimented a bit with initialising the screen and sd controller on another (WM) device and once i had the screen working, i could see the console output on the screen while the kernel was booting (unless it hangs before that, obviously). It goes very fast, but could help with detecting where it hangs.

In this case, appsboot wouldn't have to be changed at all. However, i don't know if the framebuffer of the msm7 series can be used for this.

[Guest t0mm13b]

There's still the problem of running the logging code while the new kernel is initialising all the hardware, including the cpu.

That's why i thought maybe a framebuffer console might be good enough for debugging purposes. I experimented a bit with initialising the screen and sd controller on another (WM) device and once i had the screen working, i could see the console output on the screen while the kernel was booting (unless it hangs before that, obviously). It goes very fast, but could help with detecting where it hangs.

In this case, appsboot wouldn't have to be changed at all. However, i don't know if the framebuffer of the msm7 series can be used for this.

Wow! Any chance you could share the code to see how you did it? :unsure: That is exactly what I'm looking for...

[Guest cpg]

Wow! Any chance you could share the code to see how you did it? :unsure: That is exactly what I'm looking for...

Just tested it with the SS kernel (had a build environment with that at hand) and all it needed for that one was some kernel config changes and a command line override in boot.img.

In config:

CONFIG_FRAMEBUFFER_CONSOLE=y

CONFIG_FONTS=y

CONFIG_FONT_8x16=y

In the config tree, you can find these under 'Device Drivers -> Graphics support -> Console display driver support' as the options 'Framebuffer Console support' and 'Select compiled-in fonts' and the font selection under it.

However, the default command line from appsboot is 'rdinit=/init console=ttyDCC0 console=ttyMSM2,115200'. You can override this in boot.img (the command line string is stored at offset 0x40, but you can just use the mkbootimg --cmdline option). I just added tty0 ('rdinit=/init console=tty0 console=ttyDCC0 console=ttyMSM2,115200') and it worked.

You can probably rotate the output, but for debugging purposes, holding your blade upside down isn't a big deal :)

[Guest t0mm13b]

Just tested it with the SS kernel (had a build environment with that at hand) and all it needed for that one was some kernel config changes and a command line override in boot.img.

In config:

CONFIG_FRAMEBUFFER_CONSOLE=y

CONFIG_FONTS=y

CONFIG_FONT_8x16=y

In the config tree, you can find these under 'Device Drivers -> Graphics support -> Console display driver support' as the options 'Framebuffer Console support' and 'Select compiled-in fonts' and the font selection under it.

However, the default command line from appsboot is 'rdinit=/init console=ttyDCC0 console=ttyMSM2,115200'. You can override this in boot.img (the command line string is stored at offset 0x40, but you can just use the mkbootimg --cmdline option). I just added tty0 ('rdinit=/init console=tty0 console=ttyDCC0 console=ttyMSM2,115200') and it worked.

You can probably rotate the output, but for debugging purposes, holding your blade upside down isn't a big deal :unsure:

Thank you for sharing that.... meh... wouldn't think framebuffer console be used on the handset side of things :)

[Guest fonix232]

Wow, great, now we can have bootlogs instead of the boring greendroid :unsure:

[Guest MFighter]

Highly interesting thread!

I was wondering how the FTM is loaded.

Is it done entirely by the recovery flash or are there other parts involved, such as the radio?

I read that clockworkmod automatically reboots to recovery when it detects FTM mode, so it at least has to load the recovery partition kernel & ramdisk.

How does clockwork detect ftm?

I hope I'm not hijacking this thread by asking this question... - do you know what the contacts/socket are for on the backside of the blade?

They are exposed with just the back cover off, so I figure they must carry some use?

1. Six contacts: could this be a JTAG interface? has anyone tried?

2. Socket (just above wifi antenna): could this be for a Radio Antenna?

3. Two Contacts: no idea really....

Cheers,

- MF

[Guest t0mm13b]

Highly interesting thread!

I was wondering how the FTM is loaded.

Is it done entirely by the recovery flash or are there other parts involved, such as the radio?

I read that clockworkmod automatically reboots to recovery when it detects FTM mode, so it at least has to load the recovery partition kernel & ramdisk.

How does clockwork detect ftm?

I hope I'm not hijacking this thread by asking this question... - do you know what the contacts/socket are for on the backside of the blade?

They are exposed with just the back cover off, so I figure they must carry some use?

1. Six contacts: could this be a JTAG interface? has anyone tried?

2. Socket (just above wifi antenna): could this be for a Radio Antenna?

3. Two Contacts: no idea really....

Cheers,

- MF

Not at all that you're hijacking it. :)

In fact, if you look elsewhere on this forum, Tom_G made a thread about this, what you're looking at there in the back of the blade is actually a RS232 serial pin-out for debugging, by soldering wires to those pin outs (cannot remember - so do not try it out yourself!) and rigging up a tty serial board with usb connection on other side, you can actually read the boot sequences...

Edited June 22, 2011 by t0mm13b