* RE: Xilinx PowerPC
From: Stephen Neuendorffer @ 2008-02-21 17:50 UTC (permalink / raw)
To: David H. Lynch Jr., Grant Likely, linuxppc-embedded
In-Reply-To: <47BD212B.6090809@dlasys.net>
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of David H.
Lynch Jr.
> Sent: Wednesday, February 20, 2008 10:59 PM
> To: Grant Likely; linuxppc-embedded
> Subject: Xilinx PowerPC
>=20
>=20
> So when you have Xilinx under powerpc working, do we pull it from
your
> git tree or the xilinx one ?
>=20
> Will there be an announcement ?
>=20
> How about a one paragraph getting started guide to moving a xilinx
> ppc bsp to
> xilinx powerpc.
>=20
> Like ?
>=20
> step 1).
> Generate a dts - gen-mhs-devicetree ?
> And pass it to through your boot loader to Linux ?
http://git.xilinx.com/gen-mhs-devtree.git contains two utilities for
generating device trees from EDK projects. The older option is a python
script, originally written by Grant. The newer (and probably more
mature at this point) option is an EDK BSP generator for u-boot,
originally written by Michal Simek. Preferably this gets passed from a
uboot, although it's also possible to compile it into the kernel.
Currently, the uboot option is somewhat annoying because there's not a
good surefire way for getting uboot up and running on an EDK design.
(Unfortunately, the EDK BSP generator is incomplete, and the uboot
support for virtex needs some work to get it integrated as well).
> Step 2).
> the code in arch/powerpc/???? is the devicetree equvalent
to
> arch/ppc/platforms/4xx/xilinx_ml410.c
http://git.xilinx.com/linux-2.6-xlnx.git contains a preliminary stab at
the bootcode for Virtex. I've been using this for a while with
ARCH=3Dpowerpc. There isn't really much need for board specific =
platform
code: This should (I think) be handled by the device tree. All of this
is still pretty preliminary at the moment however. The big problem with
the boot code in the Xilinx tree is that you need to be able to allocate
memory in order to parse the device tree in order to figure out how much
memory you have. I just haven't rewritten the code to use libfdt, which
can query the device tree without memory allocation yet. Grant has a
slightly different scheme in his tree, but it works as well. Generally
I've been more focused on avoiding u-boot, whereas Grant has been using
u-boot exclusively, I think.
> Step 3).
> device drivers need to change initialization/setup from
> ???? to ???
All the xilinx drivers in mainline and most of the ones in the
git.xilinx.com tree export both platform device and of_device
interfaces. You should be able to look at any of them to figure out a
good way of adding of_device support to a driver. the ll_temac is by
far the most complex instance of this, which has to do some non-trivial
traversal of the device tree to discover the information it needs about
it's interface to memory.
So, the short answer is, you might be able to get it to work today, but
the code isn't in shape for mainline yet.
Steve
^ permalink raw reply
* Re: initramfs problem - /init file
From: raul.moreno @ 2008-02-21 16:05 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <47BD9936.2000400@dlasys.lcl>
Hi Dave,
I have just figured out the problem... an stupid error... By mistake I =
took
the filesystem compiled to intel instead to ppc. I guess I forgot to as=
sign
the right cross-compile toolchain. So the microprocessor can't execute =
the
init file.
Now it works.
Anyway thank you for your time.
Ra=FAl Moreno
"David H. Lynch Jr." <dhlii@dlasys.lcl>
"David H. Lynch Jr."
21/02/2008 16:31
Por favor, responda a dhlii
=
Para: raul.moreno@telvent.abengoa.com =
=
cc: linuxppc-embedded <linuxppc-embedded@ozlabs.org> =
=
Asunto: Re: initramfs problem - /init file =
=
raul.moreno@telvent.abengoa.com wrote:
> Hello Dave,
>
> thanks for your answer. I agree with you, the easy way is to assign t=
he
> rootfs directory. I gave the filesystem as a cpio file because it is =
the
> same (the kernel takes the rootfs and converts it to a cpio format), =
but
> the compilation is faster. Anyway, although now I do as you said, I s=
till
> get the error:
> "Failed to execute /init
> Kernel panic - not syncing: No init found. Try passing init=3D optio=
n to
> kernel."
> I can't understand why it happens. I check the permission of /init an=
d
> /sbin/init and everything seems to me OK.
>
> Any idea?
>
I have had the same problem.
Things I can remember:
Permissions,
console setup,
watch out for symbolic links to init.
Also is your init and executable or script ?
I think you get this failure if ANYTHING goes wrong exec'ing
init.
Like - it found init but could not execute a shell.
or the shell required a library it could not find.
Or something is not quite right with your Virtual memory -
Linux exec's by forcing chained page faults.
One thing I tried was a simple "hello world" in ppc assembler -
no libraries,
and named it /init. When it succeeded I was able to narrow my
problem down..
Then tried a "hello world" in C with a static library, then
dynamic, then ...
Basically building more and more complex /init's until I isolate=
d
what was failing.
> Ra=FAl Moreno
>
>
>
>
--
Dave Lynch
DLA Systems
Software Development:
Embedded Linux
717.627.3770 dhlii@dlasys.net
http://www.dlasys.net
fax: 1.253.369.9244 Cell:=
1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too=
numerous to list.
"Any intelligent fool can make things bigger and more complex... It tak=
es a
touch of genius - and a lot of courage to move in the opposite directio=
n."
Albert Einstein
=
^ permalink raw reply
* Re: TLB Miss booting linux kernel on ppc 405
From: David Baird @ 2008-02-21 18:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <5ee408090802210950t498b9752meab2b91d2a13191c@mail.gmail.com>
On Thu, Feb 21, 2008 at 10:50 AM, Ricardo Ayres Severo
<severo.ricardo@gmail.com> wrote:
> I rebuilt the design in EDK 9.2i and problem persisted. The only
> difference is the registers are not zeroing anymore. No exception is
> thrown, and the system still hangs at memset_io. I'm running out of
> options.
> It is possible to boot Linux on Virtex-II, isn't?
Yes, it is possible. I have a Virtex-II Pro with Linux running on it
although I didn't configure it myself (it is one of those Black Dog
computers). I work with Virtex-4s right now.
Can you try a reference design for the Virtex-II perhaps?
Can you comment out memset_io and write your own version of it (which
you can insert debug statements into)?
When/where in memset are things breaking? What is the nature of the
breaking? Can you get your serial terminal to print out hex values
(for memory locations, memory values, etc.)?
^ permalink raw reply
* Re: TLB Miss booting linux kernel on ppc 405
From: David Baird @ 2008-02-21 18:04 UTC (permalink / raw)
To: linuxppc-embedded, Robert Woodworth
In-Reply-To: <1203542646.4812.38.camel@PisteOff>
Hi Robert,
On Wed, Feb 20, 2008 at 2:24 PM, Robert Woodworth
<rwoodworth@securics.com> wrote:
> I'm under the suspicion that the PLB is issuing an error when switching
> to virtual mode and that there is either a timing/synthesis error or a
> fundamental error with the way the FPGA is getting synthesized with the
> PLB.
Can you offer a suggestion how I can check to see if the PLB is
issuing an error (a good application note for me to read or anything)?
I was having a similar problem in virtual mode on one of my systems,
and I might be able to see also if I am having a problem with the PLB
bus.
-David
^ permalink raw reply
* [PATCH] [POWERPC] Fix zImage-dtb.initrd build error
From: Grant Likely @ 2008-02-21 18:57 UTC (permalink / raw)
To: Geert.Uytterhoeven, linuxppc-dev; +Cc: miltonm, paulus, Hiroaki_Fuse
From: Grant Likely <grant.likely@secretlab.ca>
The pattern substitution rules were failing when used with zImage-dtb
targets. if zImage-dtb.initrd was selected, the pattern substitution
would generate "zImage.initrd-dtb" instead of "zImage-dtb.initrd" which
caused the build to fail.
This patch renames zImage-dtb to dtbImage to avoid the problem entirely.
By not using the zImage prefix then is no potential for namespace
collisions.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Note to reviewers. Please consider this change carefully. I saw two
options for fixing this bug;
1) rework the pattern substitution to handle zImage-dtb correctly
2) avoid using the zImage prefix
I chose option 2 because it avoids increasing the complexity of the
pattern substitution code for generating initrd names. However, doing
so will have an impact on distributors because it changes the name of
the generated image. If this is a problem for anyone, or if you have
a better name suggestion than "dtbImage", then please speak up.
Cheers,
g.
---
arch/powerpc/Makefile | 2 +-
arch/powerpc/boot/Makefile | 18 ++++++++++--------
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 1c6ce35..ab5cfe8 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -155,7 +155,7 @@ all: zImage
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd uImage treeImage.% cuImage.%
+BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.%
PHONY += $(BOOT_TARGETS)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 63d07cc..d57a67d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -186,7 +186,7 @@ quiet_cmd_wrap = WRAP $@
image-$(CONFIG_PPC_PSERIES) += zImage.pseries
image-$(CONFIG_PPC_MAPLE) += zImage.pseries
image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries
-image-$(CONFIG_PPC_PS3) += zImage-dtb.ps3
+image-$(CONFIG_PPC_PS3) += dtbImage.ps3
image-$(CONFIG_PPC_CELLEB) += zImage.pseries
image-$(CONFIG_PPC_CHRP) += zImage.chrp
image-$(CONFIG_PPC_EFIKA) += zImage.chrp
@@ -205,7 +205,7 @@ image-$(CONFIG_DEFAULT_UIMAGE) += uImage
#
# Board ports in arch/powerpc/platform/40x/Kconfig
-image-$(CONFIG_EP405) += zImage-dtb.ep405
+image-$(CONFIG_EP405) += dtbImage.ep405
image-$(CONFIG_WALNUT) += treeImage.walnut
# Board ports in arch/powerpc/platform/44x/Kconfig
@@ -220,9 +220,9 @@ image-$(CONFIG_WARP) += cuImage.warp
# Board ports in arch/powerpc/platform/8xx/Kconfig
image-$(CONFIG_PPC_MPC86XADS) += cuImage.mpc866ads
image-$(CONFIG_PPC_MPC885ADS) += cuImage.mpc885ads
-image-$(CONFIG_PPC_EP88XC) += zImage-dtb.ep88xc
+image-$(CONFIG_PPC_EP88XC) += dtbImage.ep88xc
image-$(CONFIG_PPC_ADDER875) += cuImage.adder875-uboot \
- zImage-dtb.adder875-redboot
+ dtbImage.adder875-redboot
# Board ports in arch/powerpc/platform/52xx/Kconfig
image-$(CONFIG_PPC_LITE5200) += cuImage.lite5200 cuImage.lite5200b
@@ -230,7 +230,7 @@ image-$(CONFIG_PPC_LITE5200) += cuImage.lite5200 cuImage.lite5200b
# Board ports in arch/powerpc/platform/82xx/Kconfig
image-$(CONFIG_MPC8272_ADS) += cuImage.mpc8272ads
image-$(CONFIG_PQ2FADS) += cuImage.pq2fads
-image-$(CONFIG_EP8248E) += zImage-dtb.ep8248e
+image-$(CONFIG_EP8248E) += dtbImage.ep8248e
# Board ports in arch/powerpc/platform/83xx/Kconfig
image-$(CONFIG_MPC832x_MDS) += cuImage.mpc832x_mds
@@ -268,7 +268,8 @@ endif
initrd- := $(patsubst zImage%, zImage.initrd%, $(image-n) $(image-))
initrd-y := $(patsubst zImage%, zImage.initrd%, \
- $(patsubst treeImage%, treeImage.initrd%, $(image-y)))
+ $(patsubst dtbImage%, dtbImage.initrd%, \
+ $(patsubst treeImage%, treeImage.initrd%, $(image-y))))
initrd-y := $(filter-out $(image-y), $(initrd-y))
targets += $(image-y) $(initrd-y)
@@ -283,10 +284,11 @@ $(obj)/zImage.initrd.%: vmlinux $(wrapperbits)
$(obj)/zImage.%: vmlinux $(wrapperbits)
$(call if_changed,wrap,$*)
-$(obj)/zImage-dtb.initrd.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
+# dtbImage% - a dtbImage is a zImage with an embedded device tree blob
+$(obj)/dtbImage.initrd.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
$(call if_changed,wrap,$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
-$(obj)/zImage-dtb.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
+$(obj)/dtbImage.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
$(call if_changed,wrap,$*,$(dtstree)/$*.dts)
# This cannot be in the root of $(src) as the zImage rule always adds a $(obj)
^ permalink raw reply related
* Re: Xilinx PowerPC
From: Grant Likely @ 2008-02-21 19:02 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-embedded
In-Reply-To: <20080221175025.7817BBD8057@mail91-sin.bigfish.com>
On Thu, Feb 21, 2008 at 10:50 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> > Step 2).
> > the code in arch/powerpc/???? is the devicetree equvalent
> to
> > arch/ppc/platforms/4xx/xilinx_ml410.c
> http://git.xilinx.com/linux-2.6-xlnx.git contains a preliminary stab at
> the bootcode for Virtex. I've been using this for a while with
> ARCH=powerpc. There isn't really much need for board specific platform
> code: This should (I think) be handled by the device tree. All of this
> is still pretty preliminary at the moment however. The big problem with
> the boot code in the Xilinx tree is that you need to be able to allocate
> memory in order to parse the device tree in order to figure out how much
> memory you have. I just haven't rewritten the code to use libfdt, which
> can query the device tree without memory allocation yet. Grant has a
> slightly different scheme in his tree, but it works as well. Generally
> I've been more focused on avoiding u-boot, whereas Grant has been using
> u-boot exclusively, I think.
Actually, I'm not using u-boot at all. I've reworked the 'raw' image
target to use libfdt and properly initialize the cache and stuff.
I'll be merging it in the .26 merge window.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: TLB Miss booting linux kernel on ppc 405
From: Robert Woodworth @ 2008-02-21 19:12 UTC (permalink / raw)
To: David Baird; +Cc: linuxppc-embedded
In-Reply-To: <440abda90802211004h3833ed00ke1cdc1257e2b0379@mail.gmail.com>
I'm no expert but....
I did configure my device with the DCR enabled and connected the PLBv46
DCR to the PPC. In the TLB miss ISR I read the PLB registers and the
MCSR I *DID* notice that the PLB error registers were set.
I added some asm code to read MCSR (see Xilinx UG011.pdf, page 213) and
I also added the asm code to read the DCR of the PLB. Sure enough, the
MCSR and PLB-DCR registers showed a DPLBError.
It's only a couple of asm statements:
mfspr r30, 0x23c
Question to Xilinx experts:
What would cause the PLB to issue the DPLBError?????
<note to Xilinx>
Hey Xilinx guys!
Can you hack the gdb included with EDK such that it will recognize the
MCSR when gdb reads registers!
</note to Xilinx>
On Thu, 2008-02-21 at 11:04 -0700, David Baird wrote:
> Hi Robert,
>
> On Wed, Feb 20, 2008 at 2:24 PM, Robert Woodworth
> <rwoodworth@securics.com> wrote:
> > I'm under the suspicion that the PLB is issuing an error when switching
> > to virtual mode and that there is either a timing/synthesis error or a
> > fundamental error with the way the FPGA is getting synthesized with the
> > PLB.
>
> Can you offer a suggestion how I can check to see if the PLB is
> issuing an error (a good application note for me to read or anything)?
> I was having a similar problem in virtual mode on one of my systems,
> and I might be able to see also if I am having a problem with the PLB
> bus.
>
> -David
^ permalink raw reply
* [PATCH] [POWERPC] add target for building .dtb files
From: Grant Likely @ 2008-02-21 19:19 UTC (permalink / raw)
To: linuxppc-dev, jwboyer
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Josh, is this what your were looking for?
Cheers,
g.
---
arch/powerpc/Makefile | 2 +-
arch/powerpc/boot/Makefile | 4 ++++
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index ab5cfe8..dd80825 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -164,7 +164,7 @@ boot := arch/$(ARCH)/boot
$(BOOT_TARGETS): vmlinux
$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
-bootwrapper_install:
+bootwrapper_install %.dtb:
$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
define archhelp
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d57a67d..fb29f10 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -311,6 +311,10 @@ $(obj)/treeImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
$(obj)/treeImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts)
+# Rule to build device tree blobs
+$(obj)/%.dtb: $(dtstree)/%.dts $(obj)/dtc
+ $(obj)/dtc -O dtb -o $(obj)/$*.dtb -b 0 $(dtstree)/$*.dts
+
# If there isn't a platform selected then just strip the vmlinux.
ifeq (,$(image-y))
image-y := vmlinux.strip
^ permalink raw reply related
* [PATCH] [POWERPC] 8xx: timebase frequency should not depend on bus-frequency
From: Anton Vorontsov @ 2008-02-21 19:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
m8xx_setup.c says:
/* Force all 8xx processors to use divide by 16 processor clock. */
And at the same time it is using bus-frequency for calculating
timebase. It is okay for most setups because bus-frequency is
equal to clock-frequency.
The problem emerges when cpu frequency is > 66MHz, quoting
u-boot/cpu/mpc8xx/speed.c:
if (gd->cpu_clk <= 66000000) {
sccr_reg |= SCCR_EBDF00; /* bus division factor = 1 */
gd->bus_clk = gd->cpu_clk;
} else {
sccr_reg |= SCCR_EBDF01; /* bus division factor = 2 */
gd->bus_clk = gd->cpu_clk / 2;
}
So in case of cpu clock > 66MHz, bus_clk = cpu_clk / 2. An then, from
Linux, we calculate timebase frequency as tb_freq = bus_clk / 16,
that is cpu_clk / 2 / 16, which is wrong.
This patch fixes system time drifting problem on the EP885C board
running at 133MHz.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/8xx/m8xx_setup.c | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c b/arch/powerpc/platforms/8xx/m8xx_setup.c
index 184f998..0d9f75c 100644
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -111,17 +111,12 @@ void __init mpc8xx_calibrate_decr(void)
/* Processor frequency is MHz.
*/
- ppc_tb_freq = 50000000;
- if (!get_freq("bus-frequency", &ppc_tb_freq)) {
- printk(KERN_ERR "WARNING: Estimating decrementer frequency "
- "(not found)\n");
- }
- ppc_tb_freq /= 16;
ppc_proc_freq = 50000000;
if (!get_freq("clock-frequency", &ppc_proc_freq))
printk(KERN_ERR "WARNING: Estimating processor frequency "
"(not found)\n");
+ ppc_tb_freq = ppc_proc_freq / 16;
printk("Decrementer Frequency = 0x%lx\n", ppc_tb_freq);
/* Perform some more timer/timebase initialization. This used
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] [POWERPC] 8xx: timebase frequency should not depend on bus-frequency
From: Scott Wood @ 2008-02-21 19:48 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080221194508.GA12896@localhost.localdomain>
Anton Vorontsov wrote:
> diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c b/arch/powerpc/platforms/8xx/m8xx_setup.c
> index 184f998..0d9f75c 100644
> --- a/arch/powerpc/platforms/8xx/m8xx_setup.c
> +++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
> @@ -111,17 +111,12 @@ void __init mpc8xx_calibrate_decr(void)
>
> /* Processor frequency is MHz.
> */
> - ppc_tb_freq = 50000000;
> - if (!get_freq("bus-frequency", &ppc_tb_freq)) {
> - printk(KERN_ERR "WARNING: Estimating decrementer frequency "
> - "(not found)\n");
> - }
> - ppc_tb_freq /= 16;
> ppc_proc_freq = 50000000;
> if (!get_freq("clock-frequency", &ppc_proc_freq))
> printk(KERN_ERR "WARNING: Estimating processor frequency "
> "(not found)\n");
>
> + ppc_tb_freq = ppc_proc_freq / 16;
Shouldn't we just use the timebase-frequency property?
-Scott
^ permalink raw reply
* [PATCH] [USB POWERPC] ehci: fix ppc build
From: Anton Vorontsov @ 2008-02-21 19:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: dbrownell, linux-usb
Currently, this setup:
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_HCD_PPC_OF=y
Will fail to build:
CC drivers/usb/host/ehci-hcd.o
drivers/usb/host/ehci-hcd.c:1018:2: error: #error "missing bus glue for ehci-hcd"
make[3]: *** [drivers/usb/host/ehci-hcd.o] Error 1
ehci-hcd.c actually contains OF_PLATFORM_DRIVER glue, so error is bogus.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/usb/host/ehci-hcd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 4caa6a8..3a19b1a 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1014,7 +1014,7 @@ MODULE_LICENSE ("GPL");
#endif
#if !defined(PCI_DRIVER) && !defined(PLATFORM_DRIVER) && \
- !defined(PS3_SYSTEM_BUS_DRIVER)
+ !defined(PS3_SYSTEM_BUS_DRIVER) && !defined(OF_PLATFORM_DRIVER)
#error "missing bus glue for ehci-hcd"
#endif
--
1.5.2.2
^ permalink raw reply related
* [PATCH] [USB POWERPC] ehci-fsl: add PPC_MPC837x to default y
From: Anton Vorontsov @ 2008-02-21 19:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-usb
Without this patch it's impossible to select ehci-fsl on PPC_MPC837x.
Another option would be to convert USB_EHCI_FSL to verbose bool,
but I presume EHCI_FSL is purposely made silent.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/usb/host/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index d97b16b..33da056 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -72,7 +72,7 @@ config USB_EHCI_FSL
bool
depends on USB_EHCI_HCD
select USB_EHCI_ROOT_HUB_TT
- default y if MPC834x || PPC_MPC831x
+ default y if MPC834x || PPC_MPC831x || PPC_MPC837x
---help---
Variation of ARC USB block used in some Freescale chips.
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] [USB POWERPC] ehci-fsl: add PPC_MPC837x to default y
From: Scott Wood @ 2008-02-21 19:55 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <20080221195021.GC12896@localhost.localdomain>
Anton Vorontsov wrote:
> Without this patch it's impossible to select ehci-fsl on PPC_MPC837x.
> Another option would be to convert USB_EHCI_FSL to verbose bool,
> but I presume EHCI_FSL is purposely made silent.
I think making it verbose bool would be better.
-Scott
^ permalink raw reply
* Re: [PATCH] [USB POWERPC] ehci-fsl: add PPC_MPC837x to default y
From: Kumar Gala @ 2008-02-21 19:58 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <20080221195021.GC12896@localhost.localdomain>
On Feb 21, 2008, at 1:50 PM, Anton Vorontsov wrote:
> Without this patch it's impossible to select ehci-fsl on PPC_MPC837x.
> Another option would be to convert USB_EHCI_FSL to verbose bool,
> but I presume EHCI_FSL is purposely made silent.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/usb/host/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index d97b16b..33da056 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -72,7 +72,7 @@ config USB_EHCI_FSL
> bool
> depends on USB_EHCI_HCD
> select USB_EHCI_ROOT_HUB_TT
> - default y if MPC834x || PPC_MPC831x
> + default y if MPC834x || PPC_MPC831x || PPC_MPC837x
Can we just change this to FSL_SOC
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] 8xx: timebase frequency should not depend on bus-frequency
From: Anton Vorontsov @ 2008-02-21 19:59 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47BDD587.9060206@freescale.com>
On Thu, Feb 21, 2008 at 01:48:23PM -0600, Scott Wood wrote:
> Anton Vorontsov wrote:
> >diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c
> >b/arch/powerpc/platforms/8xx/m8xx_setup.c
> >index 184f998..0d9f75c 100644
> >--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
> >+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
> >@@ -111,17 +111,12 @@ void __init mpc8xx_calibrate_decr(void)
> >
> > /* Processor frequency is MHz.
> > */
> >- ppc_tb_freq = 50000000;
> >- if (!get_freq("bus-frequency", &ppc_tb_freq)) {
> >- printk(KERN_ERR "WARNING: Estimating decrementer frequency "
> >- "(not found)\n");
> >- }
> >- ppc_tb_freq /= 16;
> > ppc_proc_freq = 50000000;
> > if (!get_freq("clock-frequency", &ppc_proc_freq))
> > printk(KERN_ERR "WARNING: Estimating processor frequency "
> > "(not found)\n");
> >
> >+ ppc_tb_freq = ppc_proc_freq / 16;
>
> Shouldn't we just use the timebase-frequency property?
Nope. Most u-boots currently do not setup timebase-frequency, and if
they are setting it up, they're doing it wrong, in sense that Linux
overwrites timebase setup (yeah, in this regard MPC8xx is special).
So, for MPC8xx, Linux doesn't care what timebase setup was used in
the firmware.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] [USB POWERPC] ehci: fix ppc build
From: David Brownell @ 2008-02-21 19:59 UTC (permalink / raw)
To: linuxppc-dev, avorontsov; +Cc: linux-usb
In-Reply-To: <20080221194913.GB12896@localhost.localdomain>
> From avorontsov@ru.mvista.com Thu Feb 21 11:49:48 2008
> Date: Thu, 21 Feb 2008 22:49:13 +0300
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> To: linuxppc-dev@ozlabs.org
> Cc: linux-usb@vger.kernel.org, dbrownell@users.sourceforge.net
> Subject: [PATCH] [USB POWERPC] ehci: fix ppc build
>
> Currently, this setup:
> CONFIG_USB_ARCH_HAS_EHCI=y
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_EHCI_HCD_PPC_OF=y
>
> Will fail to build:
> CC drivers/usb/host/ehci-hcd.o
> drivers/usb/host/ehci-hcd.c:1018:2: error: #error "missing bus glue for ehci-hcd"
> make[3]: *** [drivers/usb/host/ehci-hcd.o] Error 1
>
> ehci-hcd.c actually contains OF_PLATFORM_DRIVER glue, so error is bogus.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
... for 2.6.25 ...
> ---
> drivers/usb/host/ehci-hcd.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index 4caa6a8..3a19b1a 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -1014,7 +1014,7 @@ MODULE_LICENSE ("GPL");
> #endif
>
> #if !defined(PCI_DRIVER) && !defined(PLATFORM_DRIVER) && \
> - !defined(PS3_SYSTEM_BUS_DRIVER)
> + !defined(PS3_SYSTEM_BUS_DRIVER) && !defined(OF_PLATFORM_DRIVER)
> #error "missing bus glue for ehci-hcd"
> #endif
>
> --
> 1.5.2.2
>
^ permalink raw reply
* Re: [PATCH] [POWERPC] 8xx: timebase frequency should not depend on bus-frequency
From: Scott Wood @ 2008-02-21 20:06 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080221195918.GA14636@localhost.localdomain>
Anton Vorontsov wrote:
> On Thu, Feb 21, 2008 at 01:48:23PM -0600, Scott Wood wrote:
>> Anton Vorontsov wrote:
>>> diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c
>>> b/arch/powerpc/platforms/8xx/m8xx_setup.c
>>> index 184f998..0d9f75c 100644
>>> --- a/arch/powerpc/platforms/8xx/m8xx_setup.c
>>> +++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
>>> @@ -111,17 +111,12 @@ void __init mpc8xx_calibrate_decr(void)
>>>
>>> /* Processor frequency is MHz.
>>> */
>>> - ppc_tb_freq = 50000000;
>>> - if (!get_freq("bus-frequency", &ppc_tb_freq)) {
>>> - printk(KERN_ERR "WARNING: Estimating decrementer frequency "
>>> - "(not found)\n");
>>> - }
>>> - ppc_tb_freq /= 16;
>>> ppc_proc_freq = 50000000;
>>> if (!get_freq("clock-frequency", &ppc_proc_freq))
>>> printk(KERN_ERR "WARNING: Estimating processor frequency "
>>> "(not found)\n");
>>>
>>> + ppc_tb_freq = ppc_proc_freq / 16;
>> Shouldn't we just use the timebase-frequency property?
>
> Nope. Most u-boots currently do not setup timebase-frequency, and if
> they are setting it up, they're doing it wrong, in sense that Linux
> overwrites timebase setup (yeah, in this regard MPC8xx is special).
Current u-boots don't support device trees at all on 8xx. The most
recent 8xx FDT patch I saw called get_tbclk() to fill in
timebase-frequency; does get_tbclk() not work?
Obviously, when booting with a cuImage we can't use u-boot's value,
since it's not in the bd_t. In that case, we should fix the wrapper's
calculation of the timebase frequency.
-Scott
^ permalink raw reply
* How to dynamically disable/enable CPU features?
From: Gerhard Pircher @ 2008-02-21 20:07 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm wondering how to disable or enable CPU features based on the board the
kernel is running on. In my case I want to disable the
CPU_FTR_NEED_COHERENT flag for 74xx CPUs, because it locks up the machine.
I tried to clear the flag in the platform's *_probe() function with the
following code:
cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
First I thought that this works fine, because the kernel booted once till
the console login prompt (and died afterwards). Therefore I suspected that
another change or bug in the kernel conflicts with my hardware (usually
the machine died much earlier on older kernels, if the flag wasn't
cleared).
Now I removed all CPU_FTR_NEED_COHERENT entries from the cputable.h file
and the kernel boots just fine without any lockups (reproducable).
I don't quite understand the difference between dynamically clearing the
flag in the platform setup code and removing the flag for all CPU
defines in cputable.h. I can only suspect that clearing the flag in the
platform probe function is too late, as the MMU and BATs may already be
set up.
Can anybody confirm my suspicion or give me a hint how to implement it
correctly? (I don't want to tinker with cputable.h)
Thanks!
regards,
Gerhard
--
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games!
http://games.entertainment.web.de/de/entertainment/games/free
^ permalink raw reply
* Re: [PATCH] [USB POWERPC] ehci-fsl: add PPC_MPC837x to default y
From: Scott Wood @ 2008-02-21 20:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <9AD13D2E-B57F-4F19-B89C-C8A83157E0F2@kernel.crashing.org>
Kumar Gala wrote:
> On Feb 21, 2008, at 1:50 PM, Anton Vorontsov wrote:
>
>> Without this patch it's impossible to select ehci-fsl on PPC_MPC837x.
>> Another option would be to convert USB_EHCI_FSL to verbose bool,
>> but I presume EHCI_FSL is purposely made silent.
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>> drivers/usb/host/Kconfig | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> index d97b16b..33da056 100644
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -72,7 +72,7 @@ config USB_EHCI_FSL
>> bool
>> depends on USB_EHCI_HCD
>> select USB_EHCI_ROOT_HUB_TT
>> - default y if MPC834x || PPC_MPC831x
>> + default y if MPC834x || PPC_MPC831x || PPC_MPC837x
>
> Can we just change this to FSL_SOC
Why do you want to bloat all freescale kernels, even on chips that don't
have this hardware?
There are very few cases where default y is justified. This isn't one
of them.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] add target for building .dtb files
From: Grant Erickson @ 2008-02-21 20:03 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20080221191955.10139.10496.stgit@trillian.secretlab.ca>
On 2/21/08 11:19 AM, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> ---
>
> Josh, is this what your were looking for?
>
> Cheers,
> g.
> ---
>
> arch/powerpc/Makefile | 2 +-
> arch/powerpc/boot/Makefile | 4 ++++
> 2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index ab5cfe8..dd80825 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -164,7 +164,7 @@ boot := arch/$(ARCH)/boot
> $(BOOT_TARGETS): vmlinux
> $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>
> -bootwrapper_install:
> +bootwrapper_install %.dtb:
> $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>
> define archhelp
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index d57a67d..fb29f10 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -311,6 +311,10 @@ $(obj)/treeImage.initrd.%: vmlinux $(dtstree)/%.dts
> $(wrapperbits)
> $(obj)/treeImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
> $(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts)
>
> +# Rule to build device tree blobs
> +$(obj)/%.dtb: $(dtstree)/%.dts $(obj)/dtc
> + $(obj)/dtc -O dtb -o $(obj)/$*.dtb -b 0 $(dtstree)/$*.dts
> +
Grant,
Would it be beneficial to provide a way to have environment- or
command-line-provided DTC arguments/flags such that the oft-required '-S
<size>' and '-R <reserved>' flags can be specified? Or, are there reasonable
size and reserved defaults appropriate for all platforms that can be
specified?
FWIW, generating a blob for Haleakala/Kilauea on the PPC405EX[r] using the
above command in the patch results in complaints about lack of space for the
"CHOSEN" node in u-boot.
Regards,
Grant
^ permalink raw reply
* Re: [PATCH] [POWERPC] add target for building .dtb files
From: Scott Wood @ 2008-02-21 20:14 UTC (permalink / raw)
To: Grant Erickson; +Cc: linuxppc-dev
In-Reply-To: <C3E318FD.D883%gerickson@nuovations.com>
Grant Erickson wrote:
>> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
>> index d57a67d..fb29f10 100644
>> --- a/arch/powerpc/boot/Makefile
>> +++ b/arch/powerpc/boot/Makefile
>> @@ -311,6 +311,10 @@ $(obj)/treeImage.initrd.%: vmlinux $(dtstree)/%.dts
>> $(wrapperbits)
>> $(obj)/treeImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
>> $(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts)
>>
>> +# Rule to build device tree blobs
>> +$(obj)/%.dtb: $(dtstree)/%.dts $(obj)/dtc
>> + $(obj)/dtc -O dtb -o $(obj)/$*.dtb -b 0 $(dtstree)/$*.dts
>> +
>
> Grant,
>
> Would it be beneficial to provide a way to have environment- or
> command-line-provided DTC arguments/flags such that the oft-required '-S
> <size>' and '-R <reserved>' flags can be specified? Or, are there reasonable
> size and reserved defaults appropriate for all platforms that can be
> specified?
These aren't required for the bootwrapper, which is the main purpose of
the bootwrapper makefile...
> FWIW, generating a blob for Haleakala/Kilauea on the PPC405EX[r] using the
> above command in the patch results in complaints about lack of space for the
> "CHOSEN" node in u-boot.
U-boot should be fixed to not need this. It's ridiculous.
-Scott
^ permalink raw reply
* Re: [PATCH] [USB POWERPC] ehci-fsl: add PPC_MPC837x to default y
From: Anton Vorontsov @ 2008-02-21 20:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <9AD13D2E-B57F-4F19-B89C-C8A83157E0F2@kernel.crashing.org>
On Thu, Feb 21, 2008 at 01:58:18PM -0600, Kumar Gala wrote:
>
> On Feb 21, 2008, at 1:50 PM, Anton Vorontsov wrote:
>
> >Without this patch it's impossible to select ehci-fsl on PPC_MPC837x.
> >Another option would be to convert USB_EHCI_FSL to verbose bool,
> >but I presume EHCI_FSL is purposely made silent.
> >
> >Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> >---
> >drivers/usb/host/Kconfig | 2 +-
> >1 files changed, 1 insertions(+), 1 deletions(-)
> >
> >diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> >index d97b16b..33da056 100644
> >--- a/drivers/usb/host/Kconfig
> >+++ b/drivers/usb/host/Kconfig
> >@@ -72,7 +72,7 @@ config USB_EHCI_FSL
> > bool
> > depends on USB_EHCI_HCD
> > select USB_EHCI_ROOT_HUB_TT
> >- default y if MPC834x || PPC_MPC831x
> >+ default y if MPC834x || PPC_MPC831x || PPC_MPC837x
>
> Can we just change this to FSL_SOC
Easily. But not "default y"... "depends on" instead, ok?
There are plenty of FSL chips without EHCI built-in, so with
default y we'll enable it wrongly.
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [USB POWERPC] ehci-fsl: handles other freescale processors
This patch converts USB_EHCI_FSL config option into the verbose
bool, so we'll able to select it for other freescale processors
with built-in EHCI controller.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/usb/host/Kconfig | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index d97b16b..bf8be2a 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -69,10 +69,9 @@ config USB_EHCI_BIG_ENDIAN_DESC
default y
config USB_EHCI_FSL
- bool
- depends on USB_EHCI_HCD
+ bool "Support for Freescale on-chip EHCI USB controller"
+ depends on USB_EHCI_HCD && FSL_SOC
select USB_EHCI_ROOT_HUB_TT
- default y if MPC834x || PPC_MPC831x
---help---
Variation of ARC USB block used in some Freescale chips.
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] [POWERPC] 8xx: timebase frequency should not depend on bus-frequency
From: Anton Vorontsov @ 2008-02-21 21:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47BDD9E2.5050007@freescale.com>
On Thu, Feb 21, 2008 at 02:06:58PM -0600, Scott Wood wrote:
[...]
> >>>+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
> >>>@@ -111,17 +111,12 @@ void __init mpc8xx_calibrate_decr(void)
> >>>
> >>> /* Processor frequency is MHz.
> >>> */
> >>>- ppc_tb_freq = 50000000;
> >>>- if (!get_freq("bus-frequency", &ppc_tb_freq)) {
> >>>- printk(KERN_ERR "WARNING: Estimating decrementer frequency "
> >>>- "(not found)\n");
> >>>- }
> >>>- ppc_tb_freq /= 16;
> >>> ppc_proc_freq = 50000000;
> >>> if (!get_freq("clock-frequency", &ppc_proc_freq))
> >>> printk(KERN_ERR "WARNING: Estimating processor frequency "
> >>> "(not found)\n");
> >>>
> >>>+ ppc_tb_freq = ppc_proc_freq / 16;
> >>Shouldn't we just use the timebase-frequency property?
> >
> >Nope. Most u-boots currently do not setup timebase-frequency, and if
> >they are setting it up, they're doing it wrong, in sense that Linux
> >overwrites timebase setup (yeah, in this regard MPC8xx is special).
>
> Current u-boots don't support device trees at all on 8xx.
Yes, vanilla u-boots. I assume many of us use some u-boot hacks to
actually boot with the device tree (no, not cuboots)... ;-)
> The most
> recent 8xx FDT patch I saw called get_tbclk() to fill in
> timebase-frequency; does get_tbclk() not work?
I don't know. I didn't look at this, it isn't interesting because
currently getting timebase-frequency from the device tree is
meaningless on MPC8xx. Linux is doing timebase stuff on its own.
Surely, moving timebase setup code into the cuboot will solve
backwards compatibility issues, so we'll setup timebase-frequency
there, and will use generic_calibrate_decr(). And for FDT-aware
u-boots we'll simply get fixed up timebase-frequency.
Unfortunately (or fortunately ;-) I don't have this 8xx board
any longer, so I'd suggest to not expect such 8xx cleanups from
me in near future...
If you have such patches pending... surely, they would be more
correct way to solve the issue.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] [POWERPC] 8xx: timebase frequency should not depend on bus-frequency
From: Scott Wood @ 2008-02-21 21:20 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080221211343.GA24786@localhost.localdomain>
Anton Vorontsov wrote:
> On Thu, Feb 21, 2008 at 02:06:58PM -0600, Scott Wood wrote:
>> Current u-boots don't support device trees at all on 8xx.
>
> Yes, vanilla u-boots. I assume many of us use some u-boot hacks to
> actually boot with the device tree (no, not cuboots)... ;-)
Fine, but don't expect misbehavior from out-of-tree u-boots to be used
as justification for the kernel ignoring device tree content. :-)
-Scott
^ permalink raw reply
* MODPOST section mismatches
From: Steve Heflin @ 2008-02-21 21:33 UTC (permalink / raw)
To: linuxppc-embedded
while building vmlinux.o the MODPOST warns about 8 section mismatches.
WARNING: modpost: Found 8 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
After modifying the make launch to include the recommended option
shown above, I see that the section mismatch warning is due to data
structures containing the address of initialization modules which
have the __init attribute. Since the memory model is FLAT, is this a problem?
thanks,
Steve
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox