* Re: building Rootfs
From: Wolfgang Denk @ 2008-07-09 6:21 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-embedded
In-Reply-To: <63386a3d0807081653t5e19cae2vd35c03de4bec7fa8@mail.gmail.com>
In message <63386a3d0807081653t5e19cae2vd35c03de4bec7fa8@mail.gmail.com> you wrote:
>
> >> 3. Getting files into the filesystem when the development
> >> system does not allow root access.
>
> > 3. is a non-issue for most common file systems.
>
> The only one thing I ever ran into trouble with was device nodes,
No, this is not a problem.
> these cannot be reproduced any way, not even with fakeroot
Most tools support a "device table", i. e. a plain text file
describing needed device nodes, owners, permissions etc., so no root
permissins are needed.
For details please see
http://www.denx.de/wiki/view/DULG/RootFileSystemOnARamdisk
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Beware of the Turing Tar-pit in which everything is possible but
nothing of interest is easy.
^ permalink raw reply
* Re: building Rootfs
From: David VomLehn @ 2008-07-09 0:52 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-embedded
In-Reply-To: <63386a3d0807081653t5e19cae2vd35c03de4bec7fa8@mail.gmail.com>
Linus Walleij wrote:
> If you know some way of sneaking a device node into a
> .tar file created ENTIRELY running as a regular user,
> tell me!
We do this all the time. We have a very minimal root filesystem and aren't
currently using any of the frameworks for building root filesystems, so
everything is done with make. In general, we create tar files for each piece. The
piece that has device nodes has a make file with something like:
all:
fakeroot make fakeroot-package
fakeroot-package:
mkdir -p image
mknod image/dev/null c 1 3
mknod image/dev/random c 1 8
tar -C image -czf image.tgz .
We ran into some issues when we separated running mknod and tar into separate
fakeroot invocations because there is a bug in fakeroot with exporting and
importing its state. Fortunately, doing all of this under a single fakeroot
command works just fine. When we untar the tar files for all of the pieces to
create a root filesystem image and then run mkcramfs to create a CRAMFS image, we
do all commands under a single invocation of fakeroot.
No stage of the build requires running as root.
--
David VomLehn, dvomlehn@cisco.com
- - - - - Cisco - - - - -
This e-mail and any attachments may contain information which is confidential,
proprietary, privileged or otherwise protected by law. The information is solely
intended for the named addressee (or a person responsible for delivering it to
the addressee). If you are not the intended recipient of this message, you are
not authorized to read, print, retain, copy or disseminate this message or any
part of it. If you have received this e-mail in error, please notify the sender
immediately by return e-mail and delete it from your computer.
^ permalink raw reply
* Re: building Rootfs
From: Linus Walleij @ 2008-07-09 0:14 UTC (permalink / raw)
To: Robert Schwebel, linux-embedded
In-Reply-To: <20080707212150.GK4319@pengutronix.de>
2008/7/7 Robert Schwebel <r.schwebel@pengutronix.de>:
> On Mon, Jul 07, 2008 at 10:34:11PM +0200, Linus Walleij wrote:
>> Robert, can you brief us of how ptxdist fits together with
>> OpenEmbedded? What does these two projects actually share? Where do
>> they do similar things in parallel for example?
>
> They are both build systems for userlands, or whole embedded linux
> systems. I cannot speak for OE as I don't really know it in detail.
Anyone have experience with both? I'd really like to have them
contrasted and, well you know, cross-firtualized.
> The idea behind ptxdist is executable documentation.
I really like ptxdist, especially it is beautiful that you have
based it around just bash and make plus some crosscompiler
of choice. I just have some trouble getting it to do what
I want. I'll hopefully get there. This is not meant as any generic
complaining. I'm trying to figure out if ptxdist or openembedded
is the best starting point.
I have a situation where the build system would be on top
of some SCM like git, CVS or whatever and packages being
checked out and worked on by several people daily.
This seems to clash with ptxdist design goals,
for example:
ptxdist seems
* hardcoded to run in a users home directory
with projects in $HOME/foo (stopped me
right now, perhaps it can easily be fixed or is
already part of ptxdist 2?)
* assume only one person builds rootfs. So
it doesn't really want the project tree to be used
or modified by more than one person at the time.
(Same as first more or less.)
* not store source code, patches and config plus my
local additions in one place. For most other package
systems e.g. RPM there is
/foo/foo.spec
/foo/foo-1.0.tar.gz
/foo/foo-patch1.diff
/foo/foo-patch2.diff
/foo/my-foo-config.file
In ptxdist these seem to be spread out, some in the installation
of ptxdist itself in say /usr/lib/ptxdist/patches, /usr/lib/ptxdist/...
then in my project space $HOME/project/... etc.
I believe at archivicing time everything including ptxdist itself
is zipped up and archived on one storage media. But I need to
keep all files relating to a package in one place while developing,
and living like that for a long time. Since /usr/lib/ptxdist isn't even
being backed up normally, only NFS mounts like /home, I then
need to move the entire ptxdist into the SCM, which it clearly
doesn't like without a lot of hacking, plus, how would I
upgrade it?
OK this is a bit picky. And perhaps I can fix it all and merge
back. Just trying to decide.
Linus
^ permalink raw reply
* Re: building Rootfs
From: Linus Walleij @ 2008-07-08 23:53 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <20080708140034.B2B7424681@gemini.denx.de>
2008/7/8 Wolfgang Denk <wd@denx.de>:
>> 3. Getting files into the filesystem when the development
>> system does not allow root access.
> 3. is a non-issue for most common file systems.
The only one thing I ever ran into trouble with was device nodes,
these cannot be reproduced any way, not even with fakeroot
environments, just in scratchbox, which in turn needs you to be root.
initramfs etc can handle it with special description files. But if
you want to cook up say a .tar file of your rootfs, you're pretty
much lost AFAIK.
The good thing is that you don't need the device nodes
if you have udev, I think the kernel wants /dev/console
and a few more at boot but actually it survives just fine
without them.
The rest is possible to create with fakeroot and clever
scripting if I'm not mistaken.
If you know some way of sneaking a device node into a
.tar file created ENTIRELY running as a regular user,
tell me!
Linus
^ permalink raw reply
* Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
From: Michelle Konzack @ 2008-07-08 23:36 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <486F60F4.1050109@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]
Hallo Stefan,
Am 2008-07-05 13:54:28, schrieb Stefan Schoenleitner:
> I could still do some peripheral device driver development for the stuff I want
> to attach on the EP3902 board I already bought and do some testing as well.
> Can you suggest some specific CPU ?
>
> Of course features like LAN, USB and such are nice to have, but they are not
> required for my design.
Philips/NXP: LH7A400/10/11
00 = I²C,...
10 = Ethetnet without CAN
11 = Ethernet, CAN, I²C,...
> Goals should rather be that the CPU is cheap, easy to get and one should be able
> to solder it by hand (e.g. SMD paste and hot-air flow soldering).
> For this reason BGA packages are not possible.
No InfraRed-Welding System available?
I have goten one from eBay AOYUE 710 which cost new 2000€, but on eBay
400€ + transport.
> Is there something like good documentation on how to attach hardware to an
> embedded CPU so that the linux-kernel will work just fine with it ?
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
From: Michelle Konzack @ 2008-07-08 23:17 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <486F557D.3090209@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]
Am 2008-07-05 13:05:33, schrieb Stefan Schoenleitner:
> ----------------------------------------------------------------------------------------
> "It is not being discontinued. We just will not be supporting the OS's like
> Wince and Linux anymore. The linux part is supported mostly by this forum and
> OE, and the cirrus-linux mailing list.
>
> We will not be moving the kernel port forward from the Cirrus side, however,
> Lennert has a kernel port in the mainstream. someone could take up our patch and
> add the final set of periferals.
>
> So yes, you can still buy EP93XX and EP73XX chips. Dont worry, they aint going
> anywhere anytime soon."
> ----------------------------------------------------------------------------------------
> [http://arm.cirrus.com/forum/viewtopic.php?t=3442]
Das ist cool.. did'nt know since I have read other things.
Greetings
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
From: Michelle Konzack @ 2008-07-08 23:14 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <486F38CF.40803@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6084 bytes --]
Hallo Stefan,
Ich habe ein ähnliches project / I have a similar project.
Am 2008-07-05 11:03:11, schrieb Stefan Schoenleitner:
> Hi,
>
> for my project I would like to design an ARM9 based single board computer (SBC)
> using the cirrus logic EP9302 CPU:
>
> http://www.cirrus.com/en/pubs/proDatasheet/EP9302_PP3.pdf
> http://www.cirrus.com/en/pubs/manual/EP93xx_Users_Guide_UM1.pdf
Simpy forget it... discontinued.
Cirrus does not recommend it for new designs.
Maybe you schould go with a Freescale. (Me too)
> For this reason I'm looking for the best way to hook up peripheral hardware to
> the CPU so that the linux kernel can handle it.
Hehe me too
> Among other features the CPU has a SPI bus and a total of 27 GPIO pins.
> Using bit-banging on some of the available GPIO pins the CPU can also do I2C
> communication.
> (AFAIK bit-banging I2C on GPIO pins is already suppored by the linux kernel.)
I have tested bit-banging on a LH7A411 bit it eat up CPU time as the
hell. I have attached an I²C-Master which do the stuff... 3.48€ and
the problem is history...
> 1) directly connect it to the CPU's GPIO pins
This would be the fastestes method.
> 2) connect it to the CPU's GPIO pins in a multiplexed way using a bus
> switch
> 3) hook it up to some existing serial bus (SPI or I2C)
Bluetooth over I2C? - Good luck.
> 4) hook it up to some existing _external_ serial bus (USB, UART)
I am using for some devices the USB port on the CPU and connected a 7
port USB2.0 hub to it... Not the best solution, but it works perfectly.
and of course, the the whole USB-Tree is Linux-Supported. No need to
reinvent the weel
> 4) hook it up to some existing _external_ serial bus (USB, UART)
>
> The single board computer should have external connections to the "outside world".
> One serial port should be used as serial console while the other one will be
> used for something else.
> The USB connectors should be usable to connect arbitrary devices which are
> supported by the linux kernel (e.g. external harddisk, webcam, whatever ...).
> Also, usually peripheral hardware chips do not support USB.
> For this reason this approach will not be taken for peripheral hardware access.
How many USB Hosts does the Chip has exactly?
Maybe you could do the same as me with a 7-port USB 2.0 hub.
One of my Meto-Stations need MANY USB-Ports so I have connected a 4-port
hub to the LH7A411 and on the 4 ports of the 4-port hub again 4 USB Hubs
with 7 ports...
Now my Meto-Station has 28 USB ports availlable, supporting (in theorie)
version 2.0... I have not found a solution less expensive as this one.
Now I can connect ANY hardware, like Bluetooth, WiFi, IR or what else to
it
> 5) connect it to GPIO pins of a linux-supported GPIO expander that can be
> accessed over I2C
>
> This is IMHO a very promising approach which also has been taken in various
> other (linux-compatible) designs I found on the internet
> (e.g. the "DaVinci prototyping board",
> http://www.linuxdevices.com/news/NS2209350555.html).
>
> The idea is to connect a GPIO expander to the CPU's I2C bus which provides a
> number (i.e. 8, 16, ..) of freely usable GPIO pins.
I have gotten some differenttypes from Philips/NXP, but currently I have
not found support in the Kernel except one (since 6 weeks?).
AFAIK there are some peoples working on it.
> These GPIO pins are then connected to the peripheral hardware.
> The linux kernel already has support for various GPIO expanders like the PCA9539
> (16 port) or the PCF8574 (8 port) chips.
This is the one I am currently using... and it works very nice.
> As far as I read in the kernel documentation, the drivers transparently map
> those GPIO pins to the GPIO interface of the linux kernel.
> Thus, from a device driver perspective, it makes no difference whether a device
> is connected to the CPU's "real" GPIO pins or to a GPIO expander chip which can
> be accessed over thr I2C bus.
Right.
> Another advantage is the simple circuit design: Instead of having to route a
> complete parallel bus over the PCB, only the serial I2C bus has to be routed
> from the CPU to the port expander.
Be careful with the speed of the I²C bus. If you use bit-banging, you
can run into trouble. bit-banging is realy only for very-cheep hardware
where you not realy care about timings...
> As we saw, from a software perspective, it doesn't seem to make a big difference
> whether peripheral hardware is directly hooked up to the CPU's GPIO pins or
> it is hooked up to GPIO expanders.
This is a good question. Since I am beginning to go into this business
(studied electronic for more then 13 years and was working only french
@army and have no experience in it) your questions fit 100% my own
questions
> * However, if we look at existing device drivers, will it be possible to use
> them with this setup without modification ?
>
> * How will the kernel find devices attached to GPIO pins ?
> (There's no way to scan the bus since the kernel doesn't know what and where
> devices are attached to the GPIO pins, right ?)
This is what I am asking me too...
I have tried to read the Kernel-Sources but... HELL!!!
I am not a Kernel-Geek!
> * What would be the best way to attach peripheral hardware from a linux-kernel
> perspective ?
USB ;-)
> * Can you suggest any embedded hardware design documentation that considers
> linux compatibility ?
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: building Rootfs
From: Wolfgang Denk @ 2008-07-08 14:00 UTC (permalink / raw)
To: Haller, John H (John); +Cc: Linus Walleij, linux-embedded
In-Reply-To: <B78930B8E34A824993912C39C24569E60141D874@ILEXC3U01.ndc.lucent.com>
In message <B78930B8E34A824993912C39C24569E60141D874@ILEXC3U01.ndc.lucent.com> you wrote:
>
> There are three issues in building an embedded cross-filesystem:
> 1. Identification of the files to put into the filesystem.
> 2. Stripping or extracting debug symbols from the filesystem.
> 3. Getting files into the filesystem when the development
> system does not allow root access.
3. is a non-issue for most common file systems.
> The third item is easy for an initramfs, but not well handled
> by existing tools for an initrd (although I haven't looked
> recently). One possibility is to modify a mkfs program, such
genext2fs has been around for a long, long time.
And there are similar tools for other file system types like cramfs
or jffs2 ...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The human race is a race of cowards; and I am not only marching in
that procession but carrying a banner. - Mark Twain
^ permalink raw reply
* Re: building Rootfs
From: Robert Schwebel @ 2008-07-08 6:54 UTC (permalink / raw)
To: Haller, John H (John); +Cc: Linus Walleij, linux-embedded
In-Reply-To: <B78930B8E34A824993912C39C24569E60141D874@ILEXC3U01.ndc.lucent.com>
On Mon, Jul 07, 2008 at 06:24:48PM -0500, Haller, John H (John) wrote:
> There are three issues in building an embedded cross-filesystem:
> 1. Identification of the files to put into the filesystem.
> 2. Stripping or extracting debug symbols from the filesystem.
> 3. Getting files into the filesystem when the development
> system does not allow root access.
Ack. In PTXdist, we also cover
4. what to put into the initial image on deployment (we had what you
describe in 3 above but split that up into "what to build" vs. "what
to install" in ptxdist-2.x).
5. how to push the image into the device (managing and writing
complicated u-boot environments and pushing it into the device
automatically, via serial+ethernet)
6. automatic test suites against embedded targets
> The first item is made a little easier by RPM, as it groups files
> together into packages, and package dependencies are quite often
> properly declared. However, packages sometimes have dependencies on
> another package when only part of the package may be required. Another
> problem is with documentation files (usually unwanted on an embedded
> system), and locales which are huge and generally unwanted.
That was the reason why we went with ipkg; the meta data of rpm and deb
are too large to be hold on an embedded system, but we want software
updatability. However, if someone needs any sort of Carrier Grade
Blubberblabber, we could easily add rpm and/or deb :-)
> The second item can be tricky, as one doesn't want to strip debug
> symbols every time a filesystem is built, but the debug symbols are
> generally needed for cross debugging.
Yup; ptxdist solves this by having root/ and root-debug/, where the
first one can be booted via NFS or flash, and the second one contains
all the debug symbols. Cross debugging works that way, even with Eclipse
(for the people who deny seeing the pure elegance and shinyness of vim
and commandline gdb).
> The third item is easy for an initramfs, but not well handled by
> existing tools for an initrd (although I haven't looked recently). One
> possibility is to modify a mkfs program, such as mke2fs, for the
> filesystem of choice to accept proto files, like the traditional Unix
> mkfs does. [Google mkfs proto for some examples]. I'm not sure if
> ptxdist supports both initramfs and initrd. If you do have root
> access, this is all much simpler, as an initrd can be locally mounted
> and populated.
I'm not sure as well; the parts for initramfs are there, but we don't
use it here at Pengutronix, because all of our current customer systems
have normal flash root filesystems; we once had a system with IXP425
that needed a userspace firmware for nfsroot, but that's the only case I
can remember.
However, if somebody needs improvement, he is free to send patches...
> One other item that pops up sometimes is post-install scripts
> that are associated with some packages. These scripts run in
> the target filesystem, and there is no good way to run them
> in the host environment.
This is already solved :-) We have pre/post scripts, this way:
rules/foobar.make
rules/foobar.preinst
rules/foobar.postinst
...
In the scripts you can check if DESTDIR is set; if yes, you are in the
host environment (development system tries to build a root fs from the
ipkgs); if not, you are on the target (something does 'ipkg install').
With that mechanics, you can for example decide that on the target you
need to stop a service first, then update, then start it again.
Everything but update isn't required if only an image is being made.
> This doesn't happen too often, so it can usually be handled by hand as
> an exception. One example of this type of item is installing the
> symbolic links in the right place for init scripts.
Yup, that can be done with the mechanics above.
> Using the tools from an embedded vendor has two problems -
> they can change from release to release,
We have a stable ptxdist-1.x series with long term bugfix maintenance
for that ... even this stable series is completely open source, for
everyone's download pleasure.
> and they are proprietary tools that lock you into the vendor.
No need to do so. Everything in ptxdist is GPL. If somebody wants to be
locked to Pengutronix, we feel better if he does so because he has the
warm and cuddly feeling that we solve his problems best ... which, by
the way, doesn't work too bad.
> But, they may provide a GUI, if you are into graphical presentations.
Well, if someone absolutely needs a GUI, he can use gvim¹ :-)
rsc
¹ Or even Eclipse & vmware, if your software department has a better
feeling while using buzzword technology.
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* RE: building Rootfs
From: Haller, John H (John) @ 2008-07-07 23:24 UTC (permalink / raw)
To: Linus Walleij, linux-embedded
In-Reply-To: <63386a3d0807071334q2242ac45x540cee2a3fcb231b@mail.gmail.com>
>
> What else is there out there for rootfs, really? A hack
> from every embedded company there is? I'm more after
> what people actually *use* and what is community driven
> here, not so much opinions on what is best (which will
> probably be the unwanted side effect of this mail
> anyway...)
>
> Linus
There are three issues in building an embedded cross-filesystem:
1. Identification of the files to put into the filesystem.
2. Stripping or extracting debug symbols from the filesystem.
3. Getting files into the filesystem when the development
system does not allow root access.
The first item is made a little easier by RPM, as it groups
files together into packages, and package dependencies are
quite often properly declared. However, packages sometimes
have dependencies on another package when only part of the
package may be required. Another problem is with documentation
files (usually unwanted on an embedded system), and locales
which are huge and generally unwanted.
The second item can be tricky, as one doesn't want to
strip debug symbols every time a filesystem is built, but
the debug symbols are generally needed for cross debugging.
debugedit from the RPM package does a nice job of this,
separating the debug symbols from the executable, but
it is best to do this when an cross executable is installed
on the host system, rather than at filesystem build time.
The third item is easy for an initramfs, but not well handled
by existing tools for an initrd (although I haven't looked
recently). One possibility is to modify a mkfs program, such
as mke2fs, for the filesystem of choice to accept proto
files, like the traditional Unix mkfs does. [Google mkfs proto
for some examples]. I'm not sure if ptxdist supports both
initramfs and initrd. If you do have root access, this is
all much simpler, as an initrd can be locally mounted
and populated.
One other item that pops up sometimes is post-install scripts
that are associated with some packages. These scripts run in
the target filesystem, and there is no good way to run them
in the host environment. This doesn't happen too often, so
it can usually be handled by hand as an exception. One example
of this type of item is installing the symbolic links in the
right place for init scripts. Another option would be to
capture the scripts and run them during boot, but this would
slow boot times.
Using the tools from an embedded vendor has two problems -
they can change from release to release, and they are proprietary
tools that lock you into the vendor. But, they may provide
a GUI, if you are into graphical presentations.
John Haller
^ permalink raw reply
* Re: building Rootfs
From: Robert Schwebel @ 2008-07-07 21:21 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-embedded, r.schwebel
In-Reply-To: <63386a3d0807071334q2242ac45x540cee2a3fcb231b@mail.gmail.com>
On Mon, Jul 07, 2008 at 10:34:11PM +0200, Linus Walleij wrote:
> Robert, can you brief us of how ptxdist fits together with
> OpenEmbedded? What does these two projects actually share? Where do
> they do similar things in parallel for example?
They are both build systems for userlands, or whole embedded linux
systems. I cannot speak for OE as I don't really know it in detail.
The idea behind ptxdist is executable documentation. If you use Open
Source software for business critical industrial applications, having
control over the source is an important thing. So our customers are
usually able to reproduce their root filesystems with one "ptxdist go"
directly from the sources. Our design criteria are
- things are highly configurable
- you have to find out what was done why
- going the mainline way where ever possible
- use proven technology (ptxdist is written in bash & gnu make)
> I'm trying - real hard - to get an idea of how people out there prefer
> to build their root filesystems in cross-compiled environments.
Well, I still havn't seen a real argument against it. At least not for
our usecases.
> Rob Landley recently wrote up a small blurb on why native
> compilation is the way to go, and a small roadmap on how
> he intended to get there using e.g. Qemu and Firmware Linux,
> c.f: http://www.landley.net/code/firmware/about.html
> which finally won me over to that line of thinking.
> Debian and friends obviously go this way now.
Cool, so what do we do for platforms like Blackfin, or any of the random
ARM processors out there, write qemu support first? Sorry, you cannot
really suggest this. Not with Qemu being in such a crude state that it
can not even be built with modern compilers.
Being able to be cross compiled is actually a *feature* of unix
software, be it autotoolized or not. And, in reality, the problems which
usually come up in these 'build native' discussions are very often
academic.
> However, when it comes to the widespread and much fragmented ways of
> cross-compiling a rootfs, including the stuff put together by
> MontaVista, WR and all those animals in the forest, obviously based on
> RPM (build systems I haven't put my hands inside, since they are
> proprietary) there seems to be very little consensus.
Well, the consensus is usually configure && make && make install. If
people just wouldn't assume that they know it better than autotools ...
But don't let us start a flamewar in this direction here. It doesn't
bring us anywhere.
> ptxdist stands out but do you get a lot of outside contributions for
> it? As it looks it seems you're running it yourself. (Beware: I
> haven't looked close.)
Oh, we have quite a bunch of contributions from the outside, and almost
200 people on the mailing list. It goes up and down, there are times
where we get more contributions from the customers, then from the
community, but in general it works really good.
Note that it is a tool to solve *our* problems (which consist of making
reproducable embedded linux systems for our customers, while being able
to fix problems as they arise). And it solves them very, very well.
> What else is there out there for rootfs, really? A hack from every
> embedded company there is?
PTXdist doesn't invent something new, it just exercises the usual
configure && make && make install canon, in a reproducable way. Nothing
more and nothing less. It is completely open, being GPL, so you can
freely choose if you accept realizing it being on the way to world
domination or not :-)
It's not even focussed on building root filesystems. We also use it to
build cross compilers and well defined Eclipse installations.
> I'm more after what people actually *use* and what is community driven
> here, not so much opinions on what is best (which will probably be the
> unwanted side effect of this mail anyway...)
PTXdist is in use and community driven, so it migth be worth a look :-)
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: building Rootfs
From: Linus Walleij @ 2008-07-07 20:34 UTC (permalink / raw)
To: linux-embedded, r.schwebel
In-Reply-To: <20080707181018.GG4319@pengutronix.de>
OK Robert wrote this on ARM-Linux mailinglist but the discussion
belongs on linux-embedded, so I'm moving it there, the suggested
ptxdist ML seems inapropriate for the entire embedded
community.
2008/7/7 Robert Schwebel <r.schwebel@pengutronix.de>:
> On Mon, Jul 07, 2008 at 06:01:51PM +0800, Eric Miao wrote:
>> or start from buildroot, scratchbox and openembedded as a tool, you've
>> really got a lot to learn :-)
>
> Or ptxdist, or course :-)
Robert, can you brief us of how ptxdist fits together with
OpenEmbedded? What does these two projects actually
share? Where do they do similar things in parallel for
example?
I'm trying - real hard - to get an idea of how people out
there prefer to build their root filesystems in cross-compiled
environments.
Rob Landley recently wrote up a small blurb on why native
compilation is the way to go, and a small roadmap on how
he intended to get there using e.g. Qemu and Firmware Linux,
c.f: http://www.landley.net/code/firmware/about.html
which finally won me over to that line of thinking.
Debian and friends obviously go this way now.
However, when it comes to the widespread and much
fragmented ways of cross-compiling a rootfs, including the
stuff put together by MontaVista, WR and all those animals
in the forest, obviously based on RPM (build systems I
haven't put my hands inside, since they are proprietary)
there seems to be very little consensus. ptxdist stands out
but do you get a lot of outside contributions for it? As it
looks it seems you're running it yourself. (Beware: I
haven't looked close.)
What else is there out there for rootfs, really? A hack
from every embedded company there is? I'm more after
what people actually *use* and what is community driven
here, not so much opinions on what is best (which will
probably be the unwanted side effect of this mail
anyway...)
Linus
^ permalink raw reply
* Re: Atmel AT91SAM7S and AT91SAM7A3
From: Richard Genoud @ 2008-07-07 6:45 UTC (permalink / raw)
To: Michelle Konzack; +Cc: Embedded
In-Reply-To: <20080629023721.GI12731@freenet.de>
> I realy do not know, how to begin this stuff...
you may have more answers on the linux-arm-kernel
http://www.arm.linux.org.uk/mailinglists/lists.php
^ permalink raw reply
* Re: Incompatible CFLAGS for kernel module
From: Sam Ravnborg @ 2008-07-06 20:00 UTC (permalink / raw)
To: Shaz
Cc: linux-embedded, ray.sunjae.lee, tpm-emulator-user,
tpm-emulator-devel, Security Engineering Archive
In-Reply-To: <7b740b700807060035y66bdc54byc8a5ad87b6e3d50d@mail.gmail.com>
> >>> >> this case. Following is the error:
> >>> >>
> >>> >> [root@develbox tpm_emulator-0.5]# make
> >>> >> Making all in tpmd
> >>> >> make[1]: Entering directory `/embedded/tpm_emulator-0.5/tpmd'
> >>> >> make[1]: Nothing to be done for `all'.
> >>> >> make[1]: Leaving directory `/embedded/tpm_emulator-0.5/tpmd'
> >>> >> Making all in tpmd_dev
> >>> >> make[1]: Entering directory `/embedded/tpm_emulator-0.5/tpmd_dev'
> >>> >> CC [M] /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.o
> >>> >> cc1: error: unrecognized command line option "-mlittle-endian"
> >>> >> cc1: error: unrecognized command line option "-mapcs"
> >>> >> cc1: error: unrecognized command line option "-mno-sched-prolog"
> >>> >> cc1: error: unrecognized command line option "-mabi=aapcs-linux"
> >>> >> cc1: error: unrecognized command line option "-mno-thumb-interwork"
This all looks like you are using the wrong gcc.
And the "make V=1" option should tell you that.
> I've noticed some issues in my rootfs and on to it but plz do look at
> the Makefile. i might be missing something there instead.
The Makefile looks ok.
Sam
^ permalink raw reply
* Re: [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
From: James Bottomley @ 2008-07-06 16:19 UTC (permalink / raw)
To: Denys Vlasenko
Cc: linux-arch, Russell King, David Howells, Ralf Baechle,
Lennert Buytenhek, Josh Boyer, Paul Mackerras, David Woodhouse,
Andi Kleen, torvalds, akpm, Paul Gortmaker, linux-embedded,
linux-kernel, Tim Bird, Martin Schwidefsky, Dave Miller
In-Reply-To: <200807061746.02517.vda.linux@googlemail.com>
On Sun, 2008-07-06 at 17:46 +0200, Denys Vlasenko wrote:
> The purpose of this patch is to make kernel buildable
> with "gcc -ffunction-sections -fdata-sections".
> This patch fixes parisc architecture.
>
> Updated version - does not try to rename sections
> which really are expected to be produced by gcc - .text.sys_exit etc.
Actually, I've thought about it some more and I don't think your
approach is quite right. The way gcc works with -ffunction-sections
makes it clear that it expects the section namespace to be scoped left
to right. However, by using *.text and *.data, your patch is following a
reverse convention (putting your most global name to the right). This
is setting us up for a clash with future global section names that our
toolchain might emit in future.
Since we have to have special handling for your reversed sections in
every vmlinux.lds, what about introducing our own namespace instead? So
we reserve the global section specifier linux and then make everything a
namespace under this. So our constructed text and data sections become
linux.text.*
and
linux.data.*
That way we could only ever get a clash if the toolchain decided to use
a section global name linux (which we can beat them up over).
James
^ permalink raw reply
* Re: [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
From: Denys Vlasenko @ 2008-07-06 15:46 UTC (permalink / raw)
To: linux-arch, James Bottomley
Cc: Russell King, David Howells, Ralf Baechle, Lennert Buytenhek,
Josh Boyer, Paul Mackerras, David Woodhouse, Andi Kleen, torvalds,
akpm, Paul Gortmaker, linux-embedded, linux-kernel, Tim Bird,
Martin Schwidefsky, Dave Miller
In-Reply-To: <200807020239.11410.vda.linux@googlemail.com>
The purpose of this patch is to make kernel buildable
with "gcc -ffunction-sections -fdata-sections".
This patch fixes parisc architecture.
Updated version - does not try to rename sections
which really are expected to be produced by gcc - .text.sys_exit etc.
James please ACK/NAK.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
--
vda
--- 0.org/arch/parisc/kernel/head.S Wed Jul 2 00:40:41 2008
+++ 1.fixname/arch/parisc/kernel/head.S Wed Jul 2 00:45:45 2008
@@ -345,7 +345,7 @@
ENDPROC(stext)
#ifndef CONFIG_64BIT
- .section .data.read_mostly
+ .section .read_mostly.data
.align 4
.export $global$,data
--- 0.org/arch/parisc/kernel/init_task.c Wed Jul 2 00:40:41 2008
+++ 1.fixname/arch/parisc/kernel/init_task.c Wed Jul 2 00:46:55 2008
@@ -49,7 +49,7 @@
* "init_task" linker map entry..
*/
union thread_union init_thread_union
- __attribute__((aligned(128))) __attribute__((__section__(".data.init_task"))) =
+ __attribute__((aligned(128))) __attribute__((__section__(".init_task.data"))) =
{ INIT_THREAD_INFO(init_task) };
#if PT_NLEVELS == 3
@@ -58,11 +58,11 @@
* guarantee that global objects will be laid out in memory in the same order
* as the order of declaration, so put these in different sections and use
* the linker script to order them. */
-pmd_t pmd0[PTRS_PER_PMD] __attribute__ ((__section__ (".data.vm0.pmd"), aligned(PAGE_SIZE)));
+pmd_t pmd0[PTRS_PER_PMD] __attribute__ ((__section__ (".vm0.pmd.data"), aligned(PAGE_SIZE)));
#endif
-pgd_t swapper_pg_dir[PTRS_PER_PGD] __attribute__ ((__section__ (".data.vm0.pgd"), aligned(PAGE_SIZE)));
-pte_t pg0[PT_INITIAL * PTRS_PER_PTE] __attribute__ ((__section__ (".data.vm0.pte"), aligned(PAGE_SIZE)));
+pgd_t swapper_pg_dir[PTRS_PER_PGD] __attribute__ ((__section__ (".vm0.pgd.data"), aligned(PAGE_SIZE)));
+pte_t pg0[PT_INITIAL * PTRS_PER_PTE] __attribute__ ((__section__ (".vm0.pte.data"), aligned(PAGE_SIZE)));
/*
* Initial task structure.
--- 0.org/arch/parisc/kernel/vmlinux.lds.S Wed Jul 2 00:40:41 2008
+++ 1.fixname/arch/parisc/kernel/vmlinux.lds.S Wed Jul 2 01:02:35 2008
@@ -95,8 +95,8 @@
/* rarely changed data like cpu maps */
. = ALIGN(16);
- .data.read_mostly : {
- *(.data.read_mostly)
+ .read_mostly.data : {
+ *(.read_mostly.data)
}
. = ALIGN(L1_CACHE_BYTES);
@@ -107,14 +107,14 @@
}
. = ALIGN(L1_CACHE_BYTES);
- .data.cacheline_aligned : {
- *(.data.cacheline_aligned)
+ .cacheline_aligned.data : {
+ *(.cacheline_aligned.data)
}
/* PA-RISC locks requires 16-byte alignment */
. = ALIGN(16);
- .data.lock_aligned : {
- *(.data.lock_aligned)
+ .lock_aligned.data : {
+ *(.lock_aligned.data)
}
/* nosave data is really only used for software suspend...it's here
@@ -123,7 +123,7 @@
. = ALIGN(PAGE_SIZE);
__nosave_begin = .;
.data_nosave : {
- *(.data.nosave)
+ *(.nosave.data)
}
. = ALIGN(PAGE_SIZE);
__nosave_end = .;
@@ -135,10 +135,10 @@
__bss_start = .;
/* page table entries need to be PAGE_SIZE aligned */
. = ALIGN(PAGE_SIZE);
- .data.vmpages : {
- *(.data.vm0.pmd)
- *(.data.vm0.pgd)
- *(.data.vm0.pte)
+ .data.vmpages : { /* TODO: rename .vmpages.data? */
+ *(.vm0.pmd.data)
+ *(.vm0.pgd.data)
+ *(.vm0.pte.data)
}
.bss : {
*(.bss)
@@ -150,8 +150,8 @@
/* assembler code expects init_task to be 16k aligned */
. = ALIGN(16384);
/* init_task */
- .data.init_task : {
- *(.data.init_task)
+ .init_task.data : {
+ *(.init_task.data)
}
#ifdef CONFIG_64BIT
--- 0.org/include/asm-parisc/cache.h Wed Jul 2 00:40:50 2008
+++ 1.fixname/include/asm-parisc/cache.h Wed Jul 2 00:45:45 2008
@@ -28,7 +28,7 @@
#define SMP_CACHE_BYTES L1_CACHE_BYTES
-#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+#define __read_mostly __attribute__((__section__(".read_mostly.data")))
void parisc_cache_init(void); /* initializes cache-flushing */
void disable_sr_hashing_asm(int); /* low level support for above */
--- 0.org/include/asm-parisc/system.h Wed Jul 2 00:40:50 2008
+++ 1.fixname/include/asm-parisc/system.h Wed Jul 2 00:46:14 2008
@@ -174,7 +174,7 @@
})
#ifdef CONFIG_SMP
-# define __lock_aligned __attribute__((__section__(".data.lock_aligned")))
+# define __lock_aligned __attribute__((__section__(".lock_aligned.data")))
#endif
#define arch_align_stack(x) (x)
^ permalink raw reply
* Re: Incompatible CFLAGS for kernel module
From: Shaz @ 2008-07-06 7:35 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-embedded, ray.sunjae.lee, tpm-emulator-user,
tpm-emulator-devel, Security Engineering Archive
In-Reply-To: <7b740b700807052234p49a50c22g290d9a76e04d373f@mail.gmail.com>
On Sun, Jul 6, 2008 at 10:34 AM, Shaz <shazalive@gmail.com> wrote:
> On Sat, Jul 5, 2008 at 11:33 AM, Sam Ravnborg <sam@ravnborg.org> wrote:
>> On Sat, Jul 05, 2008 at 10:33:28AM +0500, Shaz wrote:
>>> On Sat, Jul 5, 2008 at 1:32 AM, Sam Ravnborg <sam@ravnborg.org> wrote:
>>> > On Fri, Jul 04, 2008 at 10:34:56PM +0500, Shaz wrote:
>>> >> Hi,
>>> >>
>>> >> I am porting tpm emulator to versatilepb, which is an arm platform. I
>>> >> have some problem with CFLAGS from /arch/arm/Makefile when building
>>> >> the kernel module for this software. I cannot figure out what to do in
>>> >> this case. Following is the error:
>>> >>
>>> >> [root@develbox tpm_emulator-0.5]# make
>>> >> Making all in tpmd
>>> >> make[1]: Entering directory `/embedded/tpm_emulator-0.5/tpmd'
>>> >> make[1]: Nothing to be done for `all'.
>>> >> make[1]: Leaving directory `/embedded/tpm_emulator-0.5/tpmd'
>>> >> Making all in tpmd_dev
>>> >> make[1]: Entering directory `/embedded/tpm_emulator-0.5/tpmd_dev'
>>> >> CC [M] /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.o
>>> >> cc1: error: unrecognized command line option "-mlittle-endian"
>>> >> cc1: error: unrecognized command line option "-mapcs"
>>> >> cc1: error: unrecognized command line option "-mno-sched-prolog"
>>> >> cc1: error: unrecognized command line option "-mabi=aapcs-linux"
>>> >> cc1: error: unrecognized command line option "-mno-thumb-interwork"
>>> >> /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.c:1: error: bad value
>>> >> (armv4t) for -march= switch
>>> >> /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.c:1: error: bad value
>>> >> (arm9tdmi) for -mtune= switch
>>> >> make[3]: *** [/embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.o] Error 1
>>> >> make[2]: *** [_module_/embedded/tpm_emulator-0.5/tpmd_dev] Error 2
>>> >> make[1]: *** [all] Error 2
>>> >> make[1]: Leaving directory `/embedded/tpm_emulator-0.5/tpmd_dev'
>>> >> make: *** [all-recursive] Error 255
>>> >>
>>> >> kindly help me understand the core issue here and point out some solutions.
>>> >
>>> > A quick guess is that you use your host gcc and not your target gcc.
>>> > You most likely have to set CROSS_COMPILE=...
>>> >
>>> > Try with "make V=1" to see the exact gcc command line.
>>> >
>>> > If you continue to rn into trouble please post your Makefile.
>>> I tried make V=1 but the loads of info was given for the things that
>>> went right but nothing noticeable where the error is.
>> What is interesting is the gcc commandline for a good case and
>> a bad case. If they do not look the same we are on the right track.
I've noticed some issues in my rootfs and on to it but plz do look at
the Makefile. i might be missing something there instead.
>>
>>> I've attached my arch/arm/Makefile. My build, host and target are on
>>> same system. i am emulating the board with Qemu. The process is very
>>> conventional. I've mounted my rootfs with -o loop and kernel and extra
>>> modules go there with INSTALL_MOD_PATH and INSTALL_MOD_DIR. ARCH=arm
>>> and CROSS_COMPILE=arm-linux-
>>
>> But you do some kind of "external module" build judging from the output
>> above. So the Makefile of interest is the one(s) that is special for
>> your module. At lest the one you have in /embedded/tpm_emulator-0.5/tpmd_dev
> Yes am building tpm emulator. Its nature is generic but successfully
> runs on PC and might have some porting issues which I am figuring out.
> Thanx for sufficient attention. I am attaching the emulator's source
> archive which I've altered. The main change that I've done is add
> PREFIXDIR in all Makefiles. It includes the required Makefile in
> tpmd_dev. I am separately also attaching the required makefile so to
> make it easier.
>>
>> Sam
>>
>
>
>
> --
> Shaz
>
--
Shaz
^ permalink raw reply
* Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
From: Stefan Schoenleitner @ 2008-07-05 12:48 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linux-embedded
In-Reply-To: <20080705113255.GO4319@pengutronix.de>
Robert Schwebel wrote:
>
> If you want to have something which has good community support, check
> what the mainline Linux kernel supports and base your stuff on that.
What do you think of this board ?
http://www.olimex.com/dev/sam9-L9260.html
The CPU seems to have good linux support.
^ permalink raw reply
* Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
From: Stefan Schoenleitner @ 2008-07-05 11:54 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linux-embedded
In-Reply-To: <20080705113255.GO4319@pengutronix.de>
Robert Schwebel wrote:
> Has it been different in the past? Last time we had an EP93 project (has
> been some time ago), the support for Maverick Crunch was horrible and
> cirrus' effort to support Linux mainline was almost 0.
>
> If you want to have something which has good community support, check
> what the mainline Linux kernel supports and base your stuff on that.
>
> rsc
Sounds good to me.
I could still do some peripheral device driver development for the stuff I want
to attach on the EP3902 board I already bought and do some testing as well.
Can you suggest some specific CPU ?
Of course features like LAN, USB and such are nice to have, but they are not
required for my design.
Goals should rather be that the CPU is cheap, easy to get and one should be able
to solder it by hand (e.g. SMD paste and hot-air flow soldering).
For this reason BGA packages are not possible.
Anyway, back to my original question ?
What is the best way to attach peripheral hardware so that existing drivers in
the linux-kernel can be used without having to do a lot of patching ?
It would be great if one could just use I2C expanders to interface low-speed
devices and the device drivers will just work once they know where to find the
hardware.
One of the chips I want to talk to is a voice codec with
data-rates < 15kbytes/sec.
Due to the low data-rate this should work with I2C port expanders.
The other possibility would be to use a multiplexed parallel bus using bus-switches.
How would you hook up such hardware to the CPU ?
What can you suggest ?
Is there something like good documentation on how to attach hardware to an
embedded CPU so that the linux-kernel will work just fine with it ?
stefan
^ permalink raw reply
* Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
From: Robert Schwebel @ 2008-07-05 11:32 UTC (permalink / raw)
To: Stefan Schoenleitner; +Cc: linux-embedded
In-Reply-To: <486F557D.3090209@gmail.com>
On Sat, Jul 05, 2008 at 01:05:33PM +0200, Stefan Schoenleitner wrote:
> Where did you get your information from ?
Thought I had read something like that, but if they say so ...
> To quote one of the cirrus guys:
> ----------------------------------------------------------------------------------------
> "It is not being discontinued. We just will not be supporting the OS's
> like Wince and Linux anymore. The linux part is supported mostly by
> this forum and OE, and the cirrus-linux mailing list.
Has it been different in the past? Last time we had an EP93 project (has
been some time ago), the support for Maverick Crunch was horrible and
cirrus' effort to support Linux mainline was almost 0.
If you want to have something which has good community support, check
what the mainline Linux kernel supports and base your stuff on that.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
From: Stefan Schoenleitner @ 2008-07-05 11:05 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linux-embedded
In-Reply-To: <20080705103509.GN4319@pengutronix.de>
Robert Schwebel wrote:
> As far as I know, Cirrus has discontinued the EP93 processors. I
> wouldn't base a new design on it any more.
>
> rsc
Where did you get your information from ?
As far as I know cirrus discontinued direct software support for the ARM line in
favour of third party software.
(It seems that they even had their own linux distribution which is now
discontinued.)
The chips are still produced and even new product lines seem to be released.
To quote one of the cirrus guys:
----------------------------------------------------------------------------------------
"It is not being discontinued. We just will not be supporting the OS's like
Wince and Linux anymore. The linux part is supported mostly by this forum and
OE, and the cirrus-linux mailing list.
We will not be moving the kernel port forward from the Cirrus side, however,
Lennert has a kernel port in the mainstream. someone could take up our patch and
add the final set of periferals.
So yes, you can still buy EP93XX and EP73XX chips. Dont worry, they aint going
anywhere anytime soon."
----------------------------------------------------------------------------------------
[http://arm.cirrus.com/forum/viewtopic.php?t=3442]
Currently I bought a EP9302 evaluation board from olimex
(http://www.olimex.com/dev/cs-e930x.html).
Since I havn't started designing the prototype yet, moving to another CPU won't
be much of a problem.
stefan
^ permalink raw reply
* Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
From: Robert Schwebel @ 2008-07-05 10:35 UTC (permalink / raw)
To: Stefan Schoenleitner; +Cc: linux-embedded
In-Reply-To: <486F38CF.40803@gmail.com>
On Sat, Jul 05, 2008 at 11:03:11AM +0200, Stefan Schoenleitner wrote:
> for my project I would like to design an ARM9 based single board
> computer (SBC) using the cirrus logic EP9302 CPU:
As far as I know, Cirrus has discontinued the EP93 processors. I
wouldn't base a new design on it any more.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
From: Stefan Schoenleitner @ 2008-07-05 9:03 UTC (permalink / raw)
To: linux-embedded
Hi,
for my project I would like to design an ARM9 based single board computer (SBC)
using the cirrus logic EP9302 CPU:
http://www.cirrus.com/en/pubs/proDatasheet/EP9302_PP3.pdf
http://www.cirrus.com/en/pubs/manual/EP93xx_Users_Guide_UM1.pdf
My goal is to use existing linux drivers together with attached peripheral
hardware without having to patch the driver code.
For this reason I'm looking for the best way to hook up peripheral hardware to
the CPU so that the linux kernel can handle it.
Among other features the CPU has a SPI bus and a total of 27 GPIO pins.
Using bit-banging on some of the available GPIO pins the CPU can also do I2C
communication.
(AFAIK bit-banging I2C on GPIO pins is already suppored by the linux kernel.)
Peripheral hardware (e.g. some linux-supported bluetooth chipset) can be hooked
up to the CPU in the following ways:
1) directly connect it to the CPU's GPIO pins
2) connect it to the CPU's GPIO pins in a multiplexed way using a bus
switch
3) hook it up to some existing serial bus (SPI or I2C)
4) hook it up to some existing _external_ serial bus (USB, UART)
5) connect it to GPIO pins of a linux-supported GPIO expander that can
be accessed over I2C
Now I would like to review the mentioned approaches:
1) directly connect it to the CPU's GPIO pins:
The CPU has 18 standard GPIO pins (usable for I/O) and 19 enhanched GPIO pins
which also have interrupt support.
Obviously, I do not wan't to use all of the available GPIO pins for peripheral
hardware.
Also, if we consider chipset configuration pins, the number of available CPU
GPIO pins would not suffice.
For this reason, IMHO a direct connection of peripheral hardware to the CPU's
GPIO pins is not a reasonable design decision.
2) connect it to the CPU's GPIO pins in a multiplexed way using a bus switch
This approach is similar to 1) except for the difference that the CPUs GPIO pins
are multiplexed using a bus switch.
Thus different peripheral chipsets could be accessed in the following way:
1. address the according bus switch so that the CPU's required GPIO are
routed through to the chip we want to talk to
2. communicate with the chip
Again to save GPIO pins, the various bus switches could be addressed over a
serial bus like I2C.
While this communication is certainly suitable for high-speed devices, it also
has the drawback that the CPU's GPIO lines need to be routed all over the PCB
(printed circuit board) to the different bus switches and from there to the
chips we want to talk to.
Since I plan to use low-speed devices only, I do not want to make the hardware
design too complex.
For this reason I'd rather not take this design decision.
3) hook it up to some existing serial bus (SPI or I2C)
If the peripheral hardware chipset has support for serial communication, this
would be the easiest way to go.
Since there's already linux support for SPI as well as for I2C I would like to
use this way of talking to low-speed hardware whenever possible.
4) hook it up to some existing _external_ serial bus (USB, UART)
The single board computer should have external connections to the "outside world".
One serial port should be used as serial console while the other one will be
used for something else.
The USB connectors should be usable to connect arbitrary devices which are
supported by the linux kernel (e.g. external harddisk, webcam, whatever ...).
Also, usually peripheral hardware chips do not support USB.
For this reason this approach will not be taken for peripheral hardware access.
5) connect it to GPIO pins of a linux-supported GPIO expander that can be
accessed over I2C
This is IMHO a very promising approach which also has been taken in various
other (linux-compatible) designs I found on the internet
(e.g. the "DaVinci prototyping board",
http://www.linuxdevices.com/news/NS2209350555.html).
The idea is to connect a GPIO expander to the CPU's I2C bus which provides a
number (i.e. 8, 16, ..) of freely usable GPIO pins.
These GPIO pins are then connected to the peripheral hardware.
The linux kernel already has support for various GPIO expanders like the PCA9539
(16 port) or the PCF8574 (8 port) chips.
As far as I read in the kernel documentation, the drivers transparently map
those GPIO pins to the GPIO interface of the linux kernel.
Thus, from a device driver perspective, it makes no difference whether a device
is connected to the CPU's "real" GPIO pins or to a GPIO expander chip which can
be accessed over thr I2C bus.
Another advantage is the simple circuit design: Instead of having to route a
complete parallel bus over the PCB, only the serial I2C bus has to be routed
from the CPU to the port expander.
From the port expander a rather short bus then goes to the low-speed chip we
want to talk to.
In my oppinion, from a hardware as well as from a software perspective, this is
the right way to go.
As we saw, from a software perspective, it doesn't seem to make a big difference
whether peripheral hardware is directly hooked up to the CPU's GPIO pins or
it is hooked up to GPIO expanders.
* However, if we look at existing device drivers, will it be possible to use
them with this setup without modification ?
* How will the kernel find devices attached to GPIO pins ?
(There's no way to scan the bus since the kernel doesn't know what and where
devices are attached to the GPIO pins, right ?)
* What would be the best way to attach peripheral hardware from a linux-kernel
perspective ?
* Can you suggest any embedded hardware design documentation that considers
linux compatibility ?
sincerly,
stefan
^ permalink raw reply
* Re: Incompatible CFLAGS for kernel module
From: Sam Ravnborg @ 2008-07-05 6:33 UTC (permalink / raw)
To: Shaz
Cc: linux-embedded, ray.sunjae.lee, tpm-emulator-user,
tpm-emulator-devel, Security Engineering Archive
In-Reply-To: <7b740b700807042233q77336ba0taaae06f36e80f216@mail.gmail.com>
On Sat, Jul 05, 2008 at 10:33:28AM +0500, Shaz wrote:
> On Sat, Jul 5, 2008 at 1:32 AM, Sam Ravnborg <sam@ravnborg.org> wrote:
> > On Fri, Jul 04, 2008 at 10:34:56PM +0500, Shaz wrote:
> >> Hi,
> >>
> >> I am porting tpm emulator to versatilepb, which is an arm platform. I
> >> have some problem with CFLAGS from /arch/arm/Makefile when building
> >> the kernel module for this software. I cannot figure out what to do in
> >> this case. Following is the error:
> >>
> >> [root@develbox tpm_emulator-0.5]# make
> >> Making all in tpmd
> >> make[1]: Entering directory `/embedded/tpm_emulator-0.5/tpmd'
> >> make[1]: Nothing to be done for `all'.
> >> make[1]: Leaving directory `/embedded/tpm_emulator-0.5/tpmd'
> >> Making all in tpmd_dev
> >> make[1]: Entering directory `/embedded/tpm_emulator-0.5/tpmd_dev'
> >> CC [M] /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.o
> >> cc1: error: unrecognized command line option "-mlittle-endian"
> >> cc1: error: unrecognized command line option "-mapcs"
> >> cc1: error: unrecognized command line option "-mno-sched-prolog"
> >> cc1: error: unrecognized command line option "-mabi=aapcs-linux"
> >> cc1: error: unrecognized command line option "-mno-thumb-interwork"
> >> /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.c:1: error: bad value
> >> (armv4t) for -march= switch
> >> /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.c:1: error: bad value
> >> (arm9tdmi) for -mtune= switch
> >> make[3]: *** [/embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.o] Error 1
> >> make[2]: *** [_module_/embedded/tpm_emulator-0.5/tpmd_dev] Error 2
> >> make[1]: *** [all] Error 2
> >> make[1]: Leaving directory `/embedded/tpm_emulator-0.5/tpmd_dev'
> >> make: *** [all-recursive] Error 255
> >>
> >> kindly help me understand the core issue here and point out some solutions.
> >
> > A quick guess is that you use your host gcc and not your target gcc.
> > You most likely have to set CROSS_COMPILE=...
> >
> > Try with "make V=1" to see the exact gcc command line.
> >
> > If you continue to rn into trouble please post your Makefile.
> I tried make V=1 but the loads of info was given for the things that
> went right but nothing noticeable where the error is.
What is interesting is the gcc commandline for a good case and
a bad case. If they do not look the same we are on the right track.
> I've attached my arch/arm/Makefile. My build, host and target are on
> same system. i am emulating the board with Qemu. The process is very
> conventional. I've mounted my rootfs with -o loop and kernel and extra
> modules go there with INSTALL_MOD_PATH and INSTALL_MOD_DIR. ARCH=arm
> and CROSS_COMPILE=arm-linux-
But you do some kind of "external module" build judging from the output
above. So the Makefile of interest is the one(s) that is special for
your module. At lest the one you have in /embedded/tpm_emulator-0.5/tpmd_dev
Sam
^ permalink raw reply
* Re: Incompatible CFLAGS for kernel module
From: Shaz @ 2008-07-05 5:33 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-embedded, ray.sunjae.lee, tpm-emulator-user,
tpm-emulator-devel, Security Engineering Archive
In-Reply-To: <20080704203255.GB19110@uranus.ravnborg.org>
[-- Attachment #1: Type: text/plain, Size: 2387 bytes --]
On Sat, Jul 5, 2008 at 1:32 AM, Sam Ravnborg <sam@ravnborg.org> wrote:
> On Fri, Jul 04, 2008 at 10:34:56PM +0500, Shaz wrote:
>> Hi,
>>
>> I am porting tpm emulator to versatilepb, which is an arm platform. I
>> have some problem with CFLAGS from /arch/arm/Makefile when building
>> the kernel module for this software. I cannot figure out what to do in
>> this case. Following is the error:
>>
>> [root@develbox tpm_emulator-0.5]# make
>> Making all in tpmd
>> make[1]: Entering directory `/embedded/tpm_emulator-0.5/tpmd'
>> make[1]: Nothing to be done for `all'.
>> make[1]: Leaving directory `/embedded/tpm_emulator-0.5/tpmd'
>> Making all in tpmd_dev
>> make[1]: Entering directory `/embedded/tpm_emulator-0.5/tpmd_dev'
>> CC [M] /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.o
>> cc1: error: unrecognized command line option "-mlittle-endian"
>> cc1: error: unrecognized command line option "-mapcs"
>> cc1: error: unrecognized command line option "-mno-sched-prolog"
>> cc1: error: unrecognized command line option "-mabi=aapcs-linux"
>> cc1: error: unrecognized command line option "-mno-thumb-interwork"
>> /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.c:1: error: bad value
>> (armv4t) for -march= switch
>> /embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.c:1: error: bad value
>> (arm9tdmi) for -mtune= switch
>> make[3]: *** [/embedded/tpm_emulator-0.5/tpmd_dev/tpmd_dev.o] Error 1
>> make[2]: *** [_module_/embedded/tpm_emulator-0.5/tpmd_dev] Error 2
>> make[1]: *** [all] Error 2
>> make[1]: Leaving directory `/embedded/tpm_emulator-0.5/tpmd_dev'
>> make: *** [all-recursive] Error 255
>>
>> kindly help me understand the core issue here and point out some solutions.
>
> A quick guess is that you use your host gcc and not your target gcc.
> You most likely have to set CROSS_COMPILE=...
>
> Try with "make V=1" to see the exact gcc command line.
>
> If you continue to rn into trouble please post your Makefile.
I tried make V=1 but the loads of info was given for the things that
went right but nothing noticeable where the error is.
I've attached my arch/arm/Makefile. My build, host and target are on
same system. i am emulating the board with Qemu. The process is very
conventional. I've mounted my rootfs with -o loop and kernel and extra
modules go there with INSTALL_MOD_PATH and INSTALL_MOD_DIR. ARCH=arm
and CROSS_COMPILE=arm-linux-
>
> Sam
>
--
Shaz
[-- Attachment #2: Makefile --]
[-- Type: application/octet-stream, Size: 9736 bytes --]
#
# arch/arm/Makefile
#
# This file is included by the global makefile so that you can add your own
# architecture-specific flags and dependencies.
#
# This file is subject to the terms and conditions of the GNU General Public
# License. See the file "COPYING" in the main directory of this archive
# for more details.
#
# Copyright (C) 1995-2001 by Russell King
LDFLAGS_vmlinux :=-p --no-undefined -X
CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET)
OBJCOPYFLAGS :=-O binary -R .note -R .note.gnu.build-id -R .comment -S
GZFLAGS :=-9
#KBUILD_CFLAGS +=-pipe
# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
KBUILD_CFLAGS +=$(call cc-option,-marm,)
# Do not use arch/arm/defconfig - it's always outdated.
# Select a platform tht is kept up-to-date
KBUILD_DEFCONFIG := versatile_defconfig
# defines filename extension depending memory manement type.
ifeq ($(CONFIG_MMU),)
MMUEXT := -nommu
endif
ifeq ($(CONFIG_FRAME_POINTER),y)
KBUILD_CFLAGS +=-fno-omit-frame-pointer -mapcs -mno-sched-prolog
endif
ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
KBUILD_CPPFLAGS += -mbig-endian
AS += -EB
LD += -EB
else
KBUILD_CPPFLAGS += -mlittle-endian
AS += -EL
LD += -EL
endif
comma = ,
# This selects which instruction set is used.
# Note that GCC does not numerically define an architecture version
# macro, but instead defines a whole series of macros which makes
# testing for a specific architecture or later rather impossible.
arch-$(CONFIG_CPU_32v7) :=-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7a,-march=armv5t -Wa$(comma)-march=armv7a)
arch-$(CONFIG_CPU_32v6) :=-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6)
# Only override the compiler option if ARMv6. The ARMv6K extensions are
# always available in ARMv7
ifeq ($(CONFIG_CPU_32v6),y)
arch-$(CONFIG_CPU_32v6K) :=-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,-march=armv5t -Wa$(comma)-march=armv6k)
endif
arch-$(CONFIG_CPU_32v5) :=-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t)
arch-$(CONFIG_CPU_32v4T) :=-D__LINUX_ARM_ARCH__=4 -march=armv4t
arch-$(CONFIG_CPU_32v4) :=-D__LINUX_ARM_ARCH__=4 -march=armv4
arch-$(CONFIG_CPU_32v3) :=-D__LINUX_ARM_ARCH__=3 -march=armv3
# This selects how we optimise for the processor.
tune-$(CONFIG_CPU_ARM610) :=-mtune=arm610
tune-$(CONFIG_CPU_ARM710) :=-mtune=arm710
tune-$(CONFIG_CPU_ARM7TDMI) :=-mtune=arm7tdmi
tune-$(CONFIG_CPU_ARM720T) :=-mtune=arm7tdmi
tune-$(CONFIG_CPU_ARM740T) :=-mtune=arm7tdmi
tune-$(CONFIG_CPU_ARM9TDMI) :=-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM940T) :=-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM946T) :=$(call cc-option,-mtune=arm9e,-mtune=arm9tdmi)
tune-$(CONFIG_CPU_ARM920T) :=-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM922T) :=-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM925T) :=-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM926T) :=-mtune=arm9tdmi
tune-$(CONFIG_CPU_SA110) :=-mtune=strongarm110
tune-$(CONFIG_CPU_SA1100) :=-mtune=strongarm1100
tune-$(CONFIG_CPU_XSCALE) :=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
tune-$(CONFIG_CPU_XSC3) :=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
tune-$(CONFIG_CPU_V6) :=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
ifeq ($(CONFIG_AEABI),y)
CFLAGS_ABI :=-mabi=aapcs-linux -mno-thumb-interwork
else
CFLAGS_ABI :=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) $(call cc-option,-mno-thumb-interwork,)
endif
# Need -Uarm for gcc < 3.x
KBUILD_CFLAGS +=$(CFLAGS_ABI) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
KBUILD_AFLAGS +=$(CFLAGS_ABI) $(arch-y) $(tune-y) -msoft-float
CHECKFLAGS += -D__arm__
#Default value
head-y := arch/arm/kernel/head$(MMUEXT).o arch/arm/kernel/init_task.o
textofs-y := 0x00008000
machine-$(CONFIG_ARCH_RPC) := rpc
machine-$(CONFIG_ARCH_EBSA110) := ebsa110
machine-$(CONFIG_ARCH_CLPS7500) := clps7500
incdir-$(CONFIG_ARCH_CLPS7500) := cl7500
machine-$(CONFIG_FOOTBRIDGE) := footbridge
incdir-$(CONFIG_FOOTBRIDGE) := ebsa285
machine-$(CONFIG_ARCH_CO285) := footbridge
incdir-$(CONFIG_ARCH_CO285) := ebsa285
machine-$(CONFIG_ARCH_SHARK) := shark
machine-$(CONFIG_ARCH_SA1100) := sa1100
ifeq ($(CONFIG_ARCH_SA1100),y)
# SA1111 DMA bug: we don't want the kernel to live in precious DMA-able memory
textofs-$(CONFIG_SA1111) := 0x00208000
endif
machine-$(CONFIG_ARCH_PXA) := pxa
machine-$(CONFIG_ARCH_L7200) := l7200
machine-$(CONFIG_ARCH_INTEGRATOR) := integrator
textofs-$(CONFIG_ARCH_CLPS711X) := 0x00028000
machine-$(CONFIG_ARCH_CLPS711X) := clps711x
machine-$(CONFIG_ARCH_IOP32X) := iop32x
machine-$(CONFIG_ARCH_IOP33X) := iop33x
machine-$(CONFIG_ARCH_IOP13XX) := iop13xx
machine-$(CONFIG_ARCH_IXP4XX) := ixp4xx
machine-$(CONFIG_ARCH_IXP2000) := ixp2000
machine-$(CONFIG_ARCH_IXP23XX) := ixp23xx
machine-$(CONFIG_ARCH_OMAP1) := omap1
machine-$(CONFIG_ARCH_OMAP2) := omap2
incdir-$(CONFIG_ARCH_OMAP) := omap
machine-$(CONFIG_ARCH_S3C2410) := s3c2410
machine-$(CONFIG_ARCH_LH7A40X) := lh7a40x
machine-$(CONFIG_ARCH_VERSATILE) := versatile
machine-$(CONFIG_ARCH_IMX) := imx
machine-$(CONFIG_ARCH_H720X) := h720x
machine-$(CONFIG_ARCH_AAEC2000) := aaec2000
machine-$(CONFIG_ARCH_REALVIEW) := realview
machine-$(CONFIG_ARCH_AT91) := at91
machine-$(CONFIG_ARCH_EP93XX) := ep93xx
machine-$(CONFIG_ARCH_PNX4008) := pnx4008
machine-$(CONFIG_ARCH_NETX) := netx
machine-$(CONFIG_ARCH_NS9XXX) := ns9xxx
textofs-$(CONFIG_ARCH_NS9XXX) := 0x00108000
machine-$(CONFIG_ARCH_DAVINCI) := davinci
machine-$(CONFIG_ARCH_KS8695) := ks8695
incdir-$(CONFIG_ARCH_MXC) := mxc
machine-$(CONFIG_ARCH_MX3) := mx3
machine-$(CONFIG_ARCH_ORION) := orion
machine-$(CONFIG_ARCH_MSM7X00A) := msm
ifeq ($(CONFIG_ARCH_EBSA110),y)
# This is what happens if you forget the IOCS16 line.
# PCMCIA cards stop working.
CFLAGS_3c589_cs.o :=-DISA_SIXTEEN_BIT_PERIPHERAL
export CFLAGS_3c589_cs.o
endif
# The byte offset of the kernel image in RAM from the start of RAM.
TEXT_OFFSET := $(textofs-y)
ifeq ($(incdir-y),)
incdir-y := $(machine-y)
endif
INCDIR := arch-$(incdir-y)
ifneq ($(machine-y),)
MACHINE := arch/arm/mach-$(machine-y)/
else
MACHINE :=
endif
export TEXT_OFFSET GZFLAGS MMUEXT
# Do we have FASTFPE?
FASTFPE :=arch/arm/fastfpe
ifeq ($(FASTFPE),$(wildcard $(FASTFPE)))
FASTFPE_OBJ :=$(FASTFPE)/
endif
# If we have a machine-specific directory, then include it in the build.
core-y += arch/arm/kernel/ arch/arm/mm/ arch/arm/common/
core-y += $(MACHINE)
core-$(CONFIG_ARCH_S3C2410) += arch/arm/mach-s3c2400/
core-$(CONFIG_ARCH_S3C2410) += arch/arm/mach-s3c2412/
core-$(CONFIG_ARCH_S3C2410) += arch/arm/mach-s3c2440/
core-$(CONFIG_ARCH_S3C2410) += arch/arm/mach-s3c2442/
core-$(CONFIG_ARCH_S3C2410) += arch/arm/mach-s3c2443/
core-$(CONFIG_FPE_NWFPE) += arch/arm/nwfpe/
core-$(CONFIG_FPE_FASTFPE) += $(FASTFPE_OBJ)
core-$(CONFIG_VFP) += arch/arm/vfp/
# If we have a common platform directory, then include it in the build.
core-$(CONFIG_PLAT_IOP) += arch/arm/plat-iop/
core-$(CONFIG_ARCH_OMAP) += arch/arm/plat-omap/
core-$(CONFIG_PLAT_S3C24XX) += arch/arm/plat-s3c24xx/
core-$(CONFIG_ARCH_MXC) += arch/arm/plat-mxc/
drivers-$(CONFIG_OPROFILE) += arch/arm/oprofile/
drivers-$(CONFIG_ARCH_CLPS7500) += drivers/acorn/char/
drivers-$(CONFIG_ARCH_L7200) += drivers/acorn/char/
libs-y := arch/arm/lib/ $(libs-y)
# Default target when executing plain make
ifeq ($(CONFIG_XIP_KERNEL),y)
KBUILD_IMAGE := xipImage
else
KBUILD_IMAGE := zImage
endif
all: $(KBUILD_IMAGE)
boot := arch/arm/boot
# Update machine arch and proc symlinks if something which affects
# them changed. We use .arch to indicate when they were updated
# last, otherwise make uses the target directory mtime.
include/asm-arm/.arch: $(wildcard include/config/arch/*.h) include/config/auto.conf
@echo ' SYMLINK include/asm-arm/arch -> include/asm-arm/$(INCDIR)'
ifneq ($(KBUILD_SRC),)
$(Q)mkdir -p include/asm-arm
$(Q)ln -fsn $(srctree)/include/asm-arm/$(INCDIR) include/asm-arm/arch
else
$(Q)ln -fsn $(INCDIR) include/asm-arm/arch
endif
@touch $@
archprepare: maketools
PHONY += maketools FORCE
maketools: include/linux/version.h include/asm-arm/.arch FORCE
$(Q)$(MAKE) $(build)=arch/arm/tools include/asm-arm/mach-types.h
# Convert bzImage to zImage
bzImage: zImage
zImage Image xipImage bootpImage uImage: vmlinux
$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
zinstall install: vmlinux
$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
CLEAN_FILES += include/asm-arm/mach-types.h \
include/asm-arm/arch include/asm-arm/.arch
# We use MRPROPER_FILES and CLEAN_FILES now
archclean:
$(Q)$(MAKE) $(clean)=$(boot)
# My testing targets (bypasses dependencies)
bp:; $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/bootpImage
i zi:; $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
define archhelp
echo '* zImage - Compressed kernel image (arch/$(ARCH)/boot/zImage)'
echo ' Image - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
echo '* xipImage - XIP kernel image, if configured (arch/$(ARCH)/boot/xipImage)'
echo ' uImage - U-Boot wrapped zImage'
echo ' bootpImage - Combined zImage and initial RAM disk'
echo ' (supply initrd image via make variable INITRD=<path>)'
echo ' install - Install uncompressed kernel'
echo ' zinstall - Install compressed kernel'
echo ' Install using (your) ~/bin/installkernel or'
echo ' (distribution) /sbin/installkernel or'
echo ' install to $$(INSTALL_PATH) and run lilo'
endef
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox