Bare bones filesytem using Karim's book

Bare bones filesytem using Karim's book

[brian.auld]

Hello,

I have used pre-built tool-chains/filesytems to boot linux on a 440GP ebony platform in the past using u-boot and an nfs mounted root filesystem.

After getting Karim's new book, I have been trying some things from scratch. I've built the tool-chain and I'm now trying to boot my kernel on ebony using a filesystem that was built according to the guidelines in Chapter 6 (Root Filesystem Content). I'm pretty sure I have followed the book to a tee (busybox not LFS), however, my boot sequence appears to be stopping at the point init is supposed to run.

Any quick thoughts on why this might be happening? To provide a comparison benchmark as I worked through this, I copied the (i) dev files, (ii) inittab and (iii) rc.sysinit from chapter 6 of the book (my "from scratch filesytem") to the ELDK stripped down target filesystem and this setup still boots. As for my stripped down ELDK, I have stripped it to the point where the following remains:

glibc-ppc_4xx-2.2.5-0.19a
libtermcap-devel-ppc_4xx-2.0.8-28
cracklib-dicts-ppc_4xx-2.7-12
pam-devel-ppc_4xx-0.75-19
fileutils-ppc_4xx-4.1-4
mingetty-ppc_4xx-0.9.4-18
gawk-ppc_4xx-3.1.0-3
SysVinit-ppc_4xx-2.78-19
e2fsprogs-devel-ppc_4xx-1.26-1.72
modutils-ppc_4xx-2.4.13-0.7.1a
bash-ppc_4xx-2.05-8
net-tools-ppc_4xx-1.60-3
portmap-ppc_4xx-4.0-38a
initscripts-ppc_4xx-6.43-1c
termcap-ppc_4xx-11.0.1-10
kernel-headers-ppc_4xx-2.4.4-1
glibc-common-ppc_4xx-2.2.5-0.19a
glibc-devel-ppc_4xx-2.2.5-0.19a
glib-ppc_4xx-1.2.10-5
libtermcap-ppc_4xx-2.0.8-28
cracklib-ppc_4xx-2.7-12
pam-ppc_4xx-0.75-19
textutils-ppc_4xx-2.0.14-2
mount-ppc_4xx-2.11g-5a
setup-ppc_4xx-2.3.4-1b
sh-utils-ppc_4xx-2.0.11-5
e2fsprogs-ppc_4xx-1.26-1.72
logrotate-ppc_4xx-3.5.9-1
sysklogd-ppc_4xx-1.4.1-4
util-linux-ppc_4xx-2.11f-17
busybox-ppc_4xx-0.60.1-17

Most of the above were left in as I felt they needed to be there or they were "required" sysVinit or initscripts, which I didn't want to remove...

Below is a log of my boot log for the "from scratch" filesystem. The stripped down ELDK filesystem still boots.

=============================================
Environment size: 509/4092 bytes
=> run bootcmd
ENET Speed is 100 Mbps - HALF duplex connection
ARP broadcast 1
TFTP from server 172.16.77.152; our IP address is 172.16.77.156
Filename '/tftpboot/vmlinux-iscsi-kernel'.
Load address: 0x100000
Loading: #################################################################
         #################################################
done
Bytes transferred = 583522 (8e762 hex)
## Booting image at 00100000 ...
   Image Name:   Linux-2.4.20
   Created:      2003-06-01  19:36:59 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    583458 Bytes = 569.8 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Linux version 2.4.20 (test@ppc-dev) (gcc version 2.95.3 20010315 (release)) #1 Sun Jun 1 15:34:30 EDT 2003
IBM Ebony port (C) 2002 MontaVista Software, Inc. (source@mvista.com)
On node 0 totalpages: 32768
zone(0): 4096 pages.
zone(1): 28672 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs rw nfsroot=172.16.77.152:/home/test/mcb/usr/iscsi-rootfs ip=172.16.77.156:172.16.77.152:172.16.77.1:255.255.255.0:EBONY-3::off console=ttyS0
Calibrating delay loop... 599.65 BogoMIPS
Memory: 127760k available (940k kernel code, 344k data, 212k init, 0k highmem)
Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0xfdfe9200 (irq = 0) is a 16550A
ttyS01 at 0xfdfe8300 (irq = 1) is a 16550A
Zmii bridge in RMII mode
eth0: Phy @ 0x8, type Am79c875A (0x00225541)
Reset ethernet interfaces
Zmii bridge in RMII mode
eth1: Phy @ 0x9, type Am79c875A (0x00225541)
Reset ethernet interfaces
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
eth0: IBM EMAC: link up, 100 Mbps Half Duplex, auto-negotiation complete.
eth0: IBM EMAC: MAC 00:04:ac:e3:1a:51.
eth0: IBM EMAC: open completed

eth1: IBM EMAC: link up, 10 Mbps Half Duplex.
eth1: IBM EMAC: MAC 00:04:ac:e3:1a:52.
eth1: IBM EMAC: open completed

IP-Config: Complete:
      device=eth0, addr=172.16.77.156, mask=255.255.255.0, gw=172.16.77.1,
     host=EBONY-3, domain=, nis-domain=(none),
     bootserver=172.16.77.152, rootserver=172.16.77.152, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 172.16.77.152
Looking up port of RPC 100005/1 on 172.16.77.152
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 212k init
==================================================

The "Freeing unused kernel memory:..." line is where it stops. Any ideas?

Thanks,

-- Brian


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Bare bones filesytem using Karim's book

[Wolfgang Denk]

Dear Brian,

in message <995FF289C9D69747A09E4299264459540C109861@penguin.adic.com> you wrote:
>
> Any quick thoughts on why this might be happening? To provide a comparison benchmark as I worked through this, I copied the (i) dev files, (ii) inittab and (iii) rc.sysinit from chapter 6 of the book (my "from scratch filesytem") to the ELDK stripped do
> wn target filesystem and this setup still boots. As for my stripped down ELDK, I have stripped it to the point where the following remains:
>
> glibc-ppc_4xx-2.2.5-0.19a
> libtermcap-devel-ppc_4xx-2.0.8-28
> cracklib-dicts-ppc_4xx-2.7-12
> pam-devel-ppc_4xx-0.75-19
> fileutils-ppc_4xx-4.1-4
> mingetty-ppc_4xx-0.9.4-18
> gawk-ppc_4xx-3.1.0-3
> SysVinit-ppc_4xx-2.78-19
> e2fsprogs-devel-ppc_4xx-1.26-1.72
> modutils-ppc_4xx-2.4.13-0.7.1a
> bash-ppc_4xx-2.05-8
> net-tools-ppc_4xx-1.60-3
> portmap-ppc_4xx-4.0-38a
> initscripts-ppc_4xx-6.43-1c
> termcap-ppc_4xx-11.0.1-10
> kernel-headers-ppc_4xx-2.4.4-1
> glibc-common-ppc_4xx-2.2.5-0.19a
> glibc-devel-ppc_4xx-2.2.5-0.19a
> glib-ppc_4xx-1.2.10-5
> libtermcap-ppc_4xx-2.0.8-28
> cracklib-ppc_4xx-2.7-12
> pam-ppc_4xx-0.75-19
> textutils-ppc_4xx-2.0.14-2
> mount-ppc_4xx-2.11g-5a
> setup-ppc_4xx-2.3.4-1b
> sh-utils-ppc_4xx-2.0.11-5
> e2fsprogs-ppc_4xx-1.26-1.72
> logrotate-ppc_4xx-3.5.9-1
> sysklogd-ppc_4xx-1.4.1-4
> util-linux-ppc_4xx-2.11f-17
> busybox-ppc_4xx-0.60.1-17

Oops. You call that "stripped down"? Ummm...

If you want to know what is  needed  for  a  small  filesystem  still
providing  things  like  PAM-based  login  and  xinetd based services
(telnet, ftp) you should have a look at the SELF RPM and  it's  build
script.  It  is  *significantly*  smaller  than your ""stripped down"
system...

> Most of the above were left in as I felt they needed to be there or they were "required" sysVinit or initscripts, which I didn't want to remove...

What makes you think these packages are needed? What exactly  do  YOU
need them for?

For example, why do you think glibc-devel is needed for  your  target
filesystem?

When designing an embedded system you  must  not  try  to  folow  any
package  dependencies  from  some  distribution.  Design  your system
bottom up: just add the components which absolutley  must  go  in  to
perform  services required by your project specification. OK, you may
_then_ end up adding some more "glue"...

> Below is a log of my boot log for the "from scratch" filesystem. The stripped down ELDK filesystem still boots.
...
> The "Freeing unused kernel memory:..." line is where it stops. Any ideas?

There are many, many things you may have done wrong.  Missing  device
nodes,  missing  libraries,  bogus  configuration.  For  example, you
include both SysVinit-ppc_4xx-2.78-19  and  busybox-ppc_4xx-0.60.1-17
in  your  list - both include thier own (and incompatible!!!) version
of an init process.

Which one did you (try to) enable?


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The explanation requiring the fewest assumptions is the  most  likely
to be correct.                                    -- William of Occam

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Bare bones filesytem using Karim's book

[Karim Yaghmour]

Hello Brian,

Apart from what Wolfgang has already said, I would add the following
gotchas:
- Make sure the library you are linking your init to, whichever one it
may be, is actually functional. I have seen some glibc versions
compile fine and fail to work on the target. See the 4th paragraph
on p. 112 for an example. Suggestion: try a different C library
version.
- Your libs may not be properly located. Suggestions: try linking
your init statically.
- Try putting something else as init. Use the init= kernel boot param
to pass some custom statically linked program that does something
obvious (while(1) printf(...); for example) and check if that works.

brian.auld@adic.com wrote:
> Any quick thoughts on why this might be happening? To provide a comparison benchmark as I worked through this, I copied the (i) dev files, (ii) inittab and (iii) rc.sysinit from chapter 6 of the book (my "from scratch filesytem") to the ELDK stripped down target filesystem and this setup still boots.

Right, this sounds like a library thing. Though I may be wrong.

> Most of the above were left in as I felt they needed to be there or they were "required" sysVinit or initscripts, which I didn't want to remove...

Better watch out for having both sysVinit and BusyBox-init as Wolfgang
already pointed out.

HTH,

Karim

--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Bare bones filesytem using Karim's book

[brian.auld]

Thanks for the feedback Wolfgang and Karim...

Regarding the ELDK target filesytem, all I did was try to strip it down using 'ppc_4xx-rpm -e package' as far as I could go. The remaining packages below are there because the above command would could not remove them because of package dependencies. So, the reason busybox and sysvinit are both shown in the list is because they were part of the initial ppc_4xx target filesystem provided with the ELDK.

Based on your responses, it sounds like the steps provided in Karim's book should work. I'll try the suggestions provided.

Regarding my tool chain, for and x86-host --> ppc-target setup, the following packages were suggested in the book:

gcc - 2.95.3
binutils - 2.10.1
glibc - 2.2.1

When I tried to build this tool chain (on RH8.0 system) glibc would not compile. I then checked the versions used in the ELDK tool-chain which were as follows:

gcc - 2.95.4-4j
Binutils - 2.11.93.0.2-3b
glibc - 2.2.5-0.19a

So, I tried building the tool-chain again using versions obtainable from gnu.org that were as close to the ELDK as possible without being more recent:

gcc - 2.95.3
binutils - 2.11.2
glibc - 2.2.5

If anyone has any suggestions as to a different combination of version, please let me know.

-- Brian

> -----Original Message-----
> From: Karim Yaghmour [mailto:karim@opersys.com]
> Sent: Monday, June 02, 2003 7:56 PM
> To: brian.auld@adic.com
> Cc: linuxppc-embedded@lists.linuxppc.org
> Subject: Re: Bare bones filesytem using Karim's book
>
>
> Hello Brian,
>
> Apart from what Wolfgang has already said, I would add the following
> gotchas:
> - Make sure the library you are linking your init to, whichever one it
> may be, is actually functional. I have seen some glibc versions
> compile fine and fail to work on the target. See the 4th paragraph
> on p. 112 for an example. Suggestion: try a different C library
> version.
> - Your libs may not be properly located. Suggestions: try linking
> your init statically.
> - Try putting something else as init. Use the init= kernel boot param
> to pass some custom statically linked program that does something
> obvious (while(1) printf(...); for example) and check if that works.
>
> brian.auld@adic.com wrote:
> > Any quick thoughts on why this might be happening? To provide a
> comparison benchmark as I worked through this, I copied the (i) dev files,
> (ii) inittab and (iii) rc.sysinit from chapter 6 of the book (my "from
> scratch filesytem") to the ELDK stripped down target filesystem and this
> setup still boots.
>
> Right, this sounds like a library thing. Though I may be wrong.
>
> > Most of the above were left in as I felt they needed to be there or they
> were "required" sysVinit or initscripts, which I didn't want to remove...
>
> Better watch out for having both sysVinit and BusyBox-init as Wolfgang
> already pointed out.
>
> HTH,
>
> Karim
>
> --
> Author, Speaker, Developer, Consultant
> Pushing Embedded and Real-Time Linux Systems Beyond the Limits
> http://www.opersys.com || karim@opersys.com || 514-812-4145

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Bare bones filesytem using Karim's book

[Wolfgang Denk]

Dear Brian,

in message <995FF289C9D69747A09E4299264459540C109862@penguin.adic.com> you wrote:
>
> Regarding the ELDK target filesytem, all I did was try to strip it
> down using 'ppc_4xx-rpm -e package' as far as I could go. The
> remaining packages below are there because the above command would
> could not remove them because of package dependencies. So, the reason

Such an approach makes little sense for building an embedded system.

Why do you care about packages and package dependencies? You will not
use a package manager in hte target system, so you are free  to  copy
or remove individual files as you like.

Also, the approach to strip  down  a  general  purppose  distribution
(even  an embedded one) does not make much sense - as I wrote before,
you better design your system bottom up by  starting  with  an  empty
filesystem  and  just  adding  the  really required components. Where
"required" means "required to perform some task you defined  in  your
project specification".


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
We're all sorry for the other guy when he loses his job to a machine.
But when it comes to your job -- that's different. And it always will
be different.
	-- McCoy, "The Ultimate Computer", stardate 4729.4

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Bare bones filesytem using Karim's book

[brian.auld]

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd@denx.de]
> Sent: Tuesday, June 03, 2003 11:12 AM
> To: brian.auld@adic.com
> Cc: linuxppc-embedded@lists.linuxppc.org
> Subject: Re: Bare bones filesytem using Karim's book
>
> Dear Brian,
>
> in message <995FF289C9D69747A09E4299264459540C109862@penguin.adic.com> you
> wrote:
> >
> > Regarding the ELDK target filesytem, all I did was try to strip it
> > down using 'ppc_4xx-rpm -e package' as far as I could go. The
> > remaining packages below are there because the above command would
> > could not remove them because of package dependencies. So, the reason
>
> Such an approach makes little sense for building an embedded system.


Thanks for the feedback Wolfgang. My intention ultimately is to build my tgt filesytem from the ground up. The ELDK tinkering was an attempt to provide a comparison platform to try and help me understand why my bare bones filesytem wasn't working...


>
> Why do you care about packages and package dependencies? You will not
> use a package manager in hte target system, so you are free  to  copy
> or remove individual files as you like.
>
> Also, the approach to strip  down  a  general  purppose  distribution
> (even  an embedded one) does not make much sense - as I wrote before,
> you better design your system bottom up by  starting  with  an  empty
> filesystem  and  just  adding  the  really required components. Where
> "required" means "required to perform some task you defined  in  your
> project specification".

That's what I'm trying to do, building from the ground up that is. Just can't get my bare bones system (basic rootfs dir infrastructure with busybox) to boot yet :-(

-- Brian

>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
> We're all sorry for the other guy when he loses his job to a machine.
> But when it comes to your job -- that's different. And it always will
> be different.
> 	-- McCoy, "The Ultimate Computer", stardate 4729.4

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Bare bones filesytem using Karim's book

[Karim Yaghmour]

brian.auld@adic.com wrote:
> Regarding my tool chain, for and x86-host --> ppc-target setup, the following packages were suggested in the book:
>
> gcc - 2.95.3
> binutils - 2.10.1
> glibc - 2.2.1
>
> When I tried to build this tool chain (on RH8.0 system) glibc would not compile.

Interesting. You may want to try uClibc.

Karim

--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Bare bones filesytem using Karim's book

[Dr. Craig Hollabaugh]

> Also, the approach to strip  down  a  general  purppose  distribution
> (even  an embedded one) does not make much sense - as I wrote before,
> you better design your system bottom up by  starting  with  an  empty
> filesystem  and  just  adding  the  really required components. Where
> "required" means "required to perform some task you defined  in  your
> project specification".


I agree, here's how you start. After kernel initializes everything it
executes init, so what libraries does init require?

holla@gibson[502]: ldd /sbin/init
        libc.so.6 => /lib/libc.so.6 (0x4001a000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Well that is if you're running init and want libc. ldd bash, sash,
ash, busybox whatever.

Craig


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/