[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

Hello all,

I switch from an external OABI toolchain to an external EABI toolchain
awhile back.  I had to do this in order to build the more recent kernels
since my old toolchain was 4.1.1 and the kernel will not build with
that version.

I haven't had any problems with the toolchain building my kernel but
realized the other day that my rootfs was actually still based on the
older OABI toolchain.  So I deleted all the old directories (build_arm,
toolchain_build_arm, binaries, etc.) and rebuilt everything with the
EABI toolchain.

Now when I try to boot the kernel comes up fine but I get the following
when run_init_process("/sbin/init") trys to execute:

Kernel panic - not syncing: Attempted to kill init!
[<c002ca8c>] (unwind_backtrace+0x0/0xdc) from [<c02943dc>] (panic+0x48/0x120)
[<c02943dc>] (panic+0x48/0x120) from [<c0048430>] (do_exit+0x64/0x608)
[<c0048430>] (do_exit+0x64/0x608) from [<c0048a84>] (do_group_exit+0xb0/0xe4)
[<c0048a84>] (do_group_exit+0xb0/0xe4) from [<c0052cc4>] (get_signal_to_deliver+0x384/0x3dc)
[<c0052cc4>] (get_signal_to_deliver+0x384/0x3dc) from [<c00295f8>] (do_signal+0x50/0x528)
[<c00295f8>] (do_signal+0x50/0x528) from [<c0026eac>] (work_pending+0x1c/0x20)

I haven't been able to figure out what the problem is.  Does anyone have
an idea?  I'm using buildroot version 2009.08-rc2 and kernel 2.6.30.5 if
that's any help.

Thanks,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Thomas Petazzoni]

Le Wed, 19 Aug 2009 14:32:24 -0400,
"H Hartley Sweeten" <hartleys@visionengravers.com> a ?crit :

> I haven't been able to figure out what the problem is.  Does anyone
> have an idea?  I'm using buildroot version 2009.08-rc2 and kernel
> 2.6.30.5 if that's any help.

Do you compile your kernel with Buildroot, or do you compile it
manually ? If compiled manually, is CONFIG_AEABI enabled in your kernel
configuration ?

Sincerly,

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

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Wednesday, August 19, 2009 12:43 PM, Thomas Petazzoni wrote:
>> I haven't been able to figure out what the problem is.  Does anyone
>> have an idea?  I'm using buildroot version 2009.08-rc2 and kernel
>> 2.6.30.5 if that's any help.
>
> Do you compile your kernel with Buildroot, or do you compile it
> manually ? If compiled manually, is CONFIG_AEABI enabled in your kernel
> configuration ?

The kernel and rootfs are both created with Buildroot.

For the kernel config I have:

CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y

For buildroot's config I have:

# BR2_ARM_OABI is not set
BR2_ARM_EABI=y

Is there a similar configuration that needs to be set in Busybox?

Regards,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Thomas Petazzoni]

Le Wed, 19 Aug 2009 16:19:35 -0400,
"H Hartley Sweeten" <hartleys@visionengravers.com> a ?crit :

> The kernel and rootfs are both created with Buildroot.
> 
> For the kernel config I have:
> 
> CONFIG_AEABI=y
> CONFIG_OABI_COMPAT=y
> 
> For buildroot's config I have:
> 
> # BR2_ARM_OABI is not set
> BR2_ARM_EABI=y

That's correct. When I fall into similar issue, I usually end up
writing a very simple init program that does:

int main(void)
{
	write(1, "Hello\n", 6);
	while(1);
}

Compile it statically and put it in /sbin/init. Getting this first
basic program to work is a first step.

> Is there a similar configuration that needs to be set in Busybox?

Not that I'm aware of.

Sincerly,

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

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Wednesday, August 19, 2009 2:31 PM, Thomas Petazzoni wrote:
>> The kernel and rootfs are both created with Buildroot.
>> 
>> For the kernel config I have:
>> 
>> CONFIG_AEABI=y
>> CONFIG_OABI_COMPAT=y
>> 
>> For buildroot's config I have:
>> 
>> # BR2_ARM_OABI is not set
>> BR2_ARM_EABI=y
>
> That's correct. When I fall into similar issue, I usually end up
> writing a very simple init program that does:
>
> int main(void)
> {
>	write(1, "Hello\n", 6);
>	while(1);
> }
>
> Compile it statically and put it in /sbin/init. Getting this first
> basic program to work is a first step.

I just tried that and get the same results.  Maybe I didn't compile
it statically?  I just did:

$ arm-none-linux-gnueabi-gcc init.c -o init

Then replaced the /sbin/init link to busybox with the file.  I also
loop mounted the rootfs.arm.ext2 filesystem to verify that the file
was indeed replaced.

>> Is there a similar configuration that needs to be set in Busybox?
>
> Not that I'm aware of.

I added a printk in the run_init_process() function in init/main.c
to verify what process was trying to start.  Here's a bit more of
the boot messages, I can post the whole thing it needed:

Uncompressing Linux................................................................................................................... done, booting the kernel.
Linux version 2.6.30.5 (bigguiness at etch) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #12 PREEMPT Wed Aug 19 11:10:39 MST 2009
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
CPU: VIVT data cache, VIVT instruction cache
Machine: Vision Engraving Systems EP9307 SoM
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16192
Kernel command line: root=/dev/ram console=ttyAM2 video=ep93xx-fb:640x480-16 at 60

... Everything after that looks normal

rtc-isl1208 0-006f: setting system clock to 2009-08-19 14:57:28 UTC (1250693848)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing init memory: 120K
run_init_process: /sbin/init
Kernel panic - not syncing: Attempted to kill init!
[<c002ca8c>] (unwind_backtrace+0x0/0xdc) from [<c02943dc>] (panic+0x48/0x120)
[<c02943dc>] (panic+0x48/0x120) from [<c0048430>] (do_exit+0x64/0x608)
[<c0048430>] (do_exit+0x64/0x608) from [<c0048a84>] (do_group_exit+0xb0/0xe4)
[<c0048a84>] (do_group_exit+0xb0/0xe4) from [<c0052cc4>] (get_signal_to_deliver+0x384/0x3dc)
[<c0052cc4>] (get_signal_to_deliver+0x384/0x3dc) from [<c00295f8>] (do_signal+0x50/0x528)
[<c00295f8>] (do_signal+0x50/0x528) from [<c0026eac>] (work_pending+0x1c/0x20)

Any other ideas?

Thanks for the help,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Wednesday, August 19, 2009 6:50 PM, Kelvin Cheung wrote: 
>>>> The kernel and rootfs are both created with Buildroot.
>>>> 
>>>> For the kernel config I have:
>>>> 
>>>> CONFIG_AEABI=y
>>>> CONFIG_OABI_COMPAT=y
>>>> 
>>>> For buildroot's config I have:
>>>> 
>>>> # BR2_ARM_OABI is not set
>>>> BR2_ARM_EABI=y
>>>
>>> That's correct. When I fall into similar issue, I usually end up
>>> writing a very simple init program that does:
>>>
>>> int main(void)
>>> {
>>>	write(1, "Hello\n", 6);
>>>	while(1);
>>> }
>>>
>>> Compile it statically and put it in /sbin/init. Getting this first
>>> basic program to work is a first step.
>>
>> I just tried that and get the same results.  Maybe I didn't compile
>> it statically?  I just did:
>>
>> $ arm-none-linux-gnueabi-gcc init.c -o init
>>
>> Then replaced the /sbin/init link to busybox with the file.  I also
>> loop mounted the rootfs.arm.ext2 filesystem to verify that the file
>> was indeed replaced.
>>
>>>> Is there a similar configuration that needs to be set in Busybox?
>>>
>>> Not that I'm aware of.
>
> This problem happened to me before.
>
> You could use arm-linux-readelf to check out whether the kernel(vmlinux)
> and busybox were compiled with the same architecture version.
>
> In my case, the kernel was v4 while busybox was v5.

Ok.  That "seems" to be the problem.

$ arm-none-linux-gnueabi-readelf -A project_build_arm/ep9307/linux-2.6.30.5/vmlinux
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "4T"
  Tag_CPU_arch: v4T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align8_needed: Yes
  Tag_ABI_enum_size: int

$ arm-none-linux-gnueabi-readelf -A project_build_arm/ep9307/busybox-1.13.4/busybox
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM10TDMI"
  Tag_CPU_arch: v5T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align8_needed: Yes
  Tag_ABI_enum_size: int

The question is how to fix it...

I tried setting:

BR2_TARGET_OPTIMIZATION="-march=armv4t"

Which is what I think the kernel build does.  The build went along for a while the
gave me an error about a lib file being the wrong version.

Arrgh... Any help?

Thanks,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Wednesday, August 19, 2009 7:39 PM, Kelvin Cheung wrote:
>>> This problem happened to me before.
>>>
>>> You could use arm-linux-readelf to check out whether the kernel(vmlinux)
>>> and busybox were compiled with the same architecture version.
>>>
>>> In my case, the kernel was v4 while busybox was v5.
>>	
>>	
>> Ok.  That "seems" to be the problem.
>> 	
>> $ arm-none-linux-gnueabi-readelf -A project_build_arm/ep9307/linux-2.6.30.5/vmlinux
>> Attribute Section: aeabi
>> File Attributes
>>  Tag_CPU_name: "4T"
>>  Tag_CPU_arch: v4T
>>  Tag_ARM_ISA_use: Yes
>>  Tag_THUMB_ISA_use: Thumb-1
>>  Tag_ABI_PCS_wchar_t: 4
>>  Tag_ABI_FP_denormal: Needed
>>  Tag_ABI_FP_exceptions: Needed
>>  Tag_ABI_FP_number_model: IEEE 754
>>  Tag_ABI_align8_needed: Yes
>> Tag_ABI_enum_size: int
>> 	
>> $ arm-none-linux-gnueabi-readelf -A project_build_arm/ep9307/busybox-1.13.4/busybox
>> Attribute Section: aeabi
>> File Attributes
>>  Tag_CPU_name: "ARM10TDMI"
>>  Tag_CPU_arch: v5T
>>  Tag_ARM_ISA_use: Yes
>>  Tag_THUMB_ISA_use: Thumb-1
>>  Tag_ABI_PCS_wchar_t: 4
>>  Tag_ABI_FP_denormal: Needed
>>  Tag_ABI_FP_exceptions: Needed
>>  Tag_ABI_FP_number_model: IEEE 754
>>  Tag_ABI_align8_needed: Yes
>>  Tag_ABI_enum_size: int
>> 	
>> The question is how to fix it...
>> 
>> I tried setting:
>> 
>> BR2_TARGET_OPTIMIZATION="-march=armv4t"
>> 
>> Which is what I think the kernel build does.  The build went along for a while the
>> gave me an error about a lib file being the wrong version.
>> 
>> Arrgh... Any help?
>> 	
> Please set as follow:
>
> BR2_EXTRA_BINUTILS_CONFIG_OPTIONS="--with-arch=armv4t --with-cpu=arm920t"
> BR2_EXTRA_GCC_CONFIG_OPTIONS="--with-arch=armv4t --with-cpu=arm920t"

I'm using an external toolchain so I don't think those config options are available.

Would the equivalent CFLAGS be:

-march=armv4t -mcpu=arm920t

If so do I just set BR2_TARGET_OPTIMIZATION with that?

Regards and thanks,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Thomas Petazzoni]

Le Wed, 19 Aug 2009 18:28:42 -0400,
"H Hartley Sweeten" <hartleys@visionengravers.com> a ?crit :

> I just tried that and get the same results.  Maybe I didn't compile
> it statically?  I just did:
> 
> $ arm-none-linux-gnueabi-gcc init.c -o init

Add -static

And verify with "file" that it is indeed statically compiled:

thomas at surf:/tmp$ arm-linux-gcc -o hello hello.c
thomas at surf:/tmp$ file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
thomas at surf:/tmp$ arm-linux-gcc -o hello hello.c -static
thomas at surf:/tmp$ file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped

Sincerly,

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

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Thursday, August 20, 2009 5:35 AM, Thomas Petazzoni wrote:
>> I just tried that and get the same results.  Maybe I didn't compile
>> it statically?  I just did:
>> 
>> $ arm-none-linux-gnueabi-gcc init.c -o init
>
> Add -static
>
> And verify with "file" that it is indeed statically compiled:
>
> thomas at surf:/tmp$ arm-linux-gcc -o hello hello.c
> thomas at surf:/tmp$ file hello
> hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
> thomas at surf:/tmp$ arm-linux-gcc -o hello hello.c -static
> thomas at surf:/tmp$ file hello
> hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped

Ok.  That works.

rtc-isl1208 0-006f: setting system clock to 2009-08-20 09:31:48 UTC (1250760708)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing init memory: 120K
run_init_process: /sbin/init
Hello
usb 1-1: configuration #1 chosen from 1 choice
input: HID 04d9:1203 as /devices/platform/ep93xx-ohci/usb1/1-1/1-1:1.0/input/input2
generic-usb 0003:04D9:1203.0001: input: USB HID v1.11 Keyboard [HID 04d9:1203] on usb-ep93xx-1/input0
input: HID 04d9:1203 as /devices/platform/ep93xx-ohci/usb1/1-1/1-1:1.1/input/input3
generic-usb 0003:04D9:1203.0002: input: USB HID v1.11 Device [HID 04d9:1203] on usb-ep93xx-1/input1

But I had to comile the test init as:

$ arm-none-linux-gnueabi-gcc -static -march=armv4t -mcpu=arm920t init.c -o init
$ file init
init: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, statically linked, for GNU/Linux 2.6.14, not stripped
$ arm-none-linux-gnueabi-readelf -A init Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "4T"
  Tag_CPU_arch: v4T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align8_needed: Yes
  Tag_ABI_enum_size: int

If I compile it without the -march=armv4t -mcpu=arm920t flags I get:

$ arm-none-linux-gnueabi-gcc -static init.c -o init
$ arm-none-linux-gnueabi-readelf -A init Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM10TDMI"
  Tag_CPU_arch: v5T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align8_needed: Yes
  Tag_ABI_enum_size: int

Can I just add the -march=armv4t -mcpu=arm920t to BR2_TARGET_OPTIMIZATION?  I 
previously just tried setting it to -march=armv4t but got a linker error about
a lib file being the wrong version.

The CodeSourcery compiler has a strange directory structure, probably due to
supporting various arm cpu's.  I'm not sure how to configure buildroot so that
the correct library files are used.

The directory tree looks something like this:

$ tree arm-none-linux-gnueabi/ -d -L 3
arm-none-linux-gnueabi/
|-- bin
|-- include
|   `-- c++
|       `-- 4.3.3
|-- lib
|   |-- armv4t
|   |-- boards
|   |-- ldscripts
|   `-- thumb2
`-- libc
    |-- armv4t
    |   |-- etc
    |   |-- lib
    |   |-- sbin
    |   `-- usr
    |-- etc
    |-- lib
    |-- sbin
    |-- thumb2
    |   |-- etc
    |   |-- lib
    |   |-- sbin
    |   `-- usr
    `-- usr
        |-- bin
        |-- include
        |-- info
        |-- lib
        |-- libexec
        |-- man
        |-- sbin
        `-- share

Regards,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Thursday, August 20, 2009 5:35 AM, Thomas Petazzoni wrote:
>> I just tried that and get the same results.  Maybe I didn't compile
>> it statically?  I just did:
>> 
>> $ arm-none-linux-gnueabi-gcc init.c -o init
>
> Add -static
>
> And verify with "file" that it is indeed statically compiled:
>
> thomas at surf:/tmp$ arm-linux-gcc -o hello hello.c
> thomas at surf:/tmp$ file hello
> hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
> thomas at surf:/tmp$ arm-linux-gcc -o hello hello.c -static
> thomas at surf:/tmp$ file hello
> hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped

Follow-up information...

It appears that ext-tool.mk is not copying the correct external toolchain
libraries for my architecture.

The ext-tool.mk uses the following to get SYSROOT_DIR:

SYSROOT_DIR=$(shell LANG=C $(TARGET_CC) -v 2>&1 | grep ^Configured | tr " " "\n" | grep -- "--with-sysroot" | cut -f2 -d=)

Manually doing that from the command line gives me:

$ arm-none-linux-gnueabi-gcc -v 2>&1 | grep ^Configured | tr " " "\n" | grep -- "--with-sysroot" | cut -f2 -d=
/opt/codesourcery/arm-none-linux-gnueabi/libc
$ arm-none-linux-gnueabi-gcc -march=armv4t -v 2>&1 | grep ^Configured | tr " " "\n" | grep -- "--with-sysroot" | cut -f2 -d=
/opt/codesourcery/arm-none-linux-gnueabi/libc

It appears the -march=armv4t option does not effect the -v option.

/opt/codesourcery/arm-none-linux-gnueabi is a hardlink to the real
location of the files.

$ ls -la /opt/codesourcery/arm-none-linux-gnueabi
lrwxrwxrwx 1 root root 70 2009-07-20 17:28 /opt/codesourcery/arm-none-linux-gnueabi -> /home/bigguiness/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi

But, if I query the directories in the compiler's search path they
are different.  Note, in the following I clipped the first part of
all the paths in order to shorten the output.

$ arm-none-linux-gnueabi-gcc -print-search-dirs
install:
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/
programs: =
	bin/../libexec/gcc/arm-none-linux-gnueabi/4.3.3/
	bin/../libexec/gcc/
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi/4.3.3/
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/
libraries: =
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/
	bin/../lib/gcc/
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/lib/arm-none-linux-gnueabi/4.3.3/
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/lib/
	bin/../arm-none-linux-gnueabi/libc/lib/arm-none-linux-gnueabi/4.3.3/
	bin/../arm-none-linux-gnueabi/libc/lib/
	bin/../arm-none-linux-gnueabi/libc/usr/lib/arm-none-linux-gnueabi/4.3.3/
	bin/../arm-none-linux-gnueabi/libc/usr/lib/

$ arm-none-linux-gnueabi-gcc -march=armv4t -print-search-dirs
install: 
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/
programs: =
	bin/../libexec/gcc/arm-none-linux-gnueabi/4.3.3/
	bin/../libexec/gcc/
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi/4.3.3/
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/
libraries: =
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/armv4t/
	bin/../lib/gcc/armv4t/
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/lib/arm-none-linux-gnueabi/4.3.3/armv4t/
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/lib/armv4t/
	bin/../arm-none-linux-gnueabi/libc/armv4t/lib/arm-none-linux-gnueabi/4.3.3/armv4t/
	bin/../arm-none-linux-gnueabi/libc/armv4t/lib/armv4t/
	bin/../arm-none-linux-gnueabi/libc/armv4t/usr/lib/arm-none-linux-gnueabi/4.3.3/armv4t/
	bin/../arm-none-linux-gnueabi/libc/armv4t/usr/lib/armv4t/
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/
	bin/../lib/gcc/
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/lib/arm-none-linux-gnueabi/4.3.3/
	bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/lib/
	bin/../arm-none-linux-gnueabi/libc/armv4t/lib/arm-none-linux-gnueabi/4.3.3/
	bin/../arm-none-linux-gnueabi/libc/armv4t/lib/
	bin/../arm-none-linux-gnueabi/libc/armv4t/usr/lib/arm-none-linux-gnueabi/4.3.3/
	bin/../arm-none-linux-gnueabi/libc/armv4t/usr/lib/

I think the ARMv5T (default) libraries are getting copied to the
staging_dir and not the ARMv4T (-march=armv4t) libraries.

Can you think of anyway to fix this?

Regards,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

Hello Thomas,

The current external toolchain support doesn't appear to work correctly
for a multilib toolchain.  The library files are in different subdirectories
depending on the architecture.

For example, the CodeSourcery 2009q1-203 toolchain supports the following
library configurations (this is from the Getting_Started_Guide provided
with the toolchain):

1) ARMv5T - Little-Endian, Soft-Float, GLIBC
   Command-line option(s): default
   Sysroot subdirectory: ./
   Dynamic linker: lib/ld-linux.so.3

2) ARMv4T - Little-Endian, Soft-Float, GLIBC
   Command-line option(s): -march=armv4t
   Sysroot subdirectory: armv4t/
   Dynamic linker: lib/ld-linux.so.3

3) ARMv7-A Thumb-2, Little-Endian, Soft-Float, GLIBC
   Command-line option(s): -mthumb -march=arm7-a
   Sysroot subdirectory: thumb2/
   Dynamic linker: lib/ld-linux.so.3

Instead of finding the external toolchain sysroot directory by grep'ing
the output of the $(TARGET_CC) -v command it might be better to use that
as an indication that the toolchain does support sysroot.  The actual
directory location can then be found using the -print-sysroot option.

$ arm-none-linux-gnueabi-gcc -print-sysroot
/home/bigguiness/CodeSourcery/Sourcery_G++_Lite/bin/../arm-none-linux-gnueabi/libc
$ arm-none-linux-gnueabi-gcc -print-sysroot -march=armv4t
/home/bigguiness/CodeSourcery/Sourcery_G++_Lite/bin/../arm-none-linux-gnueabi/libc/armv4t
$ arm-none-linux-gnueabi-gcc -print-sysroot -mthumb -march=armv7-a
/home/bigguiness/CodeSourcery/Sourcery_G++_Lite/bin/../arm-none-linux-gnueabi/libc/thumb2

This will allow the correct libraries to be copied to the staging
directory and avoid having to create a symlink to the directory
indicated by the --with-sysroot= configured option:

$ arm-none-linux-gnueabi-gcc -v 2>&1 | grep ^Configured | tr " " "\n" | grep -- "--with-sysroot" | cut -f2 -d=
/opt/codesourcery/arm-none-linux-gnueabi/libc

The -march= option also needs to be handled for the external
toolchain.  It appears to be done correctly in package/Makefile.in
when BR2_TOOLCHAIN_SOURCE is defined but not for external ones:

...
#########################################################################
ifeq ($(BR2_TOOLCHAIN_SOURCE),y)
...
CC_TARGET_ARCH_:=$(strip $(subst ",,$(BR2_GCC_TARGET_ARCH)))
...
ifneq ($(CC_TARGET_ARCH_),)
TARGET_CFLAGS+=-march=$(CC_TARGET_ARCH_)
endif
...
# else it's an external toolchain
#########################################################################
else
TARGET_CFLAGS=$(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING) --sysroot $(STAGING_DIR)/
...
endif
#########################################################################

The problem is I'm not really sure how to make the necessary changes.

Any ideas on how to make this work?

Regards,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Thomas Petazzoni]

Hello,

Thanks for all your researches, they are very interesting.

Le Thu, 20 Aug 2009 20:53:33 -0400,
"H Hartley Sweeten" <hartleys@visionengravers.com> a ?crit :

> The current external toolchain support doesn't appear to work
> correctly for a multilib toolchain. 

I've definitely never used multilib toolchains with the external
toolchain support. That's something that must be extended.

> Any ideas on how to make this work?

In the menuconfig, the CPU type can be specified in the ? Target
Architecture Variant ?, the value of this option can be used to call
-print-sysroot properly.

And as you said, the handling of ?Target Architecture Variant? is
currently incorrect for external toolchains.

Do you want me to work on this, or do you plan to work on it yourself ?

Sincerly,

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

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Friday, August 21, 2009 2:45 AM, Thomas Petazzoni wrote:
> Hello,
> 
> Thanks for all your researches, they are very interesting.

Right now I'm in a panic mode just trying to get it to work.

> 
> Le Thu, 20 Aug 2009 20:53:33 -0400,
> "H Hartley Sweeten" <hartleys@visionengravers.com> a ?crit :
> 
>>  The current external toolchain support doesn't appear to work
>> correctly for a multilib toolchain. 
> 
> I've definitely never used multilib toolchains with the external
> toolchain support. That's something that must be extended.
> 
> > Any ideas on how to make this work?
> 
> In the menuconfig, the CPU type can be specified in the ? Target
> Architecture Variant ?, the value of this option can be used to call
> -print-sysroot properly.

Does the -print-sysroot work and return the correct path on your
non-multilib external toolchain?

I already have the "Target Architecture Variant" and the other options
set correctly.

BR2_arm=y
BR2_ARM_TYPE="ARM920T"
BR2_ARM_EABIT=y
BR2_ARCH="arm"
BR2_ENDIAN="LITTLE"
BR2_GCC_TARGET_TUNE="arm920t"
BR2_GCC_TARGET_ARCH="armv4t"
BR2_GCC_TARGET_ABI="aapcs-linux"

> 
> And as you said, the handling of ?Target Architecture Variant? is
> currently incorrect for external toolchains.
> 
> Do you want me to work on this, or do you plan to work on it yourself ?

I'm still trying to get it to work but I'm a bit lost.  There are still
a bunch of things about makefiles and all the shell stuff in them that
I just don't get ;-).

The main problem I am having is modifying ext-tool.mk correctly.

If you have the time I would appreciate any help.  I can test anything
that you might suggest.

Thanks,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Thomas Petazzoni]

Le Fri, 21 Aug 2009 12:37:50 -0400,
"H Hartley Sweeten" <hartleys@visionengravers.com> a ?crit :

> Does the -print-sysroot work and return the correct path on your
> non-multilib external toolchain?

No, because this option has been added in gcc 4.4.x it seems. It might
be present in your Codesourcery toolchain even if it uses 4.3.x because
the patch might have been backported by Codesourcery.

Therefore, we'll have to come up with a smarter solution. We can try
-print-sysroot and if this option does not exist, fallback to the old
method. But that would not solve the case of people using a toolchain
with multilib but not supporting -print-sysroot. Maybe
-print-search-dirs is more widely available ?

> I'm still trying to get it to work but I'm a bit lost.  There are
> still a bunch of things about makefiles and all the shell stuff in
> them that I just don't get ;-).
> 
> The main problem I am having is modifying ext-tool.mk correctly.
> 
> If you have the time I would appreciate any help.  I can test anything
> that you might suggest.

If we come up with a strategy, I can happily implement it quickly in
ext-tool.mk. I've already downloaded and installed the same
Codesourcery toolchain as yours, in order to do some testing. But I'll
be quite busy the coming days, so I'm not sure how much time I'll be
able to spend on this right now.

In order to help you progressing, I've hacked two things (not ready for
the official version, but good for testing) :

 * A fix that makes sure that -march=armv4t is inside TARGET_CFLAGS,
   even in the external toolchain case

   http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=multilib-toolchain-fix&id=65ee9b3945a665f1279fa940b30818f4924acd31

 * A patch that uses -print-sysroot instead of $(CROSS)-gcc -v to
   detect the sysroot location

   http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=multilib-toolchain-fix&id=ee62af9871801f1d7892d21219c844ca86e034b8

The Buildroot pass on checking the external toolchain and copying the
sysroot directory succeeds. But later on, while configuring the first
package, I get :

configure:1719: /usr/local/xtools/arm-2009q1/bin/arm-none-linux-gnueabi-gcc -Os -pipe -Os  -mtune=arm920t -march=armv4t -mabi=aapcs-linux -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot /home/thomas/local/buildroot-codesourcery/build_arm/staging_dir/    conftest.c  >&5
/usr/local/xtools/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: crt1.o: No such file: No such file or directory
collect2: ld returned 1 exit status

And this is probably because in the multilib case, the value returned
by -print-sysroot doesn't contain all the sysroot. For example, in my
case, /usr/local/xtools/arm-2009q1/bin/../arm-none-linux-gnueabi/libc/armv4t
(the sysroot returned by -print-sysroot with -march=armv4t) does not
contain the headers of the C library. They are
in /usr/local/xtools/arm-2009q1/arm-none-linux-gnueabi/libc/usr/include,
which is the sysroot of the !armv4t case.

So obviously, our method of simply copying one sysroot directory is not
sufficient.

Sincerly,

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

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Fri 8/21/2009 7:19 PM, Thomas Petazzoni wrote:

This reply might be a bit messed up.  I'm replying thru a web-mail
interface.

>> Does the -print-sysroot work and return the correct path on your
>> non-multilib external toolchain?
>
> No, because this option has been added in gcc 4.4.x it seems. It might
> be present in your Codesourcery toolchain even if it uses 4.3.x because
> the patch might have been backported by Codesourcery.

Dang.  That would have mad it easier...

> Therefore, we'll have to come up with a smarter solution. We can try
> -print-sysroot and if this option does not exist, fallback to the old
> method. But that would not solve the case of people using a toolchain
> with multilib but not supporting -print-sysroot. Maybe
> -print-search-dirs is more widely available ?

As least with the CodeSourcery toolchain that probably will not work.
-print-search-dirs outputs all the available directories.  I'm not
at work right now to verify but I think it outputs them in this order:

1) all the directories used by the -march=??? option
2) all the default directories (no -march=??? option)

>> I'm still trying to get it to work but I'm a bit lost.  There are
>> still a bunch of things about makefiles and all the shell stuff in
>> them that I just don't get ;-).
>> 
>> The main problem I am having is modifying ext-tool.mk correctly.
>> 
>> If you have the time I would appreciate any help.  I can test anything
>> that you might suggest.
>
> If we come up with a strategy, I can happily implement it quickly in
> ext-tool.mk. I've already downloaded and installed the same
> Codesourcery toolchain as yours, in order to do some testing. But I'll
> be quite busy the coming days, so I'm not sure how much time I'll be
> able to spend on this right now.
> 
> In order to help you progressing, I've hacked two things (not ready for
> the official version, but good for testing) :
> 
>  * A fix that makes sure that -march=armv4t is inside TARGET_CFLAGS,
>    even in the external toolchain case
> 
>    http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=multilib-toolchain-fix&id=65ee9b3945a665f1279fa940b30818f4924acd31
> 
>  * A patch that uses -print-sysroot instead of $(CROSS)-gcc -v to
>    detect the sysroot location
> 
>    http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=multilib-toolchain-fix&id=ee62af9871801f1d7892d21219c844ca86e034b8

I'll pull those patches tomorrow and see how they compare to what I've
got so far.
 
> The Buildroot pass on checking the external toolchain and copying the
> sysroot directory succeeds. But later on, while configuring the first
> package, I get :
> 
> configure:1719: /usr/local/xtools/arm-2009q1/bin/arm-none-linux-gnueabi-gcc -Os -pipe -Os  -mtune=arm920t -march=armv4t -mabi=aapcs-linux -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot /home/thomas/local/buildroot-codesourcery/build_arm/staging_dir/    conftest.c  >&5
> /usr/local/xtools/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: crt1.o: No such file: No such file or directory
> collect2: ld returned 1 exit status
> 
> And this is probably because in the multilib case, the value returned
> by -print-sysroot doesn't contain all the sysroot. For example, in my
> case, /usr/local/xtools/arm-2009q1/bin/../arm-none-linux-gnueabi/libc/armv4t
> (the sysroot returned by -print-sysroot with -march=armv4t) does not
> contain the headers of the C library. They are
> in /usr/local/xtools/arm-2009q1/arm-none-linux-gnueabi/libc/usr/include,
> which is the sysroot of the !armv4t case.
> 
> So obviously, our method of simply copying one sysroot directory is not
> sufficient.

I saw that also.  The -print-sysroot does give you the location of the
correct libraries that need to be copied to the target but not all the
stuff that's needed for the build.  Those files are available at the
patch returned by the --with-sysroot config option.  But, the libraries
are not correct for the multilib.  It appears that if you don't pass the
--sysroot $(STAGING_DIR)/ option the -march= option will correctly setup
the library and file locations.  But with the --sysroot ... option it
doesn't.  it appears to be assuming that "you" have correctly setup all
the paths.

Getting the correct files into the $(TARGET_DIR) doesn't seem to be a
problem.  The issue is with $(STAGING_DIR).  Maybe it would be better not
to copy the files and just let the compiler work it out based on the
-march= option?

I'll be back in the office tomorrow to look this over again.  If you have
anything else I'll try it.

Regards,
Hartley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20090821/d2dcfb66/attachment-0001.htm>

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Thomas Petazzoni]

Le Fri, 21 Aug 2009 23:08:29 -0400,
"H Hartley Sweeten" <hartleys@visionengravers.com> a ?crit :

> I'll pull those patches tomorrow and see how they compare to what I've
> got so far.

If you've already pulled something, please discard. I've rebased this
branch with new fixes (see below).

> I saw that also.  The -print-sysroot does give you the location of the
> correct libraries that need to be copied to the target but not all the
> stuff that's needed for the build.  Those files are available at the
> patch returned by the --with-sysroot config option.  But, the
> libraries are not correct for the multilib.  It appears that if you
> don't pass the --sysroot $(STAGING_DIR)/ option the -march= option
> will correctly setup the library and file locations.  But with the
> --sysroot ... option it doesn't.  it appears to be assuming that
> "you" have correctly setup all the paths.
> 
> Getting the correct files into the $(TARGET_DIR) doesn't seem to be a
> problem.  The issue is with $(STAGING_DIR).  Maybe it would be better
> not to copy the files and just let the compiler work it out based on
> the -march= option?

Unfortunately, this is the approach we tried at the beginning of
external toolchain support, but that didn't work for various reasons
that I can't remember.

I've updated the fix on external toolchain support, with two
improvements:

 1. We now don't pass -march= when doing CROSS-gcc -print-sysroot. The
    effect with the Codesourcery toolchain is that it returns the
    default, main sysroot, that includes everything necessary regardless
    of the selected architecture (armv4t, thumb2, etc.).

 2. If -print-sysroot doesn't return anything, we fallback to the old
    way.

With this fix I'm able to build a simple system with ncurses and sed
(just some random packages), both with the Codesoucery toolchain and a
Crosstool-NG toolchain.

Would you mind testing this new fix, and see if it works for you ?

Sincerly,

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

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Saturday, August 22, 2009 1:55 AM, Thomas Petazzoni wrote:
>> I'll pull those patches tomorrow and see how they compare to what I've
>> got so far.
>
> If you've already pulled something, please discard. I've rebased this
> branch with new fixes (see below).

Got a late start so I haven't pulled anything.

>> I saw that also.  The -print-sysroot does give you the location of the
>> correct libraries that need to be copied to the target but not all the
>> stuff that's needed for the build.  Those files are available at the
>> patch returned by the --with-sysroot config option.  But, the
>> libraries are not correct for the multilib.  It appears that if you
>> don't pass the --sysroot $(STAGING_DIR)/ option the -march= option
>> will correctly setup the library and file locations.  But with the
>> --sysroot ... option it doesn't.  it appears to be assuming that
>> "you" have correctly setup all the paths.
>> 
>> Getting the correct files into the $(TARGET_DIR) doesn't seem to be a
>> problem.  The issue is with $(STAGING_DIR).  Maybe it would be better
>> not to copy the files and just let the compiler work it out based on
>> the -march= option?
>
> Unfortunately, this is the approach we tried at the beginning of
> external toolchain support, but that didn't work for various reasons
> that I can't remember.

OK. Scratch that idea..

> I've updated the fix on external toolchain support, with two
> improvements:
>
> 1. We now don't pass -march= when doing CROSS-gcc -print-sysroot. The
>    effect with the Codesourcery toolchain is that it returns the
>    default, main sysroot, that includes everything necessary regardless
>    of the selected architecture (armv4t, thumb2, etc.).
>
> 2. If -print-sysroot doesn't return anything, we fallback to the old
>    way.
>
> With this fix I'm able to build a simple system with ncurses and sed
> (just some random packages), both with the Codesoucery toolchain and a
> Crosstool-NG toolchain.
>
> Would you mind testing this new fix, and see if it works for you ?

No link?  Where can I get the fix to test?

Thanks,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Thomas Petazzoni]

Le Sat, 22 Aug 2009 18:53:34 -0400,
"H Hartley Sweeten" <hartleys@visionengravers.com> a ?crit :

> > Would you mind testing this new fix, and see if it works for you ?
> 
> No link?  Where can I get the fix to test?

Same place as the other fixes, in my multilib-toolchain-fix branch, at
http://git.buildroot.net/~tpetazzoni/git/buildroot/log/?h=multilib-toolchain-fix

The two commits are :
 http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=multilib-toolchain-fix&id=65ee9b3945a665f1279fa940b30818f4924acd31
 http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=multilib-toolchain-fix&id=2907415d82b7d306ca3f1f1ead0bbb0c7f1505c3

Sincerly,

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

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Saturday, August 22, 2009 11:17 PM, Thomas Petazzoni wrote:
>>> Would you mind testing this new fix, and see if it works for you ?
>> 
>> No link?  Where can I get the fix to test?
>
> Same place as the other fixes, in my multilib-toolchain-fix branch, at
> http://git.buildroot.net/~tpetazzoni/git/buildroot/log/?h=multilib-toolchain-fix

Sorry, I should have figured that out ;-)

> The two commits are :
>  http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=multilib-toolchain-fix&id=65ee9b3945a665f1279fa940b30818f4924acd31
>  http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=multilib-toolchain-fix&id=2907415d82b7d306ca3f1f1ead0bbb0c7f1505c3

Initially it looked like this might work.

But during the final linking of gettext (I think that's what was happening) I get:

/home/bigguiness/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-gcc  -Os  -mtune=arm920t -march=armv4t -mabi=aapcs-linux -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot /home/bigguiness/buildroot/build_arm/staging_dir/ -shared  .libs/allocsa.o .libs/backupfile.o .libs/addext.o .libs/basename.o .libs/c-ctype.o .libs/c-strcasecmp.o .libs/c-strncasecmp.o .libs/c-strcasestr.o .libs/c-strstr.o .libs/classpath.o .libs/clean-temp.o .libs/closeout.o .libs/copy-file.o .libs/csharpcomp.o .libs/csharpexec.o .libs/error-progname.o .libs/execute.o .libs/exitfail.o .libs/fatal-signal.o .libs/findprog.o .libs/fstrcmp.o .libs/full-write.o .libs/fwriteerror.o .libs/gcd.o .libs/hash.o .libs/javacomp.o .libs/javaexec.o .libs/javaversion.o .libs/linebreak.o .libs/gl_linkedhash_list.o .libs/gl_list.o .libs/localcharset.o .libs/lock.o .libs/mbswidth.o .libs/concatpath.o .libs/pipe.o .libs/progname.o .libs/progreloc.o .libs/propername.o .libs/quote.o .libs/quotearg.o .libs/sh-quote.o .libs/striconv.o .libs/strnlen1.o .libs/tls.o .libs/tmpdir.o .libs/wait-process.o .libs/xmalloc.o .libs/xstrdup.o .libs/xallocsa.o .libs/xerror.o .libs/xreadlink.o .libs/xsetenv.o .libs/xstriconv.o .libs/xvasprintf.o .libs/xasprintf.o .libs/argmatch.o .libs/fnmatch.o .libs/mbchar.o .libs/safe-read.o .libs/safe-write.o .libs/strstr.o  -L/home/bigguiness/buildroot/build_arm/staging_dir/usr/lib -L/usr/lib -lintl -lc  -mtune=arm920t -march=armv4t -mabi=aapcs-linux -msoft-float -Wl,-soname -Wl,libgettextlib-0.16.1.so -o .libs/libgettextlib-0.16.1.so/home/bigguiness/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: warning: library search path "/usr/lib" is unsafe for cross-compilation
/home/bigguiness/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/home/bigguiness/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: cannot find /lib/libc.so.6
collect2: ld returned 1 exit status
libtool: install: error: relink `libgettextlib.la' with the above command before installing it
make[5]: *** [install-libLTLIBRARIES] Error 1
make[5]: Leaving directory `/home/bigguiness/buildroot/build_arm/gettext-0.16.1/gettext-tools/gnulib-lib'
make[4]: *** [install-am] Error 2
make[4]: Leaving directory `/home/bigguiness/buildroot/build_arm/gettext-0.16.1/gettext-tools/gnulib-lib'
make[3]: *** [install] Error 2
make[3]: Leaving directory `/home/bigguiness/buildroot/build_arm/gettext-0.16.1/gettext-tools/gnulib-lib'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/home/bigguiness/buildroot/build_arm/gettext-0.16.1/gettext-tools'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/bigguiness/buildroot/build_arm/gettext-0.16.1'
make: *** [/home/bigguiness/buildroot/build_arm/staging_dir/usr/bin/gettext] Error 2

I'll try to prune down my rootfs to see if I can at least get the system to boot.

Regards,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Saturday, August 22, 2009 11:17 PM, Thomas Petazzoni wrote:
>>> Would you mind testing this new fix, and see if it works for you ?
>> 
>> No link?  Where can I get the fix to test?
>
> Same place as the other fixes, in my multilib-toolchain-fix branch, at
> http://git.buildroot.net/~tpetazzoni/git/buildroot/log/?h=multilib-toolchain-fix
>
> The two commits are :
>  http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=multilib-toolchain-fix&id=65ee9b3945a665f1279fa940b30818f4924acd31
>  http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=multilib-toolchain-fix&id=2907415d82b7d306ca3f1f1ead0bbb0c7f1505c3

Thomas,

I stripped my packages down to the following:

BR2_PACKAGE_BUSYBOX=y
BR2_BUSYBOX_VERSION_1_13_X=y
BR2_BUSYBOX_VERSION="1.13.4"
BR2_PACKAGE_BUSYBOX_FULLINSTALL=y
BR2_PACKAGE_BUSYBOX_CONFIG="local/ep9307/busybox-1.13.4.config"
BR2_HOST_FAKEROOT=y
BR2_PACKAGE_LZO=y
BR2_PACKAGE_ZLIB=y

Everything seems to build fine but the system still crashes when
trying to run /sbin/init.  I have CONFIG_DEBUG_USER=y in my kernel
and passed "user_debug=31" in my kernel command line.  With that
I get:

rtc-isl1208 0-006f: setting system clock to 2009-08-24 09:30:58 UTC (1251106258)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing init memory: 120K
run_init_process: /sbin/init
init (1): undefined instruction: pc=400160cc
Code: 02800004 0afffff9 e2621000 e0022001 (e16f2f12)
Kernel panic - not syncing: Attempted to kill init!
[<c002ca90>] (unwind_backtrace+0x0/0xdc) from [<c02943dc>] (panic+0x48/0x120)
[<c02943dc>] (panic+0x48/0x120) from [<c0048430>] (do_exit+0x64/0x608)
[<c0048430>] (do_exit+0x64/0x608) from [<c0048a84>] (do_group_exit+0xb0/0xe4)
[<c0048a84>] (do_group_exit+0xb0/0xe4) from [<c0052cc4>] (get_signal_to_deliver+0x384/0x3dc)
[<c0052cc4>] (get_signal_to_deliver+0x384/0x3dc) from [<c00295f8>] (do_signal+0x50/0x528)
[<c00295f8>] (do_signal+0x50/0x528) from [<c0026eac>] (work_pending+0x1c/0x20)

I'm not sure what the undefined instruction is but my guess is it's
an armv5t instruction which is the default library configuration for
the CodeSourcery toolchain.  Something is still not right.

It appears the libraries that get copied to rootfs are stripped so I
can't verify what they actually are.

An ideas?

Regards,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Monday, August 24, 2009 9:53 AM, H Hartley Sweeten wrote:
> On Saturday, August 22, 2009 11:17 PM, Thomas Petazzoni wrote:
>>>> Would you mind testing this new fix, and see if it works for you ?
>>> 
>>> No link?  Where can I get the fix to test?
>>
>> Same place as the other fixes, in my multilib-toolchain-fix branch, at
>> http://git.buildroot.net/~tpetazzoni/git/buildroot/log/?h=multilib-toolchain-fix
>>
>> The two commits are :
>>  http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=multilib-toolchain-fix&id=65ee9b3945a665f1279fa940b30818f4924acd31
>>  http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=multilib-toolchain-fix&id=2907415d82b7d306ca3f1f1ead0bbb0c7f1505c3
>
> Thomas,
> 
> I stripped my packages down to the following:
> 
> BR2_PACKAGE_BUSYBOX=y
> BR2_BUSYBOX_VERSION_1_13_X=y
> BR2_BUSYBOX_VERSION="1.13.4"
> BR2_PACKAGE_BUSYBOX_FULLINSTALL=y
> BR2_PACKAGE_BUSYBOX_CONFIG="local/ep9307/busybox-1.13.4.config"
> BR2_HOST_FAKEROOT=y
> BR2_PACKAGE_LZO=y
> BR2_PACKAGE_ZLIB=y
> 
> Everything seems to build fine but the system still crashes when
> trying to run /sbin/init.  I have CONFIG_DEBUG_USER=y in my kernel
> and passed "user_debug=31" in my kernel command line.  With that
> I get:
> 
> rtc-isl1208 0-006f: setting system clock to 2009-08-24 09:30:58 UTC (1251106258)
> RAMDISK: gzip image found at block 0
> VFS: Mounted root (ext2 filesystem) on device 1:0.
> Freeing init memory: 120K
> run_init_process: /sbin/init
> init (1): undefined instruction: pc=400160cc
> Code: 02800004 0afffff9 e2621000 e0022001 (e16f2f12)
> Kernel panic - not syncing: Attempted to kill init!
> [<c002ca90>] (unwind_backtrace+0x0/0xdc) from [<c02943dc>] (panic+0x48/0x120)
> [<c02943dc>] (panic+0x48/0x120) from [<c0048430>] (do_exit+0x64/0x608)
> [<c0048430>] (do_exit+0x64/0x608) from [<c0048a84>] (do_group_exit+0xb0/0xe4)
> [<c0048a84>] (do_group_exit+0xb0/0xe4) from [<c0052cc4>] (get_signal_to_deliver+0x384/0x3dc)
> [<c0052cc4>] (get_signal_to_deliver+0x384/0x3dc) from [<c00295f8>] (do_signal+0x50/0x528)
> [<c00295f8>] (do_signal+0x50/0x528) from [<c0026eac>] (work_pending+0x1c/0x20)
> 
> I'm not sure what the undefined instruction is but my guess is it's
> an armv5t instruction which is the default library configuration for
> the CodeSourcery toolchain.  Something is still not right.
> 
> It appears the libraries that get copied to rootfs are stripped so I
> can't verify what they actually are.
> 
> An ideas?

As a brute-force test, I tried replacing the files in $(TARGET_DIR)/lib
with the files in $(SYSROOT_DIR)/armv4t/lib.  With just that it appears
/sbin/init executes but some other command fails:

VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing init memory: 120K
run_init_process: /sbin/init
usb 1-1: configuration #1 chosen from 1 choice
input: HID 04d9:1203 as /devices/platform/ep93xx-ohci/usb1/1-1/1-1:1.0/input/input2
generic-usb 0003:04D9:1203.0001: input: USB HID v1.11 Keyboard [HID 04d9:1203] on usb-ep93xx-1/input0
input: HID 04d9:1203 as /devices/platform/ep93xx-ohci/usb1/1-1/1-1:1.1/input/input3
generic-usb 0003:04D9:1203.0002: input: USB HID v1.11 Device [HID 04d9:1203] on usb-ep93xx-1/input1
rcS (430): undefined instruction: pc=0007514c
Code: e1530001 9a00006f e1110002 0a000071 (e16f2f13)
can't open /dev/tty1: No such file or directory
can't open /dev/tty2: No such file or directory
can't open /dev/ttyAM0: No such file or directory
can't open /dev/ttyAM1: No such file or directory
can't open /dev/ttyAM2: No such file or directory

The "can't open ..." messages then keep repeating.

Regards,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

Hello Thomas, 

Well, I have verified that the 2.6.30.5 kernel compiled with the
CodeSourcery toolchain is not the issue.

I finally found an old rootfs on my system that was originally
built for kernel 2.6.20.4 with the oabi toolchain provided by
Cirrus Logic.  That rootfs starts fine until the init process
tries to load a kernel module then it of course dies.  But the
other init shells start fine and busybox works on those terminals:
  tty1 - on-board LCD controller + USB keyboard
  tty2 - on-board LCD controller + USB keyboard
  ttyAM0 - UART0 serial port

My boot terminal is actually ttyAM2, that's the one that locks up.
Here's part of the boot messages.

Linux version 2.6.30.5 (bigguiness at etch) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #13 PREEMPT Mon Aug 24 09:42:11 MST 2009
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
CPU: VIVT data cache, VIVT instruction cache
Machine: Vision Engraving Systems EP9307 SoM
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16192
Kernel command line: root=/dev/ram console=ttyAM2 video=ep93xx-fb:640x480-16 at 60
...
Console: switching to colour frame buffer device 80x30
graphics fb0: registered. Mode = 640x480-16
Serial: AMBA driver
apb:uart1: ttyAM0 at MMIO 0x808c0000 (irq = 52) is a AMBA
apb:uart2: ttyAM1 at MMIO 0x808d0000 (irq = 54) is a AMBA
apb:uart3: ttyAM2 at MMIO 0x808e0000 (irq = 55) is a AMBA
console [ttyAM2] enabled
...
RAMDISK: gzip image found at block 0
usb 1-1: configuration #1 chosen from 1 choice
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing init memory: 120K
input: HID 04d9:1203 as /devices/platform/ep93xx-ohci/usb1/1-1/1-1:1.0/input/input2
generic-usb 0003:04D9:1203.0001: input: USB HID v1.11 Keyboard [HID 04d9:1203] on usb-ep93xx-1/input0
input: HID 04d9:1203 as /devices/platform/ep93xx-ohci/usb1/1-1/1-1:1.1/input/input3
generic-usb 0003:04D9:1203.0002: input: USB HID v1.11 Device [HID 04d9:1203] on usb-ep93xx-1/input1
run_init_process: /sbin/init
lirc_edb9307A: version magic '2.6.20.4 preempt mod_unload ARMv4 ' should be '2.6.30.5 preempt mod_unload ARMv4 '

I have been messing around with ext-tool.mk and package/Makefile.in
trying to figure out what is missing/needed to get the external
multilib toolchain to work correctly.  Unfortunately I think I'm
way over my head.

Have you had any other ideas on this?

Thanks for all your help,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

Thomas,

I found this FAQ on the CodeSourcery website.

Installing CodeSourcery Run-time Libraries
http://www.codesourcery.com/sgpp/lite/arm/portal/kbentry48

Would this simplify copying the external toolchain libraries
to the target rootfs?

What was the original problem with using the external toolchain
from it's installed location?  Why do the files need to be
copied to $(STAGING_DIR) and the flag "--sysroot $(STAGING_DIR)"
added to the TARGET_*FLAGS.

If the external toolchain is used from the install location I
think the -march= option will correctly setup the library paths
and allow the multilib toolchain to work correctly.  I believe
this is how the kernel build works.

Regards,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Bernhard Reutner-Fischer]

On Tue, Aug 25, 2009 at 01:48:21PM -0400, H Hartley Sweeten wrote:
>Thomas,
>
>I found this FAQ on the CodeSourcery website.
>
>Installing CodeSourcery Run-time Libraries
>http://www.codesourcery.com/sgpp/lite/arm/portal/kbentry48
>
>Would this simplify copying the external toolchain libraries
>to the target rootfs?
>
>What was the original problem with using the external toolchain
>from it's installed location?  Why do the files need to be
>copied to $(STAGING_DIR) and the flag "--sysroot $(STAGING_DIR)"
>added to the TARGET_*FLAGS.
>
>If the external toolchain is used from the install location I
>think the -march= option will correctly setup the library paths
>and allow the multilib toolchain to work correctly.  I believe
>this is how the kernel build works.

except that the kernel won't link against those helper-libs as opposed
to userspace which will need some of those libs on the rootfs.

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Tuesday, August 25, 2009 12:02 PM, Bernhard Reutner-Fischer wrote:
> On Tue, Aug 25, 2009 at 01:48:21PM -0400, H Hartley Sweeten wrote:
>> Thomas,
>>
>> I found this FAQ on the CodeSourcery website.
>> 
>> Installing CodeSourcery Run-time Libraries
>> http://www.codesourcery.com/sgpp/lite/arm/portal/kbentry48
>> 
>> Would this simplify copying the external toolchain libraries
>> to the target rootfs?
>> 
>> What was the original problem with using the external toolchain
>> from it's installed location?  Why do the files need to be
>> copied to $(STAGING_DIR) and the flag "--sysroot $(STAGING_DIR)"
>> added to the TARGET_*FLAGS.
>> 
>> If the external toolchain is used from the install location I
>> think the -march= option will correctly setup the library paths
>> and allow the multilib toolchain to work correctly.  I believe
>> this is how the kernel build works.
> 
> except that the kernel won't link against those helper-libs as opposed
> to userspace which will need some of those libs on the rootfs.

I agree that the kernel does not link against the helper-libs in the
toolchain.

I also agree that those libs need to be copied to the rootfs.

What I don't understand is why they need to be copied to $(STAGING_DIR)
and then needing to re-direct the --sysroot to them.  The only comment
about this in ext-tool.mk says:

#  3. Copy the libraries and headers to the staging directory. This
#  will allow all further calls to gcc to be made using --sysroot
#  $(STAGING_DIR), which greatly simplifies the compilation of the
#  packages when using external toolchains. So in the end, only the
#  cross-compiler binaries remains external, all libraries and headers
#  are imported into the Buildroot tree.

The question is "how" does this actually simplify the compilation?

Thanks,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Peter Korsgaard]

>>>>> "H" == H Hartley Sweeten <hartleys@visionengravers.com> writes:

Hi,

 H> What I don't understand is why they need to be copied to $(STAGING_DIR)
 H> and then needing to re-direct the --sysroot to them.  The only comment
 H> about this in ext-tool.mk says:

I didn't write the external toolchain support, but I guess it's
because the individual packages wants to install their libraries /
headers, and it's a lot simpler (E.G. similar to the internal
toolchain) if everything is together in a single directory tree
instead of 2 trees.

-- 
Bye, Peter Korsgaard

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Wednesday, August 26, 2009 1:45 PM, Peter Korsgaard wrote:
>> What I don't understand is why they need to be copied to $(STAGING_DIR)
>> and then needing to re-direct the --sysroot to them.  The only comment
>> about this in ext-tool.mk says:
>
> I didn't write the external toolchain support, but I guess it's
> because the individual packages wants to install their libraries /
> headers, and it's a lot simpler (E.G. similar to the internal
> toolchain) if everything is together in a single directory tree
> instead of 2 trees.

Thanks for the information.

I've "almost" got the external toolchain stuff working with the
multilib CodeSourcery toolchain.

I started with the two commits Thomas Petrazzoni made:

> Same place as the other fixes, in my multilib-toolchain-fix branch, at
> http://git.buildroot.net/~tpetazzoni/git/buildroot/log/?h=multilib-toolchain-fix
> 
> The two commits are :
>  http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=multilib-toolchain-fix&id=65ee9b3945a665f1279fa940b30818f4924acd31
>  http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=multilib-toolchain-fix&id=2907415d82b7d306ca3f1f1ead0bbb0c7f1505c3

There are still a couple of issues with the external multilib toolchain
support.

1) The commit to improve SYSROOT_DIR detection was not passing the -march=???
option when trying the -print-sysroot option.  This results in the "default"
sysroot directory getting returned which is effectivly the same as the one
found by --with-sysroot.

This was easily fixed by adding the following before the SYSROOT_DIR= stuff:

# We need to pass the -march= option in order to get the correct
# multilib sysroot with CROSS-gcc -print-sysroot.
ifneq ($(CC_TARGET_ARCH_),)
SYSROOT_CFLAGS=-march=$(CC_TARGET_ARCH_)
endif

Then changing the first SYSROOT_DIR= to:

SYSROOT_DIR=$(shell $(TARGET_CC) -print-sysroot $(SYSROOT_CFLAGS) 2>&1)

Now SYSROOT_DIR is the location of the correct files that need to be
copied to the target.

2) Not all the necessary sysroot files are getting copied to the target.

copy_toolchain_lib_root only copys the lib files.  According to the
CodeSourcery documentation the lib, usr/bin, and sbin files all need to
be copied to the target.  I couldn't figure out a clean way to do this
so I just hacked in the mkdir and cp commands and commented out the
for/call/done loop in ext-tool.mk.

3) The wrong files are getting copied to the staging directory.

The call to copy_toolchain_sysroot is passing SYSROOT_DIR that was
previously found above.  In the multilib toolchain case this will be
something like (in my case):

/home/bigguiness/CodeSourcery/Sourcery_G++_Lite/bin/../arm-none-linux-gnueabi/libc/armv4t

In that directory are etc, lib, sbin, and usr.  The copy_toolchain_sysroot
call copies all of these to $(STAGING_DIR).

But when the compiler is called with -march=armv4t --sysroot $(STAGING_DIR)
it trys to find the library files in $(STAGING_DIR)/armv4t/lib and
$(STAGING_DIR)/armv4t/usr/lib.

The correct directory that should have been copied to $(STAGING_DIR) is the
one that is found by the CROSS-gcc -v ... --with-sysroot value, which in my
case is:

/opt/codesourcery/arm-none-linux-gnueabi/libc

Which is a symlink to:

/home/bigguiness/CodeSourcery/Sourcery_G++_Lite/bin/../arm-none-linux-gnueabi/libc

This directory has armv4t, etc, lib, sbin, thumb2, and usr subdirectories in it.

To handle this I changed the second test to find the sysroot to WITH_SYSROOT_DIR.
If the test to find SYSROOT_DIR failed I set that equal to WITH_SYSROOT_DIR.

Now SYSROOT_DIR points to the necessary files for the target and
WITH_SYSROOT_DIR points to the files for STAGING_DIR.

Following is the modified patch:

---

diff a/toolchain/external-toolchain/ext-tool.mk b/toolchain/external-toolchain/ext-tool.mk
--- a/toolchain/external-toolchain/ext-tool.mk
+++ b/toolchain/external-toolchain/ext-tool.mk
@@ -205,12 +205,26 @@
 EXTERNAL_LIBS+=libstdc++.so
 endif
 
-SYSROOT_DIR=$(shell LANG=C $(TARGET_CC) -v 2>&1 | grep ^Configured | tr " " "\n" | grep -- "--with-sysroot" | cut -f2 -d=)
+# We need to pass the -march= option in order to get the correct
+# multilib sysroot with CROSS-gcc -print-sysroot.
+ifneq ($(CC_TARGET_ARCH_),)
+SYSROOT_CFLAGS=-march=$(CC_TARGET_ARCH_)
+endif
+
+# SYSROOT_DIR selection. We first try the -print-sysroot option,
+# available in gcc 4.4.x and in some CodeSourcery toolchains. If this
+# option is not available, we fallback to the value of --with-sysroot
+# as visible in CROSS-gcc -v.
+SYSROOT_DIR=$(shell $(TARGET_CC) -print-sysroot $(SYSROOT_CFLAGS) 2>&1)
+WITH_SYSROOT_DIR=$(shell LANG=C $(TARGET_CC) -v 2>&1 | grep ^Configured | tr " " "\n" | grep -- "--with-sysroot" | cut -f2 -d=)
+ifeq ($(SYSROOT_DIR),)
+SYSROOT_DIR=$(WITH_SYSROOT_DIR)
+endif
 
 $(STAMP_DIR)/ext-toolchain-installed:
 	@echo "Checking external toolchain settings"
 	$(Q)$(call check_cross_compiler_exists)
-ifeq ($(strip $(SYSROOT_DIR)),)
+ifeq ($(strip $(WITH_SYSROOT_DIR)),)
 	@echo "External toolchain doesn't support --sysroot. Cannot use."
 	exit 1
 endif
@@ -224,9 +238,19 @@
 endif
 	mkdir -p $(TARGET_DIR)/lib
 	@echo "Copy external toolchain libraries to target..."
-	$(Q)for libs in $(EXTERNAL_LIBS); do \
-		$(call copy_toolchain_lib_root,$(SYSROOT_DIR),$$libs,/lib,$(BR2_TOOLCHAIN_EXTERNAL_STRIP)); \
-	done
+#	$(Q)for libs in $(EXTERNAL_LIBS); do \
+#		$(call copy_toolchain_lib_root,$(SYSROOT_DIR),$$libs,/lib,$(BR2_TOOLCHAIN_EXTERNAL_STRIP)); \
+#	done
+	# HACK
+	# Copy all the lib, usr/bin, and /sbin files from the sysroot
+	# to the target.
+	cp -d $(SYSROOT_DIR)/lib/* $(TARGET_DIR)/lib
+	mkdir -p $(TARGET_DIR)/usr
+	mkdir -p $(TARGET_DIR)/usr/bin
+	cp -d $(SYSROOT_DIR)/usr/bin/* $(TARGET_DIR)/usr/bin
+	mkdir -p $(TARGET_DIR)/sbin
+	cp -d $(SYSROOT_DIR)/sbin/* $(TARGET_DIR)/sbin
+	# END HACK
 	@echo "Copy external toolchain sysroot to staging..."
-	$(Q)$(call copy_toolchain_sysroot,$(SYSROOT_DIR))
+	$(Q)$(call copy_toolchain_sysroot,$(WITH_SYSROOT_DIR))
 	@touch $@

---

I also have Thomas' second patch applied that takes into account the
architecture variant (-mtune=, -march=, -mabi=, etc.).  With that patch and
the modified patch above I can now build my rootfs and it "almost" works.

My kernel (2.6.30.5) starts up fine then trys to run /sbin/init.  It now
doesn't do a kernel panic but I get the following:

rtc-isl1208 0-006f: setting system clock to 2009-08-26 13:41:04 UTC (1251294064)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing init memory: 120K
run_init_process: /sbin/init
usb 1-1: configuration #1 chosen from 1 choice
input: HID 04d9:1203 as /devices/platform/ep93xx-ohci/usb1/1-1/1-1:1.0/input/input2
generic-usb 0003:04D9:1203.0001: input: USB HID v1.11 Keyboard [HID 04d9:1203] on usb-ep93xx-1/input0
input: HID 04d9:1203 as /devices/platform/ep93xx-ohci/usb1/1-1/1-1:1.1/input/input3
generic-usb 0003:04D9:1203.0002: input: USB HID v1.11 Device [HID 04d9:1203] on usb-ep93xx-1/input1
rcS (430): undefined instruction: pc=0007514c
Code: e1530001 9a00006f e1110002 0a000071 (e16f2f13)

Please press Enter to activate this console.

Every time I press Enter after that I get:

sh (441): undefined instruction: pc=0007514c
Code: e1530001 9a00006f e1110002 0a000071 (e16f2f13)

Please press Enter to activate this console.

I'm not sure how to figure out what the undefined instruction was but my
guess is it's an ARMv5T instruction.  It seems like something in the busybox
build did not honor the TARGET_CFLAGS that were setup for my build.

TARGET_CFLAGS= -Os -mtune=arm920t -march=armv4t -mabi=aapcs-linux -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot /home/bigguiness/buildroot/build_arm/staging_dir/

Does anyone have any ideas on this?

Regards,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Bernhard Reutner-Fischer]

On Wed, Aug 26, 2009 at 05:50:55PM -0400, H Hartley Sweeten wrote:
>diff a/toolchain/external-toolchain/ext-tool.mk b/toolchain/external-toolchain/ext-tool.mk
>--- a/toolchain/external-toolchain/ext-tool.mk
>+++ b/toolchain/external-toolchain/ext-tool.mk
>@@ -205,12 +205,26 @@
> EXTERNAL_LIBS+=libstdc++.so
> endif
> 
>-SYSROOT_DIR=$(shell LANG=C $(TARGET_CC) -v 2>&1 | grep ^Configured | tr " " "\n" | grep -- "--with-sysroot" | cut -f2 -d=)
>+# We need to pass the -march= option in order to get the correct
>+# multilib sysroot with CROSS-gcc -print-sysroot.
>+ifneq ($(CC_TARGET_ARCH_),)
>+SYSROOT_CFLAGS=-march=$(CC_TARGET_ARCH_)
>+endif

Not that i'd care, but you should always check against (and of course
use) the full set of flags anyway.

>Every time I press Enter after that I get:
>
>sh (441): undefined instruction: pc=0007514c
>Code: e1530001 9a00006f e1110002 0a000071 (e16f2f13)
>
>Please press Enter to activate this console.
>
>I'm not sure how to figure out what the undefined instruction was but my
>guess is it's an ARMv5T instruction.  It seems like something in the busybox
>build did not honor the TARGET_CFLAGS that were setup for my build.
>
>TARGET_CFLAGS= -Os -mtune=arm920t -march=armv4t -mabi=aapcs-linux -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot /home/bigguiness/buildroot/build_arm/staging_dir/
>
>Does anyone have any ideas on this?

see above. Sounds most likely like an incorrectly used toolchain. I'd
usually say that you should go bug the people who provide that
toolchain (or use the internal toolchain ;), but i'm pretty sure that
in this particular case you just use it incorrectly.

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Thursday, August 27, 2009 12:50 AM, Bernhard Reutner-Fischer wrote:
> On Wed, Aug 26, 2009 at 05:50:55PM -0400, H Hartley Sweeten wrote:
>> diff a/toolchain/external-toolchain/ext-tool.mk b/toolchain/external-toolchain/ext-tool.mk
>> --- a/toolchain/external-toolchain/ext-tool.mk
>> +++ b/toolchain/external-toolchain/ext-tool.mk
>> @@ -205,12 +205,26 @@
>>  EXTERNAL_LIBS+=libstdc++.so
>>  endif
>>  
>> -SYSROOT_DIR=$(shell LANG=C $(TARGET_CC) -v 2>&1 | grep ^Configured | tr " " "\n" | grep -- "--with-sysroot" | cut -f2 -d=)
>> +# We need to pass the -march= option in order to get the correct
>> +# multilib sysroot with CROSS-gcc -print-sysroot.
>> +ifneq ($(CC_TARGET_ARCH_),)
>> +SYSROOT_CFLAGS=-march=$(CC_TARGET_ARCH_)
>> +endif
> 
> Not that i'd care, but you should always check against (and of course
> use) the full set of flags anyway.

For my particular toolchain the only option that determines the correct
sysroot for "my" architecture is the -march=armv4t one.  For complete
support I agree that all the flags should be used. But, TARGET_CFLAGS
can't be used since it includes "--sysroot $(STAGING_DIR)".

>> Every time I press Enter after that I get:
>>
>> sh (441): undefined instruction: pc=0007514c
>> Code: e1530001 9a00006f e1110002 0a000071 (e16f2f13)
>>
>> Please press Enter to activate this console.
>>
>> I'm not sure how to figure out what the undefined instruction was but my
>> guess is it's an ARMv5T instruction.  It seems like something in the busybox
>> build did not honor the TARGET_CFLAGS that were setup for my build.
>>
>> TARGET_CFLAGS= -Os -mtune=arm920t -march=armv4t -mabi=aapcs-linux -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot /home/bigguiness/buildroot/build_arm/staging_dir/
>> 
>> Does anyone have any ideas on this?
> 
> see above. Sounds most likely like an incorrectly used toolchain. I'd
> usually say that you should go bug the people who provide that
> toolchain (or use the internal toolchain ;), but i'm pretty sure that
> in this particular case you just use it incorrectly.

I think I'm using the toolchain correctly.  If I create a dummy init program
and replace sbin/init with it I don't get any error messages.

I have narrowed down what application is dying during the init, it appears
to be hotplug.  The hotplug.mk file does the build by:

$(HOTPLUG_DIR)/hotplug: $(HOTPLUG_DIR)
	$(MAKE) CROSS=$(TARGET_CROSS) DEBUG=false KLIBC=false \
	    KERNEL_INCLUDE_DIR=$(STAGING_DIR)/usr/include \
	    TARGET_DIR=$(TARGET_DIR) -C $(HOTPLUG_DIR)
	$(STRIPCMD) $(HOTPLUG_DIR)/hotplug
	touch -c $(HOTPLUG_DIR)/hotplug

TARGET_CFLAGS is not passed to the underlying Makefile.  The Makefile then appends
a number of options to CFLAGS and does:

hotplug: hotplug.c
	$(CC) $(CFLAGS) $(LDFLAGS) hotplug.c -o hotplug
	$(STRIPCMD) hotplug

End of the day this all boils down to the following on my system:

/usr/bin/make -j1 CROSS=/home/bigguiness/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- DEBUG=false KLIBC=false \
            KERNEL_INCLUDE_DIR=/home/bigguiness/buildroot/build_arm/staging_dir/usr/include \
            TARGET_DIR=/home/bigguiness/buildroot/project_build_arm/ep9307/root -C /home/bigguiness/buildroot/build_arm/diethotplug-0.5
make[1]: Entering directory `/home/bigguiness/buildroot/build_arm/diethotplug-0.5'
/home/bigguiness/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-gcc -pipe -Wall -Wshadow -Wstrict-prototypes -Os -fomit-frame-pointer -D_GNU_SOURCE -s -Wl,-warn-common hotplug.c -o hotplug
/home/bigguiness/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-strip -s --remove-section=.note --remove-section=.comment hotplug
make[1]: Leaving directory `/home/bigguiness/buildroot/build_arm/diethotplug-0.5'
/home/bigguiness/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-strip --remove-section=.comment --remove-section=.note /home/bigguiness/buildroot/build_arm/diethotplug-0.5/hotplug
touch -c /home/bigguiness/buildroot/build_arm/diethotplug-0.5/hotplug

The -march=armv4t (and --sysroot for that matter) is missing.  I have looked at
a number of other packages and seen similar problems.  The only ones that appear
to be ok are the ones that use AUTOTARGETS since the .stamp_configured rule
uses $(TARGET_CONFIGURE_ENV) which has the correct flags.  This is assuming
that the ./configure step correctly passes the flags into the resulting Makefile.

So basically I'm still stuck... I can kind of see what the problem is but I'm
still not sure how to fix it...

Any ideas?

Regards,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Bernhard Reutner-Fischer]

On Fri, Aug 28, 2009 at 07:09:27PM -0400, H Hartley Sweeten wrote:
>On Thursday, August 27, 2009 12:50 AM, Bernhard Reutner-Fischer wrote:
>> On Wed, Aug 26, 2009 at 05:50:55PM -0400, H Hartley Sweeten wrote:
>>> diff a/toolchain/external-toolchain/ext-tool.mk b/toolchain/external-toolchain/ext-tool.mk
>>> --- a/toolchain/external-toolchain/ext-tool.mk
>>> +++ b/toolchain/external-toolchain/ext-tool.mk
>>> @@ -205,12 +205,26 @@
>>>  EXTERNAL_LIBS+=libstdc++.so
>>>  endif
>>>  
>>> -SYSROOT_DIR=$(shell LANG=C $(TARGET_CC) -v 2>&1 | grep ^Configured | tr " " "\n" | grep -- "--with-sysroot" | cut -f2 -d=)
>>> +# We need to pass the -march= option in order to get the correct
>>> +# multilib sysroot with CROSS-gcc -print-sysroot.
>>> +ifneq ($(CC_TARGET_ARCH_),)
>>> +SYSROOT_CFLAGS=-march=$(CC_TARGET_ARCH_)
>>> +endif
>> 
>> Not that i'd care, but you should always check against (and of course
>> use) the full set of flags anyway.
>
>For my particular toolchain the only option that determines the correct
>sysroot for "my" architecture is the -march=armv4t one.  For complete
>support I agree that all the flags should be used. But, TARGET_CFLAGS
>can't be used since it includes "--sysroot $(STAGING_DIR)".

If you would look at my tree then you would see why these live in
TARGET_CC_FLAGS, TARGET_LD_FLAGS :P
>
>>> Every time I press Enter after that I get:
>>>
>>> sh (441): undefined instruction: pc=0007514c
>>> Code: e1530001 9a00006f e1110002 0a000071 (e16f2f13)

>I have narrowed down what application is dying during the init, it appears
>to be hotplug.  The hotplug.mk file does the build by:

>The -march=armv4t (and --sysroot for that matter) is missing.  I have looked at
>a number of other packages and seen similar problems.  The only ones that appear
>to be ok are the ones that use AUTOTARGETS since the .stamp_configured rule
>uses $(TARGET_CONFIGURE_ENV) which has the correct flags.  This is assuming
>that the ./configure step correctly passes the flags into the resulting Makefile.
>
>So basically I'm still stuck... I can kind of see what the problem is but I'm
>still not sure how to fix it...

two options come to mind:
-) use busybox
-) use TARGET_CONFIGURE_ENV for "hotplug" (i.e. configure that package
correctly)
>
>Any ideas?

Your buildroot lacks some tweaks that you should pick from my tree
(IMO).

HTH,

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

Hello all,

Well, I spent the last three weeks trying to get the CodeSourcery G++ Lite
2009q1-203 multilib toolchain to work with buildroot.  I have reached the
end of what I can do to get it to work.

I'm in the process of building my own external toolchain with crosstool-ng.
Hopefully I will have better success with that.

I just wanted to summarize what I found trying to get this to work in case
someone else wants to figure out the issues.  Some of this may be a bit
wordy since I'm composing this from memory ;-).

---

1) The wrong library files get copied to the target directory.

The multilib toolchain has subdirectories for the various libraries that
it supports.  In the CodeSourcery 2009q1-203 case the supported systems
are:

	ARMv5T - Little-Endian, Soft-Float, GLIBC
	Command-line option(s): default
	Sysroot subdirectory: ./
	Dynamic linker: lib/ld-linux.so.3

	ARMv4T - Little-Endian, Soft-Float, GLIBC
	Command-line option(s): -march=armv4t
	Sysroot subdirectory: armv4t/
	Dynamic linker: lib/ld-linux.so.3

	ARMv7-A Thumb-2 - Little-Endian, Soft-Float, GLIBC
	Command-line option(s): -mthumb -march=armv7-a
	Sysroot subdirectory: thumb2/
	Dynamic linker: lib/ld-linux.so.3

The current external toolchain support calls the compiler with the -v option
and then greps out the --with-sysroot string to figure out where the
SYSROOT_DIR is located.  Unfortunately this directory is the location of the
default libraries that the compiler was created with.

To correctly get the location for the desired system libraries the compiler
can be called with the -print-sysroot option and the correct -march= option
for the system (~ is my home directory):

$ $ arm-none-linux-gnueabi-gcc -print-sysroot -march=armv4t
~/CodeSourcery/Sourcery_G++_Lite/bin/../arm-none-linux-gnueabi/libc
$ arm-none-linux-gnueabi-gcc -print-sysroot -march=armv4t
~/CodeSourcery/Sourcery_G++_Lite/bin/../arm-none-linux-gnueabi/libc/armv4t
$ arm-none-linux-gnueabi-gcc -print-sysroot -mthumb -march=armv7-a
~/CodeSourcery/Sourcery_G++_Lite/bin/../arm-none-linux-gnueabi/libc/thumb2

This gives the correct files for the target but I haven't figured out what
is needed to copy to the staging directory.  I think everything in the
sysroot needs to be copied but I haven't been able to get a bootable system
to work it all out.

2) A lot of the packages don't correctly use TARGET_CFLAGS as setup in
   package/Makefile.in.

This causes all sorts of problems.  The default libraries are for ARMv5T,
I need the -march=armv4t in order to correctly create code for my processor
(ep93xx).  Since the packages are not using the TARGET_CFLAGS the code
gets compiled then linked as armv5t which of course will not run correctly.

I was able to get the compiler to work correctly at one point but still had
problems with the linker.  I verified this by doing a clean "make V=1" and
then examining all the output.  I would see the -march=armv4t in all the
compile steps but it was missing in some of the link steps.  I think this 
was happening due to the following in TARGET_CONFIGURE_OPTS:

		AR="$(TARGET_AR)" \
		AS="$(TARGET_AS)" \
		LD="$(TARGET_LD)" \
		NM="$(TARGET_NM)" \
		CC="$(TARGET_CC) $(TARGET_CFLAGS)" \
		GCC="$(TARGET_CC) $(TARGET_CFLAGS)" \
		CPP="$(TARGET_CPP) $(TARGET_CFLAGS)" \
		CXX="$(TARGET_CXX) $(TARGET_CXXFLAGS)" \
		FC="$(TARGET_FC) $(TARGET_FCFLAGS)" \

If the package build used CC (or equiv.) for the link it would get the
necessary flags.  But if it used LD, no flags.

Then there are the packages that just use CROSS=$(TARGET_CROSS).  For
those packages none of the flags are getting passed.

Also, I'm not sure having the $(TARGET_CFLAGS) directly in CC, GCC, etc.
is correct.  At one point I got an error during the ./configure for one
of the packages due to a -V option passed to the compiler.  I think this
had something to due with determining the version of the compiler.  It
appears that the -V option must come at the start of the command line
with gcc.  Of course this could also be a problem with the ./configure
stuff.

3) Package libraries end up in the wrong directory in $(STAGING_DIR).

At one point I manually copied all the sysroot stuff into $(STAGING_DIR)
and the correct libraries for my system to $(TARGET_DIR).  But when I
started the build I ran into problems with some of the external libraries
(libusb for instance).  The error message was something about not locating
the library files.

I tried finding the libusb library and it was in $(STAGING_DIR)/lib and
not in $(STAGING_DIR)/armv4t/lib which is where the linker's path is
setup when the -march=armv4t option is used.

I manually moved the library files to $(STAGING_DIR)/armv4t/lib then
restarted the build.  This time the library file was located but when
the build tried to link the files I got an error message about the
library being incompatible.  I assume this was because the library was
compiled for armv5t an not armv4t.  This was probably due to the
problem listed above.

---

I hope this helps someone in trying to work out the external multilib
toolchain support.  I see that Thomas Petrazzoni is currently working on
some buildroot cleanup.  If any of that cleanup involves the external
toolchain support hopefully this information will help.

Regards,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Bernhard Reutner-Fischer]

On Thu, Sep 10, 2009 at 07:57:29PM -0400, H Hartley Sweeten wrote:

>I was able to get the compiler to work correctly at one point but still had
>problems with the linker.  I verified this by doing a clean "make V=1" and
>then examining all the output.  I would see the -march=armv4t in all the
>compile steps but it was missing in some of the link steps.  I think this 
>was happening due to the following in TARGET_CONFIGURE_OPTS:
>
>		AR="$(TARGET_AR)" \
>		AS="$(TARGET_AS)" \
>		LD="$(TARGET_LD)" \
>		NM="$(TARGET_NM)" \
>		CC="$(TARGET_CC) $(TARGET_CFLAGS)" \
>		GCC="$(TARGET_CC) $(TARGET_CFLAGS)" \
>		CPP="$(TARGET_CPP) $(TARGET_CFLAGS)" \
>		CXX="$(TARGET_CXX) $(TARGET_CXXFLAGS)" \
>		FC="$(TARGET_FC) $(TARGET_FCFLAGS)" \
>
>If the package build used CC (or equiv.) for the link it would get the
>necessary flags.  But if it used LD, no flags.

So whatever buildroot you're using it's handling flags in an incomplete
way (this is nothing new; see archives).
My tree does:

AUTO_CONFIGURE_TARGET=\
        $(TARGET_CONFIGURE_OPTS) \
        $(TARGET_CONFIGURE_ARGS) \
        $(TARGET_CONFIGURE_ENV) \
        $(if $(THIS_SRCDIR),$(THIS_SRCDIR)/,./)configure \
        --cache-file="$(PROJECT_BUILD_DIR)/tgt-config.cache" \
        --target=$(REAL_GNU_TARGET_NAME) \
        --host=$(REAL_GNU_TARGET_NAME) \
        --build=$(GNU_HOST_NAME)

TARGET_CONFIGURE_OPTS=\
        PATH=$(TARGET_PATH) \
        AR="$(TARGET_AR)" \
        AS="$(TARGET_AS)" \
        LD="$(TARGET_LD)$(if $(TARGET_LD_FLAGS), $(TARGET_LD_FLAGS))" \
        NM="$(TARGET_NM)" \
        CC="$(TARGET_CC)$(if $(TARGET_CC_FLAGS), $(TARGET_CC_FLAGS))" \
        GCC="$(TARGET_CC)$(if $(TARGET_CC_FLAGS), $(TARGET_CC_FLAGS))" \
        CPP="$(TARGET_CPP)$(if $(TARGET_CC_FLAGS), $(TARGET_CC_FLAGS))"
\
        CXX="$(if $(BR2_GCC_CROSS_CXX),$(TARGET_CXX)$(if
$(TARGET_CXXFLAGS), $(TARGET_CXXFLAGS)))" \
        GCJ="$(if $(BR2_GCC_CROSS_GCJ),$(TARGET_GCJ)$(if
$(TARGET_GCJFLAGS), $(TARGET_GCJFLAGS)))" \
        FC="$(TARGET_FC)$(if $(TARGET_FC_FLAGS), $(TARGET_FC_FLAGS))" \
        RANLIB="$(TARGET_RANLIB)" \

>
>Then there are the packages that just use CROSS=$(TARGET_CROSS).  For
>those packages none of the flags are getting passed.
>
>Also, I'm not sure having the $(TARGET_CFLAGS) directly in CC, GCC, etc.

care must be taken which stuff you put into CC (see above).
I think that i resorted to only putting the bare necessities in it.
Again, my tree:

ifeq ($(BR2_TOOLCHAIN_SOURCE),y)
TARGET_CFLAGS=
TARGET_LDFLAGS=
# flags that are inherent part of the tool
TARGET_CC_FLAGS=
TARGET_LD_FLAGS=

ifeq ($(BR2_TOOLCHAIN_SYSROOT),y)
TARGET_CC_FLAGS+= $(BR2_SYSROOT) $(BR2_ISYSROOT) -I=/usr/include
TARGET_LD_FLAGS+= $(BR2_SYSROOT)
else
# for old gcc's, as fallback
TARGET_CC_FLAGS+= -I$(STAGING_DIR)/usr/include -I$(STAGING_DIR)/include
endif
ifeq ($(BR2_ENABLE_MULTILIB),y)
TARGET_LD_FLAGS+= -L$(STAGING_DIR)/lib64 -L$(STAGING_DIR)/usr/lib64
endif
TARGET_LD_FLAGS+= -L$(STAGING_DIR)/lib -L$(STAGING_DIR)/usr/lib
TARGET_CFLAGS += $(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING)

ifeq ($(BR2_bfin),y)
CC_TARGET_CPU_SUB_:=$(strip $(subst ",,$(BR2_bfin_sirevision)))
#"))
CC_TARGET_CPU_SUB_:=$(if $(CC_TARGET_CPU_SUB_),-$(CC_TARGET_CPU_SUB_))
endif

##############################################################################
#disabled
ifneq (XXX,XXX)
# gcc configury --with-foo
CC_TARGET_CPU_:=$(strip $(subst ",,$(BR2_GCC_TARGET_CPU)))
#"))
CC_TARGET_TUNE_:=$(strip $(subst ",,$(BR2_GCC_TARGET_TUNE)))
#"))
CC_TARGET_ARCH_:=$(strip $(subst ",,$(BR2_GCC_TARGET_ARCH)))
#"))
CC_TARGET_ABI_:=$(strip $(subst ",,$(BR2_GCC_TARGET_ABI)))
#"))

# fixup for MOTOROLA
ifeq ($(BR2_m68k),y)
CC_TARGET_ARCH_:=$(filter-out cf m68k,$(CC_TARGET_ARCH_))
endif

ifneq ($(strip $(CC_TARGET_CPU_)),)
TARGET_CFLAGS+=-mcpu=$(CC_TARGET_CPU_)$(CC_TARGET_CPU_SUB_)
endif
ifneq ($(strip $(CC_TARGET_TUNE_)),)
TARGET_CFLAGS+=-mtune=$(CC_TARGET_TUNE_)
endif
ifneq ($(strip $(CC_TARGET_ARCH_)),)
TARGET_CFLAGS+=-march=$(CC_TARGET_ARCH_)
endif
ifneq ($(strip $(CC_TARGET_ABI_)),)
TARGET_CFLAGS+=-mabi=$(CC_TARGET_ABI_)
endif

endif


>is correct.  At one point I got an error during the ./configure for one
>of the packages due to a -V option passed to the compiler.  I think this
>had something to due with determining the version of the compiler.  It
>appears that the -V option must come at the start of the command line
>with gcc.  Of course this could also be a problem with the ./configure
>stuff.

gcc: '-V' must come at the start of the command line
so yes.

HTH,

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Friday, September 11, 2009 3:35 AM, Bernhard Reutner-Fischer wrote:
> So whatever buildroot you're using it's handling flags in an incomplete
> way (this is nothing new; see archives).
> My tree does:

Bernhard,

FWIW, my buildroot tree is 2009.11-git with some customization in
target/device for my platform.  Everything else is straight from the
git tree.

Where is your tree located?  Is it pullable?

Thanks,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Peter Korsgaard]

>>>>> "H" == H Hartley Sweeten <hartleys@visionengravers.com> writes:

Hi,

 H> FWIW, my buildroot tree is 2009.11-git with some customization in
 H> target/device for my platform.  Everything else is straight from the
 H> git tree.

 H> Where is your tree located?  Is it pullable?

Bernhard forked buildroot several years ago, so the differences between
his tree and the official one is unfortunately quite big.

Hopefully we can get him to contribute to the official tree again, now
that atleast some of the issues leading to the fork have been / are
getting resolved.

His tree is at:

git://repo.or.cz/buildroot

-- 
Bye, Peter Korsgaard

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Wednesday, August 19, 2009 2:31 PM, Thomas Petazzoni wrote:
>> The kernel and rootfs are both created with Buildroot.
>> 
>> For the kernel config I have:
>> 
>> CONFIG_AEABI=y
>> CONFIG_OABI_COMPAT=y
>> 
>> For buildroot's config I have:
>> 
>> # BR2_ARM_OABI is not set
>> BR2_ARM_EABI=y
>
> That's correct. When I fall into similar issue, I usually end up
> writing a very simple init program that does:
>
> int main(void)
> {
>	write(1, "Hello\n", 6);
>	while(1);
> }
>
> Compile it statically and put it in /sbin/init. Getting this first
> basic program to work is a first step.
>
>> Is there a similar configuration that needs to be set in Busybox?
>
> Not that I'm aware of.

Thomas,

Is it possible I need to pass the -march=armv4t flag to the compiler
in order to use the correct instruction set for my architecture?

If so, where do you set that in buildroot.  The kernel sets this
automatically.

Regards,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Daniel Mack]

On Wed, Aug 19, 2009 at 04:19:35PM -0400, H Hartley Sweeten wrote:
> On Wednesday, August 19, 2009 12:43 PM, Thomas Petazzoni wrote:
> >
> > Do you compile your kernel with Buildroot, or do you compile it
> > manually ? If compiled manually, is CONFIG_AEABI enabled in your kernel
> > configuration ?
> 
> The kernel and rootfs are both created with Buildroot.
> 
> For the kernel config I have:
> 
> CONFIG_AEABI=y
> CONFIG_OABI_COMPAT=y

Just a side note: for performance reasons, you shouldn't enable
OABI_COMPAT unless you really can't know which binaries the kernel will
execute.

See http://wiki.debian.org/ArmEabiPort for some more details.

Other than that, your problem could also be related to VFP emulation
issues. I had such awhile back.

Daniel

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[H Hartley Sweeten]

On Wednesday, August 19, 2009 3:14 PM, Daniel Mack wrote:
> On Wed, Aug 19, 2009 at 04:19:35PM -0400, H Hartley Sweeten wrote:
>> On Wednesday, August 19, 2009 12:43 PM, Thomas Petazzoni wrote:
>>>
>>> Do you compile your kernel with Buildroot, or do you compile it
>>> manually ? If compiled manually, is CONFIG_AEABI enabled in your kernel
>>> configuration ?
>> 
>> The kernel and rootfs are both created with Buildroot.
>> 
>> For the kernel config I have:
>> 
>> CONFIG_AEABI=y
>> CONFIG_OABI_COMPAT=y
>
> Just a side note: for performance reasons, you shouldn't enable
> OABI_COMPAT unless you really can't know which binaries the kernel will
> execute.

I had CONFIG_OABI_COMPAT disabled originally.  I just turned it on to see
if that helped.

> See http://wiki.debian.org/ArmEabiPort for some more details.

Thanks for the link.

> Other than that, your problem could also be related to VFP emulation
> issues. I had such awhile back.

What was your issue then?  Were you able to resolve it?

Right now I'm kind of stuck...

Thanks,
Hartley

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Daniel Mack]

On Wed, Aug 19, 2009 at 06:19:54PM -0400, H Hartley Sweeten wrote:
> On Wednesday, August 19, 2009 3:14 PM, Daniel Mack wrote:
> > On Wed, Aug 19, 2009 at 04:19:35PM -0400, H Hartley Sweeten wrote:
> >> On Wednesday, August 19, 2009 12:43 PM, Thomas Petazzoni wrote:
> >>>
> >>> Do you compile your kernel with Buildroot, or do you compile it
> >>> manually ? If compiled manually, is CONFIG_AEABI enabled in your kernel
> >>> configuration ?
> >> 
> >> The kernel and rootfs are both created with Buildroot.
> >> 
> >> For the kernel config I have:
> >> 
> >> CONFIG_AEABI=y
> >> CONFIG_OABI_COMPAT=y
> >
> > Just a side note: for performance reasons, you shouldn't enable
> > OABI_COMPAT unless you really can't know which binaries the kernel will
> > execute.
> 
> I had CONFIG_OABI_COMPAT disabled originally.  I just turned it on to see
> if that helped.
> 
> > See http://wiki.debian.org/ArmEabiPort for some more details.
> 
> Thanks for the link.
> 
> > Other than that, your problem could also be related to VFP emulation
> > issues. I had such awhile back.
> 
> What was your issue then?  Were you able to resolve it?

I would try the simple hello-world app Thomas suggested. There is always
a reason for why processes crash, and so there's always a solution ;)

Daniel

[Buildroot] equivalent of a 'make modules'

[Jeff Krasky]

Hello,

 

I am working with another program that builds itself against the kernel.  I
am using BuildRoot for making the kernel and filesystem.  It is believed
that the next step would be to do something like a "make modules" command so
that the kernel and filesystem can be rebuilt with this other program's
information in it.

 

In Buildroot, where I normally do the 'make' command, I tried 'make modules'
and got this message:

 

"No rule to make target 'modules'. Stop."

 

Is there an equivalent?

 

Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111122/44bd57ee/attachment.html>

[Buildroot] LIBFOO_SITE in .mk file

[Jeff Krasky]

The following is a message from yesterday.  It was the closest I have gotten
to both ethercat application and kernel modules being built.  As can be seen
from the last email I sent today, I can't build either one with the new .mk
file.  Something in that file only applies to buildroot-2011.11?

Can someone help out with what I had going yesterday?  The suggestions from
Thomas De Schampheleire helped to build the kernel modules, but in so doing
the application was no longer being built.  I will show both .mk files.  It
would get REALLY appreciated if someone would merge these for me somehow.

.mk file for building the application:


#############################################################
#
# EtherCAT
#
#############################################################
ETHERCAT_VERSION = 1.0
ETHERCAT_SOURCE = etherlabmaster-1.0.tar.bz2
###ETHERCAT_SITE = file:///home/user1/Desktop/EtherCAT4Atmel/
ETHERCAT_SITE = http://127.0.0.1/home/user1/Desktop/EtherCAT4Atmel/
ETHERCAT_AUTORECONF = YES
ETHERCAT_INSTALL_STAGING = YES

ETHERCAT_INSTALL_TARGET = YES
ETHERCAT_CONF_OPT = --enable-generic

$(eval $(call AUTOTARGETS,package,ethercat))




And here is the .mk for building the kernel module:

#############################################################
#
# EtherCAT
#
#############################################################
ETHERCAT_VERSION = 1.0
ETHERCAT_SOURCE = etherlabmaster-1.0.tar.bz2
###ETHERCAT_SITE = file:///home/user1/Desktop/EtherCAT4Atmel/
ETHERCAT_SITE = http://127.0.0.1/home/user1/Desktop/EtherCAT4Atmel/
ETHERCAT_AUTORECONF = YES
ETHERCAT_INSTALL_STAGING = YES

ETHERCAT_INSTALL_TARGET = YES
ETHERCAT_CONF_OPT = --enable-generic

###These next two lines were a part of building the kernel module.
ETHERCAT_DEPENDENCIES = linux
ETHERCAT_INSTALL_MOD_DIR = ethercat

# From here to the GENTARGETS line is part of building the kernel module.
define ETHERCAT_BUILD_CMDS
       $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) M=$(@D) modules
endef

define ETHERCAT_INSTALL_TARGET_CMDS
       $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) M=$(@D) \
               INSTALL_MOD_STRIP=1 \
               INSTALL_MOD_DIR=$(ETHERCAT_INSTALL_MOD_DIR) \
               modules_install
endef

define ETHERCAT_UNINSTALL_TARGET_CMDS
       rm -rf
$(TARGET_DIR)/lib/modules/$(LINUX26_VERSION_PROBED)/$(ETHERCAT_INSTALL_MOD_D
IR)
endef

$(eval $(call GENTARGETS,package,ethercat))











> You do realize that these rules are purely intended for the module, right.

No, I thought it would do both.  I have a second build running with both
$evals in it.  Hopefully that will do it.

> Based on what ThomasP says, things may be a little more complicated
> than I originally thought.

Do I need to separate sets of build rules in the .mk?

> Just checking: you are looking into output/target/lib/modules or
> /lib/modules on the target right, not /lib/modules on the host?

Correct, I am looking at /lib/modules when running the Linux image on the
target.

> If the modules_install step in your .mk file goes well, this should
> put the file there.

It did.  I just wrote a post about how it's there but the application isn't.

Thanks again.

[Buildroot] LIBFOO_SITE in .mk file

[Thomas De Schampheleire]

Jeff,

On Thu, Dec 1, 2011 at 11:56 PM, Jeff Krasky <jeff.krasky@dspcg.com> wrote:
> The following is a message from yesterday. ?It was the closest I have gotten
> to both ethercat application and kernel modules being built. ?As can be seen
> from the last email I sent today, I can't build either one with the new .mk
> file. ?Something in that file only applies to buildroot-2011.11?
>
> Can someone help out with what I had going yesterday? ?The suggestions from
> Thomas De Schampheleire helped to build the kernel modules, but in so doing
> the application was no longer being built. ?I will show both .mk files. ?It
> would get REALLY appreciated if someone would merge these for me somehow.
>

I have the impression you are missing some basic skills, and I really
think it will help you if you took the time to learn about them. For
example:
* how does make work and how are Makefiles organized
* what is a patch, how do you apply a patch

There is some information on patching here:
http://www.linuxchix.org/content/courses/kernel_hacking/lesson9
but take into account that some of it is specific to the linux kernel.


Regarding ethercat: what Thomas Petazzoni has provided you with is a
patch for the entire thing, application + drivers. It is based on a
clean 2011.11 release. Here is a step-by-step guide of things I think
you should do:

1. Start from a clean 2011.11 buildroot tarball (unpack it)
2. Move to the buildroot directory with cd
3. Apply the patch of ThomasP by saving the e-mail in text file format) and run:
patch -p1 < saved-email
You should see output like:
patching file package/Config.in
patching file package/igh-ethercat/Config.in
patching file package/igh-ethercat/igh-ethercat.mk

4. Configure buildroot properly (using make menuconfig) and don't
forget to enable the new igh-ethercat package, which is present under
'Networking applications'

5. Run 'make'.

That should be it. Buildroot will do all the rest for you and when the
build is done, you can test ethercat to see if everything works.

Best regards,
Thomas

[Buildroot] LIBFOO_SITE in .mk file

[Michael S. Zick]

On Fri December 2 2011, Thomas De Schampheleire wrote:
> Jeff,
> 
> On Thu, Dec 1, 2011 at 11:56 PM, Jeff Krasky <jeff.krasky@dspcg.com> wrote:
> > The following is a message from yesterday. ?It was the closest I have gotten
> > to both ethercat application and kernel modules being built. ?As can be seen
> > from the last email I sent today, I can't build either one with the new .mk
> > file. ?Something in that file only applies to buildroot-2011.11?
> >
> > Can someone help out with what I had going yesterday? ?The suggestions from
> > Thomas De Schampheleire helped to build the kernel modules, but in so doing
> > the application was no longer being built. ?I will show both .mk files. ?It
> > would get REALLY appreciated if someone would merge these for me somehow.
> >
> 
> I have the impression you are missing some basic skills, and I really
> think it will help you if you took the time to learn about them. For
> example:
> * how does make work and how are Makefiles organized
> * what is a patch, how do you apply a patch
> 
> There is some information on patching here:
> http://www.linuxchix.org/content/courses/kernel_hacking/lesson9
> but take into account that some of it is specific to the linux kernel.
> 
> 
> Regarding ethercat: what Thomas Petazzoni has provided you with is a
> patch for the entire thing, application + drivers. It is based on a
> clean 2011.11 release. Here is a step-by-step guide of things I think
> you should do:
> 
> 1. Start from a clean 2011.11 buildroot tarball (unpack it)
> 2. Move to the buildroot directory with cd
> 3. Apply the patch of ThomasP by saving the e-mail in text file format) and run:
> patch -p1 < saved-email
> You should see output like:
> patching file package/Config.in
> patching file package/igh-ethercat/Config.in
> patching file package/igh-ethercat/igh-ethercat.mk
> 
> 4. Configure buildroot properly (using make menuconfig) and don't
> forget to enable the new igh-ethercat package, which is present under
> 'Networking applications'
>

4.5 Ensure that you have a kernel version selected that is supported
by the EtherCAT patches. 
I seem to recall the most recent supported kernel in stable-1.5 was
2.6.32, __not__ 2.6.33 which was mentioned in your posts earlier.

Mike 
> 5. Run 'make'.
> 
> That should be it. Buildroot will do all the rest for you and when the
> build is done, you can test ethercat to see if everything works.
> 
> Best regards,
> Thomas
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 
> 

[Buildroot] LIBFOO_SITE in .mk file

[Jeff Krasky]

Ok, ok, I'm tryin again from the 2011.11 version.  Can someone at least say
if there is a way to just clean the ethercat part?  Like a

'make clean-igh-ethercat' or something?

[Buildroot] LIBFOO_SITE in .mk file

[Quotient Remainder]

On 2 Noll 2011 15:58, "Jeff Krasky" <jeff.krasky@dspcg.com> wrote:
>
> Ok, ok, I'm tryin again from the 2011.11 version.  Can someone at least
say
> if there is a way to just clean the ethercat part?  Like a
>
> 'make clean-igh-ethercat' or something?
>
>
>

make igh-ethercat-clean to run the clean commands for the package. (in the
..._CLEAN_CMDS variable in the .mk file)

make igh-ethercat-dirclean to start from blank build directory again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111202/48a3b675/attachment.html>

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Jeff Krasky]

I'm giving things a try with 2011.11 and when booting the board I see this:

 

VFS: Mounted root (jffs2 filesystem) on device 31:1.

Freeing init memory: 124K

Kernel panic - not syncing: Attempted to kill init!

 

If anyone has a hint it would be appreciated.  I think I've done the steps
correctly, so if I can just get it to boot..

 

 

Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111202/27c2a065/attachment.html>

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Jeff Krasky]

> I'm giving things a try with 2011.11 and when booting the board I see
this:

> 

> VFS: Mounted root (jffs2 filesystem) on device 31:1.

> Freeing init memory: 124K

> Kernel panic - not syncing: Attempted to kill init!

> 

 

If it helps any, I get this same error message whether I put the jffs2
filesystem at 0x400000 (four hundred thousand) or 0x2a0000 in Nandflash.  So
maybe the kernel doesn't know where to look?  When building kernel 2.6.33 in
2011.05 I would put kernel at 0xa0000 and filesystem at 0x400000 (four
hundred thousand).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111202/8263d55f/attachment.html>

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Tim Judd]

"Attempted to kill init" means the init process died.? Kernel must panic because init cannot terminate.
There's something preventing init from running, or it is dying during execution.

Is your userland correctly have an init?? normally /sbin/init is called.? If your init is somewhere else, use the init= paramater to kernel append

you may have a mounted jffs2 filesystem but not directly usable (think squashfs), is it loaded to ramdisk?? if so, root=/dev/ram0 init=/sbin/init

I'm trying to rework an OEM userland and have come up on many attempts to kill init.? It sucks for diagnostics.




?
If opportunity doesn't knock, build a door.
"I can" is a way of life.
More and Bigger is not always Better.
The road to success is always uphill.
Life isn't about finding yourself, it's about creating yourself.


________________________________
 From: Jeff Krasky <jeff.krasky@dspcg.com>
To: buildroot at busybox.net 
Sent: Friday, December 2, 2011 9:51 AM
Subject: [Buildroot] Kernel panic - not syncing: Attempted to kill init!
 

 
I?m giving things a try with 2011.11
and when booting the board I see this:
?
VFS: Mounted root (jffs2 filesystem) on
device 31:1.
Freeing init memory: 124K
Kernel panic - not syncing: Attempted to
kill init!
?
If anyone has a hint it would be
appreciated.? I think I?ve done the steps correctly, so if I can just get
it to boot?.
?
?
Thanks.
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111202/329157bd/attachment.html>

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Jeff Krasky]

> "Attempted to kill init" means the init process died.  Kernel must panic
because init cannot terminate.

> There's something preventing init from running, or it is dying during
execution.

> 

> Is your userland correctly have an init?  normally /sbin/init is called.
If your init is somewhere else, use

> the init= paramater to kernel append

 

How do I know where init is if I can't bring the board up and run any linux
commands?

 

>you may have a mounted jffs2 filesystem but not directly usable (think
squashfs), is it loaded to

> ramdisk?  if so, root=/dev/ram0 init=/sbin/init

 

When I successfully ran 2.6.33 built from Buildroot-2011.05, in U-boot the
setting for root was root=/dev/mtdblock1.  I am not sure what squashfs is.
How can the filesystem not be usable?

 

Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111202/62bb2304/attachment-0001.html>

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Aleksander Dutkowski]

afair this message could be because of lack of dev/console and/or dev/null.
You must run "mknod -m 660 dev/console c 5 1" and "mknod -m
660dev/null c 1 3" in root partition.

How to do it? I have my on usb stick, so i
simply mount usb drive, and do some changes. If youre using yaffs2 and
NAND memory, you can use

System configuration --> Custom script to run before creating filesystem images

to invoke those commands or just find unyaffs script (somewhere on the
Internet, on google code
afair), unyaffs your rootfs, make changes and make yaffs image one
more time.
You have output/target folder with your rootfs, so you can make changes there :)


On Fri, Dec 2, 2011 at 7:02 PM, Jeff Krasky <jeff.krasky@dspcg.com> wrote:
>> "Attempted to kill init" means the init process died.? Kernel must panic
>> because init cannot terminate.
>
>> There's something preventing init from running, or it is dying during
>> execution.
>
>>
>
>> Is your userland correctly have an init?? normally /sbin/init is called.
>> If your init is somewhere else, use
>
>> the init= paramater to kernel append
>
>
>
> How do I know where init is if I can?t bring the board up and run any linux
> commands?
>
>
>
>>you may have a mounted jffs2 filesystem but not directly usable (think
>> squashfs), is it loaded to
>
>> ramdisk?? if so, root=/dev/ram0 init=/sbin/init
>
>
>
> When I successfully ran 2.6.33 built from Buildroot-2011.05, in U-boot the
> setting for root was root=/dev/mtdblock1. ?I am not sure what squashfs is.
> How can the filesystem not be usable?
>
>
>
> Thanks.
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot



-- 
pozdrawiam
Aleksander Dutkowski

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Jeff Krasky]

> afair this message could be because of lack of dev/console and/or
dev/null.
> You must run "mknod -m 660 dev/console c 5 1" and "mknod -m
> 660dev/null c 1 3" in root partition.
>
> How to do it? I have my on usb stick, so i
> simply mount usb drive, and do some changes. If youre using yaffs2 and
> NAND memory, you can use
> 
> System configuration --> Custom script to run before creating filesystem
> images
> 
> to invoke those commands or just find unyaffs script (somewhere on the
> Internet, on google code
> afair), unyaffs your rootfs, make changes and make yaffs image one
> more time.

Ok, I ran 'make menuconfig' and went into "System configuration -> Custom
script to run before creating filesystem images" and I entered this string:

mknod -m 660 dev/console c 5 1; mknod -m 660 dev/null c 1 3

and I got this when running 'make':

echo 2011.11 > /home/user1/buildroot-2011.11/output/target/etc/br-version
"mknod -m 660 dev/console c 5 1; mknod -m 660 dev/null c 1 3"
/home/user1/buildroot-2011.11/output/target
/bin/sh: mknod -m 660 dev/console c 5 1; mknod -m 660 dev/null c 1 3: No
such file or directory
make: *** [target-finalize] Error 127
user1 at dhcppc15:~/buildroot-2011.11>


> You have output/target folder with your rootfs, so you can make changes
> there :)

How to do it to a already built .jffs2 file?  Can I just open a terminal
window on the linux PC that buildroot is on and run some commands?

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Aleksander Dutkowski]

On Fri, Dec 2, 2011 at 7:30 PM, Jeff Krasky <jeff.krasky@dspcg.com> wrote:
>> afair this message could be because of lack of dev/console and/or
> dev/null.
>> You must run "mknod -m 660 dev/console c 5 1" and "mknod -m
>> 660dev/null c 1 3" in root partition.
>>
>> How to do it? I have my on usb stick, so i
>> simply mount usb drive, and do some changes. If youre using yaffs2 and
>> NAND memory, you can use
>>
>> System configuration --> Custom script to run before creating filesystem
>> images
>>
>> to invoke those commands or just find unyaffs script (somewhere on the
>> Internet, on google code
>> afair), unyaffs your rootfs, make changes and make yaffs image one
>> more time.
>
> Ok, I ran 'make menuconfig' and went into "System configuration -> Custom
> script to run before creating filesystem images" and I entered this string:
>
> mknod -m 660 dev/console c 5 1; mknod -m 660 dev/null c 1 3
>
> and I got this when running 'make':
>
> echo 2011.11 > /home/user1/buildroot-2011.11/output/target/etc/br-version
> "mknod -m 660 dev/console c 5 1; mknod -m 660 dev/null c 1 3"
> /home/user1/buildroot-2011.11/output/target
> /bin/sh: mknod -m 660 dev/console c 5 1; mknod -m 660 dev/null c 1 3: No
> such file or directory
> make: *** [target-finalize] Error 127
> user1 at dhcppc15:~/buildroot-2011.11>

"System configuration --> Custom script to run before creating
filesystem image" input is for specify a PATH to bash script.
You you must simply create script, fill with mknod commands (remember
- mknod can be ran only by root! so do 'sudo mknod')
and then put the path to the script in "Custom script to run before
creating filesystem image".
Remeber to add execute mode to the script (chmod +x file)
>
>
>> You have output/target folder with your rootfs, so you can make changes
>> there :)
>
> How to do it to a already built .jffs2 file? ?Can I just open a terminal
> window on the linux PC that buildroot is on and run some commands?

When buildroot is done compiling all packages, it installs all in
'output/target' directory, and then create image.
I am used to tell buildroot not to create any images, make my own
adjustements in output/target dir, and then create image by hand.
If you need to create yaffs, you can look for "mkyaffs2" script, which
you can find on code.google.com.

On Fri, Dec 2, 2011 at 7:31 PM, Tim Judd <tjudd2k@yahoo.com> wrote:
> lack of dev/console or /dev/null should give a message something like "can't
> allocate initial tty!"
> I was having those errors too.? his is unable to run/survive init
>
>
> having dev/console and dev/null (and if necessary dev/tty*) so the console
> can be opened.? It's odd the kernel can spit the bootup on ttyS0 but
> complains when trying to run init.? one of the great mysteries of linux.

I had another error message (I experienced problem with lack of
/dev/console some time ago), but you can be right. I'm just assuming,
that my solution is proper, and want Jeff to check it ;)

>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot



-- 
pozdrawiam
Aleksander Dutkowski

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Tim Judd]

lack of dev/console or /dev/null should give a message something like "can't allocate initial tty!"
I was having those errors too.? his is unable to run/survive init


having dev/console and dev/null (and if necessary dev/tty*) so the console can be opened.? It's odd the kernel can spit the bootup on ttyS0 but complains when trying to run init.? one of the great mysteries of linux.



?

If opportunity doesn't knock, build a door.
"I can" is a way of life.
More and Bigger is not always Better.
The road to success is always uphill.
Life isn't about finding yourself, it's about creating yourself.


________________________________
 From: Aleksander Dutkowski <adutkowski@gmail.com>
To: buildroot at busybox.net 
Sent: Friday, December 2, 2011 11:21 AM
Subject: Re: [Buildroot] Kernel panic - not syncing: Attempted to kill init!
 
afair this message could be because of lack of dev/console and/or dev/null.
You must run "mknod -m 660 dev/console c 5 1" and "mknod -m
660dev/null c 1 3" in root partition.

How to do it? I have my on usb stick, so i
simply mount usb drive, and do some changes. If youre using yaffs2 and
NAND memory, you can use

System configuration --> Custom script to run before creating filesystem images

to invoke those commands or just find unyaffs script (somewhere on the
Internet, on google code
afair), unyaffs your rootfs, make changes and make yaffs image one
more time.
You have output/target folder with your rootfs, so you can make changes there :)


On Fri, Dec 2, 2011 at 7:02 PM, Jeff Krasky <jeff.krasky@dspcg.com> wrote:
>> "Attempted to kill init" means the init process died.? Kernel must panic
>> because init cannot terminate.
>
>> There's something preventing init from running, or it is dying during
>> execution.
>
>>
>
>> Is your userland correctly have an init?? normally /sbin/init is called.
>> If your init is somewhere else, use
>
>> the init= paramater to kernel append
>
>
>
> How do I know where init is if I can?t bring the board up and run any linux
> commands?
>
>
>
>>you may have a mounted jffs2 filesystem but not directly usable (think
>> squashfs), is it loaded to
>
>> ramdisk?? if so, root=/dev/ram0 init=/sbin/init
>
>
>
> When I successfully ran 2.6.33 built from Buildroot-2011.05, in U-boot the
> setting for root was root=/dev/mtdblock1. ?I am not sure what squashfs is.
> How can the filesystem not be usable?
>
>
>
> Thanks.
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot



-- 
pozdrawiam
Aleksander Dutkowski
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111202/b8eaca41/attachment.html>

[Buildroot] Kernel panic - not syncing: Attempted to kill init!

[Tim Judd]

"usable" on the filesystem is maybe not the perfect word to use, it is more meant in terms of what is read-write and freely accessible on the root device.? A mtdblock is an embedded flash memory area who often times has a read-only compressed filesystem such as squashfs (google it).? squashfs is not directly usable like ext2 on a hard disk is.

You might have to hack 'n slash your way in (this is my limited linux knowledge.? I'm not claiming to be an expert).
use an additional append= argument: "init=/bin/sh" or "init=/bin/bash" or "init=/bin/ash" to try to get into a usable shell to see what's there.? This argument overrides the traditional init that runs so you can look in the directories trying to find where your init is supposed to be.? Remember that init itself is never supposed to terminate/end like you can close Firefox.? So if you leave the shell, linux kernel WILL panic (same error you started this thread with)

I'm not very confident mtdblock1 is supposed to be a read-write filesystem, but may have some kind of read-only squashfs kind of filesystem on it.


you're still welcome to try "root=/dev/ram0 init=/bin/ash" and related combinations trying to get a usable root filesystem and working shell.? This is where the headaches for me start.


I'm just knowledgeable enough to know basics, others here are guaranteed to be more experienced.





?
If opportunity doesn't knock, build a door.
"I can" is a way of life.
More and Bigger is not always Better.
The road to success is always uphill.
Life isn't about finding yourself, it's about creating yourself.


________________________________
 From: Jeff Krasky <jeff.krasky@dspcg.com>
To: buildroot at busybox.net 
Sent: Friday, December 2, 2011 11:02 AM
Subject: Re: [Buildroot] Kernel panic - not syncing: Attempted to kill init!
 

 
> "Attempted
to kill init" means the init process died.? Kernel must panic because
init cannot terminate.
> There's
something preventing init from running, or it is dying during execution.
> 
> Is
your userland correctly have an init?? normally /sbin/init is
called.? If your init is somewhere else, use
> the
init= paramater to kernel append
?
How do I know
where init is if I can?t bring the board up and run any linux commands?
?
>you
may have a mounted jffs2 filesystem but not directly usable (think squashfs),
is it loaded to
> ramdisk??
if so, root=/dev/ram0 init=/sbin/init
?
When I
successfully ran 2.6.33 built from Buildroot-2011.05, in U-boot the setting for
root was root=/dev/mtdblock1. ?I am not sure what squashfs
is.? How can the filesystem not be usable?
?
Thanks.
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111202/c9e38a49/attachment.html>