* Re: [PATCH v4] [POWERPC] MPC8360E-RDK: device tree, board file and defconfig
From: Kumar Gala @ 2008-02-11 15:32 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080211130132.GA6445@localhost.localdomain>
On Feb 11, 2008, at 7:01 AM, Anton Vorontsov wrote:
> On Fri, Feb 01, 2008 at 04:56:40PM +0300, Anton Vorontsov wrote:
>> This is new board made by Freescale Semiconductor Inc. and
>> Logic Product Development.
>>
>> Currently supported:
>> 1. UEC{1,2,7,4};
>> 2. I2C;
>> 3. SPI;
>> 4. NS16550 serial;
>> 5. PCI and miniPCI;
>> 6. Intel NOR StrataFlash X16 64Mbit PC28F640P30T85;
>> 7. Graphics controller, Fujitsu MB86277.
>>
>> Not supported so far:
>> 1. StMICRO NAND512W3A2BN6E, 512 Mbit (supported with FSL UPM
>> patches);
>> 2. QE Serial UCCs (tested to not work with ucc_uart driver, reason
>> unknown, yet);
>> 3. ADC AD7843 (tested to work, but support via device tree depends on
>> major SPI rework, GPIO API, etc);
>> 4. FHCI USB (will send RFC patches soon).
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>>
>> Hello Kumar,
>>
>> It would be great if we can get this into the 2.6.25.
>
> Is there any chance this will hit 2.6.25?..
Not really. It seemed like there were a lot of other patches this
really depend on getting so I was waiting to see how that fell out.
As Linus, just released 2.6.25-rc1 lets queue this up for 2.6.26.
- k
^ permalink raw reply
* [PATCH] [POWERPC] Remove generated files on make clean
From: Kumar Gala @ 2008-02-11 15:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
vmlinux.lds and dtc-parser.tab.h get created but never cleaned up.
---
arch/powerpc/boot/Makefile | 2 ++
arch/powerpc/kernel/Makefile | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 49797a4..63d07cc 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -147,6 +147,8 @@ HOSTCFLAGS += -I$(src)/dtc-src/ -I$(src)/libfdt/
targets += dtc-src/dtc-parser.tab.c
targets += dtc-src/dtc-lexer.lex.c
+clean-files += dtc-src/dtc-parser.tab.h
+
ifdef DTC_GENPARSER
BISON = bison
FLEX = flex
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 0662ae4..c1baf9d 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -104,3 +104,5 @@ quiet_cmd_systbl_chk = CALL $<
PHONY += systbl_chk
systbl_chk: $(src)/systbl_chk.sh $(obj)/systbl_chk.i
$(call cmd,systbl_chk)
+
+clean-files := vmlinux.lds
--
1.5.3.8
^ permalink raw reply related
* Re: [PATCH 1/5] Tsi108_eth: add missing linking to driver data
From: Jeff Garzik @ 2008-02-11 15:28 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: netdev, linuxppc-dev
In-Reply-To: <1B5F013528140F45B5C671039279CA5702A9609F@NANUK.pc.tundra.com>
Alexandre Bounine wrote:
> Bug fix for tsi108_eth network driver.
> This patch adds missing linking to driver data.
>
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> ---
>
> diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
> linux-2.6.24-fix/drivers/net/tsi108_eth.c
> --- linux-2.6.24/drivers/net/tsi108_eth.c 2008-01-24
> 17:58:37.000000000 -0500
> +++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
> 14:30:04.000000000 -0500
> @@ -1629,6 +1629,7 @@ tsi108_init_one(struct platform_device *
> goto register_fail;
> }
>
> + platform_set_drvdata(pdev, dev);
> printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n",
> dev->name, print_mac(mac, dev->dev_addr));
> #ifdef DEBUG
ACK, but your patches are unusable because they are word-wrapped
^ permalink raw reply
* Re: [PATCH] Fix for Freescale ppc cores: major revision detection
From: Kumar Gala @ 2008-02-11 15:01 UTC (permalink / raw)
To: Martin Langer; +Cc: linuxppc-dev
In-Reply-To: <20080209174748.GA3245@tuba>
On Feb 9, 2008, at 11:47 AM, Martin Langer wrote:
> Ppc cores by Freescale are using the configuration field instead of
> the
> major revision field for their major revision number. Those field
> definitions come from include/asm-powerpc/reg.h.
>
> Look at the pdf below and you will see that PVR_MAJ() does a wrong
> shift
> for ppc cores by Freescale. This patch fixes it.
>
> http://www.freescale.com/files/archives/doc/support_info/PPCPVR.pdf
This doc doesn't encompass the e500/book-e cores that don't follow the
same pattern.
The code should probably be something like:
#ifdef CONFIG_FSL_BOOKE
maj = PVR_MAJ(pvr);
#else
maj = (pvr >> 8) & 0xff;
#endif
>
>
>
> Signed-Off-By: Martin Langer <martin-langer@gmx.de>
>
>
> --- arch/powerpc/kernel/setup-common.c.ORIGINAL 2008-02-08
> 22:22:56.000000000 +0100
> +++ arch/powerpc/kernel/setup-common.c 2008-02-09 18:18:36.000000000
> +0100
> @@ -241,7 +241,7 @@
> /* If we are a Freescale core do a simple check so
> * we dont have to keep adding cases in the future */
> if (PVR_VER(pvr) & 0x8000) {
> - maj = PVR_MAJ(pvr);
> + maj = (pvr >> 8) & 0xF;
> min = PVR_MIN(pvr);
> } else {
> switch (PVR_VER(pvr)) {
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH v4] [POWERPC] MPC8360E-RDK: device tree, board file and defconfig
From: Anton Vorontsov @ 2008-02-11 13:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <20080201135640.GA10966@localhost.localdomain>
On Fri, Feb 01, 2008 at 04:56:40PM +0300, Anton Vorontsov wrote:
> This is new board made by Freescale Semiconductor Inc. and
> Logic Product Development.
>
> Currently supported:
> 1. UEC{1,2,7,4};
> 2. I2C;
> 3. SPI;
> 4. NS16550 serial;
> 5. PCI and miniPCI;
> 6. Intel NOR StrataFlash X16 64Mbit PC28F640P30T85;
> 7. Graphics controller, Fujitsu MB86277.
>
> Not supported so far:
> 1. StMICRO NAND512W3A2BN6E, 512 Mbit (supported with FSL UPM patches);
> 2. QE Serial UCCs (tested to not work with ucc_uart driver, reason
> unknown, yet);
> 3. ADC AD7843 (tested to work, but support via device tree depends on
> major SPI rework, GPIO API, etc);
> 4. FHCI USB (will send RFC patches soon).
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>
> Hello Kumar,
>
> It would be great if we can get this into the 2.6.25.
Is there any chance this will hit 2.6.25?..
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Ebony development board
From: Josh Boyer @ 2008-02-11 12:53 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200802110720.12842.sr@denx.de>
On Mon, 11 Feb 2008 07:20:12 +0100
Stefan Roese <sr@denx.de> wrote:
> Hi Zoltan,
>
> On Saturday 09 February 2008, Zoltan HERPAI wrote:
> > I've recently got an Ebony board (440GP) with the original bootloader
> > (440GP 1.18 ROM Monitor) which I would like to replace with U-boot. Is
> > there a way to boot an U-boot image via TFTP to replace the bootloader,
> > or is it possible only with using a JTAG? I've googled through the
> > mailing list, but most of the related hits are dated back in 2004-2005,
> > they say no, one have to use JTAG, but some time passed since then, and
> > I would like to know if there is a way for this.
>
> Does the original ROM monitor support writing to onboard FLASH? If yes, it
> should be possible.
It doesn't. Theoretically, you can boot Linux and use MTD on the flash
to load U-Boot. I wouldn't recommend it without a JTAG debugger around
to fix things in case they get screwed up.
josh
^ permalink raw reply
* External interrupts with UIO framework on mpc8313e
From: Frank Prepelica @ 2008-02-11 11:24 UTC (permalink / raw)
To: linuxppc-embedded
Hi everyone!
I'm trying to receive external interrupts on the mpc8313erdb board.
I'm also using the UIO framework to register the interrupt handler.=20
It works for me when I register the interrupt handler for external =
interrupt IRQ4 (irq =3D 20)
But when I'm trying the register the handler for IRQ0(48)-IRQ3(17-19) it =
doesn't.=20
I'm using following simple code:
---snip---
static irqreturn_t intHandler(int irq, struct uio_info *dev_info)
{
printk("name: %s\n", dev_info->name);
return IRQ_HANDLED
}
static struct uio_info myinfo =3D {
.name =3D "IRQ4 Kernel Driver",
.version =3D "1.0.0",
.irq =3D 20,
.irq_flags =3D IRQF_SHARED | IRQF_DISABLED,
.handler =3D intHandler,
};
static int uio_probe(struct device *dev)
{
if(uio_register_device(dev,&myinfo))
{
return -ENODEV;
}
else
{
return 0;
}
}
---snip---
After booting the kernel, the driver (for IRQ4) appears correct in =
/proc/interrups and can be triggered.
I guess, this should also work for IRQ0-IRQ3 but it won't. IRQ0 cannot =
registered to 48 at all and the
other ones appear in /proc/interruts but they cannot be triggered (BUT =
shared with serial or i2c).=20
I also checked the value of the SEMSR register and see that IRQ4 is set =
correctly.
Okay, I thought when I set the SEMSR register manually e.g. IRQ2 to "1" =
and trigger the correct interrupt signal I could see in /proc/stat a =
counting value. Nothing happened. But the BAD counter in =
/proc/interrupts is rising.=20
Furthermore there's a mapping issue between the interrupt id number from =
the board manual
(page 8-10) and the output of /proc/interrupts. The kernel registers the =
i2c devices to=20
ID 16 and 17 although the manual says they are mapped to 14 and 15.
Any hint is appreciate!=20
Best regards
Frank Prepelica
Software Design Engineer
Ubidyne GmbH
Lise-Meitner-Str.-14
89081 Ulm - Germany
Phone:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +49 731 88 00 71 58
Fax:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +49 731 88 00 71 99
Email:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
frank.prepelica@ubidyne.com
Homepage:=A0=A0=A0=A0=A0=A0 www.ubidyne.com
=A0
Registered office: Ulm
District court of Ulm: HRB 5295
Managing Directors:
Dipl. Ing. Ken Hawk
Dipl. Ing. Beat M=FCller
Dr. Clemens Rheinfelder
^ permalink raw reply
* Re: APU FPU in Virtex ppc405
From: A. Nolson @ 2008-02-11 11:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40802081132h22b91464xd150e0671ca4fc34@mail.gmail.com>
I have been checking and it seems that the APU FPU patches will give
some headaches now, so I will probably wait until they merge them with
the official GCC release. In any case, it seems that the FPU restricts
the PowerPC and bus frequencies to a max of 200/100.
Anyway, thanks for the info. I will try to keep track of this in case of
an update.
Grant Likely wrote:
> On Feb 8, 2008 11:51 AM, A. Nolson <alohanono@gmail.com> wrote:
>
>> Hi,
>>
>> I have just heard that Xilinx has freed the FPU module for the PPC
>> architecture in EDK9.2i. WIll I be able to make it work with my
>> Secretlab Linux 2.6.24rc3? Will the eldk toolchain for PPC_4xxfp work?
>> Will it be just a matter of integrating it with the XPS BSP?I make an
>> extensive use of floating point in my applications and this will be
>> really useful.
>>
>
> It's been 2 years since I last played with the FPU core. At the time
> it wasn't a complete FPU so the eldk 4xxfp toolchain would not work.
> I had to build my own. I don't know if the new core is a complete
> implementation.
>
> Cheers,
> g.
>
>
>
^ permalink raw reply
* Re: [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-11 10:47 UTC (permalink / raw)
To: Dave Hansen
Cc: Jan-Bernd Themann, Greg KH, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch, netdev
In-Reply-To: <1202724743.8276.2.camel@nimitz.home.sr71.net>
On Monday 11 February 2008 11:12, Dave Hansen wrote:
> On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
> > are you the right person to address this patch to?
>
> You might want to check the top of the file. ;)
>
> > --- a/drivers/base/memory.c
> > +++ b/drivers/base/memory.c
> > @@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
> > {
> > return blocking_notifier_chain_register(&memory_chain, nb);
> > }
> > +EXPORT_SYMBOL(register_memory_notifier);
> >
> > void unregister_memory_notifier(struct notifier_block *nb)
> > {
> > blocking_notifier_chain_unregister(&memory_chain, nb);
> > }
> > +EXPORT_SYMBOL(unregister_memory_notifier);
>
> Is there a particular reason these can't be GPL?
>
I don't object to make them GPL. Greg, what do you think?
Regards,
Jan-Bernd
^ permalink raw reply
* Re: [PATCH] Fix compilation of powerpc asm-offsets.c with old gcc
From: Geert Uytterhoeven @ 2008-02-11 10:36 UTC (permalink / raw)
To: Simon Holm Thøgersen
Cc: linux-kernel, linuxppc-dev, Paul Jackson, paulus, akpm,
Linus Torvalds, tglx
In-Reply-To: <1202495464.6722.13.camel@odie.local>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 1496 bytes --]
On Fri, 8 Feb 2008, Simon Holm Thøgersen wrote:
> fre, 08 02 2008 kl. 12:06 -0600, skrev Paul Jackson:
> > Linus wrote:
> > > Please, when mentioning hex numbers, also do the one-liner shortlog.
> > > ...
> > > without _requiring_ people to be git users to get the gist of the
> > > matter, ok?
> >
> >
> > Thanks for sticking up for us git-challenged contributors.
> >
> > Can anyone point me at instructions providing the shortest
> > path for getting from one of those git hex numbers to the
> > log or change it represents, for non-git users?
>
> Use gitweb [1], Linus' tree is here [2]. Just search for the hex.
>
> [1] http://git.kernel.org/
> [2]
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
As the IDs are supposed to be unique, it doesn't matter where you look it up,
as long as the tree has that commit ;-)
BTW, time for Google to start handling git IDs?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Dave Hansen @ 2008-02-11 10:12 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Jan-Bernd Themann, Greg KH, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch, netdev
In-Reply-To: <200802111049.05478.ossthema@de.ibm.com>
On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
> are you the right person to address this patch to?
You might want to check the top of the file. ;)
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
> {
> return blocking_notifier_chain_register(&memory_chain, nb);
> }
> +EXPORT_SYMBOL(register_memory_notifier);
>
> void unregister_memory_notifier(struct notifier_block *nb)
> {
> blocking_notifier_chain_unregister(&memory_chain, nb);
> }
> +EXPORT_SYMBOL(unregister_memory_notifier);
Is there a particular reason these can't be GPL?
-- Dave
^ permalink raw reply
* [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-11 9:49 UTC (permalink / raw)
To: Greg KH
Cc: Jan-Bernd Themann, netdev, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch
Drivers like eHEA need memory notifiers in order to
update their internal DMA memory map when memory is added
to or removed from the system.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
Hi Greg,
are you the right person to address this patch to?
Regards,
Jan-Bernd
drivers/base/memory.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 7ae413f..1e1bd4c 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
{
return blocking_notifier_chain_register(&memory_chain, nb);
}
+EXPORT_SYMBOL(register_memory_notifier);
void unregister_memory_notifier(struct notifier_block *nb)
{
blocking_notifier_chain_unregister(&memory_chain, nb);
}
+EXPORT_SYMBOL(unregister_memory_notifier);
/*
* register_memory - Setup a sysfs device for a memory block
--
1.5.2
^ permalink raw reply related
* [PATCH] ppc: Fix arch/ppc compilation - Add missing typedef pgtable_t
From: Stefan Roese @ 2008-02-11 9:41 UTC (permalink / raw)
To: linuxppc-dev
Commit 2f569afd9ced9ebec9a6eb3dbf6f83429be0a7b4 ("CONFIG_HIGHPTE vs.
sub-page page tables.") breaks compilation of arch/ppc since it
introduces the pgtable_t type which was not added to arch/ppc.
This patch now adds the missing typedef.
Signed-off-by: Stefan Roese <sr@denx.de>
---
include/asm-ppc/page.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/asm-ppc/page.h b/include/asm-ppc/page.h
index ad4c5a1..37e4756 100644
--- a/include/asm-ppc/page.h
+++ b/include/asm-ppc/page.h
@@ -125,6 +125,8 @@ extern __inline__ int get_order(unsigned long size)
return 32 - lz;
}
+typedef struct page *pgtable_t;
+
#endif /* __ASSEMBLY__ */
#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC | \
--
1.5.4.1
^ permalink raw reply related
* Re: Where is fcc_enet.c
From: Vitaly Bordug @ 2008-02-11 9:37 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1AA74@xmb-sjc-212.amer.cisco.com>
On Sun, 10 Feb 2008 15:08:46 -0800
Bizhan Gholikhamseh (bgholikh) wrote:
> Hi,
> I am porting to Linux 2.6.24 from linux 2.6.11 on mpc85xx cds
> platform, I am not able to locate fcc_enet.c file under
> linux 2.6.24 source tree, any idea????
try drivers/net/fs_enet
at least CPM2 FCC is handled in there.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [RFC][POWERPC] bootwrapper: Add a firmware-independent
From: Milton Miller @ 2008-02-11 7:07 UTC (permalink / raw)
To: david, grant.likely; +Cc: linuxppc-dev
On Friday, Feb 8, 2008 David Gibson wrote:
> On Fri, Feb 01, 2008 at 11:55:42PM -0700, Grant Likely wrote:
> From: Grant Likely <grant.likely at secretlab.ca>
[snip]
>> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
>> + unsigned long r6, unsigned long r7)
>> +{
>> +const u32 *na, *ns, *reg, *timebase;
>> +u64 memsize64;
>> +int node, size, i;
>> +
>> +/* Allocate initial heap for probing the tree */
>> +simple_alloc_init(initial_heap, sizeof(initial_heap), 32, 64);
>> +
>> +/* Make sure FDT blob is sane */
>> +if (fdt_check_header(_dtb_start) != 0)
>> +fatal("Invalid device tree blob\n");
>
> I think most of these fatal()s are pretty pointless. This is
> platform_init(), so the console won't even have been initialized to
> actually print any of the messages. Precisely because this is
> simpleboot, in which every bit of information the wrapper has comes
> from teh device tree, if the provided blob is so bad as to fail these
> basic tests, we're totally stuffed anyway. It'll take a hardware
> debugger to track down, and I don't think the fatal()s will actually
> help much at that point.
My experience is the opposite: fatal is very useful even with a hardware debugger. Since the code knows what is wrong, one only has to get the printf assembly buffer out of the map and dump it out. Also, one can find which function called fatal from the nia and/or lr. Much much easier than figuring out what happend when the prcessor jumps into the middle of code because it took an exception.
Also, one can patch in a debug output routine, possibly even in the __zlib_init. Having the assertions is good.
That said, we should be conservative in calling something an error.
milton
^ permalink raw reply
* Re: [PATCH] PPC440EP Interrupt Triggering and Level Settings
From: Stefan Roese @ 2008-02-11 6:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Wolfgang Ocker
In-Reply-To: <1202671442.3384.15.camel@galileo.recco.de>
On Sunday 10 February 2008, Wolfgang Ocker wrote:
> From: Wolfgang Ocker <weo@reccoware.de>
>
> Corrected IRQ triggering and level settings according to latest revision
> of the 440EP User Manual (rev 1.24 nov 16, 2007).
>
> The incorrect settings might cause a failure of the network if both
> onchip ethernet ports are under heavy load.
>
> Signed-off-by: Wolfgang Ocker <weo@reccoware.de>
Thanks, looks good.
Acked-by: Stefan Roese <sr@denx.de>
Best regards,
Stefan
^ permalink raw reply
* Re: Ebony development board
From: Stefan Roese @ 2008-02-11 6:20 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <47AE00FE.1000704@uid0.hu>
Hi Zoltan,
On Saturday 09 February 2008, Zoltan HERPAI wrote:
> I've recently got an Ebony board (440GP) with the original bootloader
> (440GP 1.18 ROM Monitor) which I would like to replace with U-boot. Is
> there a way to boot an U-boot image via TFTP to replace the bootloader,
> or is it possible only with using a JTAG? I've googled through the
> mailing list, but most of the related hits are dated back in 2004-2005,
> they say no, one have to use JTAG, but some time passed since then, and
> I would like to know if there is a way for this.
Does the original ROM monitor support writing to onboard FLASH? If yes, it
should be possible.
Best regards,
Stefan
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Sean MacLennan @ 2008-02-11 3:49 UTC (permalink / raw)
To: LinuxPPC-dev
In-Reply-To: <20080211031110.GD11572@localhost.localdomain>
David Gibson wrote:
> On Sun, Feb 10, 2008 at 09:40:19PM -0500, Sean MacLennan wrote:
>
>> David Gibson wrote:
>>
>>> This doesn't seem right. warp_fixup_one_nor() changes only the
>>> partition's offset, so you're not changing the size of any
>>> partitions. If you're not going to actually use any of the extra
>>> flash space with 64M, I can't see why you'd bother moving around the
>>> partitions you have.
>>>
>>>
>> u-boot must be at the bottom of the flash. Also, for the 64M NOR flash
>> you can put everything in the NOR flash, I just don't show the
>> partitions. Booting from NOR is *much* faster than booting from
>> NAND.
>>
>
> Sorry, still not really following what's going on. Without worrying
> about the dts formatting or fixup code, can you summarise what the two
> flash maps look like?
>
>
I guess what is confusing is that I am actually working with 3 flash
maps right now, although there will only be one map in the final version.
Map1:
NOR:
Kernel @ 0
Ramdisk
User
FPGA
Env
U-boot @ 63.5M
Map 2:
NOR:
FPGA
Env
U-boot @ 63.5M
NAND:
Kernel @ 0
Ramdisk
User
Map 3:
Same as Map 2 only 4M NOR rather than 64M, so u-boot @ 3.5M.
The u-boot, env, and FPGA are anchored at the bottom of the flash.
Kernel is anchored at the top. Everything else goes in the middle.
The FPGA partition contains the FPGA image. The user partition contains
a persistent JFFS2 file system. I don't use the user partition, so it
doesn't show up in the map I sent.
So map 1 was used until we got the NAND working. Map 2 is an interim
solution until we get the 4M flash. Map 3 is the final version.
Cheers,
Sean
^ permalink raw reply
* Re: [libfdt] RFC: Node iterators (v2)
From: David Gibson @ 2008-02-11 3:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <47AB956D.4090805@freescale.com>
On Thu, Feb 07, 2008 at 05:34:05PM -0600, Scott Wood wrote:
> David Gibson wrote:
> > And here's a revised version. This now also handles recursive
> > iteration and iteration across nodes without respect to depth. I've
> > removed the for_each() macros for the time being, because they were
> > making my brain hurt, but I'm still contemplating bringing them back.
> > Several libfdt functions are now implemented using the new iterator,
> > so this ends up as a code-size-reducing patch.
> >
> > I'm pretty happy with the basic outline of this now, although the
> > names and details might want a bit of polish still.
>
> Can we get this merged?
Well, I'm back from holidays now, so I will resume looking at this. I
hope we can merge it soon, yes.
> > +int _fdt_next_node(const void *fdt, int offset, int *depth)
> > +{
>
> This is a public function; why the underscore?
Well, because I still think of it as a low-level "only use if you
really know what you're doing" type function (which is what _ is
supposed to indicate; truly private functions don't need the fdt_
prefix at all).
--
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: Could the DTS experts look at this?
From: David Gibson @ 2008-02-11 3:11 UTC (permalink / raw)
To: Sean MacLennan; +Cc: LinuxPPC-dev
In-Reply-To: <47AFB593.30805@pikatech.com>
On Sun, Feb 10, 2008 at 09:40:19PM -0500, Sean MacLennan wrote:
> David Gibson wrote:
> > This doesn't seem right. warp_fixup_one_nor() changes only the
> > partition's offset, so you're not changing the size of any
> > partitions. If you're not going to actually use any of the extra
> > flash space with 64M, I can't see why you'd bother moving around the
> > partitions you have.
> >
> u-boot must be at the bottom of the flash. Also, for the 64M NOR flash
> you can put everything in the NOR flash, I just don't show the
> partitions. Booting from NOR is *much* faster than booting from
> NAND.
Sorry, still not really following what's going on. Without worrying
about the dts formatting or fixup code, can you summarise what the two
flash maps look like?
--
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: Could the DTS experts look at this?
From: Sean MacLennan @ 2008-02-11 2:40 UTC (permalink / raw)
To: LinuxPPC-dev
In-Reply-To: <20080211001451.GA11572@localhost.localdomain>
David Gibson wrote:
> This doesn't seem right. warp_fixup_one_nor() changes only the
> partition's offset, so you're not changing the size of any
> partitions. If you're not going to actually use any of the extra
> flash space with 64M, I can't see why you'd bother moving around the
> partitions you have.
>
u-boot must be at the bottom of the flash. Also, for the 64M NOR flash
you can put everything in the NOR flash, I just don't show the
partitions. Booting from NOR is *much* faster than booting from NAND.
>
> In practice, probably not. We already do a similar fixup on Ebony for
> different flash layouts that won't leave the unit names correct. We
> really should get this right - and the fdt_set_name() function that's
> now in libfdt should make that possible, it just needs some wiring up
> to use in the bootwrapper. That can come later, though, for now I
> think applying your fixups without correcting the unit addresses is
> adequate.
>
>
Ok.
>> If anybody has suggestions on better ways to do this, fire away.
>>
>> And looking at this code, and other board ports, why is sysclk a local
>> variable and all the other numbers hardcoded in the args? I left it the
>> same way as the others but it does look a bit strange.
>>
>
> I think this also came from Ebony. IIRC, the sysclk isn't strictly
> speaking fixed, although it almost always has initialized value. The
> point of the local variable was that I planned to replace the static
> initialization with some sort of probing once I figured out the
> details.
>
That makes sense. I don't think you can probe for the sysclk on the
taco, so I may just put it as a constant to the function.
Cheers,
Sean
^ permalink raw reply
* [PATCH] [POWERPC] Wire up new timerfd syscalls
From: Stephen Rothwell @ 2008-02-11 0:38 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, LKML
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/asm-powerpc/systbl.h | 4 +++-
include/asm-powerpc/unistd.h | 6 ++++--
2 files changed, 7 insertions(+), 3 deletions(-)
Kernel built for ppc64_defconfig, pseries_defconfig, iseries_defconfig,
cell_defconfig and pmac32_defconfig. The latter failed because
check_media_bay is still undefined (i.e. for unrelated reasons).
This has been tested on a pseries_defconfig kernel using the posted test
program built for 64 and 32 bit.
diff --git a/include/asm-powerpc/systbl.h b/include/asm-powerpc/systbl.h
index e996521..ae7085c 100644
--- a/include/asm-powerpc/systbl.h
+++ b/include/asm-powerpc/systbl.h
@@ -309,8 +309,10 @@ SYSCALL_SPU(getcpu)
COMPAT_SYS(epoll_pwait)
COMPAT_SYS_SPU(utimensat)
COMPAT_SYS_SPU(signalfd)
-SYSCALL(ni_syscall)
+SYSCALL_SPU(timerfd_create)
SYSCALL_SPU(eventfd)
COMPAT_SYS_SPU(sync_file_range2)
COMPAT_SYS(fallocate)
SYSCALL(subpage_prot)
+COMPAT_SYS_SPU(timerfd_settime)
+COMPAT_SYS_SPU(timerfd_gettime)
diff --git a/include/asm-powerpc/unistd.h b/include/asm-powerpc/unistd.h
index fedc4b8..ce91bb6 100644
--- a/include/asm-powerpc/unistd.h
+++ b/include/asm-powerpc/unistd.h
@@ -328,15 +328,17 @@
#define __NR_epoll_pwait 303
#define __NR_utimensat 304
#define __NR_signalfd 305
-#define __NR_timerfd 306
+#define __NR_timerfd_create 306
#define __NR_eventfd 307
#define __NR_sync_file_range2 308
#define __NR_fallocate 309
#define __NR_subpage_prot 310
+#define __NR_timerfd_settime 311
+#define __NR_timerfd_gettime 312
#ifdef __KERNEL__
-#define __NR_syscalls 311
+#define __NR_syscalls 313
#define __NR__exit __NR_exit
#define NR_syscalls __NR_syscalls
--
1.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-11 0:14 UTC (permalink / raw)
To: Sean MacLennan; +Cc: LinuxPPC-dev
In-Reply-To: <47ACE630.8090101@pikatech.com>
On Fri, Feb 08, 2008 at 06:30:56PM -0500, Sean MacLennan wrote:
> The Rev B warp is moving to a 4M NOR / 256M NAND flash setup from the
> current 64M NOR / 64M NAND. I would like to keep support for the 64M NOR
> so I modified the boot code to be a bit more dynamic. Here is the new
> NOR parition layout in the DTS:
>
> nor_flash@0,0 {
> compatible = "amd,s29gl512n", "cfi-flash";
> bank-width = <2>;
> reg = <0 0 4000000>;
> #address-cells = <1>;
> #size-cells = <1>;
> partition@300000 {
> label = "fpga";
> reg = <300000 40000>;
> };
> partition@340000 {
> label = "env";
> reg = <340000 40000>;
> };
> partition@380000 {
> label = "u-boot";
> reg = <380000 80000>;
> };
> };
>
> Yes, the top of the NOR will be empty. Here is the code from
> cuboot-warp.c to handle fixups for the 64M flash:
>
> static void warp_fixup_one_nor(u32 from, u32 to)
> {
> void *devp;
> char name[40];
> u32 v[2];
>
> sprintf(name, "/plb/opb/ebc/nor_flash@0,0/partition@%x", from);
>
> devp = finddevice(name);
> if (!devp) return;
>
> if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
> v[0] = to;
> setprop(devp, "reg", v, sizeof(v));
>
> printf("NOR 64M fixup %x -> %x\n", from, to);
> }
> }
>
>
> static void warp_fixups(void)
> {
> unsigned long sysclk = 66000000;
>
> ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
> ibm4xx_sdram_fixup_memsize();
> ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
> dt_fixup_mac_addresses(&bd.bi_enetaddr);
>
> /* Fixup for 64M flash on Rev A boards. */
> if(bd.bi_flashsize == 0x4000000) {
> warp_fixup_one_nor(0x300000, 0x3f00000);
> warp_fixup_one_nor(0x340000, 0x3f40000);
> warp_fixup_one_nor(0x380000, 0x3f80000);
> }
> }
This doesn't seem right. warp_fixup_one_nor() changes only the
partition's offset, so you're not changing the size of any
partitions. If you're not going to actually use any of the extra
flash space with 64M, I can't see why you'd bother moving around the
partitions you have.
> I have tested this with the 64M NOR, and it seems to work. However, are
> there going to be problems with the partition name not matching the reg
> address entry?
In practice, probably not. We already do a similar fixup on Ebony for
different flash layouts that won't leave the unit names correct. We
really should get this right - and the fdt_set_name() function that's
now in libfdt should make that possible, it just needs some wiring up
to use in the bootwrapper. That can come later, though, for now I
think applying your fixups without correcting the unit addresses is
adequate.
> If anybody has suggestions on better ways to do this, fire away.
>
> And looking at this code, and other board ports, why is sysclk a local
> variable and all the other numbers hardcoded in the args? I left it the
> same way as the others but it does look a bit strange.
I think this also came from Ebony. IIRC, the sysclk isn't strictly
speaking fixed, although it almost always has initialized value. The
point of the local variable was that I planned to replace the static
initialization with some sort of probing once I figured out the
details.
--
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
* Where is fcc_enet.c
From: Bizhan Gholikhamseh (bgholikh) @ 2008-02-10 23:08 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 186 bytes --]
Hi,
I am porting to Linux 2.6.24 from linux 2.6.11 on mpc85xx cds platform,
I am not able to locate fcc_enet.c file under
linux 2.6.24 source tree, any idea????
Thanks,
Bizhan
[-- Attachment #2: Type: text/html, Size: 926 bytes --]
^ permalink raw reply
* [PATCH 1/8] arch/ppc: Use FIELD_SIZEOF
From: Julia Lawall @ 2008-02-10 20:07 UTC (permalink / raw)
To: paulus, linuxppc-dev
From: Julia Lawall <julia@diku.dk>
Robert P.J. Day proposed to use the macro FIELD_SIZEOF in replace of code
that matches its definition.
The modification was made using the following semantic patch
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@haskernel@
@@
#include <linux/kernel.h>
@depends on haskernel@
type t;
identifier f;
@@
- (sizeof(((t*)0)->f))
+ FIELD_SIZEOF(t, f)
@depends on haskernel@
type t;
identifier f;
@@
- sizeof(((t*)0)->f)
+ FIELD_SIZEOF(t, f)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
diff -u -p a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
--- a/arch/ppc/8xx_io/commproc.c 2008-02-02 15:28:16.000000000 +0100
+++ b/arch/ppc/8xx_io/commproc.c 2008-02-10 17:36:23.000000000 +0100
@@ -43,7 +43,7 @@
({ \
u32 offset = offsetof(immap_t, member); \
void *addr = ioremap (IMAP_ADDR + offset, \
- sizeof( ((immap_t*)0)->member)); \
+ FIELD_SIZEOF(immap_t, member)); \
addr; \
})
^ 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