[Buildroot] Still can't build working rootfs with crosstool-NG toolchain

[Buildroot] Still can't build working rootfs with crosstool-NG toolchain

[Grant Edwards]

I've spend the past week trying to use crosstool-NG instead of
buildroot to build a toolchain.  I had been using external buildroot
toolchains for the past couple months with no problems. But, that is
unsupported by buildroot, and I'm giving up fighting that battle.

With crosstool-NG I can build a toolchain fine, and I can use it to
build kernels and root filesystems, but when I use a root filesystem
built with the crosstool-NG toolchain, I get a kernel panic
immediately folloing the mounting of the root filesystem.

A rootfs built by the buildroot toolchain works fine.

It's the same gcc and uClibc versions in both cases and the same
buildroot/rootfs settings.

It doesn't seem to matter which toolchain I use to build the kernel, I
get the same results with both kernels. I'm using an Atmel
AT91SAM9G20EK development board, gcc 4.4.3, uClibc 0.9.30.2.

Below the log of a failed startupt.  The log of a successful startup
using a buildroot-toolchain rootfs is identical except for two things:

  1) The successfull rootfs is 20K larger, so a few of the lines with
     memory size diagnostics are different.

  2) Instead of a kernel panic, I get welcome message and login
     prompt when using the buildroot toolchain.

Any ideas on why a rootfs built using a crosstool-ng toolchain
wouldn't work?   In general how does one troubleshoot kernel panics
like this?

Differences I can see in the toolchain configurations:

 * ct-NG uses cloog/ppl, buildroot doesn't

 * ct-NG enables __cxa_atexit, buildroot doesn't.

 * ct-NG enables c99, buildroot doesn't.

 * ct-NG enables long-long, buildroot doesn't.

 * ct-NG uses --enable-threads=posix, buildroot is just --enable-threads 

 * buildroot specifies armv5te/arm9tdmi, ct-NG doesn't

 * buildroot specifies abi=apcs-gnu, ct-NG doesn't


My ct-NG config is based on one of the "working samples" provided with
ct-NG.
  
All ideas/suggestions welcome...
  

------------------------------------------------------------------------  
RomBOOT


U-Boot 1.3.4 (Jan  6 2010 - 15:52:13)

DRAM:  64 MB
NAND:  256 MiB
DataFlash:AT45DB642
Nb pages:   8192
Page Size:   1056
Size= 8650752 bytes
Logical address: 0xD0000000
Area 0:	D0000000 to D00041FF (RO) Bootstrap
Area 1:	D0004200 to D00083FF      Environment
Area 2:	D0008400 to D0041FFF (RO) U-Boot
Area 3:	D0042000 to D0251FFF      Kernel
Area 4:	D0252000 to D083FFFF      FS
In:    serial
Out:   serial
Err:   serial
Net:   macb0
macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1)
Hit any key to stop autoboot:  3 \b\b\b 2 \b\b\b 1 \b\b\b 0 
macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1)
Using macb0 device
TFTP from server 10.0.0.1; our IP address is 10.0.0.98
Filename 'rootfs'.
Load address: 0x22800000
Loading: *\b#########################################################
done
Bytes transferred = 822110 (c8b5e hex)
macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1)
Using macb0 device
TFTP from server 10.0.0.1; our IP address is 10.0.0.98
Filename 'uImage'.
Load address: 0x22200000
Loading: *\b#################################################################
	 ################################################
done
Bytes transferred = 1647948 (19254c hex)
## Booting kernel from Legacy Image at 22200000 ...
   Image Name:   Linux-2.6.30
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1647884 Bytes =  1.6 MB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux.......................................................................................................... done, booting the kernel.
Linux version 2.6.30 (grante at alpha) (gcc version 4.4.3 (crosstool-NG-1.6.1) ) #5 Fri Apr 16 16:55:29 CDT 2010
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Atmel AT91SAM9G20-EK
Memory policy: ECC disabled, Data cache writeback
Clocks: CPU 396 MHz, master 132 MHz, main 18.432 MHz
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: root=/dev/ram0 rw initrd=0x22800000,0xC8B5E
NR_IRQS:192
AT91: 96 gpio irqs in 3 banks
PID hash table entries: 256 (order: 8, 1024 bytes)
Console: colour dummy device 80x30
console [tty0] enabled
console [ttyS0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 60680KB available (2992K code, 266K data, 116K init, 0K highmem)
Calibrating delay loop... 197.83 BogoMIPS (lpj=989184)
Security Framework initialized
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 520 bytes
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 800K
NetWinder Floating Point Emulator V0.97 (double precision)
DLM (built Apr 16 2010 16:30:14) installed
JFFS2 version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
msgmni has been set to 120
alg: No test for cipher_null (cipher_null-generic)
alg: No test for ecb(cipher_null) (ecb-cipher_null)
alg: No test for digest_null (digest_null-generic)
alg: No test for compress_null (compress_null-generic)
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered (default)
atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL
atmel_usart.1: ttyS1 at MMIO 0xfffb0000 (irq = 6) is a ATMEL_SERIAL
atmel_usart.2: ttyS2 at MMIO 0xfffb4000 (irq = 7) is a ATMEL_SERIAL
brd: module loaded
loop: module loaded
ssc ssc.0: Atmel SSC device at 0xc4878000 (irq 14)
Driver 'sd' needs updating - please use bus_type methods
MACB_mii_bus: probed
eth0: Atmel MACB at 0xfffc4000 irq 21 (3a:1f:34:08:54:54)
eth0: attached PHY driver [Davicom DM9161A] (mii_bus:phy_addr=ffffffff:00, irq=-1)
NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bit)
AT91 NAND: 8-bit, Software ECC
Scanning device for bad blocks
Creating 3 MTD partitions on "atmel_nand":
0x000000000000-0x000000400000 : "Bootstrap"
0x000000400000-0x000004000000 : "Partition 1"
0x000004000000-0x000010000000 : "Partition 2"
usbmon: debugfs is not available
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
at91_ohci at91_ohci: AT91 OHCI
at91_ohci at91_ohci: new USB bus registered, assigned bus number 1
at91_ohci at91_ohci: irq 20, io mem 0x00500000
usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: AT91 OHCI
usb usb1: Manufacturer: Linux 2.6.30 ohci_hcd
usb usb1: SerialNumber: at91
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver usbserial
USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
udc: at91_udc version 3 May 2006
mice: PS/2 mouse device common for all mice
Registered led device: ds5
Registered led device: ds1
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
SCTP: Hash tables configured (established 2048 bind 4096)
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing init memory: 116K
Kernel panic - not syncing: Attempted to kill init!
Backtrace: 
[<c00296dc>] (dump_backtrace+0x0/0x114) from [<c02659e4>] (dump_stack+0x18/0x1c)
 r6:c3812c40 r5:0000000b r4:c0338314
[<c02659cc>] (dump_stack+0x0/0x1c) from [<c0265a34>] (panic+0x4c/0x114)
[<c02659e8>] (panic+0x0/0x114) from [<c003f06c>] (do_exit+0x74/0x5cc)
 r3:c03196ac r2:c3817e3c r1:00002710 r0:c02ccc39
[<c003eff8>] (do_exit+0x0/0x5cc) from [<c003f658>] (do_group_exit+0x94/0xc8)
[<c003f5c4>] (do_group_exit+0x0/0xc8) from [<c0048a90>] (get_signal_to_deliver+0x2f4/0x330)
 r4:00106001
[<c004879c>] (get_signal_to_deliver+0x0/0x330) from [<c0027e90>] (do_signal+0x5c/0x4b8)
[<c0027e34>] (do_signal+0x0/0x4b8) from [<c002831c>] (do_notify_resume+0x30/0x34)
[<c00282ec>] (do_notify_resume+0x0/0x34) from [<c0025dcc>] (work_pending+0x1c/0x20)


-- 
Grant Edwards               grant.b.edwards        Yow! This ASEXUAL PIG
                                  at               really BOILS my BLOOD
                              gmail.com            ... He's so ... so
                                                   ... URGENT!!

[Buildroot] Still can't build working rootfs with crosstool-NG toolchain

[Thomas Petazzoni]

Hello,

On Mon, 19 Apr 2010 14:44:30 +0000 (UTC)
Grant Edwards <grant.b.edwards@gmail.com> wrote:

> I've spend the past week trying to use crosstool-NG instead of
> buildroot to build a toolchain.  I had been using external buildroot
> toolchains for the past couple months with no problems. But, that is
> unsupported by buildroot, and I'm giving up fighting that battle.

Come on, it is *not* unsupported. We are trying to support it, but
facing issues.

> It doesn't seem to matter which toolchain I use to build the kernel, I
> get the same results with both kernels. I'm using an Atmel
> AT91SAM9G20EK development board, gcc 4.4.3, uClibc 0.9.30.2.

The problem might be related to OABI vs. EABI. What's the configuration
of the toolchain, the Buildroot configuration, and the kernel
configuration for this ?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Still can't build working rootfs with crosstool-NG toolchain

[Peter Korsgaard]

>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:

Hi,

 Grant> Any ideas on why a rootfs built using a crosstool-ng toolchain
 Grant> wouldn't work?   In general how does one troubleshoot kernel panics
 Grant> like this?

I would start simple - Does a boot using init=/bin/sh work? If not, does
a simple hello world program run?

 Grant>  * buildroot specifies abi=apcs-gnu, ct-NG doesn't

That sounds suspicions. apcs-gnu is ARM OABI, are you sure you have
enabled that in CT-NG? Any reason why you are not using EABI?

-- 
Bye, Peter Korsgaard

[Buildroot] Still can't build working rootfs with crosstool-NG toolchain

[Grant Edwards]

On 2010-04-19, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Mon, 19 Apr 2010 14:44:30 +0000 (UTC)
> Grant Edwards <grant.b.edwards@gmail.com> wrote:
>
>> I've spend the past week trying to use crosstool-NG instead of
>> buildroot to build a toolchain.  I had been using external buildroot
>> toolchains for the past couple months with no problems. But, that is
>> unsupported by buildroot, and I'm giving up fighting that battle.
>
> Come on, it is *not* unsupported. We are trying to support it, but
> facing issues.

I just meant that it doesn't currently work unless I maintain forked
versions of several .mk files (including ext-tool.mk).  I don't want
to do that anymore, so I'm trying to switch to ctNG and abandon my
forked files.

>> It doesn't seem to matter which toolchain I use to build the kernel, I
>> get the same results with both kernels. I'm using an Atmel
>> AT91SAM9G20EK development board, gcc 4.4.3, uClibc 0.9.30.2.
>
> The problem might be related to OABI vs. EABI. What's the
> configuration of the toolchain, the Buildroot configuration, and the
> kernel configuration for this ?

Doh.

It was indeed an OABI vs. EABI problem.  The problem was a result of
daisy-chaining several bits of my own stupidity together:

 1) At one point I had switched the buildroot toolchain to EABI, but
    somehow I switched it back either without knowing or without
    remembering.

 2) I had thought that using an EABI toolchain produced an EABI
    kernel, but it doesn't: there's a kernel configuration variable
    you have to set.  This resulted in my mistaken belief that my
    kernel was EABI and my misinterpreting some testing that I did in
    an attempt to confirm that both toolchains were EABI.

 3) I had a downloaded an EABI kernel uImage file to use for testing
    and didn't realize it had backwards OABI compatibility enabled --
    causing me to stumble even further down the path of believing all
    my different kernels, root filesystems, and toolchains were EABI.

It's all painfully obvious now...
    
-- 
Grant Edwards               grant.b.edwards        Yow! ... My pants just went
                                  at               on a wild rampage through a
                              gmail.com            Long Island Bowling Alley!!

[Buildroot] Still can't build working rootfs with crosstool-NG toolchain

[Grant Edwards]

On 2010-04-19, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:
>
> Grant> Any ideas on why a rootfs built using a crosstool-ng toolchain
> Grant> wouldn't work?   In general how does one troubleshoot kernel panics
> Grant> like this?
>
> I would start simple - Does a boot using init=/bin/sh work? If not,
> does a simple hello world program run?
>
> Grant>  * buildroot specifies abi=apcs-gnu, ct-NG doesn't
>
> That sounds suspicions. apcs-gnu is ARM OABI, 

Indeed, that was the issue.  I mistakenly thought my kernel was EABI,
and that both my toolchains were EABI, and didn't realize that
apcs-gnu meant ARM OABI.

> are you sure you have enabled that in CT-NG?
> Any reason why you are not using EABI?

I starting using a default config from Atmel that was OABI.  I 
switched to EABI, but at some point had switched back (and either
didn't know or forgot).

Everything really is EABI now, and things are working again.

-- 
Grant Edwards               grant.b.edwards        Yow! Did I SELL OUT yet??
                                  at               
                              gmail.com            

[Buildroot] Still can't build working rootfs with crosstool-NGtoolchain

[Microbit_P43000]

Hi Grant et al,

I joined this group some time ago to ask a couple of things about BR2, but just didn't
seem to get 'round it yet, because I wanted to first document my query much better.
Thought it was time I at least asked a prelim anyway, considering all the traffic here :-)

The last version of BR2 I've been using was 2009.11 under Ubuntu.
I haven't tried newer versions anymore, because I'd first like to ask what exactly is
going amok....
I've time & again experienced frustration with unnecessary complete "rebuilds" of the
internal toolchain. Even after upgrading to C++ build of 4.3.3 of toolchain and what not,
still the same quircks to some extent :

At times I'll change a simple option in eg. Busybox and when I recompile (well, remake)
from the actual BR "root" menu, it suddenly decides to start rebuilding the whole bloody
environment ?
All in all that's not so bad - but just about each time that happens some runtime mayhem
occurs wrt
to the Nano package. (I like Nano, and I really don't want to turn it off if it can be
helped).

When I run my target (SAM7L9260), regardless of kernel version, invoking Nano will throw
this error :
" __aeabi_idiv cannot be resolved " or some such.
I spent a great deal of time quite a while ago to try to get to the bottom of it but never
did.... =>
That hidden symbol isn't a problem at all for the initial build (ie. BR2 from scratch).
Just only when suddenly the smallest change in busybox will trigger BR2 to rebuild GCC ARM
cross compiler nano is broken at runtime on my target.
The whole (re)make process doesn't issue any obvious errors over those hidden symbols, nor
does the rebuild of toolchain, busybox, ucLib or rootfs.

Other notes :
i) When for example changing a small option in Busybox - even remaking busybox from within
its own
directory and _then_ remaking from the BR2 root (so my rootfs is updated) will still cause
the rebuild of internal toolchain, regardless (if and when that complete rebuild of BR2
occurs).

ii) I am aware that BR's build process doesn't readily allow to rebuild BR itself when a
package is removed because of the way things are tracked in make.
The problem I get does NOT involve changes to one of BR2's packages itself. It's only
small changes to eg. busybox.

iii) I persisted for quite some time to find the problem on my own, also thinking I was
making a mistake myself, but I don't think so. I've recently found that it's just easier
(and faster in the long run) to completely wipe BR2 and remake everything from scratch.
That ensures things behave again.

iv) I did notice there were some apparent issues with Nano, because earlier versions of BR
2009.xx
incorrectly removed the Nano option from the main setup menu when "hide Busybox..." option
was checked.  That seems to have been fixed in the more recent versions I tried. Perhaps
still something there ?? dunno.

Q :
Does anyone know if this is a common problem, and if so what I can do to work around it or
avoid this frustration ?
In more recent times, I've tried creating my rootfs with external toolchains but that
seems to come with its own challenges all right as well...

I've long hesitated to post about this as not to bug anyone, but when I saw Grant's
trouble fighting some issues, I thought now might be a good time - since when veterans can
struggle with some BR problem, surely I can too :-). I still consider myself a newbie
although I've been studying Embedded Linux for almost a year now.

Best Regards,
Kris 

> -----Original Message-----
> From: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] On Behalf Of
> Grant Edwards
> Sent: Tuesday, 20 April 2010 12:44 AM
> To: buildroot at uclibc.org
> Subject: [Buildroot] Still can't build working rootfs with crosstool-NGtoolchain
> 
> I've spend the past week trying to use crosstool-NG instead of
> buildroot to build a toolchain.  I had been using external buildroot
> toolchains for the past couple months with no problems. But, that is
> unsupported by buildroot, and I'm giving up fighting that battle.
> 
> With crosstool-NG I can build a toolchain fine, and I can use it to
> build kernels and root filesystems, but when I use a root filesystem
> built with the crosstool-NG toolchain, I get a kernel panic
> immediately folloing the mounting of the root filesystem.
> 
> A rootfs built by the buildroot toolchain works fine.
> 
> It's the same gcc and uClibc versions in both cases and the same
> buildroot/rootfs settings.
> 
> It doesn't seem to matter which toolchain I use to build the kernel, I
> get the same results with both kernels. I'm using an Atmel
> AT91SAM9G20EK development board, gcc 4.4.3, uClibc 0.9.30.2.
> 
> Below the log of a failed startupt.  The log of a successful startup
> using a buildroot-toolchain rootfs is identical except for two things:
> 
>   1) The successfull rootfs is 20K larger, so a few of the lines with
>      memory size diagnostics are different.
> 
>   2) Instead of a kernel panic, I get welcome message and login
>      prompt when using the buildroot toolchain.
> 
> Any ideas on why a rootfs built using a crosstool-ng toolchain
> wouldn't work?   In general how does one troubleshoot kernel panics
> like this?
> 
> Differences I can see in the toolchain configurations:
> 
>  * ct-NG uses cloog/ppl, buildroot doesn't
> 
>  * ct-NG enables __cxa_atexit, buildroot doesn't.
> 
>  * ct-NG enables c99, buildroot doesn't.
> 
>  * ct-NG enables long-long, buildroot doesn't.
> 
>  * ct-NG uses --enable-threads=posix, buildroot is just --enable-threads
> 
>  * buildroot specifies armv5te/arm9tdmi, ct-NG doesn't
> 
>  * buildroot specifies abi=apcs-gnu, ct-NG doesn't
> 
> 
> My ct-NG config is based on one of the "working samples" provided with
> ct-NG.
> 
> All ideas/suggestions welcome...
> 
> 
> ------------------------------------------------------------------------
> RomBOOT
> 
> 
> U-Boot 1.3.4 (Jan  6 2010 - 15:52:13)
> 
> DRAM:  64 MB
> NAND:  256 MiB
> DataFlash:AT45DB642
> Nb pages:   8192
> Page Size:   1056
> Size= 8650752 bytes
> Logical address: 0xD0000000
> Area 0:	D0000000 to D00041FF (RO) Bootstrap
> Area 1:	D0004200 to D00083FF      Environment
> Area 2:	D0008400 to D0041FFF (RO) U-Boot
> Area 3:	D0042000 to D0251FFF      Kernel
> Area 4:	D0252000 to D083FFFF      FS
> In:    serial
> Out:   serial
> Err:   serial
> Net:   macb0
> macb0: Starting autonegotiation...
> macb0: Autonegotiation complete
> macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1)
> Hit any key to stop autoboot:  3 \b\b\b 2 \b\b\b 1 \b\b\b 0
> macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1)
> Using macb0 device
> TFTP from server 10.0.0.1; our IP address is 10.0.0.98
> Filename 'rootfs'.
> Load address: 0x22800000
> Loading: *\b#########################################################
> done
> Bytes transferred = 822110 (c8b5e hex)
> macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1)
> Using macb0 device
> TFTP from server 10.0.0.1; our IP address is 10.0.0.98
> Filename 'uImage'.
> Load address: 0x22200000
> Loading: *\b#################################################################
> 	 ################################################
> done
> Bytes transferred = 1647948 (19254c hex)
> ## Booting kernel from Legacy Image at 22200000 ...
>    Image Name:   Linux-2.6.30
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    1647884 Bytes =  1.6 MB
>    Load Address: 20008000
>    Entry Point:  20008000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> OK
> 
> Starting kernel ...
> 
> Uncompressing
Linux.....................................................................................
..................... done,
> booting the kernel.
> Linux version 2.6.30 (grante at alpha) (gcc version 4.4.3 (crosstool-NG-1.6.1) ) #5 Fri Apr
16
> 16:55:29 CDT 2010
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
> CPU: VIVT data cache, VIVT instruction cache
> Machine: Atmel AT91SAM9G20-EK
> Memory policy: ECC disabled, Data cache writeback
> Clocks: CPU 396 MHz, master 132 MHz, main 18.432 MHz
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
> Kernel command line: root=/dev/ram0 rw initrd=0x22800000,0xC8B5E
> NR_IRQS:192
> AT91: 96 gpio irqs in 3 banks
> PID hash table entries: 256 (order: 8, 1024 bytes)
> Console: colour dummy device 80x30
> console [tty0] enabled
> console [ttyS0] enabled
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Memory: 64MB = 64MB total
> Memory: 60680KB available (2992K code, 266K data, 116K init, 0K highmem)
> Calibrating delay loop... 197.83 BogoMIPS (lpj=989184)
> Security Framework initialized
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> net_namespace: 520 bytes
> NET: Registered protocol family 16
> bio: create slab <bio-0> at 0
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 2048 (order: 2, 16384 bytes)
> TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
> TCP: Hash tables configured (established 2048 bind 2048)
> TCP reno registered
> NET: Registered protocol family 1
> Trying to unpack rootfs image as initramfs...
> rootfs image is not initramfs (no cpio magic); looks like an initrd
> Freeing initrd memory: 800K
> NetWinder Floating Point Emulator V0.97 (double precision)
> DLM (built Apr 16 2010 16:30:14) installed
> JFFS2 version 2.2. (NAND) B) 2001-2006 Red Hat, Inc.
> msgmni has been set to 120
> alg: No test for cipher_null (cipher_null-generic)
> alg: No test for ecb(cipher_null) (ecb-cipher_null)
> alg: No test for digest_null (digest_null-generic)
> alg: No test for compress_null (compress_null-generic)
> alg: No test for stdrng (krng)
> io scheduler noop registered
> io scheduler anticipatory registered (default)
> atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL
> atmel_usart.1: ttyS1 at MMIO 0xfffb0000 (irq = 6) is a ATMEL_SERIAL
> atmel_usart.2: ttyS2 at MMIO 0xfffb4000 (irq = 7) is a ATMEL_SERIAL
> brd: module loaded
> loop: module loaded
> ssc ssc.0: Atmel SSC device at 0xc4878000 (irq 14)
> Driver 'sd' needs updating - please use bus_type methods
> MACB_mii_bus: probed
> eth0: Atmel MACB at 0xfffc4000 irq 21 (3a:1f:34:08:54:54)
> eth0: attached PHY driver [Davicom DM9161A] (mii_bus:phy_addr=ffffffff:00, irq=-1)
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bit)
> AT91 NAND: 8-bit, Software ECC
> Scanning device for bad blocks
> Creating 3 MTD partitions on "atmel_nand":
> 0x000000000000-0x000000400000 : "Bootstrap"
> 0x000000400000-0x000004000000 : "Partition 1"
> 0x000004000000-0x000010000000 : "Partition 2"
> usbmon: debugfs is not available
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> at91_ohci at91_ohci: AT91 OHCI
> at91_ohci at91_ohci: new USB bus registered, assigned bus number 1
> at91_ohci at91_ohci: irq 20, io mem 0x00500000
> usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb1: Product: AT91 OHCI
> usb usb1: Manufacturer: Linux 2.6.30 ohci_hcd
> usb usb1: SerialNumber: at91
> usb usb1: configuration #1 chosen from 1 choice
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 2 ports detected
> Initializing USB Mass Storage driver...
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> usbcore: registered new interface driver usbserial
> USB Serial support registered for generic
> usbcore: registered new interface driver usbserial_generic
> usbserial: USB Serial Driver core
> udc: at91_udc version 3 May 2006
> mice: PS/2 mouse device common for all mice
> Registered led device: ds5
> Registered led device: ds1
> TCP cubic registered
> NET: Registered protocol family 17
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> SCTP: Hash tables configured (established 2048 bind 4096)
> drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
> RAMDISK: gzip image found at block 0
> VFS: Mounted root (ext2 filesystem) on device 1:0.
> Freeing init memory: 116K
> Kernel panic - not syncing: Attempted to kill init!
> Backtrace:
> [<c00296dc>] (dump_backtrace+0x0/0x114) from [<c02659e4>] (dump_stack+0x18/0x1c)
>  r6:c3812c40 r5:0000000b r4:c0338314
> [<c02659cc>] (dump_stack+0x0/0x1c) from [<c0265a34>] (panic+0x4c/0x114)
> [<c02659e8>] (panic+0x0/0x114) from [<c003f06c>] (do_exit+0x74/0x5cc)
>  r3:c03196ac r2:c3817e3c r1:00002710 r0:c02ccc39
> [<c003eff8>] (do_exit+0x0/0x5cc) from [<c003f658>] (do_group_exit+0x94/0xc8)
> [<c003f5c4>] (do_group_exit+0x0/0xc8) from [<c0048a90>]
(get_signal_to_deliver+0x2f4/0x330)
>  r4:00106001
> [<c004879c>] (get_signal_to_deliver+0x0/0x330) from [<c0027e90>] (do_signal+0x5c/0x4b8)
> [<c0027e34>] (do_signal+0x0/0x4b8) from [<c002831c>] (do_notify_resume+0x30/0x34)
> [<c00282ec>] (do_notify_resume+0x0/0x34) from [<c0025dcc>] (work_pending+0x1c/0x20)
> 
> 
> --
> Grant Edwards               grant.b.edwards        Yow! This ASEXUAL PIG
>                                   at               really BOILS my BLOOD
>                               gmail.com            ... He's so ... so
>                                                    ... URGENT!!

[Buildroot] Still can't build working rootfs with crosstool-NGtoolchain

[Ben Kloosterman]

Im all new to this so treat this with a grain of salt. 

But since for arm, there is no %/divide instruction,
a call to __umodsi3/__aeabi_uidiv is used.

Not sure where this lib is but your missing some lib , maybe  the uClib
extended float support ? 


 >-----Original Message-----
 >From: buildroot-bounces at busybox.net [mailto:buildroot-
 >bounces at busybox.net] On Behalf Of Microbit_P43000
 >Sent: Wednesday, April 21, 2010 2:26 AM
 >To: 'Grant Edwards'; buildroot at uclibc.org
 >Subject: Re: [Buildroot] Still can't build working rootfs with
 >crosstool-NGtoolchain
 >
 >Hi Grant et al,
 >
 >I joined this group some time ago to ask a couple of things about BR2,
 >but just didn't
 >seem to get 'round it yet, because I wanted to first document my query
 >much better.
 >Thought it was time I at least asked a prelim anyway, considering all
 >the traffic here :-)
 >
 >The last version of BR2 I've been using was 2009.11 under Ubuntu.
 >I haven't tried newer versions anymore, because I'd first like to ask
 >what exactly is
 >going amok....
 >I've time & again experienced frustration with unnecessary complete
 >"rebuilds" of the
 >internal toolchain. Even after upgrading to C++ build of 4.3.3 of
 >toolchain and what not,
 >still the same quircks to some extent :
 >
 >At times I'll change a simple option in eg. Busybox and when I recompile
 >(well, remake)
 >from the actual BR "root" menu, it suddenly decides to start rebuilding
 >the whole bloody
 >environment ?
 >All in all that's not so bad - but just about each time that happens
 >some runtime mayhem
 >occurs wrt
 >to the Nano package. (I like Nano, and I really don't want to turn it
 >off if it can be
 >helped).
 >
 >When I run my target (SAM7L9260), regardless of kernel version, invoking
 >Nano will throw
 >this error :
 >" __aeabi_idiv cannot be resolved " or some such.
 >I spent a great deal of time quite a while ago to try to get to the
 >bottom of it but never
 >did.... =>
 >That hidden symbol isn't a problem at all for the initial build (ie. BR2
 >from scratch).
 >Just only when suddenly the smallest change in busybox will trigger BR2
 >to rebuild GCC ARM
 >cross compiler nano is broken at runtime on my target.
 >The whole (re)make process doesn't issue any obvious errors over those
 >hidden symbols, nor
 >does the rebuild of toolchain, busybox, ucLib or rootfs.
 >
 >Other notes :
 >i) When for example changing a small option in Busybox - even remaking
 >busybox from within
 >its own
 >directory and _then_ remaking from the BR2 root (so my rootfs is
 >updated) will still cause
 >the rebuild of internal toolchain, regardless (if and when that complete
 >rebuild of BR2
 >occurs).
 >
 >ii) I am aware that BR's build process doesn't readily allow to rebuild
 >BR itself when a
 >package is removed because of the way things are tracked in make.
 >The problem I get does NOT involve changes to one of BR2's packages
 >itself. It's only
 >small changes to eg. busybox.
 >
 >iii) I persisted for quite some time to find the problem on my own, also
 >thinking I was
 >making a mistake myself, but I don't think so. I've recently found that
 >it's just easier
 >(and faster in the long run) to completely wipe BR2 and remake
 >everything from scratch.
 >That ensures things behave again.
 >
 >iv) I did notice there were some apparent issues with Nano, because
 >earlier versions of BR
 >2009.xx
 >incorrectly removed the Nano option from the main setup menu when "hide
 >Busybox..." option
 >was checked.  That seems to have been fixed in the more recent versions
 >I tried. Perhaps
 >still something there ?? dunno.
 >
 >Q :
 >Does anyone know if this is a common problem, and if so what I can do to
 >work around it or
 >avoid this frustration ?
 >In more recent times, I've tried creating my rootfs with external
 >toolchains but that
 >seems to come with its own challenges all right as well...
 >
 >I've long hesitated to post about this as not to bug anyone, but when I
 >saw Grant's
 >trouble fighting some issues, I thought now might be a good time - since
 >when veterans can
 >struggle with some BR problem, surely I can too :-). I still consider
 >myself a newbie
 >although I've been studying Embedded Linux for almost a year now.
 >
 >Best Regards,
 >Kris
 >
 >> -----Original Message-----
 >> From: buildroot-bounces at busybox.net [mailto:buildroot-
 >bounces at busybox.net] On Behalf Of
 >> Grant Edwards
 >> Sent: Tuesday, 20 April 2010 12:44 AM
 >> To: buildroot at uclibc.org
 >> Subject: [Buildroot] Still can't build working rootfs with crosstool-
 >NGtoolchain
 >>
 >> I've spend the past week trying to use crosstool-NG instead of
 >> buildroot to build a toolchain.  I had been using external buildroot
 >> toolchains for the past couple months with no problems. But, that is
 >> unsupported by buildroot, and I'm giving up fighting that battle.
 >>
 >> With crosstool-NG I can build a toolchain fine, and I can use it to
 >> build kernels and root filesystems, but when I use a root filesystem
 >> built with the crosstool-NG toolchain, I get a kernel panic
 >> immediately folloing the mounting of the root filesystem.
 >>
 >> A rootfs built by the buildroot toolchain works fine.
 >>
 >> It's the same gcc and uClibc versions in both cases and the same
 >> buildroot/rootfs settings.
 >>
 >> It doesn't seem to matter which toolchain I use to build the kernel, I
 >> get the same results with both kernels. I'm using an Atmel
 >> AT91SAM9G20EK development board, gcc 4.4.3, uClibc 0.9.30.2.
 >>
 >> Below the log of a failed startupt.  The log of a successful startup
 >> using a buildroot-toolchain rootfs is identical except for two things:
 >>
 >>   1) The successfull rootfs is 20K larger, so a few of the lines with
 >>      memory size diagnostics are different.
 >>
 >>   2) Instead of a kernel panic, I get welcome message and login
 >>      prompt when using the buildroot toolchain.
 >>
 >> Any ideas on why a rootfs built using a crosstool-ng toolchain
 >> wouldn't work?   In general how does one troubleshoot kernel panics
 >> like this?
 >>
 >> Differences I can see in the toolchain configurations:
 >>
 >>  * ct-NG uses cloog/ppl, buildroot doesn't
 >>
 >>  * ct-NG enables __cxa_atexit, buildroot doesn't.
 >>
 >>  * ct-NG enables c99, buildroot doesn't.
 >>
 >>  * ct-NG enables long-long, buildroot doesn't.
 >>
 >>  * ct-NG uses --enable-threads=posix, buildroot is just --enable-
 >threads
 >>
 >>  * buildroot specifies armv5te/arm9tdmi, ct-NG doesn't
 >>
 >>  * buildroot specifies abi=apcs-gnu, ct-NG doesn't
 >>
 >>
 >> My ct-NG config is based on one of the "working samples" provided with
 >> ct-NG.
 >>
 >> All ideas/suggestions welcome...
 >>
 >>
 >> ----------------------------------------------------------------------
 >--
 >> RomBOOT
 >>
 >>
 >> U-Boot 1.3.4 (Jan  6 2010 - 15:52:13)
 >>
 >> DRAM:  64 MB
 >> NAND:  256 MiB
 >> DataFlash:AT45DB642
 >> Nb pages:   8192
 >> Page Size:   1056
 >> Size= 8650752 bytes
 >> Logical address: 0xD0000000
 >> Area 0:	D0000000 to D00041FF (RO) Bootstrap
 >> Area 1:	D0004200 to D00083FF      Environment
 >> Area 2:	D0008400 to D0041FFF (RO) U-Boot
 >> Area 3:	D0042000 to D0251FFF      Kernel
 >> Area 4:	D0252000 to D083FFFF      FS
 >> In:    serial
 >> Out:   serial
 >> Err:   serial
 >> Net:   macb0
 >> macb0: Starting autonegotiation...
 >> macb0: Autonegotiation complete
 >> macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1)
 >> Hit any key to stop autoboot:  3 \b\b\b 2 \b\b\b 1 \b\b\b 0
 >> macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1)
 >> Using macb0 device
 >> TFTP from server 10.0.0.1; our IP address is 10.0.0.98
 >> Filename 'rootfs'.
 >> Load address: 0x22800000
 >> Loading: *\b#########################################################
 >> done
 >> Bytes transferred = 822110 (c8b5e hex)
 >> macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1)
 >> Using macb0 device
 >> TFTP from server 10.0.0.1; our IP address is 10.0.0.98
 >> Filename 'uImage'.
 >> Load address: 0x22200000
 >> Loading:
 >*\b#################################################################
 >> 	 ################################################
 >> done
 >> Bytes transferred = 1647948 (19254c hex)
 >> ## Booting kernel from Legacy Image at 22200000 ...
 >>    Image Name:   Linux-2.6.30
 >>    Image Type:   ARM Linux Kernel Image (uncompressed)
 >>    Data Size:    1647884 Bytes =  1.6 MB
 >>    Load Address: 20008000
 >>    Entry Point:  20008000
 >>    Verifying Checksum ... OK
 >>    Loading Kernel Image ... OK
 >> OK
 >>
 >> Starting kernel ...
 >>
 >> Uncompressing
 >Linux...................................................................
 >..................
 >..................... done,
 >> booting the kernel.
 >> Linux version 2.6.30 (grante at alpha) (gcc version 4.4.3 (crosstool-NG-
 >1.6.1) ) #5 Fri Apr
 >16
 >> 16:55:29 CDT 2010
 >> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
 >> CPU: VIVT data cache, VIVT instruction cache
 >> Machine: Atmel AT91SAM9G20-EK
 >> Memory policy: ECC disabled, Data cache writeback
 >> Clocks: CPU 396 MHz, master 132 MHz, main 18.432 MHz
 >> Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
 >16256
 >> Kernel command line: root=/dev/ram0 rw initrd=0x22800000,0xC8B5E
 >> NR_IRQS:192
 >> AT91: 96 gpio irqs in 3 banks
 >> PID hash table entries: 256 (order: 8, 1024 bytes)
 >> Console: colour dummy device 80x30
 >> console [tty0] enabled
 >> console [ttyS0] enabled
 >> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
 >> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
 >> Memory: 64MB = 64MB total
 >> Memory: 60680KB available (2992K code, 266K data, 116K init, 0K
 >highmem)
 >> Calibrating delay loop... 197.83 BogoMIPS (lpj=989184)
 >> Security Framework initialized
 >> Mount-cache hash table entries: 512
 >> CPU: Testing write buffer coherency: ok
 >> net_namespace: 520 bytes
 >> NET: Registered protocol family 16
 >> bio: create slab <bio-0> at 0
 >> SCSI subsystem initialized
 >> usbcore: registered new interface driver usbfs
 >> usbcore: registered new interface driver hub
 >> usbcore: registered new device driver usb
 >> NET: Registered protocol family 2
 >> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
 >> TCP established hash table entries: 2048 (order: 2, 16384 bytes)
 >> TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
 >> TCP: Hash tables configured (established 2048 bind 2048)
 >> TCP reno registered
 >> NET: Registered protocol family 1
 >> Trying to unpack rootfs image as initramfs...
 >> rootfs image is not initramfs (no cpio magic); looks like an initrd
 >> Freeing initrd memory: 800K
 >> NetWinder Floating Point Emulator V0.97 (double precision)
 >> DLM (built Apr 16 2010 16:30:14) installed
 >> JFFS2 version 2.2. (NAND) B) 2001-2006 Red Hat, Inc.
 >> msgmni has been set to 120
 >> alg: No test for cipher_null (cipher_null-generic)
 >> alg: No test for ecb(cipher_null) (ecb-cipher_null)
 >> alg: No test for digest_null (digest_null-generic)
 >> alg: No test for compress_null (compress_null-generic)
 >> alg: No test for stdrng (krng)
 >> io scheduler noop registered
 >> io scheduler anticipatory registered (default)
 >> atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL
 >> atmel_usart.1: ttyS1 at MMIO 0xfffb0000 (irq = 6) is a ATMEL_SERIAL
 >> atmel_usart.2: ttyS2 at MMIO 0xfffb4000 (irq = 7) is a ATMEL_SERIAL
 >> brd: module loaded
 >> loop: module loaded
 >> ssc ssc.0: Atmel SSC device at 0xc4878000 (irq 14)
 >> Driver 'sd' needs updating - please use bus_type methods
 >> MACB_mii_bus: probed
 >> eth0: Atmel MACB at 0xfffc4000 irq 21 (3a:1f:34:08:54:54)
 >> eth0: attached PHY driver [Davicom DM9161A]
 >(mii_bus:phy_addr=ffffffff:00, irq=-1)
 >> NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB
 >3,3V 8-bit)
 >> AT91 NAND: 8-bit, Software ECC
 >> Scanning device for bad blocks
 >> Creating 3 MTD partitions on "atmel_nand":
 >> 0x000000000000-0x000000400000 : "Bootstrap"
 >> 0x000000400000-0x000004000000 : "Partition 1"
 >> 0x000004000000-0x000010000000 : "Partition 2"
 >> usbmon: debugfs is not available
 >> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
 >> at91_ohci at91_ohci: AT91 OHCI
 >> at91_ohci at91_ohci: new USB bus registered, assigned bus number 1
 >> at91_ohci at91_ohci: irq 20, io mem 0x00500000
 >> usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
 >> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
 >> usb usb1: Product: AT91 OHCI
 >> usb usb1: Manufacturer: Linux 2.6.30 ohci_hcd
 >> usb usb1: SerialNumber: at91
 >> usb usb1: configuration #1 chosen from 1 choice
 >> hub 1-0:1.0: USB hub found
 >> hub 1-0:1.0: 2 ports detected
 >> Initializing USB Mass Storage driver...
 >> usbcore: registered new interface driver usb-storage
 >> USB Mass Storage support registered.
 >> usbcore: registered new interface driver usbserial
 >> USB Serial support registered for generic
 >> usbcore: registered new interface driver usbserial_generic
 >> usbserial: USB Serial Driver core
 >> udc: at91_udc version 3 May 2006
 >> mice: PS/2 mouse device common for all mice
 >> Registered led device: ds5
 >> Registered led device: ds1
 >> TCP cubic registered
 >> NET: Registered protocol family 17
 >> RPC: Registered udp transport module.
 >> RPC: Registered tcp transport module.
 >> SCTP: Hash tables configured (established 2048 bind 4096)
 >> drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
 >> RAMDISK: gzip image found at block 0
 >> VFS: Mounted root (ext2 filesystem) on device 1:0.
 >> Freeing init memory: 116K
 >> Kernel panic - not syncing: Attempted to kill init!
 >> Backtrace:
 >> [<c00296dc>] (dump_backtrace+0x0/0x114) from [<c02659e4>]
 >(dump_stack+0x18/0x1c)
 >>  r6:c3812c40 r5:0000000b r4:c0338314
 >> [<c02659cc>] (dump_stack+0x0/0x1c) from [<c0265a34>]
 >(panic+0x4c/0x114)
 >> [<c02659e8>] (panic+0x0/0x114) from [<c003f06c>] (do_exit+0x74/0x5cc)
 >>  r3:c03196ac r2:c3817e3c r1:00002710 r0:c02ccc39
 >> [<c003eff8>] (do_exit+0x0/0x5cc) from [<c003f658>]
 >(do_group_exit+0x94/0xc8)
 >> [<c003f5c4>] (do_group_exit+0x0/0xc8) from [<c0048a90>]
 >(get_signal_to_deliver+0x2f4/0x330)
 >>  r4:00106001
 >> [<c004879c>] (get_signal_to_deliver+0x0/0x330) from [<c0027e90>]
 >(do_signal+0x5c/0x4b8)
 >> [<c0027e34>] (do_signal+0x0/0x4b8) from [<c002831c>]
 >(do_notify_resume+0x30/0x34)
 >> [<c00282ec>] (do_notify_resume+0x0/0x34) from [<c0025dcc>]
 >(work_pending+0x1c/0x20)
 >>
 >>
 >> --
 >> Grant Edwards               grant.b.edwards        Yow! This ASEXUAL
 >PIG
 >>                                   at               really BOILS my
 >BLOOD
 >>                               gmail.com            ... He's so ... so
 >>                                                    ... URGENT!!
 >
 >
 >_______________________________________________
 >buildroot mailing list
 >buildroot at busybox.net
 >http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Still can't build working rootfs with crosstool-NGtoolchain

[Microbit_P43000]

Hi Ben,

Thanks for reviewing !   .... sigh .... I wish it were that simple...

It's a while ago I've been through this - but the common denominator of course is the fact
that the lib is dynamically linked.
The config of float/lib is just fine - it compiles on a fresh install - or consequent
builds for my rootfs, Nano runs perfect - no problemo.

I just couldn't pin down _what_ exactly triggers BR2 to "remake" itself completely.
It mostly would happen *after* I change a simple option in Busybox - of all things. How
exactly does that warrant RE-building the whole install (incl internal toolchain) ???
The GCC cross compiler is rebuilt, ucLib and so on and on.
It's as if the timestamps are perceived "wrong" by the make file and it behaves as if it
were a fresh install, except it's not. Sometimes you can mimick the behaviour by doing a
complete clean from BR2's root dir. Then rebuild everything and BANG.

When I checked last with 2009.11, the __aeabi_uidiv & _idiv symbols show up exactly the
same in the object dump. The lib itself 'appears' fine. The hidden symbol is still
"there".
And yet, at runtime on the target the only affected executable is Nano.
I've tried just about everything - even as desperate as fiddling with the stamps (force
Readonly), so they can't be removed and a global re-make is done... no avail, nope. It's
nuts.

Once that complete make has run again, the ONLY way (so far) to get Nano to function again
is to wipe the whole bloody root dir BR-2009.11. Then start the complete build from
scratch again.

If anyone might recognise this behaviour, I'd get it all running again and re-inspect. I
did ftraces and what not. I just couldn't figure where exactly the runtime error is wrt
not being able to dynamically link in that ASM func for idiv/uidiv.........

Best Regards,
Kris 

> -----Original Message-----
> From: Ben Kloosterman [mailto:bklooste at gmail.com]
> Sent: Wednesday, 21 April 2010 9:43 AM
> To: 'Microbit_P43000'; 'Grant Edwards'; buildroot at uclibc.org
> Subject: RE: [Buildroot] Still can't build working rootfs with crosstool-NGtoolchain
> 
> Im all new to this so treat this with a grain of salt.
> 
> But since for arm, there is no %/divide instruction,
> a call to __umodsi3/__aeabi_uidiv is used.
> 
> Not sure where this lib is but your missing some lib , maybe  the uClib
> extended float support ?
> 
> 
>  >-----Original Message-----
>  >From: buildroot-bounces at busybox.net [mailto:buildroot-
>  >bounces at busybox.net] On Behalf Of Microbit_P43000
>  >Sent: Wednesday, April 21, 2010 2:26 AM
>  >To: 'Grant Edwards'; buildroot at uclibc.org
>  >Subject: Re: [Buildroot] Still can't build working rootfs with
>  >crosstool-NGtoolchain
>  >
>  >Hi Grant et al,
>  >
>  >I joined this group some time ago to ask a couple of things about BR2,
>  >but just didn't
>  >seem to get 'round it yet, because I wanted to first document my query
>  >much better.
>  >Thought it was time I at least asked a prelim anyway, considering all
>  >the traffic here :-)
>  >
>  >The last version of BR2 I've been using was 2009.11 under Ubuntu.
>  >I haven't tried newer versions anymore, because I'd first like to ask
>  >what exactly is
>  >going amok....
>  >I've time & again experienced frustration with unnecessary complete
>  >"rebuilds" of the
>  >internal toolchain. Even after upgrading to C++ build of 4.3.3 of
>  >toolchain and what not,
>  >still the same quircks to some extent :
>  >
>  >At times I'll change a simple option in eg. Busybox and when I recompile
>  >(well, remake)
>  >from the actual BR "root" menu, it suddenly decides to start rebuilding
>  >the whole bloody
>  >environment ?
>  >All in all that's not so bad - but just about each time that happens
>  >some runtime mayhem
>  >occurs wrt
>  >to the Nano package. (I like Nano, and I really don't want to turn it
>  >off if it can be
>  >helped).
>  >
>  >When I run my target (SAM7L9260), regardless of kernel version, invoking
>  >Nano will throw
>  >this error :
>  >" __aeabi_idiv cannot be resolved " or some such.
>  >I spent a great deal of time quite a while ago to try to get to the
>  >bottom of it but never
>  >did.... =>
>  >That hidden symbol isn't a problem at all for the initial build (ie. BR2
>  >from scratch).
>  >Just only when suddenly the smallest change in busybox will trigger BR2
>  >to rebuild GCC ARM
>  >cross compiler nano is broken at runtime on my target.
>  >The whole (re)make process doesn't issue any obvious errors over those
>  >hidden symbols, nor
>  >does the rebuild of toolchain, busybox, ucLib or rootfs.
>  >
>  >Other notes :
>  >i) When for example changing a small option in Busybox - even remaking
>  >busybox from within
>  >its own
>  >directory and _then_ remaking from the BR2 root (so my rootfs is
>  >updated) will still cause
>  >the rebuild of internal toolchain, regardless (if and when that complete
>  >rebuild of BR2
>  >occurs).
>  >
>  >ii) I am aware that BR's build process doesn't readily allow to rebuild
>  >BR itself when a
>  >package is removed because of the way things are tracked in make.
>  >The problem I get does NOT involve changes to one of BR2's packages
>  >itself. It's only
>  >small changes to eg. busybox.
>  >
>  >iii) I persisted for quite some time to find the problem on my own, also
>  >thinking I was
>  >making a mistake myself, but I don't think so. I've recently found that
>  >it's just easier
>  >(and faster in the long run) to completely wipe BR2 and remake
>  >everything from scratch.
>  >That ensures things behave again.
>  >
>  >iv) I did notice there were some apparent issues with Nano, because
>  >earlier versions of BR
>  >2009.xx
>  >incorrectly removed the Nano option from the main setup menu when "hide
>  >Busybox..." option
>  >was checked.  That seems to have been fixed in the more recent versions
>  >I tried. Perhaps
>  >still something there ?? dunno.
>  >
>  >Q :
>  >Does anyone know if this is a common problem, and if so what I can do to
>  >work around it or
>  >avoid this frustration ?
>  >In more recent times, I've tried creating my rootfs with external
>  >toolchains but that
>  >seems to come with its own challenges all right as well...
>  >
>  >I've long hesitated to post about this as not to bug anyone, but when I
>  >saw Grant's
>  >trouble fighting some issues, I thought now might be a good time - since
>  >when veterans can
>  >struggle with some BR problem, surely I can too :-). I still consider
>  >myself a newbie
>  >although I've been studying Embedded Linux for almost a year now.
>  >
>  >Best Regards,
>  >Kris
>  >
>  >> -----Original Message-----
>  >> From: buildroot-bounces at busybox.net [mailto:buildroot-
>  >bounces at busybox.net] On Behalf Of
>  >> Grant Edwards
>  >> Sent: Tuesday, 20 April 2010 12:44 AM
>  >> To: buildroot at uclibc.org
>  >> Subject: [Buildroot] Still can't build working rootfs with crosstool-
>  >NGtoolchain
>  >>
>  >> I've spend the past week trying to use crosstool-NG instead of
>  >> buildroot to build a toolchain.  I had been using external buildroot
>  >> toolchains for the past couple months with no problems. But, that is
>  >> unsupported by buildroot, and I'm giving up fighting that battle.
>  >>
>  >> With crosstool-NG I can build a toolchain fine, and I can use it to
>  >> build kernels and root filesystems, but when I use a root filesystem
>  >> built with the crosstool-NG toolchain, I get a kernel panic
>  >> immediately folloing the mounting of the root filesystem.
>  >>
>  >> A rootfs built by the buildroot toolchain works fine.
>  >>
>  >> It's the same gcc and uClibc versions in both cases and the same
>  >> buildroot/rootfs settings.
>  >>
>  >> It doesn't seem to matter which toolchain I use to build the kernel, I
>  >> get the same results with both kernels. I'm using an Atmel
>  >> AT91SAM9G20EK development board, gcc 4.4.3, uClibc 0.9.30.2.
>  >>
>  >> Below the log of a failed startupt.  The log of a successful startup
>  >> using a buildroot-toolchain rootfs is identical except for two things:
>  >>
>  >>   1) The successfull rootfs is 20K larger, so a few of the lines with
>  >>      memory size diagnostics are different.
>  >>
>  >>   2) Instead of a kernel panic, I get welcome message and login
>  >>      prompt when using the buildroot toolchain.
>  >>
>  >> Any ideas on why a rootfs built using a crosstool-ng toolchain
>  >> wouldn't work?   In general how does one troubleshoot kernel panics
>  >> like this?
>  >>
>  >> Differences I can see in the toolchain configurations:
>  >>
>  >>  * ct-NG uses cloog/ppl, buildroot doesn't
>  >>
>  >>  * ct-NG enables __cxa_atexit, buildroot doesn't.
>  >>
>  >>  * ct-NG enables c99, buildroot doesn't.
>  >>
>  >>  * ct-NG enables long-long, buildroot doesn't.
>  >>
>  >>  * ct-NG uses --enable-threads=posix, buildroot is just --enable-
>  >threads
>  >>
>  >>  * buildroot specifies armv5te/arm9tdmi, ct-NG doesn't
>  >>
>  >>  * buildroot specifies abi=apcs-gnu, ct-NG doesn't
>  >>
>  >>
>  >> My ct-NG config is based on one of the "working samples" provided with
>  >> ct-NG.
>  >>
>  >> All ideas/suggestions welcome...
>  >>
>  >>
>  >> ----------------------------------------------------------------------
>  >--
>  >> RomBOOT
>  >>
>  >>
>  >> U-Boot 1.3.4 (Jan  6 2010 - 15:52:13)
>  >>
>  >> DRAM:  64 MB
>  >> NAND:  256 MiB
>  >> DataFlash:AT45DB642
>  >> Nb pages:   8192
>  >> Page Size:   1056
>  >> Size= 8650752 bytes
>  >> Logical address: 0xD0000000
>  >> Area 0:	D0000000 to D00041FF (RO) Bootstrap
>  >> Area 1:	D0004200 to D00083FF      Environment
>  >> Area 2:	D0008400 to D0041FFF (RO) U-Boot
>  >> Area 3:	D0042000 to D0251FFF      Kernel
>  >> Area 4:	D0252000 to D083FFFF      FS
>  >> In:    serial
>  >> Out:   serial
>  >> Err:   serial
>  >> Net:   macb0
>  >> macb0: Starting autonegotiation...
>  >> macb0: Autonegotiation complete
>  >> macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1)
>  >> Hit any key to stop autoboot:  3 \b\b\b 2 \b\b\b 1 \b\b\b 0
>  >> macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1)
>  >> Using macb0 device
>  >> TFTP from server 10.0.0.1; our IP address is 10.0.0.98
>  >> Filename 'rootfs'.
>  >> Load address: 0x22800000
>  >> Loading: *\b#########################################################
>  >> done
>  >> Bytes transferred = 822110 (c8b5e hex)
>  >> macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1)
>  >> Using macb0 device
>  >> TFTP from server 10.0.0.1; our IP address is 10.0.0.98
>  >> Filename 'uImage'.
>  >> Load address: 0x22200000
>  >> Loading:
>  >*\b#################################################################
>  >> 	 ################################################
>  >> done
>  >> Bytes transferred = 1647948 (19254c hex)
>  >> ## Booting kernel from Legacy Image at 22200000 ...
>  >>    Image Name:   Linux-2.6.30
>  >>    Image Type:   ARM Linux Kernel Image (uncompressed)
>  >>    Data Size:    1647884 Bytes =  1.6 MB
>  >>    Load Address: 20008000
>  >>    Entry Point:  20008000
>  >>    Verifying Checksum ... OK
>  >>    Loading Kernel Image ... OK
>  >> OK
>  >>
>  >> Starting kernel ...
>  >>
>  >> Uncompressing
>  >Linux...................................................................
>  >..................
>  >..................... done,
>  >> booting the kernel.
>  >> Linux version 2.6.30 (grante at alpha) (gcc version 4.4.3 (crosstool-NG-
>  >1.6.1) ) #5 Fri Apr
>  >16
>  >> 16:55:29 CDT 2010
>  >> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
>  >> CPU: VIVT data cache, VIVT instruction cache
>  >> Machine: Atmel AT91SAM9G20-EK
>  >> Memory policy: ECC disabled, Data cache writeback
>  >> Clocks: CPU 396 MHz, master 132 MHz, main 18.432 MHz
>  >> Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
>  >16256
>  >> Kernel command line: root=/dev/ram0 rw initrd=0x22800000,0xC8B5E
>  >> NR_IRQS:192
>  >> AT91: 96 gpio irqs in 3 banks
>  >> PID hash table entries: 256 (order: 8, 1024 bytes)
>  >> Console: colour dummy device 80x30
>  >> console [tty0] enabled
>  >> console [ttyS0] enabled
>  >> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
>  >> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
>  >> Memory: 64MB = 64MB total
>  >> Memory: 60680KB available (2992K code, 266K data, 116K init, 0K
>  >highmem)
>  >> Calibrating delay loop... 197.83 BogoMIPS (lpj=989184)
>  >> Security Framework initialized
>  >> Mount-cache hash table entries: 512
>  >> CPU: Testing write buffer coherency: ok
>  >> net_namespace: 520 bytes
>  >> NET: Registered protocol family 16
>  >> bio: create slab <bio-0> at 0
>  >> SCSI subsystem initialized
>  >> usbcore: registered new interface driver usbfs
>  >> usbcore: registered new interface driver hub
>  >> usbcore: registered new device driver usb
>  >> NET: Registered protocol family 2
>  >> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
>  >> TCP established hash table entries: 2048 (order: 2, 16384 bytes)
>  >> TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
>  >> TCP: Hash tables configured (established 2048 bind 2048)
>  >> TCP reno registered
>  >> NET: Registered protocol family 1
>  >> Trying to unpack rootfs image as initramfs...
>  >> rootfs image is not initramfs (no cpio magic); looks like an initrd
>  >> Freeing initrd memory: 800K
>  >> NetWinder Floating Point Emulator V0.97 (double precision)
>  >> DLM (built Apr 16 2010 16:30:14) installed
>  >> JFFS2 version 2.2. (NAND) B) 2001-2006 Red Hat, Inc.
>  >> msgmni has been set to 120
>  >> alg: No test for cipher_null (cipher_null-generic)
>  >> alg: No test for ecb(cipher_null) (ecb-cipher_null)
>  >> alg: No test for digest_null (digest_null-generic)
>  >> alg: No test for compress_null (compress_null-generic)
>  >> alg: No test for stdrng (krng)
>  >> io scheduler noop registered
>  >> io scheduler anticipatory registered (default)
>  >> atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL
>  >> atmel_usart.1: ttyS1 at MMIO 0xfffb0000 (irq = 6) is a ATMEL_SERIAL
>  >> atmel_usart.2: ttyS2 at MMIO 0xfffb4000 (irq = 7) is a ATMEL_SERIAL
>  >> brd: module loaded
>  >> loop: module loaded
>  >> ssc ssc.0: Atmel SSC device at 0xc4878000 (irq 14)
>  >> Driver 'sd' needs updating - please use bus_type methods
>  >> MACB_mii_bus: probed
>  >> eth0: Atmel MACB at 0xfffc4000 irq 21 (3a:1f:34:08:54:54)
>  >> eth0: attached PHY driver [Davicom DM9161A]
>  >(mii_bus:phy_addr=ffffffff:00, irq=-1)
>  >> NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB
>  >3,3V 8-bit)
>  >> AT91 NAND: 8-bit, Software ECC
>  >> Scanning device for bad blocks
>  >> Creating 3 MTD partitions on "atmel_nand":
>  >> 0x000000000000-0x000000400000 : "Bootstrap"
>  >> 0x000000400000-0x000004000000 : "Partition 1"
>  >> 0x000004000000-0x000010000000 : "Partition 2"
>  >> usbmon: debugfs is not available
>  >> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
>  >> at91_ohci at91_ohci: AT91 OHCI
>  >> at91_ohci at91_ohci: new USB bus registered, assigned bus number 1
>  >> at91_ohci at91_ohci: irq 20, io mem 0x00500000
>  >> usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
>  >> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>  >> usb usb1: Product: AT91 OHCI
>  >> usb usb1: Manufacturer: Linux 2.6.30 ohci_hcd
>  >> usb usb1: SerialNumber: at91
>  >> usb usb1: configuration #1 chosen from 1 choice
>  >> hub 1-0:1.0: USB hub found
>  >> hub 1-0:1.0: 2 ports detected
>  >> Initializing USB Mass Storage driver...
>  >> usbcore: registered new interface driver usb-storage
>  >> USB Mass Storage support registered.
>  >> usbcore: registered new interface driver usbserial
>  >> USB Serial support registered for generic
>  >> usbcore: registered new interface driver usbserial_generic
>  >> usbserial: USB Serial Driver core
>  >> udc: at91_udc version 3 May 2006
>  >> mice: PS/2 mouse device common for all mice
>  >> Registered led device: ds5
>  >> Registered led device: ds1
>  >> TCP cubic registered
>  >> NET: Registered protocol family 17
>  >> RPC: Registered udp transport module.
>  >> RPC: Registered tcp transport module.
>  >> SCTP: Hash tables configured (established 2048 bind 4096)
>  >> drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
>  >> RAMDISK: gzip image found at block 0
>  >> VFS: Mounted root (ext2 filesystem) on device 1:0.
>  >> Freeing init memory: 116K
>  >> Kernel panic - not syncing: Attempted to kill init!
>  >> Backtrace:
>  >> [<c00296dc>] (dump_backtrace+0x0/0x114) from [<c02659e4>]
>  >(dump_stack+0x18/0x1c)
>  >>  r6:c3812c40 r5:0000000b r4:c0338314
>  >> [<c02659cc>] (dump_stack+0x0/0x1c) from [<c0265a34>]
>  >(panic+0x4c/0x114)
>  >> [<c02659e8>] (panic+0x0/0x114) from [<c003f06c>] (do_exit+0x74/0x5cc)
>  >>  r3:c03196ac r2:c3817e3c r1:00002710 r0:c02ccc39
>  >> [<c003eff8>] (do_exit+0x0/0x5cc) from [<c003f658>]
>  >(do_group_exit+0x94/0xc8)
>  >> [<c003f5c4>] (do_group_exit+0x0/0xc8) from [<c0048a90>]
>  >(get_signal_to_deliver+0x2f4/0x330)
>  >>  r4:00106001
>  >> [<c004879c>] (get_signal_to_deliver+0x0/0x330) from [<c0027e90>]
>  >(do_signal+0x5c/0x4b8)
>  >> [<c0027e34>] (do_signal+0x0/0x4b8) from [<c002831c>]
>  >(do_notify_resume+0x30/0x34)
>  >> [<c00282ec>] (do_notify_resume+0x0/0x34) from [<c0025dcc>]
>  >(work_pending+0x1c/0x20)
>  >>
>  >>
>  >> --
>  >> Grant Edwards               grant.b.edwards        Yow! This ASEXUAL
>  >PIG
>  >>                                   at               really BOILS my
>  >BLOOD
>  >>                               gmail.com            ... He's so ... so
>  >>                                                    ... URGENT!!
>  >
>  >
>  >_______________________________________________
>  >buildroot mailing list
>  >buildroot at busybox.net
>  >http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Still can't build working rootfs with crosstool-NGtoolchain

[Grant Edwards]

On 2010-04-21, Microbit_P43000 <microbit@virginbroadband.com.au> wrote:

> It's a while ago I've been through this - but the common denominator
> of course is the fact that the lib is dynamically linked. The config
> of float/lib is just fine - it compiles on a fresh install - or
> consequent builds for my rootfs, Nano runs perfect - no problemo.
>
> I just couldn't pin down _what_ exactly triggers BR2 to "remake"
> itself completely. It mostly would happen *after* I change a simple
> option in Busybox - of all things. How exactly does that warrant
> RE-building the whole install (incl internal toolchain) ???

I never do anything with buildroot other than complete ground-up
builds from scratch.  Despite the documented ways to do partial
rebuilds, I was never able to reliably do a parial rebuild.  After
several instances of spending hours or days chasing problems that went
away after a complete re-build, I simply gave up on doing anything
other than building from zero.

-- 
Grant Edwards               grant.b.edwards        Yow! Where do your SOCKS
                                  at               go when you lose them in
                              gmail.com            th' WASHER?

[Buildroot] Still can't build working rootfswith crosstool-NGtoolchain

[Microbit_P43000]

Thanks Grant,

That puts my soul at rest a bit... &:). Wish I posted this many months ago, oh well...
I have a copy of the 'dl' dir, re-extract BR, re-copy the dl directory contents and
re-import
my configs for everything and make. 
At one stage the whole cycle took ~ 1 hour 15 mins. Common sense had to prevail I guess -
it's just a lot faster than chasing ghosts - it seems that your experience matches the
observations I made.

Being unfamiliar with BR as I was, naturally one always doubts themselves first.
I really wanted to know wtf exactly was going on. Never have, never will - I guess.

Shame, although I really like buildroot, it is/was extremely irritating.
(It used to be much worse for me when I started, then BR still supported "multiple
projects", that I just
_never_ got a handle on. Things would go ape frequently, a rebuild of one project would 
- guess what - ...trigger a "complete rebuild" of the internal toolchain after making a
subsequent small change in the other project - It seems it was a good idea to do away with
that, blah)

But I learned heaps in the process. So something constructive after all - BR2 still is my
favourite so far. I like its flexibility !!

Best Regards,
Kris 


> -----Original Message-----
> From: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] On Behalf Of
> Grant Edwards
> Sent: Thursday, 22 April 2010 12:06 AM
> To: buildroot at uclibc.org
> Subject: Re: [Buildroot] Still can't build working rootfswith crosstool-NGtoolchain
> 
> On 2010-04-21, Microbit_P43000 <microbit@virginbroadband.com.au> wrote:
> 
> > It's a while ago I've been through this - but the common denominator
> > of course is the fact that the lib is dynamically linked. The config
> > of float/lib is just fine - it compiles on a fresh install - or
> > consequent builds for my rootfs, Nano runs perfect - no problemo.
> >
> > I just couldn't pin down _what_ exactly triggers BR2 to "remake"
> > itself completely. It mostly would happen *after* I change a simple
> > option in Busybox - of all things. How exactly does that warrant
> > RE-building the whole install (incl internal toolchain) ???
> 
> I never do anything with buildroot other than complete ground-up
> builds from scratch.  Despite the documented ways to do partial
> rebuilds, I was never able to reliably do a parial rebuild.  After
> several instances of spending hours or days chasing problems that went
> away after a complete re-build, I simply gave up on doing anything
> other than building from zero.
> 
> --
> Grant Edwards               grant.b.edwards        Yow! Where do your SOCKS
>                                   at               go when you lose them in
>                               gmail.com            th' WASHER?
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Still can't build working rootfswith crosstool-NGtoolchain

[Grant Edwards]

On 2010-04-21, Microbit_P43000 <microbit@virginbroadband.com.au> wrote:

> That puts my soul at rest a bit... &:). Wish I posted this many
> months ago, oh well... I have a copy of the 'dl' dir, re-extract BR,
> re-copy the dl directory contents and re-import my configs for
> everything and make.
>
> At one stage the whole cycle took ~ 1 hour 15 mins. Common sense had
> to prevail I guess - it's just a lot faster than chasing ghosts - it
> seems that your experience matches the observations I made.

If it's taking that long, I suspect you're also building a toolchain
and kernel everytime.  When I realized that partial rebuilds weren't
practical, I switched to using an external toolchain.  With an
external toolchain and an external download directory, doing a
from-scratch basic rootfs build takes about 6-7 minutes on a single
CPU, 2GHz AMD Athlon64.

I also switched to building my kernel outside of buildroot.  If you're
doing any sort of kernel development (or just want to try
experimenting with kernel configurations), doing the kernel builds
with buildroot is pretty clumsy.

Once you've got a kernel configuration figured out and set in stone,
it could be useful to have the kernel built by buildroot, but it
doesn't seem to be a paractical way to do kernel development.

-- 
Grant Edwards               grant.b.edwards        Yow! PARDON me, am I
                                  at               speaking ENGLISH?
                              gmail.com            

[Buildroot] Still can't build workingrootfswith crosstool-NGtoolchain

[Microbit_P43000]

Hi Grant,

> -----Original Message-----
> From: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] On Behalf Of
> Grant Edwards
> Sent: Thursday, 22 April 2010 2:31 AM
> To: buildroot at uclibc.org
> Subject: Re: [Buildroot] Still can't build workingrootfswith crosstool-NGtoolchain
> 
> On 2010-04-21, Microbit_P43000 <microbit@virginbroadband.com.au> wrote:
> 
> > That puts my soul at rest a bit... &:). Wish I posted this many
> > months ago, oh well... I have a copy of the 'dl' dir, re-extract BR,
> > re-copy the dl directory contents and re-import my configs for
> > everything and make.
> >
> > At one stage the whole cycle took ~ 1 hour 15 mins. Common sense had
> > to prevail I guess - it's just a lot faster than chasing ghosts - it
> > seems that your experience matches the observations I made.
> 
> If it's taking that long, I suspect you're also building a toolchain
> and kernel everytime.  When I realized that partial rebuilds weren't
> practical, I switched to using an external toolchain.  With an
> external toolchain and an external download directory, doing a
> from-scratch basic rootfs build takes about 6-7 minutes on a single
> CPU, 2GHz AMD Athlon64.
> 
> I also switched to building my kernel outside of buildroot.  If you're
> doing any sort of kernel development (or just want to try
> experimenting with kernel configurations), doing the kernel builds
> with buildroot is pretty clumsy.
> 
> Once you've got a kernel configuration figured out and set in stone,
> it could be useful to have the kernel built by buildroot, but it
> doesn't seem to be a paractical way to do kernel development.
> 
> --
> Grant Edwards               grant.b.edwards        Yow! PARDON me, am I
>                                   at               speaking ENGLISH?
>                               gmail.com
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

Indeed, the time I mention is a complete make from scratch. Xcompiler, utils, libc,
busybox, rootfs, etc.... It doesn't have to include the kernel, that takes all but 5 mins.
This is on a P4 dual CPU 3 GHz (albeit with only 1 GB ram).

I've tried external tools like codesourcery (which I dislike) and arm-elf-gcc and likes.
Either I ran into sysroot problems, or their were hissies being thrown about 90% through
building, that sort of stuff - yet again off a Sherlock Holmes to figure out in scripts
where these mysterious 'issues' come from.
I can't recall - surely I must have been doing something wrong, I guess. (I've come across
clear bugs on a couple of occasions, eg. I've got 32 bit EABI and some package (Lynx with
the latest SSL extensions IIRC) incorrectly gets a perceived 64 bit environment from host
instead of target settings.... More whinging yet again that uclibc is compiled for 32 bit
only - that sort of crap.
I need to revisit getting ext tool working for me again soon.  But yes, when I get back to
that, I really have to get the ext tool going.

Thanks for the insights, Grant - much appreciated, I'll post again when I get my feet back
under desk for linux cross-compile.

Maybe a note to the authors of Buildroot here that this doesn't mean I'm not appreciating
all their effort - on the contrary ! This surely must be a massive effort which I guess
could seem thankless, given all the 'problem traffic' on here.
Too much to learn anyhoo I say :-)

Best Regards,
Kris

[Buildroot] Still can't build workingrootfswith crosstool-NGtoolchain

[Grant Edwards]

On 2010-04-21, Microbit_P43000 <microbit@virginbroadband.com.au> wrote:

> Indeed, the time I mention is a complete make from scratch.
> Xcompiler, utils, libc, busybox, rootfs, etc.... It doesn't have to
> include the kernel, that takes all but 5 mins. This is on a P4 dual
> CPU 3 GHz (albeit with only 1 GB ram).

The toolchain is probably 90+ percent of that.  I think you'll be far
happier if you use an external toolchain.

> I've tried external tools like codesourcery (which I dislike) and
> arm-elf-gcc and likes. Either I ran into sysroot problems, or their
> were hissies being thrown about 90% through building, that sort of
> stuff - yet again off a Sherlock Holmes to figure out in scripts
> where these mysterious 'issues' come from.

AFAIK, most of the buildroot developers use external toolchains built
by crosstools-NG (and that's what I'm now using), so that's probably
the path of least resistance.  If you like, I can send you the
crosstools-NG and uClibc config files I'm using for ARM9, but 
Crosstools-NG comes with quite a few sample configs -- one of them is
probably pretty close to what you want.

Just pay close attention to ARM EABI vs. OABI.

-- 
Grant Edwards               grant.b.edwards        Yow! As President I have
                                  at               to go vacuum my coin
                              gmail.com            collection!

[Buildroot] Still can't build working rootfswith crosstool-NGtoolchain

[Peter Korsgaard]

>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:

Hi,

 >> At one stage the whole cycle took ~ 1 hour 15 mins. Common sense had
 >> to prevail I guess - it's just a lot faster than chasing ghosts - it
 >> seems that your experience matches the observations I made.

 Grant> If it's taking that long, I suspect you're also building a
 Grant> toolchain and kernel everytime.  When I realized that partial
 Grant> rebuilds weren't practical, I switched to using an external
 Grant> toolchain.  With an external toolchain and an external download
 Grant> directory, doing a from-scratch basic rootfs build takes about
 Grant> 6-7 minutes on a single CPU, 2GHz AMD Athlon64.

FYI, I do full builds (internal toolchain including C++, a number of
packages including Qt, U-Boot and Linux kernel) in about 25 mins on a
2.8GHz i7 (buildbot server)

 Grant> Once you've got a kernel configuration figured out and set in stone,
 Grant> it could be useful to have the kernel built by buildroot, but it
 Grant> doesn't seem to be a paractical way to do kernel development.

Agreed. Doing these things with BR is mainly interesting as a
structured integration tool when the basics are stable - E.G. to ensure
you have everything under configuration control and can reproduce the
build.

-- 
Bye, Peter Korsgaard

[Buildroot] Still can't build workingrootfswith crosstool-NGtoolchain

[Peter Korsgaard]

>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:

Hi,

 Grant> AFAIK, most of the buildroot developers use external toolchains
 Grant> built by crosstools-NG (and that's what I'm now using), so
 Grant> that's probably the path of least resistance.  If you like, I
 Grant> can send you the crosstools-NG and uClibc config files I'm using
 Grant> for ARM9, but Crosstools-NG comes with quite a few sample
 Grant> configs -- one of them is probably pretty close to what you
 Grant> want.

Not me. I still use an internal toolchain (but will probably move to
ct-NG once the kinks are sorted out).

-- 
Bye, Peter Korsgaard

[Buildroot] Still can't buildworkingrootfswith crosstool-NGtoolchain

[Microbit_P43000]

Hi Grant,

> -----Original Message-----
> From: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] On Behalf Of
> Grant Edwards
> Sent: Thursday, 22 April 2010 4:33 AM
> To: buildroot at uclibc.org
> Subject: Re: [Buildroot] Still can't buildworkingrootfswith crosstool-NGtoolchain
> 
> On 2010-04-21, Microbit_P43000 <microbit@virginbroadband.com.au> wrote:
> 
> > Indeed, the time I mention is a complete make from scratch.
> > Xcompiler, utils, libc, busybox, rootfs, etc.... It doesn't have to
> > include the kernel, that takes all but 5 mins. This is on a P4 dual
> > CPU 3 GHz (albeit with only 1 GB ram).
> 
> The toolchain is probably 90+ percent of that.  I think you'll be far
> happier if you use an external toolchain.
> 
> > I've tried external tools like codesourcery (which I dislike) and
> > arm-elf-gcc and likes. Either I ran into sysroot problems, or their
> > were hissies being thrown about 90% through building, that sort of
> > stuff - yet again off a Sherlock Holmes to figure out in scripts
> > where these mysterious 'issues' come from.
> 
> AFAIK, most of the buildroot developers use external toolchains built
> by crosstools-NG (and that's what I'm now using), so that's probably
> the path of least resistance.  If you like, I can send you the
> crosstools-NG and uClibc config files I'm using for ARM9, but
> Crosstools-NG comes with quite a few sample configs -- one of them is
> probably pretty close to what you want.
> 
> Just pay close attention to ARM EABI vs. OABI.
> 
> --
> Grant Edwards               grant.b.edwards        Yow! As President I have
>                                   at               to go vacuum my coin
>                               gmail.com            collection!
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot


That sounds great. Unless there's a pretty-close config for Olimex SAM9-L9260. But the
Atmel 9260EK is already as good as compatible. Small differences like CS1 vs. CS0 for
DataFlash
is taken care of in my own board file anyway.

The OABI drama, I recall that all right. The Olimex board was turnkey, but when I tried
basic user space code, 'twas always nasty page faults etc.
Then I realised that I needed to recompile the kernel to run EABI, that's what (the
included) codesourcery tool produced anyway.

I recall I looked at crosstools-NG, and it seemed a bit overwhelming at the start for
newbie like me.
If you have some sort of a kickstart config, it'd certainly be well appreciated. I still
need to learn, but at times it's like it's pushing the proverbial ** up hill :-)

** Peter : Interesting that the internal tool + packages builds that quick for you.
Perhaps I should underscore that I'm using Ubuntu 9.10 w/ kernel fixes. It's also a distro
x86 install. Perhaps a lot of my 3 GHz P4 CPU is being blown there, dunno.

Note : I can't readily try it ftm, I'm doing code w/ CrossWorks ARM for SAM7 under XP.
It's also painful that I couldn't find a way to get Ubuntu 9.10 to install as EXT3, rather
than EXT4. I like using Colinux if need really arises, but Colinux has no clue about EXT4
(yet, dunno ?)
I boot off a completely separate HDD for Linux. Eventually I'll upgrade, but that machine
still stands up really well when it runs XP.

Best regards,
Kris

[Buildroot] Still can't build working rootfswith crosstool-NGtoolchain

[Thomas Petazzoni]

On Wed, 21 Apr 2010 16:31:24 +0000 (UTC)
Grant Edwards <grant.b.edwards@gmail.com> wrote:

> If it's taking that long, I suspect you're also building a toolchain
> and kernel everytime.  When I realized that partial rebuilds weren't
> practical, I switched to using an external toolchain.  With an
> external toolchain and an external download directory, doing a
> from-scratch basic rootfs build takes about 6-7 minutes on a single
> CPU, 2GHz AMD Athlon64.
> 
> I also switched to building my kernel outside of buildroot.  If you're
> doing any sort of kernel development (or just want to try
> experimenting with kernel configurations), doing the kernel builds
> with buildroot is pretty clumsy.
> 
> Once you've got a kernel configuration figured out and set in stone,
> it could be useful to have the kernel built by buildroot, but it
> doesn't seem to be a paractical way to do kernel development.

This is also exactly what I do. We should probably document a bit more
some typical "use cases" in the Buildroot documentation.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Still can't build working rootfs with crosstool-NGtoolchain

[Thomas Petazzoni]

On Wed, 21 Apr 2010 14:06:18 +0000 (UTC)
Grant Edwards <grant.b.edwards@gmail.com> wrote:

> I never do anything with buildroot other than complete ground-up
> builds from scratch.  Despite the documented ways to do partial
> rebuilds, I was never able to reliably do a parial rebuild.  After
> several instances of spending hours or days chasing problems that went
> away after a complete re-build, I simply gave up on doing anything
> other than building from zero.

Yes, building from zero is the only way of being sure of what is
happening. As soon as *any* system-wide change, such as a toolchain
configuration change, is made, then a rebuild from zero is needed.

Partial rebuilds, as documented in the documentation, are possible on a
per-package basis, when you fully understand what you're doing and how
Buildroot uses the stamp files. You can very easily break things, or on
the opposite, get something working that wouldn't work with a build
starting from zero.

When doing work on packages, I do use partial rebuilds a lot, but I
also make sure to do a full rebuild at the end to make sure everything
is in order.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com