* RE: Bootloader & Flash
From: MingLiu @ 2007-11-09 14:19 UTC (permalink / raw)
To: schardt; +Cc: linuxppc-embedded
In-Reply-To: <47346BB7.2000009@fz-juelich.de>
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]
Sometimes the simplest error is the most diffucult one to be found. :)
Have fun.
BR
Ming
> Date: Fri, 9 Nov 2007 15:16:23 +0100> From: g.schardt@fz-juelich.de> To: eemingliu@hotmail.com> CC: linuxppc-embedded@ozlabs.org> Subject: Re: Bootloader & Flash> > Argl :)> > The error was so ... simple.> The Flash device is broken. I take a new MiniModul and all things are> running.> > Thanks a lot> Georg> > MingLiu wrote:> > Hi,> >> > > - I have download the zImage.elf via the EDK flash loader> > > - The flash loader creates a bootloader, this is also running on> > start up :)> >> > What you need to store in flash memory, is not the .elf file. Before> > you use EDK flash loader to burn your linux kernel in flash, .elf file> > should be transfered into .srec file, just like the below reminds you:> > SREC line is corrupted.> >> >> > > But ... It stops with an error-message after a few seconds:> > >> > > EDK Bootloader:> > > Bootloader: Processed (0x)000000b2 S-recordsERROR: SREC line is> > corrupted> > >> > > What now ?> >> > Hopefully it helps.> >> > BR> > Ming> >> > ------------------------------------------------------------------------> > 用 Windows Live Spaces 展示个性自我，与好友分享生活！ 了解更多信息！> > <http://spaces.live.com/?page=HP>> > > > -----------------------------------------------------------------------------------------> -----------------------------------------------------------------------------------------> Forschungszentrum Jülich GmbH> 52425 Jülich> > Sitz der Gesellschaft: Jülich> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498> Vorsitzende des Aufsichtsrats: MinDirig'in B"arbel Brumme-Bothe> Gesch"aftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. > Vorsitzender)> -----------------------------------------------------------------------------------------> -----------------------------------------------------------------------------------------
_________________________________________________________________
Windows Live Spaces 中最年轻的成员！
http://miaomiaogarden2007.spaces.live.com/
[-- Attachment #2: Type: text/html, Size: 2852 bytes --]
^ permalink raw reply
* Re: Bootloader & Flash
From: schardt @ 2007-11-09 14:16 UTC (permalink / raw)
To: MingLiu; +Cc: linuxppc-embedded
In-Reply-To: <BAY138-W21A6D92355C81BE1341628B2840@phx.gbl>
Argl :)
The error was so ... simple.
The Flash device is broken. I take a new MiniModul and all things are
running.
Thanks a lot
Georg
MingLiu wrote:
> Hi,
>
> > - I have download the zImage.elf via the EDK flash loader
> > - The flash loader creates a bootloader, this is also running on
> start up :)
>
> What you need to store in flash memory, is not the .elf file. Before
> you use EDK flash loader to burn your linux kernel in flash, .elf file
> should be transfered into .srec file, just like the below reminds you:
> SREC line is corrupted.
>
>
> > But ... It stops with an error-message after a few seconds:
> >
> > EDK Bootloader:
> > Bootloader: Processed (0x)000000b2 S-recordsERROR: SREC line is
> corrupted
> >
> > What now ?
>
> Hopefully it helps.
>
> BR
> Ming
>
> -----------------------------------------------------------------------=
-
> =D3=C3 Windows Live Spaces =D5=B9=CA=BE=B8=F6=D0=D4=D7=D4=CE=D2=A3=AC=D3=
=EB=BA=C3=D3=D1=B7=D6=CF=ED=C9=FA=BB=EE=A3=A1 =C1=CB=BD=E2=B8=FC=B6=E0=D0=
=C5=CF=A2=A3=A1
> <http://spaces.live.com/?page=3DHP>
-------------------------------------------------------------------------=
----------------
-------------------------------------------------------------------------=
----------------
Forschungszentrum J=A8=B9lich GmbH
52425 J=A8=B9lich
Sitz der Gesellschaft: J=A8=B9lich
Eingetragen im Handelsregister des Amtsgerichts D=A8=B9ren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in B"arbel Brumme-Bothe
Gesch"aftsf=A8=B9hrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich=
Krafft (stellv.=20
Vorsitzender)
-------------------------------------------------------------------------=
----------------
-------------------------------------------------------------------------=
----------------
^ permalink raw reply
* Re: [PATCH v3 07/13] [POWERPC] TQM5200 DTS
From: Marian Balakowicz @ 2007-11-09 14:15 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071106223646.GD31367@localhost.localdomain>
David Gibson wrote:
> On Tue, Nov 06, 2007 at 09:05:48PM +0100, Marian Balakowicz wrote:
>> Add device tree source file for TQM5200 board.
> [snip]
>> + usb@1000 {
>> + device_type = "usb-ohci-be";
>
> This device_type is bogus. Remember having a valid device_type is the
> exception not the rule. Really the only common device_type values are
> "cpu", "memory", "network" and "serial".
Ok, rechecked this one, doesn't seem necessary, removed.
>> + serial@2000 { // PSC1
>> + device_type = "serial";
>> + compatible = "mpc5200-psc-uart";
>> + port-number = <0>; // Logical port assignment
>
> I know you said this is still needed, but the driver really needs to
> be fixed. This is not a proper way of using the device tree for
> logical numbering.
True, driver needs fixing, but there are also other boards that use
that driver, and I am not able to test them right now. And, as I
recall Grant mentioned that he's working on straightening this up.
Cheers,
m.
^ permalink raw reply
* Re: [PATCH v3 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Marian Balakowicz @ 2007-11-09 14:11 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071107133426.63593b98.sfr@canb.auug.org.au>
Hi Stephen,
Stephen Rothwell wrote:
>
> On Tue, 06 Nov 2007 21:05:20 +0100 Marian Balakowicz <m8@semihalf.com> wrote:
>> +++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
>> +
>> +#include <linux/pci.h>
>> +#include <linux/of.h>
>> +#include <asm/time.h>
>> +#include <asm/io.h>
>
> Its not clear to me that you need any of the above four includes.
#include <asm/time.h> is needed for generic_calibrate_decr() but other
few includes are in fact not necessary. Thanks.
Cheers,
m.
^ permalink raw reply
* Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Grant Likely @ 2007-11-09 13:57 UTC (permalink / raw)
To: Domen Puncer, Jeff Garzik; +Cc: PowerPC dev list, netdev
In-Reply-To: <20071109091245.GA3148@nd47.coderock.org>
On 11/9/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> On 09/11/07 00:31 -0500, Jon Smirl wrote:
> > This is the reason I couldn't get user space started or connect to my
> > nfs server. Patch is against current linus git.
> >
> > mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> > where the wrong skb buffer was being referenced.
> >
> > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>
> Acked-by: Domen Puncer <domen.puncer@telargo.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Jeff, can you please pick this up for .24?
Thanks,
g.
>
> I can't test it at the moment, but the patch is obviously correct,
> mapped buffer should be the _same_ as submitted.
>
> >
> > ---
> >
> > drivers/net/fec_mpc52xx.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> >
> > diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> > index a8a0ee2..ddfcc0b 100644
> > --- a/drivers/net/fec_mpc52xx.c
> > +++ b/drivers/net/fec_mpc52xx.c
> > @@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > irq, void *dev_id)
> >
> > rskb =3D bcom_retrieve_buffer(priv->rx_dmatsk, &status,
> > (struct bcom_bd **)&bd);
> > - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FRO=
M_DEVICE);
> > + dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_FR=
OM_DEVICE);
> >
> > /* Test for errors in received frame */
> > if (status & BCOM_FEC_RX_BD_ERRORS) {
> > @@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > irq, void *dev_id)
> > bcom_prepare_next_buffer(priv->rx_dmatsk);
> >
> > bd->status =3D FEC_RX_BUFFER_SIZE;
> > - bd->skb_pa =3D dma_map_single(&dev->dev, rskb->data,
> > + bd->skb_pa =3D dma_map_single(&dev->dev, skb->data,
> > FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> >
> > bcom_submit_next_buffer(priv->rx_dmatsk, skb);
> >
> >
> > --
> > Jon Smirl
> > jonsmirl@gmail.com
>
> --
> Domen Puncer | Research & Development
> .........................................................................=
....................
> Telargo d.o.o. | Zagreb=9Aka cesta 20 | 2000 Maribor | Slovenia
> .........................................................................=
....................
> www.telargo.com
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Anton Vorontsov @ 2007-11-09 13:33 UTC (permalink / raw)
To: Kim Phillips; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071105121530.5c38fbb7.kim.phillips@freescale.com>
On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> Hello all,
>
> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> according to erratum #2 (erratum text included below). Basically the
> most intrusive part is the addition of two new RGMII Internal Delay
> modes; one for TX delay only, and the other for RX delay only (i.e, not
> both at the same time).
>
> Please review, and since this affects both netdev and powerpc trees,
> one maintainer should ack them for the other to push upstream (i.e,
> Kumar acks them, and Leo picks them up to go through netdev or the
> other way around; either way is fine with me). I'm hoping they're
> trivial enough to go in 2.6.24.
All five patches are
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Let's hope they'll hit 2.6.24.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] ehea: Add kdump support
From: Thomas Klein @ 2007-11-09 13:33 UTC (permalink / raw)
To: Jeff Garzik
Cc: Michael Neuling, Jan-Bernd Themann, netdev, linux-kernel,
linux-ppc, Christoph Raisch, Paul Mackerras, Marcus Eder,
Stefan Roscher
To support ehea driver reloading in a kdump kernel the driver has to perform
firmware handle deregistrations when the original kernel crashes. As there's
currently no notifier chain for machine crashes this patch enables kdump support
in the ehea driver by bending the ppc_md.machine_crash_shutdown hook to its own
machine crash handler. The original machine_crash_shutdown() fn is called
afterwards. This works fine as long as the ehea driver is the only one which
does so. Problems may occur if other drivers do the same and unload regularly.
This patch enables 2.6.24-rc2 to use kdump with ehea and only puts a very
low risk on base kernel. In 2.6.24 we know ehea is the only user of this
mechanism. The next step for 2.6.25 would be to add a proper notifier chain.
The full solution might be that register_reboot_notifier() provides sth
like a SYS_CRASH action. Please apply.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 28 ++++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index f78e5bf..5935899 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0080"
+#define DRV_VERSION "EHEA_0081"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index f0319f1..40a732e 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -37,6 +37,7 @@
#include <linux/reboot.h>
#include <net/ip.h>
+#include <asm-powerpc/machdep.h>
#include "ehea.h"
#include "ehea_qmr.h"
@@ -98,6 +99,7 @@ static int port_name_cnt = 0;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags = 0;
struct work_struct ehea_rereg_mr_task;
+static void (*orig_machine_crash_shutdown)(struct pt_regs *regs);
struct semaphore dlpar_mem_lock;
@@ -3312,6 +3314,29 @@ static struct notifier_block ehea_reboot_nb = {
.notifier_call = ehea_reboot_notifier,
};
+void ehea_crash_notifier(struct pt_regs *regs)
+{
+ ehea_info("Machine crash: freeing all eHEA resources");
+ ibmebus_unregister_driver(&ehea_driver);
+ orig_machine_crash_shutdown(regs);
+}
+
+void ehea_register_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ orig_machine_crash_shutdown =
+ (void*)__xchg_u64((unsigned long*)&ppc_md.machine_crash_shutdown,
+ (unsigned long)ehea_crash_notifier);
+#endif
+}
+
+void ehea_unregister_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ ppc_md.machine_crash_shutdown = orig_machine_crash_shutdown;
+#endif
+}
+
static int check_module_parm(void)
{
int ret = 0;
@@ -3369,6 +3394,7 @@ int __init ehea_module_init(void)
goto out;
register_reboot_notifier(&ehea_reboot_nb);
+ ehea_register_crash_notifier();
ret = ibmebus_register_driver(&ehea_driver);
if (ret) {
@@ -3382,6 +3408,7 @@ int __init ehea_module_init(void)
ehea_error("failed to register capabilities attribute, ret=%d",
ret);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ibmebus_unregister_driver(&ehea_driver);
goto out;
}
@@ -3396,6 +3423,7 @@ static void __exit ehea_module_exit(void)
driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
ibmebus_unregister_driver(&ehea_driver);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ehea_destroy_busmap();
}
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Anton Vorontsov @ 2007-11-09 13:25 UTC (permalink / raw)
To: Kim Phillips; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071108131135.e16a2f9a.kim.phillips@freescale.com>
On Thu, Nov 08, 2007 at 01:11:35PM -0600, Kim Phillips wrote:
[...]
> right, but whether it does or not doesn't affect your failure outcome
> either I'm assuming.
>
> > > If it's something like 0x03, the u-boot patch will probably look like:
> > >
> > > if ((bcsr[12] == 0x10) &&
> > > (immr->sysconf.spridr == SPR_8360_REV21 ||
> > > immr->sysconf.spridr == SPR_8360E_REV21))
> > > /* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> > > ...
> > >
> > > but these linux patches would remain the same (the clk and data delay
> > > settings for the UCC's are still valid; it's just the PHY config
> > > that is triggering your problem from what I can tell).
> >
> > Yup, most likely this is not UCC specific, but PHY. For some reason
> > delays making harm here...
And today I was unable to reproduce yesterday's behaviour. Your
patches works fine, with sixth patch and without it. With -rxid
and with just -id.
Though, after few resets I hit on that:
- - - -
U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
Reset Status: External/Internal Soft, External/Internal Hard
CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
Board: Freescale MPC8360EMDS
I2C: ready
DRAM: 256 MB (DDR2, 64-bit, ECC on)
SDRAM: 64 MB (local bus)
FLASH: 32 MB
In: serial
Out: serial
Err: serial
Net: UEC: PHY is Marvell 88E11x1 (1410cc2)
FSL UEC0: Full Duplex
switching to rgmii 100
FSL UEC0: Speed 100BT
FSL UEC0: Link is up
read wrong value : mii_id 1,mii_reg 2, base e0103120
read wrong value : mii_id 1,mii_reg 3, base e0103120
UEC: PHY is Generic MII (ffffffff)
read wrong value : mii_id 1,mii_reg 1, base e0103120
read wrong value : mii_id 1,mii_reg 1, base e0103120
read wrong value : mii_id 1,mii_reg 5, base e0103120
FSL UEC1: Full Duplex
switching to rgmii 100
FSL UEC1: Speed 100BT
FSL UEC1: Link is up
FSL UEC0, FSL UEC1
- - - -
And UCC1 does not work at all. After another reset that message
disappears and it does work again.
So, I think hardware is tricking me in various ways, not your
patches fault.
:-(
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* auto soft reset after kernel crash?
From: robert lazarski @ 2007-11-09 13:25 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm trying to read the __log_buf after a kernel crash on a custom
board via a software reset. While I'm waiting for the hardware guys to
give me a sw reset button, I've noticed that the particular 2.6.22
kernel I'm using software resets itself around 7 minutes after a
crash. I tried a 2.6.23 kernel to see if my problem was related to
kernel version and it doesn't reset itself. Is this reset indeed a
kernel feature? How do I enable / disable it and set the amount of
time it waits before it resets? I went thru the menuconfig features
and couldn't enable a sw reset. Any ideas?
Thanks,
Robert
^ permalink raw reply
* Appletouch going wild
From: Andreas Schwab @ 2007-11-09 12:58 UTC (permalink / raw)
To: linux-input; +Cc: linuxppc-dev
Every once in a while the touchpad in my iBook G4 (geyser1, 030B) is
going wild, emitting random movement events even when not being touched.
That started only with 2.6.24-rc1. The only way to stop it is to reload
the appletouch module. My guess would be that reinitializing the
touchpad can result in some kind of race condition.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* RE: Bootloader & Flash
From: MingLiu @ 2007-11-09 12:51 UTC (permalink / raw)
To: schardt; +Cc: linuxppc-embedded
In-Reply-To: <47344D70.4050308@fz-juelich.de>
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
Hi,
> - I have download the zImage.elf via the EDK flash loader> - The flash loader creates a bootloader, this is also running on start up :)
What you need to store in flash memory, is not the .elf file. Before you use EDK flash loader to burn your linux kernel in flash, .elf file should be transfered into .srec file, just like the below reminds you: SREC line is corrupted.
> But ... It stops with an error-message after a few seconds:> > EDK Bootloader:> Bootloader: Processed (0x)000000b2 S-recordsERROR: SREC line is corrupted> > What now ?
Hopefully it helps.
BR
Ming
_________________________________________________________________
Windows Live Spaces 中最年轻的成员！
http://miaomiaogarden2007.spaces.live.com/
[-- Attachment #2: Type: text/html, Size: 1005 bytes --]
^ permalink raw reply
* Re: [PATCH] balance ioremap/iounmap in {sycamore, walnut}_setup_arch()
From: Roel Kluin @ 2007-11-09 12:32 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <47333EDA.4080907@ru.mvista.com>
Valentine Barshak wrote:
> Roel Kluin wrote:
>> I guess it should be done after the last usage of kb_data or fpga_status?
>
> I think no iounmap(kb_data) needed. Looks like the pointer kn_cs (kb_cs
> = kb_data + 1) is used by the serio driver
> (drivers/input/serio/i8042-ppcio.h).
> Please note that we just ioremap and assign pointers here, not actually
> reading the registers.
> Also, looks like you unmap the fpga registers too early.
> Thanks,
> Valentine.
Thanks for your pointers. I'm new, so I'm not sure how this should be done. I
have removed the iounmap(kb_data), and moved the iounmap(fpga_status) lower.
possibly the latter could be done before the sycamore_rtc_base assignment?
--
Balance ioremap/iounmap
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/ppc/platforms/4xx/sycamore.c b/arch/ppc/platforms/4xx/sycamore.c
index 8689f3e..6ce4815 100644
--- a/arch/ppc/platforms/4xx/sycamore.c
+++ b/arch/ppc/platforms/4xx/sycamore.c
@@ -132,6 +132,7 @@ sycamore_setup_arch(void)
sycamore_rtc_base = (void *) SYCAMORE_RTC_VADDR;
TODC_INIT(TODC_TYPE_DS1743, sycamore_rtc_base, sycamore_rtc_base,
sycamore_rtc_base, 8);
+ iounmap(fpga_status);
/* Identify the system */
printk(KERN_INFO "IBM Sycamore (IBM405GPr) Platform\n");
^ permalink raw reply related
* Re: Bootloader & Flash
From: schardt @ 2007-11-09 12:07 UTC (permalink / raw)
To: MingLiu; +Cc: linuxppc-embedded
In-Reply-To: <BAY138-W14EEE9667CD669878D3BD0B28A0@phx.gbl>
Hi again,
i've learned a little bit :)
- I have download the zImage.elf via the EDK flash loader
- The flash loader creates a bootloader, this is also running on start up=
:)
But ... It stops with an error-message after a few seconds:
EDK Bootloader:
Bootloader: Processed (0x)000000b2 S-recordsERROR: SREC line is corrupted=
What now ?
Georg
MingLiu wrote:
> Dear Georg,
> I guess you were talking about the booting process of the system, both =
HW and the SW, from the flash memory. This process should be like this:
>
> 1. Store your HW bitstream and Linux kernel in flash memories. If neede=
d, perhaps you want another bootloader program, such as U-boot also insid=
e.=20
>
> 2. In your HW bitstream, you need one bootloader which helps you to loa=
d the software and execute it in DDR-ram. EDK helps you to generate such =
a bootloader when you design.=20
>
> 3. Durong Power on, HW bitstream (with an EDK bootloader included) will=
be loaded into FPGA and configure the FPGA, then the EDK bootloader will=
load your Linux kernel into DDR-Ram and execute it there. Thus your linu=
x could run.=20
>
> This is a normal process. If you want to execute the program in flash d=
irectly, that's another story. Also you should know, for the booting proc=
ess, MTD driver is not necessary. The driver is only used when you want t=
o access flash memories when you booted your Linux kernel.
>
> Clear or not? :)
>
> Best Regards
> Ming
>
> ----------------------------------------> Date: Wed, 7 Nov 2007 13:00:3=
5 +0100> From: g.schardt@fz-juelich.de> To: Linuxppc-embedded@ozlabs.org>=
Subject: Bootloader & Flash>> Hi,>> i use the AVnet Xilinx4 FX12 Minimod=
ule and until now, i use system-ace> to configure the fpga and boot the l=
inux kernel.> But now, i want to boot from the on board flash memory and =
have no idea> where to start.>> I think i have to:> - save the fpga confi=
guration in the fpga-prom> - use/program some kind of bootloader store in=
fpga block ram to jump to> the flash-adress where the executable linux k=
ernel resist> - use the mtd-device driver to mount root fs on the same fl=
ash some> address later>> Is this the right way ?>>> Regards> Georg>>>>>>=
> -----------------------------------------------------------------------=
------------------> -----------------------------------------------------=
------------------------------------> Forschungszentrum J=C3=BClich GmbH>=
52425 J=C3=BClich>> Sitz der Gesellschaft: J=C3=BClich> Eingetragen im H=
andelsregister des Amtsgerichts D=C3=BCren Nr. HR B 3498> Vorsitzende des=
Aufsichtsrats: MinDirig'in B=C3=A4rbel Brumme-Bothe> Gesch=C3=A4ftsf=C3=BC=
hrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.>=
Vorsitzender)> ---------------------------------------------------------=
--------------------------------> ---------------------------------------=
--------------------------------------------------> _____________________=
__________________________> Linuxppc-embedded mailing list> Linuxppc-embe=
dded@ozlabs.org> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _________________________________________________________________
> MSN =E4=B8=AD=E6=96=87=E7=BD=91=EF=BC=8C=E6=9C=80=E6=96=B0=E6=97=B6=E5=B0=
=9A=E7=94=9F=E6=B4=BB=E8=B5=84=E8=AE=AF=EF=BC=8C=E7=99=BD=E9=A2=86=E8=81=9A=
=E9=9B=86=E9=97=A8=E6=88=B7=E3=80=82
> http://cn.msn.com
=0A=0A-------------------------------------------------------------------------=
----------------=0A-----------------------------------------------------------=
------------------------------=0AForschungszentrum J=C3=BClich GmbH=0A52425 J=C3=BClich=
=0A=0ASitz der Gesellschaft: J=C3=BClich=0AEingetragen im Handelsregister des Amtsgeri=
chts D=C3=BCren Nr. HR B 3498=0AVorsitzende des Aufsichtsrats: MinDirig'in B=C3=A4rbel=
Brumme-Bothe=0AGesch=C3=A4ftsf=C3=BChrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr.=
Ulrich Krafft (stellv. =0AVorsitzender)=0A-------------------------------------=
----------------------------------------------------=0A-----------------------=
------------------------------------------------------------------=0A
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Sergej Stepanov @ 2007-11-09 11:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <47336F9D.8060405@freescale.com>
Am Donnerstag, den 08.11.2007, 14:20 -0600 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > If both mdio and mdc controlling pins are on the same processor port,
> > one resource should be used.
> > Otherwise, two resources are used: the 1-st - mdio, the 2-nd - mdc.
>
> How about:
> The first reg resource is the I/O port register block on which MDIO
> resides. The second reg resource is the I/O port register block on
> which MDC resides. If there is only one reg resource, it is used for
> both MDIO and MDC.
>
Ok.
> We also need to change the reference to port C in fsl,mdio-pin and
> fsl,mdc-pin.
Do you mean this:
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
-> fsl,cpm2-mdio-bitbang (reg is port C registers)
Properties for fsl,cpm2-mdio-bitbang:
-> fsl,mdio-pin : pin of port C controlling mdio data
-> fsl,mdc-pin : pin of port C controlling mdio clock
Right. But i thought it would be related to the example,
and than the reader gets the short comment about I/O ports.
Or the other variant would be:
--------------------
iv) MDIO
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
fsl,cpm2-mdio-bitbang (reg is the I/O port register block(s))
Properties for fsl,cpm2-mdio-bitbang:
The first reg resource is the I/O port register block on which MDIO
resides. The second reg resource is the I/O port register block on
which MDC resides. If there is only one reg resource, it is used for
both MDIO and MDC.
fsl,mdio-pin : pin of chosen port for controlling mdio data
fsl,mdc-pin : pin of chosen port for controlling mdio clock
Example:
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
reg = <10d40 14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <12>;
fsl,mdc-pin = <13>;
};
-----------------
Regards
Sergej.
^ permalink raw reply
* Please pull from 'for-2.6.24' branch
From: Kumar Gala @ 2007-11-09 9:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.24' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.24
to receive the following updates:
arch/powerpc/Makefile | 3 +++
arch/powerpc/sysdev/cpm_common.c | 4 +---
include/asm-powerpc/tlbflush.h | 4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
Kumar Gala (2):
[POWERPC] Add -mno-spe for ARCH=powerpc builds
[POWERPC] Fix oops related to 4xx flush_tlb_page modification
Scott Wood (1):
[POWERPC] cpm: Fix a couple minor issues in cpm_common.c.
^ permalink raw reply
* [PATCH] [POWERPC] Fix oops related to 4xx flush_tlb_page modification
From: Kumar Gala @ 2007-11-09 9:58 UTC (permalink / raw)
To: linuxppc-dev
kmap_atomic calls flush_tlb_page with a NULL VMA and thus we end
up dereferencing a NULL pointer to try and get the context.id.
If the VMA is null use the global pid value of 0.
---
include/asm-powerpc/tlbflush.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/tlbflush.h b/include/asm-powerpc/tlbflush.h
index e7b4c0d..5c91081 100644
--- a/include/asm-powerpc/tlbflush.h
+++ b/include/asm-powerpc/tlbflush.h
@@ -44,13 +44,13 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr, vma->vm_mm->context.id);
+ _tlbie(vmaddr, vma ? vma->vm_mm->context.id : 0);
}
static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr, vma->vm_mm->context.id);
+ _tlbie(vmaddr, vma ? vma->vm_mm->context.id : 0);
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
--
1.5.3.3
^ permalink raw reply related
* Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Domen Puncer @ 2007-11-09 9:12 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, netdev
In-Reply-To: <9e4733910711082131v70c4b7bm2b00445b7e62c33f@mail.gmail.com>
On 09/11/07 00:31 -0500, Jon Smirl wrote:
> This is the reason I couldn't get user space started or connect to my
> nfs server. Patch is against current linus git.
>
> mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> where the wrong skb buffer was being referenced.
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Acked-by: Domen Puncer <domen.puncer@telargo.com>
I can't test it at the moment, but the patch is obviously correct,
mapped buffer should be the _same_ as submitted.
>
> ---
>
> drivers/net/fec_mpc52xx.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
>
> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> index a8a0ee2..ddfcc0b 100644
> --- a/drivers/net/fec_mpc52xx.c
> +++ b/drivers/net/fec_mpc52xx.c
> @@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> irq, void *dev_id)
>
> rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
> (struct bcom_bd **)&bd);
> - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FROM_DEVICE);
> + dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_FROM_DEVICE);
>
> /* Test for errors in received frame */
> if (status & BCOM_FEC_RX_BD_ERRORS) {
> @@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> irq, void *dev_id)
> bcom_prepare_next_buffer(priv->rx_dmatsk);
>
> bd->status = FEC_RX_BUFFER_SIZE;
> - bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
> + bd->skb_pa = dma_map_single(&dev->dev, skb->data,
> FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
>
> bcom_submit_next_buffer(priv->rx_dmatsk, skb);
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
--
Domen Puncer | Research & Development
.............................................................................................
Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
.............................................................................................
www.telargo.com
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Benjamin Herrenschmidt @ 2007-11-09 7:50 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071109074155.266120@gmx.net>
> I tried to use /bin/sh as init program and was able to enter a command,
> but then the machine locked up, too.
> Could that be a problem with a CPU sleeping/idle code?
That's possibly an issue, try disabling power save if any for that CPU
type. If it worked and broke, you may have to bisect tho.
Ben.
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Gerhard Pircher @ 2007-11-09 7:41 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1194564017.6561.21.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Fri, 09 Nov 2007 10:20:17 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: Kernel locks up after calling kernel_execve()
>
> On Thu, 2007-11-08 at 22:47 +0100, Gerhard Pircher wrote:
> > Hi,
> >
> > I tested my patches for the AmigaOne platform with the lastest
> > 2.6.24-rc2 kernel snapshot. The kernel runs through all initcalls, but
> > locks up completely after calling INIT (/sbin/init) by kernel_execve().
> > Thus I couldn't capture any kernel oops or panic output. Also the magic
> > sysrq key doesn't work. Enabling debug code for soft lockups and
> > spinlock debugging didn't reveal any information.
> > I'm not sure, but I think it is the same problem I had with all kernels
> > >= 2.6.17. All of these kernels lock up shortly before or right at
> > calling the init program (resp. as soon as the kernel forks some kernel
> > theads).
> > Any suggestions on how to track down this problem?
>
> You don't have a HW debugger or anything like that ?
>
> Ben.
Unfortunately, no. A BDI2000 is too costly for me.
I tried to use /bin/sh as init program and was able to enter a command,
but then the machine locked up, too.
Could that be a problem with a CPU sleeping/idle code?
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* help linux for linux2.6
From: vincent.liu @ 2007-11-09 6:39 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200711091434079212507@bmrtech.com>
Hi
These days I am working on a MPC8270 based board with linux 2.6.10 kernel.
When I use the default kernel and load the uImage to the target board.
The kernel hangs after uncompressing kernel image ... ok .
I am freshman in the embedded linux area,So I do not know how to go on this project.
>From internet , I searched many articles,and no gain.
Please help me .
Thanks a lot.
--------------
vincent.liu
2007-11-09
^ permalink raw reply
* [PATCH] ibm_newemac: Add ET1011c PHY support
From: Stefan Roese @ 2007-11-09 6:07 UTC (permalink / raw)
To: linuxppc-dev
This adds support for the Agere ET1011c PHY as found on the AMCC Taishan
board.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/phy.c | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/phy.c b/drivers/net/ibm_newemac/phy.c
index 1404457..4270a66 100644
--- a/drivers/net/ibm_newemac/phy.c
+++ b/drivers/net/ibm_newemac/phy.c
@@ -314,6 +314,38 @@ static struct mii_phy_def bcm5248_phy_def = {
.ops = &generic_phy_ops
};
+static int et1011c_init(struct mii_phy *phy)
+{
+ u16 reg_short;
+
+ reg_short = (u16)(phy_read(phy, 0x16));
+ reg_short &= ~(0x7);
+ reg_short |= 0x6; /* RGMII Trace Delay*/
+ phy_write(phy, 0x16, reg_short);
+
+ reg_short = (u16)(phy_read(phy, 0x17));
+ reg_short &= ~(0x40);
+ phy_write(phy, 0x17, reg_short);
+
+ phy_write(phy, 0x1c, 0x74f0);
+ return 0;
+}
+
+static struct mii_phy_ops et1011c_phy_ops = {
+ .init = et1011c_init,
+ .setup_aneg = genmii_setup_aneg,
+ .setup_forced = genmii_setup_forced,
+ .poll_link = genmii_poll_link,
+ .read_link = genmii_read_link
+};
+
+static struct mii_phy_def et1011c_phy_def = {
+ .phy_id = 0x0282f000,
+ .phy_id_mask = 0x0fffff00,
+ .name = "ET1011C Gigabit Ethernet",
+ .ops = &et1011c_phy_ops
+};
+
static int m88e1111_init(struct mii_phy *phy)
{
printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
@@ -344,6 +376,7 @@ static struct mii_phy_def m88e1111_phy_def = {
};
static struct mii_phy_def *mii_phy_table[] = {
+ &et1011c_phy_def,
&cis8201_phy_def,
&bcm5248_phy_def,
&m88e1111_phy_def,
--
1.5.3.5.561.g140d
^ permalink raw reply related
* Re: [PATCH 2/6] ibm_newemac: Add ET1011c PHY support
From: Stefan Roese @ 2007-11-09 5:44 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1194555321.6561.4.camel@pasglop>
On Thursday 08 November 2007, Benjamin Herrenschmidt wrote:
> > DENX is pretty good about having Signed-off-by lines in their tree...
> > maybe you should add the original authors as well if it's there.
>
> I picked it up from an already patched tree. Stefan, can you provide me
> the proper SOB ?
Sure:
Signed-off-by: Stefan Roese <sr@denx.de>
Thanks.
Best regards,
Stefan
^ permalink raw reply
* [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Jon Smirl @ 2007-11-09 5:31 UTC (permalink / raw)
To: PowerPC dev list, Domen Puncer, Grant Likely, netdev
This is the reason I couldn't get user space started or connect to my
nfs server. Patch is against current linus git.
mpc5200 fec driver is corrupting memory. This patch fixes two bugs
where the wrong skb buffer was being referenced.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
drivers/net/fec_mpc52xx.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index a8a0ee2..ddfcc0b 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
irq, void *dev_id)
rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
(struct bcom_bd **)&bd);
- dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FROM_DEVICE);
+ dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_FROM_DEVICE);
/* Test for errors in received frame */
if (status & BCOM_FEC_RX_BD_ERRORS) {
@@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
irq, void *dev_id)
bcom_prepare_next_buffer(priv->rx_dmatsk);
bd->status = FEC_RX_BUFFER_SIZE;
- bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
+ bd->skb_pa = dma_map_single(&dev->dev, skb->data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(priv->rx_dmatsk, skb);
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Fix typo #ifdef -> #ifndef
From: Andrew Morton @ 2007-11-09 4:35 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: jeff, netdev, linux-kernel, linuxppc-embedded
In-Reply-To: <472CC914.3030709@scram.de>
> On Sat, 03 Nov 2007 20:16:36 +0100 Jochen Friedrich <jochen@scram.de> wrote:
> Subject: [PATCH] [POWERPC] Fix typo #ifdef -> #ifndef
Please put the "powerpc" outside the []. Because things inside [] get
removed when the receiver applies the patch, but the subsystem
identification ("powerpc") is useful information which we want to carry
into the permanent git record. (Although Paul might add it anyway - some
git tree maintainers do).
> User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009)
This seems to be setting a record for MUA vandalism. Leading spaces were
removed and various esoteric whitespace transformations were made. The
diffs were small so I fixed them by hand.
Please strangle your email client.
^ permalink raw reply
* Re: [PATCH 3/4] Use embedded libfdt in the bootwrapper
From: Jerry Van Baren @ 2007-11-09 0:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <473392A3.4010203@freescale.com>
Scott Wood wrote:
> David Gibson wrote:
>>> How hard would it be to get libfdt to dynamically allocate any extra space
>>> it needs? This is a regression from the current flat device tree code...
>> Uh.. it already does. Or rather, the shims in libfdt-wrapper.c do so,
>> when libfdt functions which can expand the tree report that they've
>> run out of room.
>
> Ah, good -- I was looking in libfdt itself, not the wrapper. Now if
> only we could get something similar into u-boot... maybe libfdt proper
> could accept an optional realloc() function pointer in fdt_init(), and
> eliminate the need for the caller to provide such a wrapper?
>
> -Scott
Hi Scott,
My concern from the u-boot side is that u-boot has to know exactly
*where* to put the expanded blob because it has to pass it to linux and
keep it out of linux' way so it doesn't get "stepped on." Linux has an
advantage in that it "owns" all of memory and can allocate and
deallocate whatever and wherever and it won't step on itself (hopefully).
I'm assuming your boot wedge has the advantage of being able to use
linux's malloc() and thus don't have to worry about coordinating with
linux on memory allocation.
With the current u-boot fdt command, you can resize the blob, and this
can be done in a script with all the (somewhat limited) capabilities of
the u-boot shell (an adaptation of hush).
In the u-boot world, we fixate on memory maps and putting things in
specific places. Maybe I'm making a problem where one doesn't exist,
but an arbitrary malloc() in u-boot (as opposed to linux's malloc) seems
like a Bad Thing[tm] because it is uncontrolled and may end up in a very
bad place when linux starts (e.g. the linux start up script expands
linux on top of the blob).
Best regards,
gvb
^ 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