Buildroot a linux 2.6.26-lab126 kernal. (3.3)

[knc1]

Holy War challenge accepted ::

K4&K5 == -mfpu=vfpv3-d16 -mfloat-abi=softfp (rather than: -mfpu=vfpv3 or -mfpu=neon)

Keep in mind that the neon instruction set treats denormals as zero.
Should not make a difference in typical uses, like finding the pixel bounds of a graphic item.
Will make a difference in fft and inverse fft code (big time).
Would probably not be recommended for building gcc with either - very likely to screw up the optimizer's tree coloring.

Hmm...
I wouldn't trust the neon instruction set for building Lua either (Lua's only (default) internal numeric type is double)

Note: Only messing with the K3 code at the moment here, not (yet) with K4&K5.

[NiLuJe]

@knc1: Thanks for the details .

Why vfpv3-d16, though? AFAIK, the K4/K5's cpu has the full 32 registers available, no?

(I omit the float-abi stuff because I default to softfp on my TCs, I think I mentioned it in the full post twobob quoted ).

[knc1]

If the only things we are generating code for is the i.MX31, i.MX35, I.MX53 - -
Then I guess we don't need to be concerned about running the stuff on ARM arch's other than ARMv6 and ARMv7.

The (-d16) uses half-wide registers as pairs.
I still haven't found what that 'l' of the ARMv6l and ARMv7l arch is - the only hint is about the "(l)ight FPU silicon". (Takes more FPU cycles than the "full" silicon.)

On my "to do list" is some small diagnostic things that would tell us exactly which core variation that Freescale licensed. Just haven't had enough of a pressing need to know.

So for now - assuming 16bit register pairs should be the "safe course" .

(Plus it lets us borrow from the Ubuntu-Core project. )

[geekmaster]

Originally Posted by knc1

If the only things we are generating code for is the i.MX31, i.MX35, I.MX53 - -
Then I guess we don't need to be concerned about running the stuff on ARM arch's other than ARMv6 and ARMv7.
...

I see that you mentioned i.MX53 series instead of the i.MX508 that is used in K4/K5.

For anybody that questions differences between i.MX53x and i.MX508: They both use the Cortex A8 instruction set, but the SoC chips have other differences (such as no eink controller on the i.MX53x SoC chips).

[knc1]

Typo.

[twobob]

Spoiler:

Here we show a head to head of the im35_luigi_defonfigs from the 3.3 and 3.4 Kernels.

As you can see they are identical.

So no changes there then.

http://minimodding.com/article10-com...g-head-to-head

This bodes well for us. no kernel tweaks required for 3.4 compliance. Happy days.

Looking at the Src bz2's they appear identical.

Any bets on updated headers???

[knc1]

Originally Posted by twobob

Spoiler:

Here we show a head to head of the im35_luigi_defonfigs from the 3.3 and 3.4 Kernels.

As you can see they are identical.

So no changes there then.

http://minimodding.com/article10-com...g-head-to-head

This bodes well for us. no kernel tweaks required for 3.4 compliance. Happy days.

Looking at the Src bz2's they appear identical.

Any bets on updated headers???

I just had to be the first one to use a cross-site, thoughtless, request title.

At this site:
http://www.daemonology.net/bsdiff/
Is described the (original) bsdiff / bspatch program, with sources:
http://www.daemonology.net/bsdiff/bsdiff-4.3.tar.gz

If you would please wire that into your build system?

If you want to practice building it (to find problems in the build), we could use an Intel, 32bit version also (in BR, jsut call both the 'target' and the 'host' builders).

Once some testing confirms that the above is the same bsdiff / bspatch being used by lab126 . . .

- - - speed bump - - - topic shift - - -

For the vendor (binary) tarballs released for Media Players, a file changes audit report generator already exists.

HowTo install binfmt_misc support for it (not required, and in supplement to what you have already written up here):
http://minimodding.com/LuaBinFmt

HowTo on building and installing LuaFileAudit:
http://minimodding.com/LuaFileAudit

HowTo use LFA and example reports generated:
http://minimodding.com/FW121NTSCcomp

The above example is on comparison of binary trees, but should work just the same on source trees.

- - - speed bump - - - topic return here - - -

For the "Describe this for Me" to-do list ::

• Write-up for everyone how to use the update tool to unpack a Kindle update ;
• Apply that update to a file image - using a "non-Kindle" machine ;
• Generate a File Audit report of the changes to the image ;
• Then on using the update tool to re-pack the updated "forensic" image.

It should all be a "piece of cake" for the crew at either of our cross-scripted web-sites:

• Lua will build and run on anything that supports a standard "C" compiler ;
• The LFA application is a Lua script ;
• We already have the un-pack/re-pack tool in several versions, by several people.

[twobob]

Let me check the version on this... Might be the wrong one.
EDIT: Yep - version is correct. 4.3 bsdiff

bsdiif - bspatch (built for a Kindle 3.x)

[root@kindle root]# /mnt/us/usr/bin/bsdiff

bsdiff: usage: /mnt/us/usr/bin/bsdiff oldfile newfile patchfile

[root@kindle root]# /mnt/us/usr/bin/bspatch

bspatch: usage: /mnt/us/usr/bin/bspatch oldfile newfile patchfile

(Built static static)

[root@kindle root]# readelf -d /mnt/us/usr/bin/bsdiff

There is no dynamic section in this file.

[root@kindle root]# readelf -d /mnt/us/usr/bin/bspatch

There is no dynamic section in this file.

I'll have a look at the others now

Will build a 32 bit Intel Linux build too then : )

[knc1]

Thanks a lot!

I am carving out a new chamber in the Nerd Cave this morning.

After making my post, I noticed that LFA processes the output of sha1deep
So we will have to build that little collection of *deep tools also.

[twobob]

okay. np. Today I am attempting to grab the guts from this DX, however that just needs "setting running" AFAIK.

Also I FINALLY managed to get the entire "examples" catalogue of QT 4.8.3 cross-compiled for a kindle (Got it down to a 2Gb size )

Also managed to get BR to swallow hawhills qt patch on-the-fly : )
so testing the impact of that.

Err. what else. yeah the 32 bit version of bsdiff /patch (I have them already somewhere - need to dig em out)

I looked at that Lua audit thingy Have to take some time to figure out howto install /use that too (I once-over-ed the docs)

etc... TBC

[knc1]

You may have to "tweek" K3Flasher - the KDX is a different processor and the setup command file sequence is probably different.
You may have to check the ATK sources (on our kloud) for the details.

The "RAM kernel" is different, but you can pull that out of the ATK binary.

[twobob]

I was just looking to export the files...

I vaugely recall a dd command would do the job??? (the Dx is fine right now, simply backing up to FAT and pulling off over USB would be far easier I posited?)

Clues gratefully accepted. In essence I am looking to create the image that will be required by another poor soul who will be running this in via serial.

: )

EDIT: And yes I reading through the tens of thousands of posts, unhelpful google results, far too many bookmarks, far too much mail in an effort to find out for myself.

dd was always a bit of a mystery. "copy stuff bit for bit" from here to there I guess, just want to get the swtches bang on is all.

[knc1]

Originally Posted by twobob

I was just looking to export the files...

Yeah, dd will do that.

I thought you wanted a "complete - user storage" set of files like Hawhill's dump script does.

PM me if you need some help with that - I am only digging the "diaper residue" out of the Nerd Cave this morning.

[twobob]

Originally Posted by twobob

I was just looking to export the files...

I vaugely recall a dd command would do the job??? (the Dx is fine right now, simply backing up to FAT and pulling off over USB would be far easier I posited?)

dd was always a bit of a mystery. "copy stuff bit for bit" from here to there I guess, just want to get the swtches bang on is all.

And here I am, many hours later DX FINALLY !!!! READY to run backups...

Sigh. There are quite a few quirks in our documentation. should really get a "unified" effort rolled onto the wiki one day I suppose. *gasp* more work.

anways, here I am, made it.

now - those pesky dd commands for a DX... resumes wandering through the annals.

[knc1]

Keep notes.
If interested, keep them on a new wiki page at mmg.

Note: The new page does not have to be "linked in" anywhere, you can always find every page you ever created in your MyTiki section (if turned on in MyTiki:preferences).