Re: [uClinux-dev] BusyBox issues
John Williams wrote: > I've found that if you change the busybox config, you have to rebuild it > (make user_only) *twice* before doing a make romfs, to ensure all new > applets are built and properly symlinked. Never taken the time to > figure out why, just a gotcha. > > Anyone else seen this? Last time I looked, (Busybox-1.00), it's because of a bug in Busybox's Makefile. It tries to create dependency files for each CONFIG_ option, just like the Linux kernel does. If that worked, changing the config would trigger a recompile of only those files which are affected by the option changes, which would be perfect. But it doesn't work because a path is wrong somewhere in the Makefile. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] GTK DirectFB
Hi, Did someone succeed to port the last GTK release to ARM9/Linux2.6 target (DirectFB) ? Now GTK needs a lot of additionnal libraries and a big memory space to run What is your experience on a 200MHz/64Mo RAM target ? Regards, Xavier ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] BusyBox issues
Hi all, This is why I some months ago suggested to take the "glue makefile" concept in use :) The glue makefile concept is that in snapgear/user every "package" looks like this snapgear/[user|lib]/ Makefile This structure is owned by snapgear. The "glue makefile" is the makefile above. The glue makefile is the little magician making it work so much smoother, I have this implemented in a "snapgear like build environment" I did a couple of years ago and when I started with the snapgear stuff for a client, I was thrilled how similar snapgear was/is :) For a specific package, why not take busybox as example :), it looks like: snapgear/user/busybox Makefile busybox-1.4.1 The busybox-1.4.1 is as it comes from busbox site, perhaps with bugfixes etc. The thing is, we shouldn't spread around stuff in the package just to be able to build it... In the above scheme we don't have any nameclashes whatsoever, we can do all sorts of trix in the gluemakefile for configuring, installing romfs etc without having to modify the package itself. It will also be much much quicker to update the package to a newer version and, which is quite important for longterm projects, several versions can coexist nicely. Attached is an example of such a glue makefile, which makes it possible to integrate cyassl into snapgear/lib very easy. To take some steps even further, here is some more feature we can build into this concept. A package will then look like: snapgear/[user|lib]/ Makefile downloads patches The glue Makefile should now have functionality for downloading the package from network (if it isn't already in downloads dir) and when building it unpacks it and applies patches (if it isn't unpacked already) and as before build, install etc. In this way, we also have a good sense of what patches we do to a package. It will be much simplier to bring these fixes upstream. It will also separate our fixes/additions so that the package maintainer understands the changes better (sometimes this is a really tidous job :) and perhaps more easily will accept our changes. On the other hand, this is about where I think I lost you all because there wasn't any feedback here... or perhaps it aint a good idea? :) Best regards, Per David McCullough wrote: Jivin John Williams lays it down ... Hi David, David McCullough wrote: Jivin John Williams lays it down ... David McCullough wrote: Jivin Steve Bennett lays it down ... This often (always?) happens if you reconfigure busybox and rebuild. The solution is simply to clean out busybox after reconfiguring to ensure that everything is rebuilt. $ make user/busybox_clean The code in user/busbox/Makefile is supposed to do a clean whenever the config is changed. I think we should change: .config.mkconfig: $(ROOTDIR)/config/.config ... $(MAKE) clean; \ ... to a "distclean" perhaps to ensure everything is truly cleaned out. Someone want to try it :-) :-) I've found that if you change the busybox config, you have to rebuild it (make user_only) *twice* before doing a make romfs, to ensure all new applets are built and properly symlinked. Never taken the time to figure out why, just a gotcha. Anyone else seen this? Most likely because there is no Makefile seperation, as in the Makefile that builds the config has probably got dependancies on the config that do not get fixed. I am guessing a good solution will be: create a "makefile" that generates the config, checks the config cleans the old build and rebuilds using the "Makefile" as needed. I'm a bit wary of mixing lowercase and uppercase [mM]akefiles in the same dir, for the reason that one day I'll have to stop putting off supporting cygwin for MicroBlaze builds! I know this is already done extensively, but no point in adding to it! On that note, a while ago a Makefile.uc concept was proposed - user/Makefile would look for a .uc" makefile first and make -f on that, if possible. There is always the GNUMakefile option as well. Just seems uglier to me. The .uc would at least make it uc-specific I guess and able to be included with source distros etc in a non-intrusive way. that way it has no dependancies on anything busybox related. Oh and uses distclean as well ;-) Perhaps even have it build a symlink tree so we can do all the BB stuff in a subdir so we can be really sure it works as clean just removes the directory :-) I can send an example of a "makefile" that does the symlinks if anyone wants to tackle it, This isn't urgent from my perspective, busy rebuilding toolchains at the moment :) Joy :-) Cheers, Davidm # Glue Makefile for yassl # # Author: Per Hallsmark <[EMAIL PROTECTED]> # PKG = cyassl-0.6.2 all: $(PKG)/Makefile $(MAKE) -C $(PKG) $(PKG)/Makefile: cd
[uClinux-dev] test
-- Daniele Ziglioli Signal S.r.l. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 4/4] NOMMU: Make it possible for RomFS to use MTD devices directly
Andrew Morton <[EMAIL PROTECTED]> wrote: > > + brelse(bh); > > A little fyi: brelse() is rather old-fashioned, and has a usually unneeded > test for non-null bh in it. In situations where we know that the pointer is > valid, let's please use put_bh(). That's what was in the old romfs. I can make the change, though. Hmmm... brelse() isn't quite equivalent to put_bh(), but the difference seems just to be the message you get if you over-release a buffer head - and the resulting refcount on the BH if that happens. > Anyway, I'll assume that dwmw2 will be handling this patch series. I assume so. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Can't get Gadget Serial driver to start on WindowsXPPro
Butok Andrey-B00423 wrote: > Option 1: > The better way is to edit the > /uClinux-dist/vendors/Freescale/M5329EVB/Makefile > > ... > DEVICES = \ > ... > ttygserial,c,127,0 > ... > Ah, this is what I was looking for - the better way! As you can tell from this question, I am extremely new to uClinux, though I've been greatly impressed already! It does look like I'll have to get my revision control setup (e.g. vendor drop for uClinux, etc.) in place, now! Thanks again! -Bob ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] BusyBox issues
Hi Per, I believe your concept is similar to what Greg/David have started with 'makefile' (versus 'Makefile'), creating a build directory, and running configure from the build directory (net-snmp and quagga are examples). In other words, 'makefile' contains the uClinux/snapgear "glue". The one difference, between your proposal and makefile, is specifying the package version and (I assume) creating an additional directory level. Also, the 'makefile' scheme, it appears, is being applied as user packages are being added and/or updated. Another point to consider is uClinux/snapgear specific patches for the package. Presently, these patches are applied directly to the package. With an extra directory level (???), would the uClinux/snapgear patch be distributed in the parent directory and applying the patch be incorporated into the "glue makefile"? Just running with your thought. ...doug --- Per Hallsmark wrote: > Hi all, > > This is why I some months ago suggested to take the > "glue makefile" > concept in use :) > > The glue makefile concept is that in snapgear/user > every "package" looks > like this > > snapgear/[user|lib]/ >Makefile > > This structure is owned by snapgear. The "glue > makefile" is the makefile > above. > The glue makefile is the little magician making it > work so much smoother, > I have this implemented in a "snapgear like build > environment" I did a > couple > of years ago and when I started with the snapgear > stuff for a client, I was > thrilled how similar snapgear was/is :) > > For a specific package, why not take busybox as > example :), it looks like: > snapgear/user/busybox >Makefile >busybox-1.4.1 > > The busybox-1.4.1 is as it comes from busbox site, > perhaps with bugfixes > etc. > The thing is, we shouldn't spread around stuff in > the package just to be > able to build it... > In the above scheme we don't have any nameclashes > whatsoever, we can do all > sorts of trix in the gluemakefile for configuring, > installing romfs etc > without having > to modify the package itself. > It will also be much much quicker to update the > package to a newer version > and, which is quite important for longterm projects, > several versions > can coexist > nicely. > > Attached is an example of such a glue makefile, > which makes it possible to > integrate cyassl into snapgear/lib very easy. > > To take some steps even further, here is some more > feature we can build into > this concept. A package will then look like: > > snapgear/[user|lib]/ >Makefile >downloads >patches > > The glue Makefile should now have functionality for > downloading the > package from network (if it isn't already in > downloads dir) and when > building it unpacks it and applies patches (if it > isn't unpacked already) > and as before build, install etc. > In this way, we also have a good sense of what > patches we do to a package. > It will be much simplier to bring these fixes > upstream. > It will also separate our fixes/additions so that > the package maintainer > understands > the changes better (sometimes this is a really > tidous job :) and perhaps > more > easily will accept our changes. > On the other hand, this is about where I think I > lost you all because > there wasn't > any feedback here... or perhaps it aint a good idea? > :) > > Best regards, > Per > > > David McCullough wrote: > > Jivin John Williams lays it down ... > > > >> Hi David, > >> > >> David McCullough wrote: > >> > >>> Jivin John Williams lays it down ... > >>> > >>> > David McCullough wrote: > > > > Jivin Steve Bennett lays it down ... > > > > > > > >> This often (always?) happens if you > reconfigure busybox and rebuild. > >> The solution is simply to clean out busybox > after reconfiguring to > >> ensure > >> that everything is rebuilt. > >> > >> $ make user/busybox_clean > >> > > The code in user/busbox/Makefile is supposed > to do a clean whenever > > the config is changed. > > > > I think we should change: > > > > .config.mkconfig: $(ROOTDIR)/config/.config > > ... > > $(MAKE) clean; \ > > ... > > > > to a "distclean" perhaps to ensure everything > is truly cleaned out. > > Someone want to try it :-) :-) > > > I've found that if you change the busybox > config, you have to rebuild it > (make user_only) *twice* before doing a make > romfs, to ensure all new > applets are built and properly symlinked. > Never taken the time to > figure out why, just a gotcha. > > Anyone else seen this? > > >>> Most likely because there is no Makefile > seperation, as in the > >>> Makefile that builds the config has probably got > dependancies > >>> on the config that do not get fixed. >
[uClinux-dev] MCF5275EVB, booting linux from Flash
Hi,
I am able to boot uclinux with dBUG from SDRAM ("go 0x2") and now I
want to boot uclinux from Flash (2MB). There is any procedure on how to
do?
I prefer to keep dBUG, do I have to install coLilo? uclinux should be
compressed/decompressed? how?
Any help would be greatly appreciated, thank you,
Calin.
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] MCF5275EVB, booting linux from Flash
El Jueves, 22 de Febrero de 2007 15:07, Calin Onofrei escribió:
> Hi,
>
> I am able to boot uclinux with dBUG from SDRAM ("go 0x2") and now I
> want to boot uclinux from Flash (2MB). There is any procedure on how to
> do?
> I prefer to keep dBUG, do I have to install coLilo? uclinux should be
> compressed/decompressed? how?
Maybe you can modificate dBUG to boot from flash. I think you need CodeWarrior
for that, so I have not tried it.
I have ported colilo and u-boot for m5275evb and I recomend you u-boot since
it has MORE functionalities than colilo ie. networking and flash writing. I
have sent the patch to u-boot list this week, or tell me if you want it.
u-boot runs starting at second MB, but then it has problems with the flash.
I have it right now instead of dBUG with no problem. Only different commands
but same functions (or more).
Regards,
Aitor.
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] MCF5275EVB, booting linux from Flash
Hi Aitor,
I would really like to try your patches for uboot. Would you mind
sending them to me?
What version of uboot are you working with?
Mike
On Thu, 2007-02-22 at 15:34 +0100, Aitor Calderón wrote:
> El Jueves, 22 de Febrero de 2007 15:07, Calin Onofrei escribió:
> > Hi,
> >
> > I am able to boot uclinux with dBUG from SDRAM ("go 0x2") and now I
> > want to boot uclinux from Flash (2MB). There is any procedure on how to
> > do?
> > I prefer to keep dBUG, do I have to install coLilo? uclinux should be
> > compressed/decompressed? how?
>
> Maybe you can modificate dBUG to boot from flash. I think you need
> CodeWarrior
> for that, so I have not tried it.
>
> I have ported colilo and u-boot for m5275evb and I recomend you u-boot since
> it has MORE functionalities than colilo ie. networking and flash writing. I
> have sent the patch to u-boot list this week, or tell me if you want it.
>
> u-boot runs starting at second MB, but then it has problems with the flash.
> I have it right now instead of dBUG with no problem. Only different commands
> but same functions (or more).
>
> Regards,
> Aitor.
> ___
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] MCF5275EVB, booting linux from Flash
Thanks Aitor,
I've found your patch for u-boot(u-boot-1.1.6-5275.patch. I have another
question please. After installing u-boot, there is any special configuration
for uclinux to start from Flash?
Regards,
Calin.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aitor Calderón
Sent: Thursday, February 22, 2007 9:34 AM
To: uClinux development list
Subject: Re: [uClinux-dev] MCF5275EVB, booting linux from Flash
El Jueves, 22 de Febrero de 2007 15:07, Calin Onofrei escribió:
> Hi,
>
> I am able to boot uclinux with dBUG from SDRAM ("go 0x2") and now
> I want to boot uclinux from Flash (2MB). There is any procedure on how
> to do?
> I prefer to keep dBUG, do I have to install coLilo? uclinux should be
> compressed/decompressed? how?
Maybe you can modificate dBUG to boot from flash. I think you need CodeWarrior
for that, so I have not tried it.
I have ported colilo and u-boot for m5275evb and I recomend you u-boot since it
has MORE functionalities than colilo ie. networking and flash writing. I have
sent the patch to u-boot list this week, or tell me if you want it.
u-boot runs starting at second MB, but then it has problems with the flash.
I have it right now instead of dBUG with no problem. Only different commands
but same functions (or more).
Regards,
Aitor.
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] MCF5275EVB, booting linux from Flash
I found the patch as well so no need to send it.
Thanks anyway,
Mike
On Thu, 2007-02-22 at 11:15 -0500, Calin Onofrei wrote:
> Thanks Aitor,
>
> I've found your patch for u-boot(u-boot-1.1.6-5275.patch. I have another
> question please. After installing u-boot, there is any special configuration
> for uclinux to start from Flash?
> Regards,
> Calin.
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aitor Calderón
> Sent: Thursday, February 22, 2007 9:34 AM
> To: uClinux development list
> Subject: Re: [uClinux-dev] MCF5275EVB, booting linux from Flash
>
> El Jueves, 22 de Febrero de 2007 15:07, Calin Onofrei escribió:
> > Hi,
> >
> > I am able to boot uclinux with dBUG from SDRAM ("go 0x2") and now
> > I want to boot uclinux from Flash (2MB). There is any procedure on how
> > to do?
> > I prefer to keep dBUG, do I have to install coLilo? uclinux should be
> > compressed/decompressed? how?
>
> Maybe you can modificate dBUG to boot from flash. I think you need
> CodeWarrior for that, so I have not tried it.
>
> I have ported colilo and u-boot for m5275evb and I recomend you u-boot since
> it has MORE functionalities than colilo ie. networking and flash writing. I
> have sent the patch to u-boot list this week, or tell me if you want it.
>
> u-boot runs starting at second MB, but then it has problems with the flash.
> I have it right now instead of dBUG with no problem. Only different commands
> but same functions (or more).
>
> Regards,
> Aitor.
> ___
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
> ___
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] BusyBox issues
Hi Doug, Yes, you are correct, one of the main differences is the extra directory level. It looks simple but one actually gets alot from it, separating the snapgears makefiles (or building framework to put a name for it) from whatever build framework a package may have although most will have makefiles here too. (there do exist packages with other type of build systems) The main focus, I believe, should be that a open source build framework should be able to use open source packages with as little changes as necessary. Optimally, just untar'ing the package and the glue system will do the rest. The uClinux/snapgear patch for a specific package, would be distributed in the specific package patches directory, as I tried to describe in my first mail. So a packed package directory may look like (adding a / at the end to make it visible which are directories...) snapgear/user/busybox/ Makefile downloads/ patches/ After the build, where the glue Makefile then have downloaded the package (if nescessary) and applied any patches (if nescessary), it will look like: snapgear/user/busybox/ Makefile downloads/ patches/ busybox-1.4.1/ Ultimatly, the uClinux/Snapgear distro could also be made alot smaller since we don't have to put in every packages tarball in the distro. This is in theory though because in practice it turns out that some packages needs huge changes so the patch thing would make it difficult to work with the package. In my build environment (BiP, building in progess :) ) I had about 170 packages and about 15 of these didn't have any downloads directory, this because of their strange build system (think asterisk and zaptel... :) ). One has to be practical also, can't always run a idéa to its full extension... Another case is also when there is pure inhouse developed packages. The pure inhouse packages can of course be stored in svn directly without the download thing, but of course with a glue directory to keep everything logically correct (and ease if such a need arises later on). Doug Kehn wrote: Hi Per, I believe your concept is similar to what Greg/David have started with 'makefile' (versus 'Makefile'), creating a build directory, and running configure from the build directory (net-snmp and quagga are examples). In other words, 'makefile' contains the uClinux/snapgear "glue". The one difference, between your proposal and makefile, is specifying the package version and (I assume) creating an additional directory level. Also, the 'makefile' scheme, it appears, is being applied as user packages are being added and/or updated. Another point to consider is uClinux/snapgear specific patches for the package. Presently, these patches are applied directly to the package. With an extra directory level (???), would the uClinux/snapgear patch be distributed in the parent directory and applying the patch be incorporated into the "glue makefile"? Just running with your thought. ...doug --- Per Hallsmark wrote: Hi all, This is why I some months ago suggested to take the "glue makefile" concept in use :) The glue makefile concept is that in snapgear/user every "package" looks like this snapgear/[user|lib]/ Makefile This structure is owned by snapgear. The "glue makefile" is the makefile above. The glue makefile is the little magician making it work so much smoother, I have this implemented in a "snapgear like build environment" I did a couple of years ago and when I started with the snapgear stuff for a client, I was thrilled how similar snapgear was/is :) For a specific package, why not take busybox as example :), it looks like: snapgear/user/busybox Makefile busybox-1.4.1 The busybox-1.4.1 is as it comes from busbox site, perhaps with bugfixes etc. The thing is, we shouldn't spread around stuff in the package just to be able to build it... In the above scheme we don't have any nameclashes whatsoever, we can do all sorts of trix in the gluemakefile for configuring, installing romfs etc without having to modify the package itself. It will also be much much quicker to update the package to a newer version and, which is quite important for longterm projects, several versions can coexist nicely. Attached is an example of such a glue makefile, which makes it possible to integrate cyassl into snapgear/lib very easy. To take some steps even further, here is some more feature we can build into this concept. A package will then look like: snapgear/[user|lib]/ Makefile downloads patches The glue Makefile should now have functionality for downloading the package from network (if it isn't already in downloads dir) and when building it unpacks it and applies patches (if it isn't unpacked already) and as before build, install etc. In this way, we also have a good sense of what patches we do to a package. It will be much simplier to bring these fixes upstream. It will also separate our fixes/additio
Re: [uClinux-dev] BusyBox issues
Boy, I sure touched a live wire here, eh? Still, Thanks! Steve Bennett wrote: > Hi Bob, > > This often (always?) happens if you reconfigure busybox and rebuild. > The solution is simply to clean out busybox after reconfiguring to ensure > that everything is rebuilt. > > $ make user/busybox_clean > > Cheers, > Steve > > On 22/02/2007, at 10:45 AM, Robert S. Grimes wrote: > >> Hi, >> >> I'm not sure, but it seems BusyBox is difficult to build. I don't >> really know what is going on, but here's my experience so far. >> >> The first time I attempted to build uClinux (uClinux-dist-20070130, >> target board M5329EVB, ColdFire 5329), I selected a goodly number of >> BusyBox "commands". It would not build, seeming to fail during >> linking. So I reconfigured without it, and it all built fine. >> >> Then, I needed insmod, which seems to only ,be in BusyBox. I added >> it, selecting insmod (and I think find) and it built properly this >> time. Later, I added some more, and then it would not build again! >> >> So, I removed BusyBox, built the uClinux image just fine. Then, I >> reconfigured to include it, and just insmod, and it built again. >> >> I wish I wrote down the errors, but I recall they were of the form >> 'main_more not found' (or perhaps 'more_main'?). Others include >> main_ls, main_ls, main_mv (or again, the other order?). So I'm >> wondering: is there some sort of conflict between BusyBox "commands" >> and their "standalone" equivalents? Or am I missing something? It >> seems building BusyBox is rather fragile, but I think it is something >> I'm doing wrong - is that right? >> >> Thanks, all! >> -Bob >> ___ >> uClinux-dev mailing list >> uClinux-dev@uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev@uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev >> >> > > -- > WorkWare Systems Pty Ltd > W: www.workware.net.au > P: 0434 921 300 > F: 07 3102 9221 > E: [EMAIL PROTECTED] > > > > > ___ > uClinux-dev mailing list > uClinux-dev@uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev@uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Bad uClinux performance on Spartan-2e.
Hi: I have Spartan-2e board here which resembles to certain extent Spartan-3e starter kit. There are differences however - SDRAM instead of DDR, older Microblaze core, higher CPU clock, EMAC instead Etherlite, etc... I've attached auto-config.h files, generated by Petalogix BSP for both cases. I managed to compile and run u-boot and uClinux for both boards. However there is visible delay - 3-5 sec - when start any application (like "ls" for instance) on my Spartan-2e target under uClinux. The following observations have been done: 1) Delay depends on application's size: "ls" which in fact starts busybox (200K) takes several seconds to start while small "cat" launches quickly. 2) On Spartan-3e Starter Kit delay is also visible, but less than on my Spartan-2e based HW. Note that the Starter Kit CPU clock is little bit slower than mine (50MHz vs. 64MHz). 3) Simple memory read/write tests (I ran them from BRAM based code) show that my board performs even better than starter kit which is to be expected provided that clock is higher. I sounds for me that uClinux kernel uses some resources (cashes?) which are not well supported in older Spartan-2e architecture. Can somebody give me an idea where to look? Thanks, Leonid. auto-config-spartan-3e.h Description: auto-config-spartan-3e.h auto-config-spartan-2e.h Description: auto-config-spartan-2e.h ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] 5282 and 2GB SD cards
On Mittwoch, 21. Februar 2007, NZG wrote: > Personally I'll probably just force all cards to a 512 block size. > Any card that ignores this command and wants to use a different size > is just going to have to be declared unsupported to support this new > SD garbage. You don't need to set a block size. 512 is the default, even for those cards which have 1024 in the csd... regards Wolfgang -- Das Leben kann nur rückwärts verstanden, muß aber vorwärts gelebt werden. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] 5282 and 2GB SD cards
Yes I understand that, but assuming 512 to be the default is a violation of MMC specification 3.1, and I think it's better not to assume the hardware violates it (even if it does at the moment). This way, if some "crazy" manufacturer actually implements the specification, the software still works. NZG On Thursday 22 February 2007 3:18 pm, Wolfgang Mües wrote: > On Mittwoch, 21. Februar 2007, NZG wrote: > > Personally I'll probably just force all cards to a 512 block size. > > Any card that ignores this command and wants to use a different size > > is just going to have to be declared unsupported to support this new > > SD garbage. > > You don't need to set a block size. 512 is the default, even for those > cards which have 1024 in the csd... > > regards > > Wolfgang ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] 5282 and 2GB SD cards
Hi Nat, > Yes I understand that, but assuming 512 to be the default is a > violation of > MMC specification 3.1, and I think it's better not to assume the hardware > violates it (even if it does at the moment). > > This way, if some "crazy" manufacturer actually implements the > specification, > the software still works. At some point you will have to come to terms with the fact that SD cards have outgrown the SD standard ;o) The SD standard calls for a 128 bit descriptor (someone was thinking small) called the CSD. It has a 12 bit field to hold the number of blocks (c_size) and a 3 bit field to shift c_size (c_size_mult). The numner of blocks is calculated: BLOCKNR = ((csd.c_size + 1)*(0x01 << (csd.c_size_mult + 2))) Filling all these fields completely allows for a max of = (4095 + 1) * (0x01 << (7 + 2) ) = 2097152 blocks = 1MB at 512 bytes per block So, if you make SD cards, you can make 2G, 4G and 8G cards and there is a market for them, what do you do? How do you get a card to convey that it is larger than 1MB? It so happens that the 4 bit csd.rd_bl_len field that determines block length has some wiggle room. The block length is calculated: BLOCK_LEN = (0x01 << csd.rd_bl_len) But, everyone (except me) knows that all SD cards are accessed with 512 byte blocks (csd.rd_bl_len = 9). With 4 bits, csd.rd_bl_len could be as large as 15 (32768 bytes). So, this is where the extra size has been placed. Where would you place it? In the meantime, a new, proprietary SDHC standard has been established and we will start seeing SDHC capable devices (cameras, camcorders, etc.). These devices will be capable of recognizing and reading both SD and SDHC cards. The challenge for us will be how to get hold of the SDHC standard so we can add SDHC support to Linux/uClinux. RF > On Thursday 22 February 2007 3:18 pm, Wolfgang Mües wrote: > > On Mittwoch, 21. Februar 2007, NZG wrote: > > > Personally I'll probably just force all cards to a 512 block size. > > > Any card that ignores this command and wants to use a different size > > > is just going to have to be declared unsupported to support this new > > > SD garbage. > > > > You don't need to set a block size. 512 is the default, even for those > > cards which have 1024 in the csd... > > > > regards > > > > Wolfgang > ___ > uClinux-dev mailing list > uClinux-dev@uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev@uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [ANNOUNCE] uClinux-dist-20070130 release
Hi Gerg, Is there a (good :) ) reason why uClinux-dist/Makefile clean: target now deletes the $(LINUX)/include/asm symlink? This means that after a make clean you have to make oldconfig to get the symlink back. Perhaps this should be in distclean rather than clean? Cheers, John Greg Ungerer wrote: Hi All, I have generated a uClinux-dist-20070130 release. You can get it from the usual place: http://www.uclinux.org/pub/uClinux/dist/uClinux-dist-20070130.tar.gz http://www.uclinux.org/pub/uClinux/dist/uClinux-dist-20070130.tar.bz2 The uClinux-dist CVS, at cvs.uclinux.org, has been updated as well. It contains: . linux-2.6.19-uc0 . linux-2.4.32-uc0 . linux-2.0.39-uc2 . uClibc-0.9.27 . _lots_ of other application packages (as usual :-) . _many_ new targets as well Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [ANNOUNCE] uClinux-dist-20070130 release
Hi John, John Williams wrote: Is there a (good :) ) reason why uClinux-dist/Makefile clean: target now deletes the $(LINUX)/include/asm symlink? This means that after a make clean you have to make oldconfig to get the symlink back. Perhaps this should be in distclean rather than clean? It sure is annoying, I have seen the same thing. Lets ask Davidm, since he made the change :-) From the CVS commit of that change: 2.6 doesn't remove the include/asm link on clean and switching targets breaks (ie., arm to sh) Regards Greg Greg Ungerer wrote: Hi All, I have generated a uClinux-dist-20070130 release. You can get it from the usual place: http://www.uclinux.org/pub/uClinux/dist/uClinux-dist-20070130.tar.gz http://www.uclinux.org/pub/uClinux/dist/uClinux-dist-20070130.tar.bz2 The uClinux-dist CVS, at cvs.uclinux.org, has been updated as well. It contains: . linux-2.6.19-uc0 . linux-2.4.32-uc0 . linux-2.0.39-uc2 . uClibc-0.9.27 . _lots_ of other application packages (as usual :-) . _many_ new targets as well Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev -- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] PATCH cxxtest and shared stlport
Hi Matt, Matthew Natalier wrote: Dave, I finally got around to building and testing a shared stlport and cxx test. If you could apply these to the uClinux-dist cvs I would appreciate it. Will this break non-MMU builds? (Come to think of it, has this ever worked on non-MMU systems?) Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
