On Sat, Jun 02, 2007 at 02:38:28PM -0400, Dave Jones wrote:
> Hi Lennert,
Hi Dave,
Thanks for your time.
> > I'm posting here because I would really really like to get the
> > relevant diffs merged back into Fedora.
>
> I took a quick look at the kernel dir, and the specfile changes are
> pretty unoffensive, and mergable imo.
Note that the current kernel changes only make %{arm} a nobuildarch.
I.e. we don't actually build a kernel image rpm at this point. This
is for several reasons, some of which noted elsewhere in the thread:
- ARM kernels are pretty much specific to the ARM CPU model they are
built for. E.g., while you _can_ make a kernel image that supports
multiple different boards that are all based on the same Samsung
s3c24xx ARM CPU, you can't build one kernel image that supports
both Samsung s3c24xx and Intel PXA27x based boards, due to various
differences in those CPUs:
- Top-level IRQ demux is done differently on different ARM CPUs
(as different ARM CPUs have different on-chip IRQ controllers),
and IRQ demux is currently done by a CPU port provided macro
(in include/asm-arm/arch-*/entry-macro.S.) It probably _is_
possible to make this switchable at boot time, but would
require some work.
- Some ARM CPUs are cache coherent w.r.t. DMA, and some are not.
- Some ARM CPUs are strongly ordered, while some have weak
ordering of RAM accesses versus I/O accesses, and the barrier
instructions supported by the (semi-)weakly ordered ARM CPUs
are undefined insns on earlier strongly ordered CPUs.
- Different ARM CPUs conform to different versions of the ARM
instruction set spec, which means that different ops are available
for atomic accesses (an xchg-type 'swp' instruction in older CPUs
versus load locked/store conditional insns in newer CPUs), some
CPUs provide opcodes for 'find first bit' while others do not,
etc.
So if you want to provide ARM kernel images, you probably have
no choice but to provide one per CPU type, which is probably doable
(Debian does it this way as well, for the CPU types that people
request support for), but it does mean that it's not as easy as
just providing one kernel image which would then work everywhere.
- The kernels people tend to use on ARM hardware tend to diverge more
from upstream than kernels that people tend to use on x86 hardware.
While I and many others do build kernels from upstream and make sure
the boards we use are fully supported upstream, a lot of others do
not. In fact, the upstream kernel probably doesn't even support
half of the ARM CPU types out there (despite our best efforts) :-(
At this point, the FC6 ARM port is more intended for developers
than end users, and that class of people presumably already have
working kernel images for their hardware anyway. I'm not sure how
much sense it makes in the end. (There appear to be some ARM
folks on the list, maybe they can share their opinions on this?)
> The config file however I think might be better served if it was
> done differently.
ACK, that makes sense. I just copied whatever the other FC6 archs
did to get the package to build.
> Instead of having a single flat config file, the Fedora kernel rpm
> generates configs out of templates (see configs/ dir in cvs)
> It should be fairly simple to change this though..
> just remove all the symbols from your current config that are already
> in config-generic (except for ones you want to override).
> Then add a stanza to Makefile.config to call merge.pl on
> config-generic and config-arm.
To be honest, I didn't spend a lot of effort on creating the current
.config file, I actually just used the .config file that I use on one
of my ARM boards.
> The advantages of doing it this way are that we don't have to update
> n config files when upstream adds a new option, just adding it to
> config-generic gets it automatically added to all archs where it
> makes sense.
ACK.
> Having a quick scan through some of the options you have set..
>
> # CONFIG_UTRACE is not set
>
> note that this will also disable ptrace too afaik.
Hmm. Hmm?
[root@iop ~]# uname -a
Linux iop.wantstofly.org 2.6.21 #13 Sun May 13 23:39:28 CEST 2007 armv5tel armv5tel armv5tel GNU/Linux
[root@iop ~]# cat /etc/redhat-release
Fedora Core release 6 (Zod)
[root@iop ~]# strace ls
execve("/bin/ls", ["ls"], [/* 23 vars */]) = 0
brk(0) = 0x26000
uname({sys="Linux", node="iop.wantstofly.org", ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x15571000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=42215, ...}) = 0
mmap2(NULL, 42215, PROT_READ, MAP_PRIVATE, 3, 0) = 0x1557b000
[...]
> CONFIG_DEFAULT_DEADLINE=y
>
> Any reason not to go with CFQ like we do on other archs?
No particular reason, really.
> CONFIG_IDE=y
> Has anyone looked at porting the ARM ATA drivers over to libata ?
IDE/PATA comes in various different flavors on ARM platforms. In
summary, yes, most ATA stuff on ARM platforms either works with
libata right now or will work with libata very soon.
First of all, there's the regular PCI controllers. These work fine
on ARM without any changes necessary. The main dev boards that I use
all have their storage on PCI, and use libata.
[root@iop ~]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 305678480 69718320 220432536 25% /
none 127980 0 127980 0% /dev/shm
[root@iop ~]# lspci | grep SATA
00:01.0 Mass storage controller: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01)
[root@iop ~]#
Then there's a lot of ARM dev boards that come with CompactFlash slots.
These are typically just hooked up to the peripheral bus of the CPU
(typically the same bus that the boot flash is on), and if task file
accesses can be made with regular direct MMIO accesses, you can just
use the pata_platform driver (which works fine.) (In this case, you
typically just use PIO.)
Then there's also a bunch of ARM CPUs come with PATA or SATA built in
to the chip. Most of the SATA stuff is actually using libata already,
and most PATA stuff either also uses pata_platform, or when HW designers
do ugly things, or when the chip can do DMA, it needs a CPU-specific
driver. Most of these have either already been written for libata, or
are still being written. E.g.:
http://marc.info/?l=linux-ide&m=117001700116724&w=2
> # CONFIG_VT is not set
> Is this always going to be useless on ARM ?
Probably not -- there's enough ARM CPUs out there with built-in
graphics controllers, and you'd probably like to run VTs on those
(it's just that my build machines only have serial console.)
> # CONFIG_MMC is not set
> might be handy for handhelds ?
ACK.
> # CONFIG_EXT2_FS_XATTR is not set
> # CONFIG_EXT3_FS_XATTR is not set
> # CONFIG_SECURITY is not set
>
> aww, no selinux ?
I've never actually tested this on ARM. (I _assume_ it should just
work..)
> There's a lot of stuff built in =y, rather than modular which
> seems a little wasteful. (In fact, there's nothing =m,
> yet CONFIG_MODULES=y :-)
>
> There's a few things that stuck out that seem like they may be
> useful (ipsec support for eg) in some use-cases for embedded systems
> that were disabled.
>
> I'll concede that Fedora-ARM is breaking new ground here, in that
> its the first arch we're supporting (other than olpc I guess)
> where the size of the generated rpms is a concern, but I think
> there's probably a balance to be struck between what we have
> so far, and a 'generic' kernel that may be of use to many different
> projects without them needing to rebuild parts of the kernel
> that were left out.
I think that for development use, when disk space is not a concern
(when you're either on directly attached storage or nfsroot), it makes
a lot of sense to use a kernel that supports everything, and to run
the full vanilla Fedora ARM distro with all the development tools, etc.
When you get to the phase where you're building a custom filesystem
for an embedded device, where everything has to fit in 32M or 16M of
flash or even less, you'd customise both your kernel and all your
userland packages from what is provided in Fedora (and you'd typically
cross-compile most of your packages when you do so), but that isn't a
use case that is targeted with this round of patches yet.
I.e. on top of the Fedora ARM patches we have now, there are various
other things that can be done (slimming down packages, making them
cross-compileable, etc.) to make Fedora packages more suitable for
building such minimal filesystems with, things that will benefit ARM
and OLPC alike, but those are orthogonal efforts to this ARM support
patch set.
IOW, I think not spending any effort yet on trying to slim down
packages is fine in this stage.
cheers,
Lennert
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
