Understanding the Spica

[Fulkerson]

• bml3 (384kB) - boot logo (logo.png) + bootloader parameters (if you flash big logo, you can destroy bootloader params)

This means a simple dump of bml3 and a quick inspection with a hexeditor should give us the exact maximum size of logo.png.

A quick look showed me the png and then 1ns up to 2FFFF. After that there's some stuff followed by almost only zeroes although there are some other stuff in between. (I think parameters). If the junk(?) in between the two areas is a flag showing where parameters should be then it'll be a no brainer making a new and safe logo flasher.

[Phlexonance]

well when the whole partition is 384kB just for the logo, why not just make a flasher that allows for 380kB max and then you're safe, no?

[Fulkerson]

well when the whole partition is 384kB just for the logo, why not just make a flasher that allows for 380kB max and then you're safe, no?

Because the partition is not just for a logo. When writing a too large png you end up overwriting at least some bootloader parameters.

EDIT: The logo is laid out raw on the partition starting on 0 and the space after seem to be filled with ones. So there's ones up to and including 2FFFF and if we guess that it is ok to overwrite them (pretty solid guess I'd say) we have exactly 196608 bytes to fill (or 192 KB). Make that 10 bytes less and you should be just fine. The 192 KB is based on that there's 1024 bytes on a KB. Some developers prefer to use 1000 so the number 192KB should not be used as a reference at all.

BTW, I think I read somewere that a guy just changed the file extension from jpg to png and flashed and if worked. Now I'm not sure if he actually meant that he converted it or not but since all the software for png, jpeg and whatever format it's not unthinkable that the spica just displays whathellever it finds. JPEGs at that resolution and 192KB size can be pretty darn detailed.

[Phlexonance]

4kB aren't enough for parameters?
that must be some darn long strings or at least some blobs
but yeah, you could calculate it by the address the params start in the hex editor

[Fulkerson]

4kB aren't enough for parameters?
that must be some darn long strings or at least some blobs
but yeah, you could calculate it by the address the params start in the hex editor

Actually the other half of the partition is almost only zeroes so there's very little space used. They probably want some free space here and there to use for future upgrades. It could be pure partitional problems as well. Look for yourself if you want, it's real simple and completely safe. Just run "dd if=/dev/bml3 of=/sdcard/logo.img" on your phone through adb or something and move it over to a computer and open with a hexeditor (I've really come to like Okteta). As long as you don't write to the partition you're safe.

Starting at 30000 you'll find "24 66 72 72 11" (some kind of flag, possibly?) and further down some info I think is firmware version or something and a little further down some kind of console and it's baud. Then we have another console thingie at 50488. Most is just zeeeeero. However it might well be used during certain procedures as temporary space (flashing and similar).

[vit12345]

A question: how do you create a .tar (for ex a tar containing zimage and logo.png to flash via Odin)? is it possible to get it done on windows?

[Phlexonance]

I see. Interesting findings Fulkerson!

A question: how do you create a .tar (for ex a tar containing zimage and logo.png to flash via Odin)? is it possible to get it done on windows?

you could get gnutools or tugzip to do it on windows

[vit12345]

Thks for that!

[shinn_Asuka]

Awakening and old thread .

Can we just rewrite the bootloader parameter to boot for a new kernel from adb shell, just like we installed GRUB on our HDD mbr? Or maybe a bootloader console like RedBoot like in some development board.

I mostly work on my GNU/Linux box and hate just to reboot too windows only to flash a new kernel using odin. Not trying using Wine yet.

[adef]

Awakening and old thread .

Can we just rewrite the bootloader parameter to boot for a new kernel from adb shell, just like we installed GRUB on our HDD mbr? Or maybe a bootloader console like RedBoot like in some development board.

I mostly work on my GNU/Linux box and hate just to reboot too windows only to flash a new kernel using odin. Not trying using Wine yet.

welcome to the jungle bro..
*sinyora