On Tue, Jul 30, 2013 at 03:37:38PM +0200, Daniel Mack wrote:

Hi Jason,

On 30.07.2013 15:17, Jason Cooper wrote:

quoted

On Tue, Jul 30, 2013 at 09:48:51AM +0200, Daniel Mack wrote:

quoted

On 29.07.2013 23:23, Jason Cooper wrote:

quoted

Basic idea is to replace a device's stock kernel with this impedance-matcher.
Load the kernel and/or the devicetree blob to desired addresses.  Add
'loadaddrs=0xXXXXXXXX,0xYYYYYYYY' to the kernel's command line.  Or, if you are
appending, 'loadaddrs=appended,0xYYYYYYYY'.  First address is the location of
the kernel, second is the location of the dtb.

Nice to see that idea implemented! For me though, changing any of the
U-Boot variables is out of the question, and I need the matcher just the
way I implemented it, including the LED blink pattern to let the user
know if things go wrong.

Understandable.  After thinking about it a bit, I think I'm going to
rework this patch to allow appending both kernels and dtbs (as you had),
and abstract out the led blink so that your code would become a compile
time option.

And how would you match machids and system_rev values to the dtb files?

I'm thinking board-specific match functions.  For your use case, you
would match machid/system_rev to a compatible string.  Then, generic
code would scan the appended dtbs for a matching string.

This is how I identify my boards at least. But as Stephen Warren said in
the thread that started this discussion, there might be totally
different ways of detection. For instance, other boards could read GPIO
lines, or even have a pseudo driver that initializes the I2C controller
in order to talk to an EEPROM or such. Reading from an ADC is another
option.

As long as it resolves to a compatible string.

And the more I think about it, I believe Nicolas was right in saying
that such a thing does not need to be very generic (as much as I like
generic solutions in principle).

If at all, I think we should start thinking of that code base as
something like a framework, consisting of a merely empty main() function
body, a lds linker script and some objcopy magic in the Makefile. And
then have a menuconfig which allows to select one out of many hardware
types, which then uses its specific way of board detection, LED
signaling and so on. The two lines of vectoring to the actual kernel can
be generic then. But again, I really don't know if it's worth the hassle.

quoted

hrmmm, I don't like forking on general principle.  Let me do the above
rework and see if that works for you, while adding the capabilities I
need.

When I'm done, you should just be able to do:

  $ make APPEND_KERNEL=input/zImage APPEND_DTBS=input/*.dtb uImage

Out of curiosity, I'd like to see how you dynamically create the symbol
definitions for the binary blobs :)

Me too.  ;-)

quoted

In the meantime, would you mind adding a license to your code?  If you
have no preference, I like GPLv2-only, but it's your code, so whatever
you like.

Done, GPLv2 it is.

Thanks!

thx,

Jason.