Request for a personal git tree for AT91/AVR32

Request for a personal git tree for AT91/AVR32

[Ulf Samuelsson]

I have now succeeded (after some hassle) to build
Angstrom for the AT91SAM9263EK using:

linux-2.6.18-rc7     Requires new recipy
u-boot-1.3.4          Requires new recipy
dataflashboot.bin    Requires a patch and updated recipy.
shasum-native        Recipy need bugfix.                   
qemu                     Need to update host files for OpenSuSE 10.2.
checksums.ini        Needs to be updated with data for four tarballs.

While doing that, I also updated the machine descriptions for the
at32stk1000 and atngw100 to use the latest u-boot,
and added/cleaned out some machine descriptions for other 
at91sam9 machines

Would like to share it with the community,
so access to a personal git tree would be nice.

Best Regards
Ulf Samuelsson

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

[Sergey Lapin]

On Mon, Dec 8, 2008 at 1:48 PM, Ulf Samuelsson <ulf.samuelsson@atmel.com> wrote:
> I have now succeeded (after some hassle) to build
> Angstrom for the AT91SAM9263EK using:
>
> linux-2.6.18-rc7     Requires new recipy
> u-boot-1.3.4          Requires new recipy
> dataflashboot.bin    Requires a patch and updated recipy.
> shasum-native        Recipy need bugfix.                   qemu
>         Need to update host files for OpenSuSE 10.2.
> checksums.ini        Needs to be updated with data for four tarballs.
by the way I've added at91bootstrap .bb, that might interest you.
afeb9260 machine is also at91sam9 architecture, runs recent enough
u-boot and kernel. So, why don't you use oe-dev branch for your work?
or might use your own branch, if that matters. That will make merging
your work much simpler.

Hope, that helps,
S.

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

[Philip Balister]

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

Ulf Samuelsson wrote:
> I have now succeeded (after some hassle) to build
> Angstrom for the AT91SAM9263EK using:
> 
> linux-2.6.18-rc7     Requires new recipy
> u-boot-1.3.4          Requires new recipy

Any chance you could use u-boot-2008.10 instead? I've been meaning to 
add that version as well.

Philip

> dataflashboot.bin    Requires a patch and updated recipy.
> shasum-native        Recipy need bugfix.                   
> qemu                     Need to update host files for OpenSuSE 10.2.
> checksums.ini        Needs to be updated with data for four tarballs.
> 
> While doing that, I also updated the machine descriptions for the
> at32stk1000 and atngw100 to use the latest u-boot,
> and added/cleaned out some machine descriptions for other at91sam9 machines
> 
> Would like to share it with the community,
> so access to a personal git tree would be nice.
> 
> Best Regards
> Ulf Samuelsson
> 
> 
> 
> _______________________________________________
> 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 --]

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

[Sergey Lapin]

On Mon, Dec 8, 2008 at 4:00 PM, Philip Balister <philip@balister.org> wrote:
> Ulf Samuelsson wrote:
>>
>> I have now succeeded (after some hassle) to build
>> Angstrom for the AT91SAM9263EK using:
>>
>> linux-2.6.18-rc7     Requires new recipy
>> u-boot-1.3.4          Requires new recipy
>
> Any chance you could use u-boot-2008.10 instead? I've been meaning to add
> that version as well.
why not just use u-boot_git and add version tag? u-boot use time-based
releases now,
so I don't see real point in using versioned approach.

S.


>
> Philip
>
>> dataflashboot.bin    Requires a patch and updated recipy.
>> shasum-native        Recipy need bugfix.                   qemu
>>           Need to update host files for OpenSuSE 10.2.
>> checksums.ini        Needs to be updated with data for four tarballs.
>>
>> While doing that, I also updated the machine descriptions for the
>> at32stk1000 and atngw100 to use the latest u-boot,
>> and added/cleaned out some machine descriptions for other at91sam9
>> machines
>>
>> Would like to share it with the community,
>> so access to a personal git tree would be nice.
>>
>> Best Regards
>> Ulf Samuelsson
>>
>>
>>
>> _______________________________________________
>> 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
>
>

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

[Ulf Samuelsson]

----- Original Message ----- 
From: "Sergey Lapin" <slapinid@gmail.com>
To: <openembedded-devel@lists.openembedded.org>
Sent: Monday, December 08, 2008 2:08 PM
Subject: Re: [oe] Request for a personal git tree for AT91/AVR32


> On Mon, Dec 8, 2008 at 4:00 PM, Philip Balister <philip@balister.org> 
> wrote:
>> Ulf Samuelsson wrote:
>>>
>>> I have now succeeded (after some hassle) to build
>>> Angstrom for the AT91SAM9263EK using:
>>>
>>> linux-2.6.18-rc7     Requires new recipy
>>> u-boot-1.3.4          Requires new recipy
>>
>> Any chance you could use u-boot-2008.10 instead? I've been meaning to add
>> that version as well.
> why not just use u-boot_git and add version tag? u-boot use time-based
> releases now,

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.

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.


>
> S.
>


Best Regards
Ulf Samuelsson


>>
>> Philip
>>
>>> dataflashboot.bin    Requires a patch and updated recipy.
>>> shasum-native        Recipy need bugfix.                   qemu
>>>           Need to update host files for OpenSuSE 10.2.
>>> checksums.ini        Needs to be updated with data for four tarballs.
>>>
>>> While doing that, I also updated the machine descriptions for the
>>> at32stk1000 and atngw100 to use the latest u-boot,
>>> and added/cleaned out some machine descriptions for other at91sam9
>>> machines
>>>
>>> Would like to share it with the community,
>>> so access to a personal git tree would be nice.
>>>
>>> Best Regards
>>> Ulf Samuelsson
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

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

[Sergey Lapin]

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.

>
> 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.

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

[Ulf Samuelsson]

> 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.

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
> 

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

[Koen Kooi]

On 08-12-08 17:26, 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.

Sourcemirrors and tarballstashes in OE provide tarballs, not 1:1 mirrors 
of the scms. Had you actually read the error message you would have 
noticed that it did something like:

1) try source mirror for tarball -> FAIL
2) try upstream repo -> FAIL
3) error out

if 1) fails it means the autobuilder hasn't build and mirror that rev 
yet. 2) means an error on your end, be it corporate firewall or the 
infamous --tags bug in bitbake 1.8.10.

Note that the angstrom sourcemirror has been real good at hiding the 
bitbake 1.8.10 bug.

regards,

Koen

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

[Ulf Samuelsson]

> On 08-12-08 17:26, 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.
> 
> Sourcemirrors and tarballstashes in OE provide tarballs, not 1:1 mirrors 
> of the scms. Had you actually read the error message you would have 
> noticed that it did something like:
> 

I don't have it in front of me, but IIRC the recipy for u-boot.git 
tries to do *git* access to the *source mirror*.
It was not trying to download a tarball.
That must simply be wrong.

> 1) try source mirror for tarball -> FAIL
> 2) try upstream repo -> FAIL
> 3) error out
> 
> if 1) fails it means the autobuilder hasn't build and mirror that rev 
> yet. 2) means an error on your end, be it corporate firewall or the 
> infamous --tags bug in bitbake 1.8.10.
> 
> Note that the angstrom sourcemirror has been real good at hiding the 
> bitbake 1.8.10 bug.
> 
> regards,
> 
> Koen
> 


Best Regards
Ulf Samuelsson

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

[Philip Balister]

[-- 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 --]

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

[Ulf Samuelsson]

>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 ...

I usually prefer typing with fingers ;-)

>
>Philip
>
>If no gets to it, I'll look at i
>>

Thanks,

The sooner I get access, the sooner I can provide the updates.


>> 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
>>

Best Regards
Ulf Samuelsson                ulf@atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavallerivägen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

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

[Robert Schuster]

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

Hi Ulf,

somehow nobody cared to answer this :$
Ulf Samuelsson schrieb:
> Is the "personal" git tree really personal, or can you have
> a git tree which is available to a group?
We normally give r/w access to individuals. With write access you have
the possibility to create user branches. After you fixed/added/whatever
a certain feature you can propose your changes on the list and if its
fine it can be merged.

> It makes sense for me to have an "atmel" group which I
> could share with other interested atmel employees.
I think the closest you can get with git is that one person commits on
behalf of someone else, e.g. git commit --author <the other person>

Of course it would also be possible to give write access to more people.

> Who is making decisions on access?
The OE team. Someone proposes you and then the rest of OE informally
votes. If no one has strong objections which needs to be discussed
write access will be granted.

I will write that proposal for you. :)

Regards
Robert

> 
> 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: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 268 bytes --]

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

[Ulf Samuelsson]

>Ulf Samuelsson wrote:
>> I have now succeeded (after some hassle) to build
>> Angstrom for the AT91SAM9263EK using:
>>
>> linux-2.6.18-rc7     Requires new recipy
>> u-boot-1.3.4          Requires new recipy
>
>Any chance you could use u-boot-2008.10 instead? I've been meaning to
>add that version as well.

I think that would be just another 5 minutes to add the recipy.

To test it is another things.
I started the build on Friday evening, and while needing some fixing,
it was not complete until Sunday at 18:00 on my laptop.
Also it is eating a lot of my hard disk, so
realistically I can only test building the recipy for the AT91SAM9263EK.

If it is an issue to get the git access, I can send the added recipies to 
the list.

>Philip
>
>> dataflashboot.bin    Requires a patch and updated recipy.
>> shasum-native        Recipy need bugfix.
>> qemu                     Need to update host files for OpenSuSE 10.2.
>> checksums.ini        Needs to be updated with data for four tarballs.
>>
>> While doing that, I also updated the machine descriptions for the
>> at32stk1000 and atngw100 to use the latest u-boot,
>> and added/cleaned out some machine descriptions for other at91sam9 
>> machines
>>
>> Would like to share it with the community,
>> so access to a personal git tree would be nice.
>>
>> Best Regards
>> Ulf Samuelsson
>>
>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>

Best Regards
Ulf Samuelsson