Re: Compiling problems
Hi Alberto, Marc Bantle wrote: Build works fine for me. My local.conf looks like this MACHINE = "fic-gta01" DISTRO = "openmoko" BUILD_ARCH = "i686" INHERIT += "rm_work" make update-makefile && make clean && make setup update all Update: after the above clean, I also get a build error (http://pastebin.ca/843715). Unfortunately I get it on kernel build already, so I can`t confirm your problem. This also happens, when I build entirely from scratch. Marc ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Very basic and fundamental question about the Neo
On Sun, 06 Jan 2008 00:35:29 +0100, "Piotr Duda" <[EMAIL PROTECTED]> said: > > > [...] > > Look at the answer from Mickey on the post with subject 'Neo faulty?' > > from Jan, 1st. > > It explains what you're looking for. > > no, it doesn't. It only explains "power leaking when Neo is off" problem. > Nicolas is asking why the Neo sucks the power so fast when it is on. > Nicolas check this one out: > http://wiki.openmoko.org/wiki/Neo1973_GTA01_Power_Management > The page is saying that the power management software is in very > beginning ok, true ;) > stage. Lets hope that this is only a software and no another hidden bug > in hardware. that'd be another important question: Do you think I'd need a GTA02 in order to get a fully working battery? I mean I am not really that much interested in the additional features of GTA02, so I'd be satisfied with GTA01. However, if that power management issue is handled very differently in GTA02 I'd be forced to buy a new device ... Or am I thinking along the wrong lines? regards, Nicolas > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Compiling problems
Dear Marc, thanks for your reply. It looks like you have a different problem: it complains while not being able to find quilt: > sh: quilt: command not found Now I can see the openmoko-terminal2 package, but my distribution is looking for version 3542, while the available version is 3777. (I tried with the sequence: make setup update openmoko-devel-image) Is there a way to print the version number of all (or some) packages ? I think I cannot postpone learning how to use all the different pieces (monotone, bitbake, etc) ... Alberto. Marc Bantle wrote: > Hi Alberto, > > Marc Bantle wrote: >> Build works fine for me. My local.conf looks like this >> >> MACHINE = "fic-gta01" >> DISTRO = "openmoko" >> BUILD_ARCH = "i686" >> INHERIT += "rm_work" >> >> make update-makefile && make clean && make setup update all > > Update: > after the above clean, I also get a build error > (http://pastebin.ca/843715). Unfortunately I get it on kernel build > already, so I can`t confirm your problem. This also happens, when I > build entirely from scratch. > > Marc > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Very basic and fundamental question about the Neo
On Jan 6, 2008 8:15 PM, Nicolas Linkert <[EMAIL PROTECTED]> wrote: > > that'd be another important question: Do you think I'd need a GTA02 in > order to get a fully working battery? I mean I am not really that much > interested in the additional features of GTA02, so I'd be satisfied with > GTA01. However, if that power management issue is handled very > differently in GTA02 I'd be forced to buy a new device ... Or am I > thinking along the wrong lines? > You can always update the software when the issue is resolved. But you should be aware of that gta02 will have a battery with higher capacity. Maybe you want a different battery also? But the main issue is the power management which hopefully will be fixed. -- Join the FSF as an Associate Member at: http://www.fsf.org/register_form?referrer=5774> ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Small question about the Neo1973 interface
Hi. Surfing the net about the Neo, I found the old (?) interface (for example: http://youtube.com/watch?v=tQPjfUqp-dk or the captures in the Wiki). Did you think it will be possible and simple to reinstall this one in place of the new one? Looking at the sources, I've noticed the matchbox vs. xglamo (?). Am I right? Whatever, good job for the whole team engaged in this process. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Very basic and fundamental question about the Neo
Hallo, * Nicolas Linkert <[EMAIL PROTECTED]> [06-01-08 20:15]: > that'd be another important question: Do you think I'd need a GTA02 in > order to get a fully working battery? I mean I am not really that much > interested in the additional features of GTA02, so I'd be satisfied with > GTA01. However, if that power management issue is handled very > differently in GTA02 I'd be forced to buy a new device ... Or am I > thinking along the wrong lines? I have read some pages from CPU doku and i think there isn't much work to be done, because main thinks are allready there but they don't have enough glue. For the basic things we only need an interface wich could vary the cpu freq. and set it to SLOW mode. Then a program like cpufreqd or so to drive this interface. With this limited power management we could save the most power, i think. Tim Niemeyer signature.asc Description: Digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Toolchain alpha release
On Sat, Jan 05, 2008 at 10:59:39PM -0300, Werner Almesberger wrote:
>
> I found one little problem with setup-env: when I try to build u-boot
> or the kernel with it, ld fails due to the LDFLAGS, which are defined
> as follows:
>
> export LDFLAGS="-L${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib
> -Wl,-rpath-link,${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -Wl,-O1"
>
> Now, both u-boot and kernel invoke "ld" directly and not through "cc"
> or "gcc". Unfortunately, "ld" doesn't understand the option -Wl, so
> it fails.
>
> We couldn't just omit the -Wl, since "gcc" doesn't understand -rpath-link,
> and we wouldn't want to unconditionally compile with -O1 anyway. But in
> what scenario do we actually need to set these flags ? As far as I can
> tell, just plain use of arm-angstrom-linux-gnueabi-gcc or
> arm-angstrom-linux-gnueabi-ld gets all the search paths right.
>
> If we do have to set LDFLAGS, I can think of the following ways to work
> around breaking u-boot and kernel builds:
>
> 1) don't use setup-env but define only PATH (which is all kernel and
>u-boot really need anyway)
>
> 2) make LDFLAGS= ...
>
> 3) LDFLAGS= make ...
>
> What I don't like about 2) and 3) is that they make an already too long
> command even longer, and that this may let more environment variables
> slip through and cause subtle breakage. 1) looks much safer.
>
> Would you agree that, if we have to keep LDFLAGS in setup-env, 1) best
> reflects proper use of the toolchain in these cases ? If not, how would
> you propose to solve this problem ?
>
Yes, I met this one before and I solved it by 1). This environment
setting is dumped and modified from OE but the way it uses LDFLAGS is
strange. However, if this got fixed, something other then kernel or
uboot might break, so I just leave it as it is.
I think if one wants to use toolchain this kind of problems will
always happen. To fully avoid it we have to use OE. For now the
users of toolchain will just have to customize it to fit their own
usage. I am thinking about dumping the run.* scripts OE generated
along with the source package to solve this but haven't got time to
really look at it.
- John
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
