Re: [OpenWrt-Devel] 2.6 kernel and b43 driver
> Can you try the following patch?
[...]
> +if (dev->bus->bustype != SSB_BUSTYPE_PCI) {
> +/* This SSB device is not on a PCI host-bus. So the IRQs are
> + * not routed through the PCI core.
> + * So we must not enable routing through the PCI core. */
> +goto out;
> +}
> +
[...]
> The b43 driver now loads, loads firmware and returns scan results.
With the above patch (and a freshly updated svn checkout of Kamikaze),
my WL700gE indeed loads the driver, it seems to load the firmware as
well, but something goes wrong afterwards and I don't get any network
interface. The corresponding dmesg output is:
b43-phy0: Broadcom 4318 WLAN found
b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8
b43-phy0 debug: DebugFS (CONFIG_DEBUG_FS) not enabled in kernel config
phy0: Selected rate control algorithm 'pid'
phy0: Failed to initialize wep
b43: probe of ssb1:0 failed with error -12
Broadcom 43xx driver loaded [ Features: NLR, Firmware-ID: FW13 ]
-- Stefan
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2.6 kernel and b43 driver
Felipe Maya wrote:
> Hi Steve,
>
> I'm happy too with the result, but..
> I did the test with the patch that Michael sent (with and without)
> disabling the function ssb_pcicore_dev_irqvecs_enable following the
> e-mails, without the same result. (Kernel 2.6.25.9-wl500gpv2).
>
> Steve can you verify the modifications of the test, please, I want to
> reproduce the result.
>
> } //else
> //ssb_pcicore_dev_irqvecs_enable(&sdev->bus->pcicore, sdev);
>
> Thanks,
> Fmay
> On Fri, 2008-07-04 at 20:33 -0400, Steve Brown wrote:
>
>> Forgot the cc's. And to close the thread.
>>
>> Michael Buesch wrote:
>>
>>> On Friday 04 July 2008 21:39:46 Steve Brown wrote:
>>>
>>>
Michael Buesch wrote:
> On Tuesday 01 July 2008 21:50:43 Steve Brown wrote:
>
>
>
>> It looks like (almost) every other phy register doesn't respond. I put
>> in a large (200us) delay between accesses with no change in behaviour.
>> If it is timing, it must be on the pci bus side of the core.
>>
>>
>>
> Ah this is a minipci card?
> Can you try to play with the PCI bus timings that are initialised in
> the PCI-core driver of SSB? See the function that initialises the
> PCI-core in hostmode.
>
>
>
>
The problem is actually in b44. The ssb_pcicore_dev_irqvecs_enable call
in b44_chip_enable at b44.c:1281 is the cause of the problem. It gets
called unconditionally, even if the b44 is not on the pci. With it
commented out, b43 loads, loads firmware and returns scan results.
>>> So do you have a PCI bus on the system? Is the wireless connected via
>>> minipci?
>>>
>>>
>>>
>>> I'll immediately submit this for inclusion in mainline, if you report
>>> success.
>>> Thanks for testing.
>>>
>>> you got
>>> Index: wireless-testing/drivers/ssb/driver_pcicore.c
>>> ===
>>> --- wireless-testing.orig/drivers/ssb/driver_pcicore.c2008-06-10
>>> 13:58:23.0 +0200
>>> +++ wireless-testing/drivers/ssb/driver_pcicore.c2008-07-04
>>> 23:16:02.0 +0200
>>> @@ -537,6 +537,13 @@ int ssb_pcicore_dev_irqvecs_enable(struc
>>> int err = 0;
>>> u32 tmp;
>>>
>>> +if (dev->bus->bustype != SSB_BUSTYPE_PCI) {
>>> +/* This SSB device is not on a PCI host-bus. So the IRQs are
>>> + * not routed through the PCI core.
>>> + * So we must not enable routing through the PCI core. */
>>> +goto out;
>>> +}
>>> +
>>> if (!pdev)
>>> goto out;
>>> bus = pdev->bus;
>>>
>>>
>>> The bug is fixed!
>>>
>>> The b43 driver now loads, loads firmware and returns scan results.
>>>
>>> Thanks,
>>>
>>> Steve
>>>
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>
I gather you still get a bus error after the patch. Can you post the oops?
The patch works for me. However, I'm using the wireless-testing tree,
not the 2.6.25 tree. I moved to wireless-testing because I didn't want
to end up tracking down a bug that had already been fixed. After you
post the oops, I'll try to reproduce it with the 2.6.25 tree. Be sure to
set KALLSYMS=y in your kernel config.
Steve
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2.6 kernel and b43 driver
Hi Steve,
I'm happy too with the result, but..
I did the test with the patch that Michael sent (with and without)
disabling the function ssb_pcicore_dev_irqvecs_enable following the
e-mails, without the same result. (Kernel 2.6.25.9-wl500gpv2).
Steve can you verify the modifications of the test, please, I want to
reproduce the result.
} //else
//ssb_pcicore_dev_irqvecs_enable(&sdev->bus->pcicore, sdev);
Thanks,
Fmay
On Fri, 2008-07-04 at 20:33 -0400, Steve Brown wrote:
> Forgot the cc's. And to close the thread.
>
> Michael Buesch wrote:
> > On Friday 04 July 2008 21:39:46 Steve Brown wrote:
> >
> >> Michael Buesch wrote:
> >>
> >>> On Tuesday 01 July 2008 21:50:43 Steve Brown wrote:
> >>>
> >>>
> It looks like (almost) every other phy register doesn't respond. I put
> in a large (200us) delay between accesses with no change in behaviour.
> If it is timing, it must be on the pci bus side of the core.
>
>
> >>> Ah this is a minipci card?
> >>> Can you try to play with the PCI bus timings that are initialised in
> >>> the PCI-core driver of SSB? See the function that initialises the
> >>> PCI-core in hostmode.
> >>>
> >>>
> >>>
> >> The problem is actually in b44. The ssb_pcicore_dev_irqvecs_enable call
> >> in b44_chip_enable at b44.c:1281 is the cause of the problem. It gets
> >> called unconditionally, even if the b44 is not on the pci. With it
> >> commented out, b43 loads, loads firmware and returns scan results.
> >>
> >> It crept in sometime after 2.6.23.1. I'm not familiar with b44 and can't
> >> offer a fix.
> >>
> >> I still don't understand how this caused the bus errors. Anybody got an
> >> explanation?
> >>
> >
> > So do you have a PCI bus on the system? Is the wireless connected via
> > minipci?
> >
> >
> >
>
> Yeah well. Probably a silicon glitch. We're not supposed
> to change the IRQ routing of the PCI core on the board, as the
> IRQs on the board are routed through the Mips core.
>
> Can you try the following patch?
> Please try ethernet and wireless. For wireless it's probably OK
> to try loading the driver. But I'd prefer if you try to scan the
> channels. That would probably be enough to make sure it works correctly.
>
> I'll immediately submit this for inclusion in mainline, if you report
> success.
> Thanks for testing.
>
>
> Index: wireless-testing/drivers/ssb/driver_pcicore.c
> ===
> --- wireless-testing.orig/drivers/ssb/driver_pcicore.c2008-06-10
> 13:58:23.0 +0200
> +++ wireless-testing/drivers/ssb/driver_pcicore.c2008-07-04
> 23:16:02.0 +0200
> @@ -537,6 +537,13 @@ int ssb_pcicore_dev_irqvecs_enable(struc
> int err = 0;
> u32 tmp;
>
> +if (dev->bus->bustype != SSB_BUSTYPE_PCI) {
> +/* This SSB device is not on a PCI host-bus. So the IRQs are
> + * not routed through the PCI core.
> + * So we must not enable routing through the PCI core. */
> +goto out;
> +}
> +
> if (!pdev)
> goto out;
> bus = pdev->bus;
>
>
> The bug is fixed!
>
> The b43 driver now loads, loads firmware and returns scan results.
>
> Thanks,
>
> Steve
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2.6 kernel and b43 driver
Forgot the cc's. And to close the thread.
Michael Buesch wrote:
> On Friday 04 July 2008 21:39:46 Steve Brown wrote:
>
>> Michael Buesch wrote:
>>
>>> On Tuesday 01 July 2008 21:50:43 Steve Brown wrote:
>>>
>>>
It looks like (almost) every other phy register doesn't respond. I put
in a large (200us) delay between accesses with no change in behaviour.
If it is timing, it must be on the pci bus side of the core.
>>> Ah this is a minipci card?
>>> Can you try to play with the PCI bus timings that are initialised in
>>> the PCI-core driver of SSB? See the function that initialises the
>>> PCI-core in hostmode.
>>>
>>>
>>>
>> The problem is actually in b44. The ssb_pcicore_dev_irqvecs_enable call
>> in b44_chip_enable at b44.c:1281 is the cause of the problem. It gets
>> called unconditionally, even if the b44 is not on the pci. With it
>> commented out, b43 loads, loads firmware and returns scan results.
>>
>> It crept in sometime after 2.6.23.1. I'm not familiar with b44 and can't
>> offer a fix.
>>
>> I still don't understand how this caused the bus errors. Anybody got an
>> explanation?
>>
>
> So do you have a PCI bus on the system? Is the wireless connected via
> minipci?
>
>
>
Yeah well. Probably a silicon glitch. We're not supposed
to change the IRQ routing of the PCI core on the board, as the
IRQs on the board are routed through the Mips core.
Can you try the following patch?
Please try ethernet and wireless. For wireless it's probably OK
to try loading the driver. But I'd prefer if you try to scan the
channels. That would probably be enough to make sure it works correctly.
I'll immediately submit this for inclusion in mainline, if you report
success.
Thanks for testing.
Index: wireless-testing/drivers/ssb/driver_pcicore.c
===
--- wireless-testing.orig/drivers/ssb/driver_pcicore.c2008-06-10
13:58:23.0 +0200
+++ wireless-testing/drivers/ssb/driver_pcicore.c2008-07-04
23:16:02.0 +0200
@@ -537,6 +537,13 @@ int ssb_pcicore_dev_irqvecs_enable(struc
int err = 0;
u32 tmp;
+if (dev->bus->bustype != SSB_BUSTYPE_PCI) {
+/* This SSB device is not on a PCI host-bus. So the IRQs are
+ * not routed through the PCI core.
+ * So we must not enable routing through the PCI core. */
+goto out;
+}
+
if (!pdev)
goto out;
bus = pdev->bus;
The bug is fixed!
The b43 driver now loads, loads firmware and returns scan results.
Thanks,
Steve
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ssb-pcicore: Fix IRQ-vector init on embedded devices
On embedded devices we must not route the interrupts through
the PCI core, if our host-bus is not PCI.
Reported-by: Steve Brown <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
---
John, If still possible, please queue for 2.6.26.
Index: wireless-testing/drivers/ssb/driver_pcicore.c
===
--- wireless-testing.orig/drivers/ssb/driver_pcicore.c 2008-06-10
13:58:23.0 +0200
+++ wireless-testing/drivers/ssb/driver_pcicore.c 2008-07-04
23:16:02.0 +0200
@@ -537,6 +537,13 @@ int ssb_pcicore_dev_irqvecs_enable(struc
int err = 0;
u32 tmp;
+ if (dev->bus->bustype != SSB_BUSTYPE_PCI) {
+ /* This SSB device is not on a PCI host-bus. So the IRQs are
+* not routed through the PCI core.
+* So we must not enable routing through the PCI core. */
+ goto out;
+ }
+
if (!pdev)
goto out;
bus = pdev->bus;
--
Greetings Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2.6 kernel and b43 driver
On Friday 04 July 2008 21:39:46 Steve Brown wrote: > Michael Buesch wrote: > > On Tuesday 01 July 2008 21:50:43 Steve Brown wrote: > > > >> It looks like (almost) every other phy register doesn't respond. I put > >> in a large (200us) delay between accesses with no change in behaviour. > >> If it is timing, it must be on the pci bus side of the core. > >> > > > > Ah this is a minipci card? > > Can you try to play with the PCI bus timings that are initialised in > > the PCI-core driver of SSB? See the function that initialises the > > PCI-core in hostmode. > > > > > The problem is actually in b44. The ssb_pcicore_dev_irqvecs_enable call > in b44_chip_enable at b44.c:1281 is the cause of the problem. It gets > called unconditionally, even if the b44 is not on the pci. With it > commented out, b43 loads, loads firmware and returns scan results. > > It crept in sometime after 2.6.23.1. I'm not familiar with b44 and can't > offer a fix. > > I still don't understand how this caused the bus errors. Anybody got an > explanation? So do you have a PCI bus on the system? Is the wireless connected via minipci? -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how to flash Linux kernel directly, without tftp?
> Is this what you meant? > http://wiki.openwrt.org/OpenWrtDocs/Installing >Reflashing OpenWrt will overwrite the filesystem, erasing all previous >applications and data. You are strongly urged to back up any changes >you may have made to the system. >mtd -r write firmware.trx linux Yes, pretty much. > But this overwrites everything - I'd like to only flash the kernel. I don't think you can do that: the same flash partition holds both the kernel and its "initrd" (i.e. the squashfs partition). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2.6 kernel and b43 driver
Michael Buesch wrote: > On Tuesday 01 July 2008 21:50:43 Steve Brown wrote: > >> It looks like (almost) every other phy register doesn't respond. I put >> in a large (200us) delay between accesses with no change in behaviour. >> If it is timing, it must be on the pci bus side of the core. >> > > Ah this is a minipci card? > Can you try to play with the PCI bus timings that are initialised in > the PCI-core driver of SSB? See the function that initialises the > PCI-core in hostmode. > > The problem is actually in b44. The ssb_pcicore_dev_irqvecs_enable call in b44_chip_enable at b44.c:1281 is the cause of the problem. It gets called unconditionally, even if the b44 is not on the pci. With it commented out, b43 loads, loads firmware and returns scan results. It crept in sometime after 2.6.23.1. I'm not familiar with b44 and can't offer a fix. I still don't understand how this caused the bus errors. Anybody got an explanation? Steve ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how to flash Linux kernel directly, without tftp?
Stefan Monnier schrieb: >> I'd like to be able to flash the kernel without using tftp, just with dd: > >> # erase /dev/mtd1 >> # dd if=kernel of=/dev/mtd1 > >> Does anyone know a "magic" formula? Having to power off the device and >> pressing the reset button is boring ;) > > The OpenWRT wiki ha(s|d) the instructions, tho I can't find them anymore. > It looked like > >mtd -e linux .trx Is this what you meant? http://wiki.openwrt.org/OpenWrtDocs/Installing Reflashing OpenWrt will overwrite the filesystem, erasing all previous applications and data. You are strongly urged to back up any changes you may have made to the system. mtd -r write firmware.trx linux But this overwrites everything - I'd like to only flash the kernel. -- Tomasz Chmielewski http://wpkg.org ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how to flash Linux kernel directly, without tftp?
> I'd like to be able to flash the kernel without using tftp, just with dd: > # erase /dev/mtd1 > # dd if=kernel of=/dev/mtd1 > Does anyone know a "magic" formula? Having to power off the device and > pressing the reset button is boring ;) The OpenWRT wiki ha(s|d) the instructions, tho I can't find them anymore. It looked like mtd -e linux .trx -- Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] how to flash Linux kernel directly, without tftp?
Is it possible to flash Linux kernel directly on BCM43XX - based hardware (ASUS WL-500gP etc.), without using tftp? According to /proc/mtd, kernel is located on /dev/mtd1: # cat /proc/mtd dev:size erasesize name mtd0: 0004 0001 "cfe" mtd1: 007b 0001 "linux" mtd2: 006d 0001 "rootfs" mtd3: 0001 0001 "nvram" When we look at the contents of /dev/mtd1, it begins with "HDR0" - so perhaps Linux kernel has to be converted into some special format first? I'd like to be able to flash the kernel without using tftp, just with dd: # erase /dev/mtd1 # dd if=kernel of=/dev/mtd1 Does anyone know a "magic" formula? Having to power off the device and pressing the reset button is boring ;) -- Tomasz Chmielewski http://wpkg.org ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] uclibc 0.9.28 broken in trunk
Hi, selectable uClibc Version (uClibc 0.9.28) is broken in trunk, because the file/dir layout seems to have changed since 7.09. The first problem [0] can be fixed by something like the simple patch in [1]. However soon after one meets the next problem with extra/scripts/gen_bits_syscall_h.sh [2]. (I would need 0.9.28 because 0.9.29 causes a segfault in libpthread. I myself do not know enough about uClibc to fix this) regards, Jens [0] v + ./extra/scripts/fix_includes.sh -k ./build_dir/toolchain-i386_gcc4.1.2/linux -t i386 The file ./build_dir/toolchain-i386_gcc4.1.2/linux/Makefile or ./build_dir/toolchain-i386_gcc4.1.2/linux/include/linux/version.h is missing! Perhaps your kernel source is broken? make[4]: *** [headers] Error 1 make[4]: Leaving directory `/pers/proj/edim/seismo95_with_openwrt11614/build_dir/toolchain-i386_gcc4.1.2/uClibc-0.9.28.2' [1] Index: toolchain/uClibc/config/0.9.28.2/i386 === --- toolchain/uClibc/config/0.9.28.2/i386 (revision 113) +++ toolchain/uClibc/config/0.9.28.2/i386 (working copy) @@ -66,7 +66,7 @@ UCLIBC_HAS_FLOATS=y HAS_FPU=y DO_C99_MATH=y -KERNEL_SOURCE="./toolchain_build_i386/linux" +KERNEL_SOURCE="../../../build_dir/toolchain-i386_gcc4.1.2/linux" C_SYMBOL_PREFIX="" HAVE_DOT_CONFIG=y [2] vv make[4]: Entering directory `/pers/proj/edim/seismo95_with_openwrt11614/build_dir/toolchain-i386_gcc4.1.2/uClibc-0.9.28.2' + ./extra/scripts/fix_includes.sh -k ../../../build_dir/toolchain-i386_gcc4.1.2/linux -t i386 + TOPDIR=. + CC='ccache i386-linux-uclibc-gcc' + /bin/sh extra/scripts/gen_bits_syscall_h.sh i386-linux-uclibc-gcc: ./include/asm/unistd.h: No such file or directory i386-linux-uclibc-gcc: no input files :1:34: error: ./include/asm/unistd.h: No such file or directory + cmp include/bits/sysnum.h include/bits/sysnum.h.new + rm -f include/bits/sysnum.h.new make -C libc/sysdeps/linux/common headers make[5]: Entering directory `/pers/proj/edim/seismo95_with_openwrt11614/build_dir/toolchain-i386_gcc4.1.2/uClibc-0.9.28.2/libc/sysdeps/linux/common' ln -fs ../libc/sysdeps/linux/common/fpu_control.h ../../../..//include/ make[5]: Leaving directory `/pers/proj/edim/seismo95_with_openwrt11614/build_dir/toolchain-i386_gcc4.1.2/uClibc-0.9.28.2/libc/sysdeps/linux/common' make -C libc/sysdeps/linux/i386 headers make[5]: Entering directory `/pers/proj/edim/seismo95_with_openwrt11614/build_dir/toolchain-i386_gcc4.1.2/uClibc-0.9.28.2/libc/sysdeps/linux/i386' ln -fs ../libc/sysdeps/linux/i386/fpu_control.h ../../../../include/ make[5]: Leaving directory `/pers/proj/edim/seismo95_with_openwrt11614/build_dir/toolchain-i386_gcc4.1.2/uClibc-0.9.28.2/libc/sysdeps/linux/i386' make -C ldso make[5]: Entering directory `/pers/proj/edim/seismo95_with_openwrt11614/build_dir/toolchain-i386_gcc4.1.2/uClibc-0.9.28.2/ldso' ln -fs ../../include/elf.h include/elf.h ln -fs ../ldso/i386/dl-startup.h include/dl-startup.h ln -fs ../ldso/i386/dl-syscalls.h include/dl-syscalls.h ln -fs ../ldso/i386/dl-sysdep.h include/dl-sysdep.h ln -fs ../ldso/i386/dl-debug.h include/dl-debug.h make -C ldso make[6]: Entering directory `/pers/proj/edim/seismo95_with_openwrt11614/build_dir/toolchain-i386_gcc4.1.2/uClibc-0.9.28.2/ldso/ldso' ccache i386-linux-uclibc-gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-stack-protector -mpreferred-stack-boundary=2 -falign-jumps=0 -falign-loops=0 -Os -funit-at-a-time -DUCLIBC_LDSO=\"ld-uClibc.so.0\" -O2 -pipe -march=i486 -funit-at-a-time -fhonour-copts -fPIC -DUCLIBC_RUNTIME_PREFIX=\"/\" -fno-builtin -nostdinc -D_LIBC -DLDSO_ELFINTERP=\"i386/elfinterp.c\" -I../../ldso/ldso/i386 -I../../ldso/include -I../../ldso/ldso -I../../include -D_GNU_SOURCE -isystem /pers/proj/edim/seismo95_with_openwrt11614/staging_dir/toolchain-i386_gcc4.1.2/lib/gcc/i386-linux-uclibc/4.1.2/include -c i386/resolve.S -o i386/resolve.o i386-linux-uclibc-strip -x -R .note -R .comment i386/resolve.o ccache i386-linux-uclibc-gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-stack-protector -mpreferred-stack-boundary=2 -falign-jumps=0 -falign-loops=0 -Os -funit-at-a-time -DUCLIBC_LDSO=\"ld-uClibc.so.0\" -O2 -pipe -march=i486 -funit-at-a-time -fhonour-copts -fPIC -DUCLIBC_RUNTIME_PREFIX=\"/\" -fno-builtin -nostdinc -D_LIBC -DLDSO_ELFINTERP=\"i386/elfinterp.c\" -I../../ldso/ldso/i386 -I../../ldso/include -I../../ldso/ldso -I../../include -D_GNU_SOURCE -isystem /pers/proj/edim/seismo95_with_openwrt11614/staging_dir/toolchain-i386_gcc4.1.2/lib/gcc/i386-linux-uclibc/4.1.2/include -c ldso.c -o ldso.o In file included from ../../ldso/include/ldso.h:37, from ldso.c:33: ../
Re: [OpenWrt-Devel] [rfc] Kernel sources download strategy
On ven, 2008-07-04 at 08:16 +0200, Alfred E. Heggestad wrote:
> Luigi 'Comio' Mantellini wrote:
> > Hi All,
> >
> > ...
> >
> > Thanks a lot for your comments.
> >
>
> would it be possible to use the program called `ketchup' to download
> kernel sources?
>
>http://www.selenic.com/ketchup/
>
Interesting. I will give a look in this evening.
> I guess the build system could also look in /usr/src for kernel source,
> and copy them instead of downloading.
>
I think that is a bad idea because you don't know (usually) which
patches are applied to the host kernel.
best regards,
luigi
>
> /alfred
--
__ Luigi Mantellini
.'__'. R&D - Software
(.' '.)Industrie Dial Face S.p.A.
( :==: )Via Canzo, 4
('.__.')20068 Peschiera Borromeo (MI), Italy
'.__.' Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
Ind. Dial Face Email: [EMAIL PROTECTED]
www.idf-hit.com GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
B003 175F E979 907E 1650
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
