On 12/01/2016 11:18 PM, Mathias Kresin wrote:
02.12.2016 06:28, J Mo:
On 11/27/2016 02:29 AM, Mathias Kresin wrote:
I asked you three (!) times to _explain_ what this code should do
[0][1][2]. Now I see the very same code again without having ever seen
the requested explanation.
This still looks like the hackish image code that was required with
the old image build system. I guess most of the stuff can be done with
the existing build helpers.
To say it with easy understandable words: This patch will not be
merged till I get an understandable answer what this code should do. I
do not even consider doing a review before I get this answer.
Mathias
[0]
http://lists.infradead.org/pipermail/lede-dev/2016-September/002677.html
[1]
http://lists.infradead.org/pipermail/lede-dev/2016-September/002681.html
[2]
http://lists.infradead.org/pipermail/lede-dev/2016-September/002744.html
Wow.
First off I would like to apologize for whatever I've done that made you
feel such an indignant reply was needed.
I'm a weekend hobbyist coder and this is my first patch set send to
LEDE. This kind of stuff is not my day job. So, I would ask that you
assume whatever offense I've committed was not intentional. Not up to
now anyway.
Here is how I previously answered your question:
Cameo signatures are already used by a large number of devices. This
should do the same thing, but in the new makefile style. The old style
was nearly incomprehensible.
I'm not doing anything obscure here. This should be self-evident. Add
a byte-aligned signature. pad-to can't do that.
Can you please clarify what of my previous reply it is that you don't
understand so that I can do a better job of explaining it?
The problem is quite simple, I don't get how the signature created by
Build/cameo-sig should look like. And the way the signature is created
looks way to complex to me.
Mentioning that it's a cameo signature does not help at all, as long
as you don't provide a link to some kind of specification how this
signature format should look like.
I expect to see a human readable explantation of what the code should
do. Hence I asked you back in the days:
> Do you want to add the signature to a 64 byte padded image or should
> the image + signature padded to a multiple of 64byte? Where does the
> 64 byte does come from? It doesn't seam to be related to the 128k
> blocksize of the flash
With the new image build code, we have a lot of helper for doing
padding without the need of a single line of custom code. But as long
as I don't understand how the resulting signature should look
like/should be padded, I can not point you to the correct helper for
the job.
My requirements are the same as the Image/Build/Cameo target in
target/linux/ar71xx/image/legacy.mk.
There are two devices in particular which require a similar signature
method: TEW-632BRP (CameoAP81) and TEW-823DRU (CameoAP135). Both are
already in LEDE.
The TEW-632BRP (CameoAP81) is an ancient device from 2004. I just
happened to have two of them, so I was vaguely familiar with this
requirement before I acquired my new device.
The TEW-823DRU (CameoAP135) is both very recent and architecturally
similar to the tew827dru. It's also based on the same upstream source
(QSDK).
The makefile portion that I wrote was intended to duplicate the same
image generation functionality so that it would be useful for future
devices. I looked at existing tools prior to making my own and didn't
find anything that would do what I needed.
The image needs to be byte-aligned with the signature inside. The 64 was
backwards compatible with the old default from the old makefiles, but it
works for this device too. The actual blocksize is not relevant to my
device because of it being a FIT image.
You are aware that tools/firmware-utils has a mkcameofw? Not sure if
it's the same format you need.
Not applicable here and I'm not sure why you would bring it up.
mkcameofw is used by the CameoHornet target, which is only used by one
device. It's a one-off tool. None of the other devices which require
cameo signatures use it. It seems to have a bunch of additional
requirements that are not related to them or my device.
Mathias
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
