[ECOS] Build fails after CVS update

[ECOS] Build fails after CVS update

[Rutger Hofman]

Hi list,

I updated to the most recent version of the CVS list; the previous 
checkout was from last february, not too long ago; but I ran into some 
problems:

= the Legacy Flash stuff has disappeared, but I use it (I think I might 
be the only user, but still!). I can add it back of course.
= more seriously: after some conflict resolution, I can instruct 
ecosconfig to create a tree, which it does without reporting any errors. 
But it doesn't create a pkgconf/hal.h. It does create/copy a number of 
include files from my ARM configuration, like hal_arm.h

I thought many this was to do with an incompatible version of 
ecosconfig, so I rebuilt that from today's checkout. It made no difference.

Any clue how I can get a working build again?

Rutger

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Build fails after CVS update

[Gary Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rutger Hofman wrote:
> Hi list,
> 
> I updated to the most recent version of the CVS list; the previous
> checkout was from last february, not too long ago; but I ran into some
> problems:
> 
> = the Legacy Flash stuff has disappeared, but I use it (I think I might
> be the only user, but still!). I can add it back of course.
> = more seriously: after some conflict resolution, I can instruct
> ecosconfig to create a tree, which it does without reporting any errors.
> But it doesn't create a pkgconf/hal.h. It does create/copy a number of
> include files from my ARM configuration, like hal_arm.h
> 
> I thought many this was to do with an incompatible version of
> ecosconfig, so I rebuilt that from today's checkout. It made no difference.
> 
> Any clue how I can get a working build again?

What command did you use to checkout/update?
Did you do this in a clean directory (checkout)?

- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGhR93maKbSsQGV8ARAhIBAJ96hpnMcz0M4y+g8PZmw3Q6mF2vowCfZb9o
kqvYCwVvdvMVC4YYegnGhqI=
=WlUC
-----END PGP SIGNATURE-----

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Build fails after CVS update

[Rutger Hofman]

Gary Thomas wrote:
> Rutger Hofman wrote:
>> Hi list,
>>
>> I updated to the most recent version of the CVS list; the previous
>> checkout was from last february, not too long ago; but I ran into some
>> problems:
>>
>> = the Legacy Flash stuff has disappeared, but I use it (I think I might
>> be the only user, but still!). I can add it back of course.
>> = more seriously: after some conflict resolution, I can instruct
>> ecosconfig to create a tree, which it does without reporting any errors.
>> But it doesn't create a pkgconf/hal.h. It does create/copy a number of
>> include files from my ARM configuration, like hal_arm.h
> 
> What command did you use to checkout/update?
> Did you do this in a clean directory (checkout)?

Well, my .ecc file turns out to be inconsistent, because it used some 
flash dependencies which are gone -- the flash thingy was the problem 
anyway. I cut them away, and now I can generate a tree.

The next problem is now with the flash stuff. The "Legacy API" flash 
code is dependent on older versions of the flash code, so it won't compile.

What is the best way to tackle this? What is the quickest way to tackle 
this? I don't want to port our vendor's flash implementation to the 
newer flash implementation. Is there a way that I can easily restore the 
legacy API stuff?

Rutger

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Build fails after CVS update

[Gary Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gary Thomas wrote:
> Rutger Hofman wrote:
>> Hi list,
> 
>> I updated to the most recent version of the CVS list; the previous
>> checkout was from last february, not too long ago; but I ran into some
>> problems:
> 
>> = the Legacy Flash stuff has disappeared, but I use it (I think I might
>> be the only user, but still!). I can add it back of course.
>> = more seriously: after some conflict resolution, I can instruct
>> ecosconfig to create a tree, which it does without reporting any errors.
>> But it doesn't create a pkgconf/hal.h. It does create/copy a number of
>> include files from my ARM configuration, like hal_arm.h
> 
>> I thought many this was to do with an incompatible version of
>> ecosconfig, so I rebuilt that from today's checkout. It made no difference.
> 
>> Any clue how I can get a working build again?
> 
> What command did you use to checkout/update?
> Did you do this in a clean directory (checkout)?
> 

Also, what's the target?  How did you configure eCos?

I just tried this with a fresh checkout, using an ARM target (aaed)
and had no troubles building either RedBoot or an eCos kernel.

- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGhSUOmaKbSsQGV8ARAoDkAKCDSAT+szCKvf6dFqbh/D9SjPlgngCeNP8X
zi06wlvqppRe10Sq+sYlLS4=
=Huzv
-----END PGP SIGNATURE-----

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Legacy Flash implementation (was: Re: [ECOS] Build fails after CVS update)

[Rutger Hofman]

Rutger Hofman wrote:
>> Rutger Hofman wrote:
>>> I updated to the most recent version of the CVS list; the previous
>>> checkout was from last february, not too long ago; but I ran into some
>>> problems:
>>>
>>> = the Legacy Flash stuff has disappeared, but I use it (I think I might
>>> be the only user, but still!).

> The ... problem is with the flash stuff. The "Legacy API" flash 
> ... won't compile.
> 
> What is the best way to tackle this? What is the quickest way to tackle 
> this? I don't really want to port our vendor's flash implementation to the 
> newer flash implementation. Is there a way that I can easily restore the 
> legacy API stuff?

A week ago, I asked this. I think it has escaped the attention of the 
list. Right now, to keep things alive I had to revert to my previous 
eCos checkout. I would really like to upgrade to bleeding-edge CVS (e.g. 
I want to add my external RTC chip, DS1339, which is driven via I2C, but 
the I2C interface has changed/improved meanwhile).

How would I go about upgrading? Our vendor has provided Flash drivers 
but they speak the old Legacy API. Would it be a breeze to convert them 
to the newer Flash API? Or would it be easier to try to reinstate a 
Legacy portability layer, with maybe symbol name changes in our vendor's 
code to avoid name conflicts?

Rutger Hofman
VU Amsterdam


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Legacy Flash implementation (was: Re: [ECOS] Build fails after CVS update)

[Andrew Lunn]

On Fri, Jul 06, 2007 at 12:35:19PM +0200, Rutger Hofman wrote:
> Rutger Hofman wrote:
>>> Rutger Hofman wrote:
>>>> I updated to the most recent version of the CVS list; the previous
>>>> checkout was from last february, not too long ago; but I ran into some
>>>> problems:
>>>>
>>>> = the Legacy Flash stuff has disappeared, but I use it (I think I might
>>>> be the only user, but still!).
>
>> The ... problem is with the flash stuff. The "Legacy API" flash ... won't 
>> compile.
>> What is the best way to tackle this? What is the quickest way to tackle 
>> this? I don't really want to port our vendor's flash implementation to the 
>> newer flash implementation. Is there a way that I can easily restore the 
>> legacy API stuff?
>
> A week ago, I asked this. I think it has escaped the attention of the list. 

Sorry, been away. 

I need more details. I don't see anything in the ChangeLogs about
removing the Legacy API. 

Do you know which change caused the problem? What exactly is the
problem you are having now?

        Thanks
                Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Legacy Flash implementation

[Rutger Hofman]

Andrew Lunn wrote:
> On Fri, Jul 06, 2007 at 12:35:19PM +0200, Rutger Hofman wrote:
>> Rutger Hofman wrote:
>>>> Rutger Hofman wrote:
>>>>> I updated to the most recent version of the CVS list; the previous
>>>>> checkout was from last february, not too long ago; but I ran into some
>>>>> problems:
>>>>>
>>>>> = the Legacy Flash stuff has disappeared, but I use it (I think I might
>>>>> be the only user, but still!).
>>> The ... problem is with the flash stuff. The "Legacy API" flash ... won't 
>>> compile.
>>> What is the best way to tackle this? What is the quickest way to tackle 
>>> this? I don't really want to port our vendor's flash implementation to the 
>>> newer flash implementation. Is there a way that I can easily restore the 
>>> legacy API stuff?
>> A week ago, I asked this. I think it has escaped the attention of the list. 
> 
> Sorry, been away. 
> 
> I need more details. I don't see anything in the ChangeLogs about
> removing the Legacy API. 
> 
> Do you know which change caused the problem? What exactly is the
> problem you are having now?

Ahum. I guess I had forgotten this now, but it appears that Flash v2 
(including legacy API) requires CVS branch flash_v2 in the checkout. 
Having a different branch is entirely consistent with my problems.

Sorry for the hassle,

Rutger

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Legacy Flash implementation

[Rutger Hofman]

Rutger Hofman wrote:
> Ahum. I guess I had forgotten this now, but it appears that Flash v2 
> (including legacy API) requires CVS branch flash_v2 in the checkout. 
> Having a different branch is entirely consistent with my problems.

OK, it's trivial to get -r flash_v2_tag. But this effectively gives me 
an eCos CVS snapshot from 2004, with patches *only* to the flash 
modules. I would very much prefer to be in sync with the main eCos CVS 
trunk and still have flash_v2 -- I want the newer i2c, for example.

I think there are a number of different solutions to this:

1) eCos maintainers merge the flash v2 branch into the main trunk. This 
would be perfect.

2) I myself merge the v2 branch into my checkout of the main trunk. I 
attempted this, and it gives me a number of conflicts, especially in 
redboot flash.c. The conflicts are caused by 2 additions in the main 
trunk to redboot flash.c: REDBOOT_FLASH_REVERSE_BYTEORDER and 
CYGOPT_REDBOOT_REDUNDANT_FIS. Addition of an 'ls' command apparently is 
handled seemlessly by CVS. Mostly, the conflict resolution in redboot 
flash.c seems to be straightforward, but a few difficult sites reaain. 
Also, as things are with CVS, there may be invisible conflicts: both 
parent branches may have added code in different places, but the 
additions are inconsistent. For the rest of the tree, of course the same 
holds, but my feeling is that the merge is painless, because it's very 
much localized.
Now, I don't build redboot, I build eCos applications. So any remaining 
errors in redboot flash.c are not going to bite me, right? But it still 
feels unsatisfactory to have a checkout that may be broken in redboot.
The obvious downside of this approach is that I will have a conflict 
each time anything related to flash is changed in the repository. This 
is not so very attractive!

Rutger Hofman
VU Amsterdam

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Legacy Flash implementation

[Andrew Lunn]

On Mon, Jul 09, 2007 at 01:09:22PM +0200, Rutger Hofman wrote:
> Rutger Hofman wrote:
>> Ahum. I guess I had forgotten this now, but it appears that Flash v2 
>> (including legacy API) requires CVS branch flash_v2 in the checkout. 
>> Having a different branch is entirely consistent with my problems.
>
> OK, it's trivial to get -r flash_v2_tag. But this effectively gives me an 
> eCos CVS snapshot from 2004, with patches *only* to the flash modules. I 
> would very much prefer to be in sync with the main eCos CVS trunk and still 
> have flash_v2 -- I want the newer i2c, for example.
>
> I think there are a number of different solutions to this:
>
> 1) eCos maintainers merge the flash v2 branch into the main trunk. This 
> would be perfect.

A long, long time ago, it was planned to merge the flash_v2 branch
into the trunk when eCos 3.0 was released. Changes to flash can
introduce big problems. eg turn a device into a brick if it does not
work correctly. So it was planned to do quite a bit of testing first,
which is normal for a major release.

However the plan for the 3.0 release was to wait until eCos could be
signed over to the FSF. This has taken years and years to get the
copyright issues sorted out. I beleave all but eCosCentric originated
code can now be assigned to FSF, but since eCosCentric are the big
drivers for making 3.0 happen, not much has happened. 

If 3.0 is not going to happen real soon now we could merge the
flash_v2 branch in. eCosCentrics private tree already uses
flash_v2. So they have obviously done lots of testing of the generic
parts, plus the device drivers there customers use. So if eCosCentric
could contribute any patches they have we could do a merge and be
reasonable sure we are not going to brick anybodies device.

           Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss