* Re: Newbie
From: David Hawkins @ 2006-03-14 22:09 UTC (permalink / raw)
To: Eric Heim; +Cc: linuxppc-embedded
In-Reply-To: <20060314212941.87682.qmail@web37811.mail.mud.yahoo.com>
Eric Heim wrote:
> Any suggestions for geting started on embedded Linux. I'm supposed to
> be using embedded linux on an mpc83xx taget board with an x86 host. I
> have searched many sites and most information is over my head. I know
> very little. Anyone know of a good getting started guide?
>
Hey Eric,
Read Karim Yaghmour's 'Building Embedded Linux Systems', its a nice
introduction to the subject.
Do you know which MPC83xx target board you will be using?
Regards
Dave
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: Mark A. Greer @ 2006-03-14 23:52 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20060314033135.GA24168@localhost.localdomain>
On Tue, Mar 14, 2006 at 02:31:35PM +1100, David Gibson wrote:
> On Mon, Mar 13, 2006 at 02:21:05PM -0700, Mark A. Greer wrote:
> > Hi David,
> >
> > I'm playing around with moving some 32-bit embedded platforms (that don't
> > have OF or dev-tree-aware uboot) to the powerpc tree. Basically, I make an
> > initial .dts file for that platform then dtc-compile it using:
> >
> > dtc -I dts -O asm -o <platform>.S -V 16 <platform>.dts
> >
> > Then I build the <platform>.S file with the normal bootwrapper/kernel build.
> >
> > The problem I'm having is that dtc generates some .quad directives that
> > is causing my 32-bit assembler to choke (.quad not supported). Do we need
> > a 32-bit switch for dtc or should I be giving some sort of switch to
> > gcc(version 3.4.3)/gas(version 2.15.94) to make it work?
>
> [snip]
> > dtc asm output:
> > ---------------
> >
> > /* autogenerated by dtc, do not edit */
> >
> > <snip>
> >
> > dt_reserve_map:
> > _dt_reserve_map:
> > .quad 0, _dt_blob_start
> > .quad 0, _dt_blob_end - _dt_blob_start
> > /* Memory reserve map from source file */
> > .quad 0
> > .quad 0
> >
> > <snip>
>
> Oh, bother. I guess I never tried with a 32-bit only assembler. Um,
> a number of observations are applicable here:
> - The flattened tree spec defines the memory range fields to
> be 64-bit quantities, always, so these things shouldn't just become
> ".long" for 32-bit targets.
> - For the "spacer" 0 entries, we can and should just replace
> the .quad with two ".long" directives, easy change.
> - The autogenerated entry reserving the tree itself, however,
> is trickier. It genuinely needs to be a .quad for 64-bit targets. So
> I guess we'd have to have a 32/64 bit target option. Yuck.
> - IIRC BenH was contemplating revising the spec so that the
> range for the device tree is reserved implicitly, like the range for
> the kernel image, so it wouldn't have to be listed in the blob. This
> would sidestep the problem, though we would have to change dtc to omit
> this entry, at least for suitable output blob versions.
> - I've been thinking for a while, that the whole memory
> reserve thing needs some work in dtc. The fact that the range for the
> tree blob is included automatically for asm output, but not for blob
> output is a wart, at least. I was thinking about instead of
> automatically generating it, including a new keyword, or form for the
> /memreserve/ directive that will generate this range if necessary /
> possible. I never got around to implementing that, though.
>
> And finally, as of, well right about now, until October or so, I'm
> expecting to be unavailable, off travelling and things. In the
> interim Jon Loeliger of Freescale has agreed to be dtc maintainer.
Jon, any comments?
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: Jon Loeliger @ 2006-03-15 0:06 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20060314235254.GA6045@mag.az.mvista.com>
So, like, the other day "Mark A. Greer" mumbled:
> >
> > And finally, as of, well right about now, until October or so, I'm
> > expecting to be unavailable, off travelling and things. In the
> > interim Jon Loeliger of Freescale has agreed to be dtc maintainer.
>
> Jon, any comments?
For 9 months nothing. Dave abdicates his DTC maintainer role to me.
The very next day, all hell breaks loose! Of _course_ I have comments!
Uh, I've been bitten by the difference between the binary and asm
form of these outputs before as well. Specifically where the reserve
map included its own layout region as a reserve block. IIRC, though,
it was a physical versus virtual address problem that, though understood,
we didn't really resolve.
I was eventually forced to move along, as that was not the battle I
was looking for. Our U-Boot eventually went to a straight binary
form that was directly munged into a C array definition and side-stepped
that issue.
As for the 64-bit-ness problem, I'm willing to accept donated 64-bit
hardware that would allow me to test the problems you are seeing. :-)
I mean, any patches that drift my way will be considered. :-)
Oh, and, give me a couple days to clone and set up a repository too...
jdl
^ permalink raw reply
* header files
From: Henry Quinn @ 2006-03-15 5:02 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 400 bytes --]
guru bala wrote:
> can anyone give headerfiles for mpc850 to write c programs and compile
them with singlestep simul;ator for powerpc
I wish I could help but can not. This will be our first Linux project on an
embedded processor and I am still a bit lost.
Thanks for this list though, I worked through almost half the archive
yesterday so as not to sound too stupid. :-)
Regards
Henry
[-- Attachment #2: Type: text/html, Size: 3221 bytes --]
^ permalink raw reply
* please pull powerpc-merge.git
From: Paul Mackerras @ 2006-03-15 5:52 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
There are 5 commits in there which fix bugs which need to be fixed for
2.6.16:
Benjamin Herrenschmidt:
powerpc: enable NAP only on cpus who support it to avoid memory corruption
John Rose:
powerpc: properly configure DDR/P5IOC children devs
Michael Neuling:
powerpc: RTC memory corruption
Olaf Hering:
powerpc: correct cacheflush loop in zImage
Paul Mackerras:
powerpc: Fix problem with time going backwards
plus a patch from Olaf Hering to remove some duplicate EXPORT_SYMBOLs,
which cause warnings at compile time (perhaps not critical, but still
should be fixed, and the fix is low-impact),
plus two patches which make minor changes to Kconfig files:
Michael Ellerman:
powerpc: Clarify wording for CRASH_DUMP Kconfig option
Paul Mackerras:
powerpc: Disallow lparcfg being a module
plus two commits that update defconfig files:
Olaf Hering:
powerpc/64: enable CONFIG_BLK_DEV_SL82C105
Paul Mackerras:
powerpc: update defconfigs
I have included the full commit message plus patch below for all
except the defconfig updates.
Thanks,
Paul.
arch/powerpc/Kconfig | 2 -
arch/powerpc/boot/crt0.S | 5 +
arch/powerpc/configs/cell_defconfig | 94 +++++++++++++++++++--------
arch/powerpc/configs/iseries_defconfig | 96 +++++++++++++++++-----------
arch/powerpc/configs/maple_defconfig | 50 ++++++++++++---
arch/powerpc/configs/mpc834x_sys_defconfig | 32 +++++----
arch/powerpc/configs/pmac32_defconfig | 77 ++++++++++++++--------
arch/powerpc/configs/ppc64_defconfig | 2 -
arch/powerpc/kernel/pci_64.c | 5 +
arch/powerpc/kernel/ppc_ksyms.c | 10 ---
arch/powerpc/kernel/rtas-rtc.c | 2 -
arch/powerpc/kernel/rtas_pci.c | 24 -------
arch/powerpc/kernel/time.c | 48 ++++++++++----
arch/powerpc/mm/pgtable_32.c | 5 +
arch/powerpc/platforms/powermac/feature.c | 9 +--
arch/powerpc/platforms/powermac/setup.c | 4 -
arch/powerpc/platforms/pseries/Kconfig | 2 -
arch/powerpc/platforms/pseries/pci_dlpar.c | 28 ++++++++
include/asm-powerpc/ppc-pci.h | 1
19 files changed, 315 insertions(+), 181 deletions(-)
diff-tree bb32754f054f42455cac667daea62668035f427c (from 7177ee48eb3a9f042f10d5b4e49f1737b988123d)
Author: John Rose <johnrose@austin.ibm.com>
Date: Tue Mar 14 17:46:45 2006 -0600
[PATCH] powerpc: properly configure DDR/P5IOC children devs
The dynamic add path for PCI Host Bridges can fail to configure children
adapters under P5IOC controllers. It fails to properly fixup bus/device
resources, and it fails to properly enable EEH. Both of these steps
need to occur before any children devices are enabled in
pci_bus_add_devices().
Signed-off-by: John Rose <johnrose@austin.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index c367520..ba92bab 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -589,7 +589,6 @@ void __devinit scan_phb(struct pci_contr
#endif /* CONFIG_PPC_MULTIPLATFORM */
if (mode == PCI_PROBE_NORMAL)
hose->last_busno = bus->subordinate = pci_scan_child_bus(bus);
- pci_bus_add_devices(bus);
}
static int __init pcibios_init(void)
@@ -608,8 +607,10 @@ static int __init pcibios_init(void)
printk("PCI: Probing PCI hardware\n");
/* Scan all of the recorded PCI controllers. */
- list_for_each_entry_safe(hose, tmp, &hose_list, list_node)
+ list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
scan_phb(hose);
+ pci_bus_add_devices(hose->bus);
+ }
#ifndef CONFIG_PPC_ISERIES
if (pci_probe_only)
diff --git a/arch/powerpc/kernel/rtas_pci.c b/arch/powerpc/kernel/rtas_pci.c
index 5579f65..7442775 100644
--- a/arch/powerpc/kernel/rtas_pci.c
+++ b/arch/powerpc/kernel/rtas_pci.c
@@ -280,8 +280,7 @@ static int phb_set_bus_ranges(struct dev
return 0;
}
-static int __devinit setup_phb(struct device_node *dev,
- struct pci_controller *phb)
+int __devinit setup_phb(struct device_node *dev, struct pci_controller *phb)
{
if (is_python(dev))
python_countermeasures(dev);
@@ -359,27 +358,6 @@ unsigned long __init find_and_init_phbs(
return 0;
}
-struct pci_controller * __devinit init_phb_dynamic(struct device_node *dn)
-{
- struct pci_controller *phb;
- int primary;
-
- primary = list_empty(&hose_list);
- phb = pcibios_alloc_controller(dn);
- if (!phb)
- return NULL;
- setup_phb(dn, phb);
- pci_process_bridge_OF_ranges(phb, dn, primary);
-
- pci_setup_phb_io_dynamic(phb, primary);
-
- pci_devs_phb_init_dynamic(phb);
- scan_phb(phb);
-
- return phb;
-}
-EXPORT_SYMBOL(init_phb_dynamic);
-
/* RPA-specific bits for removing PHBs */
int pcibios_remove_root_bus(struct pci_controller *phb)
{
diff --git a/arch/powerpc/platforms/pseries/pci_dlpar.c b/arch/powerpc/platforms/pseries/pci_dlpar.c
index f3bad90..44abdeb 100644
--- a/arch/powerpc/platforms/pseries/pci_dlpar.c
+++ b/arch/powerpc/platforms/pseries/pci_dlpar.c
@@ -27,6 +27,7 @@
#include <linux/pci.h>
#include <asm/pci-bridge.h>
+#include <asm/ppc-pci.h>
static struct pci_bus *
find_bus_among_children(struct pci_bus *bus,
@@ -179,3 +180,30 @@ pcibios_add_pci_devices(struct pci_bus *
}
}
EXPORT_SYMBOL_GPL(pcibios_add_pci_devices);
+
+struct pci_controller * __devinit init_phb_dynamic(struct device_node *dn)
+{
+ struct pci_controller *phb;
+ int primary;
+
+ primary = list_empty(&hose_list);
+ phb = pcibios_alloc_controller(dn);
+ if (!phb)
+ return NULL;
+ setup_phb(dn, phb);
+ pci_process_bridge_OF_ranges(phb, dn, 0);
+
+ pci_setup_phb_io_dynamic(phb, primary);
+
+ pci_devs_phb_init_dynamic(phb);
+
+ if (dn->child)
+ eeh_add_device_tree_early(dn);
+
+ scan_phb(phb);
+ pcibios_fixup_new_pci_devices(phb->bus, 0);
+ pci_bus_add_devices(phb->bus);
+
+ return phb;
+}
+EXPORT_SYMBOL_GPL(init_phb_dynamic);
diff --git a/include/asm-powerpc/ppc-pci.h b/include/asm-powerpc/ppc-pci.h
index f80482c..cf79bc7 100644
--- a/include/asm-powerpc/ppc-pci.h
+++ b/include/asm-powerpc/ppc-pci.h
@@ -38,6 +38,7 @@ void *traverse_pci_devices(struct device
void pci_devs_phb_init(void);
void pci_devs_phb_init_dynamic(struct pci_controller *phb);
+int setup_phb(struct device_node *dev, struct pci_controller *phb);
void __devinit scan_phb(struct pci_controller *hose);
/* From rtas_pci.h */
diff-tree 7177ee48eb3a9f042f10d5b4e49f1737b988123d (from 33bcc33f7f445c9c43a0f4a67b24561821b3aeaa)
Author: Olaf Hering <olh@suse.de>
Date: Tue Mar 14 21:21:11 2006 +0100
[PATCH] powerpc: remove duplicate EXPORT_SYMBOLS
remove warnings when building a 64bit kernel.
smp_call_function triggers also with 32bit kernel.
WARNING: vmlinux: duplicate symbol 'smp_call_function' previous definition was in vmlinux
arch/powerpc/kernel/ppc_ksyms.c:164:EXPORT_SYMBOL(smp_call_function);
arch/powerpc/kernel/smp.c:300:EXPORT_SYMBOL(smp_call_function);
WARNING: vmlinux: duplicate symbol 'ioremap' previous definition was in vmlinux
arch/powerpc/kernel/ppc_ksyms.c:113:EXPORT_SYMBOL(ioremap);
arch/powerpc/mm/pgtable_64.c:321:EXPORT_SYMBOL(ioremap);
WARNING: vmlinux: duplicate symbol '__ioremap' previous definition was in vmlinux
arch/powerpc/kernel/ppc_ksyms.c:117:EXPORT_SYMBOL(__ioremap);
arch/powerpc/mm/pgtable_64.c:322:EXPORT_SYMBOL(__ioremap);
WARNING: vmlinux: duplicate symbol 'iounmap' previous definition was in vmlinux
arch/powerpc/kernel/ppc_ksyms.c:118:EXPORT_SYMBOL(iounmap);
arch/powerpc/mm/pgtable_64.c:323:EXPORT_SYMBOL(iounmap);
Signed-off-by: Olaf Hering <olh@suse.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index 8a731ea..63ecbec 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -110,15 +110,6 @@ EXPORT_SYMBOL(_insw_ns);
EXPORT_SYMBOL(_outsw_ns);
EXPORT_SYMBOL(_insl_ns);
EXPORT_SYMBOL(_outsl_ns);
-EXPORT_SYMBOL(ioremap);
-#ifdef CONFIG_44x
-EXPORT_SYMBOL(ioremap64);
-#endif
-EXPORT_SYMBOL(__ioremap);
-EXPORT_SYMBOL(iounmap);
-#ifdef CONFIG_PPC32
-EXPORT_SYMBOL(ioremap_bot); /* aka VMALLOC_END */
-#endif
#if defined(CONFIG_PPC32) && (defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE))
EXPORT_SYMBOL(ppc_ide_md);
@@ -161,7 +152,6 @@ EXPORT_SYMBOL(__flush_icache_range);
EXPORT_SYMBOL(flush_dcache_range);
#ifdef CONFIG_SMP
-EXPORT_SYMBOL(smp_call_function);
#ifdef CONFIG_PPC32
EXPORT_SYMBOL(smp_hw_index);
#endif
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index f4e5ac1..d296eb6 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -37,6 +37,7 @@
unsigned long ioremap_base;
unsigned long ioremap_bot;
+EXPORT_SYMBOL(ioremap_bot); /* aka VMALLOC_END */
int io_bat_index;
#if defined(CONFIG_6xx) || defined(CONFIG_POWER3)
@@ -153,6 +154,7 @@ ioremap64(unsigned long long addr, unsig
{
return __ioremap(addr, size, _PAGE_NO_CACHE);
}
+EXPORT_SYMBOL(ioremap64);
void __iomem *
ioremap(phys_addr_t addr, unsigned long size)
@@ -162,6 +164,7 @@ ioremap(phys_addr_t addr, unsigned long
return ioremap64(addr64, size);
}
#endif /* CONFIG_PHYS_64BIT */
+EXPORT_SYMBOL(ioremap);
void __iomem *
__ioremap(phys_addr_t addr, unsigned long size, unsigned long flags)
@@ -247,6 +250,7 @@ __ioremap(phys_addr_t addr, unsigned lon
out:
return (void __iomem *) (v + ((unsigned long)addr & ~PAGE_MASK));
}
+EXPORT_SYMBOL(__ioremap);
void iounmap(volatile void __iomem *addr)
{
@@ -259,6 +263,7 @@ void iounmap(volatile void __iomem *addr
if (addr > high_memory && (unsigned long) addr < ioremap_bot)
vunmap((void *) (PAGE_MASK & (unsigned long)addr));
}
+EXPORT_SYMBOL(iounmap);
void __iomem *ioport_map(unsigned long port, unsigned int len)
{
diff-tree 33bcc33f7f445c9c43a0f4a67b24561821b3aeaa (from 486154a6329aca598d1590d6fc6ea074a8e3d7bd)
Author: Michael Neuling <mikey@neuling.org>
Date: Tue Mar 14 17:11:51 2006 +1100
[PATCH] powerpc: RTC memory corruption
We should be memset'ing the data we are pointing to, not the pointer
itself. This is in an error path so we probably don't hit it much.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
diff --git a/arch/powerpc/kernel/rtas-rtc.c b/arch/powerpc/kernel/rtas-rtc.c
index 635d3b9..34d073f 100644
--- a/arch/powerpc/kernel/rtas-rtc.c
+++ b/arch/powerpc/kernel/rtas-rtc.c
@@ -52,7 +52,7 @@ void rtas_get_rtc_time(struct rtc_time *
error = rtas_call(rtas_token("get-time-of-day"), 0, 8, ret);
if (error == RTAS_CLOCK_BUSY || rtas_is_extended_busy(error)) {
if (in_interrupt() && printk_ratelimit()) {
- memset(&rtc_tm, 0, sizeof(struct rtc_time));
+ memset(rtc_tm, 0, sizeof(struct rtc_time));
printk(KERN_WARNING "error: reading clock"
" would delay interrupt\n");
return; /* delay not allowed */
diff-tree 486154a6329aca598d1590d6fc6ea074a8e3d7bd (from 6275062d9d9f1709543667cb509755c2a1c9153a)
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Sun Mar 12 10:55:01 2006 +1100
[PATCH] powerpc: enable NAP only on cpus who support it to avoid memory corruption
This patch fixes incorrect setting of powersave_nap to 1 on all
PowerMacs, potentially causing memory corruption on some models. This
bug was introuced by me during the 32/64 bits merge.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index 34714d3..bbe7948 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -2491,9 +2491,7 @@ found:
pmac_mb.model_id = PMAC_TYPE_COMET;
iounmap(mach_id_ptr);
}
-#endif /* CONFIG_POWER4 */
-#ifdef CONFIG_6xx
/* Set default value of powersave_nap on machines that support it.
* It appears that uninorth rev 3 has a problem with it, we don't
* enable it on those. In theory, the flush-on-lock property is
@@ -2522,10 +2520,11 @@ found:
* NAP mode
*/
powersave_lowspeed = 1;
-#endif /* CONFIG_6xx */
-#ifdef CONFIG_POWER4
+
+#else /* CONFIG_POWER4 */
powersave_nap = 1;
-#endif
+#endif /* CONFIG_POWER4 */
+
/* Check for "mobile" machine */
if (model && (strncmp(model, "PowerBook", 9) == 0
|| strncmp(model, "iBook", 5) == 0))
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 1955462..29c2946 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -621,10 +621,6 @@ static void __init pmac_init_early(void)
/* Probe motherboard chipset */
pmac_feature_init();
- /* We can NAP */
- powersave_nap = 1;
- printk(KERN_INFO "Using native/NAP idle loop\n");
-
/* Initialize debug stuff */
udbg_scc_init(!!strstr(cmd_line, "sccdbg"));
udbg_adb_init(!!strstr(cmd_line, "btextdbg"));
diff-tree 6275062d9d9f1709543667cb509755c2a1c9153a (from 0406e1c8a64b329377cae662cfcb1efccbde754d)
Author: Michael Ellerman <michael@ellerman.id.au>
Date: Fri Mar 10 15:01:08 2006 +1100
[PATCH] powerpc: Clarify wording for CRASH_DUMP Kconfig option
The wording of the CRASH_DUMP Kconfig option is not very clear. It gives you a
kernel that can be used _as_ the kdump kernel, not a kernel that can boot into
a kdump kernel.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index a834f9e..dfba817 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -580,7 +580,7 @@ config KEXEC
strongly in flux, so no good recommendation can be made.
config CRASH_DUMP
- bool "kernel crash dumps (EXPERIMENTAL)"
+ bool "Build a kdump crash kernel (EXPERIMENTAL)"
depends on PPC_MULTIPLATFORM && PPC64 && EXPERIMENTAL
help
Build a kernel suitable for use as a kdump capture kernel.
diff-tree 8ff99aa6d36c4e568c85197e6e1439c15b206504 (from 17c3dec53d68857a5c9e3d671b6a2b82225ec202)
Author: Olaf Hering <olh@suse.de>
Date: Sat Mar 4 13:15:40 2006 +0100
[PATCH] powerpc: correct cacheflush loop in zImage
Correct the loop for cacheflush. No idea where I copied the code from,
but the original does not work correct. Maybe the flush is not needed.
Signed-off-by: Olaf Hering <olh@suse.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S
index e0192c2..70e65b1 100644
--- a/arch/powerpc/boot/crt0.S
+++ b/arch/powerpc/boot/crt0.S
@@ -45,7 +45,8 @@ _zimage_start:
bdnz 2b
/* Do a cache flush for our text, in case OF didn't */
-3: lis r9,_start@h
+3: lis r9,_start@ha
+ addi r9,r9,_start@l
add r9,r0,r9
lis r8,_etext@ha
addi r8,r8,_etext@l
@@ -53,7 +54,7 @@ _zimage_start:
4: dcbf r0,r9
icbi r0,r9
addi r9,r9,0x20
- cmplwi 0,r9,8
+ cmplw cr0,r9,r8
blt 4b
sync
isync
diff-tree 17c3dec53d68857a5c9e3d671b6a2b82225ec202 (from cdc1e86904587171e70e16f7b77e8d2879f06c3c)
Author: Paul Mackerras <paulus@samba.org>
Date: Wed Mar 15 13:47:15 2006 +1100
powerpc: Fix problem with time going backwards
The recent changes to keep gettimeofday in sync with xtime had the side
effect that it was occasionally possible for the time reported by
gettimeofday to go back by a microsecond. There were two reasons:
(1) when we recalculated the offsets used by gettimeofday every 2^31
timebase ticks, we lost an accumulated fractional microsecond, and
(2) because the update is done some time after the notional start of
jiffy, if ntp is slowing the clock, it is possible to see time go backwards
when the timebase factor gets reduced.
This fixes it by (a) slowing the gettimeofday clock by about 1us in
2^31 timebase ticks (a factor of less than 1 in 3.7 million), and (b)
adjusting the timebase offsets in the rare case that the gettimeofday
result could possibly go backwards (i.e. when ntp is slowing the clock
and the timer interrupt is late). In this case the adjustment will
reduce to zero eventually because of (a).
Signed-off-by: Paul Mackerras <paulus@samba.org>
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 2a7ddc5..86f7e3d 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -283,9 +283,9 @@ static inline void update_gtod(u64 new_t
* the two values of tb_update_count match and are even then the
* tb_to_xs and stamp_xsec values are consistent. If not, then it
* loops back and reads them again until this criteria is met.
+ * We expect the caller to have done the first increment of
+ * vdso_data->tb_update_count already.
*/
- ++(vdso_data->tb_update_count);
- smp_wmb();
vdso_data->tb_orig_stamp = new_tb_stamp;
vdso_data->stamp_xsec = new_stamp_xsec;
vdso_data->tb_to_xs = new_tb_to_xs;
@@ -310,20 +310,15 @@ static __inline__ void timer_recalc_offs
unsigned long offset;
u64 new_stamp_xsec;
u64 tlen, t2x;
+ u64 tb, xsec_old, xsec_new;
+ struct gettimeofday_vars *varp;
if (__USE_RTC())
return;
tlen = current_tick_length();
offset = cur_tb - do_gtod.varp->tb_orig_stamp;
- if (tlen == last_tick_len && offset < 0x80000000u) {
- /* check that we're still in sync; if not, resync */
- struct timeval tv;
- __do_gettimeofday(&tv, cur_tb);
- if (tv.tv_sec <= xtime.tv_sec &&
- (tv.tv_sec < xtime.tv_sec ||
- tv.tv_usec * 1000 <= xtime.tv_nsec))
- return;
- }
+ if (tlen == last_tick_len && offset < 0x80000000u)
+ return;
if (tlen != last_tick_len) {
t2x = mulhdu(tlen << TICKLEN_SHIFT, ticklen_to_xs);
last_tick_len = tlen;
@@ -332,6 +327,21 @@ static __inline__ void timer_recalc_offs
new_stamp_xsec = (u64) xtime.tv_nsec * XSEC_PER_SEC;
do_div(new_stamp_xsec, 1000000000);
new_stamp_xsec += (u64) xtime.tv_sec * XSEC_PER_SEC;
+
+ ++vdso_data->tb_update_count;
+ smp_mb();
+
+ /*
+ * Make sure time doesn't go backwards for userspace gettimeofday.
+ */
+ tb = get_tb();
+ varp = do_gtod.varp;
+ xsec_old = mulhdu(tb - varp->tb_orig_stamp, varp->tb_to_xs)
+ + varp->stamp_xsec;
+ xsec_new = mulhdu(tb - cur_tb, t2x) + new_stamp_xsec;
+ if (xsec_new < xsec_old)
+ new_stamp_xsec += xsec_old - xsec_new;
+
update_gtod(cur_tb, new_stamp_xsec, t2x);
}
@@ -564,6 +574,10 @@ int do_settimeofday(struct timespec *tv)
}
#endif
+ /* Make userspace gettimeofday spin until we're done. */
+ ++vdso_data->tb_update_count;
+ smp_mb();
+
/*
* Subtract off the number of nanoseconds since the
* beginning of the last tick.
@@ -724,10 +738,16 @@ void __init time_init(void)
* It is computed as:
* ticklen_to_xs = 2^N / (tb_ticks_per_jiffy * 1e9)
* where N = 64 + 20 - TICKLEN_SCALE - TICKLEN_SHIFT
- * so as to give the result as a 0.64 fixed-point fraction.
+ * which turns out to be N = 51 - SHIFT_HZ.
+ * This gives the result as a 0.64 fixed-point fraction.
+ * That value is reduced by an offset amounting to 1 xsec per
+ * 2^31 timebase ticks to avoid problems with time going backwards
+ * by 1 xsec when we do timer_recalc_offset due to losing the
+ * fractional xsec. That offset is equal to ppc_tb_freq/2^51
+ * since there are 2^20 xsec in a second.
*/
- div128_by_32(1ULL << (64 + 20 - TICKLEN_SCALE - TICKLEN_SHIFT), 0,
- tb_ticks_per_jiffy, &res);
+ div128_by_32((1ULL << 51) - ppc_tb_freq, 0,
+ tb_ticks_per_jiffy << SHIFT_HZ, &res);
div128_by_32(res.result_high, res.result_low, NSEC_PER_SEC, &res);
ticklen_to_xs = res.result_low;
diff-tree 82dfdcae0d57c842e02f037758687eef42fb7af6 (from 3759fa9c55923f719ae944a3f8fbb029b36f759d)
Author: Paul Mackerras <paulus@samba.org>
Date: Tue Mar 14 11:35:37 2006 +1100
powerpc: Disallow lparcfg being a module
The lparcfg code needs several things which are pretty arcane internal
details and which we don't want to export, which means that lparcfg
doesn't work when built as a module. This makes it a bool instead of
a tristate in the Kconfig so that users can't try to build it as a
module.
Signed-off-by: Paul Mackerras <paulus@samba.org>
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index 4e5c8f8..a57032c 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -19,7 +19,7 @@ config SCANLOG
depends on RTAS_PROC && PPC_PSERIES
config LPARCFG
- tristate "LPAR Configuration Data"
+ bool "LPAR Configuration Data"
depends on PPC_PSERIES || PPC_ISERIES
help
Provide system capacity information via human readable
^ permalink raw reply related
* OF tree flattening.
From: David Updegraff @ 2006-03-15 15:10 UTC (permalink / raw)
To: linuxppc-embedded
Hi.
When OF device tree is flattened, the resultant struct has pointers into
the 'initial_boot_params' area.
I think that area needs 'reserving', since the text of various
properties are contained therein.
One could perhaps argue that the BootRom should do that, in the provided
OF-tree reserve maps... but if we're gonna keep pointers into the area,
seems we should protect it. Adding a
--------
lmb_reserve(__pa(initial_boot_params), initial_boot_params->totalsize);
------------
to early_init_devtree() worked for me.
There is of course then the problem alluded to in
kdump_move_device_tree(), that then this old DT should be un-reserved..
I don't have a suggestion for that problem; hope some of you do?
thnx.
-dbu.
^ permalink raw reply
* Re: please pull powerpc-merge.git
From: Linus Torvalds @ 2006-03-15 15:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17431.43915.712222.861194@cargo.ozlabs.ibm.com>
On Wed, 15 Mar 2006, Paul Mackerras wrote:
>
> Please do a pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
Umm. What _have_ you done to that tree?
error: object directory /home/paulus/kernel/linux-2.6/.git/objects does not exist; check .git/objects/info/alternates.
error: object directory /home/paulus/kernel/linux-2.6/.git/objects does not exist; check .git/objects/info/alternates.
Generating pack...
error: object directory /home/paulus/kernel/linux-2.6/.git/objects does not exist; check .git/objects/info/alternates.
error: Could not read a488edc914aa1d766a4e2c982b5ae03d5657ec1b
error: Could not read 3759fa9c55923f719ae944a3f8fbb029b36f759d
error: Could not read 153b1d3f0a5ec0760deef783e337e2164bfa1a68
fatal: bad tree object 153b1d3f0a5ec0760deef783e337e2164bfa1a68
Done counting 0 objects.
Total 0, written 0 (delta 0), reused 0 (delta 0)
Unpacking 0 objects
Hmm? Looks like you're _still_ using rsync to move git trees around, and
that is just not valid.
Please just do "git push" to push to master. Use the "-f" flag if you
want to force it because you did bad things. Don't use rsync. rsync on
git repos is evil and wrong when there are other alternatives, and leads
to crap like the above.
Linus
^ permalink raw reply
* Re: buildroot uClibc busybox and associated tool versions
From: White @ 2006-03-15 16:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <loom.20060314T023032-451@post.gmane.org>
Hi,
i'm using gcc 3.4.6
uclibc Release 0.9.28
busybox daily Snapshot.
With uclibc Snapshot i get an toolchain, but on the Target:
busybox init segfaults during init, at different points.
(but the snapshots uclibc build with gcc 4.1 and 4.2 :)
With gcc 4.x i get Compiler Errors, because of the weak aliases in
uclibc.
I test this last at 7.3
Would be nice to get Infos, which Combinations works...
Gcc 4.x would be nice to test.
Bye
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: Mark A. Greer @ 2006-03-15 17:49 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <E1FJJXV-0005Zf-7r@jdl.com>
On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
> So, like, the other day "Mark A. Greer" mumbled:
> > >
> > > And finally, as of, well right about now, until October or so, I'm
> > > expecting to be unavailable, off travelling and things. In the
> > > interim Jon Loeliger of Freescale has agreed to be dtc maintainer.
> >
> > Jon, any comments?
>
> For 9 months nothing. Dave abdicates his DTC maintainer role to me.
> The very next day, all hell breaks loose! Of _course_ I have comments!
>
> Uh, I've been bitten by the difference between the binary and asm
> form of these outputs before as well. Specifically where the reserve
> map included its own layout region as a reserve block. IIRC, though,
> it was a physical versus virtual address problem that, though understood,
> we didn't really resolve.
>
> I was eventually forced to move along, as that was not the battle I
> was looking for. Our U-Boot eventually went to a straight binary
> form that was directly munged into a C array definition and side-stepped
> that issue.
>
> As for the 64-bit-ness problem, I'm willing to accept donated 64-bit
> hardware that would allow me to test the problems you are seeing. :-)
>
> I mean, any patches that drift my way will be considered. :-)
Heh!
Okay, right now the kernel/prom.c code is choking on the dt from the asm
file so I'll figure that out and then start poking into the dtc code and
see what I can figure out.
Mark
^ permalink raw reply
* Re: RFC: [PATCH Upated]: snd-pmac-gpio interfaces for snd-powermac
From: Johannes Berg @ 2006-03-15 18:00 UTC (permalink / raw)
To: Ben Collins; +Cc: Linuxppc-dev
In-Reply-To: <1137630485.4425.2.camel@grayson>
[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]
Hi,
I have no idea if this is the latest version of this patch, but I
couldn't find any more recent one...
A few of comments inlined below.
> +static struct pmf_function *get_audio_pfunc(const char *name, const char *altname)
> +{
> + struct device_node *np;
> + struct pmf_function *pfunc = NULL;
> +
> + if (! (np = find_devices("i2s-a")))
> + return NULL;
Can we have this function take an explicit device parameter instead? As
it is now, it can only handle the i2s-a soundcard, while the latest
powermacs have two sound cards (codecs?): i2s-a and i2s-c.
> +int snd_pmac_get_gpio(const char *name, const char *altname,
> + snd_pmac_gpio_t *gp)
> +{
> + memset(gp, 0, sizeof(*gp));
> +
> + gp->name = name;
> + gp->altname = altname;
> +
> + /* Platform functions are prefered */
> + if ((gp->pfunc = get_audio_pfunc(name, altname)))
> + return 0;
> +
> + /* Else, fallback to direct gpio */
> + return get_audio_gpio(name, altname, gp);
Maybe there ought to be a way to disable the fallback when we're on
newer chips? I don't grok the sound architecture well enough yet to
tell.
> + /* XXX: pmf_unregister_irq_client doesn't use its
> + * first two arguments. We only need to send it
> + * the irq_client. WATCH FOR THIS CHANGING!
> + */
> + pmf_unregister_irq_client(NULL, NULL, &gp->irq_client);
Heh, so I'm looking at an old version of this patch. The current
pmf_unregister_irq_client makes this explicit and only takes one
parameter :)
> +int snd_pmac_request_irq(snd_pmac_gpio_t *gp, void (*handler)(void *),
> + void *data)
> +{
> + int ret = -ENODEV;
> + struct device_node *np;
> +
> + gp->irq_client.handler = handler;
> + gp->irq_client.data = data;
> + gp->irq_client.owner = NULL;
> +
> + if (gp->pfunc) {
> + gp->irq_client.owner = THIS_MODULE;
> +
> + if ((np = find_devices("i2s-a"))) {
same comment here as the first one -- the powermac needs to be able to
access i2s-c through this too, I think.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* mii_send error or at least strange
From: Antonio Di Bacco @ 2006-03-15 20:21 UTC (permalink / raw)
To: linuxppc-embedded
I had a look to mii_send code in u-boot/cpu/mpc8xx/fec.c . It supports both
FEC1 and FEC2 but anyway it seems to write always register mii-data of FEC1,
look here:
/* send command to phy using mii, wait for result */
static uint mii_send(uint mii_cmd)
{
uint mii_reply;
volatile fec_t *ep;
int cnt;
ep = &(((immap_t *)CFG_IMMR)->im_cpm.cp_fec);
ep->fec_mii_data = mii_cmd; /* command to phy */
/* wait for mii complete */
cnt = 0;
while (!(ep->fec_ievent & FEC_ENET_MII)) {
if (++cnt > 1000) {
printf("mii_send STUCK!\n");
break;
}
}
mii_reply = ep->fec_mii_data; /* result from phy */
ep->fec_ievent = FEC_ENET_MII; /* clear MII complete */
#if 0
printf("%s[%d] %s: sent=0x%8.8x, reply=0x%8.8x\n",
__FILE__,__LINE__,__FUNCTION__,mii_cmd,mii_reply);
#endif
return (mii_reply & 0xffff); /* data read from phy */
}
^ permalink raw reply
* spi support for 8xx in u-boot broken
From: Antonio Di Bacco @ 2006-03-15 20:32 UTC (permalink / raw)
To: linuxppc-embedded
I enabled the SPI COMMAND in u-boot for an 8xx and it doesn't compile. Chipset
in spi_xfer is not managed correctly!?!
I'm going to modify this code. Anyone is interested?
I know I shouldn't post on this mailing list for u-boot but where can I post?
Bye,
Antonio.
^ permalink raw reply
* Re: please pull powerpc-merge.git
From: Paul Mackerras @ 2006-03-15 20:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0603150748380.3618@g5.osdl.org>
Linus Torvalds writes:
> Umm. What _have_ you done to that tree?
Just stuffed up the objects/info/alternates file. It's fixed now.
> Please just do "git push" to push to master. Use the "-f" flag if you
> want to force it because you did bad things. Don't use rsync. rsync on
> git repos is evil and wrong when there are other alternatives, and leads
> to crap like the above.
OK, will do.
Paul.
^ permalink raw reply
* Re: mii_send error or at least strange
From: Wolfgang Denk @ 2006-03-15 21:02 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200603152121.21852.antonio.dibacco@aruba.it>
In message <200603152121.21852.antonio.dibacco@aruba.it> you wrote:
> I had a look to mii_send code in u-boot/cpu/mpc8xx/fec.c . It supports both
You are off topic here. Please post U-Boot related questions on the
U-Boot mailing list.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Es gibt immer genug fuer die Beduerfnisse aller, aber niemals genug
fuer die Gier einzelner. -- Ghandi
^ permalink raw reply
* Re: spi support for 8xx in u-boot broken
From: Wolfgang Denk @ 2006-03-15 21:03 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200603152132.05124.antonio.dibacco@aruba.it>
In message <200603152132.05124.antonio.dibacco@aruba.it> you wrote:
> I enabled the SPI COMMAND in u-boot for an 8xx and it doesn't compile. Chipset
Off topic again. Please post U-Boot related questions on the U-Boot
mailing list.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"We don't have to protect the environment -- the Second Coming is at
hand." - James Watt
^ permalink raw reply
* Re: buildroot uClibc busybox and associated tool versions
From: Harald Küthe @ 2006-03-15 21:36 UTC (permalink / raw)
To: linuxppc-embedded, white
>>With uclibc Snapshot i get an toolchain, but on the Target:
>>busybox init segfaults during init, at different points.Try a different
>>malloc "version" in the uClibc config.Harald
^ permalink raw reply
* Specify number of SPI received characters
From: Antonio Di Bacco @ 2006-03-15 22:11 UTC (permalink / raw)
To: linuxppc-embedded
Anyone knows, during an SPI transfer (8xx CPU as master and EEPROM as slave ),
how to specify how many characters I want to receive? When should I release
the chip select?
Thank you,
Antonio.
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: Mark A. Greer @ 2006-03-16 0:00 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <E1FJJXV-0005Zf-7r@jdl.com>
On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
>
> For 9 months nothing. Dave abdicates his DTC maintainer role to me.
Jon,
I can't find dtc under ~dgibson on ozlabs anymore. Do you have it
somewhere now?
Mark
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: David Gibson @ 2006-03-16 0:49 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20060316000059.GA29326@mag.az.mvista.com>
On Wed, Mar 15, 2006 at 05:00:59PM -0700, Mark A. Greer wrote:
> On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
> >
> > For 9 months nothing. Dave abdicates his DTC maintainer role to me.
>
> Jon,
>
> I can't find dtc under ~dgibson on ozlabs anymore. Do you have it
> somewhere now?
Ah, bother. I did arrange for one of the old addresses of the tree to
keep working, but forgot that it wasn't the one which had been widely
announced. Just a minute, I'll send an announcement to the lists.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: Stephen Rothwell @ 2006-03-16 0:56 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Linuxppc-dev, jdl, david
In-Reply-To: <20060316000059.GA29326@mag.az.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]
On Wed, 15 Mar 2006 17:00:59 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
>
> I can't find dtc under ~dgibson on ozlabs anymore. Do you have it
> somewhere now?
http://dtc.ozlabs.org/ has a link to a tarball, or
git://ozlabs.org/~dgibson/git/dtc.git
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* dtc git tree has moved (and maintainership announcement)
From: David Gibson @ 2006-03-16 0:58 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
For the next six months or so, I will be available intermittently at
best for dtc work. For this reason, Jon Loeliger of Freescale has
agreed to take over dtc maintainership for the interim.
As part of the logistics of this handover, the location of the dtc git
tree has changed. It is now available *only* via git daemon (not http
or rsync, sorry), the address is:
git://ozlabs.org/srv/projects/dtc/dtc.git
There is also now a web page for dtc, although at present there's
basically no information there, at:
http://dtc.ozlabs.org/
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: Mark A. Greer @ 2006-03-16 1:59 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20060316004948.GA1512@localhost.localdomain>
On Thu, Mar 16, 2006 at 11:49:48AM +1100, David Gibson wrote:
> On Wed, Mar 15, 2006 at 05:00:59PM -0700, Mark A. Greer wrote:
> > On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
> > >
> > > For 9 months nothing. Dave abdicates his DTC maintainer role to me.
> >
> > Jon,
> >
> > I can't find dtc under ~dgibson on ozlabs anymore. Do you have it
> > somewhere now?
>
> Ah, bother. I did arrange for one of the old addresses of the tree to
> keep working, but forgot that it wasn't the one which had been widely
> announced. Just a minute, I'll send an announcement to the lists.
Okay, thanks guys.
Here is a patch that fixes a problem I'm having with asm output. My
host system is a x86 box so its 32-bit, little endian.
Disclaimer: Everything below is AFAICT.
The problem is that asm_emit_cell() was swapping its asm output when
it shouldn't be (because the assembler will do the necessary swapping).
The cell values (asm_emit_cell()) are different from the data values
(asm_emit_data()) because the cell values are generated within the
program and don't get swapped like the data values read from the dts file.
They should be left as they are so that the assembler will swap them,
if necessary. For example, when the property length field was 4,
the asm output contained ".long 0x4000000" and sent the kernel prom.c
dt parsing code into the weeds.
The dtb output is correct.
Did any of that make sense?
/me knows he's rambling...
Anyway, here is a simple patch the fixes it for me (i.e., the
cross-assembled asm output matches the dtb).
Mark
---
diff -Nurp dtc/flattree.c dtc_new/flattree.c
--- dtc/flattree.c 2006-02-24 10:57:56.000000000 -0700
+++ dtc_new/flattree.c 2006-03-15 18:02:07.000000000 -0700
@@ -121,7 +121,7 @@ static void asm_emit_cell(void *e, cell_
{
FILE *f = e;
- fprintf(f, "\t.long\t0x%x\n", be32_to_cpu(val));
+ fprintf(f, "\t.long\t0x%x\n", val);
}
static void asm_emit_string(void *e, char *str, int len)
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: David Gibson @ 2006-03-16 2:05 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20060316015924.GA32493@mag.az.mvista.com>
On Wed, Mar 15, 2006 at 06:59:24PM -0700, Mark A. Greer wrote:
> On Thu, Mar 16, 2006 at 11:49:48AM +1100, David Gibson wrote:
> > On Wed, Mar 15, 2006 at 05:00:59PM -0700, Mark A. Greer wrote:
> > > On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
> > > >
> > > > For 9 months nothing. Dave abdicates his DTC maintainer role to me.
> > >
> > > Jon,
> > >
> > > I can't find dtc under ~dgibson on ozlabs anymore. Do you have it
> > > somewhere now?
> >
> > Ah, bother. I did arrange for one of the old addresses of the tree to
> > keep working, but forgot that it wasn't the one which had been widely
> > announced. Just a minute, I'll send an announcement to the lists.
>
> Okay, thanks guys.
>
> Here is a patch that fixes a problem I'm having with asm output. My
> host system is a x86 box so its 32-bit, little endian.
>
> Disclaimer: Everything below is AFAICT.
>
> The problem is that asm_emit_cell() was swapping its asm output when
> it shouldn't be (because the assembler will do the necessary swapping).
> The cell values (asm_emit_cell()) are different from the data values
> (asm_emit_data()) because the cell values are generated within the
> program and don't get swapped like the data values read from the dts file.
> They should be left as they are so that the assembler will swap them,
> if necessary. For example, when the property length field was 4,
> the asm output contained ".long 0x4000000" and sent the kernel prom.c
> dt parsing code into the weeds.
>
> The dtb output is correct.
>
> Did any of that make sense?
Ah, yes, that be32_to_cpu() is, indeed, complete crap.
> /me knows he's rambling...
>
> Anyway, here is a simple patch the fixes it for me (i.e., the
> cross-assembled asm output matches the dtb).
>
> Mark
> ---
>
> diff -Nurp dtc/flattree.c dtc_new/flattree.c
> --- dtc/flattree.c 2006-02-24 10:57:56.000000000 -0700
> +++ dtc_new/flattree.c 2006-03-15 18:02:07.000000000 -0700
> @@ -121,7 +121,7 @@ static void asm_emit_cell(void *e, cell_
> {
> FILE *f = e;
>
> - fprintf(f, "\t.long\t0x%x\n", be32_to_cpu(val));
> + fprintf(f, "\t.long\t0x%x\n", val);
> }
>
> static void asm_emit_string(void *e, char *str, int len)
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* kernel support for the MPC5200b
From: Henry Quinn @ 2006-03-16 6:08 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 535 bytes --]
Hello all
I want to run the Linux kernel on a device based on the Freescale MPC5200b,
based on the MPC603e series G2_LE core.
What I don't understand is whether support for this processor is built into
the kernel or not, can one take a stock kernel from
www.kernel.org <http://www.kernel.org/> and compile it to run on this
processor or are there a series of patches that one needs to apply before
the
kernel will run on this processor?
I'd be really grateful if someone can clear this issue up for me.
Regards
Henry
[-- Attachment #2: Type: text/html, Size: 2921 bytes --]
^ permalink raw reply
* SCC4 MPC8247 BD's
From: somshekar chandrashekar kadam @ 2006-03-16 7:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
Hi ,
I am using MPC8247 on a custom board , with FCC2 and SCC4 for ethernet and scc2 for serial console ,
if increase buffer descirptor size from 4 to 8 ,, kernel panics after some pings ,, increasing number of buffer diesciptor should not ne a problem , as far as i know , correct me if i am wrong . or there something else i should look into. please guide
thanks A Lot In Advance
Rgerds
Neelu
[-- Attachment #2: Type: text/html, Size: 799 bytes --]
^ 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