90 replies to this topic

[theparasol]

Well, simple Ajeeb: you just proved that recent/new bootloaders have indeed disabled the writing of manufacturer images.

So you have to revert to latest bootloader that does write those images, replace the unwanted logo with another and upgrade the bootloader again to latest.

 

So only way it could ever change again is that it is flashing directly to the right offset from within a booted image. (yeah or a newer bootloader has image writing enabled again!)

[ajeeb]

@theparasol , am not trying to prove anything ... I just want to know why it does work with VIX and not other

take a look at a simple compare binary file in picture right side is vix ... and left pli for the rootfs.bin file !

in the right side it mentioned 3 times , does that mean something !????

 

BR

Attached Files

•  Screen Shot 2014-02-08 at 2.51.43 PM.png   188.23KB   33 downloads

Edited by ajeeb, 8 February 2014 - 14:00.

[Lost in Space]

Yes first check if the cfe.bin they include is the same - if yes, then there must be something wrong with your logo (file size, colour deptht).

 

But you should be able to do the same as the (old) loader does, he also only uses this flash binary code to do the job.

 

And the tools to dump and write are naddump and nadwrite from the standard mtd-utils.

 

But if the logo resides in raw devices (as your loaders are kind of dumb they can load kernel only from raw device I would assume that for logo the same applies) then live is much sinplier as only the flash overhead (OOB, checksum...) needs to be omitted and then you can read the pure data directly in Flash without any need to dump it - and you can ignore all blocks with UBI header as they are part of the ubifs flash filesystem.

 

So the search normally should be pretty fast as only the raw partitions or adress space of flash not shwon as partition will remain which typicall is less then 5-10% of the total flash.

 

And as I said nand_check binary will show you which blocks are used so there is no need to search very much places.

 

But let#s put the question around - are there also VU* bixes where nobody know where the logo goes, because there I could contact my testers which helped to make fgwrite work to get the needed informations/dumps.

Edited by gutemine, 8 February 2014 - 14:08.

[theparasol]

However considering that the technical question is valid and the logo search is a very doable challenge.

But solving the riddle will eventually lead to even more advertiser logo's from the well know bells and whistles image providers.

So proof of concept is fine but I rather put my effort into support of migration to gstreamer 1.x

 

Personally I think the manufacturer logo shouldnt be touched in the first place.

It would be so nice if a manufacturer releases a new bootloader that actually does checksum the logo and prevents loading of the image after 50 times wrong crc

That would disable all "x-mas" tree images around the globe for sure...

[Lost in Space]

Good that normally you blame me of becoming OT

 

Look, if you can have  the splash.bin together with a small binary flashing it similar to what DMM does with their secondstage loader or what your images do it for updating their kernel in the rawdevice, then this is nothing to be scared of, because THEN imagebuiders could handle this like any other update of their feed.

 

And yes then people could create their own bootlogo ipks and users could choose which one to use.

 

If you prefere to fiddle around with USB Flashing boot you are welcome, but then I can't add any value.

Edited by gutemine, 8 February 2014 - 15:15.

[theparasol]

We already have a bootlogo that every image maker can replace with their own. So why touch the manufacturer logo too? Just leave it as its part of the identity of the device itself.

[littlesat]

So why touch the manufacturer logo too?

Ask the openVix team... (and other OE-alliance based image team)

Edited by littlesat, 8 February 2014 - 15:29.

[Lost in Space]

Why do you climb the Everest ... because it is there.

 

This thread gives you the exact reason and explaination WHY users would like to have this possibility, so repeating your argument that nobody needs it is not really helpfull either.

 

Just because nobody has climbed the Everest before was not a good reason for not doing it either.

 

Replacing the logo with old loaders is not the knd of good solution I would have expected from such a knowledgeable team.

Edited by gutemine, 8 February 2014 - 15:31.

[theparasol]

A very strange comparison.... Better compare it to cars, if you pimp your ride you decided to replace the manufacturer logo with your own too. There is no obvious reason to do so, there is no challenge in it. You just do it coz you can do so.

 

Climbing the everest is not for everybody, mostly done by people to tell others: been there, seen that, done that.

 

I rather put my effort in pratical things that really do enhence instead of cosmetic. And we all know some people only can do nice "spray" jobs and rely for functionality on others.

No problem with that only dont call and pronounce it as "your" image.

[ajeeb]

Personally I think the manufacturer logo shouldnt be touched in the first place.

It would be so nice if a manufacturer releases a new bootloader that actually does checksum the logo and prevents loading of the image after 50 times wrong crc

That would disable all "x-mas" tree images around the globe for sure...

 

So why touch the manufacturer logo too?

Ask the openVix team... (and other OE-alliance based image team)

 

so agree with that !!! to put ...www.sh*** is bad idea since manufacturer make fixed logo .

 

cheers

[Lost in Space]

Only pimps pim cars ...

 

OK, I asked a VU+ solo owner to do this for us:

 

nanddump /dev/mtd0 -f dump0

nanddump /dev/mtd2 -f dump2

nanddump /dev/mtd3 -f dump3

 

The splash.bin has a BM8 header.

 

If you the do a strings dump0 | grep BM8 this shows that the logo is there in the full flash.

 

All the other dump* give no result. So the logo is not in the kernel or the mac partition of his VU+  and it cann't be in root partition either.

 

Now you have to check partition layout from cat /proc/mtd for the holes and get the header offset with bvi dump0 and then you have the offset for the nandwrite -s xxxx /dev/mtd0 splash.bin to write to the hidden logo part of the flash. And maybe check if cat /proc/mtd on a vix image shows more partitions  :-)

 

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 0e100000 00020000 "rootfs"
mtd1: 0e100000 00020000 "rootfs(redundant)"
mtd2: 00700000 00020000 "kernel"
mtd3: 00100000 00020000 "mac"
mtd4: 0d675000 0001f000 "rootfs"
 

But from here I can't help as I don't have any such box and I can't ask soembody else to try it out based on my dirty guess..

Edited by gutemine, 8 February 2014 - 15:47.

[ajeeb]

 et9x00 splash.bin header BM6 ! ... maybe the header cause all this lol !! splash.bin header inside VIX is " BM8 "

Edited by ajeeb, 8 February 2014 - 15:56.

[Lost in Space]

Then use this header for searching ... but be aware that rootfs will also give false results, so look for the holes in the partition table to verify your find.

 

Look I'm just trying to help. NOT to solve your problem, if you are not taking advice then I cann't help.

 

it might not even be good advice, BUT if you don't start climbing you will never make it to the top of the hill.

 

And don't forget the bootlog of a working logo flash of the bootloader, this could be the showrtcut to the peak.

Edited by gutemine, 8 February 2014 - 15:56.

[theparasol]

Well something odd going on (or I'm just too stupid!)

 

root@xp1000:/tmp# nanddump /dev/mtd0 -f dump0
nanddump: invalid option -- 'f'
BusyBox v1.21.1 (2014-02-04 22:29:25 CET) multi-call binary.

Usage: nanddump [-o] [-b] [-s ADDR] [-f FILE] MTD_DEVICE

Dump the specified MTD device

        -o      Dump oob data
        -b      Omit bad block from the dump
        -s ADDR Start address
        -l LEN  Length
        -f FILE Dump to file ('-' for stdout)

root@xp1000:/tmp#

 

Seems to me the -f parameter isnt recognized correct....

[Lost in Space]

Seems to me that you are simply unable to read the help output.

 

The BUSYBOX version of nanddump wants naddump -f dump0 /dev/mtd0

 

Try mtd-utils-nanddump ipk for a better one.

Edited by gutemine, 8 February 2014 - 16:04.

[littlesat]

This thread gives you the exact reason and explaination WHY users would like to have this possibility, so repeating your argument that nobody needs it is not really helpfull either.

I thought this thread was about that users just want the orriginal logo back...

But now it seems it changed to working around the bootloader to change that logo....

Edited by littlesat, 8 February 2014 - 16:03.

[Lost in Space]

If you are not understanding that a way to switch bootlogos from running operating system will give you also a simple and easy way to get the original one back ... then I'm probably too dumb for this thread

Edited by gutemine, 8 February 2014 - 16:07.

[theparasol]

But now it seems it changed to working around the bootloader to change that logo....

 

I consider it ok to see how things can be done without doing it the obvious way and it enhances my understanding of technical things.

Till now its rather straight forward, I wonder if its all that easy. If so its rather a "hill" instead of the world biggest mountain

[littlesat]

As far i can see the splash.bin is just a bpm file renamed to bin....

[Lost in Space]

Excatly because this makes it extremely easy to find.

 

And after climbing a mountain you are allowed to judge, before it is just ... wishfull thinking.

 

But as I already explained investigation is the path to understanding and this leads to solutions.

 

Mapping a flash partition which is only visible to the loader should not be too diffucult, then you would not even need -s option for nadwrite, but first you have to know here it is, then you can decide how to replace it.

 

BTW you could use also nanddump -s to verify the offset, because then a simple compare or diff to the spalsh.bin would tell you if you found the logo in flash.

 

Which brings us back to the superiority of understanding to ignorance.

Edited by gutemine, 8 February 2014 - 16:16.