Re: Request for a personal git tree for AT91/AVR32

[Philip Balister <philip@balister.org>]

[-- Attachment #1: Type: text/plain, Size: 3159 bytes --]

Ulf Samuelsson wrote:
>> On Mon, Dec 8, 2008 at 4:44 PM, Ulf Samuelsson 
>> <ulf.samuelsson@atmel.com> wrote:
>>> I ran into a problem that linux would not build because if you
>>> use linux and request UIMAGE, then you fail because
>>> u-boot-mkimage is not available.
>> Well, u-boot native tools are built perfectly now, and uImages
>> work. Try to build for afeb9260 machine, and see for yourself.
>> I tried that yesterday, it works perfectly.
>>
> 
> If you can't download the source you can't build the tools.
> It used the backup location which does not have a git server.
> Obviously it could be a temporary problem with the main
> location, but it is probably a bug trying to use the backup location.
> 
> If a "stable" version is used, then the backup location can contain the 
> same source code.
> 
> Anyway , If it normally works, then I do not need to add it!
> 
> If people have problem, does it hurt that u-boot-1.3.4 is supported as 
> well?
> 
> I checked with the AT91 group and they have been spending quite
> some time to test and verify 1.3.4 on a multitude of boards so
> it does make sense to have this supported.

I'd like to see recipes for the later stable u-boots to support HW that 
is well supported by u-boot. I've been mraning to do this but haven't 
had to do this myself. Thanks for adding 1.3.4. whrn I can type with two 
arms again ...

Philip

If no gets to it, I'll look at i
> 
> Is the "personal" git tree really personal, or can you have
> a git tree which is available to a group?
> 
> It makes sense for me to have an "atmel" group which I
> could share with other interested atmel employees.
> 
> Who is making decisions on access?
> 
> Best Regards
> Ulf Samuelsson
> 
> 
>>>
>>> I then made the linux recipy depend on the u-boot native tools,
>>> and then u-boot.git was selected and oe tried
>>> to do git access to www.angstrom-distribution.org or something similar.
>>> I do not know why, and could not figure out why it did so.
>>>
>>> That is why I wrote the new recipy.
>>>
>>>> so I don't see real point in using versioned approach.
>>>
>>> If you want to add patches they may or may not be broken by a later git
>>> version.
>>> It is more important to have something which has been tested and 
>>> validated
>>> than the latest stuff.
>>>
>>> I agree that it would have been better to use the 2008.10 though.
>> Wel, look at u-boot_git.bb, it has tags fixed for some machines, and
>> apply patches too. I never had problems with it. That could save you
>> lots of time.
>> you can fix versions by providing git commit hashes in SRC_URI. Look
>> at mentioned
>> u-boot_git on how this is done.
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]